►
From YouTube: IETF113-6MAN-20220322-0900
Description
6MAN meeting session at IETF113
2022/03/22 0900
https://datatracker.ietf.org/meeting/113/proceedings/
B
Yes,
good,
I
guess
morning
in
vienna
very
very
early
in
the
morning
for
me,
so
this
is
a
six-man
working
group.
Next
slide.
B
This
is
notewell,
which
you
should
all
know
by
now.
We
will
have
a
test
at
the
end,
but
basic
description
of
the
itf
process,
how
it
relates
to
meetings
we're
using
meat
echo
in
a
slightly
new
way
this
time,
because
this
is
a
hybrid
meeting,
if
you're
in
the
room,
use
the
light
version
to
join
the
queue,
don't
use,
audio
and
video
if
you're
in
the
room.
B
If
you
happen
to
be
there's
a
light
version
which
I,
since
this
is
tuesday,
you
should
all
know
about-
and
you
know
likewise
only
turn
on
your
audio
and
video
if
you're
speaking
or
presenting,
and
we
recommend
headsets
next
slide.
B
We
have
the
jabra
room
being
run
out
of
meat
echo.
You
can
also
access
it
with
zulup,
which
I
have
running
in
the
background
somewhere,
so
where
the
minutes
are
shoot.
Many
thanks
to
xu
ping
for
taking
minutes.
If
there's
someone
else
who
also
wants.
A
I
think
pascal
to
bear
also
volunteered
to
do
help
out
with
a
minute.
So
oh.
B
B
We
have
four
working
group
documents
to
discuss,
as
you
note
here,
tom
herbert
submitted
slides,
but
he
had
some
other
family
obligations
that
kept
him
from
being
able
to
present.
So
we
will
have
a
little
extra
time
for
the
agenda,
which
is
good
because
it
was
already
very
tight,
but
he
would
appreciate
feedback
on
his
draft
on
the
list,
but
you
you
know
those
his
slides
will
be
in
the
presentation.
B
B
That
was
discussed
quite
a
lot
last
time
we'll
be
presented
and
then
ted
will
be
talking
about
source,
address
selection
next
slide,
and
then
we
have
five
short
presentations
on
new
drafts
that
haven't
had
much
discussion
or
it
doesn't
it's
unclear
what
the
level
of
working
group
support
is
that
we
hope
to
get
to,
and
I
think
we
should
have
time
this
time
for
a
brief
talk
on
each
of
those.
These
are
intended
to
be
introductions
to
this
work,
not
not
to
have
a
big
discussion
next
slide.
B
D
A
A
A
Thank
you
so
document
status.
So
since
the
last
meeting
meeting,
we
have
published
one
rfc
9131
on
gratuitous
neighbor
discovery.
We
have
nothing
in
the
rfc
editor
queue.
A
We
have
three
documents
submitted
to
the
isg.
We
have
the
oam
document
in
segment
routing
which
has
one
disqus.
We
have
the
alternate
marking
method,
which
is
it
down
to
one
discuss
now.
Otherwise,
it's
two
and
we
have
the
minimum
path
empty
by
hop
option
document
eric.
Do
you
want
to
say
a
little
bit
about
this?
The
status
of
these
in
the
isg.
E
I
just
issued
the
ballot
for
mtu
option
and
requested
putting
on
a
telechat,
so
I
might
be
on
the
first
telechat
in
april
or
the
second
telechat
in
april.
E
A
F
Good,
so
we
have
a
discuss
from
then
we
have
addressed
the
comments
from
then
and
sent
an
email
to
him
as
well.
So
the
comment
has
been
addressed
in
revision.
11.
revision,
13
howard
bean
had
had
a
chance
to
clearly
discuss.
That's
the
only
discuss
pending
yeah.
That's
right.
I
talked
I.
E
Ben
is
working
to
clear
all
of
his
document
cue
before
tomorrow
evening,
andover
so
hopefully
he'll
get
to
it.
If
not
we'll
I'll,
follow
up
and
ask
the
incoming
psyched
if
they
want
to
pick
up
his
comments
and
complete
the
review.
A
Like
these
are
finally
progressing
they've
been
at
the
isg
for
about
300
days,
I
think
so,
but
at
least
there's
no
action
from
the
working
group.
Thank
you
and
we
have
nothing
awaiting
write
up
or
in
adoption
calls.
We
have
four
new
work,
relatively
new
working
group
documents.
A
We
have
the
zone
identifiers
document
that
just
passed
adoption
call
that
brian
is
going
to
video
talk
about
later.
We
have
the
limits
on
sending
and
processing
ib6
extension
headers.
There
is
a
presentation
in
the
in
the
proceedings,
but
tom
can't
present
on
that.
A
A
D
G
I
don't
know
whether
I
can
do
that
okay,
so
this
is
the
ipv6
hot,
buy
up,
opt
by
op
options,
processing
procedures
and
it's
bob-
and
I
who
are
the
document
editors.
This
is
the
first
working
group
version
of
this
document,
but
now
we're
at
zero
one,
because
we
did
some
tweaking
after
we
started
the
process
so
we'll
describe
to
you
where
we
got
and
hopefully
interest
you
in
helping
us
to
get
to
the
final
destination.
So
next.
G
There
may
be
some
disagreement
about
whether
they
should
ought
must
work,
but
that's
kind
of
where
we're
starting
from
they're,
not
working,
it's
very
common
for
routers
to
drop
hot
by
hop
option
headers
and
where
they
do
it
and
which
ones
do
it
is
kind
of
an
interesting
measurement
problem,
and
probably
we
should
delve
into
that.
We
will
hopefully
see
more
data
agent
200
said
that
it
would
document
the
current
practice.
G
G
Changes
from
the
individual
draft:
well,
we
listened
to
the
working
group.
We
didn't
necessarily
find
the
answers
to
the
questions
that
were
raised,
but
we,
where
we
found
answers,
we
changed
the
text
right,
so
there
is
a
kind
of
elephant
in
the
room
which
could
think
us.
Sorry
I
carry
on
talking
while
you
figure
out
what
to
do
so.
We
just
bob.
We
just
lost
video
to
the
projector,
but
I
think
we
can
okay.
G
One
of
the
big
questions
we
have
to
figure
out
is
what
language
do
we
use
to
talk
about
this
thing
that
we
call
fast
path,
which
was
a
nice
thing,
simple
option
between
doing
something
in
an
accelerated
hard
work
or
software
fashion
versus
doing
a
big
full
pass
of
the
packet
headers
life's,
not
quite
so
simple
now
as
it
used
to
be
and
we're
going
to
get
stuck
on
words.
G
A
Soon
it
would
be
good,
so
people
can
either
go
into
the
metico
and
act
as
they
are
remote
and
they
can
see
the
slides
or
you
can
just
look
at
the
pdfs.
So
here's
there's
support
here's
technical
support.
G
Okay,
so
so
the
the
real
takeaway
from
this
slide
and
is
when
we
did
the
adoption
call
lots
of
people
responded.
Thank
you
ever
so
much
lots
of
people
responded
with
yeah.
Let's
do
this,
but
and
they
had
some
sort
of
issue
and
we
thought
as
an
experiment.
What
we
would
do
is
try
and
capture
as
many
of
those
as
we
could
actually
work
out
from
passing
the
thread
and
put
them
in
the
issue
tracker
straight
away.
G
B
D
G
Well,
bob
we've
got
slides
here,
so
your
parallel
universe,
I
think
we'll
carry
on
okay.
So
this
is
the
url.
I
mean
it's
the
working
group
url,
so
you
can
find
it,
but
please
go
there
because
we'll
use
it
and
we
will
pass
the
mail
thread
and
try
and
add
issues
to
this.
If
you
feel
inspired,
you
can
go
and
add
an
issue
yourself
and
surely
please
comment
on
the
issues
as
we
try
and
respond
to
them
in
the
tracker.
G
So
we
can
assemble
this
massive,
slightly
conflicting
responses
to
get
something
coherent
at
the
end
of
the
process.
So
are
we
ready
to
go
right
now?
We
look
at
the
issues.
Hopefully
we'll
have
fewer
of
these
as
we
do
each
presentation
to
six
months.
These
are
the
short
things
most
of
these
we
hope
are
just
fixed.
G
G
G
Better
to
encode
hot
by
hot
processing
in
the
destination
address
is
an
interesting
proposal,
but
I
think
it
changes
the
ipv6
architecture.
So,
for
the
moment
we
cast
that
one
out
and
we
changed
the
spelling
mistake,
which
was
fun
because
we
didn't
see
it
next
slide.
Please
right
now
he
was
always
more
substance.
G
Why
do
leading
edge
line
speed
routers
want
to
ignore
the
hop
by
hop
extension
headers?
What
is
it
they
will
get
as
benefits
if
they
don't
ignore
them?
I
think
if
we
can't
answer
this
question
properly
by
the
end
of
the
document,
nobody
will
bother
reading
the
document,
so
this
is
actually
fundamental
and
not
obvious.
Yes,.
G
Well,
either
way
right,
yeah,
yeah,
yeah
right,
but
seriously
both
ways.
We
need
to
put
that
argument
through
and
figure
out
what
it
is.
That
is
the
right
thing
to
do.
You
know
is
there
benefits
for
not
ignoring
ignoring
it
and
the
meaning
of
should.
I
must
needs
full
care
in
working
it
out
because
it
could
be
one
of
these
places
where
shouldn't
must
seems
like
simple
words,
but
probably
need
to
be
really
explained
in
context
here.
G
So
that
wasn't
very
helpful,
but
it
was
just
saying
issue:
two
is
the
one
where
really
it
would
be
good
to
get
a
little
bit
more
text
and
thoughts.
Do
you
wanna
say
any
more
bob?
G
G
I
hope
the
operation
is
considered
payloads.
This
refers
to
I've
seen
9098,
and
maybe
we
need
some
text
around
forwarding
nodes
that
look
into
the
what
people
often
call
the
transport
header
the
offset
it
can
be.
There
are
things
related
here
to
the
work
by
tom
herbert,
so
we
probably
have
to
link
with
that,
but
it
does
have
an
impact
on
whether
the
hot
buy
hop
option
is
finally
passed
so
actually
needed
here.
Next,
one.
G
What
do
we
call
the
way
in
which
routers
sometimes
do
things
better,
with
some
types
of
packets
and
headers
than
other
types
of
packs
and
headers,
which
can
be
actually
causing
them
more
pain
right?
So
I
invented
with
bob
the
idea
of
full
forwarding
rate
define
full
how
you
like
forwarding,
is
certainly
what's
happening.
Your
rate
is
the
thing
that's
affected
and
the
idea
being
simply
to
try
and
move
away
from
the
fastpass
slow
path,
which
is
many
connotations.
G
G
G
I
Oh
yeah,
the
the
comment
right.
Yes,
I
I
think
if
we
define
it
to
be,
you
know
the
same
throughput
as
without
the
option,
header
right
and
then
the
question
is:
is
that
reasonable
to
expect
right?
So
I
think
the
the
minimum
functionality
that
we
need
to
look
into
is
to
be
able
to
do
all
the
crappy
things
that
a
platform
may
do
in
looking
into
layer,
4
information
to
skip
through
the
chain
of
extension,
headers
right
and
that's
that's
the
big
question.
I
If
we
can
expect
that
to
be
without
performance
penalty,
so,
and
maybe
so
in
in
other
cases
like
control
plane,
we
did
questionnaires
right,
so
we
just
did
questionnaires
and
multicast.
So
maybe
you
know,
starting
to
put
together
a
questionnaire
for
relevant
things
that
we
want
to
learn
to
help
improve.
This
might
be,
you
know
an
an
option
to
look
into
okay,
so.
A
J
So
full
forwarding
rate
is
probably
not
a
good
term.
There
are
times
when
you
move
the
packet
through
the
forwarding
hardware
and
you
get
half
forwarding
rate
or
you
might
give
up
some
of
the
forwarding
to
do
this.
The
big
thing
is
the
previous
slide,
where
it's
like.
Why
would
we
even
bother
and
if
you
said,
must-
and
we
think
in
our
asics-
we
can't
afford
it.
We
might
just
ignore
the
must.
J
So
the
question
is:
what's
the
value
of
processing
hop
by
hub,
what
are
the
kind
of
options
you're
putting
there
and
how
would
it
help
if
it's
worth
processing
it
doesn't
have
to
be
full
forwarding
rate?
So
I
think
fast
path
and
slow
path
is
probably
better
because
for
me,
slow
path
is
like
really
slow
and
fast
path
is
pretty
fast,
but
it
may
not
be
fulfilling
right.
G
That
makes
sense,
it
makes
sense,
but
then
I'm
sure
other
people
will
argue
slightly
differently,
and
this
is
just
wording
that
we
have
to
get
right
because
there's
some
semantics
behind
it.
We
have
to
just
capture
that
yeah
yeah.
Okay,
I
hear
what
you're
saying
I
will
carefully
think
on
those
words.
K
Ben
madison
work
online.
Sorry,
my
app
doesn't
want
to
work.
So
I
suppose
my
my
feedback
here
would
be
roughly
the
same
as
karit's.
For
me,
what's
important
is
not
necessarily
the
forwarding
rate,
but
the
determinism
of
the
performance
as
soon
as
you
start
punting
stuff,
you
don't
know
in
advance
what
the
various
bytes
are
going
to
do
to
your
cpu
right,
and
that
was
that
was
the
slope
I
think
was
kind
of
like
I'm
going
to
go
through
a
decision
tree
about
how
to
get
there
so
slow
path.
K
For
me
is
I'm
going
to
wind
up
in
a
general
purpose,
cpu
somewhere,
that's
busy
with
other
stuff,
some
of
which
may
be
significantly
more
important.
I
think
the
thing
to
capture
here
is:
I
mean
speaking
as
speaking
as
a
network
operator.
What
I
want
to
know
is
how
do
I
configure
a
policer
to
make
sure
that
what
is
entering
can
be
dealt
with
deterministically
so
that
I
don't
end
up
blind?
K
Fast
path
is
the
place
where
a
given
operation
can
happen
at
a
very,
very
stable
rate
of
packets
per
second,
and
that's
usually
some
sort
of
hardware
device.
But
I
think
I
think
that's
the
way
to
talk
about
it.
Generically
personally.
I
Again
yeah,
maybe
maybe
we
really
need
to
start
figuring
out
a
place
where
we
can
put
together
the
experience
about
the
issue
that
that
we've
gained
before
even
trying
to
come
to
a
conclusion
of
what
the
right
verbiage
is.
Let
me
add
the
one
I
think
high
level
data
point.
We
got
from
multicast,
where
you
know
the
forwarding,
even
let's
say
without
replication,
took
you
know
four
times
the
amount
of
resources
than
of
a
unicast
packet
in
a
lot
of
platforms.
So
what
was
the
impact?
I
The
impact
was
that
in
a
mix
of
unicast
and
multicast
packets,
the
you
know,
average
packet
size
you
could
do
and
and
still
achieve
line
rate
was
going
up
as
because
you
couldn't
the
the
total
packet
rate
you
could
do
was
was
lower
in
the
mix.
And
so
then
we
had
to
argue.
Oh
wait
a
second,
so
this
multicast
traffic
is
all
video,
so
it's
large
packets,
so
it
actually
helps
your.
I
But
so
I
don't
think
that
kiriti's
thing
like
it
can
be
at
a
lower
packet
rate
is
something
that
may
be
seen
as
appropriate
by
operators
depending
on
what
you
know.
The
packets
with
more
complicated
processing
requirements
is
right.
We're
now
looking
only
into
the
options,
but
I
think
the
the
problem
is
general
right.
If
there
are
different
forwarding
performances,
how
do
we
deal
with
that
and
yeah?
I
I
would
just
to
go
back
to
my
previous
point,
just
ignoring
this
stuff
right,
just
having
some
offset
of
extension,
headers
that
a
particular
platform
can
chose
to
always
ignore,
but
not
complain
about
the
fact
that
it
needs
to
skip
forward
and
ignore
it
at
the
line
rate
at
whatever
the
packet,
without
the
extension
header
has.
That,
I
think,
is
the
the
one
glorious
requirement.
We
need
to
be
able
to
do
everything
else.
I
think
we
have
a
lot
of
flexibility.
Okay,.
G
I'm
more
on
deterministic
processing
there,
so
I
I'll
pick
up
that
and
I'll
try
and
listen
to
the
audio
again
and
make
some
notes
in
the
issue:
tracker:
okay,
8200!
Oh,
this
is
just
for
clarification.
We
should
be
much
clearer
on
this.
The
whole
purpose
h200
was
to
progress
to
full
standard
and
it
wasn't
intended
to
do
anything
to
change
the
spec
and
this
particular
piece
of
work
here
is
a
plan
to
do
some
new
design
work
of
some
sort,
unlimited
scope,
hopefully,
but
it's
a
different
thing
to
x200
next
right.
G
Oh
yeah,
we
didn't
change
anything
for
this
because
we
didn't
know
what
to
do.
I
mean
clearly.
This
is
actually
the
other
side
of
having
an
extension
header
is
when
people
write
their
code
for
processing,
malformed
extension
headers,
the
chord
may
be
incomplete
or
it
may
contain
a
bug
because
it's
not
exercised.
Often,
if
it's
in
hardware,
then
that's
a
little
bit
more
tricky
even
and
maybe
we
weren't
so
smart
at
the
beginning
of
ipv6.
G
G
That
would
be
a
good
thing
to
talk
about
as
we
go
forward,
but
we
didn't
change
anything
yet.
Should
we
deprecate
roots
or
alert,
question
and
ron
bonica's
writing
something.
So
we
thought
we
might
wait
and
see
what
ron's
suggestion
happened
to
be
received?
Who
liked
that
who
didn't
like
that?
So
we're
not
doing.
G
You
see
there's
many
flavors
of
this
because,
depending
on
where
you
sit,
you
have
different
versions
of
not
liking
this,
and
I
think
this
is
the
one
we'll
try
and
tidy
up
if
we
can,
by
gathering
all
these
together
and
listening
to
what
people
say.
So
we
are
listening
next
one:
what's
the
difference
between
slow
path,
fast
path
and
does
that
become
root
in
the
future,
this
is
slide
13.
If
you're,
following
on
the
side
numbers.
G
A
So
to
insert
myself
in
the
queue,
so
I'm
working
on
a
forwarding
engine
like
that
which
only
has
a
fast
path
and
it's
an
in
deterministic
forwarding
path.
You
know
fast
forwarding
path,
but
I
don't
know
if
it
makes
any
significant
difference.
Really.
You
have
the
cycles.
You
have
right
at
the
time
you
have
them
so
get
ready.
Please
go
ahead.
Yes,.
J
A
J
So
I
think
that
terminology
is
important
to
keep
yes,
people
are
talking
about.
You
know,
running
routing,
forwarding
on
vms
and
so
on,
and
then
the
distinction
will
be
far
less,
but
the
rate
at
which
network,
processors
and
and
general
special
purpose
asics
are
growing
compared
to
how
cpus
are
growing.
That
distinction
will
just
get
bigger.
G
Yeah-
and
I
think
also,
we
have
a
box
size
problem
here.
We
have
routers
which
are
like
bigger
than
me,
and
we
have
routers
that
can
fit
in
my
pocket
and
some
all
of
these
form
the
path
and
if
they
any
of
these
block
extension
headers,
then
you
don't
get
extension
headers
across
the
path
between
two
users.
G
So
it's
a
little
bit
tricky
to
get
language
right,
because
there
are
very
different
views
of
what
a
router
is
so,
which
ones
do
we
need
to
change
to
make
this
happen,
I
think,
is
the
is
the
ultimate
question
and
we'll
get
there
hopefully
yeah,
and
I
will
listen
to
the
words
you
spoke
as
well.
K
Ben
madison
again,
I
assume
that
the
implementation
that
you
mentioned
a
moment
earlier
was
vpp.
So
I
mean
vpp
is
a
good
example
of
where
this
becomes
a
kind
of
weird
nuance.
I
suppose
the
thing
is
when
you're,
even
when
you're
running
something
like
that
implementation
on
general
purpose,
cpus
you're
still,
I
presume
writing
it
with
a
very
specific
cycle
budget
in
mind.
K
This
is
the
processing
path
where
I
can
just
execute
arbitrary
code,
and
I
can
go
into
a
loop
and
all
of
those
nice
things
can
happen,
and
this
is
the
bit
where
I
have
a
hard
stop
time
and
that
will
be
different
for
different
platforms,
and
you
know
mostly
operators
can
be
trusted
to
choose
the
right
one,
depending
on
how
you
know
how
how
hard
a
deadline
that
is,
but
I
think
that
that
I
I
still
think
that
that's
the
that's
the
distinction
to
capture
it's
the
it's
the
path
in
which
other
stuff
won't
be
asked
to
sit
and
wait
around.
I
Okay,
yes,
so
tell
us
again:
maybe
you
know,
I
think,
there's
a
lot
of
insight
gained
into
these
performance
characteristics
and
I
think
it's
it's
certainly
too
much
for
this
document
and
I
think
we're
just
trying
to
figure
out
what
of
that
insight.
I
We,
you
know,
want
to
take
here
for
this
document,
but
maybe
we
should
have
another
document,
maybe
in
routing
working
group
or
so
I
don't
think
we'll
get
away
without
writing
down
what
we
know
and
don't
know
about
the
word,
slow
and
fast
path,
and
maybe
we
should
write
that
down,
but
in
here
maybe
just
you
know
afternoon
extraction
when
you
go
to
edge
routers
right.
I
So
these
very
flexible
network
processing
engines,
we
we've
done
performance
tables
in
terms
of
from
you
know,
line
rate
at
120
bytes
down
to
you
activate
this
feature,
you
activate
that
feature.
You
do
this
qs
right,
so
qs
transport
level,
stuff
looking
into
layer,
4
ports,
it's
just
a
continuous
slide
down
right.
This
is
all
fast
path,
but
still
the
performance
impacts
right
that
that
you
have
impact
the
number
of
subscribers
you
can
put
behind
that
that
device
right.
So
what
do
yeah?
I
I
think
it's
it's
a
lot
more
complicated
than
just
trying
to
say
a
slow
and
fast
path
in
general
and
when
we
do
an
actual
hop
by
hub
header
function
that
is
applicable
to
some
traffic.
The
exact
performance
characteristic
of
that
has
to
be
part
of
the
discussion
about
that
by
hop
header
functionality
right,
but
here
we're
trying
to
do
something
independent
of
individual
ones
yeah.
I
J
J
L
J
G
G
Oh,
come
on,
let's
have
another
issue
that
was
one
that's
very,
very
similar
to
another
one.
So
we're
going
to
close
that.
G
What
are
the
incentives
for
wider
support
and
yeah?
I
mean
we've
already
started
touching
on
that
and
I
think
we
will
form
an
issue
here
which
will
probably
go
for
a
little
while,
which
is
we
should
try
and
explain
what
hot
by
hot
processing
is
actually
useful
on
what
it
might
be,
so
that
we
can
motivate
people
reading
this
draft
and
doing
something
different.
G
Otherwise,
the
status
quo
is
maintained
and
we
don't
have
support
for
hot
by
hot
extension
headers,
because
people
already
started
blocking
them.
So
if
we
don't
explain
what
are
the
incentives
for
wider
support,
then
we
won't
get
anywhere,
but
we
need
contributions
of
text
and
we'll
put
them
into
the
issue.
There's
some
man
standing
in
the
room
which
is
not
in
the
microphone
queue.
I
don't
know
quite.
I
I
would
I
would,
I
would
always
say
the
first
thing
where
to
have
in
there
is,
must
be
able
to
ignore
right
should
be
able
to
process
a
secondary
must
be
able
to
ignore,
I
think,
is
the
core
thing
for
interoperability
right
so
because
I
think
everything
we're
doing
is
going
to
be
optional
for
and
so
that
I'd
really
love
to
see.
That
must
ignore
support
the
size
as
as
as
the
core,
and
that
was
toilet.
Speaking
again,.
G
We
can
stay
at
the
one
chair
who's
sitting
in
the
room
and
say
at
the
end
of
the
day,
are
we
going
to
make
recommendations?
Are
we
actually
going
to
make
requirements?
Should
this
be
a
standard
strike
document
and
we'll
keep
asking
him
until
he
decides,
but
I
guess
that
would
be
depending
on
how
the
document
goes.
But
it's
a
useful
question
because,
depending
on
how
strong
the
consensus
is-
and
we
should
make
recommendations
for
the
smaller
our
recommendations
with
the
big
r-
he
says.
Yes,
that's
good
number
20..
G
Yeah
extensions.
Headers
are
an
obvious
way
to
extend
ip
features
and
I
guess
we
live
in
faith
that
we
can
extend
ipv6.
I
think
it
would
be
a
good
thing
to
do
personally
and
we
agree
that
a
specific
hop
by
hop
option
will
only
be
processed
by
nodes
wanting
to
do
so,
which
is
kind
of
a
little
bit
like
we've
heard
today.
G
G
It
seems
simple,
but
and
then
some
people
didn't
like
that
one,
so
that
will
be
an
argument
of
having
routers
on
router
alert
and
stop
us
going
further.
There's
a
url
to
the
issue
tracker,
which
is
where
all
this
stuff
really
the
best
discussion
so
end
of
my
talk,
you
have
seven
more
slides.
I.
A
A
B
I
thought
I
just
did,
but
so
the
next
we
have
so
we're
not
doing
tom's
talk
so
now.
Jai
dong
talk
about
vtn
id.
M
A
So
please
please
go
ahead.
I
can
give.
M
Okay,
thank
you.
So
this
is
an
update
about
carrying
vtid
ipv6
extension
header
draft,
I'm
presenting
on
behalf
of
the
co-authors
here.
M
M
Okay:
here's.
The
first
comment
is
about
the
terminology
during
the
adoption
call
there's
some
discussion
about
why
they
will
call
it
vtn
resource
id
or
the
nrp
id
or
something
else.
M
I
think
this
is
related
to
the
terminology,
discussion
and
definition
in
the
teas
working
group
and
in
this
working
group,
the
nrp
or
network
resource
partition
is
defined
as
a
set
of
network
resources
allocated
in
the
network
and
the
vtn.
The
virtual
transport
network
is
a
virtual
android
network
which
is
consisting
of
a
set
of
natural
resources
and
associated
with
a
network
topology.
M
So
it
seems
that
the
vpn
resource
id
and
rpid
refers
to
the
same
thing,
and
currently
the
test
working
group
is
working
on
the
alignment
of
the
terminologies
in
a
set
of
graphs,
and
this
document
could
follow
the
decision
made
in
tears
and
to
do
the
terminology
alignment,
but
something
some
something
more
to
be
considered
here.
Is
that
whether
we
want
to
extend
the
semantics
and
the
format
of
this
id
for
the
hubba
hub
extension
header?
M
Okay,
the
second
comment
is
about
the
processing
procedures.
The
first
one
is:
if
a
node
skips
the
hub
hub
extension
header,
it
cannot
apply
the
policies
required
for
the
vta,
so
this
is
yeah.
This
is
a
reasonable
comment
and
our
response
is
that,
if
strictly
conforming
to
the
vtin
specific
processing
is
required
in
the
network,
it
would.
It
is
recommended
to
make
sure
that
all
the
nodes
involved
in
the
vtn
can
process
the
hobby
hub
and
this
machine
option.
M
This
can
the
capability
of
the
national
nodes
can
be
obtained
either
via
the
management
system
or
some
control
plan
advertisement,
so
that
we
can
make
sure
that
the
traffic
will
only
be
for
forwarded
to
the
nodes
which
have
this
capability?
M
Another
thing
related
to
the
processing
is
how
to
process
the
packet.
If
the
transient
knows
it
can
pass,
it
can
pass
the
rvt
option,
but
it
does
not
have
the
network
resources
allocated
to
the
vtn.
M
M
M
Processing
the
short
third
comment
is
about
the
semantics
and
format
of
the
beating
option.
M
We
received
the
comments
and
suggestion
that
to
make
this
tag
generic
and
flexible,
because,
in
addition
to
the
network
slicing,
there
are
other
use
cases
which
could
benefit
from
this
attack
and
there's
also
following
comments
about
whether
we
need
to
consider
to
allow
the
variable
length
of
the
stack
and
whether
we
should
introduce
some
structure
to
this
option.
M
So
here
are
some
considerations
from
the
authors.
The
first
one
is.
We
think
the
semantic
of
this
id
is
like
a
natural
white
identifier.
So,
if
anything,
which
is
natural
white,
has
some
natural
white
semantics
may
be
carried
in
using
this
id?
If
it
is
generalized.
M
Another
thing
is:
we
need
to
consider
to
align
with
the
processing
and
suggestions
and
the
guidelines
in
the
harbor
hub
processing
draft.
The
first
one
is:
we
need
to
make
sure
that
this
the
option
is
straightforward
process
and
the
length
of
this
option
should
not
be
extremely
long,
which
can
make
it
extend
beyond
the
capability
of
the
nose
and
for
the
like
fastpass
processing,
so
taking
both
into
consideration.
We
are
considering
to
make
some
extensions
to
this
option,
to
keep
some
extensibility
and
for
the
future
use
the
option.
N
Yes,
my
command,
let's
not
think
about
it.
My
comment
is
the
need
to
signal
a
psychological
topology,
for
which
there
is
a
state
in
the
nodes
is,
is
appears
in
in
multiple
places.
We've
we've
done
already
a
heartbreak
header
option
for
ripple,
that's
the
ripple
option
and
that's
exactly
what
it
signals.
There
is
what
we
call
an
instance
id,
which
is
a
logical
topology
that
basically,
you
place
the
packets
on
right
now
at
that
net.
N
We
also
have
the
need
to
signal
something
like
a
path
which
is
really
a
a
complex
logical
structure
on
which
the
packets
will
be
forwarded
and
with
the
exact
same
needs
that
you
know,
every
nodes
on
the
path
must
understand
the
topology
and
forward
based
on
a
death
net
state
which
is
associated
to
that
topology,
and
so
I
was
like.
Are
we
going
to
create
one
option
per
work
group
or
or
is
there?
M
Yeah
very
good
question
I
think,
from
the
beginning
of
this
document.
We
can
see
that
it
is
mainly
about
the
initial
idea
is
to
use
this.
I
option
to
identify
a
virtual
transfer
network
and
the
set
of
resources
for
packet
processing,
but
in
the
adoption
call
we've
received
this
comments
about
the
weather
to
consider
to
generalize
it.
M
N
Yeah
I
mean
it's
not
for
the
comments.
It's
really
I
mean
I'd
like
to
back
from
the
room
actually
or
from
people.
So
do
we
have
a
direction?
Is
there
is
an
intention
to
to
lead
to
many
many
options
or
or
more
coalesced
ones?
I
mean.
Is
there
like
an
architecture
that
would
like
to
follow
us?
A
quote.
M
B
M
Okay,
so
here's
the
next
steps
we
would
like
to
collect
the
further
feedbacks
from
the
working
group
on
the
above
discussion
points,
and
if
we
have
some
consensus
on
any
of
them,
we
will
update
the
document
accordingly.
A
B
A
O
A
web
browser
may
be
the
handiest
tool
for
this,
for
example,
just
to
send
out
packets
that
you
might
want
to
trace,
and
it
may
be
the
only
tool
for
actually
reconfiguring
devices
whose
configuration
mechanism
is
a
built-in
web
server
if
they're
otherwise
broken
and
need
to
be
hand
reconfigured
and
there's
at
least
one
application
cups
printing
that
needs
http
usage
of
link
local
addresses
on
a
specific
interface.
So
the
use
case
is
quite
real,
even
if
not
very
mainstream.
O
O
O
Well,
it
modifies
the
abnf
of
the
formal
definition
of
uris
by
adding
in
this
new
new
component,
a
percent
sign,
followed
by
25,
followed
by
the
interface
name.
You
use
percent
25
as
a
separator,
because
that's
the
method
in
uris,
according
to
the
syntax
of
escaping
special
characters
such
as
the
percent
sign.
O
O
O
Another
problem
is
that
the
text
of
6874
requires
hosts
to
delete
the
zone
id
from
outgoing
uris.
That
would
be
in
an
http
host
header,
for
example,
that
violates
the
normal
behavior
of
http
implementations,
the
very
least
it's
all
quick
to
code,
and
it
actually
breaks
one
of
our
use
cases,
namely
the
cups
printing
protocol.
So
the
proposal
now
is
to
simply
delete
that
requirement.
O
Third
problem
with
rfc
6874
is:
it
suggests
that
url
passes
should
support
the
percent
25
encoding,
but
heuristically
accept
a
uri
that
doesn't
contain
the
percent
encoding,
so
descent
f
zero
would
be
recognized
as
the
same
as
percent
two
five
at
zero,
except
for
the
exception
cases
where
percent
sign
can
could
be
a
legitimate
escape.
It
makes
it
very
tricky
to
code
is
very
confusing
to
users,
so
the
proposal
is
to
delete
this
suggestion.
O
So
we
end
up
with
a
final
proposal,
which
is
that
parsers,
whether
they're,
parsing,
uris
or
iris,
should
accept
a
literal
address,
as
shown
there,
which
simply
has
percent
and
the
interface
name.
O
The
zone
id
should,
of
course,
be
passed
on
to
the
socket
api
without
any
need
to
validate
it,
and
there
are
no
other
special
requirements
for
browsers
all
the
other
special
stuff
we
discussed
in
rfc,
6784
6874
is
dropped.
O
O
So
our
conclusion
at
the
moment
is
that
the
best
course
of
action
for
the
ietf
is
to
advance
this
draft
to
precisely
document
the
required
browser
behavior
and
then
wait
until
that
strong
pressure
from
users
arrives,
which
I
think
it
will
do
as
people
deploy
ipv6
only
networks
and
discover
they
have
no
other
way
to
carry
out
certain
operations.
Of
course,
we,
the
authors,
would
prefer
to
receive
lots
more
feedback.
A
Thanks
brian
any
comments
on
that.
Anyone
representing
the
browser
community
here.
A
P
Yeah
mike
ackerman,
I
I
have
a
first
off.
I
think
this
is
great
work
and
can
get
rid
of
some
inhibitors,
I'm
from
a
large
enterprise
who's
not
doing
ipv6,
and
this
is
one
of
the
reasons
why
so.
This
is
great
work,
our
in
in
brian's
context,
there
is,
is
an
organization
like
mine,
considered
a
user,
and
should
we
apply
some
kind
of
pressure
here
to
our
vendors
or
should
we
just
sit
back
and
please
so
that's
my
question:
what
can
we
do
to
help
kind
of
question.
B
P
Fine
to
me,
and
and
just
to
give
my
perspective,
what
happens
to
us
is
I'm
one
of
the
ones
that
wants
to
do.
Ipv6
very
few
do
and
when
I
say
okay,
if
we
do
it,
here's
the
ways
to
do
it,
here's
how
we
can
help
and
everything,
but
here's
a
couple
minor
issues,
a
lot
of
people
don't
think
this
is
a
minor
issue
so
that
it's
an
inhibitor.
So
thanks
for
trying
to
address
it,
anything
we
can
do
to
help.
Let
me
know
thank
you.
Q
Michael
richardson,
at
the
mic,
having
reloaded
his
entire
browser
tab
to
get
back
to
the
thing
so
I'm
I
am.
I
expressed
the
opinion
a
couple
weeks
ago
that
there
was
no
point
in
doing
this
until
we
had
this
that
we're
just
we're
just
spinning
our
wheels
brian's
convinced
me
that
it
is
useful
to
go
ahead.
Q
I
am
very
skeptical
that
that
user,
groundswell
of
user
demand
will
appear
due
to
chicken
and
egg,
because
no
one's
going
to
bother
deploying
an
iot
device,
it's
accessible
by
ipv6
link
local
literals
until
browser
can
reach
it.
Okay,
so
you
know
that
that's
I
I
unfortunately
I
don't
know
how
to
get.
Q
I
don't
know
how
to
break
that
egg,
and
what
I
was
hoping
is
that
somebody,
maybe
an
enterprise
user
who
has
a
close
relationship
with
their
browser
vendor,
will
will
cause
at
least
one
browser
to
do
this,
and-
and
that
may
you
know,
maybe
un
break
the
log
jam,
and
I
think
that
the
example
of
in
a
home
specifically,
which
has
been
renumbered
by
renumbered-
I
mean
someone
else-
has
moved
into
the
home
and
now
they
have
a
whole
bunch
of
devices
that
are
effectively
have
names,
but-
and
maybe
they
have
ip
addresses
from
the
previous
owner
and
now
that
you
need
to
actually
go
and
find
these
devices
and
do
something
with
them
and
that
this
is
where
it
really.
Q
I
think
it's
a
real
win
for
that,
but
you
know
until
you
know,
maybe
someone's
going
to
have
to
have
a
you're
going
to
have
to
have
a
specific
compile
of
a
specific
browser
that
actually
can
find
all
your
old
devices
but
anyway.
So
the
point
is
that
I
was
on
the
skeptical.
Should
we
do
this
work?
Should
we
publish
this
is
worth?
Is
this
worth?
You
know
the
80s
time
to
review
and
I'm
convinced
that
I've
been
pushed
over
to
the
side
of
okay.
K
Did
try
again
when
you
put
the
qr
code
back
up,
it's
still
not
working,
I'm
afraid.
So
speaking
of
someone
who
can't
really
think
of
an
immediate
use
case
that
I
have
for
this,
it
seems
like
it's
probably
helpful
for
someone.
The
thing
that
occurs
to
me
is,
it
seems
like
this
is
potentially
a
an
avenue
for
either
kind
of
reconnaissance
or
or
or
data
gathering
via
the
back
door.
K
If
you,
if
you,
if
you
manage
to
get
a
browser
or
some
other
piece
of
user
software,
to
follow
a
url
of
this
form,
you
potentially
are
able
to
gather
data
that
kind
of
listens
only
on
a
linked
local
address,
under
the
expectation
that
that's
only
that
data
is
only
going
to
be
available
locally,
and
I
wonder
if
you've,
given
any
thought
to
whether
this
makes
whether
you
need
to
start
thinking
about
degrees
of
trust,
trustedness
and
whether
these,
the
the
you
know
these
qualified
uris
need
to
be
treated
as
inherently
less
trusted.
K
If
received
from
a
remote
source
than
you
know,
a
a
a
a
a
kind
of
a
normal
dns
name
based
based
uri.
It
feels
like
there
might
be
a
bit
of
a
can
of
worms
down
there.
B
R
Lorenzo
kalidi,
I
yeah,
I
think
I
think,
there's
value
in
documenting
the
correct
format.
I
don't
think
anything
will
actually
use
this
in
urls,
because
the
the
thing
that
hands
up
the
url
is
an
http
server,
usually
and
the
http
server
doesn't
know
what
interfaces
are
present
on
the
client
kind
of
by
definition
right.
So
it's
useful
like
how
does
my
iot
device
know
that
my
interface
school
leads
it's
one
right
but
anyway,
like
like,
I
said,
I
think,
there's
value
in
documenting
the
correct
format.
K
So
perhaps
it'd
be
helpful.
If
I
gave
an
example
of
the
kind
of
thing,
I
think
this
might
make
work
so
systemd,
for
example,
uses
you
know,
heuristics
and
and
information
about
the
pci
bus
that
a
nick
lives
on
to
generate
an
interface
name
by
default
by
you
know,
asking
someone
via
you
know
some
embedded
javascript
to
go
and
try
and
try.
You
know
fe-80
colon
colon
one
via
a
series
of
kind
of
constructed
interface
names.
You
might
be
able
to
gather
into
information
about
what
nick
someone's
got
on
board.
Q
And
you
get
the
last
word
michael.
Thank
you,
michael
richardson,
lorenzo's
question
about
iot
device.
Well,
in
most
cases,
what's
going
to
happen
is
that
you
need
to
get
to
the
beginning
page
of
the
device
you
get
that
by
essentially
scanning
the
the
network
using
mdns
or
something
like
that,
so
those
links
are
actually
created
locally
and
once
you
get
to
the
the
page,
the
links
are
all
relative,
so
you
don't
have
to
worry
about
the
device
knowing
which
thing
it
is
that
that's
this
is.
Q
This
is
a
mostly
solved
problem
and,
if
anything,
there's
some
security
concern
about.
If
the
page
does
come
back
with
some
interface
devices
and
but
I
think
that's
a
what's.
The
right
word
cross-site
scripting
issue
that
is
in
general
as
a
problem
not
specifically
to
this.
A
So
this
by
the
way,
is
work
that
we
asked
suresh
to
help
us
with
as
a
working
group
in
collaboration
with
spring.
So
this
came
out
of
a
work
in
spring
where
the
spring
chairs
asked
six
man
their
opinion
on
the
usage
of
v6
addresses
in
in
spring
documents.
A
Seresta
you
want
to
give
a
little
wave
or
hint
of
where
you
are
otherwise.
We
can
move
to
ted's
talk
and
come
back
to
you.
Thresh.
A
L
L
Thanks
all-
and
I
was
gonna
complain
about
like
it
being
very
early,
then
I
realized
bob
is
like
3
a.m
for
bob.
So,
like
I'm,
gonna
stop
my
complaints,
thank
you
and
and
eric
as
well.
So
thanks.
So
thank
you
very
much
like
this
has
been
like
a
very
interesting
draft
like
so
this
came
out
of
well,
as
like
allah
said,
like
you
know,
a
lot
of
discussions
between
the
six-man
chairs,
the
spring
chairs
and
the
and
the
respective
80s
as
well.
L
So
I
just
put
together
like
a
kind
of
a
straw
man
proposal
to
go
forward
with
trying
to
address,
like
all
the
points
that
were
brought
up
in
there
and
next
slide.
Thank
you.
L
Oh
excellent,
thank
you.
I
think
that's
the
part.
I
lost
the
audio,
so
thank
you.
So
the
the
goal
of
the
draft
is
to
look
at
the
characteristics
of
srv6
heads
and
how
they
relate
to
the
ipv6,
addressing
architecture
that
was
kind
of
the
ask
of
me
to
do
it
and
like
one
of
the
things
that
came
up
was
really
the
srh
like
seedless,
that's
in
there
right,
and
so
it
is
like.
I
think,
it's
pretty
clear
from
the
srh
rfc
itself.
L
Right,
like
you,
know,
there's
like
different
kind
of
things
that
can
occur
in
this
list.
Some
of
them
are
like
srv6
said
and
the
other
things
are
just
addresses
that
can
be
assigned
to
local
interfaces,
just
like
any
other
ipv6
addresses,
and
what
this
clarifies
is
like
anything
that
falls
in
the
look
other
science.
Local
interfaces
scenario
needs
to
comply
with
rfc
4291.
So,
like
you
know
how
the
address
is
formatted,
how,
like
you
know
the
nd
works,
and
so
on
needs
to
be
fully
in
compliance
with
rc4291.
L
So
we
are
really
talking
about,
like
you
know,
what's
in
b,
and
so
the
draft
like
looks
at
like
how
like
rfc8986,
which
is
the
srv6
network
programming,
defines
the
srv
success
right.
So
it's
got
like
this
three
part
thing
like
you
know
the
lock
fountain
arguments
sitting
in
there
and
this
clearly
does
not
follow
rfc
4291.
So
the
idea
is
to
really
document
this
deviation
and
to
mention
that
these
are
not
acceptable
for
assignment
to
in-house.
L
As
on
the
interfaces
and
clearly
we
do
have
president
for
doing
stuff
like
this,
so
the
6052
is
like
for
addressing
off
like
ipv's
four
type.
E6
translators
and
7343
is
like
this
orchids,
which
are
crypto
ids
and
they
don't
follow
rfc
rfc4291
either,
but
they
look
like
ipv6
addresses
so
like
what
you're
saying
is
like
hey.
This
thing
follows
the
same
path
as
this
other
things
we've
done
before,
which
don't
follow
4291,
so
don't
assign
them
to
interfaces
on
nhos
and
the
other
piece
was
like
you
know:
how
does
this
affect
stuff?
L
That
does
not
it's
not
aware
of
srv6
right,
like
you
know,
it
doesn't
do
srv6
so
for
the
nodes
which
don't
support
srv6.
These
addresses
like
when
they
appear
in
the
destination
address
of
the
packet
they're
just
used
just
like
regular
routing
addresses
right.
If
you
look
at
rfc
7608
like
which
talks
about
variable
and
prefixes,
it's
like
brian's
rc
right
and
it
really
talks
about.
Like
you
know,
you
can
have
routing
three
pictures
of
any
lens.
L
So,
like
you
know,
you
just
need
to
make
sure
that,
like
what
is
in
the
locator
part,
like
kind
of
doesn't
change
going
forward.
So
it's
simply
just
a
prefix
and
that's
really
the
standard
to
apply
here.
L
It
just
says
a
few
things
right
like,
and
one
of
them
is
to
come
up
with
some
kind
of
like
address
allocation
right,
like
it's
request,
a
prefix
allocation
from
the
inner
space
for
this
from
the
global
unicast
space
and
and
the
idea
is
like
a
lot
of
people
have
said
like
hey,
like
you
know
when,
when
you
have
a
packet,
especially
without
an
srh
like
doing
srv6,
it
becomes
like
difficult
to
do
filtering
at
the
edges,
because
you
don't
really
have
an
srh
to
look
to
see
if
this
is
like
doing
srv6.
L
So
this
allows,
like
you,
know,
people
who
don't
want
these
kind
of
packets
to
escape
the
domain
or
ought
to
enter
the
domain
depending
on,
like
you
know
where
you
look
at
it,
helps
identify
these
kind
of
packets
to
filter
them
at
the
edges
of
the
sr
domain,
and
it
also
talks
about
like
few
things
that
the
compressor
extract,
which
is
what
causes
whole.
L
Like
you
know,
exchange
between
spring
and
and
six
man.
I
saw
the
routing
and
internet
areas.
It
has
like
some
some
stuff
that
needs
to
get
fixed
before
it's
published
as
rfc,
so
it
talks
about
a
few
of
these
things
and
especially
really
about
error
handling
and
and
oam
and
like
how
the
segments
left
field
is
defined.
L
It
just
says
like
hey,
you
need
to
fix
these
things,
but
obviously
it's
not
up
to
six
man
to
decide,
but
I
think
it's
some
indication
like
for
the
80s
to
look
for
these
things
when
this
hits
the
isg
and
and
the
last
piece
is
like
you
know
pretty
much-
I
I
think
it's
it's
obvious
and
doesn't
need
to
get
said,
but
it
it's
worth
documenting
is
like
generic
ipv6.
L
Tunneling
security
considerations
apply
when
you
use
these
addresses,
especially
when,
like
you
know,
you
don't
have
like
srh
like
are
like
tunneling
happening,
you
still
have
the
same
kind
of
concerns
because
you
could
get
into
a
domain
and
direct
packets
in
a
specific
way
to
hit
specific
notes.
So
I
think
the
the
security
considerations
still
apply.
So
that's
pretty
much
what's
in
the
draft.
So
if
you
haven't
read
it,
it's
it's
like
a
pretty
easy
read:
it's
like
not
very
long,
so
please
go
ahead
and
send
comments
on
it.
L
I
got
some
extremely
good
comments
before
special
thanks
to
brian
carpenter
and
eric
klein
for,
like
you
know,
a
lot
of
the
thinking
behind
this
and
like
bob
and
ola
and
andrew
like
bruno.
Like
you
know,
a
lot
of
people
gave
like
really
really
good
comments
on
it
and
two
for
the
name
they're,
all
in
the
acknowledgement
section.
So
please
feel
free
to
reach
out
to
me
or
like
go
on
list
if
you
have
any
issues
with
it.
So
thank
you.
H
H
Use
the
something
which
is
like
more
like
borg
and
slasher,
is
your
address
space.
So
it's
never
gets
confused
with
the
like
proper
ir
allocated,
addresses.
H
Maybe
confused,
I
was
thinking
that
we're
defining
global
unicast
as
two
zero
zero
slash
three,
so
maybe
we
need
to
make
it
explicitly
clearer,
so
it
should
be
outside
of
that
block.
L
Specific
yeah,
it
is
like
specifically
outside
the
block
thanks
for.
I
think,
if
I
had
to
make
something
clearer
like
I
will
right
like,
but
it
it
it's
an
address
with
global
unica
semantics,
but
not
from
the
currently
allocated
global
textbox.
So
I
think
I
can
probably
yeah
yeah
cool.
H
L
S
Head
on
okay,
hi,
a
question
about
the
scope
of
the
draft,
I
realize
you
were
focusing
on
addressing
architecture,
but
there
were
some
other
places
where
we
might
get
in
trouble
with
8200
as
an
outgrowth
of
the
csid.
I
believe
there
are
some
situations
where
you
might
have
a
srh,
a
routing
header
that
has
no
segments
in
it.
You
just
need
it
either
to
separate
destination
options
that
come
before
and
after
or
you
might
need
it
to
carry
tax
flags
and
tlvs.
L
So
right
now
it's
like
a
good
question
right
like
so
right
now,
it's
like
saying
to
the
cc
draft
to
document
this
right,
like
you
know
how
the
segments
left
field
is
handled,
because
it's
clearly
noted
as
a
deviation
right
like
where,
especially
when
the
segments
left
close
to
zero
right,
I
right
now
it's
in
there
like.
L
If
you
want
to
have
some
kind
of
discussion
here,
I'm
I'm
perfectly
okay
with
it
right,
like
you
know,
to
add
some
for
the
meat
on
it
and
and
thanks
ron
for
your
comments
as
well
like
very
helpful
okay
from
before,
okay
yeah.
B
Okay,
good,
I
think
oli
and
I
will
start
an
adoption
call
after
the
meeting
or
next
week,
something
like
that
and
we
can
go
from
there.
C
A
Yeah,
I'm
out
this
apple
thing
that
I
have
only
have
four
usb
ports
and
all
of
them
are
used.
So
I'm
afraid
you
have
to
say
next
all
right.
Well,
I
don't
know
what
company
you
represent.
That
could
do
something
with
that,
but.
A
T
Sorry
this
is
the
mask.
Can
you
hear
me
now.
T
Yeah,
so
the
reason
that
well
so
so
this
is
a
discussion
about
the
source,
address,
relation
source,
address
selection
policy
for
foreign
ulas,
and
I
will
explain
what
that
means
in
the
presentation.
Could
I
have
the
next
slide?
T
Okay,
so
imagine
you
have
the
scenario.
This
is
not
the
only
case
where
this
can
happen.
This
is
just
an
example
scenario
that
I
can
use
to
illustrate
it,
because
this
is
something
that
that
actually
occurred,
and
I
got
a
bug
report
for
so
you've
got
a
home
network
and
you've
got
a
reasonably
competent
user
on
the
home
network
that
has
set
up
a
router
with
an
internal
network.
In
this
case
they
were
using
it
for
testing
of
you
know
software.
T
They
wanted
to
make
sure
that
various
things
could
communicate
over
a
router,
so
they
set
up
a
router.
T
You
can
see
the
router
on
the
lower
right
ish
that
is
manually
configured
to
advertise
a
ula
s,
a
pio
option
on
on
the
internal
network,
and
you
have
a
host
on
the
internal
network
in
the
far
lower
right
that
has
gotten
a
ula
address,
and
then
you
have
a
home
network
and
the
home
network
just
has
a
gua
and
it
got
the
gua
from
the
ce
router
and
there's
a
host
on
the
home
network
that
has
the
gua
configured
so
on
this.
T
In
this
configuration
the
the
router,
the
internal
router,
is
advertising
reachability
to
the
fd12
colon
3456
ula,
using
a
router
advertisement
and
host
one
sees
that
and
cu.
Router
does
not
see
that
because
cu
router
is
a
router
and
routers,
don't
listen
to
router
advertisements,
so
next
slide.
T
So
when
we
try
to
send
a
packet
from
host
one
to
host
two,
this
is
what
happens.
The
source
address
selection
chooses
2001
oc-001,
because
that's
the
only
choice
it
sends
it.
Actually,
it
sends
it
to
the
it
sends
it
to
the
internal
router
next
slide.
T
It
sends
it
to
the
to
the
internal
router
based
on
the
router
advertisement.
So
so,
actually
the
ce
router,
that's
a
mistake.
Next
slide
the
internal
router
forwards
this
to
host
two
next
slide
post
two
composes
a
reply
and
sends
it
back
to
the
source
address
that
was
selected
next
slide.
T
Now,
probably
so
so
the
the
the
internal
router
may
have
actually
been
configured
to
have
a
static
route
to
to
the
gua
or
it
may
just
send
it
to
the
ce
router,
because
that's
the
default
route
either
way
it
works
right
c,
router
next
slide,
the
c
router
would
send
it
to
host
one
or
or
maybe
the
internal
router
would
send
host
one
either
way.
This
communication
all
just
works
right.
T
T
Okay,
now
imagine
that
you
add
a
stub
router
to
this
network
and
the
stub
router
advertises
another
ula
on
the
home
network
link,
not
the
internal
network,
but
the
home
network
link.
Okay.
So
now
host
one
has
two
addresses:
it
has
the
gua
and
it
has
a
ula
next
slide.
T
T
Ce
router
knows
how
to
get
to
host
two
we're
assuming
so
it's
and
it
forwards
that
packet
to
the
internal
router
next
slide.
The
internal
router
sends
it
host
two.
That's
all
fine
next
slide
now.
I
think
I
skipped
a
step
here,
but
anyway,
the
the
host
two
sends
it
back
to
the
to
the
the
address
that
host
one
selected
next
slide
and
cu.
T
Router
very
sensibly
says
I
don't
know
what
that
address
is,
I
guess
I'll
just
use
the
default
route
and
it
sends
it
to
the
internet,
or
hopefully
it
filters
it,
but
let's
be
real
here.
So
so,
basically,
this
fails
and
now
all
of
a
sudden,
because
I've
added
this
new
router
that
we
see
on
the
sort
of
on
the
right
on
the
home
network,
because
I've
added
this
new
router,
which
is
doing
something
completely
legitimate.
It's
average
just
advertising
a
pio
option
with
a
new
ula
in
it.
T
Suddenly
the
whole
network
configuration
is
broken
so
next
slide.
T
So
so
the
problem
here,
if
we
want
to
agree
that
it's
a
problem
and
the
reason
I'm
presenting
this
is
because
I
want
you
guys
to
know
what
I
saw
and
I
ideally
this
working
group
would
decide
whether
they
think
this
is
a
problem
or
not
right.
So
so
the
problem
that
I
see
here
is
that,
because
we
have
two
dissimilar,
ulas
source
address,
selection
makes
a
decision
that
winds
up
breaking
things
and
the
decision
it
made
was
a
perfectly
sensible
decision.
T
T
Okay,
so
so
one
one
way
that
we
can
think
about
this
is
that
is
that
automatic
behavior
shouldn't
break
things.
So
so,
when
something
like
this
happens,
we
should
make
sure
that
it
works
correctly
and
the
way
that
we
would
make
sure
it
works
correctly.
One
one
way
would
be
to
have
routers
listen
to
ras,
which
I
suspect
would
get
a
big
boo.
T
The
other
way
is
to
to
have
source
address
selection,
not
treat
ulas
that
have
foreign
global
global
identifiers
as
being
close,
which
it
currently
does
just
because
of
of
shortest
match
right.
T
The
other
way
of
thinking
about
this
is
well.
This
was
a
manually
configured
network.
There
wasn't
any
automatic
protocol
happening
if
we'd
been
running
a
routing
protocol.
I
don't
think
this
would
have
happened
because,
presumably,
although
you
know
maybe
it
would
have
happened
because,
just
because
we're
running
a
routing
protocol
doesn't
mean
that
when
you
plug
another
network,
another
device
into
the
network,
it's
going
to
be
participating
in
that
routing
protocol.
T
Q
Michael
richardson,
can
you
go
back
a
bunch
of
slides?
I
don't
know
where,
but
before
the
ula
router
was
there,
maybe
it
doesn't
really
matter
in
the
end,
because
the
picture
is
good,
so
I
actually
don't
understand
how
it
worked
in
the
first
place.
Okay-
and
that's
that's
actually
actually,
I
think,
is
fundamental
because
because
I
don't
understand
how
it
worked
in
the
first
place,
I,
as
far
as
I
can
see
it
should
all
have
been
broken,
always
not
just
when
you
added
the
ula,
router,
okay
and-
and
I
think
it's
good.
Q
Q
I
think
it
is
68
the
the
the
cpe
ipv6
cpe
device
requirements:
okay,
okay,
because
it's
not
advertising
ula
on
the
home
network.
Q
T
Q
T
Okay,
that
there
that's
that's,
not
a
completely
invalid
statement
but
I'll
point
something
out
here,
which
is
if
I
were
a
naive
but
reasonably
knowledgeable
network
operator
of
my.
T
T
Okay,
so
so,
let's
say
let's
say
they
both
randomly
produce
one
well
now
and
then
suppose
I
configure
the
ce
router
to
forward
to
that.
Yo
to
that
address
is.
T
L
Q
Q
Q
An
address
in
it
because
it's
not
on
link,
etc
blah
blah
blah
right,
but
it
saw
that
yeah.
So
if
you
go
forward
olay,
I
think
you
need
to
add
to
like
three
or
something
forward
where
we
have
the
ula
router.
Q
Okay,
one
more
maybe.
Q
J
T
So
so
there's
two
ways
this
can
work.
One
is
the
cu.
Router
is
statically
configured
with
a
route
to
that
network
and
the
the
intermediate
router
which
has
disappeared
is
not
advertising
an
ra
right,
and
in
that
case
the
default
route
would
carry
it
to
the
cu
router.
So
your
router
would
know
that
it
needs
to
send
it
to
the
internal
router.
It.
Q
Is
is
good,
and
I
agree
with
you
that
that
shouldn't
necessarily
be
the
case
that
device
might
be
belong
to
the
isp.
It
has
no
management
interfaces.
That's
why
I
put
the
other
router
in
the
first
place.
I
want
to
do
something
you
know
whatever
so,
but
I
don't
understand
why
the
host
one
sent
it
to
the
ce
router
when,
in
the
previous
case
well
so.
Q
T
My
slide
and
not
actually
asking
a
real
question
here:
okay,
right
the
slide
this,
I
think
it
may
have
been
a
mistake
that
I
that
I
said
that
the
host
sent
it
to
the
cu
router.
I
don't
actually
know
the
detail
of
that,
but
there's
so
that's
why
I'm
saying
there's
two
ways
it
could
have
worked.
One
is
the
ce.
Router
knows
how
to
get
to
the
internal
network,
and
the
other
is
that
the
internal
network
router
is
advertising
the
network
either
way.
The
same
thing
happens.
Q
Okay,
that
that
isn't
caused
by
a
series
of
misconfigurations,
not
just
one
that
the
the
guy
manually
configured
that
because
you
asserted
you
did
it
correctly,
and
I
agree
with
you:
he
did
it
correctly.
Okay,
so
I'm
not
convinced
that
the
behavior
of
the
other
devices
on
the
network
is
correct.
Q
That's
why?
When
we
have
this
conversation,
I
tried
to
try
to
really
to
draw
your
diagram
so
that
I
could
be
really
sure
what
the
problem
was
right.
Okay-
and
I
I
think
I
think
I
think
actually
in
the
end,
I
don't
object
to
making
the
source
address
selection
rules
more
sophisticated,
because
I
think
that
they
cover
cases
that
are
harder
to
explain
with
one
diagram.
Q
I
just
think
that
we
have
to
articulate
why
we're
doing
it
better,
so
that-
and
this
this
case
has
to
be
clearly
in
clearly
a
problem
so
that
the
solution
is
clearly
motivated.
Otherwise,
people
are
going
to
come
back
and
say
well,
but
but
but
but
like
I'm
doing
right
now,
okay
and
and
that
also
may
mean
that
when
they
test
it,
their
code
in
the
field,
they'll
set
things
up
wrong.
V
Q
T
So
so
I
definitely
agree
that
we
should
get
the
get
the
the
problem
statement
more
crisp
and
I
apologize
for
for
for
being
unclear
on
the
slide
and.
Q
I
just
wanna
just
for
the
room
I
wanna
I
want.
I
know
what
ted
is
doing
with
the
ula
router
and
I
on
the
stub
network,
and
that's
really
really-
you
know,
I
think,
really
important,
but
that
also
could
be
another
ce
router,
yes,
whose
internet
link
is
broken
right
now
right
and
the
reason
I
had
two
of
them
in
the
first
place
is
because
there
are
both
of
them
are
not
that
reliable
right
and
I
know
recently
had
a
24
hour
outage
that
couldn't
control
right.
W
Okay,
we
have
two
more
people
in
the
queue
martin.
V
Hi,
I'm
martin.
I
also
want
to
say
that
it's
probably
a
configuration
issue,
because
the
the
sierra
should
have
a
ula,
and
probably
the
internal
network
should
be
part
of
the
some
bigger
ula
prefix.
T
Well
so
so
I
don't
think
that's
actually
an
interesting
criticism,
though,
because
this
is
a
perfectly
valid
configuration
for
a
network.
Whether
or
not
this
is
a
cu.
Router
is
not
really
the
point.
The
point
is
that
it's
entirely
possible
for
something
like
this
to
happen
and
if
it
does
happen,
do
we
care
if
the
network
breaks
or.
V
Not
yeah,
but
the
ceo
should,
as
stated
before,
should
have
a
ula
also
set
up
yeah.
T
V
Right
now,
I
don't
think
it's
something
that
should
happen
or
should
yeah.
T
Well,
so
what
I'm
saying
here
is
that
is
that
suppose
you
set
up
a
network
like
in
a
in
an
enterprise
setting
you
set
up
a
network
where
you
have
a
router.
You
have
an
internal
router,
everybody
configured
it
right.
Everybody
thought
they
were
doing
the
right
thing,
and
now
somebody
plugs
a
new
device
into
the
network,
and
the
network
suddenly
stops
working
is
that
okay.
V
T
B
R
Yeah
learns
a
clearly
I
mean
this
is
why
ula
is
a
terrible
idea
in
general,
but
I
think
so
I
don't.
To
be
honest,
I
don't
see
any
good
answer
here,
other
than
like
have
to
have
the
reader
listen
to
ras,
and
the
reason
for
that
is
if
we
change
the
the
source
address
selection
rules
to
basically
say
that
ula
is
scoped
to
slash
48.
R
First
of
all,
we'll
never
get
that
through,
because
people
believe
that
ulas
are
are
global,
but
they're
not
they're,
actually,
just
not
10
right
so
we'll
have
it
like
it'll,
be
impossible
to
actually
change
that,
but
even
if
we
did
we're
going
to
break
a
bunch
of
legitimate
use
cases
where
networks
have
separate
listing
qlas
and
they
rely
on
this
behavior
to
work.
So
that's,
I
think,
that's
an
onstarter.
Okay,.
V
R
R
When
then
we
need
other
routers
on
the
network
to
listen
to
that
right,
and
I
think
that's
the
only
thing-
and
it's
not
true
that
rooters
don't
listen
to
arrays,
because
the
c
router
at
the
top
there,
which
ostensibly
shouldn't
listen
to
our
a's,
got
its
default
route
via
varnra.
So
it
can't
be
like
that
that
sacred
that
it's
not
allowed
to
do
it
yeah
it's
very
difficult
to
implement,
though,
because
for
the
linux
boxes
that
these
things
definitely
generally
use
you,
you
have
no
easy
way
to
filter
out
certain
routes.
R
R
A
X
X
T
P
P
Nobody
can
hear
me
so
so
please
do
because
I
can
see
this
happening
on
our
network
and
again.
Another
dumb
enterprise
question
is
that
we
think
when
I
talk
to
people
that
want
to
maybe
do
this,
you
list
seem
to
be
important
to
them
and
there's
levels
of
assumed,
control
and
limitation
that
don't
seem
to
be
applying
here
so
yeah.
If
you
can
get
that
under
control,
that
would
be
fantastic
and
one
more
thing.
P
T
H
Jen
and
jen
lincoln,
so
I
still
need
to
get
my
head
around
how
exactly
this
happened,
but
I
don't
think
it's
a
configuration
issue.
I
think
what
we
did
in
here
is
is
trying
to
use
arrays
as
a
routine
protocol
like
we're
trying
to
use
nd
surrounding
protocol
right.
So
I
think
if
you
want
something
like
that
right,
we
need
to
explore
how
to
do
it
right,
but
I
don't
think
changing
default.
Address.
H
Selection
algorithm
is
the
right
way
to
fix
the
particular
topology,
because
I
can
come
up
with
five
other
different
cases
when
you
should
not
be
doing
this,
so
I
agree
this
need
to
be
solved.
I
don't
yet
know
how
maybe
array
is
the
right
way
of
doing
this?
Maybe
we
need
something
I
don't
know
like
what
home
net
was
doing
whatever,
but
I
I
disagree
that,
like
ula's
particular
case
is
the
right
way
of
doing
this,
because
actually
it
might
not
be
ula
necessary
right.
It
might
be
something
it
might
be
actually
legitimate.
T
B
E
E
V
E
A
A
So,
apologies
for
being.
Y
This
is
okay,
okay,
this
is
chen
chengwan.
You
can
call
me.
Godfrey
come
come
huawei
now.
This
document
is
cooperation
with
my
colleague
joe
tiernan,
so
this
document
just
talked
about
the
issue
that
is
the
past
m2
detection.
In
the
multi-pass
scenario.
Okay,
we
can
go
to
the
next
part.
Next
page,
okay
from
this
page,
you
can
see
when
the
left
part
you
can
see,
they
have
two
halves
from
r1
to
r4,
then
from
the
upper
player
you
can
see.
The
plasma
m2
should
be
long
about
1400
because
of
the
hash
mark.
Y
Algorithm
inside
of
the
rotor
are
fixed,
so
the
possibility
detected
packet
will
always
go
into
one
direction,
but
the
service
packet
with
a
different
port
different
ib
address.
Maybe
we
have
grocery
go
through
other
direction,
so
if
it
goes
through
r1,
r3
r4
and
the
packet
size
is
largely
larger
than
1300,
it
will
be
lost.
So
this
is,
I
think,
is
a
very
important
issue.
Y
So
the
idea
is
looks
like
the
red
part.
We
can
do
the
duplication
in
each
point
of
the
network
because
inside
the
router
we
can
know
how
many
load
balance
pass
inside
the
of
the
downstream.
Y
Y
Is
the
minimal
pass
m2
of
from
r1
to
r4?
So
you
can
record
this
inside
the
r1,
so
finally,
the
packet
will
be
cut
to
less
than
1
000
and
300..
Okay.
Next
next
page,
okay,
this
may
just
show
the
procedure
inside
of
the
network.
You
can
see
our
r1
find
the
two
paths
here.
It
will
copy
two
to
two
downstream
links.
After
then,
the
from
r2
r3.
We
will
do
the
same
thing
like
this
last.
Y
If
the
packet
could
arrive
the
r4,
it
will
reply
to
r1
each
each
each
packet
each
copy
and
at
last
r1
get
the
response
from
r4
it
can
calculate
which
one
is
the
minimum
minimum
one,
and
at
last
we
are
recording
in
memory
for
the
la
for
the
for
the
following
service
packet
to
do
the
slicing,
okay,
so
a
red
part,
just
some
consideration
about
how
to
modify
the
packed
inverter,
which
I
just
consider
to
use
the
hop.
Y
I
hope,
extension
header
about
the
request,
request
direction
and
I
use
the
dh
extension
head
for
the
response,
duration.
So
inside
of
the
packet
I
consider
to
use
the
m
m
tag
and
d
tag
to
identify
this
packet
is
just
for
pass
them
to
definition,
and
our
d
is
identified.
The
packet
is
due
to
the
duplication,
okay,
so
at
last
we
can
find
the
whole
procedure
inside
this
page.
Y
So
this
page
just
show
a
consolation
about
the
up
layer
which
which
protocol
could
send
this
synthesis
packet.
Here,
just
exam
example.
We
consider
use
the
keyword
light
to
trigger
the
passive
detection,
so
for
the
sender
to
know
which
one
is
the
which
packet
I
just
reply
for
which
one
reply
request
one
we
can
use
the
sixth
number
to
do
the
alignment
so
the
last
in
at
last,
in
the
receiver,
we
can
do
the
calculation
according
to
the
same
sequence,
number.
B
A
Can
we
just
let's
jump
ahead
to
the
nd1,
so
we
can
figure
out
the
the
slides
for
this
one?
Paulo,
do
you
want
to
go
ahead?
Thank
you.
A
Yes,
I
apologize
for
not
introducing
this
section,
but
this
is
the
new
work
that
is
not
been
discussed
on
the
list.
You
know
allowing
people
five
minutes
to
present
new
work.
Please
go
ahead.
Hold
up.
Thank.
Z
You
so
far,
I'm
presenting
on
behalf
of
the
people
you
see
listed
here
so
so.
Basically,
let
me
just
skip
the
details
and
background
of
this
work,
because
I
want
to
preserve
times
for
the
next
speakers.
But
basically
we
started
from,
let's
say
an
analysis
targeting
the
first
four
protocols.
Then
we
moved
to
neighbor
discovery
after
talking
with
a
few
operators,
and
the
idea
is
to
look
at
the
neighbor
discovery,
so
48,
61
and
62
to
see
if
those
standards
leave
room
for
solving
the
issues
caused
by
prefix
instability.
Z
Let
me
just
say,
as
the
chair
was
saying
before,
we
have
not
received
so
many
comments
from
the
mailing
list,
so
please
feel
free
to
comment
or
provide
criticism
to
our
work.
So
we
are
open
to
the
discussion
next
slide,
please
again
very
quickly.
So
there
are
options
to
solve
the
cases
of
prefix
invalidity
for
sure.
For
example,
you
can
enter
the
timers
defined
in
rfc
4861.
Z
Z
It
perfectly
works,
it's
defined,
if
I
recall
it
correctly
in
89
78.
Maybe
it's
a
possibility.
There
is
another
option,
so
the
option
we
choose
is
to
look
at
the
protocol
behavior
so
specifically
for
the
61
and
62
and
see
if
those
protocols
leave
room
to
let's
say
solve
the
corner
cases
where
invalidity
applies.
Z
So
if
you
can
do
okay,
don't
worry
is
a
very
complex
side,
but
I'm
not
going
to
discuss
it
at
the
moment,
so
feel
free
to
have
a
look
at
the
paper,
and
you
see
the
full
explanation.
But
basically
you
see,
on
the
left
hand,
side
the
solutions
that
we
have
identified
solve
those
corner
cases
where
invalidity
applies
and
on
the
right,
let's
say
it's
a
list
of
proposals
of
modifications
or
changes
to
the
existing
protocols.
Z
Let's
take
one
of
the
let's
say,
updates
introduced
by
version
zero.
Two
of
the
draft
section
6.6
you
see
we
have
a
thought
of
the
synchronization
flag
just
to
advise
the
to
let
a
router
advise
the
hosts
that
the
router
advertisement
is
complete.
So
all
the
pieces
of
information
needed
for
the
configuration
of
the
host
have
been
signaled
have
been
passed
on
to
the
host
in
doing
that
in
cases
of
misconfiguration
outage,
abrupt
reload.
Z
Sorry,
if
I've
been
very
fast,
but
that's
very
good-
that.
A
A
So
chen
now
we
found
your
presentation,
so
please
go
ahead.
AA
AA
AA
AA
AA
Increase
of
a
matka
tree
will
in-cap
the
package
in
my
class
routing
hybrid
for
each
of
its
laptop
and
extended
package
to
the
next
pop.
For
example.
Here
we
have
a
multiple
tree
from
ingress
e1
to
microsoft.
P1
the
multicast
voltage
header
will
include
the
subtree
from
micro,
p1
and
the
the
fields.
L
s,
l
m,
mb
and
b
in
the
mass
category
holder,
will
be
set
to
the
corresponding
value
for
the
link
from
english,
node
e1
to
laptop
v1
next
page.
AA
AA
AB
We
can
hear
you
good.
This
is
shooking
and
I'm
going
to
present
the
two
drafts
next,
please,
okay.
First
in
apn,
the
apn
information
will
be
encapsulated
in
the
outer
tunnel
header
and
when
the
tunnel
ends,
the
ap
information
will
be
removed
and
with
this
information
it
can
be
used
to
for
the
fine
granularity
traffic
steering
or
performance
measurement.
Next
piece.
AB
A
Yes,
she
was
almost
almost
done,
I
think
you
know
regarding
this
one.
We
certainly
have
to
be
something
we
discuss
on
the
list
and
with
our
ads.
Also
given
apns,
you
know
having
a
few
buffs
but
yeah
yeah.
This
is
something
the
chairs
and
ads
can
discuss
and
will
also
take
to
the
list.
I
think.
AB
I
Hello
next
slide,
this
is
presenting
on
behalf
of
the
two
co-authors
shown
on
the
first
slide.
So
this
is
another
proposal
for
a
native
ipv6
solution
for
point
to
multipoint
multicast
services,
stateless.
So
it's
meant
to
extend
the
existing
srv6
architecture
in
terminology
and
functionality.
I
The
target
solution
group
would
be
the
pim
working
group,
as
that
has
been.
You
know
the
group
to
outsource
multi-point
services
from
spring,
but
that
would
be
done
through
a
new
hop
by
hub
extension,
header,
which
we
typically
do
here
like
we
did
srh
here.
That's
why
I'm
here.
So
how
do
we
compare?
That
was
high
level
comparison
here,
so
in
srh,
the
extension
header
carries
the
segment
path
and
we
did
start
compression
of
that
header.
Eight
years
after
we
introduced
the
original
one
so
very
fast.
I
Maybe
we
can
do
it
even
faster
for
multicast
by
starting
with
a
compressed
header,
which
is
exactly
what
we
think
this
proposal
does
the
best
from
all
the
proposals
out
there
and
the
segment
by
segment
forwarding
would
be
exactly
the
same.
You
know
on
every
segment,
you're
rewriting
the
destination
address,
based
on
an
extraction
of
the
next
segment.
From
the
extension
header,
so
that's
logically
the
same,
but
in
the
recursive
bit
string
structure
we
would
obviously
extract
more
than
one
address,
because
we
still
want
to
do
replication.
I
That
was
the
whole
idea
of
multicast,
and
so
then,
on
the
egress
side
on
the
receivers,
we
probably
would
like
to
keep
the
same
tlvs
that
we
have
an
srh.
So
that's
another
tbd
item.
So
next
slide.
I
So
here
on
the
right
hand,
side
you
see
a
distribution
tree
that
is
really
encoded
in
the
compressed
addressing
structure.
So
most
simple
thing:
you're
on
the
first
router
a
on
top,
you
have
a
set
of
bits,
one
each
for
each
possible
adjacency,
like
next
top
that
you
have
and
then
you've
got
the
substructure
for
the
subtree
from
that
point
on
so
on,
every
segment
processing.
What
you
need
to
do
is
on
a
you
need
to
basically
take
the
red
subtree.
I
That's
your
new
active
address
for
the
next
hop
toward
b
and
then
for
the
copy
towards
c
it's
the
green
substructure.
So
the
question
is
a
little
bit.
How
do
we
do
the
rewrite?
There
are
a
couple
of
options.
We
could
simply
extract
rewrite,
make
it
shorter,
not
sure.
If
you
know
six
men
would
allow
that
we
can
try
to
adjust
a
single
segment
offset,
which
would
be
exactly
what
the
sequential
one
in
unicast
does.
I
But
if
we
actually
have
two
offsets
maybe
offset
and
length,
we
would
be
a
better
compress,
so
we're
pretty
open
in
how
that
could
be
done.
So
those,
I
think,
are
the
options
to
discuss
next
slide
yeah.
So
then,
also,
how
do
we
split
up
the
work
right?
So
the
compression
in
spring
is
now
done
by
sticking
within
128
bits,
so
it's
kind
of
a
strange
split
between
six
men
and
spring.
I
So
can
we
kind
of
proactively
for
for
this
approach,
figure
out
how
to
you
know,
split
extensibility
between
six
men
and
the
subject
matter,
working
group
like
pim
and
so
that
we
bake
in
the
extensibility
up
front,
much
better
yeah
and
maybe
even
have
multiple
options,
because,
seemingly,
depending
on
what
type
of
trees
you
want,
there
may
be
different
compression
options
that
we
can
have.
So
that's
pretty
high
level.
So,
if
you're
interested
in
the
topic
next
slide,
please
come
to
pim
thursday
if
you're
interested
in
this.
I
Otherwise,
of
course,
all
these
questions,
I
was
raising
against
the
six-man
specific
things.
I'd
love
to
hear
comments
about
those
on
the
list
and
I'll
re-trigger
that
discussion
here.
Thank
you.
A
Thanks
a
lot
trolls-
and
that
brings
us
to
the
end
of
the
session
here
in
vienna
and
remote
feel
free
to
send
us
feedback
on
how
you
thought
the
hybrid
setup
worked.
I
certainly
noticed
that
there
was
a
lot
more
activity
in
the
room.
I
think
with
questions
and
discussion
than
what
we
had
remotely,
even
though
we
it
was
a
one-fifth
of
the
people
here
in
the
room,
four-fifths
remote,
we
don't
know
quite
yet
what
we'll
do
for
philadelphia.
A
Bob
is
out
sailing
to
hawaii,
I'm
out
hiking
to
mexico.
A
So
we'll
have
a
discussion
with
the
80s
and
the
chairs
for
that,
but
thanks
a
lot
guys.
Yes
well
do.