►
From YouTube: IETF114 6MAN 20220727 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
B
B
So
housekeeping,
I
was
going
to
say
please
very
much,
but
everyone
do
an
attenuation
great.
So
please,
if
you're,
joining
the
queue
being
in
the
room,
please
still
use
on-site
tool
because
it
would
make
my
life
much
much
easier
in
terms
of
cue
management
and
state.
Your
name
at
the
microphone
david
who
is
taking
minutes
will
greatly
appreciate
that
try
to
leave
the
view
when
done.
B
B
So
yeah,
yes,
yeah
seri,
confirmed,
looks
like
individual
messages.
Work
in
the
me
take
a
chat,
but
you
cannot
send
messages
to
the
group
chat
thanks
bob.
So
here
is
a
link
to
the
agenda,
which
has
all
other
useful
links
there
like
to
the
slides
meeting,
materials
chat
and
so
on
so
agenda
busy
one
today,
so
we
have
approximately
65
minutes
for
working
group
documents.
B
We
have
four
drafts,
then
we
are
going
to
spend
another
45
minutes
on
individual
documents
and
we
also
have
some
time
permitting
with
no
time
allocated.
But
I
don't
know,
maybe
we
can
done
with
our
working
group
business
so
quickly,
so
we
can
have
some
backup
presentations
yeah.
We
seriously.
We
got
like
about
hour
and
a
half
more
requests
that
we
can
accommodate.
B
We
have
about
one
tricky
document
and
I'll
have
another
slide
just
for
that
about
alternate
marking
method,
and
there
is
a
document
which
makes
me
feel
guilty
because
I'm
still
working
on
the
write-up,
it's
a
six
eight,
seventy
four
bits.
So
it's
hopefully
will
be
out
for
ad
review
later
this
week
and
yeah
and,
as
I
said,
we
have
five
working
group
documents.
Four
of
them
will
be
presented
today
and
one
which
is
actually
dangerously
close
to
get
expired,
but
I
have
not
heard
from
authors
here
so
the
last
of
the
chair
slide.
B
If
you
didn't
pay
attention
to
the
mailing
list,
we
had
a
interesting
case
when
a
document
was
adopted
by
the
working
group
went
through
the
working
group.
Last
call
and
the
etf
last
call
and
was
reviewed
by
asg,
but
then
quite
late,
an
apr
disclosure
was
made
by
one
of
the
authors
and
some
requests
were
made.
Some
comments
were
made
about,
shall
we
consider
it
as
a
significant
change
to
the
document,
or
at
least
something
which
working
group
needs
to
be
aware
of
and
decide
if
we
still
have
consensus
on
proceeding
with
the
document.
B
B
B
B
D
Thank
you
it's
my
really.
My
only
slide
really
but
I'll
try
to
keep
this
very
short.
So
this
draft
has
been
adopted
like
at
the
last
itf
meeting
and
confirmed
on
the
list
after
and
there
were
a
bunch
of
comments,
so
some
of
them
just
editorial
there's
also
some
substantive
comments
and
they've
all
been
addressed
in
the
zero
one
draft.
D
Who
kind
of
I
tried
on
this.
So
I
can
come
up
with
the
like
right
change
there.
It's
very
small
change,
but
it's
very
important
because
it
clarifies
where
the
space
comes
out
of
and
then
we
can
define
the
properties
of
the
space
and
another
thing
is
like
from
darren's,
because
I
was
talking
about
stuff
changing
on
the
fly
right
on
in
transit
and
one
key
thing
was
like
it
only
changes
at
what
could
be
a
segment
endpoint.
So
it
doesn't
change
really
nearly
at
any
transit
point.
D
It
started
with
like
a
request
coming
from
spring
to
six
man
right,
saying:
hey,
write
up
like
this
thing,
and
so
we've
done
that
and
as
a
result
of
writing
this
stuff
up,
there's
some
actions
that
need
to
be
performed
in
spring
at
some
future
point.
So
we
need
to
kind
of
close
the
loop
on
this
tell
spring
that
hey,
you
asked
us
to
do
this,
we've
done
it
and
by
the
way,
there's
also
other
stuff
for
you
to
do
right
as
a
result
of
this,
but
that's
something
we
probably
need
to
craft.
D
An
official
message
like
jen
bob
and
oolani
comes
back
to
get
that
message
out
to
spring
to
kind
of
close
the
loop
on
this.
That's
pretty
much
what's
in
there.
So
there's
like
no
pending
comments
on
this.
So
if
you
have
any
comments
like,
please
feel
free
to
bring
them
up
here
or
on
the
mailing
list
after
and
I'll
be
like
very,
very
quick
to
kind
of
make
the
changes
that
is
required
and
let's
go
forward
with
it.
So
next
slide
jen.
D
Yep,
so
if,
like
you
know,
something
is
going
to
hold
unless
something
holds
it
up
like
it'll,
be,
I
think
the
document
is
ready
for
working
with
last
call,
so
I
would
officially
request
the
chairs
to
go
for,
like
working
group
last
call
on
this
pending
some
hold
down
timer
after
the
meeting,
and
also
to
write
up
something
towards
the
spring
working
group.
D
E
It
was
just
off
yeah
airplane,
so
I
guess
I
was
gonna,
try
to
channel
andrew
who's,
not
here
and
ask
about
whether
or
not
the
what
people
think
about
the
slash
16
being
a
must
not
in
the
in
the
dfc.
D
Okay,
so
if
you
look
at
the
draft
today
right,
so
the
idea
is
like
so
one
of
the
actions
that's
for
spring.
So
if
you
can
go
back
to
the
previous
slide,
right
is
to
do
the
operational
guidelines
for
the
16
as
well.
Right
like
that,
like
spring
needs
to
develop.
So
the
idea
would
be
some
operators
who
are
deploying
this
would
write
that
up
and
I'm
perfectly
fine
with
that
right,
but
that's.
I
think
that
would
be
a
fine
thing
to
write
somewhere
right.
Does
that
belong
in
this
document?
D
I
don't
know
right
like
that's.
I
think
it's
open
to
discussion.
So
if
you
want
to
put
that
in
here,
that's
fine
and
if
it's
going
to
go
into
an
operational
guideline
document,
that's
fine
too
right,
because
the
goal
is
for
somebody
to
be
able
to
filter
it
right
like
so,
and
if
you
need
like
a
stronger
recommendation
somewhere,
that's
fine
and
like
yeah,
so
it's
andros
like
puts
that
up.
I
think
we
can
certainly
work
on
where
we
need
to
put
it
in.
B
D
B
F
Hi
I
get
up
here
we
go
what.
B
F
Hi,
so
this
talk
is
traditionally
done
by
bob
and
I,
as
we
move
between
a
square
on
the
ground
and
the
itf,
both
was
the
remote
this
time.
So
we'll
do
our
best
to
be
brief,
but
we'd
like
to
tell
you
about
the
updates:
we've
done
to
the
hot,
buy
options,
processing
procedures.
F
Bob
will
chip
in
as
he
needs
to
so.
The
previous
version
was
working
group,
zero,
zero
and
we
were
working
our
way
through
a
large
number
of
adoption,
questions,
comments
and
other
feedback,
and
we
made
a
number
of
updates
that
are
present
in
the
zero
one
draft.
F
So
I
think
that
that
is
the
summary
of
what
we
changed.
Is
that
okay?
Bob?
Yes,
so
I
guess
the
other
thing
we
should
say
is
we
have
an
issue
tracker,
it's
the
six
six-man
tracker
and
we're
trying
to
recall
issues
for
this
draft.
F
I
probably
was
difficult
to
judge
that
at
the
beginning.
Now
it's
maturing
you
might
want
to
try
and
help
us
figure
this
out.
Should
it
be
a
bcp?
Should
it
do
requirements
or
simply
be
informational,
might
be
good
as
a
bcp?
Perhaps
I
don't
know-
and
please
tell
us,
because
we
really
would
like
to
know
what
is
best
issues.
9
and
15
relate
to
router
alert
or
the
router
alert
option,
which
was
mentioned
a
number
of
times.
It
is
a
hotbar
hop
option
and
we're
expecting
this
to
be
titled
by
another.
F
It's
that
draft
in
six
months,
so
hopefully
we
can
clear
this
issue
by
saying
another
draft
we'll
talk
about
this
now
the
most
exciting
thing
of
all.
What
do
we
call
it
when
a
router
processes,
a
hot
bypop
option
as
part
of
its
forwarding,
it
could
be
processed,
maybe
in
software
it
could
be
processed
in
an
asic.
F
It
could
be
processed
in
some
offload
or
machine
engine.
We
previously
called
this
slow
path
and
fast
path.
People
hated
that
because
they
said
it
referred
to
a
router
design
rather
than
a
a
way
of
processing.
So
we
now
talk
about
processing
extension
headers,
particularly
hot,
by
hop
headers
at
full
processing
speed.
F
We
think
that
resolves
the
issue
of
talking
about
slow
path
and
fast
path,
but
to
believe
we
solved
it.
You'd
have
to
read
the
text
and
tell
us
that
you
like
what
we've
written
I'll
talk
briefly
about
number
eight,
which
is
lack
of
graceful
handling
of
malformed
extension
headers.
F
We
think
this
is
a
security
issue,
we'd
like
to
add
some
text
and
security
considerations
for
this.
If
you
care
about
malformed
extension
headers,
please
help
us
write
that
text.
We
think
it's
more
or
less
the
same
as
any
other
malformed
header,
and
if
you
write
bad
router
chord,
then
your
rotators
will
either
crash
or
behave
badly.
If
you
write
good
writer
chord
and
protect
the
code
that
you
don't
have,
a
problem
doesn't
seem
like
something
new
for
hot
by
hop
options.
F
Rsc
9098
talks
about
processing
the
payloads
of
ipv6
packets
as
you
forward
them
and
again,
if
you're
interested
in
this
topic
and
think,
there's
good
text
on
that.
Please
tell
us
doesn't
particularly
relate
to
hotbackup
options,
and
it
may
perhaps
be
something
to
mention
in
security
considerations,
since
this
is
commonly
done
by
firewalls
and
other
middle
boxes.
F
We
don't
have
any
asic
experience.
Well,
I
don't,
I
don't
think
bob
has
either.
So
if
you
know
about
what
asics
are
actually
deployed
in
new
equipment
and
want
to
talk
to
us,
please
do
we
would
love
to
hear
you.
We
will
be
influenced
by
people
who
tell
us
that
they
are
deploying
things
at
scale
that
do
things
that
need
things
to
happen.
So
talk
to
us,
please,
if
you're
thinking
about
having
extension,
header
support
for
hot
options,
we'd
love
to
hear
from
you
and
the
last
one
was
a
comment.
F
F
F
F
We
don't
see
this
as
a
particular
issue.
If
you
think
it
is,
please
talk
to
us.
So
what
are
the
next
steps?
Well,
if
we've
actually
resolved
the
issues
we've
talked
about,
then
our
document
is
either
ready
to
decide
it's
standard
status
and
publish
as
a
buyer,
working
group
last
call
or
it's
time
for
people
to
tell
us
that
there
are
more
issues
with
it
either
way.
We're
looking
for
reviews
of
our
document
to
revise
our
id
and
I
think
that's
our
slide
deck
any
comments
or
questions.
G
I
haven't
looked
at
the
document
for
the
last
something
you
know
months,
but
if
you
need
a
review,
I
can
volunteer
to
do
a
you
know.
Another
review
of
the
document.
F
C
Yeah,
I
think
I
would
add
particularly
you
know
if
you
see
an
issue
in
this
document,
please
suggest
text
how
to
resolve
it.
That's
very
helpful
to
us.
B
G
Okay,
so
hi
all
this
is
fernando
bond
I'll,
be
doing
the
presentation
on
the
document
improving
the
robustness
of
stateless
address,
auto
configuration
to
flash
renumbering
events
next
slide.
Please.
G
So
super
you
know
short
background.
Essentially
this
is
a
topic
that
we
have
been
working
on
for
you
know
a
couple
of
years
now
there
are
a
few
documents
that
some
of
these
work
was
has
been
carried
out
in
you
know
in
the
b6
group,
so
we
have
rfc
8978,
which
is
essentially
the
problem
statement
document.
G
Then
we
also
produce
rfc
1996,
which
is
recommendations
for
customer
edge
routers.
And
finally,
this
is
you
know
the
last
remaining
item,
this
document
that
I'll
be
presenting
today,
which
is
protocol
improvements
to
actually
you
know,
improve
the
the
handling
of
flash
renumbering
events
next
slide.
G
Okay,
so
a
few
comments
about
the
progress
on
on
this
idea.
So
essentially,
what
we
have
been
doing
is,
you
know,
incorporate
the
contents
of
the
individual.
Submission
first
comment
is
that
I
recently
last
month
or
so
called
the
six
month
working
group
about
two
specific
items.
G
We
have
received
some
comments
on
those,
but
if,
for
some
reason
you
have
missed
them,
please
you
know
feel
free.
I
will
send
an
email
to
the
mailing
list
to
you
know
to
highlight
the
the
threads.
So
if
you
have
comments
on
those
two
topics,
please
do
send
your
comments
so
that
we
can
address
them.
G
G
What
we
have
done
is
to
produce
a,
I
would
say,
a
simpler
and
more
robust
algorithm
from
what
we
had
in
the
individual
submission.
And
you
know
the
goal
of
this
presentation
is
essentially
to
to
describe
the
you
know
the
algorithm.
G
You
know
from
a
conceptual
level-
and
you
know
afterwards
I'll
be
sending
the
draft
text
to
the
mailing
list
for
you
specific
review
of
of
the
text.
Okay,
next
slide,
please.
G
So,
what's
the
idea-
and
actually
this
like
this
slide-
makes
it
look
like
more
complex
than
it?
Actually
so,
what's
the
basic
idea
of
this
algorithm,
the
the
improved
algorithm
that
we
have
produced?
So
the
idea
is
super
simple:
if
your
host
receives
an
array
that
contains
missing
information,
so
it's
lacking
information
that
was
received
beforehand.
G
What
we
want
to
do
is
to
pull
the
corresponding
router
with
a
unicast
router
solicitation
to
double
check.
If
the
information
is
there
or
not,
okay,
then,
based
on
the
result
of
that,
we
can
decide
whether
you
know
yeah.
The
information
was
there
and
we
can,
you
know,
keep
the
information
or
actually
no,
the
information
has
become
stale,
so
we
should,
you
know,
get
rid
of
it.
This
slide
just
makes
the
you
know
the
process
or
or
the
algorithm
more.
It
just
addresses
details.
G
So
we
start
at
the
beginning
when
an
array
is
received.
Okay,
we
are
considering
arrays
that
are
missing
information
that
have
been
previously
received
from
this
router
okay.
So
if
we
have
one
of
those
cases,
then
we
will
wait
for
some
time.
This
would
be
like
a
couple
of
seconds
because
it
could
be
in
theory,
doesn't
happen
in
practice,
but
could
happen
in
theory
that
the
router
is
splitting
the
slack
information
into
multiple
packets.
So
we
will
wait
for
some
time
here.
G
Then,
if
that
information
is
not
hasn't
been
received,
what
we
do
is
just
wait:
a
random
small
random
period
of
time,
that's
just
to
avoid
a
lot
of
host
on
the
same
network
to
pull
the
router
at
the
same
time.
That's
the
the
random
way
that
we
have
there
and
then
what
we
do
is
essentially
just
pull
the
local
router
with
a
unicast
router
solicitation.
G
What
we
do,
what
we
do
by
default
in
the
algorithm
is
just
pull
once,
but
it's
you
know
up
to
the
implementation.
You
could
you
know
pull
pull
multiple
times,
send
an
arrays.
You
know
if
you
don't
get
what
you
want
you
pull
again
and
so
on.
If,
when
we
get
to
the
arrays
rs
rs
proof
timeout
here
you
know,
by
the
end
of
the
yellow
graphic
we
haven't,
received
the
missing
information
from
the
router.
So
that
means
that
the
information
has
become
stale.
G
Okay
and
what
we
do
is
essentially
remove
that
stale
data,
so
in
the
next
slides.
What
I
have
is
essentially,
like
you
know
the
same
graphic
but
an
analysis
of
your
typical
scenarios.
So
next
slide
please.
So
this
is
the
most
usual
case.
You
know
nothing
bad
is
going
on,
so
we
just
receive
an
array
with
all
the
same
information
that
we
had
received
before:
okay,
everything's,
okay,
there's
nothing
to
do,
there's
no
missing
information,
nothing
to
trigger
there.
All
information
is
fresh
next
slide.
G
Then
we
have
the
case
of
fresh
data
but
with
the
corner
case,
theoretical
corner
case,
where
the
router
splits
the
slack
information
into
multiple
packets.
Again,
I've
never
seen
that,
and
I
don't
know
anyone
that
has
seen
this
in
practice,
but
in
theory
the
specs
allow
it.
So
what
we
have
is
we
receive
an
array,
the
first
one,
okay,
that
doesn't
contain
all
the
information
that
we
have
previously
received
from
this
router.
Okay,
so
we
wait
for
some.
G
We
enter
this
algorithm
and
the
algorithm
says:
okay
before
you
not
pull
the
router
before
trying
to
pull
the
router
just
wait
for
some
time,
because
the
information
might
arrive
in
a
separate
array.
So
we
wait
for
some
time
and
we
indeed
receive
the
array
with
the
missing
data.
Okay,
so
again,
all
the
information
is
fresh.
There's
nothing
to
do
about
it.
We
are
okay,
that's
why
we
have
the
you
know
the
green
stuff
in
there
next
slide.
Please.
G
We
have
another,
this
is
again
corner
case.
We
are
just
trying
to
be
super
robust.
We
have
again
the
corner
case
where
we
have
a
router
that
is
spreading
the
slack
information
into
multiple
arrays
and
there's
also
packet
loss.
Okay,
so
some
of
those
arrays
with
partial
information
might
be
lost.
So
we
start
here
with
an
array
that
contains
partial
information,
and
when
we
receive
that
array
we
say:
okay,
well,
partial
information.
We
need
to
double
check
if
the
rest
of
the
information
is
there
or
not.
We
wait
for
some
time.
G
We
wait
for
the
missing
data,
but
one
of
the
other
arrays
just
got
lost
okay,
so
what
we
do
is
we
do
a
random
wait.
This
is
just
a
few
seconds
random
value
of
a
few
seconds,
and
then
we
decide
to
prove
the
router
with
a
unicast
router
solicitation.
This
is
when
we
enter
the
you
know,
yellow
stuff
in
here,
so
we
send
the
proof
to
the
router,
the
router
responds
and
we
do
receive
the
missing
information.
So
all
the
information
has
been
refreshed.
G
Nothing
else
to
do.
We
are
okay,
we
entered
the
green
stuff
again
and
last
slide.
The
next
slide.
Sorry
well,
next
slide
is
exactly
the
same,
so
we
receive
an
array
with
partial
information.
We
wait
some
time
to
receive
the
missing
data.
We
don't
receive
it.
So
we
say
okay
time,
to
pull
the
router
to
see.
If
the
information
is
there,
we
do
pull
the
router,
but
we
never
receive
that
missing
information.
G
So
after
pulling
the
router
in
our
case,
we
pull
the
rotor
just
once
a
single
rs.
But
it's
you
know
it's
it's
configurable,
you
could.
You
know
request
that
host
pulls
the
rotor
more
than
once.
Once
we
get
the
response
from
the
router
from
the
advertising
router.
If
the
information
is
not
there,
we
say:
okay,
we
hadn't
received
the
information
before
we
pulled
the
router.
The
router
is
still
not
sending
that
information.
We
consider
the
information
has
become
stale.
So
we
we
disassociate
that
information
with
the
router
okay
next
slide.
G
So
that's
the
algorithm
it
it's
it's
it's
simpler
and
improve
over
the
version
that
we
had
for
at
least
two
reasons.
Two
reasons.
First,
one
is
that
in
the
previous
algorithm
we
were,
you
know
we
had
to
modify.
You
know
the
timers,
for
example,
of
the
options
which
that
made
the
you
know
the
algorithm
more
complex.
That's
one
thing,
and
the
second
thing
is
that
the
principle
here
is
super
simple.
G
If
there's
information
that
is
missing
what
we
do,
we
send
we
pull
the
router
with
a
unicast,
rotor
solicitation
and
wait
what
comes
back
if
the
information
doesn't
come
back.
Well,
it's
not
there,
and
so
the
principle
is
is
simple
and
obviously
more
robust
than
the
previous
algorithm.
G
H
Yep
tommaso
piccolo
university
of
florence
just
a
quick
question:
what,
if
the
information
keep
being
sent
and
behind
lost?
I
mean
suppose
that
super
corner
k
is
of
a
router
that
sends
the
array
with
two
or
more
packets
and
it
keeps
sending
the
information
upon
a
ruler,
solicitation,
unicast
and
it
keeps
being
lost.
Sometimes,
I
think
that
we
need
a
number
of
retries
time
after
which
it
is
given
up
altogether.
G
Yeah,
so
the
algorithm
does
consider
you
know
that
of
the
number
of
probes
to
be
configurable,
so
I
would
say
that
you
know
slack
anyway
assumes
that
you
know
if
off
the
top
of
my
head,
like
you
know
three
retransmissions
and
you
know
if,
after
you
retransmit
three
times
things,
don't
work
well,
slug
will
break
anyway,
but
so,
if
we
wanted
to
fail
on
the
safe
side,
we
could
you
know,
instead
of
defaulting
to
a
single
proof,
we
could
def,
we
could
default
to
three.
That's
that's
in
the
document
already.
G
G
No
because
you
do
this
on
a
pair
router
basis,
so
thinking
from
a
multi-router
multi-prefix
point
of
view.
What
you
do
is
you
don't
remove
the
information
altogether,
but
you
disassociate
that
information
with
the
that
specific
advertising
router.
If
there's
any
other
system
that
you
know
is
advertising
the
same
information,
it's
okay,
so
you
will
keep
that
other
part.
It's
just
disassociating
the
information
with
that
particular
router,
the
only
case
in
which
you
end
up
completely
removing
the
information.
B
I
actually
yeah
no
heads
just
dragging
cover
just
curious.
Yes,
so
I
also
was
going
to
ask
was
timmy
asked
about
sending?
Maybe
all
routers
not
unicast,
because
it
might
be
a
corner
case
when
you
link
local
address
of
one
of
the
routers
changed,
but
the
information
pios
advertised
by
the
trouser
is
still
the
same.
B
G
But
my
expect
my
at
least
my
expectation
would
be
that
you
know
when,
and
that
is
according
to
4861,
that
if
you
know
the
the
router,
for
example,
change
the
address
and
it
becomes
a
you
know,
an
advert
advertising
router.
It
will
multicast
the
information
and
actually
a
couple
of
times
from
you
know.
As
soon
as
it
you
know,
joins
the
network,
so
you
should
have
received
that
information
too.
B
Okay
and
the
second
question,
I'm
just
curious,
so
remind
me
when
you
say
you
remove
this:
the
associate
outdated
information
you
mean
make
the
address
invalid
or
duplicated.
G
So
in
this
case,
what
we
do
is,
first
of
all,
we
we
don't
say
we
eliminate
the
information.
So
what
we
say
is
we
don't
consider
that
this
information
has
been
advertised
by
that
particular
router.
Now,
assuming
that
a
single
router
was
advertising,
the
information
to
you
know
to
go
back
to
your
case,
what
we
do
is
we
would
end
up
removing
the
addresses
okay,
because
we
are
proving
the
router
okay.
G
Yes,
but
I
would
say
that
that
is
a
side
effect
when
you
are
using
essentially
provider
dependent
prefixes
for
local
connections.
So
I
would
say:
that's
that's
the
case
and
the
reason
for
which
we,
it's
a
valid
point
to
you
know,
to
re-evaluate
the
reason
for
which
we
are
we
suggest
to
remove.
The
addresses
is
that
the
router
is
responding,
so
it's
not
that
it's
dead,
it's
responding
and
not
sending
the
prefix
anymore.
So
otherwise
you
would
be
dragging
information
that
has
become
stale.
G
B
G
C
G
So
it
is
included,
so
we
haven't
seen
that
case
in
practice,
but
still
the
algorithm
accommodates
that
case.
So
the
algorithm
is
robust
in
that
case.
So
we
don't
react
right
away
when
you
receive
an
array
with
partial
information,
but
actually
wait
for
other
possible
arrays
containing
the
missing
information
to
arrive.
B
G
E
Yes,
so
I
assume
this
is
like
section
4.5
that
says:
tbd
yeah
yeah.
Can
I
ask
whether
your
proposed
text
is
largely
narrative
or
will
it
be
framed
in
the
in
in
the
will
it
be
framed
as
a
state
machine,
particularly
the
state
machine
that
needs
to
be
implemented
to
keep.
G
B
B
Okay,
you
don't
would
you
are
going
to
share
the
slides,
so
you
like
me
to
present.
B
B
J
Yeah,
okay,
so
hello,
everyone!
This
is
from
huawei,
and
I'm
going
to
give
an
update
about
this
draft
on
carrying
the
waiting
information
in
the
ipv56
extension
header
on
behalf
of
these
co-authors.
J
J
We
received
comments
during
and
after
the
adoption
call,
and
this
shows
that
there
is
interest
to
make
this
option
generic
and
more
flexible.
So,
in
the
last
item
meeting
the
authors
presented
some
considerations
about
the
extensibility
of
this
fitting
option,
both
in
the
semantics
and
also
the
format.
J
So
in
this
zero
one
version,
it
reflects
the
update
to
the
format
of
the
vtn
option,
while
the
generalization
of
the
semantics
may
need
some
further
discussion
in
the
working
group.
Okay
next
slide,
please.
J
Here
we
show
the
updated
beta
option
format.
Basically,
it
consists
of
the
option,
type
option,
data
lens
and
the
flags
field,
the
result
reserved
field
and
between
resource
id
field
in
the
option
type
field.
The
first
two
bits
are
set
to
zero
so
that
it
is
ignored
when
it
is
not
recognized
in
the
packet
forwarding
and
it
is
not-
should
not
be
changed
in
the
in
the
packet
forwarding
the
option
data
length
is
set
to
eight
and
it
reflects
the
length
of
the
data
fields.
J
Here
we
introduce
a
flux
field
and
one
flag
is
defined.
In
this
version.
It's
called
a
strict
match,
which
means
that
when
the
packet
has
its
f
s
flat
set,
it
must
match
with
the
vtn
a
resource
id
which
is
configured
on
the
outgoing
interface
for
target
forwarding.
Otherwise,
it
package
should
be
dropped
and
if
the
s
flag
is
set
to
zero,
it
means
that
when,
if
there's
no
matching
of
the
vtn
resource
id
and
outgoing
interface,
the
packet
will
be
forwarded
using
the
default
set
of
resource
on
the
interface.
J
The
reserve
field
is
live
for
the
future
extensions
to
this
option
and
the
video
resource
id
is
for
octet
identifier
of
the
set
of
resources
allocated
to
over
here.
So
with
this
format,
we
kept
the
updating
option
with
a
fixed
lens
and
also
lift
rooms
for
the
future
extensions.
J
J
J
We
also
update
the
forwarding
behaviors,
which
takes
the
s-flag
the
value
of
the
s-flag
into
consideration.
There
are
also
some
editorial
changes
in
this
version.
Okay,
next
page,
please,
okay,
here
are
the
next
steps.
We
would
like
to
collect
the
further
feedback
from
the
working
group
and,
if
there's
interest,
we
could
continue
to
have
the
further
discussion
about
the
semantics
generalization.
K
J
Yes,
that's
for
your
comments.
I
will
notice
your
suggestion
about
a
variable
lens.
Well,
we
also
see
that
in
the
harbor
hub
processing
draft
it
recommends
or
it
the
rule
in
that
draft
is
that
we
should
use
as
fixed
lens
options
for
hubba
hub
header.
So
maybe
we
need
to
consider
whether
we
need
to
align
with
the
rules
in
that
document.
J
But
I
agree:
we
need
to
make
it
extensible,
that's
why
we
introduce
some
new
fields,
and
maybe
I'm
not
limited
to
the
natural
slicing
use
case.
That
is
for
sure.
L
Joel
halpern
with
erickson,
I
think
that
your
intention
in
the
wording
was
to
meet
some
requirements
that
you
and
I
have
discussed,
and
the
working
group
has
discussed
in
the
past,
but
the
wording
left
me
a
little
confused.
You
sometimes
talk
about
this
field
as
a
vtn
id.
L
J
It
says
for
a
comment
so
yeah.
I
agree
that
we
have
been
discussed
about
the
semantics
of
this
id
and
I
we
have
made
it
made
it
clear
that
it
is
the
resource
id
within
resource
id
or
we
may
call
it
an
rpid
for
in
the
context
of
slicing.
J
But
you
may
also
know
that.
There's
the
suggestion
about
the
generalization
of
this
semantics
of
this
option
or
the
id
so
may
we
may.
We
are
open
to
some
further
comments
about
the
generalization,
and
maybe
it
is
not
reflected
in
this
current
version,
but
still
using
the
media
resource
id
here.
J
I
B
I
M
Okay,
hello,
everyone-
this
is
xiaomi
from
zte
speaking.
This
presentation
is
on
icmp
v6
echo
request
reply
for
enabled
in-situ
om
capabilities.
M
M
This
draft
defines
two
new
icmpb6
messages
called
iom,
echo
request
and
iom
echo
reply
for
icmp
v6
iom
anchor
reply.
Six
iom
capabilities
objects
are
defined
there.
I
am
pre
allocated
tracing
capabilities,
object,
iom
incremental
tracing
capabilities,
object,
iom
approval,
transit
capabilities
object,
I
am
edge
to
edge
capability
subject.
M
The
zero
zero
version
of
this
job,
too
was
presented
at
itaf112.
Some
good
discussions
happened
there
here
with
just
a
few
updates
since
then.
Firstly,
one
more
example
where
two
namespace
ids
are
deployed
was
added.
M
M
N
C
In
the
in
the
chat,
eric
asked
whether
noted
information
queries
could
be
used
for
this.
K
Irrigating
cisco
know
hat,
and
thank
you
both
for
point
printing.
The
point
I'm
a
little
bit
annoyed
by
using
an
echo
request
reply
for
such
information.
M
I
is
this
your
intention.
K
M
K
C
B
M
M
This
is
the
problem
statement
of
this
chart
in
srv6
when
the
last
seat
is
a
compressed
one.
The
upper
layer
checks,
some
computation
rule,
defining
rfc8200
doesn't
apply
anymore
here.
We
provide
two
examples
when
obviously
8200
doesn't
apply.
The
first
example
is
the
next
cc.
The
flavor
of
compressed
seed,
multiple
seeds
may
be
carried
in
the
ipv6
destination
address
at
the
same
time.
M
M
A
Yeah
darren
duke
cisco
systems,
the
sr
source
knows
the
destination,
whether
it's
compressed
or
uncompressed
doesn't
matter.
By
the
time
the
packet
reaches
the
destination
node.
The
destination
address
is
in
the
destination
address
field
and
is
used
for
upper
header
upper
layer.
Header
check
some
calculation.
I
don't
think
that
is,
there's
any
need
for
this
draft.
M
You
know
this
job
to
in
this
job
to
we
have
the
problem
statement
now,
that's
mainly
because
in
rbc
8200
it's
assumed
that
the
last
seat
is
a
180
bit
ipv6
address.
So
at
the
originating
node.
We
need
to
have
that
kind
of
last
seat.
Otherwise
the
checksum
calculate
calculation
is
not
applied.
O
K
B
B
P
P
We
decide
then,
to
let's
say
now
around
the
scope
of
that
old
draft
and
move
to
this
one,
which
is
basically
the
role
of
neighbor
discovery
in
multi-homing
multi-prefix
networks.
Next
slide,
please!
P
Well,
there
is
no
need
to
discuss
what
the
multi-homie
multi
prefix
network
is
a.
There
is
one
example
here
in
the
picture.
You
see
basically
something
that
sometimes
is
used
for
small
offices,
home
offices.
I
would
say
this
is
specifically
useful
for
and
say
smaller
medium
enterprises.
You
have,
for
example,
two
routers.
Two
c
is
connected
to
two
different
providers.
The
reason
for
that
is
to
let's
say,
provide
resilience
or,
let's
say,
support,
load,
balancing
or
whatever
other
applications
that
are
useful
for
an
enterprise.
P
The
topology,
the
architecture
of
the
internal
network
may
be
quite
complex,
so
this
is
to
say
the
main
reason.
There
is
a
lot
of
literature
that
has
already
described
these
cases
so
how
to
let's
say
deal
with
the
different
connectivity
cases
or
the
lack
of
connectivity
because
of
faults.
You
see
some
example.
There
cytopology
discussed
in
7157,
which
is
the
I
would
say,
the
original
rfc,
to
discuss
multi-homing
without
net.
P
P
Again,
if
you
look
at
the
available
literature,
the
cases
for
that
are
almost
solved,
I
would
say
there
are
problems
still
to
be
addressed,
but
let's
say
most
of
the
mechanisms
have
been
addressed.
You
see,
for
example,
80,
28
and
again
86.78
now
for
the
open
cases.
So
we
have
focused
our
analysis
on
the
role
of
neighbor
discovery
so
once
again,
4861
4862
and
the
default
address
selection,
because
the
mechanism
to
decide
the
source
address
and
the
next
hope
is
defined
by
6724.
P
So
we
have
identified
two
scenarios
and
I'm
sorry,
maybe
the
terms
we
have
used
are
not
probably
so
widely
adopted.
But
let's
say
first
scenario
is
probably
the
most
common.
We
have
called
it
equal
prefixes,
so
we
have
two
routers
we
can
decide
which
one
to
use
depending
on
the
specific
application.
So,
basically,
if
I
want
to
to
reach
a
destination
on
internet,
I
can
use,
for
example,
router
a
or
router
b,
depending
on
the
addressing
plan,
or
let's
say
on
the
requirements
of
my
application.
P
You
can
also
apply
the
conditional
appeals
for
deciding
how
to
if
they
select
the
source
address
and
that
they
decide.
Okay.
This
is
the
next
stop.
I
want
to,
let's
say
to
use
for
connecting
to
the
destination.
P
Okay.
This
is
it,
but
there
is
another
scenario,
and
probably
we
focused
on
the
second
one,
which
is
the
one
that
we
called.
We
named
non-equal
prefixes.
Why
that,
for
example,
because
there
is
a
special
case,
a
special
requirement
to
steer
the
traffic,
for
example,
to
a
dedicated
site.
So,
typically
simple
wallet
garden
other
case.
P
Well,
we
want
to
steer
the
the
packet
to
reach
a
certain
destination
through
a
certain
gateway
because
of
specific
requirements,
for
example
the
packet
loss
or
latency,
provided
by
one
of
the
upstream
providers
how
to
deal
with
that
in
the
multi-homing
multi-prefix
case.
Well,
based
on
our
analysis,
the
only
solution
available
today
is
defined
here,
so
we
have
to
apply
routing
information
options
and,
let's
say
some
something
that
could
change
the
default
policy
table,
for
example
through
dhcp
v6,
which
is
defined
by
rfc
1778
to
our
knowledge.
P
P
Well,
we
have
to
define
that
source
address
selection
comes
first.
I
think
this
could
be
also
taken
for
granted,
but
actually
this
is
not
the
case.
So
if
you
read
across
the
available
literature,
this
is
not
always
the
case.
There
are
points
in
indiff,
scattered
across
the
different
rfcs,
where
you
see
that
next
op
selection
comes
before
source
address
selection.
P
Clearly,
we
are
open,
as
I
said,
to
comments
and
criticism
to
this
point.
But
if
we
let's
say
take
this
this
path,
so
we
decided
source
address
comes
first
and
then
we
select
the
next
stop.
Then
we
have
the
possibility
to
open,
let's
say
many
more
cases
or
mechanisms
to
solve
the
connectivity
aspect
when
we
are
in
presence
of
specific
cases
as
the
world
garden
or,
as
we
said
before,
the
idea
of
choosing
a
specific
path
because
of
let's
say
application
requirements.
P
We
are
proposing
our
draft
some
modifications
that
we
believe
are
not
so,
let's
say,
impactful
on
the
existing
rfcs
that
you
see
listed
here.
So
basically
the
idea
is
that
clearly
we
have
to
to
agree
upon
the
fact
that
source
address
is
selected.
First,
then
we
move
to
the
selection
of
the
next
stop.
This
is
point
number
one.
P
Then
we
can
apply
something
which
has
been
already
described,
as
I
said,
in
different
rfcs.
That
makes
sense
in
dealing
with
this
aspect
connected
to
multi-homing
multi-projects,
so
clearly
select
a
next
hope
that
has
already
announced
this
source.
Let's
say
the
prefix
to
which
my
source
address
belongs
to
then
dealing
with
the
deprecation
of
the
prefix
information
options
according
to
the
specific
case.
P
Basically,
the
idea
is
that
for
multi-homing
multi
prefix
in
ipv4,
there
is
a
solution
which
is
typically
based
on
private,
addressing
and
net
and
we'd
like
to
also
find
a
solution
to
the
same
issue
when
ibv6
is
used
so
that
we
can
move
to
the
next
slide.
Please,
and
they
said
so,
we
are
open
to
any
comments,
feedback,
even
criticism.
We
are
very
happy
to
let's
say
to
listen
you
by
the
way
the
analysis
open.
So
this
is
version
0,
so
anyone
interested
could
join
and
be
also
called
or
with
us.
Q
David
lampotter,
so
considering
that
link
local
addresses
are
essentially
free
and
abundant.
I
don't
see
any
need
to
change
the
source.
Address
selection
order
to
select
a
source
address
before
the
next
stop,
because
anything
that
can
be
achieved
by
doing
that
can
also
be
achieved
by
simply
adding
a
new
link
local
address
on
the
router
and
choosing
that
as
a
next
stop
and
then
choosing
the
source
address
to
match
that.
So
that
seems
to
be
a
much
simpler
approach.
E
Eric
klein,
no
hats,
I
mean
I,
I
absolutely
agree
if
you
have
8801
and
you
generate
per
per
pbd
link
local
addresses
to
announce
them.
You
don't
have
any
problems
here.
You
do
have
a
a
implement
implementation
of
8801.
Is
you
know,
I
don't
want
to
say
complex
or
non-trivial,
but
there's
a
lot
to
consider
there,
and
some
of
those
considerations
are
some
of
the
things
that
I
saw
on
the
slides.
E
So
if
you
wanted
to
write
a
document
that
was
maybe
more
in
the
style
of
all
of
the
ink
that
was
spilt
in
the
miff
working
group,
that
might
be
helpful
for
people
who
want
to
do
8801,
but
I
think
8801
plus
per
pvd,
like
local
addresses
and
like
this
is
so
it's
it's
done.
Okay,.
G
A
couple
of
comments
now
one
meta
comment
is
that
you
know
I
see
that
this
document,
and
you
know
also
the
the
previous
document
that
you
had
out
there
on
on
prefixes,
has
a
lot
of
overlap
with.
You
know,
work
that
this
very
same
working
group
is
carrying
out
with
a
working
group
document.
G
So
the
work
on
you
know
the
let's
say
prefixes
that
become
stale
is
work
that
has
been
going
on
for
you
know
about
two
years.
A
lot
of
it
happened
in
basic
shops,
there's
a
remaining
bit
in
six
months,
which
is
the
document
that
I
presented
before.
So
what
I
would
expect
is
that
the
associated
work
with
you
know,
stale
prefixes
is
you
know
done
in
that
context.
Otherwise
it's
like
redoing
stuff
that
the
working
group
is
already
doing
in
an
individual
submission.
G
The
other
comment
that
I
have
you
know
I
I
went
through
the
document
yesterday
and
I
see
that
this
document
is,
I
don't
know
if
it's
mixing
things
that
are
like
you
know,
a
topic
on
their
own,
or
that
is
trying
to
do
too
much
into
the
same
document.
For
example,
I
read
parts
where
there
are
discussion
about
the
properties
of
ipv6
addresses.
Like
you
know,
what
are
ula
is
useful
for
that's
a
topic
on
its
own.
Okay,
more
than
you
know
a
couple
of
paragraphs
as
part
of
of
this
document.
G
There
are
other
areas
where
you
know
the
document
you
know
tries
to
analyze
scenarios
for
which
there
are
operational
workarounds,
that's
probably
more
for
a
document
for
basic
shops
that
for
six
months
I
would
expect
same
for
you
know
analyzing
gaps
where
there
are
scenarios
that
you
want
to
support.
But
there's
you
know
nothing
there
to
support
them.
Probably
what
you'd
expect
there
is
a
b.
You
know
if
anything,
a
basic
subs.
G
G
And
then
you
know
that
might
require
a
you
know
a
reread
on
my
side,
but
you
know
I.
I
got
the
impression
that
more
than
trying
to
you
know
tackle
the
you
know
the
problem
in
you
know
in
a
in
a
generic
way.
There's
a
lot
of
analysis
of
you
know
super
specific
scenarios
again
I
might
need
to
read
the
document,
but
I
got
the
impression
that
there's
a
lot
of
energy
being
put
on
specific.
You
know
cases
as
opposed
to
you
know,
trying
to
see
the
broader.
O
Is
version
so
could
I
try
to
answer
this
because
for
overlap,
I
don't
agree
because
for
overlap,
we
have
really
deleted
everything
which
was
really
overlapping.
The
previous
draft
yeah
previous
draft
force.
It
was
a
big
overlap,
your
idea,
but
this
one
we
have
deleted
everything
which
overlapped.
They
believe
this
one
is
just
about
multi-home,
multi
graphics,
which
is
specific
topic
for
the
reason
overlap.
I
would
not
agree
for
mixing
things.
Maybe,
yes,
maybe
we
need
to
think
more
about
your
comment
that
it's
mixing
things.
O
It's
very
complex,
yeah,
probably
probably
you're
right.
Thanks
for
your
comment,
we'll
think
about
it,
and
especially
with
your
comment
about
ula
that
maybe
your
late
discussion
could
be
deleted
from
here,
we'll
think
about
it.
Maybe
maybe
maybe
really
your
discussion
could
be
deleted
from
this.
Therefore,
thanks
for
feedback,
we
think
we'll
think
about
it.
O
For
eric
for
eric
for
eric
question,
could
I
try
to
answer
because
I
still
believe
that
rfc
8801
is
not
enough,
because
if
we
will
choose
not
properly
initially
next
cop,
then
it
would
be
too
late
to
apply
8800.
O
B
Genuine
cover,
no
hats.
I'd
like
I'd
like
to
second
comment
eric
made
about
pvd,
because
actually
itf
has
been
trying
to
solve
this
whole
problem
for
a
while.
I
remember
we
have
a
lot
of
discussions.
I
remember
atf
2016
and
berlin.
When
I
saw
this
discussion
started
right
and
even
then
it
was
like
dvd
seemed
to
be
like
a
proper
way
of
doing
this.
So
maybe,
if
you
think
for
some
reason,
mpvd
doesn't
solve
your
problem.
O
Pvd
is
good
enough
after
the
proper
source
address
is
chosen
after
this
pvd
is
good
enough.
No,
no
problem,
it's
compatible
to
pvd,
but
pvd
itself
is
not
enough.
Initially,
we
should
properly
choose
source
address.
Okay,
we
will
try
to
explain
it
in
different
way
and
maybe
longer
and
okay,
we'll
think
how
to
explain
it
properly.
Why
pdg
is
not
enough.
B
Yeah,
so
edward
yeah
suggest
maybe
just
have
a
section
in
the
beginning
saying
this
is
what's
going
to
happen
with
mpvd
right,
and
this
is
why
it's
bad,
and
this
is
a
problem
with
causing
and
how
we
need
a
new
solution,
which
we
do.
B
O
O
C
O
Okay,
this
particular
slide
deck
is
a
small
one.
Go
next
slide,
please,
of
course,
we
know
we
discussed
many
times
already
on
the
alias
that
there
is
a
security
problem
that
any
anybody
could
impersonate
any
other
node
on
the
link,
because
anybody
could
claim
that
particular
mach
ip
relationship
is
his
his
mark
and
in
such
a
way
could
poison
the
cash.
For
other
note,
especially
for
router,
is
dangerous
in
d.
Trust
model
has
a
general
discussion.
How
to
do
this.
In
my
particular
draft
I
have
referenced
here.
O
O
Initially,
it
was
believed
that
ap
sec
will
help
help,
but
then
it
has
been
understood.
Okay,
some
for
some
reasons
as
a
challenge
not
suitable,
okay,
fine,
then
sand
and
cga
has
been
prepared
and
it's
it's
a
good
strong
encryption,
no
problem,
but,
okay,
nobody
accept
it
again
and
I
have
an
opinion
that
ipsec
and
cga
sent
has
not
been
accepted
because
it's
a
key
management
challenge.
It's
public
key
infrastructure
management.
O
Key
management
is
a
big
challenge,
which
is,
of
course,
if
you
have
it,
it's
it's
excellent,
but
if
you
don't
have
it,
then
it's
not
applicable,
and
especially
one
comment
about
cj
initial
cga,
that
initial
cj
was
not
as
a
separate
solution.
It
was
not
possible
to
use
it
as
a
separate
solution.
It
was
a
part
of
send
it
was
dependent
on
send
and
just
one
reminder
that
initially
cj
and
send
together
they
they
connect
public
key
to
ip
address.
Okay,
okay
interface
identifier,
but
it's
ap
address.
O
It
was
connection
within
public
key.
It
was
not.
It
was
not
connection
like
in
ng
protocol
between
mac,
address
and
ap
address.
What
is
possible
to
do
it's
possible
to
to
use
the
same
algorithm
with
the
same
mechanism
which
has
been
used
in
cga,
but
it's
possible
to
connect
mac
to
ip
the
primary
function
of
nd
protocol,
mac,
ap
connection,
and
if
we
will
connect
mac
to
ap
by
this
simple
cga,
even
a
little
bit
simplified,
because
in
this
particular
document,
cga
is
a
little
bit
simple
simplified.
O
For
that
reason,
it's
called
cj
light,
but
it's
in
principle.
It's
it's
the
same
cga,
it's
the
same
algorithm
which
is
used
in
bitcoin
in
blockchain
and
in
cga.
It's
it's
again
the
same,
and
then
the
security
of
ap
would
be
equal
to
security
of
mac
address
and
mac
address.
Security
is
good
for
some
particular
technology.
It's
good
for
dot,
one
dot,
one
x.
O
O
How
to
do
it
is
exactly
the
same
like
it
was
for
very
similar,
very
similar,
not
exactly
the
same,
but
very
similar
like
it
was
for
cga.
Initially,
we
prepared
some
block
of
information
with
some
some
information
like
network
name
or
time
unknowns
or
whatever,
which
is
needed
primarily
to
you
know,
for
temporary
addresses
for
different,
stable
addresses
for
different
interfaces.
O
It's
is
to
to
to
to
be
compatible
to
all
other
things
which
we
have
for
address,
and
then
we
do
hash,
connect,
prefix
and
mark
do
hash
again
and
after
double
of
hash,
we
are
trying
to
find
the
hash,
which
will
will
have
some
number
of
leading
zeros.
The
draft
itself
has
a
discussion.
How
many
leading
zeros
is
possible
and
how
many
many
leading
zeros
is
more
or
less
good
security.
And
how
and
it's
it's
a
discussion
is
more
accurate
in
the
draft
how
to
properly
choose
number
of
leading
zeros.
O
But
if
it's
not
enough,
then
we
do
mining.
We
we
change
not
so
change
something
in
the
initial
information
and
loop
again
and
do
it
again
and
again
and
it's
mining.
But
if
you
would
like
to
s
simple
security,
not
very
strong
security,
that
mining
could
be
very
fast,
it's
even
possible
for
iot
devices.
It's
it's
explained
in
the
draft
that
it's
possible
even
for
such
low
compu
computing
power
like
iot
devices.
O
If
you
would
like
something
strong
which
would
be
really
protected.
Okay,
you
could
do
mining
long
or
you
could
use
strong
machine,
even
not
the
node
itself,
but
you
could
use
some
some
offline
computation
and
then
you
will
get
some
number
of
leading
zeros.
The
trailing
beats
could
be
used
for
interface
identifier.
K
O
O
If
you
will
put
here
and
definitely
you
will
put
here
enough
information,
then
you
will
get
different,
of
course,
interface
identifier,
for
your
different
logical
interface,
for
your
difficult
physical
interface.
No,
no!
We
will
not
break
anything.
I
have
analyzed
carefully
temporary
addresses
stable
addresses,
which
are
different
for
different
logical
interfaces
or
different
network
names
are
still
possible.
It's
not
a
problem
because
it's
initially
you
will
you,
you
will
choose
different
information
for
generation
of
such
addresses.
No
problem.
Okay,.
K
O
Okay,
but
it
would
be
like
temporary
addresses
if
you
will
choose
a
low
level
of
securities.
Small
number
of
leading
zeros,
then
generation
of
new
new
ip
address
new
interface
identifier
would
be
easy
and
would
be
fast,
but
yeah.
It
would
be
additional
burden
because
it's
additional
mining,
but
it
depends
how
difficult
you
will
choose
security
level,
how
how
difficult
how
many
number
of
leading
zeros
you
will
choose.
If
you
will
choose
a
small
number
of
leading
zeros?
Okay,
it's
not
a
problem.
O
Yeah,
it's
a
good
comment.
It's
a
good
comment
here.
Thank
you.
Go
next
slide,
please
for
legal
host.
It
would
be
extremely
easy
to
check
that
some
particular
marked
ip
relationship
is
legal,
because
just
one
hash,
just
one
hash
based
on
public
information
and
any
other
host,
will
check
that.
Okay,
this
combination
is
legal.
Go
next,
if
bad
guy
will
try
to
break
this,
the
bad
guy,
what
that
guy
needs?
The
bad
guy
needs
the
same
interface
identifier,
but
for
different
mac
address.
It
means
he
will
change
something
in
the
source.
O
Initial
information,
then
what
he
need
to
do.
He
need
to
do
mining,
but
in
his
case,
mining
would
be
much
much
more
difficult
because,
in
addition
to
some
number
of
leading
zeros,
he
will
need
additionally
60
trailing
particular
bits.
60
bits
at
the
end
should
be
exactly
a
particular
interface
identifier.
It
means
that
2
powered
by
60
more
hashes.
It's
extremely
strong
additional
protection.
O
It's
again
analyzed
in
the
draft,
how
strong
it
is
and
how
it's
comparable
to
bitcoin,
for
example,
how
fast
whole
bitcoin
network
could
crash
this,
for
example,
how
much
time
will
be
needed?
Okay
go
next.
There
is
a
little
bit
information
which
could
be
should
be
distributed.
Public
information,
one
is
hash
type
and
for
hash
type,
I'm
trying
to
use
already
defined
option
39
not
to
invent
something
new.
Of
course,
it's
possible
to
invent
something
new.
O
If
you
believe
it's
it's
it's
useful,
but
my
initial
assumption
not
to
invent
something
new
and
additionally,
I
need
digestive
id
information
which
I
I
I
am
proposing
to
as
a
new
option
is
a
new
one.
Additional
option
go
next.
O
I
have
analyzed
more
or
less
all
other
extensions
for
nd,
which
we
have
like
optimistic
nd
like
grant
like
indie
proxy,
like
all
type
of
addresses,
and
looks
like
it's
compatible
to
everything
except
a
few
restrictions
which
is
put
on
this
particular
slide.
The
one
restriction,
because
everybody
is
equal
in
this
ecosystem,
nobody
could
be
restricted.
Who
is
router?
Who
is
not
router,
everybody
is
equal,
and
for
that
reason
it
does
not
preclude
anybody
to
claim
that
he
is
router.
Therefore,
a
regard
or
a
is
is
still
needed.
It's
it's!
O
Not
it's
not
a
protection
against
route
or
fake.
It's
okay!
One,
a
comment.
Another
comment,
of
course,
is
not
protection
again
against
dosto
dudos,
because
anybody
could
generate
many
legal
legal
appealed,
ap
and
addresses,
and
then
spam
everybody,
okay,
it's
ddos
is
not
protected,
of
course,
and
there
is
one
real
case,
which
is
really
could
happen.
O
If
a
particular
legal
host
is
disconnected
his
mark
and
his
ap
is
not
available,
then
anybody
else
could
try
to
use
his
mac
and
his
ap
address
and
if
the
low
level
infrastructure
level
two
infrastructure
will
accept
his
mac
address
without
authentication
or
with
maybe
breach
some.
Some
problem
with
of
authentication
exists
then,
because
he
will
claim
the
mark
and
mark
is
not
available.
O
He
will
claim
ap
address
because
he
ip
address
is
connected
just
connected
to
mac
and
if
anybody
it's
low
probability
because
server
probably
is
always
available,
but
for
client
we
don't
so
much
care.
That's
it.
Okay,
fernando
yeah
question.
O
Yes,
yes,
because
now
the
guy
who
the
the
pair
the
pair
marked
to
ip
address
this
pair,
could
not
be
claimed
by
anybody
else.
Nobody
else
is
capable
to
say.
Okay,
this
particular
ap
address
is
mine.
I
have
different
mac
mac
to
ip
will
be
street
strictly
connected
by
cryptographies.
It
would
not
possible
to
break
this
particular
connection.
G
O
Generation
to
slide
two
slide:
two
yeah
two
on
the
slide:
two:
on
the
left
side,
we
have
a
discussion
section
4.1
from
antitrust
model,
and
in
my
draft
I
have
more
detailed
discussion
how
to
particular
poison
the
cache
for
any
other
node,
and
this
is
against
this.
This
is
against
poisoning
of
the
cache
of
other
node,
because
on
the
other
node,
we
could
claim
that
this
particular
ip
address
is
connected
to
different
mark
and
then
would
be
middle
men
in
the
middle
attack.
G
Yeah,
so
in
general,
you
know
the
idea
of
tying
identifiers.
You
know
from
different
layers
together
has
generally
proved
to
bring
problems.
You
know,
unless
you
really
need
that,
so
it's
entangled
things
that
they
don't
really
need
to
be
entangled.
If
you
want
to
you
know
in
a
way,
you
know
when
we
moved
away
from
eui
64
it
had
to
do
with
that,
like
two
identifiers
from
different
layers
tied
together
that
they
shouldn't
that
aside,
you
know
if,
in
the
same
way
you
need
are
a
guard
anyway.
G
Why
would
you,
for
example,
bother
implementing
this
as
opposed
to
using
nd
inspection,
for
example,
part
of
first
hop
security.
O
Ndx
inspection
like
savvy,
for
example,
is
good
yeah,
but
but
it's
supported
just
by
a
couple
of
switches.
I
mean
just
one
vendor
couple
of
switches:
it's.
It
has
a
really
low
acceptance
by
the
market.
G
O
No,
no
a
regard
is
very
simple.
It's
it's
not
so
complex,
like
you'll
do,
of
course,
if
you
will
do
nd
snooping
in
this
looping,
full
and
disturbing
like
saudi.
Of
course,
then
you
could
trace.
Who
is
who
is
connected
to
which
particular
port
and
you
could
you
could
keep
security,
but
arrayguard
is
much
simpler.
I
mean
regard
you
typically
point
one
point
and
say:
okay
on
this
one
port
check
that
the
icmp
does
not
have
array,
and
that's
it
it's
it's
very
simple.
G
O
The
big
principal
difference
here
is
only
one
initially
cga
and
send
where
connecting
public
key
to
ip
address.
Here
is
connection
marked
to
ap
address,
and
for
that
reason
there
is
no
need
for
public
key
infrastructure.
There
is
no
need
for
key
management,
and
for
that
reason
acceptance
probability
by
the
by
the
market
is
much
higher.
B
Okay,
actually
I
put
myself
in
the
queue
jalenkova
now
heads
I'm
not
actually
exactly
clear.
Why
you're
saying
it's
only
for
disconnected
node
an
attack
could
happen.
What
would
prevent
an
attacker
to
claim
mac
address
and
ipv6
address,
while
mold
is
still
connected.
O
Because,
if
it's
partially
true
but
okay,
if,
if
particular
layer,
two
infrastructure
has
two
nodes
which
claim
the
same
mac
address
would
be
flapping
and
in
this
flapping,
of
course,
you
could
catch
some,
some
packets
in
this
particular
flapping,
but
it's
a
layer,
two
problem,
if
you
have
in
some
particular
layer
to
the
main
domain,
it's
it's
not
normal
situation
anyway
for
layer,
two,
if
two
addresses
connected
to
one
layer
to
infrastructure.
For
that
reason,
it's
its
problem
anyway,.
O
You
could
say
this
way,
yeah,
but
maybe
not
just
this
way,
because
additionally,
it's
flapping,
I
mean
interface,
mac,
address
and
interface
would
be
up
and
down
up
and
down,
because
mac
address
would
be
duplicated.
Duplicate.
Mac
address
will
not
permit
the
host
to
operate
anyway.
The
host
probably
will
call
support
and
ask
for
support
because
he
could
not
work.
B
Well,
I
guess
in
many
cases
scenario
is
stolen.
Addresses
also
can
be
detected
by
monitoring
and
complaints
yeah,
but
I
guess
we
are
talking
about
preventing
the
attack
instead
of
like
reaction
to
it.
So
actually,
my
second
question
is:
if
your
hosts
are
kind
of
in
untrusted
domain-
and
you
don't
trust
them,
wouldn't
it
be
better
just
perform
where
to
isolation
and
solve
this
problem
forever.
O
For
example,
everybody
could
connect
to
everybody,
I'm
not
sure
how
many
probably
very
small,
number
of
cases
we
have
in
the
world
that
people
really
implement
something
like
private
vlan,
for
example,
or
filtering
on
on
wi-fi
yeah,
it's
possible
it's
possible
to
restrict
that
only
wi-fi
station
could
go
only
to
uplink,
it's
not
possible
to
to
send
pocket
from
one
wi-fi
station
to
another
wi-fi
station.
It's
possible
it's
possible
to
do
filtering,
but
typically
it
is
not
done
typically,
especially
in
data
center,
but
in
enterprise
networks.
B
Okay,
thank
you,
so
any
other
comments
from
the
room
or
from
remote
participants.
B
R
R
So
speaking
as
a
network
operator
and
looking
back
from
a
migration
between
mpls
and
then
pssr,
we
we
know
that
data
plane.
Visibility
is
very
important
during
migration
and
currently
it's
missing
in
srv6
and
we're
trying
to
address
that
in
this
document.
R
R
So.
The
elements
coming
from
the
sra
chatter
are,
for
instance,
the
segments
left
field,
the
the
tag
field
and
the
flex
field,
while
other
informations,
for
instance,
the
srh
active
segment,
ipv6
type
is
basically
describing
from
which
routing
protocol
the
active
segment
is
coming
from,
while
the
srh
segment
locate
the
length
and
the
srh
segment.
Endpoint
behavior
also
are
information
coming
from
the
the
control
plane,
basically
describing
the
additionally
that
the
segment
routing
the
srv6
dimensions
next
slide.
Please,
there
are
different
ways
how
to
expose
the
the
segment
lists.
R
One
is
by
doing
the
decomposition
on
the
the
network
node
with
the
srh
segment
ipv6
basic
list
and
sfh
segment
ipv6,
while
the
other
possibility
is
to
maintain
the
the
the
seat
list
completely
and
expose
it
in
one
element
in
the
srh
segment
ipv6
list
section,
while
the
last
possibility
is
actually
to
expose
the
entire
sfh
header
in
the
srh
section,
ipv6,
depending
which
solution
is
being
chosen,
there
are
different
implications,
especially
in
terms
of
scalability,
which
are
described
in
the
operational
consideration
section
next
slide,
please.
R
This
draft
was
already
being
presented
at
itf
113
to
spring
and
ops
awg.
We
received
various
feedbacks.
We
all
addressed
already
all
open
issues
and
also
double
checked
the
ir
consideration
section
with
ipfix
doctors.
R
We
added
a
request
also
in
the
operational
consideration
section,
a
section
how
to
decompose
the
segment
list
when
compressed
cities
is
being
used,
and
we
added,
therefore
the
sh
segment
locator
length
and
the
srh
segment
endpoint
behavior.
In
the
draft
we
aligned,
the
naming
for
of
the
ipfix
entities
from
the
rfc
1712
updated
the
srh
flex,
ipv6
registry
and
com
have
now
in
the
addendum
section
examples
for
all
the
different
data
template
option,
tablets
and
data
records
next
slide,
please.
R
So
the
next
step
is.
We
have
currently
two
major
vendors
which
validate
the
technical
feasibility
and
working
on
implementations.
B
N
N
N
N
The
application
of
network
slicing
also
increases
the
number
of
empty
and
fresh
eggs
in
the
network,
which
increases
the
impact
on
the
network,
because
an
interface
may
belong
to
multi-play
enmity
of
less
lego.
This
problem
cannot
be
slowed,
slowed
by
associate
associating
separate
interfaces
with
different
mt
and
threshers.
N
N
N
This
document
introduced
a
new
hobbyhop
option
which
carries
top
publish
identify
each
top.
Each
topic
identifies
mapping
to
a
folding
table
top
bridge.
Identifier
is
inca
in
case
in
case
field
on
the
head
header
node.
The
mid
node
makes
the
folding
table
selection
based
on
the
forward
based
on
the
topic
in
capsule.
S
So
what
you
are
trying
to
do
here
goes
completely
opposite
what
we
are
trying
to
do
with
the
flex
algo
and
a
bit
of
a
history
here,
an
mtr
has
been
tried
and
failed
miserably
because
of
the
need
to
classify
the
packet
on
every
hop.
This
is
exactly
what
you
are
doing.
I'm
not
sure
this
is
a
good
idea.
Thank
you.
K
Everything,
cisco,
no
specific
hat.
I
simply
repeat
what
I
said
for
the
previous
draft
with
the
vtn
id,
I
don't
mind,
don't
discuss
the
flex.
I
go
thing
right
because
I'm
not
an
expert
there,
but
having
a
way
to
mark
or
color.
The
packet
is
interesting
for
sure,
but
make
it
generic,
not
one
per
protocol.
Thank
you.
D
D
D
T
Your
question,
in
fact
this
is
the
ingress
router
of
this.
The
of
this,
the
I'm
charles
of
the
tunnel.
I
mean
the
ingress
router
encapsulated
the
topology
information
in
the
forwarding
data
plane,
not
the
host.
D
Okay,
so
I
think
like
there's
something
that
you
probably
need
to
do
a
little
bit
more
like
the
security
stuff
in
here.
The
properties
of
this
is
like
very
scary
that
you
determine
like
you
know
how
the
router
looks
it
up.
So
probably
you
need
to
spend
a
little
bit
more
time
on
the
security
properties
of
this
before
it
goes
forward,
but
I
do
if
the
people
like
you
know
peter
was
here
if
this
is
something
that's
not
signed
off
by
the
eventual
consumer
of
this,
we
need
to
discuss
that
first.
L
T
Okay
to
me
from
huawei,
I
would
like
to
add
some
this
to
the
comments
regarding
the
erica
and
peter's
the
comments.
The
first
one
I
mean
the
peter's
the
opinion.
In
fact,
this
is
explained
in
the
in
the
slides,
because,
according
to
the
current
design
of
the
flesh
echo,
it
needed
to
need
a
more
ip
address
for
the
different
topology
so
that
it
will
consume
more
ip
addresses.
T
So
here
we
introduce
a
new
method,
can
share
this
the
ip
address
and
also
take
the
advantage
of
the
ipv6
to
encapsulate
the
support
id
to
identify.
So
this
is
just
the
solutions
concept,
a
second
one.
Regarding
the
eric's
concept.
I
comment
I
I
agree
with
this
one.
In
fact,
in
the
network
in
the
teas
working
group,
we
propose
one
draft
generalized
ietf
network
slicing
we
are
discussing
about
if
the
waiting
resource
id
is
can
be
generalized
to
represent
the
topology
or
not
yeah.
C
L
Joel
halpern
erickson,
I'm
I'm
sorry,
but
this
doesn't
add
up
the
fundamental
problem
you
stated
was
well.
We
need
a
different
ip
address
for
each
topology.
The
endnote
is
participating
in
from
where
I
sit.
That's
a
benefit,
not
a
drawback.
This
is
ipv6,
we're
not
short
of
endnote
ids
bob
laughs.
This
is
it
works,
whereas
you
want
to
introduce
a
new
extension
header
that
we
have
to
take
into
account
in
forwarding
at
every
hop.
H
T
Okay
to
me,
because
you
know
in
the
router,
because
the
packet
will
encapsulate
the
tunnel
header,
we
encapsulate
the
tunnel
header.
We
can
add
this.
The
information
with
the
with
the
topology
add
the
party
information
with
the
new
tunnel
header.
I
think
that's
that's
a
different
from
the
host
process.
C
B
Actually,
I
allowed
myself
to
the
queue,
no
heads,
but
I
actually
agree
with
eric
that
we
kind
of
see
a
lot
of
different
drafts,
probably
which
suggesting
different
kinds
of
identifications
related
to
network
slicing,
apn
and
so
on,
and
I'm
not
an
expert
in
the
area.
But
I
think
it
would
be
a
good
idea
to
consider
yeah
having
one
thing
which
can
be
reused
instead
of
standardizing
five
million
different
options.
E
Yeah,
I
was
just
going
to
say:
I
sent
email
to
the
responsibility
for
tease
about
the
status
of
the
network
slice
document
there.
It
would
be
in
hopes
that
we
could
eventually
get
a
conversation
about
network
resource
partition,
identifiers
and
all
these
other
sort
of
identifiers
it.
It's
not
clear
how
many
of
these
we
actually
need,
and
but
we
haven't,
we
haven't
closed
on
that
conversation
yet,
but
if
six
managers
could
always
send
a
liaison
statement
to
the
tease
chairs
and
ask
about
those
kind
of
things.
B
T
T
T
So
at
the
same
time,
we
now
we
also
have
many
new
features.
Even
this
has
been
proposed
by
gene.
In
the
previous
comments
we
know
now
we
have
this
the
network
slicing
and
we
have
this
epm.
We
have
this
the
alternate
marking.
We
had
the
iom,
all
these
new
features,
we
need
the
new
encapsulation
and
this
the
new
calculation
has
been
defined
and
being
defined
for
the
ipv6
encapsulation.
T
T
Okay,
so
here
propose
is
a
challenger,
so
that's
the
first
one
if
we
define
this
the
new
features
encapsulations
for
all
these
ip
tunnels.
We
have
the
huge
standardization
standardization
work
and
the
second
one
is
difficult
to
keep
the
consistency
between
the
ipv4
and
the
ipv6,
because
the
user
has
been
recommended.
T
The
new
work
is
to
be
done
based
on
the
ipv4
ipv6.
Third
one
I
mean
there's
some.
This
is
the
function
redundant
because,
for
example,
ip
if
we
use
the
ipv6
for
the
ipvc
for
this
ip
tunnel,
so
that's
the
ipv6
flow
label
can
be
used
for
ecmp,
but
you'll
notice.
In
history,
the
ipa
tunnels,
some
ip
tunnels,
take
use
the
ip
udp
port
number
for
the
ecmp.
T
So
there's
the
repeat:
repeated
functionality
in
the
sim.
There
is
a
tunnel
header,
so
there's
a
the
last
one.
So
that's
a
weaker
difficulty
to
extend
based
on
the
existing
format,
because
some
ip
tunnel
has
their
own
header,
for
example,
vxlr
and
gre,
but
we
also
have
some
these
tunnels,
such
as
the
ipuip.
They
also
know
their
own
header,
so
that
is
difficult
to
has
unified.
There
is
the
extension
if
they
need
to
support
the
new
features,
so
we
next
page.
T
Oh
yes,
so
here
we
just,
we
have
proposed
this
generalized,
the
ipv6
tunnel
header,
so
we
think
that
for
all
these
ip
tunnels,
we
you
have
generalized
the
ipvc
ipv6
tunnel
header.
That
means
the
ipv6
header
and
all
these
the
new
features
and
all
the
existing
ip
tunnels
functionality
can
be
encapsulated
in
the
ipv6
extension
header,
so
means
there's
no
need
necessary
to
defend
the
new
features
for
all
these
ip
tunnels.
That's
the
concept.