►
From YouTube: IETF109-6MAN-20201117-0500
Description
6MAN meeting session at IETF109
2020/11/17 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
B
Hello,
I'm
bob
hinden,
and
this
is
only
tron
with
six
man
chairs-
welcome
to
ietf
109,
first
of
two
six-man
sessions,
so
using
meat
echo.
B
If
you
haven't,
read
the
procedures,
if
you
want
to
when
we
get
to
a
discussion.
If
you
want
to
be
recognized,
press
the
raise
hand
thing
and
then
we'll
tell
you
to
talk,
then
you
can
turn
on
your
audio
or
and
or
video
and
it'll
be
good
to
propose
that
for
the
speakers
that
you
turn
on
your
video
and
if
that
somehow
interferes
with
the
session
we'll
say
so,
but
you'll
also
need
to
turn
on
your
audio
and
video.
B
It's
the
icons
in
the
upper
right.
So
why
don't
we
get
started?
So
this
is
so
here's
the
meeting
notes
how
to
use
meat
echo
and
remember
to
state
your
name
when
you
speak.
Blue
sheets
are
automatic
this
time
by
logging
in
and
the
notes
are
on
code
mid.
B
So
this
is
the
no
well.
We
trust
you
have
agreed
to
this,
and
I
won't
read
it.
You
should
have
it
memorized
by
now.
Next
slide,
we
have
a
question:
edward
go
ahead,.
B
It's
easy
to
press
the
wrong
button,
so
we're
jabbering
is
automatic.
This
time
we
do
not
have
a
jabra
scribe,
but
I
think
that
will
be
okay.
You
know
if
you,
but
if
you
were
we're
both
watching
the
jabber
room,
so
if
anything
has
anything
to
raise,
you
can
still
use
it.
B
So
again
we
have
two
sessions,
we're
doing
mostly
the
the
new
internet
drafts
this
time-
and
you
can
all
read
this
so
some
of
these
have
had
some
discussion
on
the
list.
Some
have
not,
but
we
wanted
to
give
the
speakers
a
chance.
We,
as
we
said,
we
got
two
two-hour
sessions
for
this
meeting
next
slide,
and
this
is
the
friday
session.
B
We
have
we'll
do
an
introduction,
we'll
have
a
t,
a
report
of
the
source
routing,
basically
the
spring
design
team
report,
two
working
group
graphs,
the
minimum
path
and
minimum
mtu
hop
by
hop
option
and
application
of
alternate
marking
method
and
then
one
new
draft
that
the
request
for
a
slot
came
in
late.
So
we
put
that
at
the
end
of
the
session
next
slide,.
B
C
Yes,
so
the
document
status
update
since
the
last
meeting
we
have
published
one
rfc,
that's
the
is
icmp
limits
document
that
tom
herbert
authored,
eight
eight,
eight
three.
We
have
nothing
in
the
roc
edition
of
queue
and
we
have
three
documents
submitted
to
the
iesg.
C
It's
the
temporary
addresses
based
document,
it's
the
gratuitous
neighbor
discovery
document
that
gen
authored
and
it's
the
oem
document
for
segment
routine.
That's
so
far
authored,
so
those
are
just
just
quite
recently
advanced
to
the
isg,
so
it
will
be
a
little
while
I
think,
before
eric
gets
to
them
and
they
continue
through
the
process.
C
Then
we
have
no
documents
in
working
group
last
call,
so
we
cleaned
off
our
slate
quite
well,
and
we
have
three
documents
in
working
group
that
we
work
on.
Currently
it's
the
path
mtu
hop
by
hop
option
that
bob
and
gory
will
talk
about
later.
It's
the
alternate
marking
method
that
giuseppe
will
talk
about
on
friday
and
it's
the
improving
the
robustness
of
of
status.
Stateless
address,
also
configuration
by
fernando
that's
not
on
the
agenda.
For
this
this
meeting
we
have
a
report
on
friday
for
the
the
design
team.
C
The
sr
design
team
that
is
working
on
compact
routing
headers
as
sort
of
a
follow-on
work
on
the
segment
routing
stuff
that
six
man
has
been
doing
for
a
while.
They
have
a
session
on
friday
morning,
just
before
six
man
on
friday,
going
through
the
design
teamwork.
So
that's
certainly
worth
joining
that
session
as
well
before
they
come
and
give
a
readout
of
the
status
on
friday.
C
That
obviously
affects
you
know
that's
kind
of
this
crh
document
that
ron
has
that
has
been
left
in
stasis
awaiting
the
decision
from
from
the
design
team,
so
fred
templin,
I
believe
you
are
up.
Let
me
get
your
slides,
so
fred
is
going
to
talk
about
the
rp6
neighbor
option
for
the
omni.
The
only
draft
we're
not
presenting
the
main
draft
here,
but
only
the
neighbor
discovery
options.
Fred,
you've,
unmuted
yourself.
The
floor
is
yours:.
B
A
Okay,
so
this
is
a
draft
on
ipv6
neighbor
discovery,
overlay,
multi-link
network
interface
option
a
new
ipv6
neighbor
discovery
option
next
chart
please
so
the
draft
title
here
is
here:
draft
temple
and
six
man
omni
option.
It
is
specifying
a
new
ipv6,
neighbor
discovery,
option
type
and
it's
requesting
an
iana
assignment
for
that
type.
For
that
that
option
the
option
body
contains
tlv
format,
sub
options,
and
this
document
defines
an
initial
set.
A
The
option
may
occur
in
any
ipv6
neighbor
discovery
message
being
router
solicitation
advertisement,
neighbor,
solicitation,
neighbor
advertisement,
nodes
that
recognize
the
option
apply,
omni
conventions,
nodes
that
do
not
recognize
the
option,
simply
ignore
it,
and
the
iana
signed
value,
allows
immediate
option.
Recognition
in
a
single
octet
compare,
in
other
words,
just
check
the
type
and
that
determines
whether
the
peer
understands
omni
without
having
to
look
more
deeply
into
the
option.
A
So
it's
a
faster
processing
thing
the
fact
that
we've
gotten
a
unique
type
value
for
this
option
next
chart
please
so
the
overlay
multi
network
interface
option
is
essentially
type
and
length
are
the
same
for
standard
ipv6,
neighbor,
discovery
messages.
A
We
have
a
prefix
length
field,
source
target
in
index
field
and
then
the
sub
options
can
follow
immediately
after
the
the
first
four
octets
next
chart.
Please,
by
the
way,
there's
a
there's,
a
tab
that
says
olatron
screen
that
obscures
some
of
my
chart.
Is
there
a
way
to
to
turn
that
off.
B
It
that
only
shows
up
move
your
mouse
somewhere
else
on
the
display.
That's
that's
just
local
to
you.
A
A
A
Okay,
that's
that's
fine,
then.
Okay,
so
in
in
the
omni
option
header
we
have
a
type
field
which
is
set
to
tbd,
and
this
is
where
we're
requesting
the
iona
value
for
the
type
the
length
is
set
to
the
number
of
eight
octet
blocks,
the
same
as
for
any
ipv6
neighbor
discovery.
Option
type
prefix
length
is
a
one
octet
field
that
encodes
a
value
between
0
and
128
as
a
prefix
length
for
the
ipv6
source
or
destination
address
of
the
neighbor
discovery
message.
A
The
source
target
om
index
field
is
a
one
octet
field
that
encodes
a
value
between
0
and
255
that
identifies
the
source
or
target
underlying
interface
for
the
ipv6
neighbor
discovery
message.
Remember:
it's
called
overlay
multi-link
network
interface,
which
means
it's
an
overlay
over
underlying
interfaces,
and
this
field
tells
which
underlying
interface
that
the
message
is
either
going
out
over
or
coming
in
on.
A
That's
why
it's
called
source
target
and
then
again
the
sub
options
is
a
variable
length
field
of
length
such
that
the
complete
omni
option
is
an
integer
multiple
of
eight
octets
long
next
chart
place,
so
the
omni
option
may
appear
in
any
ipv6
neighbor
discovery
message
type.
It
is
processed
by
interfaces
that
recognize
the
option
and
ignored
by
all
other
interfaces.
A
If
a
single
ipv6
neighbor
discovery
message
contains
multiple
omni
options,
the
first
one
is
processed
and
any
additional
options
are
ignored.
So
an
omni
option
may
include
full
or
partial
information
for
the
neighbor
if
it
includes
full
information.
Its
contents
provide
new
information
and
or
update
any
previously
cached
information.
A
If
it
includes
only
partial
information,
it
updates
the
corresponding
cash
information.
So
that's
the
union
of
the
most
recently
received
omni
options
that
define
the
state.
That's
that's
been
established
by
the
omni
options
next
chart.
Please.
A
So
the
omni
sub
option
format
it.
The
the
sub
option
contains
zero
or
more
sub
options.
Each
one
is
concatenated
immediately
after
its
predecessor
all
sub
options,
except
pad
one
are
of
type
length
value,
encoded
format,
so
you
have
a
subtype
sub
length
and
sub
option
data.
A
A
Next
chart
please
this.
This
document
defines
the
following:
sub
options
pad
one,
which
is
one
that
we're
very
familiar
with
is
one
octet
of
zero.
Padding
pad
n
is
in
octets
of
zero
padding
number
option
some
option.
Number
two
is
interface
attributes
type
one.
A
Some
options
three
through
252
are
available
for
future
assignment
253
through
254
are
reserved
for
experimentation
and
255
is
reserved
by
iana,
and
other
documents
may
define
new
subtypes
next
chart
please
so
the
first
subtype
that
we
have
that
is
is
defined
is
called
the
interface
attribute
subtype,
and
this
is
a
type
one
interface
attributes.
A
The
interface
attributes
contains
again
subtype
and
sub
length.
Then
it
contains
a
omni
in
in
index,
omni
type
provider,
id
link,
metric
a
reserve
field
and
then
a
set
of
preferences
for
the
64
dscp
codes.
That
tells
what
the
preference
is
for
each
of
those
dscps
for
sending
packets
over
that
interface
and
those
preferences
are
encoded
as
low
medium,
high
or
disabled,
and
that
gives
an
indication
to
the
ip
layer
which
underlying
interface
among
potentially
multiple
the
packet
should
be
destined
to.
A
C
F
A
Well,
the
the
encoding
of
these
bits
takes
on
the
values:
zero
for
disabled
one
for
low
two
for
medium
and
three
for
high
and
that's
a
preference
for,
for
example,
p00
corresponds
to
dscp0,
p01
corresponds
to
dscp1
and
each
one
of
those
two
bit
fields
gives
a
disabled
low,
medium
high
and
it
corresponds
to
the
dscp
value
that
appears
in
the
ip
header.
The
packet
that's
being
examined
by
the
forwarding.
H
A
Okay,
so
now
in
this
interface,
attributes
subtype
is
set
to
two.
If
multiple
instances
with
different
om
index
values
appear
in
the
same
omni
option
all
are
processed.
If
multiple
instances
with
the
same
om
index
value
appear,
the
first
is
processed
and
all
others
are
ignored.
A
The
sub
length
is
again
set
from
to
a
value
n
from
1
to
255.
Then
it
encodes
the
number
of
sub-option
octet
data.
The
octets
that
follow
om
index
is
a
one
octave
field
that
encodes
a
value
from
zero
to
255.
Identifying
the
underlying
interface
for
which
the
interface
attributes
apply.
A
Om
type
is
a
one
octet
field
that
includes
a
value
that
corresponds
to
the
type
of
the
underlying
interface,
for
example,
ethernet
or
wi-fi
or
or
cellular
whatever.
The
underlying
interface
happens
to
be
there's
a
type
value
next
chart
place
provider
id
is
a
one.
Octet
field
contains
a
value
from
zero
to
255,
corresponding
to
the
underlying
interface
identified
by
om
index
and
again,
link
is
a
four
bit
link
metric.
A
The
value
0
means
the
link
is
down,
and
the
remaining
values
mean
that
the
link
is
up
with
metrics,
ranging
from
1
meaning
lowest
to
15,
which
is
highest
and
then
again.
The
16
octa
preferences
field,
which
we
just
discussed
with
eric's
question,
immediately
follows
the
reserve
field
with
values
p00
through
p63,
corresponding
to
the
64
differentiated
service
code,
point
values
and
again
each
two
bit
field
includes
disabled,
low,
medium
or
high,
which
is
the
preference
for
sending
packets
that
have
that
dscp
value
over
that
particular
underlying
interface.
A
Next
chart
please
so
sub
options
that
may
be
defined
in
in
future.
Documents
include
type
2
interface,
attributes,
traffic,
selector
mobility,
service
register
and
release
sub
options,
network
access,
identifier,
geographical
coordinates
and
dhcp,
unique
identifier,
and
I
won't
get
into
what
those
are
used
for.
That's
in
us
and
that's
in
in
future
documents
we'll
be
looking
to
define
these
new
sub
sub
option
types
next
chart
please
so
in
iana
considers
what
we're
asking
is
that
the
iana
allocate
a
type
number
for
the
registry.
A
Ipv6
neighbor
discovery
option
formats
for
the
omni
option
as
a
provisional
registration
in
accordance
with
rfc
8126.
A
The
omni
option
also
defines
an
8-bit
subtype
field,
for
which
the
ian
is
going
to
be,
instructed
to
create
and
maintain
a
new
registry
entitled
omni
option,
subtype
values
and
the
initial
values
from
the
omni
option.
Subtype
values
registry
are
are
given
well,
it
says
given
below,
but
the
document
contains
the
the
the
values
and
then
again,
future
assignments
are
to
may
be
made
through
expert
review.
According
to
rfc
8126.
A
B
B
B
So
if
you're
interested
in
thanks
dave
thaler
go.
A
A
I
E
Yeah
so
it
looks
to
me
like
the
main
use
of
this
option
is
for
omni
interfaces.
I
mean
I
was
trying
to
figure
out
what
problem
you're
trying
to
solve,
since
you
didn't
actually
present
that
in
here,
so
I
was
looking
at
the
draft
as
you
were
presenting
while
I
was
kind
of
following
along
where
you
were
presenting
in
the
draft
and
the
draft
talks
about
that.
The
problem
being
solved
is
in
the
omni
interface
is
one
and
so
first
a
clarifying
question.
E
Where
is
the
omni
interfaces
draft
but
don't
answer
it
yet,
because
I'm
just
going
to
get
all
my
questions
on
the
table
here.
First
and
then
you
can
answer,
I
I
understand
you're
saying
it
could
be
usable
by
other
interfaces,
but
if
I
was
looking
for
what
problem
you're
trying
to
solve,
where
would
I
look
and
which
draft
is
that?
Because
I
think
what
problem
you're
trying
to
solve?
If
there's
a
draft
and
they're
working
in
the
working
group,
then
the
working
group
document
should
also
have
what
problem
is
trying
to
solve.
E
That's
my
meta
question
and
then
the
last
comment
is,
if
I
remember
correctly,
the
allocation
policy
for
nd
option
numbers
is
rfc
required
right.
It's
not
iets
a
consensus.
It's
not!
You
know,
you
know
anything
else.
So
even
you
can
get
this
even
if
it
were
to
be
an
independent
track
rfc,
and
so
even
if
the
answer
is
no
on
the
adopt
as
a
six-man
working
group
item,
it
doesn't
mean
that
you
can't
get
the
actual
option
and
use
it.
E
A
Okay,
so
dave
you're
right,
there
is
a
different
draft.
That's
called
the
omni
draft,
that's
different
than
this
draft,
and
that
is
a
full
explanation
of
the
omni
interface
and
the
omni
link
and
all
those
those
those
those
aspects.
This
document
is
strictly
looking
for
the
assignment
the
allocation
of
the
option.
A
Now
I
think
one
of
your
other
questions
had
to
do
with
whether
there's
an
rfc
required
for
obtaining
an
ipv6,
neighbor
discovery
option
and
that's
the
purpose
of
publishing
this
document
is
to
if
they
have
an
rfc
number
so
that
we
can
have
an
iana
assignment
of
the
option
number
in
conjunction
with
the
rfc.
E
Yeah,
I
guess
my
point
is
that
you
don't
need
it
to
be
a
six-man
working
group
item
in
order
to
get
a
number.
You
just
need
an
rfc
which
could
even
happen
through
the
independent
stream
through
the
rfc
editor
submission
process.
So
the
question
is
really:
what
is
the
rationale
for
adopting
as
a
six-man
working
group
item
as
opposed
to
independent?
E
But
it
wasn't
documented
in
the
draft
for
this
presentation,
and
so
my
point
is
just
whatever
the
problem
is
that
we're
trying
to
solve.
Then
it
should
either
be
in
the
graph
or
in
a
draft
in
the
same
place,
whether
that's
a
six-man
working
group
draft
or
a
rfc
editor.
You
know
independent
submission
stream
or
whatever
so,
but
it
sounds
like
you're
saying
yes
you're
doing
this,
so
that
you
can
get
a
number
which
I'm
saying
you
could
do
without
having
it
be
adopted
as
a
six-man
working
year
by
them.
A
I
I
understand
your
point
david.
It
had
not
occurred
to
me
and
it's
a
valid
point
and
I
think
I
should
probably
drop
back
and
discuss
with
perhaps
some
of
the
area,
directors
or
chairs
as
to
what's
the
right
way
to
go
or
or
maybe
I
should
just
ask
the
chairs
now-
that
dave
has
brought
up
this
other
possibility.
B
C
So
so
far
we
have
five
raised
hands
out
of
93
participants,
which
is
likely
that
we
would
have
to
take
this
question
to
the
list
anyway,
just
just
and
encourage
people
to
to
read
both
documents
before
we
can
answer
that
question
I
think,
but
yes,
I
I.
C
I
also
think
we
should
well
perhaps
based
on
that
we
should
or
what
happens
with
that,
we
can
discuss
dave's
suggestion
as
well
what
avenues,
what
the
best
avenues
are
depending
on
the
interest
interest
here,
so
we're
up
to
seven
now
this
is
you
know,
exciting.
C
C
Yes,
I
think
we'll
take
that
question
to
the
list
and
continue
discussing
you
know
between
our
80s
and
and
and
and
cheers
fred.
If
that's
okay
with
you
thanks.
B
H
A
H
C
B
C
Okay,
so
I
guess
I'll
jump
into
the
pink
box
take
off
my
chair,
hatch
bob
is
left
the
sole
chair
of
this
one.
This
is
the
a
presentation
of
the
universal
configuration
information
option,
which
is
a
draft
that
I
presented
back
in
itf
104.
C
We
have
gotten
a
new
co-author,
so
tim
winters
have
joined
in
working
on
this
draft,
which
is
greatly
appreciated
I'll
be
presenting.
This
team
is
hopefully
here
to
to
help
me
out.
Apparently
it's
a
little
tight.
C
So
the
problem
this
is
looking
at
is
twofold:
it's
it's
partly
how
we
do
new
options
in
the
working
grief
that
we're
spending
an
inordinate
amount
of
time,
arguing
over
over
relatively
simple
new
configuration
information
options
and
where
we
also
end
up
being,
you
know,
split
halfway
between
the
people
who
you
know,
need
it
and
the
other
people
who
think
you
you
shouldn't,
need
it,
and
so
this
document
proposes
a
a
slightly
different
approach
to
how
you
can
do
configuration
information
options
in
the
india
itf.
C
C
Well,
not
at
the
network
side,
at
least
that's
the
that's
the
idea
yeah.
So
the
technical
idea
here
is
that
the
option
should
use
a
self-describing
option
format
where,
on
the
you
know,
reach
or
network
side.
For
example,
the
operator
just
specifies
new
json
objects.
Those
are
modeled
in
cddl
and
encoded
in
cbore
is
the
proposal.
We
had
some
discussion
on
that
leading
up
to
itf
104
and
that
would
allow
new
options
to
add
to
be
added
without
changes
in
the
router
os
or
in
the
host
os.
C
For
that
matter,
you
could
have
applications
just
subscribing
to
keys
in
the
all
those
objects
that
the
application
is
interested
in
the
process
changes.
The
idea
is
now
that,
since
the
option,
space
is
not
really
a
constrained
resource
anymore,
there
isn't
any
huge
justification
for
the
ietf
to
to
manage
the
number
space
and
somewhat
depending
on
what
the
options
are.
The
the
idea
here-
and
this
is
you
know
why
it
was
experimental
initially
as
well,
was
to
to
see
what
would
happen
if
we
open
this
up
and
allow
the
you
know.
C
As
long
as
you
had
a
cddl
going
in
the
iana
registry,
the
option
was
essentially
implementable,
although
you
could
argue
that
the
semantics
of
it
required
more
more
documentation,
so
they.
So.
C
The
idea
here
is
to
put
in
some
more
text
perhaps
around
what
the
ayanna
registry
it's
it's
expert
review
at
the
moment
of
how
involved
that
could
be,
and
you
know
if
the
expert
could
then
punt
to
the
working
group
if,
if
more
specification
was
required,
so
it's
essentially
making
use
of
the
roofer
advertisement
under
the
hp
v6
as
a
generic
carrier
for
this
this
option,
it's
useful
for
you
know
in
the
ri
case,
it's
it's
certainly
useful
for
one
to
many
communication,
but
you
can
also
use
it
as
you
can,
with
ra
for
one
to
one
either
with
you
know,
unicast
ra
or
if
you're,
on
a
point-to-point
link
and,
as
I
said,
c-board,
would
see
the
dl
of
json
objects.
C
The
the
format
here
is
is
unchanged
from
from
itf
104
revision.
We
obviously
ask
for
type
code
42,
since
this
is
the
universal
answer
to
any
other
option.
C
C
C
D
E
E
Yeah,
so
so,
first
of
all,
I
want
to
say
I
really
like
this
idea
of
the
universal
option
of
something
that
can
be
encoded,
the
same
blob
in
dhcp
and
ra,
and
so
overall,
I
am
in
favor
of
this
approach.
I
don't
know
if
that's
a
that's
a
contentious
point,
but
I
just
want
to
add
support
for
this.
However,
the
way
that
it's
being
done
since,
as
you
point
out
that
there's
issues
with
you
know
length
you
can
only
encode
so
much
stuff.
E
The
choice
of
json
rather
than
native
c-bor
seems
questionable
to
me
so
like
on
the
previous
slide.
If
you
go
back
one,
you
see
that
the
rdnss
you
can
see
the
ipv6
addresses
are
encoded
in
text
format.
You
see
the
labels,
rdnss
is
text,
format
go
forward,
one
slide
in
the
cddl
right.
Normally
the
labels
in
the
map-
right,
you
know,
pvd,
colon,
dns,
colon
and
so
on
in
sibor.
Normally
those
would
be
nice
short
integers
as
opposed
to
big
long
strings,
and
so
using
a
json
and
t
stirs
for
things
like
you
can
see.
E
C
So
so
this
is,
you
know,
I'm
not
the
expert
on
this.
You
know
I've
been
speaking
to
carson
a
bit.
Am
I
writing
that
you
could
very
well
specify
this
cddl
with
with
you
know
the
ip6
address
and
prefix
tags
and
still
have
a
json
representation.
It
would
still
be
easy
for
a
json.
You
know
implementation
to
map
from
a
json
object
into
a
that
cbo
representation.
As
long
as
the
cdl
specified.
The
the
address
tags
is
that
you
agree
with
that.
E
So
you're
taking
an
approach,
it's
very
similar
to
what
one
of
the
other
working
groups
that
I
participate
in
did
where
they
were
designing
a
protocol
and
they
wanted
to
allow
originally
used
both
json
and
cbor
kind
of
your
choice
and
past.
You
know
like
a
media
type
or
something,
because
this
wasn't
an
ipv6
option.
It
wasn't
that
low
level
and
eventually
the
working
group
concluded
that
let's
just
delete
all
the
json
stuff,
because
it's
actually
much
more
cumbersome
to
use
compared
to
just
using
c
or
by
cumbersome.
E
I
just
mean
bloated
right
and
I
don't
think
it
provides
you
any
value
other
than
readability,
and
I
don't
know
that
readability
is
actually
important
for
an
nd
option,
since
none
of
the
other
ones
are
text
based
and
so
in
the
in
the
maps
here
right.
The
seabora
map
is
basically
a
tuple
of
two
tlv
encoded
things,
and
so
the
thing
to
the
left
of
the
colon
is
one
value,
and
the
thing
to
the
right
of
the
colon
is
another
value.
So
it's
basically
like
an
array
of
size.
E
Two
where
you
have
something
the
left
sum
to
the
right.
So
you
can
put
a
string
on
the
left,
okay,
as
so
that
the
keys
of
your
map
could
be
a
string,
but
normal
c
bar
stuff
tends
to
put
integers
there,
which
is
more
compact
and
so
they're
both
unique
and
you
need
a
registry
for
them
in
iana,
either
way
so
that
you
don't
have
collisions,
and
so
all
I'm
saying
is,
I
don't
see
the
value
in
using
json
as
the
native
object
format.
E
If
you
just
specified
it
with
steep
or
it
would
be
more,
both
more
compact,
hence
more
widely
applicable,
meaning.
You
could
pack
more
stuff
into
the
same
nd
message
and
I
don't
think
the
json
buys
you
anything
so
anything
like
that's
just
me
arguing
that
you
should
delete
the
json
stuff,
but
otherwise
I
love
it
and
the
cddo
here
looks
fine.
It's
just
you're
you're
the
left
side
of
the
colon
you'd
assign
integer
values
to
and
those
would
be
integers
and
a
registry.
You
define.
C
E
J
Okay,
good
first
time
it
didn't
work
for
some
reason.
I
really
wanted
to
say
plus
one
today,
but
this
is
more
or
less
what
we've
done
and
grasped
in
the
animal
working
group-
and
you
know
there
is
nothing
you
can't
you
can't
do
because
of
restricting
yourself
to
sibo,
and
if
someone
really
wants
to
do
json,
they
basically
just
stuff
the
json
into
seymour
and
it
arrives
at
the
other
end
in
good
shape.
So
it
really,
it
really
is
more
powerful
to
say
sibo.
C
C
I
I
also
just
wanted
to
say
that
I
definitely
prefer
the
straight
sea
ball
option
rather
than
the
json
not
really
a
fan
of
having
to
process
strings,
etc
and
the
bloat
that
they
bring
so
yeah.
I'd
also
just
want
to
second
that,
okay.
C
Good
sounds
like
we
have
a
clear
task,
then
of
fixing
that
okay,
so
let
me
I
see
brian
you're
back
in
no,
you
get
a
cue,
is
done
and
see
how,
if
it
times
out
so
the
suggestion
is
to
have
a
new
iano
registry,
then
for
the
cr
option
we
have
the
cddl
going
directly
in
the
registry.
C
So
you
could
you
know
for
simple
options.
You
could
just
have
the
iana
registry
without
any
further.
You
know
rfc
or
any
itf
work
done,
and
this
should
have
expert
review
and
I
think
the
expert
should
have
the
option.
We
should
write
some
guidance
text.
I
think
for
the
expert
review
where
he
could
or
she
could
punt
to
the
working
group
or
to
the
itf
to
decide
that
an
idf
document
would
be
required
for
a
particular
option,
depending
on
the
semantics
of
the
option.
C
C
K
G
I
don't
really
see
a
lot
of
value
in
this
proposal
in
the
sense
that
I
think
options
are
mostly
useful
to
convey
semantics,
and
this
doesn't
really
give
you
any
semantics.
You
you.
It
basically
has
like
a
a
human
readable
description.
It
it
like
clearly
defines
the
syntax,
but
it
doesn't
say
what
the
option
means.
It
doesn't
say
what
somebody
what
some
implementation
should
do
if
it
receives
one
of
these,
it
doesn't
say
how
the
necessarily
even
how
the
fields
are
defined
like.
G
G
So
at
that
point,
I'm
not
sure
what
the
use
is
of
defining
a
a
common
format,
because
I
don't
think
that
that's
a
big
part
of
the
work
in
defining
a
new
option
and
we
think
if
you
look
at
the
prep
64
option
and
yeah,
we,
there
happened
to
be
some
bike
shedding
over.
Like
you
know
what
fields
we're
going
to
go
where,
but
I
think
we
would
have
had
that
anyway.
G
I
don't
think
it's
true
that
in
order
to
in
order
to
get
this
past
the
kernel
you
need,
I,
I
don't
think
it's
true
that
this
makes
it
easier
to
make
it
to
get
this
past
the
kernel
there
are
ways
of
doing
this.
Today
I
mean
linux
has
the
nd
options
or,
and
the
user
up
to
our
dnss
facility,
where
you
can
pass
up
arbitrary
options,
and
I
also
you
know
the
first
time
we
defined
some
of
these.
G
C
So
lorenzo
how
many
implementations
do
you
have
a
pref64
in
in
router
operating
systems.
G
C
I
I
think,
that's
what
you
know.
One
of
the
purposes
here
is
is
to
avoid
that
problem.
Right,
like
we
had
with
especially
the
dns
option,
for
example,
where
it
took
many
many
years
before
you
had
had
support
in
the
network
devices,
at
least
in
this
scheme.
The
idea
is
to
do
that
once
on
the
on
the
router
os
side
and
and
then
even,
but
even
there.
G
C
Well,
the
difference
is
yes,
you
could
certainly
have
a
way
of
passing
opaque,
opaque
tlvs,
but
this
allows
you
you
know
with
the
key
space
it
allows
you
to.
You
know
to
subscribe
to
the
messages,
if
you're
an
application,
for
example-
and
you
could
also
as
an
application
just
state
that
please,
mr
network,
send
me
this
set
of
configuration
information
and
it
would
purely
be
a
an
action
between
the
network
operator
and
the
application.
L
L
So
I'm
a
bit
surprised
to
hear
there
is
no
ietf
document
required
because
I
think
this
part
needs
to
be
specified
somewhere.
Otherwise
I
cannot
reliably
use
it
in
the
network
if
every
operating
system
gonna
do
something
different
with
the
option.
I
said,
however,
I
like
the
idea
of
being
able
to
specify
some
random
thing
on
my
router,
without
waiting
for
the
new
version
really
yeah.
So
I
I
I
think
it's
a
good
idea
right,
so
I
fully
support
the
idea
of
the
universal
option
format.
L
I
just
still
think
we
need
to
make
sure
we
are
on
the
same
page
about
what
it
means
for
every
participant
and
yes,
we
do
have
at
least
one
text
for
implementation
on
the
router.
C
M
Can
you
hear
me
okay
cool,
so
I
have
a
question.
So
if
I
got
the
your
your
description
right
about
the
option
is
that
the
main
goal
is
to
reduce
the
overhead
that
they
do
essentially
specify
new
options.
Is
that
correct?
M
Yes,
part
of
it?
Yes,
okay,
so
if
that
is
the
case,
so
my
question
would
be
if
your
assessment
would
be
that
the
main
overhead
is
in
you
know,
essentially
the
working
group
specifying
the
syntax,
in
which
case
I
would
agree
that
this
would
make
a
difference
or
whether
the
main
overhead
is
in
specifying
the
semantics,
in
which
case
it
wouldn't
so
that'll.
Be
it's
a
question,
not
a
statement.
M
M
Then
essentially,
I
wonder
you
know
what
would
implementations
referred
to
when
you
know
trying
to
specify
this
when
trying
to
implement
a
specific
option?
Okay,
so
there's
a
way
for
them
already.
M
If
you
know
this,
is
you
know
if
this
document
is
adopted
and
published,
there
will
be
a
way
for
them
to
specify
the
syntax
of
new
options,
but
still
in
order
to
be
able
to
do
something
useful,
they
should
be
able
to
agree
on
the
semantics
and
if
there's
no
document
that
specifies
the
semantics
for
the
option
then
well,
we
have
a
you
know
an
inter.
We
would
be
having
an
interoperability
problem.
C
I
think
I
had
yes,
I
think
I
made
that
that
point
as
well
that
that's
a
very
well
made
point
fernando
and
okay,
and
that
that
is
why
you
know
we.
We
started
out
with
this
as
experimental,
because
we
are
you
know
what
is
the
consequence
of
the
idf.
You
know
letting
go
if
you
like
here
and-
and
you
know
in
the
sense,
moving
power
from
from
the
itf
to
implementers
in
a
sense,
but
I
was
also
suggesting
to
put
in
a
safety
valve
that
the
you
know,
expert
reviewer.
C
Could
you
could
say
you
know
how
the
semantics
here
needs
to
be
specified.
This
is
so
complex
that
that
you
need
an
rc
document
to
get
a
code
point
here.
So
so
you
know
I
don't
know
I.
I
certainly
share
the
same
same
view
as
as
you
and
sort
of
you
know
this
came
out
of
you
know
the
ipv6
only
debates
we
had
where
we
spent
you
know
two
years
debating
a
single
bit
or
a
single
flag
and
what
it
was
supposed
to
mean,
and
I'm
not
sure
right.
C
C
M
So
let's
say
my
concern
is
that
you
know
essentially,
besides
the
syntax,
the
you
know,
implementations
need
to
agree
on
what
they
are
doing
with
the
option.
So
you
know
part
of
my
question
is:
if
there's
not
going
to
be
a
document,
because
you
know,
let's
say:
implementations
are
relieved
from
that,
because
they
can
already
specify
the
option
where
they
would
still
need
to
point
somewhere.
Would
that
be
like
you
know,
I
don't
know
vendor
website
an
open
source
implementation.
M
Still
I
mean,
even
if
it
looks
to
me
that
somehow
you
know
the
document
we'd
still
need
a
document.
It's
it
just
would
be
elsewhere,
whether
that's
a
website,
a
wiki
something,
but
you
know
still,
if
you
know,
if
we
want
interoperability
well,
a
document
is
going
to
be
needed.
C
So
so
I
think
it
depends
right
in
some
cases,
and-
and
certainly
you
know-
we
I
certainly
are-
is
not
all
the
opinion
that
we
should
not
have
a
document
you
can
have.
You
know
and
there
should
be
some
stable
reference
and
it
might
be
a
document
that
exists
already
or
or
it
might
be
obvious
right.
If
you
you
know,
the
option
is
here's
here's
the
address
of
the
encrypted
dns
resolver,
then?
Presumably
there
are
other
documents.
You
could
reference
that
you
would
need
this
specific
one
for
this
option,
for
example,
but
but
yeah.
B
Okay,
so
we're
a
bit
over
time.
So,
let's
with
two
people
in
the
queue
dave
thaler
and
michael
dave,.
E
So
while
I've
been
waiting
in
the
queue,
I
have
now
three
comments
and
so
two
responses,
and
then
one
suggestion,
lorenzo's
points
about
you
know
not
having
a
seabor,
parser
and
so
on.
Mirror
is
a
bunch
of
the
discussion
we
were
having
in.
I
think
the
suit
working
group
for
that
one
where
I
was
eventually
convinced
two
things:
seaward
parsers
are
really
small,
because
they're
meant
for
even
applicability
to
tiny
constrained
devices
and
there's
open
source
ones
out
there.
E
So
that's
quite
easy,
but
the
other
point
was:
if
you
have
a
structure
that
you're
encoding.
That's
simple
enough
like
there's,
not
a
bunch
of
optional
things,
it's
just
so
the
optional
ones.
Are
those
question
mark
colons.
You
can
actually
parse
it
with
just
a
regular
typedesk
struct
right,
because
it's
just
a
binary
thing,
and
so
it's
actually
flexible
enough,
depending
on
how
you
define
what
option
you're
going
to
put
in
there
so
anyway,
other
working
groups
have
decided
that
that
actually
wasn't
a
problem
either
that
they
could
grab
a
keyboard
parser.
E
That's
only
you
know
a
very
tiny
number
of
lines
of
code,
and
so
on
other
comment.
That
was
a
response
before
I
get
to
my
suggestion
is,
I
think,
the
main
overhead
that
we've
seen
in
the
ietf
at
least,
that
I've
seen
the
ietf
ola
had
on
one
of
the
first
slides,
which
is
people
arguing
about
whether
the
something
belongs
in
an
ra
option
or
a
dhcp
option
or
both
and
every
working
group
gets
into
that
debate.
We
said,
oh,
no,
not
this
again.
E
So
don't
underestimate
that
and
then
in
many
cases
the
duplication
of
specifying
both
as
twice
the
work
of
specifying
one,
and
so
I
think
ola
is
at
least
cutting
the
work,
la
and
tim,
or
at
least
cutting
the
work
in
half
and
probably
much
more
than
half,
but
it
doesn't
make
the
need
for
a
spec
go
away
and
that's
what
my
last
comment
goes
to
you
on
expert
review.
E
So
I'm
going
to
make
a
suggestion,
but
on
expert
review
I
happen
to
be
the
expert
for
the
iftype
registry,
which
is
listed
as
as
expert
review
and
one
of
the
requirements
for
the
expert
review,
and
that
one
is
when
you
submit
the
expert,
you
need
a
pointer
to
a
spec.
It
doesn't
have
to
be
a
spec,
that's
actually
public,
and
so,
if
you
have
a
spec,
that's
you
know
a
private
spec
as
long
as
you're
willing
to
share
it
with
the
expert
you
can
get
the
number.
So
now.
E
Let
me
get
to
what
my
specific
suggestion
is.
Once
you
convert
to
cbor
and
use
integers
for
the
keys.
Okay
integers
that
are
smaller,
numbers
are
encoded
in
fewer
bytes,
okay.
So
what
I'm
going
to
suggest
is,
if
you
say,
let's
use,
say
ietf
consensus
to
get
any
number
that
it
can
be
can
be
represented
in
two
bytes
and
expert
review,
with
a
specification
needed
for
anything
larger
than
two
bytes.
Okay.
E
That
means
there's
an
incentive
to
get
ietf
consensus
to
get
the
efficient
encoding,
but
it
doesn't
stop
you
from
from
doing
your
own
thing
if
you
want
to
with
a
high
enough
number
as
long
as
you
go
through,
so
we've
got
other
cases
where
you
have
two
different.
You
know
the
low
spin
numbers
and
the
high
numbers
have
different
reviews,
and
so
my
suggestion
is
ietf
consensus
or
expert
review
with
a
spec
for
those
two
cases,
but
in
either
cases
you
need
a
spec,
it's
just
another
one.
E
B
N
N
Hi
is
it
working,
so
I
want
to
echo
everything
dave
said
said
it
better
than
me,
but
I
also
want
to
suggest
that
the
the
and
the
some
of
the
discussion
between
jen
and
lorenzo
in
the
chat,
the
the
real
big
problem,
I
think
for
actually
figuring
out
what
the
semantics
are
of
the
thing
is
actually
letting
people
to
build
some
running
code
and-
and
we
continuously
get
into
this
thing.
N
Well,
we
we've
implemented
some
new
ra
option,
but
it's
not
going
to
get
out
there
be
usable
until
you
know
five
years
of
of
of
revisions
of
routers,
and
so
I
think
that
this
this
lets
people
do
some
experiments
easily
and
figure
out.
This
is
useful.
This
is
stupid
and
come
back
in
so
this
really
puts
it
into
someone
who
has
a
a
client
implementation,
a
host
implementation
that
says.
N
Okay,
I
want
to
try
this
thing
out,
I'm
going
to
get
a
number
and
that's
why
expert
review
is
appropriate
and
not
spec
required,
and
I
totally
think
yeah
three
bytes
a
three
byte
number
is
perfectly
fine
for
this
kind
of
effort
and
to
say
figure
it
out
and
go
well
that
actually
wasn't
very
useful.
N
I
did
this
and
this
and
this-
and
this
wasn't
very
useful,
but
maybe
this
other
thing
will
be
better
and
if
we
can
get
that
down
to
you
know
one
month
instead
of
two
years,
then
I
think
that's
a
really
useful
thing
and
that's
why.
I
really
think
this
is
a
useful
process,
even
if,
in
the
end
we
actually
go
and
re-encode
the
the
semantics
in
the
traditional
tlv
format,
the
the
result
of
the
experiment
will
will
be
very
useful.
Even
if
we
wind
up
doing
that
thanks.
C
So
bob
I
have
a
question
if
we
should,
if
the
working
group
would
like
to
adopt
this,
but
this
is
without
my
chair
hat
on.
So
it's
up
to
you.
If,
if
you
think
there's
enough
people
to.
B
Also,
the
the
poll
for
reading
the
draft,
there's
16
said
they
have
three.
B
They
said
they
had
not
and
then
out
of
a
total
of
93
people
so
better
than
the
last
draft,
I'm
I
I
think
I
think
this
is
very
interesting
work,
I'm
not
quite
sure
we're
ready
to
do
the
adoption
call-
or
at
least
here
my
take
is
that
I
sort
of
wonder
if
you
and
we
end
up
doing
specification
required,
then
I'm
not
so
sure
that
the
the
encodings
here
make
are
needed,
because
I
think
the
idea
of
the
encoding
system
to
try
to
not
have
a
spec.
B
B
B
O
I
am
asking
here
evident
for
adoption,
but
I
am
asking
for
adoption
of
the
problem,
not
the
solution,
because
in
solution
definitely
we
have
some
number
of
trade-offs,
for
example,
even
internally
between
bank.
We
have
some
some
disputes
where
to
stop,
because
currently,
what
is
proposed
is
conversion
of
the
really
big
hole
for
me
in
the
middle
attack
to
denial
of
service,
and
my
partner
shepard
was
not
satisfied
at
all
about
this.
He
said.
O
O
Okay,
what
we
have
here
is
a
problem.
The
problem
is
very
is
very
simple
to
for
intruder,
because
what
is
the
essence
of
the
problem
that
even
in
the
basic
navy
discovery
protocol,
if
a
router
will
ask
everybody
who
is
who
has
particular
mac
address
particular
lla
link,
local
address,
who
has
particular
mac
address
for
particular
ap
address.
Of
course,
the
right
host
will
have
legal
cost
will
answer,
but
additionally,
intelligent
questions
were
just
after
and
because
unsolicited.
O
Unsolicited
answer,
unsolicited
message
could
have
raised
bids
for
solicited
bids
override
beats.
He
could
he
could
easily
achieve
the
right
cash
for
for
for
router
and
and
the
router
after
this
we'll
send,
as
presented
here
on
the
on
the
bottom
of
the
slide.
The
router
after
this
will
send
traffic
basic
traffic
in
in
upstream
direction
from
the
legal
victim,
but
in
opposite
direction.
O
The
traffic
will
go
through
intruder
and,
additionally,
to
this,
if
anybody
from
outside
of
this
link
will
ask
connectivity
to
this
particular
ap
address,
this
particular
address
would
be
sent
to
intruder.
It's
a
classical
mean
in
the
middle
man.
In
the
middle
attack,
especially
for
from
outside
from
outside,
is
fully
two-way.
Men
in
the
middle
from
inside
is
one
way,
but
because
dumbling
could
have
done
downstream
could
have
hd
could
have
some
dns
requests,
for
example,
and
dns
request
would
be
fake
and
then
it
would
become
two-way,
mainly
in
the
middle
attack.
O
In
reality,
this
particular
problem
has
one
mitigation.
We
have
the
standard
for
so-called
sorry
source
address,
validation,
and
so
so
there
is.
Validation
does
mitigate
this
because
on
the
switch
on
the
layer
to
device
savvy,
snoop,
all
nd
messages
and-
and
if
sally
is
in
question
about
who
is
the
right
owner,
so
he
could
send
a
nato
solicitation
and
to
to
clarify
which
one
particular,
which
one
particular
ordinary
is
right
order.
O
Maybe
I
need
to
mention
here
that
this
particular
problem
is
only
about
an
snr
neighbor
solicitation
neighbor
advertisement
is
not
a
problem
at
all.
For
perez,
I
mean
for
rsr.
I
do
not
have
here
any
any
discussion,
because
we
still
don't
understand
what
would
be
done
better
in
addition
to
agar
regard
plus
this.
This
couple
of
standards
is
still
assumed
here,
as
a
pre-request
therefore
help
from
switch
steel
needed
for
our
protection
arrest.
Protection
here
is
a
discussion
only
about
ns.
O
The
previous
slide
was
easy
for
intruder,
but
if
we'll
block
the
previous,
the
previous
problem
by
by
some
means-
and
we
have
discovered
it
during
this
particular
development-
that
okay-
we
could
block
the
previous
problem,
then
additionally,
we
could
find
some
additional
corner
cases,
which
is
more
difficult
for
intruder,
but
even
more
difficult
for
for
us
to
protect
for
standard
or
for
for
developer
to
protect
the
first
one
on
the
left
is
the
the
situation
which
is
not
protected
even
by
by
saudi
architecture.
O
Is
the
situation
that,
for
some
legal
reason
the
victim
could
be
reloaded,
it
could
be,
it
could
be
absent
effectively.
It
could
be
absent,
for
example,
hardware
upgrade
of
the
server,
or
maybe
software
upgrade
and
reload.
After
this
it
could
be
that
the
the
legal
survey
is
absent
and
then,
at
that
time,
a
couple
of
couple
of
minutes,
for
example,
at
that
time,
into
the
could
claim
his
ap
address
and
because,
at
that
time,
intruder
is
only
one
who
claimed
this
particular
ip
to
mark
binding.
O
Of
course,
definitely
he
will
pass
any
any
check,
doesn't
matter
what
check
he
will
do
at
that
time.
It
will
pass
inside
architecture
too
inside
architecture,
it's
the
same
problem
and
then
after
the
server
will
be
loaded.
The
intruder
should
just
not
respond
to
that
to
to
that
message
and
then
effectively
will
be
capable
to
claim
his
ap
address
from
the
route,
and
we
will
have
exactly
the
same
situation.
O
One
way
traffic
will
go
from
legal
horse
to
route
to
router
and
the
the
downstream
traffic
will
go
from
from
route
through
intruder
and
it's
again
exactly
the
same
situation,
exactly
the
same
situation
for
traffic
inside
the
link
and
inside
the
same
situation
for
traffic
from
outside.
It's
again,
mainly
in
the
need
to
attack
it's
it's
one
problem
and
here
his
analysis
that
it
doesn't
matter,
is
it
grant
enable
it
or
not
grant
enabled?
O
Because
if
it's,
you
have
plenty
of
time
for
a
couple
of
minutes
after
after
server
go
to
reload
with
a
couple
of
minutes,
and
it
doesn't
matter
the
second
in
the
middle
problem,
which
is
even
more
difficult
for
each
other,
but
even
more
difficult
to
block
it's
a
situation,
then
intruder
will
not
try
to
do
anything.
O
Bad
up
to
intruder
will
see
the
dub
message
after
intruder
will
see
that
that
message
he
will
have
a
transmit
timer
one
second,
one,
second,
to
persuade
router
that
he
is
the
legal
owner
of
this
particular
apis
and
okay,
if
it
is
possible
a
little
bit
different
situation
for
grant
and
non-grand
environment.
But
it's
not
a
big
change.
O
It's
exactly
the
same,
because
one
second
is
big
enough:
even
for
to
send
just
normal
legal
traffic
and
to
have
traffic
in
return
and
traffic
and
return
will
activate
router
to
ask
who
is
the
legal
owner
and
intruder
could
ask
yes
me
and
the
citizens
again
in
in
current
proposition.
We
block
all
of
this
to
block
not
just
previous
one,
which
is
easy
to
block,
but
even
these
two
things
we
do
block
and
please
go
to
the
next
slide.
We
will
discuss
how
to
look.
B
By
the
way,
I
did
start
another
hand
raised
thing
for
if
people
have
read
the
draft
okay.
O
The
proposition
current
proposition
is
very
simple.
In
reality,
any
change
of
mac
address
in
the
neighbor
cache
doesn't
matter.
Is
it
initial
right
or
maybe
rev
right
after
somebody
will
send
you
unsolicited
neighbor
advertisement
or
soliciting
neighborhood
builders?
Any
change
of
mark
of
alola
should
be
only
as
a
result
of
multicast
request,
because
we
should
give
the
capability
for
legal
cost
to
respond
and
for
us
for
for
router
to
see
the
duplicity.
O
If
it's
duplicate
or
not,
if
this
particular
link
is
normal
link,
where
only
one
ap
address
is
permitted
for
for
one
one
host
or
one
relationship
to
ap
to
mark
one,
then
we
expected
only
one.
Only
one
response
will
be
on
our
alien
neighbor
solicitation.
Only
one
neighbor
advertisement
response.
If
it
would
be
two
responses,
then
we
will
off.
O
Bit
additional
discussion
that
to
block
the
last
one
problem
which
we
have
discussed
in
the
previous
slide,
the
new
host
after
it
will
start
after.
It
will
finish
that
solicitation
after
this,
the
host
should
send
nabel
announcement
about
he
should
he
should
reveal
himself
it's
effectively
grant,
but
granting
more
strong
form,
because
the
override
bit
should
be
set.
O
It's
a
little
bit
a
little
bit
more
complex
than
on
this
slide,
but
but
not
much
what
it
is
it
gives
for
majority
of
cases,
no
need
for
change
of
host
it.
It's
more
or
less
simple.
I
I
show
later
next
slide
about
details
of
implementation
is
more
or
less
some
simple
improvement
for
engineering,
but
not
very
complex.
O
We
don't
need
for
this
nsnr
any
help
from
switch,
no,
no
need
for
savvy
architecture,
which
does
not
help
against
the
last
couple
of
problems.
Anyway.
We
have
support
here
for
any
cast
by
the
way
that
there
is
some
counter
which
could
be
programmed
in
advance
and
some
configuration
counter.
And
if
this
is
this
link,
where
we
have
any
cast,
then
we
do
expect
more
than
one
response
to
our
ns.
More
than
more
than
one
and
a
will
come
to
us,
it's
has
a
little
bit
more
multicast,
but
not
much.
O
In
majority
of
cases,
additional
multicast
would
be
zero
because
in
maturity
of
cases,
an
s
and
r
response
would
be
reused
to
check
that.
It's
really
only
one
response
receipt
here
in
in
the
grant
environment.
If
we
have
one
router,
for
example,
there
is
analysis
in
the
draft,
then,
would
be
33
percentage
of
additional
multicast
and
if
it
many
many
routers,
then
up
to
50
percentage
of
additional
multicast.
It
could
be
the
situation.
It's
a
deep
analysis
inside
the
drug.
O
O
I
don't
have
intention
to
deep
dive
in
details
here,
of
course,
if
you
like,
I
could
but
the
improvement
for
state
machine
insight.
Int
protocol
is
very
simple.
When
you
send
neighbor
solicitation
from
from
your
host
or
from
the
router,
you
should
effectively
activate
a
couple
of
things.
You
should
activate
timer
wait
for
you
to
later
to
understand
which
one
response
is
inside
the
timer,
which
was
one
responses,
really
responds
to
your
ms,
and
which
one
is
not
response
to
uns.
O
You
should
activate
the
timer
and
you
should
activate
initialized
counter
here,
because
it
could
be
the
link
which
has
any
cost,
and
then
you
do
expect
more
than
one
response
a
little
bit
complexity,
not
much,
but
a
little
bit
additional
complexity
on
the
receive
side.
When
you
receive
an
a
on
router
on
host,
then
you
should
check
first.
Is
it
response
to
your
ns
or
is
it
inside
the
timer
or
is
it
unsolicited
and
it
is
a
little
bit
different.
Behavior
is
a
listing,
announcer?
Isn't
it?
O
The
algorithm
is
here
on
this
light
and
more
details
inside
there
inside
the
draft
tip.
Probably,
except
maybe
I
need
to
tell
what
was
the
reaction
to
this.
I
have
a
couple
of
comments
which
is
about
implementation,
which
I
definitely
should
follow
yeah.
I
have
a
comment,
for
example,
that
I
need
to
tell
more
in
the
draft
about
science
architecture,
because
currently
right
in
the
draft,
there
is
only
story
that
this
particular
implementation
does
not
create
a
problem
for
psych
architecture.
O
O
The
biggest
concern
was
from
a
couple
of
people
from
philippines,
from
fernando
their
primary
concern
was
about
the
problem
itself
because
they
have
assumed
effectively.
They
both
assumed,
as
I
understand
the
same,
they
have
assumed
that,
because
we
need,
we
still
need
to
this,
the
helpful
switch.
We
still
need
the
help
from
player
2,
at
least
for
a
guard,
at
least
for
filtering
of
router
messages.
There
are
burnt
messages,
but
and
because
we
need
the
help
from
player,
2
does
not
make
sense
to
solve
anything.
O
It
was
a
message
that
any
security
problem
of
an
sni
is
a
is
a
problem
for
layer,
2
device
for
device
which
is
below
ip.
It's
questionable.
From
my
point
of
view,
I
don't
accept
this
particular
comment
because
we
still
have
currently
the
problem.
We
still
have
very
easy
attack
vector
for
an
snr.
We
could
really
conjure.
We
could
not
conjugate,
probably
the
current
session,
because
current
session
would
be
encrypted
in
major
cases,
but
we
could
be
inserted
in
the
middle
when,
in
the
middle
and
after
this
we
could
collect
all
credentials.
O
We
could
change
dns
responses,
it's
it's
really
big
big
leakage
of
information
right
now
which
is
really
open
and
because
it's,
if
you
will
have
a
solution,
some
other
solution.
Okay,
if
it's
fine,
then
I
would
be
silent,
but
the
problem
that
you
don't
have
a
solution.
Currently,
it's
a
big
big
leakage
of
information
which
is
open.
L
I
have
a
clarifying
question
and
I
have
a
concern
so
actually
I
have
a
concern:
let's
go
straight
away
until
this
day,
the
all
work
of
neighbor
discovery.
L
L
Now
you
basically
say:
okay,
as
long
as
you
have
duplicated
addresses,
does
it
matter
if
it's
attack
or
not,
let's
break
everything,
let's
break
all
participants
and
deal
with
that,
and
my
concern
here
is
also
that
I
do
not
care
about
all
this
application
layer,
like
men
and
the
mizzle
attacks,
because
each
protocol
should
deal
with
it
on
the
higher
level
for
dns.
We
have
dns
stack
right.
We
have
encryption
on
the
for
play,
I
would
not
be.
L
I
wouldn't
try
solve
it
better
than
the
middle
attack
or
the
neighbor
discovery
problem,
because
when
you
send
your
traffic
to
the
internet,
you
never
know
if
it's
actually
going
to
the
intelligent
destination.
Unless
you
use
some
formal
authentication,
so
I
don't
think
it's
worth
solving
on
neighbor
discovery
level
and
what
you're
doing
here
you're
replacing
potential
when
you
do
the
middle
attack
with
ddos
attack
right
now.
With
that
thing,
I
can
easily
disrupt
any
already
accurate
holes
in
the
network
segment
by
saving
another
neighbor
advertisement
right
and
putting
that
host.
L
O
Not
exactly
like
you
said
not
exactly
this
way,
because
the
problem
for
duplicated
ip
addresses
could
happen
only
if
you
will
have
a
real
intruder
in
in
the
in
the
subnet.
They
even
do
that.
I
mean
if
it
would
be
just
that
the
dot
will
never
send
your
flux
and
is
it
at
all
the
flag,
then
the
normal
cost,
even
after
collision,
will
never
try
to
to
install
poisoned
cash
on
your
router.
O
L
I
totally
disagree
because
you
look
like
look
at
that,
like
all
rfc
is
about
duplicate,
address,
detection,
optimistic
that
we
need
to
work
in
the
assumption
that
you,
for
example,
can
have
hosts
using
ui
64
based
interface
id,
and
you
might
have
people.
I
don't
know,
duplicated
with
duplicated
mac
addresses
so
manually.
Creating
ipv6
addresses
on
the
interfaces
which
can
lead
to
duplicated
I've.
Seen
that
in
the
real
life
right,
you
cannot
guarantee
that
you
would
never
see
two
legitimate
hosts.
O
Again
again,
you
misunderstood:
no,
it's
not
because
it's
not
because
duplication
could
not
happen.
Duplication
could
happen
is
no
problem,
because
in
in
the
duplication,
if
duplication
will
happen,
nobody
will
try
to
rewrite
the
cache
on
the
router.
Nobody
will
try
to
raise
the
flag
to
raise
the
flag
of
override
of
solicited.
Nobody
will
behave
like
the
intruder.
Therefore,
duplication
will
not
activate
this
particular
mechanism.
O
B
C
B
C
B
Q
Hey
guys,
so
I
kind
of
agree
with
jen,
but
only
kind
of
so
I
do
think
that
this
is
definitely
a
problem
that
should
be
well
there's
a
lot
of
echo
going
on.
So
this
definitely
is
a
problem
that
needs
to
be
solved,
but
I
kind
of
wonder
if
this
is
the
right
approach.
Q
A
different
approach
might
be
that
the
whoever
held
the
address
the
oldest,
holds
the
address,
and
then
the
router
will
perform,
or
not
just
the
router,
but
every
other
node
will
basically
perform
validation.
This
was
actually
something
that
we
proposed
as
part
of
the
6nd
problem
statement
that
we
put
out
a
couple
years
ago.
R
Hi
you
go
just
quickly.
I
would
I
see
where
jen
is
coming
from,
and
I
agree
that
in
my
data
center
I
may
actually
be
worried
about
duplicated
addresses,
causing
any
sort
of
disruption
to
anybody.
R
Basically
men
in
the
middle
unsecure,
unfortunately
still
unsecure
dns
responses
to
my
laptop
about,
like
where
bank
of
america
is,
and
so
I
can
see
it
in
two
different
environments,
actually
having
very
different
preference
for
availability
versus
security
pressure.
That's
my
entire
comment.
M
M
So
if
you
mitigate
one
specific
vendor
better,
but
you
still
leave
so
many
others
to
do
exactly
the
same
thing,
the
article
will
essentially
employ
whatever
works
and
in
nd,
if
you
want
to
mitigate
all
of
them.
Unfortunately,
you
need
to
rely
on
stuff,
like
said,
because
you
trust
the
nd
messages.
After
all,.
B
B
S
Can
you
hear
me
now
we
can
hear
you
now
go
ahead,
excellent!
Okay,
some
reason
didn't
work
right
away,
so
this
draft
is
about
the
use
of
least
common
scope
during
communication,
and
it's
going
to
focus
on
only
in
communication,
alexander
and
maverick
only
together
next
slide.
Please.
S
What
we're
seeing
here
on
this
diagram
is
that
there
are
hosts
different
parts
of
the
network
and
we
are
going
to
focus
on
the
holes
that
are
on
the
same
local
link
like
in
the
bottom
right
corner,
where
we
have
host
h,
b
and
h
d,
and
there
might
be
a
need
by
applications
to
communicate
on
the
local
link
using
link
local
rather
than
global,
address
and
mitigate
attacks
through
the
sockets
if
they
open
sockets
using
global
addresses.
S
So
in
most
of
the
cases,
as
far
as
I
know,
communication
is
done
using
new
global
addresses,
and
this
draft
is
going
to
propose
a
solution
where
applications
on
the
local
link
can
decide
to
use
link
local
addresses.
Instead,
even
though
applications
are
not
aware
of
link
local
addresses
in
some
cases
or
in
many
of
the
cases
next,
likewise.
S
The
least
common
scope
addresses
are
preferred
during
the
destination
of
this
election,
but
socket
api
can
be
given
only
global
address
or
or
list
of
global
and
ula
addresses,
and
there
is
no
way
to
use
this
precedence
if
link
local
others
is
not
present
in.
In
those
cases,
applications
would
use
global
addresses
and
for
for
sockets
and
open
a
socket
to
listen
on
global
others
and
expose
themselves
himself
to
the
tax
potential
attacks
next
slide.
Please.
S
S
So
what
is
link
local
address
resolution,
so
it's
practically
an
extension
to
address
resolution
where
a
host
needs
to
obtain
mac
address
of
the
destination
given
global
ip
address.
In
this
case,
we
propose
that
neighbor
solicitation
message
can
use
extra
link
local
bit.
We
call
it,
albeit
to
indicate
that
it's
requesting
a
link
local
address
from
the
destination
and
it
will
send
neighbor
solicitation
with
the
target
address
as
global
address
global
destination
address
and
source
address
is
going
to
be
link
local
address.
S
S
So
here
is
the
proposed,
albeit-
and
we
want
to
use
this
l
bit
to
indicate
that
a
source
wants
to
obtain
link
local
address
because
through
this
mechanism,
because
it's
it
knows
only
about
global
destination,
address
and
wants
to
kind
of
resolve
this
by
using
link
local
address
resolution
and
next
slides
with.
S
So
the
target
will
respond
and
this
option
will
respond
with
its
link
local
address
when
it's
requested
and
by
doing
that
the
source
will
obtain
destination,
link
local
address
and
they
can
open
a
socket
using
its
own
link,
local
address
from
the
same
link,
so
the
communication
can
be
done
on
the
local
link
using
link
local
addresses.
B
B
S
C
B
Well,
I
have,
I
guess
one
question
I
mean
I,
I
guess
I
wonder
if
I
understand
this:
it's
basically
to
try
to
move
more
communication,
local
communication
to
just
usually
global
locals,
so
they
don't
have
nodes,
don't
use
a
global
address,
but
I
wonder
how
useful
that
really
is.
Does
it
I
mean
it
seems,
like
a
lot
of
devices
are
going
to
need
global
addresses
to
communicate
outside
of
the
local
environment.
So
I
don't
know
how
useful
this
is.
S
Well,
the
expectation
is
that
if
we
have
flat
infrastructure
within
enterprises-
let's
say
small
medium
enterprises,
we
we
can
keep
all
the
local
traffic
inside
using
link
local
addresses
and
it
would
be
practically
invisible
to
the
outside
world.
So
it
would
be
secured
very
easily
that
thing.
B
K
Hi,
so
I
just
wanted
to
point
out
that
whether
or
not
you
could
ever
even
use
this
depends
on
how
you
got
the
ip
address
or
the
host
to
begin
with.
K
If
you're
using
multicast
dns,
you
would
already
have
the
link
local
address
if
you're
using
dns,
then
you
need
to
tell
that
the
host
is
not
on
the
is
on
the
link.
So
I
just
and
and
your
use
case
is
kind
of,
like
giant
flat
network,
which
is
the
use
case.
We
don't
really
tend
to
recommend.
K
T
Can
you
hear
me
okay,
all
right?
Yes,
so
the
question
I
had,
I
guess
was
for
this
use
case.
It
does
seem
quite
a
lot
to
do
for
to
resolve
a
to
mitigate
a
an
issue
with
with
glow.
I
guess
reachability
in
leveraging
the
link
local
address,
but
I.
T
Towards
it
to
get
around,
you
know
this
type
of
an
attack
vector,
especially
because
link
local.
There
are
definitely
there
are
other
control,
plane
protocols
like
routing
protocols
and
whatnot,
similar
to
neighbor
discovery.
They
use
link
local,
but
it's
generally
local,
and
I
wonder
if
opening
link
local
up
to
be
used
globally,
if
that
would
actually
create
a
new
attack
vector.
C
I
think
ted
yeah,
so
when
you're
done
speaking
or
leaving
the
microphone
line,
you
can
unclick
your
your
hand.
I
think
fernando
you
are
next.
Yes,.
M
I'm
trying
to
understand
what
is
being
proposed
here.
My
understanding
is
that
you
know,
given
that
two
notes
are
on
the
same
link,
the
authors
want
to
essentially
suggest
that
link
local
should
be
used
instead.
Now.
My
question
is
that
if
it's
for
a
local
application,
what
first
of
all?
Normally
when
you
access
a
service,
normally
it's
the
result
of
mapping
a
name
to
the
addresses
right,
then,
in
that
case
you
know
it
could
be
an
application
policy
to
essentially,
you
know,
select
the
you
know
the
the
address
of
choice.
M
Actually,
we
do
have
a
specification
for
that
and
on
the
other
hand,
if
it's
an
application
that
is
supposed
to
operate
only
on
the
local
link,
then
you
know
probably
it
should
it
should
buy
a
link,
local
address
or
a
ula
and
not
a
global
address.
So
I'm
I'm
I'm
wondering
if
what's
what
they're
trying
to
achieve
here
and
whether
you
know
that
it's
really
necessary.
H
Yes,
if
you
can
hear
me,
we
can
hear
you.
Yes,
let
me
try
to
say
a
few
words
answering
to
fernando's
question.
First,
I
was
wondering
what
is
that
application
policy
that
or
a
document
that
tells
which
source
address
to
to
use
whether
there
is
already
such
an
application?
Then
we
would
be
interesting
to
look
at
and
then
also
fernando
says
that
the
application
could
select
a
ll
or
a
ula.
H
Yes,
it
is
true,
but
it
depends
also
on
the
site
deployment.
If
that
site's
deployment
has
considered
ulas
and
has
deployed.
Ulas
has
auto
configured
uras
on
these
phones,
because
I
think
it's
mostly
about
the
phones,
sip
phones
in
enterprises,
then
probably
it
could
be
also
an
idea
to
prefer
ulas
instead
of
lls.
It
all
boils
down
to
same
scope
communication.
So
if
my
destination
is
a
ula,
then
probably
yes
prefer
a
ula
in
the
source.
H
I
think
also,
if
I
can
continue
on
this,
the
ted
recommended
asked
whether
there
is
a
real
problem
here
to
solve
in
this.
Indeed,
it
is
a
a
good
question,
the
first
one,
one
of
the
slides
that
showed
the
topology
this
place.
I
think
a
real
deployment
into
which,
indeed,
maybe
flat
networks
are
used,
and
but
that's
how
it
is
deployed
there
this
this,
you
would
see
on
the
right
hand
of
the
slide.
There
is
a
deployment
with
zip
phones
at
one
side
and
across
the
internet.
H
On
the
left
side
there
is
another
site
which
also
has
these
phones
and
there
are
sip
services
deployed
and
then,
of
course,
one
needs
to
talk
to
the
others
across
the
internet
by
using
gwas
globally
unique
addresses,
but
when
opening
a
circuit
with
agua
one
exposes
itself
to
attacks.
So
if
I
speak
to
a
phone
that
is
near
me,
why
using
agua,
why
opening
myself
to
attacks
when
I
could
just
use
a
relatives?
H
S
H
If,
probably,
there
are
some
ethernet
networks
that
could
accommodate
very
many
zip
phones
in
my
enterprise,
which
would
make
it
a
flat
network
so
yeah.
Basically,
I
wanted
to
give
these
comments.
M
The
the
kinds
of
attacks
that
you
are
trying
to
mitigate
or
prevent
attacks
against
the
server
attacks
against
the
clients,
attacks
against,
for
example,
established
connections
between
clients
and
servers.
M
Clients
nobody
so
let's
say
that
you
have
enough
like
an
off-site
archer.
Okay,
so
your
concern
is
that
the
the
attacker
would
attack
the
server
the
client,
the
established
connection
or
or
what
else.
M
But
my
concern
is
that
if
what
you're
trying
to
protect
against
is
not
attacks
against
the
established
sessions
but
attacks
against
the
clients,
then
it
doesn't
really
matter
what
the
client
uses,
because
as
long
as
the
client,
as
long
as
the
client
has
a
global
address,
you
know
it
is
subject
to
attack,
because
the
the
client
will
still
will
still
have
a
a
global
address.
So
you're
not
preventing
or
recommend
the
decline
to
use,
let's
say
lean
locals
only.
H
Sip
has
multiple
streams,
I
think,
and
some
of
them
would
be
in
a
listening
mode.
So.
M
My
my
comment
is
that
for
the
you
know,
essentially
for
the
nodes
that
are
listening
on
a
socket.
If
you
want
to
prevent
attacks
from
you
know,
off-site
attackers
just
don't
bind
a
global
address
as
long
as
you're
buying
a
global
address.
As
long
as
you
are
using
a
global
address,
the
address
is
going
to
be
reachable,
so
the
device
is
going
to
be.
The
node
is
going,
it's
still
going
to
be
subject
to
attack,
even
if
clients
are
not
using
that
global
address.
The
global
address
is
still
there.
B
H
B
Are
over
time
so
let's
get
we
have
ted
jan
in
the
queue.
Let's
do
it
quickly
and
then
we
can
move
on.
K
One
the
suggestion
to
use
ulas
makes
a
lot
of
sense
to
me
and
I
don't
actually
know
why
that's
not
what's
being
proposed
here
and
secondly,
you
know
alexandra's
comment
about
the
phone.
You
know
the
phone
has
to
be
reached.
Somehow
you
have
to
look
it
up
somehow.
So
why
not
just
fix
the
way
you
look
it
up
so
that
you
get
so
you
return
an
address,
that's
appropriate,
and
then
you
can
listen
on
that
address
and
not
listen
on
the
gua.
L
Question,
if
we're
concerned
about
not
receiving
communications
for
the
service
awfully
quietly,
that
we
use
mineral
detail
security
mechanisms
just
do
not
accept
anything
with
a
hope
limit
which
is
not
equal
to
255
and
done.
You
can
only
get
on
linked
packets.
B
Or
or
use
the
you
know,
the
255
trick.
L
A
security
mechanism,
basically
what
mds
do
is
you
always
set
your
hope
limit
to
255
and
you
never
accept
paychecks
if,
hopefully,
which
is
not
255,
which
basically
guarantees
you
that
your
packets
are
always
arriving
from
online
and
as
a
result,
you
can
use
global
address
ula
you
could
just
link
local
address.
Does
it
flatter?
You
can
only
reach
the
service
from
the
online
client.
H
Okay,
I
I
know
this
question
of
255
the
hop
limit.
Okay,
255
must
be
the
hop
limit
and
I
note
it
down
and
I
we
will
see
about
it.
Thank
you.
Okay,.
B
U
Hi,
thank
you,
hello,
everyone.
This
is
jaydon
and
I'm
going
to
present
this
document
on
carrying
between
id
ipv6
extension
header,
okay,
this
is
these-
are
the
co-authors
of
this
document.
Next
page,
please.
U
Okay,
here
are
some
background
of
this
work.
Vtn
is
defined
as
a
virtual
android
network
with
the
topology
and
the
network
resource
required
by
one
or
group
of
services,
and
we
think
the
information
of
the
associated
vtn
needs
to
be
carried
into
the
package.
U
U
Okay,
here
we
give
some
analysis
about
the
options
of
carrying
the
video
id
in
ipv6
packet.
The
first
one
is
using
the
ipv6
destination
address.
In
this
way,
we
need
to
allocate
different
ipv6
address,
or
I
service
exceed
per
node
for
vtn,
because
this
address
will
represent
both
a
node
and
the
rating
it
belongs.
To
this
way,
it
will
increase
the
complexity
in
the
address
management
and
also
it
will
increase
the
amount
of
forwarding
entries
in
the
database.
U
The
second
option
is
the
traffic
class
field
was
designed
for
the
differentiated
qrs
treatment
and
the
ec
in
function,
and
we
note
that
the
value
of
the
tcps
may
be
changed
during
the
packet
forwarding,
which
may
not
be
what
we
want
with
the
routine
information
in
the
last
point
is
within
a
vtn.
We
may
still
want
to
use
the
tc
field
to
specify
the
different
traffic
classes,
and
the
third
option
is
the
flow
label.
U
The
flow
label
was
designed
to
for
the
load
distribution
among
the
ecmp
parts
of
the
lags,
which
means
that
the
load
distribution
is
a
perhaps
behavior,
while
the
steering
of
package
to
the
retains
the
specific
resource
needs
to
be
deterministic
and
it's
be
done
with
a
whole
net.
Whole
network
planning
based
approach.
U
U
Okay,
next
page,
please.
U
Okay,
this
page
shows
the
mechanisms
we
used
in
this
document.
Basically,
we
proposed
to
define
a
new
ipv6
option
type
to
carry
the
waiting
id
and
the
option
type.
The
first
two
bits
in
option
type
asset
to
zero
zero,
so
that
it
can
be
skipped
if
I'm
recognized
and
continue
be
processed
in
the
forwarding
path
and
the
c
bit
is
set
to
zero,
which
means
it
cannot
be
changed
during
the
forwarding
and
waiting
id
field
is
for
architect
for
archetype
identifier.
U
More
specifically,
the
processing
of
the
network
nodes
on
hubba
hub
header
needs
to
be
considered
by
the
operator
when
they
want
to
use
the
updating
option
in
their
network,
so
that
the
waiting
option
should
either
be
processed
or
ignored
in
the
packet
forwarding,
and
it
should
be
based
on
this
pop-up
hub
processing
information
operator
can
avoid
the
packet
drop
due
to
the
existence
of
the
hubba
hub
header.
B
V
U
V
U
No,
the
logical
interface
belongs
to
the
layer
3
interface,
which
is
determined
by
the
destination
address
field.
We
can
have
multiple
logical
interfaces
under
the
one
layer,
three
interface.
This
is
the
one
approach
to
separate
the
resources
under
the
same
interface.
V
U
Yeah,
for
actually
the
forwarding
is
based
on
two
steps.
First
step
is
you
use
the
destination
address
to
identify
the
neighbor
or
your
next
hop,
and
then
you
use
the
written
id
to
identify
which,
like
which
queue
or
which
logical
interface,
to
send
the
traffic
to
the
desktop.
V
Yes,
that's
good,
that's
good!
If
it's
just
next
q,
then
we're
okay,
if
it
determined
the
next
hop
you
have
having
a
node
skip,
it
would
run
the
risk
of
routing
loops,
but
so
long
as.
D
W
W
Okay,
yeah,
I
I'd
add
one
point
to
the
explanation
to
the
robonica,
because
this
waiting
idea
is
to
identify
the
resource
is
in
order
to
determine
the
outcome
interface
other
resource.
It
can
have
the
different
format
it
means,
as
explained
by
the
jimmy.
That's
the
this
can
be
the
queue
it
also
can
be
some
the
layer,
2
interface
is
identified
as
logical
interface,
etc.
U
Okay,
let
me
answer
the
question.
You
mentioned
that
flux,
algo
or
some
other
mechanism
can
be
used
to
for
the
traffic
engineering
different
like
a
different
engineering
purpose.
Yeah,
that's
true,
but
that
is
in
the
control
plane.
In
a
data
plane.
You
need
different
identifiers
allocated
for
different
flight
circles
like
we
have
the
same
routing
based
identifiers.
We
have
the
ip
based
identifiers
just
discussed
on
this
yesterday,
so
this
document.
D
U
X
But
you
said
that
this
algorithm
that
this
identifier
is
not
used
for
next
top
selection.
Therefore
this
is
not
the
identifier
for
flex
algo.
Something
else
is
the
identifier
for
flex
alco
and
that
identifier
can
provide
any
needed
traffic
engineering.
If
this
identifier
is
driving
the
flexalgo,
then
this
identifier
is
directly
affecting
the
next
top
selection,
and
then
we
have
all
sorts
of
other
problems.
U
Yeah,
okay,
I
see
your
point.
Yeah
I
mean
flat
cycle
is,
for
the
routing
can
be
used
to
impact
the
routing
orders.
That's
hub
selection
right,
but
even
after
you
select
the
last
type,
you
still
need
some
fine
granularity
identifier
to
select
the
resource
used
for
to
send
traffic
to
the
nest
hop.
This
is
the
why
we
need
this
identifier
in
the
data
plane.
V
U
U
Is
that
clear.
V
Just
could
I
couldn't
clean
that
from
the
draft.
B
Okay,
I
think
we
need
to
wrap
up
for
over
time,
so
the
next
presentation
is
linda,
dunbar,
linda,
so
we're
very
close
to
the
end
of
the
session.
I
think
it
will
let
us
run
over,
but
if
it's
okay
with
you
we'd,
like
to
move
you
to
the
friday
session,
is
that
okay.
Y
B
I
could
we
could
put
you
after
the
working
group
says
presentations,
so
that'll
be
more
yeah,
we're
not
going
to
use
most
of
the
time
on
friday.
Okay!
Well,
good!
Well!
Thank
you.
Thank
you
all
right!
So.