►
From YouTube: IETF106-6MAN-20191121-1330
Description
6MAN meeting session at IETF106
2019/11/21 1330
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
C
C
C
We
have
a
jabber
room,
there
is
meet
echo
etherpad
Barbara
is
taking
minutes
and
hang
trooping
is
the
jabber
scribe.
Thank
you
very
much.
We
really
appreciate
that
we
try
really
hard
to
get
people
lined
up
to
do
it
before
the
meeting
starts.
There's
all
the
presentations
are
uploaded
and
the
blue
sheets
are
being
circulated.
C
So
for
today's
agenda
we
have
three
working
group
drafts
to
discuss
our
working
group,
eight
items,
the
fragmentation
and
RC
8200
the
path,
MTU
hop-by-hop
option,
the
Oh
a.m.
segment
routing
draft,
and
then
we
have
three
individual
drafts,
active
individual
drafts
being
discussed,
and
then,
if
we
have
time
we
have
two
new
individual
drafts,
these
may,
if
we
run
over,
these
will
get
moved
to
the
second
session
at
the
end
and
then
in
the
second
session
we
have
two
drafts
relating
to
header
insertion
and
what
we're
would
like
to
do
for
that.
C
B
C
Should
ask
clarifying
questions
and
then
we're
going
to
try
to
have
a
discussion
where
both
speakers
are
in
the
front
of
the
room.
They
don't
this
the
first
time
they're
hearing
this
too
so
so
we're
hoping
that
will
be
a
good
people
can
ask
questions
and
they
can
both
answers.
They
are
interrelated.
C
E
E
I'm
sure
there
are
other
SR
documents
in
the
pipeline,
so
you
know
you
might
not
clap
ourselves
on
the
back
too
early
all
right.
Yes,
the
IANA
allocation
for
that
document
is
done.
So
so
yes
run
out
and
implement.
The
ICMP
error
document
is
submitted
to
the
isg,
the
ITF,
sorry,
their
prep
64.
You
know
not
six
for
prefixes
in
reach
or
advertisements,
that's
in
ITF
last
call.
E
We
have
run
through
a
few
reviews
on
the
privacy
extensions
for
for
slack
document.
That
is
not
only
agenda
for
today,
but
I
expect.
We
will
work
in
group
last
call
that
very
soon
after
this
meeting
the
minimum
path
name
to
you
hope,
I
hope
option
document
is
on
the
agenda.
So
it's
do.
I
am
document
for
four
segments
routing,
so
we'll
talk
about
those
afterwards
yeah.
So
that's
the
document
status.
Any
comments
on
those
then
I
just
wanted
to
remind
you
that
the
document
process
has
changed.
E
Here's
the
links
to
the
you
know
both
the
format
FAQ
and
the
XML
to
RFC
tool,
updates
new
vocabulary.
There's
a
neat
tool
to
use
to
convert
from
v2
to
v3.
So
I
think
you
know
from
now
on,
we
expect
documents
to
be
v3.
Coming
out
to
this
working
group.
I
also
feel
free
to
use
the
github
we
have
so
we
can
do
pull
requests
for
changes
and
don't
have
to
discuss.
You
know
a
small
editorial
changes.
You
know
on
the
mailing
list.
It's
it's
a
bit
more
efficient
to
use
modern
tool
for
that.
E
C
Great
thank
you.
Now.
You
just
saw
all
the
slides
I
can
stop.
So
this
is
the
next
step
in
the
the
errata,
the
fragmentation
errata
that
was
reported
against
RC
8200
just
to
background
slides
he's
the
same
as
last
time,
8200
included
a
number
of
updates
in
for
RFC's.
This
required
extensive
changes
to
the
fragmentation
text.
In
section
4.5
and
subsequent
to
8200
being
published
a
number
of
errata
were
filed.
C
C
The
proposals
in
the
errata
proposed
other
changes,
as
we
have
talked
about,
as
we
have
talked
about
figured
out
a
I,
think
a
better
way
to
address
these
errata
than
what
was
proposed
in
the
errata,
and
then
there
was
also
5173
and
with
what
we're
proposing
to
do.
This
is
sort
of
not
even
an
issue,
because
this
figure
changes
in
a
way
that
this
doesn't
isn't
relevant
anymore.
So.
C
The
weave
at
the
last
ITF
we
proposed
the
new
text.
It's
was
discussed.
This
has
been
discussed
on
the
mailing
list
and
I
think
there
was
I
take.
There
was
general
agreement
on
the
changes
with
one
edition.
Changing
subsection
4
from
the
first
fragment
to
the
remainder
of
the
first
fragment.
You'll,
see
this
in
a
minute
in
context,
so
I
think
we're
in
good
shape,
so
I'm
going
to
do
two
things
here.
C
So
this
is,
you
know
the
HTML
diff,
so
you
can
see
on
the
left
is
the
old
and
the
right.
It's
a
I
think
it's
a
little
hard
to
follow
because,
like
in
this
one
there's
a
paragraph
that
looks
like
it's
deleted,
but
it's
actually
moved
later,
where
it
makes
more
sense,
so
I'm
going
to
go
through
these
very
well,
you
can
see
them
and
they're
online
very
quickly
or
you
can
run
your
own
whoops.
C
And
you
know,
there's
a
lot
of
changes
to
the
figures.
There's
a
few.
This
is
where
the
that
paragraph
gets
inserted
and
then
you
can
see
the
other
number
for
change
the
remainder
or
the
first
fragment,
and
then
some
other
changes
the
figures.
So
it
it's
not
a
lot
of
changes,
but
they
are
important.
So
what
I
did
was
create
my
own
diff
for
the
presentation.
It's
a
lot
of
slides
but
I
think
it's
a
clearer
way
to
see
what
the
changes
are
and
also
to
see.
What's
not
changing.
C
So
many
of
these
are
look
just
like
this,
where
there
is
no
change
the
next
one
or
this
one
there
we
go
so
this.
This
is
the
change
to
this
figure
where
we're,
instead
of
showing
extension
and
upper
layer
headers
in
the
in
the
examples
it's
now
just
talked
about
in
the
text
and
the
text
says,
as
it
always
did.
C
The
first
fragment
includes
the
the
extensions
at
upper
layer
headers,
so
as
opposed
to
trying
to
do
it
in
the
figures
and
I
think
this
makes
this
much
clearer
and
then
there's
that
you
can
see
the
paragraph.
That's
getting
moved
later
and
then
this
this
paragraph
is
rewritten
I.
Think
I
did
this
correctly
and
then
there's
another
figure
change
the
same
sort
of
thing
not
putting
extension
and
upper
layer
headers
in
the
in
the
figure.
C
So
the
the
plan
we
worked
out
with
sure
our
Airy
director
is
to
open
up
open
a
new
errata
that
describes
the
error.
The
error
is
in
the
fragmentation
text
and
include
the
revised
text,
and
this
will
basically
be
a
new
section.
Four
point:
five,
a
revised
section,
four
point:
five
and
this
width
and
then
he
well
then
he
will
accept
the
Arado
with
status
of
verified,
saying
it's.
C
It
is
a
technical
problem
and
you
know
it
is
correct
to
fix
it
and
then
the
those
the
other
four
errata
will
be
marked
as
rejected
and
in
the
notes
point
to
the
new
errata.
And
so
this
is
the
format
of
the
new
errata
and
so
errata
is
when
you
file
them.
They
they
say,
you
know
you
fill
in
what
the
current
text
is
and
then
you
put
the
new
text
and
then
you
have
a
note
which
describes
what
you're
doing
so
you
know
so
this
will
have
the
current
text.
C
E
F
F
C
C
At
that
again,
but
I
you
know
it's,
it
seemed
like
I
think
what
we
discovered
is
trying
to
break
this
out
into
a
lot
of
detail,
ended
up
causing
some
other
issues,
and
the
important
thing
is
to
read.
The
text,
which
is
I
think
has
always
was
correct,
is
correct
in
8,200,
but
the
figures
make
this
more
complicated.
Okay,.
F
C
Enough
yeah
I
mean
it
was
I
mean
I
was
the
editor
on
this,
and
it
was
really
hard.
It
was
challenged
and
it
went
through
the
whole
IETF,
the
six-man
and
the
authority--
F
working
group
process
and
the
last
call-
and
all
of
this
you
know
so
it
it
was
not
so
much
later
that
this
was
noticed
that
there
was
a
you
know.
G
E
Will
do
thank
you.
Yes,
we
need
at
least
a
couple
of
people
who
you
know
read
through
this
thing
and
give
their
thumbs
up
and
can't
find
any
other
issues.
You
know
if
they
can
be
bothered
to
implement
it
from
this
text.
That
would
also
be
nice,
but
we
don't
quite
expect
that
I
think
it's
just
a
few
hundred
lines
of
C
right.
The
flight,
oh
okay,
Bob
thank.
C
C
C
C
So
since
105
this
was
adopted.
As
a
working
group
draft
first
working
group
was
published,
we
did
a
request
for
an
early
I,
an
allocation.
This
was
assigned.
We
published
a
new
draft
with
that
and
some
other
a
bunch
of
text.
Clarifications
I
also
had
my
Wireshark
code
for
this
accepted
in
Wireshark.
H
We've
made
some
measurement
experiments
to
try
and
measure
whether
we
can
send
a
hop
by
hop
option
or
an
extension
header
we're
ipv6
works
and
where
we
find
a
bigger
empty,
you
supported
whether
we
can
send
a
bigger
packet
and
we're
in
the
network
it
might
not
get
to.
So
that's
the
general
scope
and
we
have
some
probes.
We
currently
have
five
on
this
list
here
and
we
have
a
few
more
to
give
out
or
run,
maybe
as
virtual
machines
if
anyone
would
like
to
join
us
as
a
place
to
run
these
measurements.
H
Now
we
got
to
check
what
that
means,
and
there
was
one
particular
and
location
where
none
of
the
packets
went
anywhere
when
they
had
a
hop
by
hop
session.
Yes,
Bob's
fault,
Bob's
peers
are
somewhere
along
that
path.
Something
goes
wrong
and
so
and
obviously
we're
going
to
troubleshoot
that
so
that
there
there
is
definitely
evidence
that
hop
by
hop
options
do
not
work
across
the
internet
and
there's
definitely
evidence
that
they
can
work
across
the
internet
in
some
cases.
H
So
there's
the
data
point
we're
at
more
information
next
time,
and
this
is
a
sort
of
question
we're
going
to
ask
and
probably
obvious
now.
How
often
is
the
path
MTU
smaller
than
normal?
How
often
can
use
a
much
larger
MTU,
our
ipv4
and
ipv6
playing
the
same
might
not
be
interesting
to
six-member
sure
is
interesting
to
me
to
figure
out
what
happens
and
I
can't
hop.
My
hot
buttons
be
sent
and
what's
the
pathology,
we're
going
to
try
and
look
into
pathologist.
H
H
Please
form
a
line.
You
wish
to
help
us
in
our
measurements
seriously
and
we
were
available
on
the
list
we're
available
at
the
idea
and
just
torture
XIV
you.
If
you
want
to
do
that.
But
if
you
want
to
ask
any
questions,
please
come
and
ask
recline
question:
dude:
do
your
probes
run
on
the
right
backless
framework?
No.
H
We
have
ideas
of
collaborating
and
running
these
from
ripe,
Atlas
positions
as
well.
The
reason
they
don't
is
because
there's
a
restricted
set
of
experiments,
you
can
do
from
ripe
Atlas
positions
and
that's
one
set
of
experience
from
lots
and
lots
of
vantage
points,
our
probes
that
were
more
intended
to
run
from
one
vantage
point
in
measure,
lots
of
different
paths
and
lots
of
different
ways
through
the
network
and
if
we
gather
a
different
data
set.
These
two
data
sets
in
needs
together.
So,
yes,
that
is
interesting.
H
J
C
E
K
K
Hazy
summary
of
the
draft,
so
the
draft
basically
mentioned
how
we
can
use
the
existing
ICMP
mechanism
for
onn
in
a
services
network,
and
then
it
also
defines
use
of
SRH
flag.
Specifically
basically
say
it
defines
the
flag
for
onm
purposes,
and
then
it
also
defines
some
use
cases
how
the
old
flag
could
be
used
and
it
also
defined
to
onm,
sits
specifically
n
dot.
O
P,
which
is
a
behavior
designated
for
onm,
end
point
with
punt
instruction
and
n
dot
OTP,
which
is
designed
for
onm
end
point
with
timestamp
and
punt
instruction.
K
Since
ITA
105,
we
did
receive
some
comments
on
the
draft.
Specifically,
there
were
some
comments
with
respect
to
use
and
processing
of
au
flag
when
a
package
received
with
SL
equal
to
zero.
This
version
address
was
common
thanks
very
much
for
your
comments,
but
they
said
this
address
is
the
common
dispersion
and
then
there
were
also
comments
regarding
some
cases
where
there
were
could
be
duplicate.
K
Icmp
header
error,
messages
sent
and
N,
and
this
just
does
clarification
for
those
as
well,
and
then
there
was
quite
a
bit
of
comment
on
editorial
changes
and
all
those
changes
have
been
made
in
this
version,
so
the
main
change,
which
is
from
processing
quite
a
few
dozen
territorial
thing,
is
regarding
clarifying
the
OU
flag
processing
when
a
packet
will
see
with
a
cell
could
0.
Now
this
does
not.
The
change
is
still
editorial
in
nature,
from
the
get-go
in
july
2017,
when
the
OU
flag
was
defined.
B
K
Now
this
obviously
get
executed
before
the
SL
check
SL
equal
to
zero
check.
So
basically,
this
chain
clarified
on
the
comment
now
in
the
deployment
status.
At
the
moment
there
are
six
deployment
running
comer
in
a
production,
Network
running
significant
amount
of
commercial
traffic
that
includes
Softbank
China,
Telecom
elite,
China,
Unicom,
clear
net
and
MTN
Uganda,
and
there
are
some
other
in
deployments.
There
are
no,
not
but
not
publicly
disclosed
for
the
public
disclosure.
K
There
is
a
draft
for
the
SR
v6
deployment
status,
and
these
and
and
the
operator
have
contributed
to
addition
of
what
they
have
deployed
and
is
they
specifically
mentioned
that
onm
has
been
deployed
in
these
deployments
from
implementation
status
point
of
view.
There
are
12
hardware
implementation
of
the
draft
with
shipping
which
are
shipping
and
those
are
deployed
as
well
as
we
saw,
and
there
are
additional
known
implementation
and
the
details
are
provided
in
the
ax
services
deployment
status
draft
for
interoperability.
K
There
was
a
multi
vendor
in
trop,
even
in
European,
at
once,
network
test
center
II,
a
NTC
back
in
March
2019,
and
the
results
for
the
intro
op
has
been
discussed
and
disclosed
as
part
of
MPLS
for
congress
in
apple
2019.
These
are
publically
available
and
are
referenced
in
the
services,
deployment
and
implementation
status.
Draft.
K
From
a
next
step
by
whew,
since
the
draft
has
been
deployed,
there
are
at
least
12
Hardware
implementation
of
the
draft.
We
shipping
an
interoperable
code.
We
think
that
draft
is
stable,
implementation
exists,
Interop
has
been
done
and
we
intend
to
do
a
last
call
for
this
draft
if,
depending
on
chairs,
how
they
take
it,
but
but
definitely
by
wind
cooler
or
between
now
and
when
Cooper.
But
we
will
really
like
to
hear
more
feedback
from
the
working
group,
more
reviews
and
we
welcome
any
corporation
any
questions.
E
So
while
people
are
running
up
to
the
microphone-
and
since
this
is
a
you
know,
six-man
spring
document,
you
know
when
we
will
run
a
working
group
last
call.
It
would
certainly
be
last
call
in
in
both
working
groups,
so
I
found.
You
know
unless
I
I
believe
if,
unless
you
are
quite
versed
in
in
SR
in
spring
terminology,
you
might
find
this
document
a
little
hard
to
read
how
many
people
have
read
this
document
in
in
six
man.
E
Excellent,
so
quite
quite
a
few,
so
certainly
encourage.
You
know
people
to
review
it
here
with
Wade
sort
of
yours,
v6
or
six-man
hat
on
and
give
us
feedback.
We
have
and
I
guess.
We
should
discuss
this
with
our
ad
if
there
might
be
overlap
with
all
the
working
groups
as
well.
You
know
there
might
be
I
believe
I
ppm,
for
example,
works
on
on
sort
of
similar
ish
issues.
If
we
should
get
those
in,
you
know
them
involved
now
you
know
I,
don't
know
if
Suresh
I
see
you
know
D,
but.
G
Subscription
I
was
not
really
thinking
about.
Like
know
the
stuff,
that's
generally
called
by
last
call
review.
So
I
was
thinking
like
you
know.
The
other
groups
will
get
looked
in
later
in
the
cycle,
but
I
think
the
spring
is
like
probably
important
around
the
time
of
working
to
blast,
so
the
other
stuff
are
like
after
ad
well,
I'll
probably
sends
a
Molly
review
request,
that's
kind
of
how
we
handle,
like
you,
know
stuff
like
yang,
and
things
like
that.
G
K
G
K
L
E
G
E
G
Well,
yeah,
so
one
thing
that
came
up
kind
of
like
we
talked
about
it,
expand
related
stuff
as
well
as
the
they
require
a
protocol
number
allocation.
Now
so
they're
gonna
go
with
the
early
allocation
request
for
the
protocol
number,
so
I,
don't
think
it's
gonna,
stop
anything!
It's
just
that,
like
bunch
of
process
steps
to
be
made,
yep,
ok,
yeah
super!
Let's,
let's
get.
E
M
M
Okay,
we
can
count
how
many
people
were
already
in
emails,
so
quickly
comes
then
the
problem
host
join
the
network
sends
anarres,
gets
on
the
right
back
and
that
eraser
is
everything
host
needs
to
configure
addresses
to
know
the
default
gateway,
IP
and
MAC
address.
Everything
is
ready
to
send
the
traffic
good
by
the
way.
M
Router
at
that
point
has
no
knowledge
about
host
global
addresses
yet
now
host
start
sending
traffic
outside
to
some
internet
destinations
all
good,
but
then
return
traffic
coming
back
and
router
again
has
no
entries
and
neighbor
cash
for
that
for
the
host
global
address.
So
router
is
per
standard
buffers
one
packet
and
starts
new
address
resolution
for
the
host
drop
in
air
all
other
packets
on
the
floor.
So
as
a
result,
only
first
packet,
my
reach,
the
host
everything
else
is
dropped
until
host
starts
to
the
transmission.
M
Apparently,
some
applications
might
be
quite
unhappy
about
that
which
causing
significant
user
visible
delays
in
connecting
to
the
network.
You
can
see
it
yourself
if
you
connect
to
v6,
only
not
64
SSID
hear
some
of
your
phones
might
show
like
five
seven
seven
seconds
delay
caused
by
this,
because
he
an
ideal
world.
M
While
we
cannot
have
the
same
nice
think
in
ipv6,
because
a
neighbor
discovered
arrived.
She
claims
said
if,
if
v6
device
receives
a
unsolicited
na-
and
there
is
no
entry
yet
for
that
address,
then
it
should
be
silently
discarded.
And
luckily
we
have
an
explanation
why
it
should
be
silently
discarded,
because
there
is
no
reason
to
create
an
entry,
because
the
sender
is
not
trying
to
talk
to
you.
It's
definitely
true
for
host
by
host
who's
the
host,
but
it's
definitely
not
true
for
traffic
sent
through
the
router
outside.
M
In
this
case,
he
a
host
is
not
try
and
talk
to
her
outer,
but
router
will
need
to
talk
to
host
back.
Quite
soon,
sir.
There
is
a
draft
in
v6
ops,
which
explains
the
problem
and
enumerated
possible
things.
We
can
do
to
solve
it
and
because
some
of
those
solutions
involves
updates
to
neighbor
discovery.
State
machine
I
was
advised
to
come
here.
So
here
we
are
so.
M
The
draft
which
is
in
six
month
was
sent
to
mailing
list
some
time
ago
proposed
some
solutions
discuss
the
potential
disruption
which
Maya
might
not
be
caused
by
the
solution
and
has
some
security
considerations.
So
what
we
want
from
the
solution,
we
definitely
need
to
be
able
for
the
host
to
create
a
stale
or
incomplete
entry
in
router
neighbor
cache.
M
So
what
we
can
do,
we
can
do
niacin
and
claim
its
works
as
intended.
Transport
protocol
should
take
care
of
all
of
this
and
packet
losses.
Okay,
I
kind
of
disagree.
We
can
do
what
we
do
for
APB
for
hosts
advertise
the
addresses
in
unsolicited
A's,
routers,
Update
caches.
Everyone
is
happy.
We
can
let
routers
glean
from
that
packet.
Also,
a
solution
is
far
as
I
know.
Few
vendors
doing
it
already
host
might
sent
an
nh-2
router
from
mobile
source
and
trigger
neighbors
discovery
process.
M
However,
it
would
not
work
for
opportunistic
addresses
because
it's
explicitly
prohibited
host
might
sent
an
arrest
from
global
address
which
will
trigger
again
packet
being
sent
back
to
host.
However,
it
would
not
work
for
domestic
addresses
if
routers
the
multicast,
because
you
cannot
sent
an
arrest
with
link
layer
address
in
arrest.
So
if
router
is
responding
with
unicast,
then
router
will
trigger
an
address
resolution,
but
if
router
is
doing
multicast,
it
will
just
respond
with
multicast
and
no
entries
will
be
created.
M
We
can
ask
routers
to
buffer
more
packets,
I,
think
security
people
wouldn't
approve.
There
is
also
idea
to
trigger
address
resolution
every
time
the
router
forwards
routes,
some
packet
for
which
it
does
not
have
entry
already
I
kind
of
concerned
here.
As
far
as
I
know
a
and
some
vendors
do
that,
but
I
think
this
connection
between
forwarding
cancer
control
plane
might
be
tricky
sure
proposed
changes.
M
When
host
gets
a
new
global
address
configured,
it
should
send
unsolicited
an
A
with
override
flag
set
to
zero
and
I
forgot,
to
put
it
on
the
draft
about
a
red
flag.
I
will
update
it
in
zero
one,
so
a
second
override
flag
to
0
means
we
would
not
disrupt
any
existing
countries
and
rare
routers
may
shoot
and
I'm
not
sure
about.
This
should
create
a
stale
countries
when
they
receive
unsolicited
tennis,
and
there
is
no
entry
for
that
address
yet
so
actually
purpose
because
RFC
currently
say
Ansel
Easton
a
should
be
discarded.
M
I
think
my
II
does
not
even
violate
the
current
statement
should
not
means
me,
but
I
believe
we
probably
should
say
should
here,
because
it's
a
good
idea.
If
you
have
a
host
on
the
network,
then
probably
it
makes
sense
to
create
an
entry
proactively
disruption.
What
bad
gonna
happen?
If
you
do
this,
if
there
is
an
entry
already,
then
nothing
would
happen
because
receiving
Ansel
Easton
a
might
in
the
worst
case
scenario,
updates
the
entry
state
to
income
to
stale,
which
again
would
not
disrupt
any
traffic.
M
It
might
just
trigger
additional
cycle
of
neighbors
in
neighbor
solicitations
if,
if
there
is
incomplete
entry,
well,
this
tricky
right.
It
means
that
router
already
started
address
resolution,
so
router
has
sent
and
multicast
honest.
Then
my
new
host
sends
this
unsolicited
naa.
In
this
case,
entry
changed
from
incomplete
to
stale
and
it
will
sit
in
the
stale
until
the
rightful
owner
responds
so
I'm
talking
about
situation
when
someone
might
have
that
address
already,
because
we
can
expect
that
Solis
the
10a
will
have
overwrite
said,
then
the
target
and
target
link
layer
address
included.
M
Then
style
will
come
become
reachable.
So
the
only
moment
when
some
traffic
might
go
to
the
wrong
destination
will
be
between
receiving
na
and
unsolicited
na,
and
before
Solis
that
comes,
but
in
real
life
the
traffic
would
be
dropped
anyway,
because
before
Solis
the
tane
came,
there
is
no
enter
right.
So
I
did
not
find
the
scenario
when
it
might
be
disruptive,
but
I
might
be
wrong
right.
So
I
I
would
like
people
to
read
this
draft
and
tell
me
where
I'm
wrong
Eric.
You
already
found
when
I
wrong
good.
N
M
M
O
O
M
M
M
P
Miller,
so
on
the
previous
slide,
I
think
yeah
I
have
no
problems
with
a
slide
and
should
maybe
should
yeah
sure
I
think
what
I
wanted
to
observe
is
that
for
the
router
behavior
my
reading
is
that,
on
the
slide
that
you
had
a
ways
back,
that
you
said
this
is
true
for
hosts,
but
not
for
routers
or
whatever,
where
it
was
a
should.
My
belief
is
that
any
router
that
does
this
is
still
compliant
with
4860
was
yeah.
B
P
Just
doesn't
follow
that
should
so.
This
is
just
an
elaboration
on
when
you
might
not
follow
that
should
this
is
not
actually
any
change
to
the
router
behavior
here
yeah.
Yes,
it's
just
an
informative
elaboration
on
what
should
means
and
for
a
router
you
probably
don't
to
follow
that.
Should
that's
what
you're
saying
here,
yeah.
P
That's
why
the
bottom
half
I
can't
argue
with
because
I
believe
that's
already
48
61
compliant
at
the
top.
Half
of
this
is
the
only
interaction
proposing
as
a
change,
and
that's
one
that
I'm
saying
I,
don't
see
a
problem
with
that
offhand,
although
you
might
want
to
say
that
this
whole
thing
is
just
a
may,
because
the
host
isn't
broken
per
se
if
it
doesn't
send
a
bunch
of
back
to
back
things
or
whatever,
and
so
it's
really
do
us
more
of
a
ipv6,
no
requirements.
Question
right.
P
M
P
Here
so
I
looked
at
48,
61
and
checked
my
memory
and
assuming
I
was
looking
at
the
right
place.
Isn't
it
missing
other
place?
It
allows
sending
unsolicited
ascend
A's
right
now,
but
it
does
so
in
the
condition
that
your
link
layer
address
changes
yeah
like
yeah,
you
just
had
a
change
in
your
MAC
address
or
something
like
that,
and
you
want
to
proactively.
Do
it.
That's
the
only
cases
called
out
in
there
that
I've
noticed
so
far.
What
you're
doing
is
you're,
adding
a
second
condition.
B
P
Q
M
M
O
O
M
Yeah
you're
so
like
again,
I
will
update
the
text.
So
here
is
question
to
the
audience.
If
does
it
make
sense?
If
does
can
be
for
adoption,
and
the
site
question
actually
is
currently
be.
Six
jobs
draft
enumerate
all
possible
solutions,
such
as
the
we're
doing
those
two
sins
and
brings
it
here.
Shall
we
keep
all
possible
solutions
in
this
draft
occupied
in
v6
hopes?
I,
don't
have
opinions
in
just
a
matter
of
where,
with
the
comment
stuff
so
so.
M
Like
yeah
I
forgot
to
put
on
the
slide
yeah
just
to
minimize
the
noise
and
I,
we
might
send
it
to
all
halls,
but
I
don't
think
it's
useful
because
it's
actually
intended
for
outers
and
I
do
not
think
it's.
It's
violates
any
existing
standards
because
I
think
the
current
standard
says
usually
the
destination
of
unsolicited
assets.
All
hosts-
it's
not
even
I,
do
not
even
see
it
as
a
requirement,
so
suggestion
is
to
send
it
to
all
others,
but
probably
we
can
send
it
to
all
hosts.
P
B
P
M
P
M
Understanding
Kay
is
currently
all
possible.
Solutions
belong
to
Bishop
swabs
draft
in
the
format
here
is
the
problem.
We
had
all
those
ideas
what
to
do
with
them,
starting
from
doing
nothing,
and
we
decided
there
are
two
good
things
we
can
do
and
what
we
did
in
six
men.
However,
as
far
as
I
know,
some
vendors
do
already
doing
some
of
those
additional
things
as
well
and
I,
don't
think
as
they
have
pros
and
cons.
So
at
least
yeah
we
can
probably
keep
on
these
are.
P
Things
that
operators
can
already
do
by
tweaking
things,
meaning
things
that
are
already
compliant
you're,
changing
which
things
are
configured
which
rfcs
are
turned
on
and
off,
and
whether
shoulds
or
maze
or
on
and
off
that
part
is
fine.
If
you're
saying
here's
a
bunch
of
ways,
you
can
invent
new
technologies
for
new
mechanisms
for
the
involved,
changes,
RFC's
I'd
say:
don't
put
that
in
an
RFC.
Just
leave
it
in
your
doctor
in
a
document
right
now,
but
it's
not
published
yes,.
C
G
Suresh
krisshnan,
so
it
kind
of
makes
sense
to
me.
There's
like
some
work.
I
think
you
need
to
do
specifically
the
gratuitous
na
s
going
to
doll
hosts,
as
well
as
all
daughters,
because
it's
not
clear
with
the
new
text
in
the
draft,
whether
you're,
still
sending
the
almost
one
as
well
or
just
sending
all
daughters,
one
so
I
think
you
need
to
verify
that.
Okay.
E
C
F
Earring
again,
individual
contributor
I,
like
this,
don't
take
me
wrong
right,
so
you
know
ham.
My
only
concern
is
that
it's
v6
up
you
come
up
with
five
solution.
Then
we
could
end
up
with
five
solution
here.
The
router
vendors
implement
one
two
three
and
it
was
when
they
implement
two
four
and
five.
We
end
up
nowhere.
M
So
I
think
it
can
be
six
tops
draft
enumerate
things,
I'm
insane
pros
and
cons,
and
for
some
of
the
machine
it
saying
it's
not
going
to
work
at
all.
For
example,
si
boot
here
knees
are
thinking,
ns
or
arrests.
Would
work
optimistic
addresses
right,
so
I
put
I
can
put
them
in
the
section
considered
by
discard
that
right,
I
can
rephrase
v6
ops
drafts,
obviously
yeah,
because
initially
until
now,
I
don't
know
if
it's
all
make
sense.
I
would
expect
some
people
to
come
and
tell
me
that
I'm
gonna
break
stuff
right.
E
From
a
6-minute
perspective,
I
think
these
six
ops
have
presented
us
with
a
problem
and
we're
picking
a
solution
and
I.
Think
it's
Dave
and
Bob
said
you
know
we
can
leave
those
alternatives
in
a
expired
internet
draft.
We
certainly
don't
want
to
include
them
or
talk
about
them
here.
I
think
we're
going
to
pick
one
solution
and
stand
there
as.
R
P
M
P
E
Yes,
I
think
I
mean
our
reading
both
of
the
v6
ops
lists
six-man,
and
this
room
is
that
there
is
consensus
that
of
this
document.
I,
don't
think
it
is
necessary
to
do
harm
for
any
objectors
did
I
yeah
I
didn't
hear
anything.
I
didn't
mean
to
do
good.
Super
will
confirm
that
own
list-
Thank
You,
Jen,
okay,
Keys
epi-
are
you?
Are
you
here.
S
Hello,
this
is
happen
and
we
are
going
to
present
the
ipv6
application
for
the
afternoon
of
the
alternate
marking
method.
So
just
a
quick
recap
for
this
methodology,
so
this
is
basically
an
eye
on
performance
measurement
technique
that
allow
the
two
met
to
measure
the
packet
loss,
delay
and
delay
variation,
and
you
see
the
reference.
So
we
have
an
air
FSC
8321,
basically
for
point-to-point
measurement
and
also
the
extension
that
we
consider
as
this
evolution
that
is
multi-point
alternate
marking
draft
that
allows
flexible
application
of
this
methodology.
S
But
basically
it
is
us
also.
The
name
suggests
is
the
alternation
of
two
value
tube.
Its
value,
for
example,
between
red
and
blue
and
red
counters,
are
running.
The
blue
counters
are
sealed,
so
we
can
get
the
counters
during
the
still
period
and
by
comparison
we
can
calculate
pocketers.
So
basically,
it's
very
simple
and
same
methodology
apply
also
to
delay
and
delay
variation.
What
are
the
main
strengths
that
it
works
without
my
own
pockets
that
divide
precisely
the
traffic?
So
we
don't
need
to
inject
nothing
in
our
flow.
It
works
on
real
production
traffic.
S
It
works
also,
if
you
have
out
of
sequence,
so
this
make
this
methodology
very
flexible
and
it
works
cannot
synchronize
at
the
network.
So
you
don't
need
a
strict
synchronization,
because
the
change
of
marking
is
sort
of
out
of
synchronization
signal
over
over
the
network.
Regarding
the
delay,
just
we
have
two
alternatives:
one
is
single
mark.
The
the
second
is
double
mark.
The
single
mark
we
use
one
bit,
I'll
beat
the
so
you
see
the
alternation
between
1
and
0.
You
can
do
the
alternation
for
fixed
set
period
also
or
based
on
fixed
numbers.
S
So
it
is
the
same
change
also
only
the
implementation,
and
so
the
albiet
can
it's
used
for
the
delay
and
for
first
sorry
for
the
packet
rows.
While
for
the
delay,
you
can
take
the
reference
just
for
the
first
on
last
pocket
of
each
marking
period,
but
this
doesn't
work
so
well
in
case
of
reordering.
So
in
this
case
you
can
also
calculate
the
average
packet
delay
and
delay
variation
if
we
have
the
ability
to
have
a
second
bits.
S
In
this
way,
we
can
use
the
first
bit
for
the
packet
rows
and
second
bit
for
the
delay.
In
this
case,
you
can
select
some
packets
within
each
period
to
follow
this
packet
along
path
and
calculate
the
delay
for
these
packets.
In
this
case,
you
can
have
a
more
informative
information,
because
you
can
calculate
minimum
the
maximum
and
all
the
statistics
for
for
the
delay.
So
you
you
can
have
more
informative,
matrix.
S
Okay,
that
is
basically
the
methodology.
If
you
want
more
detail,
come
to
me
already
draft
in
IP
pm
what
about
ipv6,
we
already
have
presented
draft
and
I
think
in
London.
That
makes
reporter
the
summary
about
some
alternatives
on
how
to
apply
this
methodology.
So,
for
example,
we
reported
some
alternatives
that
we
already
investigated
about.
The
use
of
ipv6
addresses
the
ipv6
flow
level
that
we
cannot
use,
of
course,
because
ipv6
addresses
is
too
expensive.
The
use
of
flow
labels
is
against
the
RFC
64
38,
because
it
is
based
on
the
easy
NP.
S
So
in
this
case,
if
we
use
flow
label
to
mark,
we
can
change
the
the
path.
So,
in
this
case,
is
not
good
to
make
performance
and
to
change
the
part
at
the
same
time.
So
the
only
way.
In
summary,
you
can
say
that
the
only
way
is
to
use
the
an
option
either
if
we
consider
the
ipv6
or
the
IDL
V.
If
we
consider
the
SH,
our
idea
is
to
define
and
generalize
alternate
marking
data
fields
we
have
made,
considering
all
the
deployment
use
cases
that
we
have.
S
We
think
that
we
can
generalize
this
data
field.
So,
as
I
said,
we
need
to
marking
4
bits
to
marking
leads
so
L
built
and
D
bit,
one
for
loss
and
the
other
for
delay.
We
considered
also
a
flow
monitoring
identified
in
T
fire,
so
I
20
bits
that
is
not
like
the
flow
label,
but
allow
us
to
make
a
Freudian
TIFF
occasion.
S
This
is
not
crucial
for
the
methodology,
but
can
be
very
useful
for
the
deployed
for
deployment
area
for
deployment
reason,
and
then
we
put
some
reserve
8
bit
for
future
use
and
this
basic
this
data
fields.
We
want
to
include
in
an
option
header
or
a
necessary
htlv.
So
we
investigated
some
alternatives.
S
Also,
there
was
some
discussion
on
the
mailing
list
and
you
can
use
this
option
as
up
by
up
has
destination
option
other,
depending
on
which
measure
you
want
to
activate,
or
in
NS
htlv,
for
example,
in
we
are
making
a
summary
of
the
the
alternative
options
that
you
may
have.
You
can
have
a
destination
option.
In
this
case,
you
can
measure
the
end
to
end
with
the
destination
address
the
hop
by
up
option.
If
you
want
to
measure
foreign
every
router
on
the
path,
an
ester
htlv.
S
This
is
zero
one,
and
we
got
several
comments
on
mini
list
in
particularly
want
to
thank
Bob,
all
Tom
and
Stefano
that
give
us
some
feedback
and
provements
to
the
document,
in
particular,
to
investigate
the
alternatives
and
to
adjust
some
time.
The
wording
of
the
draft
as
next
step
so
I
think
we
have
found
an
agreed
way
to
apply
the
FEC
8321
and
its
evolution
in
particular,
because
we
look
also
to
the
multi
point
of
mark
methodology
for
ipv6,
and
we
asked
for
comments
feedback
and,
of
course,
we
would
like
to
go
for
the
adoption.
S
You
mean
the
alternate
marking
or
in
bandar,
on
which
social
team
working
I
mean
others
working
on
this
in
the
draft
are
only
experimental
because
we
cannot
make
standard
with
this
kind
of
methodology,
so
in
IP
p.m.
we
are
basically,
we
are
described
in
general
methodology.
So
now
we
want
to
apply
in
real
protocol.
E
Big,
so
do
what
I'm
trying
to
ask
us
think
is:
is
you
know
the
distribution
work
between
IP
p.m.
and
and
and
6
man?
If
6
man
is
left,
you
know
defining
the
you
know,
TLV
format
and
perhaps
rules
of
which
extension
headers
to
go
in
and,
and
you
know,
the
marking
logic
if
you
like,
if,
if
that's
going
to
stay
in
IP
p.m.
for
example
and
I
guess,
you
know
usually.
S
If
I
also
look
at
the
experience
of
other
methodology,
the
protocol,
the
protocol,
specific
application
are
made
in
the
working
group,
for
example
here
in
six-man
and
but
the
methodology,
the
general
methodology.
We
are
working,
of
course,
in
a
ppm
because
it
is
protocol
agnostic.
We
can
say
so.
You
can
apply
to
other
kind
of
protocols
and
yet.
C
E
Think
we,
you
know,
let
us
have
a
you
know,
chat
with
the
I
ppm,
okay,
ad
chairs
as
well
and
and
then
you
know,
certainly
want
to
see
continued
discussion
on
the
mailing
list
as
well,
and
you
know
figure
out
on
a
mailing
list,
and
then
you
know
with
you
know,
see
the
next
step
as
as
adoption,
er.
Okay.
T
Hello
max
me
some
first
idea
for
Ben
to
sort
of
in
a
long
time,
I've
been
on
the
mailing
list
for
a
very
long
time.
This
is
a
bit
blue
sky
and
I've
fallen
over
you
habit
of
using
bullet
points,
so
you
might
only
find
two
or
three
okay,
whoops
ipv6
formal
any
cast
and
functionally
accursed
addresses.
Current
ipv6
anycast
addresses
are
from
within
the
unicast
address
space
and,
as
our
seat
4291
says,
they're
indistinguishable
to
configure
any
cast.
It's
it's
usually
a
flag
on
an
interface
when
you
configure
an
address.
What
that
does?
T
Is
it
disables,
duple
hood,
address
detection
and
to
get
them
available
in
the
routing
domain?
You
have
to
inject
it.
Somehow
it's
treated
as
unicast
by
routing
the
main
protocols
and
other
hosts
I
think
that's
a
negative.
Sometimes
if
you
happen
to
have
duplicate
route
table
entries,
that's
a
fault
if
it's
unintentional,
but
if
it's
intentional,
then
it's
probably
anycast
the
forwarding
scopes
or
domains
for
these
types
of
anycast
addresses
is
fairly
cost.
T
We
have
global
local
network
and
link
what
about
something
a
bit
more
discrete
such
as
realm,
administrative
or
organizational
another
thought
or
an
example,
is
that
applications
or
protocols
can't
distinguish
unicast
or
anycast
addresses
without
manual
configuration.
An
idea
is
to
have
multipath,
TCP
or
UDP,
establish
using
anycast
and
then
switch
to
using
a
unicast,
and
it
would
be
useful
to
be
able
to
distinguish
the
address
types.
So
the
thought
I've
had
is
to
have
a
formal,
ipv6
anycast
address
space.
T
My
thought
is
a
a
soshite
or
possibly
FA
for
formal
anycast
they're,
both
available
there's,
actually
not
my
idea.
The
earliest
RFC
one
of
the
earliest,
if
not
early
star
of
C's
on
any
Casper
1546,
suggested
two
ways
of
supporting
anycast
and
one
of
them
was
to
have
a
well
known
class
of
addresses,
with
the
advantages
being
it's
easier
to
determine
and
addresses
in
anycast,
address
and
well-known.
Anycast
addresses
are
easy
to
support.
T
If
we
have
a
look
at
some
of
the
existing
anycast
addresses
that
are
already
defined
within
a
subnet,
we
have
the
top
127
addresses
they're
reserved
for
this
purpose
and
there's
a
couple
of
specific
resident
reservations.
The
reserves
subnet
any
caste
range
there's
also
the
mobile
ipv6
home
agents,
the
other
one,
that's
within
a
subnet
is
all
zeros
for
this
subnet
route
or
any
cars
address.
These
have
different
scopes
and
the
scopes
depend
on
the
type
of
unicast
prefix
in
use,
such
as
global
or
link
local,
etc.
T
There
are
some
others
that
are
global
globally
assigned
by
iana
they've,
discarded
discard
only
address
block
164,
that's
a
network
local,
even
though
it's
a
globally
unique
address
the
port
control
protocol
anycast.
In
theory,
that's
supposed
to
be
globally
reachable.
But
if
you
look
at
what
PCP
is
about,
it's
unlikely
you'd
have
a
random
PCP
server
somewhere
out
on
the
intern
that
you
want
to
send
to
there's
the
turn
one
and
then
there's
the
as1
one
to
service
one.
Looking
at
these
reserved
well-known
addresses,
I
think
there
are
three
common
properties
there.
T
Encoding
services
and
functions-
they're,
not
actually
hosts
or
interface,
identifies
any
unique
assets.
They
have
different
number
spaces,
so
we
have
the
gor
global
for
some
of
those
non
guha,
global
and
subnet
ID,
and
they
also
have
different
forwarding
domains
or
scopes.
I
realize
that
these
properties
are
actually
similar
to
what
Molly
caste
has,
and
so.
T
If
the
idea
of
having
a
formal
anycast
address,
prefix
is
good,
then
I
think
any
caste
is
by
similar
to
unicast,
and
it's
also
similar
to
multicast
in
the
sense
that
it's
been
used
for
services
and
functions,
sort
of
thinking
about
where
that
puts
any
caste.
It's
perhaps
can
be
imagined
to
be
halfway
between
unicast
and
multicast,
one
to
one
one
to
any
and
one
to
many.
T
T
The
proposal
for
an
any
caste,
formal,
any
caste
prefix
ia
as
I
suggested
then
have
a
visible
scope
which
I
say
the
same
values
as
the
multicast
scopes.
Then
four
bits
for
an
any
caste
identify
format.
This
is
to
allow
flexibility
in
the
lower
112
bits,
and
this
is
also
because
I
realize,
as
a
shape
as
a
bowl
to
us.
T
So
I
should
preview
feature
proof
it
a
bit
possibly
a
dozen
a
new
destination
unreachable
code
for
edge
of
visible
scope
reached
an
interim
alternative,
would
be
communication
with
destination
and
militarily
prohibited
in
terms
of
destination.
Address
selection.
The
formal
anycast
would
be
preferred
over
unicast
by
default,
but
there
are
some
applications
such
as
that
modify
protocol
example
where
you
might
want
to
prefer
unicast
well.
That
can
be
easily
that
can
either
be
selected
because
of
the
well-known
anycast
prefix
I.
T
T
Another
thought
that
occurred
to
me
was
using
anycast
addresses
for
hop-by-hop
processing
of
packets
through
network
after
the
local
hop
processing,
which
obviously
starts
to
relate
to
what's
happening
in
spring
and
so
on.
After
the
local
hop
processing.
There's
an
RPF
check
on
the
source
address
same
as
multicast.
However,
we
need
to
exclude
the
local
node
anycast
destination,
address
instance
to
prevent
a
packet
looping
around
within
the
node
and
then
finally,
the
forwarding
is
based
on
the
remaining
anycast
routes.
T
This
is
neither
unicast
or
multicast
forwarding.
It's
got
bits
of
both
and
it's
actually
a
series
of
host
hops.
If
we
look
at
our
FC
8200
on
what
our
router
is
versus,
what
a
host
is
the
thing
to
remember
about
these
definitions
is
they're
really
functional
definition
is
not
device
definitions,
so
a
router
is
a
node
that
forwards
ipv6
packets,
not
explicit
to
it
explicitly
address
to
itself.
Well.
This
is
a
destination
address
on
a
device
inside
the
network.
T
Regarding
the
a
the
first
format,
I
think
I've
mentioned
it
the
functional
anycast.
This
is
the
breakdown
of
the
lower
112
bits,
there's
an
anycast
domain
prefix,
which
would
be
a
unicast
prefix.
This
is
inspired
by
mod.
It
casts
RFC
3306,
all
zeros
identifies
an
unspecified
or
this
domain,
and
this
also
provides
an
opportunity
to
do
any
casts
more
specific
route.
Aggregation
at
this
point,
there's
Reserve
bits
and
then
a
prefix
length
of
sixty
four-bit,
sorry,
six
bits
of
prefix
length,
zero
mean
64
this
flags
again
inspired
by
multicast.
T
T
This
is
sort
of
new.
This
is
a
to
introduce
a
local
instance
of
the
anycast
address.
An
example
could
be
that
you
are
developing
an
any
car
service
and
you
also
have
a
production
version.
This
is
a
local
instance
configuration
revision
etc.
A
number
embedded
in
the
address
this
is
a
bit
of
a
soft
field.
It
could
also
be
used
to
extend
the
anycast
function
ID
to
32
bits
if
that
would
be
useful.
T
And
finally,
the
last
allow
24
bits
the
anycast
function,
ID
with
the
t
equals
0
or
1
Flags,
determining
whether
it's
I
on
a
sign
or
not.
It
could
be
a
bit
simpler,
I'm,
not
sure
about
the
prefix
length
field.
It's
an
informational
field
and
possibly
with
one
flag
value
could
be
encoded
somewhere
else.
Some
example
uses
I've
tried
to
set
this
up
along
quite
a
while
ago
to
have
an
Internet,
DDoS,
impervious
ISP
anycast
DNS
resolvers.
T
The
requirements
would
be
reachable
to
all
of
a
nice
peace
customers,
but
not
reachable
from
the
internet,
and
then
it's
attributable
to
the
ISP
sure
your
customers
could
DDoS
the
DNS,
but
they
have
a
good
interest
in
not
doing
that
because
they
break
their
own
internet.
So
we
would
form
that
using
a
formal,
anycast
prefix
of
a
a
as
mentioned.
This
would
be
a
new
scope
of
a
visible
scope
of
a
network
service
provider
which
would
be
greater
than
organizational
but
smaller
than
global,
and
then
the
anycast
identify
format
of
functional
unicast.
T
The
only
Castlemaine
prefix
would
be
one
of
the
ISPs
globally
unique
doers
to
de
l'eau
total
0
1
DB
8
prefix
length
of
value
of
zero,
meaning
such
64
flags
of
zero,
because
it's
a
honor
assigned
any
caste
functional
identifier,
local
instance,
since
it's
in
production,
zero
or
whatever
the
ice
P
decides,
but
zero
seems
logical
for
functional,
and
then
these
would
be
some
example.
I
honor
assigned
well-known
function,
IDs
of
53,
54
and
55.
So
these
would
be
the
anycast
addresses
for
dns
that
we
would
distribute
to
our
ISP
customers.
T
Iab
0
to
Devon,
deviate,
53,
54,
55,
another
example
to
to
fill
it
out.
This
is
an
organizational
thing:
a
service
in
development,
I,
don't
know
what
a
thing
I
does,
but
it's
likely
to
find
again
a
a
size
8.
This
scope
would
be
organization
and
again
the
functional
anycast
identifier
format,
anycast
the
main
prefix,
the
ice.
The
the
organization
could
put
any
of
theirs
there,
but
to
reduce
visibility.
They
might
use
ula.
So
if
d
xxy
was
its
etc
again
prefix
length
value
of
0
indicating
such
64.
T
This
time
the
t
flag
is
1,
because
it's
a
local
organization
assigned
the
local
instance
where
we
6a,
because
this
is
the
ITF
106
revision
and
finally,
there's
any
cost
function.
Identifier
of
54
40
47,
which
is
an
arbitrary
number
and
is
TNG
in
ascii.
So
that's
that
one's
a
bit
longer,
but
it
could
be
encoded
in
dns,
but
there's
a
a
atfd
and
the
the
ula
prefix,
the
ID
for
the
t
flag
and
then
6,
a
5
4
4
e47.
T
The
status
I
sort
of
have
worked
on
this
for
quite
a
while.
The
idea
is
sort
of
mostly
baked
I.
Think
I've
been
working
in
thinking
on
this
for
about
three
years.
I
had
no
idea
that
whether
a
pan
out
or
not
and
asking
for
a
sashayed
is
pretty
bold,
so
I
think
you
gotta
justify
that
a
lot
I
reasoned
I
discovered
the
host
by
Cindy
Carson
using
ml
d
was
a
same
suggest.
There's
been
some
thoughts
of
doing
this
sort
of
thing
before
as
much.
U
N
One
yeah
sort
of
similar
to
that
point:
I
was
sort
of
wondering
operationally
for
your
network
for
a
network
service
provider.
How
much
what's
the
difference
in
work
required
for
using
one
of
these
and
routing
/
128
says
any
guests
throughout
your
network
for
various
services
versus
just
using
it
GA
they
might
have
or
three
FF
II
for
that
matter.
Okay,
sorry,
look.
T
B
N
V
Michael
Richardson
I
liked
it
on
the
list
I
still
like
it.
I
think
that
one
of
your
use
cases
was
the
quick
case
of
negotiate
on
anycast
and
then
and
and
then
move
elsewhere
and
and
I
like
that
use
case
too
I
believe
that's
the
killer
use
case.
Unfortunately,
it
doesn't
work
if
the
address
is
not
visible
to
do
is
not
address
announcing
ball
to
the
rest
of
the
world
right.
So
that's.
V
V
Apparently
they
were
switching
on
the
EC
n
bits,
and
so,
if
you
turned
them
off
in
the
middle
of
your
TCP
connection,
you
then
went
to
the
other
any
casted
DNS
server
over
TCP,
which
didn't
work
right
so
making
that
work
would
be
good
somehow
to
identify
it
or
to
make
it
clear
to
the
ecmp
that
this
wasn't
any
caste
address
and
it
shouldn't
do
quite
the
same
thing.
That
would
also
be
great,
but
I
don't
see
how
to
make
that
work
and
also
make
your
you
know:
bulletproof
DNS,
server
work.
V
We
had
a
need
for
some
kind
of
an
anycast
address
in
the
home
net
space
yep,
where
we
want
to
reach
whichever
thing
has
stuff,
and
it
wasn't
at
all
clear
to
us
how
to
to
do
that,
except
that
we
would
wind
up,
saying:
okay,
well,
his
the
HomeNet
was
going
to
be
well,
would
be
all
you
la
s
so,
and
we
may
not
even
have
address
resolution.
We
want
a
special
magic
address
that
we
can
essentially
hard-code.
So
the
a
a
thing
would
be
useful
for
that,
even
if
it
doesn't
solve
the
quick
problem.
T
M
Linka
I'm
kind
of
sitting
on
the
fence
here
right
so
I
I,
wouldn't
use
it
because
I
do
not
see
use
case
really
but
I
guess.
If
someone
else,
he
believes
it's
useful
yeah.
Why
not
I'm
a
bit
concerned
about
again
we're
gonna
live
in
the
world
when
you
have
any
cost
in
your
prefix
and
any
cost
which
belongs
to
unicast
address
space
right
because
not
everyone
going
to
renumber
right.
But,
however,
there
is
one
good
think
about
this
and
I
don't
see
it
mention.
M
Can
you
draft
from
my
perspective
the
biggest
problem
with
any
cost
is
load
balancing?
If
you
can
say,
router
must
not
ever
use
L
for
information
for
load,
balancing
for
anycast
addresses,
I
only
use
Elstree,
slash
flow
label
or
whatever.
That
would
be
beneficial
right,
so
I
don't
need
to
explicitly
configure
that
and
it
would
be
done
out
immediately.
That
might
words
mention.
Can
the
draft
yeah.
W
T
House
isn't
forced
to
I
mean
house,
don't
have
to
do
anything
to
implement
this.
This
is
really
you
know.
It's
it's
a
remote.
What
a
remote
address
appears
like
so
host
could
treat
this
as
a
unicast
address
the
way
they
do
today.
I.
W
B
W
E
E
D
So
a
symmetric
ipv6
will
use
short
in
the
addresses
because
of
the
released
region,
which
is
tricky
of
the
MTU
and
the
big
and
bit
rate
and
a
bit
of
each
regions
and
the
compression
approaches
like
6lowpan
may
not
work
here
may
not
work
here
because
of
the
edge
routers
may
be
constrained,
so
a
symmetrical
ipv6
will
route
directly
on
shorting.
The
addresses
to
award
compression
and
decompression
hope
I
hope.
D
So
the
master
includes
defend
a
short
residence
in
and
see
the
rest
over
peace
as
prefix
lanes,
and
the
ribbon
field
can
use
the
short
addresses
for
interment
forwarding,
but
for
addresses
or
sight.
So
an
and
more
unnecessary
headers
can
be
alighted
through
using
a
flexible
header,
including
the
short
address
lanes
and
the
short
residence
is,
is
decided
to
men
by
two
men
when
the
network's
start
up
and
that
it
will
be
configured
into
or
learned
by
by
local
devices.
D
So,
for
configuration
a
new
tone,
the
device
as
SRA
here
means
a
short
route
address
for
our
a
map
from
our
a
message
and
in
generator
or
shorter
address.
Accordingly,
this
address
can
be
used
for
the
interface
address
only
only
for
passing,
validation
of
the
ad
or
rewires
the
D
ad.
If
not
then
regenerate
another
one.
D
D
For
outward
for
outward
communication
traffic,
the
key
to
be
master,
a
terrific
to
form
standard
standard,
ipv6
addresses
and
the
corresponding
operation
is
for
the
in
world
traffic.
Terrific
space
will
not
attend
to
to
introdu
main
communications
at
at
last,
considering
there
normally
be
few
outside
ipv6
ipv6
addresses
involved
so
as
soon
as
a
magic
ipv6
can
allocate
short
italic
interrogation
for
the
outsider
at
v6.
D
E
E
E
X
E
X
R
This
takes
us
back
Fred
Baker
here.
This
bake
takes
us
back
to
a
discussion
to
happen
before
ipv6
was
standardized
in
RFC
1883.
Should
we
have
a
variable
length
address
or
a
fixed
length
of
Jocelin?
There
were
proponents
of
each
side,
so
this
is
a
new
protocol
or
a
change
to
the
ipv6
header,
which
would
insert
a
length
field
and
a
pointer
to
where
in
the
address
are
we
starting
and
I
guess?
My
first
question
is:
how
does
a
host
know
where
the
edge
of
the
network
is?
R
X
X
C
Let
me
so
I'm
just
asking
a
question,
not
the
chair
question.
So
I
looked
at
the
draft
in
in
the
beginning,
it
talks
about
the
motivation,
funder
stood
this.
The
motivation
was
for
5g
networks
that
have
are
very
restricted
in
bandwidth
and
packet,
size
limits,
and
then
it
had
a
reference
to
some
sort
of
document
that
was
sort
of
it
talking
about
the
characteristics
of
5g
networks.
But
I
looked
at
that
document
and
I
didn't
see
anything
that
justified
the
assumptions
you
know
or
the
problem
that
this
was
attempting
to
solve.
D
C
Okay,
well,
I
think
there
would
have
to
be
a
lot.
You
know
I
think
yeah.
At
least
it
convinced
me.
You
have
to
convince
me
that
this
is
a
problem
that
needs
to
be
solved,
and
then
you
know
there's
like
we
have
a
zillion
different
ways
of
doing
compression
already
and
what
why
we
need
a
different
one.
So.
X
Growing
again,
I
mean
in
a
sense,
that's
why
we
took
this
drove
to
sizzler
6lo
as
well,
because
that's
the
business
and
we
didn't
get
asked
that
question
there,
because
they
understand
the
answer.
If
you
like
it,
it
probably
needs
more
context
for
people
or
not
in
the
6lo
world,
but
we
thought
we'd
better
mention
it
here
anyway,
since
we're
mucking
about
with
their
ipv6
packet.
For
that,
since
1883.
G
Suresh
krisshnan
as
the
responsible
ad
for
about
six
months:
six
law,
I
I
personally,
also
think
the
justification
is
not
clear
because
one
of
the
things
it
says
in
that
draft
is
like.
Oh
I,
don't
want
to
talk
about
cheek,
for
example,
right
because
there's
compression
overhead-
that's
not
like
obvious
to
me
at
all,
because
she
can
compress
even
higher
than
this
and
get
a
better
smaller
packet
format,
while
keeping
the
IP
header
pretty
much
intact
like
before
compression.
So
and
specifically,
what
bob
was
saying.
G
The
Phi
G
document
pointed
to
in
this
draft
is
a
user
plain
analysis
draft
which
talks
nothing
about
constrained
networks,
it's
more
about.
Okay,
do
we
use
gtp
or
SR
v6
and
all
the
other
mechanisms,
so
I
think
it's
a
wrong
reference
personally,
so
you
might
find
a
better
reference
for
it
and
probably,
if
you
look
at
like
NB
IOT
or
something
in
Phi
G,
maybe
you'll
get
a
better
reference.
I
think
that
was
Bob's
point,
because
I
know
about
this
I'm,
giving
you
a
better
option
for
a
reference
but
I.
G
Think,
like
it's
good,
that
six
man
is
aware
of
it,
but
it
probably
happens
to
happen
somewhere
else.
Maybe
six,
slow
or
lpy
on
or
somewhere
would
be
a
better
place
for
this
to
be
discussed.
I
I
know
you
presented
this
in
six
slow
and
so
but
but
the
point
is
like
I,
don't
know
if
there's
room
for
yet
another
compression
format,
that's
different.
Unless
you
justify
that
by
saying
hey.
G
X
U
Roger
sorry
Cisco
so
got
two-part
question
one
in
the
slide
and
mentioned
that
the
compression
decompression
algorithm
takes
resources
and
empty.
You
may
be
low
on
the
physical
MTU.
If
you
could
clarify
how
low
are
we
talking
about
them
to
you
and
how
much
resources,
consumption
for
compression
decompression
is
really
problem,
so
any
numbers
he
could
share.
That
would
be
really
useful
and
the
second
part
was
more
on
the
solutions.
U
If,
if
two
hops
are
exchanging
or
negotiating
the
value
for
that
n,
because
you're
calculating
128
minus
n,
how
high
the
end
could
go,
there's
no
binding,
there's
no
constraint
that
I
noticed
in
the
draft.
So
could
I
go
as
low
as
two
bytes
could
I
go
as
high
as
back
to
128
bytes,
so
the
negotiation,
even
if
it's
between
two
hops
and
then
it
goes
in
a
cascading
manner,
and
how
does
it
really
work
out
that
I
couldn't
really
follow
that.
D
Yes,
the
first
question
were
good.
We
will
finish
the
detail,
information
and
the
later.
Maybe
we
Explorer
explosed
each
in
the
drafts
and
for
the
second
one
and
then
you
should
in
creation,
will
induce
the
local
lanes
increase
and
not
a
decrease
so,
but
if
originally
domain
meant
to
make
it,
we
decided
to
use,
decides
to
use
two
B's
lens
is
okay,
but
the
total
security
system,
a
network
will
be
small.
C
Y
Y
We
all
know
there's
a
new
class
of
data
into
memory
techniques.
We
call
it
on
past
data
telemetry,
which
can
directly
collects
the
data
about
the
user
traffic
by
embedding
some
actual
instruction
header
into
the
packet.
It's
very
important
too,
for
ipv6
our
v6
to
support
om
and
application-aware
services.
However,
are
we
all
know
that
I
saw
due
to
the
SRH,
the
header
overhead
of
as
our
v6?
Y
This
function
is
the
under
our
each
underlying
table
or
some
per
Section
basis.
So
it's
it's
not
clear.
So
a
better
solution
is
use.
What
we
call
the
PBT
M
is
a
document
it
in
another
draft.
We
submit
it
to
I
PP
M,
so
the
basic
idea
is
that
we,
instead
of
insert
a
new
header
into
the
packet.
We
just
use
a
single
bit
to
mark
the
packet.
If
we
want
to
collect
any
data
about
it.
Y
The
user
traffic
is
dropped,
but
it
also
introduced
some
new
issues
like
we
do,
since,
if
we
have
a
bunch
of
a
postcard
sending
from
many
segments
routers
for
each
single
packet,
let
me
need
to
have
a
mechanics
to
correlate
this
postcard
and
also
there.
It
introduced
a
little
bit
higher
export
data.
Overhead,
because
each
piece
of
data
from
each
router,
you
will
need
an
independent
packet
and
also
you
do
need
to
configuration
because
there's
no
more
instruction
carried
by
the
packet
itself.
Y
However,
this
all
this
issue
can
be
correctly
solved
and
therefore
that
the
proposal
is
actually
quite
simple.
Since
we
already
have
a
flag
fields
in
the
Asajj
header,
then
we
can
just
a
borrow
one
bit
from
that
part.
It's
not
necessary
to
be
the
first
bit
any
bit.
Will
do
so,
but
use
this
single
bit
as
indicator.
If
you
ever
want
to
collect
the
unpassed
data
about
this
packet,
you
just
enable
that
bit
and
how
to
solve
the
packet
correlation
problem.
Y
There
are
some
common
measures
already
be
documented
in
our
postcard
based
email,
telemetry,
Draft,
and
here
for
as
actually
we
have
extra
advantage,
because
we
already
have
the
segment
list
and
which
can
help.
We
ask
to
order
the
postcards
correctly
and
if
we
need
some
extra
information,
such
as
a
flow
ID
for
the
flow
correlation
or
sequence
number
for
the
packet
correlation,
then
we
can
include
them
as
simply
as
a
tea,
always
in
SRH.
Y
G
Suresh
krisshnan,
so
not
speaking
as
a
tea,
but
as
somebody
who
has
an
inventor
elementary
implementation,
yeah
I
think
the
idea
of
having
something
in
the
payload
protocol
to
mark
in
bang
telemetric
collection
doesn't
scale
okay.
So
if
you
want
to
do
this
for
every
protocol
for
which
you
want
to
do
in
bond
telemetry,
it's
not
going
to
work
okay,
so
you
need
to
do
something
outside
the
payload
for
which
you
need
to
collect.
So
I
think
it's
not
the
right
approach,
100.
G
G
G
Y
Y
Y
Oh
I
I,
don't
understand
why
you're
saying
it's
not
required
because
sometimes
I
just
want
to
follow
the
path
of
this
packet
and
also
want
to
monitor
the
per
section
upper
segment
and
latency
or
no
any
other
application
use
cases
for
this.
If
I
want
to
collect
this
data,
I
have
no
other
ways
to
do
that.
So
you
have
an
active
and
a
passive
or
EMS
ER,
but
they
know
directly
give
you
the
user
package
behavior
no,
but
if
you
don't
have
any
sir
edge,
how
do
you
do
this?
Y
Y
Z
Y
Copy
of
the
packet
sorry
I
just
sets
they
submit
to
you
this
RH
and
then
it's
just
basically
notify
the
router
to.
Z
You
know
I
understand
yet
at
that
router
that
processes,
this
header.
It
sees
that
a
bit
is
set
yeah
and
then
it
does
some
special
something
or
other
yeah.
Okay
and
I,
don't
know
what
that
special.
Something
rather
is
right,
but
there's
a
bit
that
we
just
talked
about
earlier.
That
was
a
in
the
working
group
document.
That
does
that.
So
you
might
want
to
consider
whether
you
need
this
bit
or,
if
there's
something
else
that
already
exists
and
that's
without
understanding
how
you're
gonna
use
this
just
it
looks
like
the
same
thing:
yep.
AA
Okay,
go
so
hobby
I
added
some
clarification
regarding
the
usual
I
think
that
they
say
you
know
we
always
talk
about
the
I,
sorry
six,
because
we
in
fact
that
we
have
some
days
the
the
boundary
of
the
network.
Sometimes
we
think
I
sorry
six
me
you
was
further
limited
to
me
and
not
for
the
other
internet,
so
I
think.
Ideally
you
some
the
difference.
Yes,
oh,
and
also
this
one
because
I
you
mentioned
the
HTTP
package,
so
these
we
may
use
some.
The
HTTP
is
repaired
by
the
I.
AA
Sorry,
sixth,
no
in
some
limited
Otomi
for
the
mobile
transporter
like
this
one.
So
only
this
information
you,
the
is
the
exporter
in
the
mobile
transporter,
I,
think
this
is
the
scenario
but
I
think
if
you
think
may
be
more
general
for
the
HTTP
or
some
the
application
there.
If
you
need
a
some
days
director,
this
information
I
think
that
maybe
other
solution,
I'll.
AB
Thomas
rahi,
so
first
of
all,
I
agree
with
the
this
use
case.
I
agree
with
what
has
been
said
here
that
basically,
this
is
a
different
application
than
alternate
marking,
but
they
can
both
use
the
same
kind
of
trigger
at
the
end
of
the
day.
It's
a
trigger
for
doing
something
and
I
believe
it's
the
same
requirement
from
the
data
plane.
So
a
common
solution
can
be
found
for
both
yeah.
Y
AC
AC
AC
Ap
and
six,
and
if
that's
true
I,
think
we
first
need
to
flush
out
whether
ap
and
six
as
a
use
case,
is
actually
something
ITF
will
adopt
and
how
and
so
on
so
forth.
So
for
me,
I
think
we
shouldn't
rush
into
the
solution.
Space
every
tooth
first
is
the
use
case
and
how
is
applicable
and
how
it
will
whether
it
will
ever
use,
because,
if
a
PM
six,
you
have
lots
of-
let's
say
privacy
issues
and
stuff
like
that
which
were
discussed
yesterday
in
routing
working
group.
R
AA
I
think
are
now
they
say
now,
that's
the
two
things
and
you
now
you
certificado,
since
this
is
either
the
days
of
the
elementary
embedded
elementary.
So
these
are
you
the
Isar
past
level,
as
are
possible
years
as
yeah,
but
at
the
AP,
and
that
maybe
later
can't
combine
that
we
look
together.
That's
a
user
application
level.
I
think
that's
a
even
until
now,
I,
don't
think
the
cobbler
together
right.
G
On
so
description,
so
just
answering
Robyn's
point
right,
so
I
do
understand
why
you're
doing
the
postcard
base
telemetry
I,
just
don't
see
why
you
want
to
do
it
for
every
protocol,
because
if
you're
doing
this
for
s
rv6,
you
probably
had
to
do
it
for
NS
h
for
some
other
protocol.
That's
gonna
go
through
right,
but
if
you
have
it
outside
the
protocol,
it's
it's
similar
to
saying,
like
oh
I,
want
to
collect,
like
some
net
flow
information
right
from
from
a
some
kind
of
packet
and
the
packet
itself
has
a
bit
in
there.
G
U
Brad,
she
was
sorry
I
think
so.
I
see
that
in
it's
interesting
to
to
be
how
having
a
packet
can
way
that
hey
do
something
with
me,
yeah
and
related
to
what
Suresh
was
saying.
This
is
very
specific
for
si
v6
when
there's
an
SR
H
in
place
right
so
I'm
just
curious
to
hear
your
point
of
view.
Why
restrict
this?
To
that
specific
use
case?
Why
not
just
do
it
on
ipv6?
There
are
tons
of
deployments
out
there
just
with
native
ipv6.
U
Y
So
so,
if
you
look
at
our
original
draft
on
the
PBT,
when
we
talk
about
this,
we
actually
give
several
possibility
to
apply
this
in
several
different
other
protocols.
But
here
because
those
are
high
level
mastered
and
it
has
some
a
married
compared
with
IOM.
And
here
are
we
just
give
a?
If
you
want
to
apply
this
to
to
support
the
OEM
for
sr
v6?
How
you
can
do
that
so
then
we
need
to
find
a
place
to
hold
this
mark.
So
that's
a
proposal
here.
If.
Y
Y
X
X
X
X
X
Y
X
Pointed
Suresh
is
making
is
your
solution
is
only
Universal
within
a
domain
where
everything
is
encapsulated
in
and
has
a
certain
H.
The
other
raft,
which
is
an
I
ppm
draft
I,
guess,
would
work
for
every
ipv6
packet
in
the
world
if
we
decided
to
support
such
an
extension.
So
that's
the
that's
the
decision
that
somebody
needs
to
take.
E
Yeah,
thank
you
so
I
mean
this
is
a
lightening.
Draft
I
think
this
clearly
more
work
needed
here
and
certainly
coordination
between
I
ppm.
You
know
I'll
spring
for
this
case.
You
should,
you
know,
probably
sit
down
with
the
old
mark
authors
and
and
look
at
that
as
well.
I
mean
we.
There
has
to
be
some.
You
know
coordination
of
this
set
of
markers
in
packets.
You
know
for
sure.
Yes,.
E
Let's
continue
that
on
the
on
the
list,
so
we
are
actually
eight
minutes
earlier.
I.
Think
I
can't
remember
that
has
ever
happened
while
I've
been
co-chair
at
this
working
group.
Luckily
we
have
one
more
session
that
starts
at
1740
the
same
room.
Please
bring
popcorn
cause.
We
have
planned
for
a
very
entertaining
discussion
and
see
you,
then
interior
is
in
the
meantime,
but
it's
not
going
to
be
here.
There's
a
sea
bore
class
I.
Think
thank
you.