►
From YouTube: IETF104-6MAN-20190329-0900
Description
6MAN meeting session at IETF104
2019/03/29 0900
https://datatracker.ietf.org/meeting/104/proceedings/
C
B
B
B
B
You
know
there's
been
a
lot
of
changes
and
it's
been
a
long
time
since
we
started
and
people
should
review
the
whole
document,
but
at
least
speaking
for
Olli
and
myself.
We
would
really
like
to
get
this
done
in
six
map.
So
then
it
can
go
to
the
iesg
and
they
can
have
lots
of
fun
discussions
too.
So
any
comments
or
questions
on
the
agenda:
okay,
good,
okay,
Darren.
D
So
Bob's
all
about
sharing
the
joy
today,
good
all
right.
Oh
there's
the
screen
so
sr
header
revision
17,
like
like
bob
had
said,
we've
gone
through
a
lot
of
work,
a
lot
of
late
nights,
a
lot
of
discussions,
a
lot
of
very
significant
effort
by
a
good
number
of
people.
So
thanks
everyone
for
your
input.
It's
been
really
fantastic.
I
want
to
remind
you
of
the
quickly
the
collaboration.
This
isn't.
The
I
can
only
collaboration.
D
This
half
in
this
drafts
been
out
for
several
years
now,
five
years
since
first
implementation,
I
think
now
our
emails
are
at
105
1500,
so
maybe
more
than
one
line
protects
our
land
attack,
so
one
email
per
line
attacks.
So
thanks
this
week
for
that
we're
now
at
17
presentations,
this
one
included
alright.
So
the
collaboration
started
for
this.
D
This
particular
revision
of
the
draft
on
Tuesday
morning
I
met
a
good
number
of
folks
and
really
listen
to
what
the
underlying
issues
were.
Besides
just
what
was
kind
of
in
the
ticket
text,
because
that's
not
necessarily
what
people
are
most
concerned
with,
we
got
a
clear
definition
of
what
closure
looked
like
for.
Most
of
them
and
then
followed
up
with
some
prompt
resolution
on
the
list
and
that
continued
as
we
started
to
kind
of
work
through
the
items
all
week
and
learn
more
and
and
and
get
the
text
out
and
then
on
Thursday.
D
We
did
add
tracking
update
with
the
chairs
thanks
guys.
That
was
much
appreciated
where
we
were
able
to
go
through
and
close
a
whole
bunch
of
more
items
and
the
items
that
we
closed
during
the
week
were
some
tag
related
stuff.
Where
we
sent
out
some
gifts,
those
were
accepted,
the
SR
HT.
All
these
we
sent
out
some
deferred
owes
on
issue
38.
Those
were
good,
H,
Mac
was
verified,
covers
the
destination
or
revision.
17
was
acknowledged.
We
had
a
minor
one
for
moving
up.
Our
programming
was
acknowledged.
D
D
So
we
reverted
to
or
modified
the
draft
and
sent
out
gifts
to
use
the
xn
plus
y
type
of
alignment,
definition
or
alignment
requirements
and
then
allow
the
source
node
to
to
align
the
tlvs
as
necessary
in
order
to
meet
that
requirement
of
each
TLD
type
and
that
was
sent
out
that
was
sent
out.
Yesterday,
the
C
padding
one
by
Maya
this
was
closed
a
long
time
ago,
issue
number
55,
that's
actually
an
old
one.
We
need
that.
D
Well,
we
don't
need
to
do
anything
for
that.
It
was
close.
Quite
a
while
ago
we
added
the
pad
single
byte
pad.
There
was
some
muffs
language
and
should
must
an
SH
appear
ones
that
were
also
closed
long
ago.
So
I
consider
those
ones
closed.
Now
we
had
various
minor
issues
from
Adrienne,
don't
know
if
he's
here,
we
confirmed
the
ones
that
were
previously
existing
are
closed,
but
then
there's
a
whole
bunch
of
new
nets
that
that
were
brought
up.
These
are
all
primarily
editorial
in
nature
and
discs
were
provided
with
them.
D
So
we
don't
see
anything
more.
That
needs
to
be
done.
There
follow
the
diffs
67
on
padding
and
h,
mac
and
flags.
This
is
a
question
of,
is
the
support
or
is?
Is
the
m?
Is
an
implementation
required
to
support
tlvs
and
hvac,
and
the
answer
from
the
working
group
has
consistently
been
no
and
implementation
is
not
required
to
support
TL
vh
Mac
that
I
responded
to
in
association
with
this
question
as
well.
So
that
one
I
think
the
working
groups
responded
to
pretty
well
saying
it's
closed
469,
adding
in
the
leading
tlvs.
D
No
there's
no
text
in
here
that
talks
about
adding
and
deleting
tlvs
so
that
ideas
closed
the
next
one
was
for
the
SR
header
should
have
some
discussion
around
aah
and
discs
were
sent
out
for
that
saying
that
the
SR
header
for
the
purpose
of
computing
and
a
HIC
v
is
mutable,
which
means
the
SR
header
can
change.
So
what
H
does
is
it
will
zero
out
the
the
portions
of
the
SR
header
for
the
computation
of
the
age
ICB.
D
Number
seven,
a
local
policy
is
not
defined.
Oh
yes,
okay,
local
policy
is
not
fine,
so
the
term
local
policy.
Some
folks
have
had
an
issue
as
saying.
Well,
we
don't
really
know
what
this
local
policy
is
described
and
in
discussion
that
actually
came
down
to
well.
What
you're
really
saying
is
local
configuration,
we'd
be
happy
to
say
local
configuration.
D
D
E
Anything
from
the
chairs
perspective
will
certainly
say
you
know
thanks
a
lot
to
the
authors
and
the
reviewers
for
having
spent
a
lot
of
time
this
week
to
getting
everything
resolved
well,
feel
free
not
to
come
up
on
the
mic.
What
you
know
as
we've
started
with
our
plan,
is
to
with
all
these
issues
closed.
Consider
the
working
group
last
call
of
this
revision
of
it
done
we'll
reissue.
E
E
F
E
Right
so
for
a
completely
different
topic:
the
universal
RA
option,
which
does
require
a
bit
of
suspense
of
disbelief
just
like
when
you
read
a
science
fiction
book
to
accept
the
reality,
is
behind
it.
So
this
is
draft
I
posted
a
few
months
ago
in
response
to
some
issues
that
we've
seen,
which
is
to
follow
I'll
go
more
into
that,
but
it's
basically
this
view
that
which
is
a
reflection
of
of
the
idea
failing
getting
successfully
deployed
service
discovery,
in
my
view,
so
it
ends
up
with.
E
We
need
these
general
carriers,
DHCP
being
one
RA
being
another
from
signaling
information
or
carrying
any
information
from
the
network
to
hosts,
and
so
the
idea
was.
Can
we
make
this
more
generic?
Can
we
make
it
in
a
way
where
you
don't
need
to
change
the
route
or
implementations
to
add
new
information
objects?
E
And
likewise
you
don't
need
to
change
the
sort
of
core
RA
processing
engine
on
the
hosts,
and
you
don't
need
to
disturb
the
working
group
every
time
you
want
to
add
a
new
object,
so
the
proposal
is
is
make
a
universal
array.
Format
will
request
number
42
from
the
ini,
we'll
see
if
you
can
get
that
it's
a
CD,
DL,
concise
state,
the
description,
language
described,
objects
encoded
in
in
seaboard,
and
the
point
is
essentially
to
do
this,
so
you
can
on
the
network
side,
you
describe
your
objects
as
JSON
object.
E
We
can
argue
about
the
exact
formatting
of
this
or
you
know.
Currently
everything
is
text
string,
so
they
can
be
represented
in
Jason.
You
could
make
it
more
efficient
with
you
know,
binary
encoding,
the
it's
harder
to
represent
in
Jason
and
likewise
on
the
host
side.
A
user
application
interested
in
one
of
these
object
would
just
subscribe
to
a
key,
and
you
know
that's
x4,
for
example,
and
I
will
get
notification
from
the
RA
processing
engine
when
it
receives
objects.
For
that
key,
so
I
would
you
know
not
require
implementation.
E
So
this
is
an
experiment.
It's
twofold!
One
of
them
is
to
you
know:
how
far
can
we
get
away
with
not
requiring
an
IDF
specification
for
these?
You
know,
so
the
idea
is
to
put
most
of
the
description
and
most
of
what
you
need
into
an
eye
on
a
registry.
So
you
know
it
would
just
be
the
CD
DL
with
you
know,
either
reference
to
a
external
document
as
a
stable
reference,
or
we
would
just
have
the
description
in
the
ion
or
registry
itself.
E
So,
as
you
see,
this
is
a
fairly
neat
way
of
describing
RA
options,
so
the
problem
I,
you
know
with
or
I'm
trying
to
solve,
and
it
says
you
know
remember.
That
first
slide,
though,
is
we're
spending
an
inordinate
amount
of
time
arguing
about
you
know
these
configuration
objects.
If
they
should
be
allowed
to
go
into
Ras,
you
know,
half
the
people
say
as
well:
I
don't
need
it's
not
going
to
support
standardizing
it
and
it
takes
an
awful
long
time
to
get
it
standardizing.
E
So
the
suggestion
is,
you
know:
new
Ayano
registry
CDL
described
objects,
which
is
you
know
again
self-contained
into
the
INR
registry
or
a
stable
friends
and
just
expert
review.
You
know
so
you
needed
the
prep
sixty-four
option.
For
example,
you
will
just
fill
out
the
form,
get
that
into
Ayana
or
get
through
expert
review,
and
they
will
get
it
to
the
iron
ore
registry
and
you
could
implement
it
if
you
wanted
it
or
not
without
any
discussion
in
the
working
group,
and
so
the
experiment
is
along
two
axes,
you
know
it's
a
technical
one.
E
What
is
the
advantages
of
doing
a
self
describing
describing
format?
You
know
on
the
implementations
and
the
cost
of
doing
implementations
and
the
time
it
takes
to
deploy
things
and
it's
the
process
part.
What's
the
consequences
of
the
working
group,
stepping
back
and
letting
go
and
not
involving
you
know
these,
you
know
quality
checks
that,
hopefully
the
working
group
applies
to
these,
which
means
that
you
know
take
the
example
of
the
RA
only
flagged,
for
example,
which
you
discuss
for
it
for
a
long
time,
right,
lots
of
emails.
E
In
this
case,
someone
would
just
say:
well:
I
define
one
you
city
auntie.
You
could
of
course,
still
discuss
it,
but
it
would
still
be
there
and
available
right.
So
there
are
there
certainly
interesting
consequences.
It
has
been.
You
know,
I,
think
the
third,
the
email
not
to
point
point
out.
Anyone
but
I
think
the
third
email
was
say
it
was.
You
know:
eg
I
could
use
this
mechanism
if
I
love
live
another
you
know
in
are
s
messages
as
well.
I
could
build
new
protocols
this
way
right.
E
Yes,
you
can,
but
that's
hopefully
not
that
something
that
would
pass
expert
review
so
for
the
experiment.
The
proposed
time
is
two
years.
Your
finger
in
the
air
would
take
us
about
that
much
time
to
gather
information.
We
would
get
a
official
code
point,
so
it
doesn't
conflict
with
other
experiments
and
what
are
the
success?
Parameters
and
I?
Don't
know
I
mean
absolutely
no
use
of
it
would
possibly
be
a
success.
E
E
So
you
know
so
so
that
is
you
know,
but
you
could
close
the
registry
of
course,
but
if
lots
of
people
use
it,
it's
very
hard
to
put
that
cash
back
in
into
the
bag.
So
yes,
so
you
know
this
is
an
individual
draft.
The
discussion
I
was
looking
forward
to
especially
around
that
you
know
the
process
track.
It
seems
like
we
can
quite
quickly
agree
on
on
sort
of
the
technical.
You
know
modeling
language
encoding.
All
of
this
thing
has
been
discussed.
That
has
mostly
been
discussed
at
least
not
so
much.
E
G
So
this
would
simplify
describing
the
option
right,
so
it
will
be
much
faster.
However,
how
do
you
think
we
are
going
to
define
the
host
behavior
in
this
case,
because
I
don't
I,
do
not
think
that
are
we
spending
too
much
time
discussing
bits
and
bytes
and
the
options
I
think
the
most
discussions
are
normally
happening
around?
What
hosts
are
supposed
to
do,
and
in
this
case
it's
basically
unspecified
right,
so
I
would
be
very
concerned
about.
How
can
I
deploy
something?
If
I
don't
know
what
hosts
are
supposed
to
do?
E
G
Basically,
ipv6
only
flag
right
right,
I,
don't
know,
maybe
I
was
missing
sumption,
but
I
think
the
most
discussion
was
around
host
behavior,
so
one
flag,
what
few
bits
in
the
option
is
not
really
a
subject
Cashin
so
I
do
not
think
will
be.
It
will
would
have
helped
much
right
on
my
damn
wrong
here.
Well,.
E
For
that
particular
one
I'm,
not
sure
the
working
group
document
helps
right,
oh
right,
because
you
basically
ended
up
saying:
well,
it's
really
up
to
the
implementation.
What
did
the
implementer
think
makes
sense
for
that?
So
I
would
be
happy
for
that
one
with
a
single
line
of
text
which
says
you
know,
signal
system
of
e6
only
link,
but
you
know
that's
my
very
pragmatic
view.
So
right,
Jen.
H
Eric
Cline,
the
text
in
the
document
says:
if
you
don't
understand
an
option,
you
ignore
it.
So
there's
there's
that
bit
of
host
behavior.
But
if
you
define
an
option,
then
yeah
and
you
want
people
to
use
it,
then
you
should
definitely
have
a
document
to
say
what
to
do
with
the
option,
though
the
otherwise
it'll
be
ignored.
H
I
Hi
Tony
Polly,
so
speaking
as
one
of
the
PVD
authors,
because
you'd
mentioned
on
the
list,
hey
use
this
for
PVD,
so
in
general,
I
think
there's
actually
a
really
really
good
mechanism.
I
would
like
to
see
this
used
for
like
a
lot
of
basic
option
passed
through,
especially
if
all
you
really
need
is
the
host
just
like
passes
up
to
some
other
layers,
so
they
contribute.
It
seems
really
good
I.
I
Think
in
the
case
of
PVD,
specifically
I
think
that
is
a
little
bit
more
complex
of
case,
because
it's
specifically
meant
to
be
containers
other
options.
It
has
a
large
impact
on
the
host
behavior
when
they
have
to
manage
multiple
different
Ras
that
they're
getting
and
how
there's
interact
with
advice.
However,
I
imagine
one
of
the
things
that
we'll
want
to
do
in
the
future
with
pvd's
is
have
because
they
have
containerized
options,
have
more
options
to
extend
behavior
there,
and
those
should
all
be
this.
Definitely
so
I
think
they
complement
each
other.
I
E
J
I
just
wanted
to
add
Michael
Abramson
to
what
Thomas
said.
One
of
the
use
cases
for
PV
DS
is
four-legged
sales
to
not
understand
something,
so
this
would
mean
we
would
have
to
have
standards
for
all
the
normal
things.
Let's
go
into
an
RA
to
be
in
here
as
well.
If
we,
you
want
to
apply
this
to
the
PVD
case
right,
so
the
current
sort
of
so
if
I
want
to
send
a
Pio
to
a
PVD
aware
host
that
legacy
are
not
going
to
use.
I
need
to
have
Pio
here
in
the
new
format.
Yeah.
E
H
Eric
Clint
I
realize
now
we
also
need
an
our
flag,
I
think
it's
like
60
to
75
or
something
you
know
guys
take
another
flight,
video
yeah,
but
all
of
it
isn't
that
owner
is
right.
Now
I
I
support,
I
liked
the
extensibility
of
this
right,
adding
the
MTU
to
the
RI
o
was
a
nice
and
easy
thing
to
do
so.
I
do
think
that
if
this
is
popular
and
successful,
certain
things
we
may
net
neck
now
is
the
time
to
take
care
to
minimize
the
size
of
things
right
text
strings
for
prefixes.
H
H
E
To
that
you
need
a
little
bit
more
parsing
right,
so
at
least
you
need
it
would
be
nice
to
not
require
implementation
changes,
but
yeah
sure
we
can
say
you
know
with
the
v6
working
group
at
least
we
can
do
the
v6
addresses
in
binary
encoding
and
requires
support
for
that
on
the
routes
but
yeah
yeah
yeah.
Now
the
implementation
on
the
regicide
is
15
lines
of
code
right.
It
would
be
a
little
bit
more.
Thank
you.
K
L
M
Eric
green
idiot
of
I
just
said
to
David,
really
mad
man
I,
like
the
idea
of
course,
pretty
much
like
to
meet
a
thing.
Dvd
is
mm
coder
there
and
your
option
is
pretty
much
a
token
are
so
it's
not
one
or
the
other
and
the
last
one
and
we
preserve
buddies,
experimental
status
because
you
are
really
looking
for
something
which
may
stands
forever
or
you
will
get
no
implementation
in
host.
For
instance,
I
understand
why
you
say
experimental
yeah,
no.
M
G
E
I
mean
well,
so
these
examples
are
just
you
know
you
could
represent.
The
current
information
like
this
I
would
expect
this
to
be
used
for
new
objects,
which
only
exists
in
the
universal
RA
right.
So
if
people
want
and
part
of
the
experiment
is
getting
experience
with
what
the
hell
is
people
going
to
put
in
there
are
there
pitching
their
beach,
be
a
routing
table
there.
Perhaps
that
wasn't
a
good
idea,
we
should
shut
down
the
experiment
right.
G
So
in
the
second
comment,
like
I,
am
in
a
favour
for
experiment,
but
I
just
think
two
gears
my
baby
shot
because
I
wonder
if
it
just
me
or
getting
something
supported
on
the
Audion
platforms
and
getting
it
deployed
after
all,
this
qualification
might
take
slightly
longer,
provide
and
I
probably
would
not
have
great
devices
just
to
get
this
right,
so
it
need
to
fit
into
the
standard
lifecycle
management.
We.
E
H
H
E
O
E
They
are
a
mechanism
is
by
definition,
routed
a
host
right.
There
is
one
open
issue
of
you
know.
Should
it
be
allowed
to
go
also
in
host
to
router
to
signal
what
you
want
it
back
as
it
sort
of
a
DHCP
like
option
request
option
if
you
like,
or
you
know,
but
but
but
I
mean
Richard
ureter
protocols
are
aiso
not
well.
The
CP
case
is
special,
but
then
we
say
behaves
in
host
well
right,
so
it
depends
on
what
you
mean
by
router
to
router
thing:
okay,.
O
I
will
take
this
question
to
the
email
is
to
explain
what
is
router
to
router.
Allow
me
a
second
question
which
is
with
respect
to
judging
success.
Sometimes
success
comes
from
the
availability
of
software
tools
to
implement
various
things.
Now
we
talk
about
a
new
format.
Here
we
see
Jason,
we
hear
C,
Bar,
C,
DDL,
I,
think
I've
seen
also
sn1
I'm,
not
sure
the
syntax.
If.
O
B
P
Timmy
I
support
this
I
mean
the
the
protection
here
is
that
we
we
state
that
any
unrecognized
options
must
be
silently
ignored,
so
the
hosts
were
just
ignore
it.
My
concern
might
be
then
this
kind
of
an
implication
of
the
document
you
might
generate
or
need
extra
Ras
to
convey
information.
So
you're
going
to
increase
the
number
of
Ras
at
the
scene
on
a
network
with
the
obvious
consequences
of
that
a
little
NIT
in
the
document.
P
E
P
I
think
that
the
point
is
if
this
is
something
that
removes
the
barrier
to
people
getting
things
out.
There
then
having
a
look
at
in
the
last
few
years
as
if
we
can
do
it
easily.
I
sound,
like
I'm
volunteering
here,
so
just
to
see
what
sort
of
things
people
were
putting
forward
you
sort
of
can
wave
at
start
people
all
these
options.
It
might
be
nice
to
have
a
list
of
what
has
been
put
forward
is
a
right
draft.
I.
E
K
J
And
Michael
Abram
suggested
I
support.
This
I
would
just
like
us
to
look
into
the
implications
when
it
comes
to
the
MTU
I'm
worried
about
this,
and
some
of
this
actually
is
multicast,
which
it
has
implications
on
discussions
on
Wi-Fi
and
multicast
so
and
if
we
think
that
this
is
going
to
grow,
which
means
that
we're
going
to
send
more
unsolicited,
arrays
I
would
like
us
to
think
about
that
and
conceivably
come
up
with
something.
That
means
that
this
is
from
the
rocket
to
the
host
is
sent
as
a
unicast.
J
Because
if
we
think
that
this
might
have
for
a
while
turn
out
to
be
several
kilobytes
of
information,
it
might
be
better
to
just
keep
it
out
of
the
orient
and
invent
something
more
like
I,
don't
know
yeah,
but
whatever
we
come
up
with
so
a
new
DNS
SD
would
be
mentioned
here.
So
we
probably
need
to
figure
out
like
what
should
go
in
there
and
what
you're
going
so
I'm.
J
D
S
E
T
B
Right
good
I
mean
I
have
some
concerns
to
you
know
I'm
worried
that
this
is
we.
This
is
gonna,
become
very
popular.
There's
gonna,
be
a
lot
of
new
stuff,
they'll
be
very
little
barrier,
so
we
need
to
be
careful
about
how
what
we
require
to
be
specified,
but
it's
gonna
hit
yeah,
so
I,
don't
know
how
we
do
that
and
I'm
not
sure
how
to
thinking
about
it.
There's
a
lot
to
learn
here,
but
once
we
get
this
going
with
a
type
I
think
we
won't
be
able
to
stop
it.
B
E
B
A
Do
a
double
act
here,
so
we
all
thought
path,
MTU
discovery,
kind
of
work
because
it's
very
widely
implemented
and
it
does
work.
But
it's
not
really
useful.
It's
not
working
well.
So
we
need
something
better
and
there's
two
bits
to
this:
there's,
maybe
an
important
piece
of
the
transport
layer
and
actually
checking
what
works
and
verifying
it.
But
here
there's
a
hop
option
and
the
hop
by
hop
option
is
basically
something
new
that
we
came
up
with,
which
was
something
old
that
we
discovered
afterwards.
A
B
So
they're
the
new
draft
that
was
published
this
month.
We
changed
this
to
experimental
from
standards
track
where
I'm,
at
least
gary
has
convinced
me
there's
a
lot.
We
need
to
learn
before
we
try
to
do
this
permanently
or
something
the
original
draft
just
had
it
before
particular
domains.
But
you
know
this
is
there's
a
lot.
We
need
some
real
data
here
before
we
can
decide
what
to
do
add.
A
new
motivation
and
problem
solved
section
to
better
describe
the
purpose
and
started
describing
experiments
that
we
wanted
to
do
and
some
editorial
changes.
B
B
A
So
turns
out,
it's
possible
just
to
send
a
message
through
the
network
in
the
forward
direction,
asking
what
MTU
is
supported
and
then
we
can
figure
out
what
actually
is
deployed
and
then
we
can
start
using
this.
But
the
point
is
that
such
as
the
sender
who
needs
the
message,
so
how
do
you
get
this
information
back
to
the
source
of
the
ipv6
packet?
A
Well,
we
could
send
a
path
to
packet,
to
big
message,
an
ICMP
message
from
there
involved
right
back
to
the
source,
and
this
isn't
perhaps
as
stupid
as
it
seems,
because
we
do
get
other
ICMP
messages
back
from
the
remote
all
the
way
back
to
the
source,
because
they're
not
cherished
on
path.
Maybe
the
state
in
middleboxes.
A
Let
you
forward
these,
so
this
could
be
a
cool
thing
to
do
and
we're
interesting
people
opinion
on
that
and
particularly
measurements
on
where
that
works,
because
that
could
be
helpful
and
we
could
also
put
the
value
that
we
find
out
for
the
forward
path
in
the
same
pot
by
hop
option
using
the
return
path
and
return
that
value
back
to
the
sender.
So
the
source
knows
this.
From
extension,
header
option,
that's
got
different
failure
modes,
pretty
salsa
possible,
and
we
could
also,
of
course,
perhaps
easiest
of
all.
A
When
the
transport
does
it,
we
could
simply
put
the
value
in
a
transport
parameter
or
return
it
back
over
the
top
of
the
transport
possibly
encrypted.
If
you
have
something
like
quick,
you
just
simply
return.
This
is
a
message
size
value
back
to
the
source.
So
now
we
have
three
ways
of
getting
feedback,
which
complicates
it
makes
it
more
of
an
experiment
but
I
think
there's
good
possibilities
here
that
one
or
perhaps
more
and
might
succeed.
A
How
likely
is
it
that
the
hop
by
hop
option
will
be
forwarded
to
the
remote
node?
Remember
this
is
not
necessarily
a
data
packet
or
it
may
be
a
duplicate
packet
of
a
transport
protocol,
so
we
don't
require
it
to
get
there.
We
just
want
to
know
what
its
fate
is
is.
Does
the
packet
it
tick
with
the
hop
by
hop
option,
get
discarded
and
does
it
traverse
the
link
and
get
ignored
and
just
something
else
happen?
Maybe
he
actually
gets
updated?
How
likely
is
it?
A
The
ICMP
message
is
returned
to
the
source
way,
as
originated
from
the
endpoint,
but
its
rigidity
from
the
nor
to
rather
than
from
a
box
on
the
path,
because
then
you
don't
have
routing
issues
etc,
so
it
works
with
load
balancers.
How
easy
is
this
to
implement?
Aha,
we've
already
started
that
we've
been
doing
stuff
at
the
hackathon
and
we
had
quite
a
lot
of
fun
that
and
quite
a
lot
of
success
in
making
little
things
work.
A
So
this
might
be
a
really
good
place
to
drill
and
how
much
support
is
there
for
jump
or
friends
anyway?
One
of
the
motivations
here
is
to
fix
tunnels
where
you
get
less
and
less
m
to
you,
but
one
of
them
is
to
send
bigger
and
bigger
packets.
Now
we
know
Ethernet
MTU
in
its
in
homes
and
with
with
smaller
NICs
is
limited.
But
how
much
support
is
that
really
for
jumper
friends
out
there?
Can
we
actually
start
moving
up
to
that
and
I
think
there
are
more
questions.
G
Janene
Cova
I
was
just
realized,
so
you
don't
necessarily
have
to
get
make
it
too
big
back.
You
can
get
destination
unreachable,
and
if
enough
of
the
your
head
there
will
be
included,
you
can
actually
get
that
information,
even
if
you
know
doesn't
support
this
right.
If
we
know
doesn't
recognize
that
option,
yeah
I
think
that's
quite
cool,
yeah
and
I
am
still
going
to
give
you
some
data
on
the
probability
of
getting
that
was
an
old
yeah
yeah.
H
A
A
minute
I'm
I'm,
not
that
ambitious,
a
2k
4k
9k
16.
You
know
these
are
sorting
numbers
I'm
thinking
of
not-not-not
UDP
packets.
That
are
enormous,
because
the
MTU
option.
H
H
J
I
just
wanted
to
comment
on
the
MTU
Ethernet
CRC
calculation
start
to
break
down.
If
you
go
way
above
9
K
I
think
it's
around
10
11
12!
That's
where
you
start
to
risk
getting
bit
errors
that
are
not
detected
by
the
C
or
C
algorithm
in
news
so
with
and
since
Ethernet
is
eating
the
world.
This
is
like
a
practical
thing.
We
would
need
other
link
layers
to
larger
packets.
U
Yeah
for
a
template
from
Boeing,
so
I
know
this
was
close,
came
up
on
the
list
and
you
guys
responded
to
it,
but
in
1990,
RFC
1063
tried
to
do
exactly
the
same
thing
and
a
lot
of
people
put
a
lot
of
hard
work
into
it
at
that
time.
Frankly,
I
think
they
were
on
the
right
track,
which
I
think
you
are
too
I
think
what
happened
back
then
is
they
were
under
a
time
pressure.
U
B
A
C
K
A
K
B
Are
correct?
That's
the
status
code
today.
I
would
at
least
like
to
think
that
if
we
can
show
that
this
would
be
compelling
and
provides
better
overall
service
on
the
internet,
that
that
will
encourage
people
to
do
it.
I
don't
think
we
have
to
assume
that
implementations
will
never
do
anything.
They
don't
do
today
right.
K
But
let
me
also
make
the
argument
that
this
is
something
where
we
need
to
consider
making
it
as
easy
as
possible
for
routers
to
actually
implemented
it
and
I'm,
not
sure
that
the
nigth
option
is
the
best
way
to
do
that.
Maybe
maybe
it's
possible
to
find
some
way
to
transportus.
That
is
easier
to
pick
out
from
the
general
traffic
flow
by
by
the
raw
by
the
rotor
itself.
So.
E
W
A
Yes-
and
we
want
to
do
stuff
in
this
space,
to
figure
this
out,
however,
we
also-
or
at
least
I,
do
as
a
transport
person
assert.
This
is
only
a
hint,
so
we
would
have
to
have
a
transport
layer
mechanism
to
verify
the
bigger
packet
worked
or
not,
so
the
hint
would
be
completely
wrong
if
they
took
a
different
path,
and
we
want
to
know
about
that,
but
it
would
have
probably
derailed
the
transport.
R
What
do
you
think
about
I
mean?
You
said
that
transport
return
path
is
obviously
the
most
reliable
one,
and
so
you
mentioned
quick
and
clearly
quit
the
patient
on
the
table,
so
we
can
do
a
lot
of
things
to
it.
Now
there
is
another
transport
that
is
commonly
used
in
the
Internet
TCP,
and
what
do
you
think
about
opening
up
that
thing
in
and
maybe
adding
ability
to
set
MSS
after
handshake
could
be
used
very
useful,
for
your
purposes
could
probably
be
useful
for
others
too.
A
R
X
Jones
and
so
just
an
American
Davis
questions
on
implementation,
so
the
saga
API
exposes
the
hop-by-hop
data
it
comes
through,
and
this
is
how
we
did
the
Linux
implementation
of
the
hackathon
and
in
the
forwarding
paths.
The
hop-by-hop
option.
Processing
is
not
great
like
this
is
where
the
spiders
live
in
the
network
stack.
We've
never
done
anything
with
this,
and
but
it's
not
gonna
be
horrific
to
add
support.
So
we
could
do
this.
J
Micron's
and
so
in
my
twenty
years,
I've
seen
ICMP
the
TTL
expired
I
could
just
go
from
being
handled
by
the
cpu
to
be
done
on
the
line
card.
I
guess
then
fuses
all
have
you
talked
to
the
silicon
guys
but
doing
the
hop-by-hop
option
in
silicon
and
have
the
MP
you
been
up
to
they.
They
say
it
never
needs
to
get
punted
to
anything.
Intelligent,
not
yeah.
Okay,
because
I
think
that
was
a.
J
Be
very
valuable
to
make
it
sure
it's
silicon,
friendly
and
I
know:
I've
talked
to
them
and
some
they
can
look
like
128
bits
into
the
128
bytes
into
the
packet
and
I.
Don't
know
what
they
then
can
do.
But
if
you
can
do
this,
I
mean
we're
going
you're
going
to
have
to
handle
like
10k
100k
paid
PPS
of
these.
Y
Sorry,
I
I
definitely
agree
with
this
because
commentary
about
making
this
line
I'm
very
worried
about
in
general
that
we
losing
the
possibility
to
have
the
network
communicate
and
hosts
and
using
the
the
the
IP
layer,
so
the
network
layer
to
do
this
communication.
Otherwise,
you're
gonna
have
to
do
this
processing
in
hacks
in
transport
stacks
level,
and
that's
really
worrying.
For
me.
H
Yeah
I'll,
just
repeat
something
that
I
told
David,
Lampeter
I,
think
it
could
very
well
be
that
devices
that
already
knew
to
CPMs
s.
Clamping
can
easily
handle
this
and
devices
that
don't
won't,
and
that's
probably
plenty.
Okay
and
there's
another
way
to
use
this
in
conjunction
with
your
ongoing
with
an
ongoing
protocol
session,
and
that
would
be
to
just
basically
in
parallel,
send
send
this
option
from
the
source
to
the
desk.
With
no
next
protocol,
there's
like
49
or
something
C.
V
H
B
So
just
do
this
quickly.
So,
as
Tom
mentioned,
we
played
with
this
at
the
hackathon
last
weekend.
Was
the
Linux
host
implementation,
a
BSD
post
implementation,
VPP
router
implementation
before
a
router
implementation
and
I
did
a
Wireshark?
Did
the
sector
I
got
to
learn
bunch
of
stuff
overall
work
pretty
well,
but
we
decided
to
change
it.
Of
course
it
is
an
experiment,
so
we
did
a
version
that
this
is
not
in
the
draft.
So
this
has
a
return
value
and
a
return
flag
or
turn
bid.
I
guess
I
called
it
here.
B
So
if
the
source
wants
the
destination
to
send
back
the
MTU
it
received
in
a
hop-by-hop
option,
it
sets
the
flag
and
then
and
then
the
host
with
the
destination
would
put
it
in
the
return
value
and
in
order
to
keep
this
to
still
be
eight
bytes
to
not
have
it
grow
into
sixteen.
If
you
notice
we
take,
you
can
only
send
even
size
empty
used
back.
B
So
you
divide,
you
know,
so
it's
shortened
essentially
divided
by
two,
but
you
know
I
think
if
we
lose
one
one
bite
of
NTU,
it's
not
really
a
big
deal
and
keeping
this
short
seemed
like
a
good
thing.
So
that's
why
we
experimented
with-
and
this
is
what
it
looks
like
in
Wireshark
and
I've-
almost
got
this
completed,
except
for
it
notice.
It
doesn't
show
what
the
next
protocol
is.
Wireshark
is
a
little
challenging
when
you're
not
doing
the
end
protocol,
so
one
yeah
I'll
keep
at
this.
So
yes
continue
to
talk
to
us.
A
E
I
think
there's
a
lot
of
work.
You
know
interest
in
this
work.
It
doesn't
necessarily
have
to
be
that
this
is
a
solution,
but
I
mean
this
collaboration
that
we
now
have
with
the
transport
area
is
so
you
know,
I,
encourage
everyone
to
accommodate
up,
come
a
new
suggestions
for
that
marker.
This
is
kind
of
empty
Yuri.
Take
Rome,
don't
sit
there
like
you're,
not
going
to
run
up
here
and
do
your
twenty
minutes.
If
you
can
do
it
in
20
minutes
our
bio
beer.
Z
Z
Z
Sorry
VPN
compressed
center
yeah.
We
got
a
bit
keep
in
mind
the
segment
routing
header
that
we
just
approved,
because
this
isn't
the
same
same
line
of
thought.
If
you
take
a
look
at
network
programming,
you'll
find
that
there
are
two
classes
of
SIDS
Trant,
a
transport
Sid
that
steers
a
packet
to
a
terminal
segment
of
an
ipv6
tunnel.
It's
processed
by
the
non
terminal
segments
segments
left
greater
than
0
and
examples
of
these
in
the
SRA
char
end
and
end
X.
Z
There
are
a
little
relatively
few
of
these,
in
fact,
two
and
an
index,
and
their
semantics
is
very
simple.
Very
little
information
is
carried
in
a
transport
set.
By
contrast,
we
have
service
SIDS,
they
determine
the
behavior
at
a
terminal
segment,
they're
processed
only
when
segments
left
equals
zero
at
the
terminal
segment
and
examples
of
these
are
end
d,
x4
and
d
x6.
By
the
way
this.
This
is
all
familiar
to
folks,
who've
read
the
network
programming
draft
and
they're
relatively
many
of
these.
Z
They
have
a
very
rich
semantics
and
because
of
that,
it
takes
very
many
bytes
to
carry
them
in
any
event.
In
ipv6,
we
have
two
ways
to
deliver
instructions
to
downstream
nodes.
We
have
routing
extension,
headers
that
steer
packets
from
an
ingress
to
an
egress
they're
processed
at
non
terminal
segments
when
segments
left
is
greater
than
0
and
they
are
well
positioned
to
carry
transport
sets
and
by
contrast,
we
have
destination
options
that
determine
behavior
at
the
egress
they're
processed.
Only
at
the
terminal
segment.
Z
Typically,
they
take
8
bytes
of
overhead
4
bytes
are
mandatory,
mandated
by
8200.
Most
routing
headers
have
4
more
bytes;
typically,
they
represent
each
CID
in
16.
So
a
routing
header
with
three
SIDS
is
56
bytes
long
when
it
gets
much
longer
than
three
sets,
let's
say
six
or
eight
its
impractically
long.
These
aren't
ASIC
friendly
processing.
Long
extension
headers
is
computationally
expensive.
That's
one
of
the
reasons
you
don't
see
very
many
extent
routing
headers
on
the
Internet
today.
Z
Also,
they
impose
unreasonable
bandwidth.
Overhead
short
packets,
less
than
500
bytes
are
very
common
on
the
Internet
routing
headers,
with
three
SIDS
may
become
common
and
a
routing
header
with
three
SIDS
would
impose
a
10%
bandwidth
overhead.
So
where
are
we
going
with
this
we're
proposing
two
things?
First,
to
encode
transports
heads
in
a
new
compressed
routing
header,
and
we
talked
about
that
in
graph,
Bonica,
compressed
routing
header.
It's
a
topic
of
this
talk
and
we're
also
talking
about
encoding
service
SIDS
in
a
new
ipv6
destination
option.
Z
Actually
a
set
of
new
ipv6
destination
options,
one
of
which
is
draft
Bonica,
6-man
BPM
desktop
it's
the
topic
of
the
next
talk.
Now.
What
does
this
new
routing
header
look
like?
Well,
the
first
four
bytes
are
incredibly
familiar:
they're
mandated
by
RFC
8200.
The
fifth
byte
should
look
familiar.
It's
exactly
the
same
as
the
segment
routing
header.
It's
the
next
two
bits
that
are
new.
They
tell
you
how
much
we've
compressed
each
cid,
a
cid
can
be
represented
by
8,
16
or
32
bits,
and
let's
say,
we've
talked
about
all
this
stuff.
Z
Ready
comm
tells
you
whether
the
SIDS
are
8.
16
or
32
bits
each
sid
maps
to
an
ipv6
address
through
either
a
table
out
rhythm
or
look
up,
and
the
ipv6
address
is
copied
to
the
destination
address
of
the
ipv6
header,
just
like
any
other
routing
header.
The
interesting
thing
about
this
ipv6
address.
It's
a
real
ipv6
address.
It
identifies
an
interface,
not
a
said.
It
carries
no
semantics
beyond
what
RFC
42
91
gives
it.
So
for
those
of
you
who
were
in
love
with
packet
formats.
Z
Z
We
have
some
compliance
extras
here.
An
ipv6
address
semantics
remains
unchanged.
Once
we
translate
us
into
an
ipv6
address
and
copy
it
to
the
destination
address,
it
has
no
semantics
beyond
what
4291
gives
you
there's
no
need
for
transit
routers
ever
to
insert
or
delete
if
extension,
headers
there's
no
need
to
have
two
instances
of
the
CRH
in
the
same
packet
extension
headers,
a
process
for
Cle
in
the
order
that
they
appear
in
the
packet
no
need
to
backtrack
or
anything
like
that.
Z
The
status
we
have
multiple
operators
who've
expressed
interest
in
this.
We
have
prototypes
under
development
in
juniper,
both
on
the
forwarding,
plane
and
Isis
extensions
to
supports
it.
Advertisement
they'll
also
be
in
the
next
few
days,
BGP
well
BGP
advertisements
to
support
the
VPN
destination
option
and
what
we're
asking
for
is
wide
review
in
spring
and
six-man
and
after
some
review
a
call
for
adoption
in
six-man
working
group
anyhow
stop
for
questions
here.
So.
B
AB
AB
AB
Z
Z
Bpm
destination
option
here
is
the
anatomy
of
a
VPN.
You
have
pease
that
learn
routes
from
CES,
a
PE
advert
associates
the
egress
PE
associates
information,
VPN
context,
information
with
a
router,
that's
learned
from
a
seee
advertises
it
to
an
ingress
PE
when
the
ingress
PE
gets
a
packet
for
that
route.
It
prepends
VPN
context,
information
it
to
the
payload
it
puts
that
in
a
tunnel
and
sends
it
off
to
the
egress
the
egress
pops
it
off.
Now.
What
does
the
staff
look
like
when
it's
sent
across
that
tunnel?
Z
Z
Z
What
does
this
new
option?
Look
like?
Well,
it's
got
an
option,
type
act,
bits
or
would
not
recognize
this
guard
whoa
no
change
bit
a
zero.
You
have
variable
length
data,
and
so
you
can
encode
as
much
information
or
as
little
as
you
need
in
your
VPN
context.
Information
and
you
have
data
to
go
with
it
again.
The
status
we
have
operators
expressing
interest,
we're
building
prototypes
inside
juniper.
Looking
for
comment
on
the
mailing
list,
next
steps
same
thing,
wide
review
call
for
adoption.
Next.
Z
Okay,
we
have
a
new
option
if
you
want
to
elicit
OAM
from
a
packet,
you
put
this
that
option
and
either
a
hop-by-hop
a
destination,
a
destination
header
that
precedes
a
routing,
a
header
or
in
the
ultimate
destination,
depending
on
whether
you
want
away
M
information
from
every
hop
along
a
path
from
segment
end
points
only
or
from
the
ultimate
destination.
The
OAM
option
has
some
flags
in
it.
The
flags
elicit
of
behavior
from
the
processing
node,
the
behavior
is
log
a
packet
count.
Z
A
packet
send
an
ICMP
message
to
the
packet
source,
obviously
rate
limited
or
send
telemetry
to
your
NMS.
Now,
when
you
say
log
a
packet,
what
information
goes
in
that
log
message
as
much
as
the
processing
node
can
put
in
it?
It
might
have
a
very
accurate
timestamp,
but
if
it
can
do
it,
it
might
have
what
port
it
came
on
and
on.
If
it
can
do
it
whatever
it
can
do
the
same
for
counters.
Z
What
counter
does
it
go
into
whichever
one
the
processing
node
is
configured
to
put
these
B's
in
the
policy
can
be
as
complex
or
as
simple
as
you
need?
What
does
the
packet
look
like?
Well
like
this,
the
interesting
thing
is
the
act.
Bits
are
0
0
skip
it.
If
you
don't
understand
it,
the
change
bit
is
0.
Z
Z
Ok,
this
one
is
just
for
completeness.
We
don't
expect
it
to
be
used
very
often
at
all
what
happens.
Remember
the
first
message
where
we
had
the
CRH
that
had
these
very
narrow
bandwidth
SIDS
along
the
way.
Well,
what
happens
if
you
want
to
use
a
CRH
and
you
have
a
high-bandwidth
sit
in
the
middle?
Well,
we
have
this
thing
called
the
segment
end
point
option:
it's
to
convey
information
to
selected
end
points
in
a
service
cheat.
So
let's
say
you
have
a
service
chain
with
five
elements
in
it.
Z
You
want
to
get
information
to
element,
3
and
element.
4
you
put
a
destination
option
header
in
front
of
the
routing
header,
it's
processed
by
every
segment.
End
point:
you
put
this
new
option
in
the
destination
option:
header
it
has
a
segments
left
field.
It
gets
decremented
just
like
the
segments
segments
left
field
in
the
routing
header.
Z
Z
Segment
identifier
in
the
middle
of
a
CRH
now
do
we
expect
this
to
be
used.
Often,
no,
in
fact
you
might
choose.
If
you
have
a
path
that
has
a
high
bandwidth
said
in
the
middle
of
it
to
use
an
SRH.
So
for
some
paths
you
might
use
an
S
RH,
because
you
need
that.
You
need
that.
For
others
you
might
use
a
CR
H,
but
if
you
just
have
maybe
one
segment
in
the
middle
of
it,
that
has
a
high
bandwidth.
Z
E
P
Q
Is
a
session
about
getting
beer?
Do
you
just
apply
for
lightning
talks
to
get
beer?
Okay,
that's
the
method
to
go
wine
beer
out
of
you
cool
all
right.
So
this
is
a
quick
ask
to
IP
from
IP
p.m.
to
six
men
working
group
to
go
and
give
us
some
guidance
on
how
to
proceed
with
IOM
in
ipv6.
So
hopefully,
everybody's
seen
I
am
in
a
nutshell.
Q
So
the
ass
two-six
man
from
IP
PM
is
really
we
want
to
go
and
carry
the
metadata
in
extension,
headers,
and
we
need
option
type
Co
points
both
for
hop-by-hop
as
well
as
destination
options,
depending
on
how
we
carry
these
things
and
well,
we
need
this
thumbs
up
yeah.
It
goes
the
same
way
as
what
was
done
for
TBM
PDM
earlier
on
that
ended
up
in
in
an
IP
PM
shepherd
at
our
of
c.
So
I
do
250
so
that
we
can
go
and
progress
that
work
in
IBM.
Q
So
what
do
we
want
to
go
and
do
we
have
right
now
in
iom?
We
have
four
types
of
data
that
we're
encapsulating.
Two
types
are
tracing
data
which
is
pre-allocated
tracing
or
incremental
tracing.
That
would
go
into
an
hop
by
option.
We
have
proof
of
transit
data
ie,
proving
that
your
program
progressing
through
a
predefined
set
of
nodes
and
that
we
have
a
edge
to
edge
option
which
is
just
encapsulated
at
one
point.
M
Q
Book
that
throughout
the
network
and
then
D
capsulated,
the
other
node,
which
is
what
we
need
a
destination
option
code
point
for.
So
the
ask
is
readier:
well,
we
have
a
set
of
metadata
defined
that
is
already
defined
in
a
draft
and
a
working
group
draft
in
AI
ppm,
and
we
want
to
go
and
drop
that
into
extension
matters
that
isn't
without
problems
right.
Q
So
after
we
we
started
the
working
group
discussion
prior
to
the
ITF
meeting
in
Bangkok
at
that
spurred
a
bunch
of
additional
questions,
and
so
we
thought
like
yes,
just
asking
for
coat
points
is
one
thing,
but
in
addition
to
that,
you
want
to
go
and
have
deployment
considerations
that
go
on
top
of
that.
Q
So
if
that
information
would
go
or
the
extension
header
would
go
somewhere
where
it
shouldn't
go,
then
well,
someone
should
be
able
to
go
and
detect
and
then
obviously
ward
on
are
gonna
go
to
ear
to
what
is
it
said
in
8200
ie
not
inserting,
instead
extension
headers
on
the
fly
and
what
the
deployment
option
drafts,
what
they?
What
the
Department
RAF
then
talks
about
is
a
couple
of
individual
use
cases
on
how
you
can
skin
that
cat
with
one
or
the
other,
trying
trade
off.
Q
If
you're,
sourcing
and
terminating
packets
right
at
the
host,
then
you
don't
need
double
n
cap.
You
can
insert
the
header
there.
You
could
terminate
the
header
at
the
destination
in
transit
networks.
If
you
just
want
to
go
and
do
it
on
one
particular
individual
domain,
then
well,
there's
multiple
source
of
what
I
would
call
double
n
cap.
You
can
do
ipv6
and
ipv6,
and
there
is
options
whether
you
use
a
dedicated
EULA
address
in
the
overlay,
so
that
well
even
if
packets
leak,
they
can
never
have
a
leak,
because
I
can't
be
forward.
Q
If
there
is
no
seeing
an
eroding
up
for
them.
We
could
also
choose
for
a
different
option
where
we
would
use
the
same
destination
address,
which
makes
it
easier
to
make
the
path
of
congruent
and
then
obviously
you
could
use
other
parent
protocols
to
go
and
carry
that
information.
So
you
don't
need
necessarily
need
v6
and
v6,
but
if
you're
going
to
go
and
carry
the
information
in
genève
well,
you
can
go
and
carry
it
somewhere
else.
I
want
to
go
and
come
back
to
the
main
ass
right.
Q
We
we
really
asked
you
to
go
and
help
us
so
that
we
can
unlock
the
work
and
progress
it
in
I,
ppm
and
I.
Don't
know
well
know
whether
Tommy,
who,
by
believers
here
the
chair
of
I
ppm,
can
add
additional
color
to
that
particular
ask.
Maybe
you
can
go
and
give
us
a
little
bit
of
background
off
the
discussion
that
we
had
on
on
Monday
on
that
very
tough
topic,
and
that's
it
for
me.
Thank
you
sure
thank.
I
You
Frank,
yes,
I,
think
the
question
and
the
feedback
we'd
like
to
get
from
both
the
chairs
and
the
group
in
any
any
basic
comments
are
welcome,
is
what's
the
most
appropriate
place
to
do
this
work
in
the
past.
We
have
done
work
outside
of
six
men
we
wanna
see.
Is
that
appropriate
to
do
here?
How
much
do
we
want
to
do
here?
What
type
of
relationship
do
we
want
to
do
on
the
work?
As
far
as
the
review
I
think
from
our
perspective,
we
are
fine
doing
this
particular
part
of
the
work
in
IPM.
I
The
IOM
work
in
general
has
a
lot
of
different
encapsulation
possibilities.
This
is
one
of
the
protocols
that
uses
it.
Some
of
those
will
make
potentially
more
sense
to
belong
in
the
working
group
that
owned
the
protocols
that
they're
encapsulating
with
something
like
this
I
think
is
a
bit
more
well
understood
and
I
think
we
could
feel
confident
doing
that
in
IPM.
I
If
that
is
what
the
ring
group
believes,
is
the
right
thing
to
do,
but
if
Britain
group
believes
that
this
should
all
be
specified
in
six
men
and
be
done
here,
we
would
like
to
know
that
as
well,
so
we'd
like
to
essentially
just
get
an
answer
of
what
is
the
right
place
to
pursue
this
work
in
if
it
needs
changes
in
review?
That
can
happen
in
the
future,
but
I
think
the
main
thing
we
want
to
know
right
now
swear.
AC
Shooting
from
flowey
I
think
here
we
all
agree
that
we
should
be
carefully
later.
The
ipv6
encapsulation
of
the
IOM,
and
but
here
the
proposal
is
we
are
proposing.
Here,
is
like
to
put
the
hem
data
into
the
hopper,
how
about
that's
Tunisian
option?
But
if
we
look
at
the
ipv6
extension
header
order,
that
is
before
the
RH,
so
in
the
tracing
mode,
the
the
IOM
data
along
the
path
is
going
to
become
very
large.
AC
So
we
are
going
to
push
the
RH
out
of
the
parsing
deaths,
and
so
that
will
damage
the
performance,
the
forwarding
performance
in
the
data
plane
and-
and
we
also
have
them
the
same
thought
on
this
topic-
and
we
that
was
in
the
agenda.
But
we
didn't
get
the
slot,
but
fortunately
we
are
going
to
present
in
the
next
session
in
the
RTG,
so
probably
that
we
could
contribute
and
provide
some
more
thoughts
on
this
topic.
E
J
J
Q
The
draft
right
how
about
that?
So
we
better
straight
up
so
all
of
that
right,
but
we're
trying
to
go
and
mitigate
these
concerns
as
much
as
we
can.
If
there
is
other
deployment
options
that
can
be
considered,
let's
go
and
consider
them.
There
was
no
free
lunch
right.
So
that's
something
you
changed
some
and
if
we
were.
X
Q
I
think
that
was
the
overall
question
on
guidance
on
where
we
should
go
to
the
work
right
now.
Well,
they're,
the
core
of
the
work
is
really
an
IP
PM.
This
is
where
the
data
draft
happens.
This
is
where
export
considerations
happen.
This
is
where
the
yang
models
are
being
done.
There
is
a
load
of
documents
against.
How
do
you
encapsulate
that
into
multiple
protocols
also
presented
in
IP
p.m.
at
that
one?
Q
Well
in
particular,
and
this
is
again
had
jumping
between
these
two
deployment
considerations
could
go
to
v6
ops,
I,
think
it
helps
if
we
have
a
way
that
we
think
help
keep
some
consistency
and
the
energy
of
the
people
that
really
care
about
that
in
a
relatively
concise
forum.
Right
now,
but
I
feel
it
a
little
bit
like
I'm
on
a
dating
tour
and
I
have
to
go
and
kiss
every
single
bride
and
figure
that
one
out
not
that
I,
don't
like
that
right,
but
enjoy
it,
because
you
are
yeah
at
some
point
right.
S
Bob,
so
the
idea
is
like
Michael
I'd
personally,
for
me
like
this
should
go
and
I
am
the
work
should
be
done
in
IP
p.m.
and
the
way
is
six
shot
at
us.
Like
six
man
gets
like
final
say
over
whether
this
gonna
work
so
I
think
it's
better.
That
he's,
like
you,
know,
talk
about
this
in
six-man
and
see
if
there's
like
some
showstoppers
before
starting
the
work,
rather
instead
of
like
coming
back
during
like
the
end
of
the
IETF
call
right.
So
that's
really.
S
J
R
AA
J
Get
headphones
on
sorry
again:
I
think
the
people
who
might
be
able
to
give
feedback
I
say
if
you
do
this
to
the
packet.
This
will
happen
in
the
network
that
those
people
would
be
basic.
Selves
would
be
a
good
place
or
here
I.
Don't
think
those
people
will
go
to
I
ppm
and
give
you
good
answers
there.
I'm
sorry.
Q
L
Me
I
could
have
in
the
responsible
transport
85
BPM.
Yes,
we
want
this
feedback,
please
give
it
to
us
now,
but,
like
we
all
say,
like
I
mean
we
take
the
feedback,
we
try
to
address
it
and
then
we
need
to
move
and
it's
on
at
some
point
right.
So
either
you
make
a
decision
here
that
this
is
like
something
that's
really
important
for
you.
You
want
to
work
on
in
this
working
group.
Then
you
can
have
it
or
you
provide
us
some
feedback
now
and
we
can
move
on
in
I
ppm.
E
From
a
Cheers
perspective,
I
think
we
would
happy
to
have
this
in
AI
ppm.
I
think
we
would
be
also
happy
to
review
the
format,
and
you
know
help
you
if
you
need
an
early
allocation
request
for
a
cold
point,
for
example,
that
we
would
be
involved
in
that.
But
I,
don't
know,
Bob
I,
don't
mind
this
being
owned
by
our
ppm
for
sure.
Can.
L
R
Q
A
good
point
and
I
gained
feedback
from
my
ppm
there's
two
things
that
are
mixed
up
right
now.
One
is
take
things
and
record
it,
and
the
other
thing
is
an
instruction
to
do
something
in
most
of
these
cases,
the
instruction
to
do
something
is
take
a
copy
of
the
packet
or
take
a
portion
of
the
copy
or
something
from
the
packet
and
send
it
somewhere.
Well,
maybe
to
local
author.
R
Q
Q
Of
fine
if
the
device
can
manage
it,
but
maybe
to
some
node
in
the
network,
but
I
think
that
is
there.
That
is
where
I
think
the
intersection
between
the
Wigan,
our
ppm
and
Ron's
draft
is,
and
we
already
had
a
discussion
that
we
want
to
go
on,
find
a
way
to
go
and
consolidate
that,
and
also
take
these
active
things
out
into
different
draft
and
separate
them
out
from
just
the
recording
portions.
So
I
think
that's
been
surfaced
and
it's
gonna
be
addressed.
Thank
you
for
that
yeah
internet.
A
Gouri
first
tell
us
going
back
to
the
internet
rather
than
dating
there.
We
go
some
of
the
basic
problems.
You've
got
someone
here.
The
basic
questions
you
have
are
the
same
as
Bob
and
I
had
so
there's
that
there
is
a
two
part
problem.
A
One
is
doing
the
OEM
stuff
and
measurements
and
the
other
one
is
kind
of
what's
works
in
the
Internet
and
I'm,
not
sure
how
we
get
the
clue
for
both
of
them
in
the
same
place,
because
the
two
different
communities
and
so
happy
to
coordinate
in
some
way
or
go
to
mahadji
and
present
some
data
and
mix
all
I'm
saying
is:
please
don't
lose
the
fact
that
other
people
might
be
doing
something
similar
and
we
can
all
learn
from
the
same
experience,
yeah
and
I.
Think
next.
Q
E
B
Actually
so
the
reason
we're
ahead
of
schedule
dispose
of
Darren
at
the
beginning,
because
we
had
a
lot
more
time.
We
expected
that
to
go
longer
so
well,
good
I
think
we
are
done
so.
This
concludes
today's
six-man
meeting.
Please
continue
these
discussions
on
the
mailing
list
and
we
will
see
you
all
in
Montreal.