►
From YouTube: IETF105-6MAN-20190725-1550
Description
6MAN meeting session at IETF105
2019/07/25 1550
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
A
repeat
of
the
first
session
we
have
Barbara,
that
is
taking
notes
for
us.
I,
believe
shipping
is
take
being
the
Jeffers
Krab.
Thank
you
very
much
blue
sheets
are
going
around.
Here
is
the
agenda.
We
have
two
working
group
drafts,
it's
the
or
so
well
items
it's
the
fragmentation
of
router
well
and
going
through
those
together
with
the
ad.
It's
the
press,
64
work
and
we
have
a
set
of
active
individual
drafts
that
we'll
go
through
and
then
a
set
of
lightning
talks
afterwards.
A
I
also
wanted
to
mention
that
during
our
working
group
chair
meeting
on
Wednesday,
the
RFC
editor
updated
us
on
the
RFC
format
project,
and
this
is
something
that
is
going
to
come
to
all
authors,
that
the
format
we're
moving
to
be
three
of
the
format's.
So
there's
a
new
version
of
the
XML
to
RFC
tool
and
there's
now
some
small
changes,
including
you
know
you
can
SVG
graphics
lists-
have
changed
a
bit
and
you
I
can
even
put
my
surname
incorrectly
now
with
the
Oh
/
of
yours.
B
B
And
it
included
fragmentation
updates
from
for
RFC's
and,
as
the
documentary
was
quite
challenging,
to
bring
all
that
in
and
have
coherent
text
and
I
think
based
on
the
errata
I
think
they
didn't.
We
didn't
quite
succeed
in
doing
that
correctly,
but
it
required
extensive
changes
to
the
fragmentation
text
and
errata
for
over-many.
That
is,
a
bunch
of
errata
were
filed
in
you
know,
October
of
the
same
year,
and
it's
taken
a
while
to
get
around
to
look
at
them
very
closely.
B
B
So,
but
let
me
first
talk
about
the
last
errata.
That's
the
simplest
one,
so
the
the
auto
proposed
changing
the
figure
of
the
reassemble
packet
from
the
the
first,
the
date,
the
stuff
after
the
extension
and
upper
layer,
headers
from
first
fragment
data
to
first
fragment
I.
Don't
believe
this
is
actually
correct,
because
it's
not
the
whole
first
fragment
it's
the
just
part
of
it.
So
I
think
it's
actually
correct
to
say
data.
That's
why
it
was
done
that
way.
So
I,
don't
think
that's
a
change.
B
We
should
make
so
I'm
gonna
go
through
the
direct
text,
changes
based
on
Narada
and
and
then
we
Olli
and
I
have
been
looking
at
this
and
he
meant
to
suggest
in
which
I
like
that
is
a
different
way
of
solving
this
problem.
So
the
first
one-
and
this
is
the
one
that
was
missed-
it's
on
the
it's
on
the
first
page
of
the
document
where
it
defines
fragment
offset
and
and
that
that
also
has
the
same
problem.
B
So
instead
of
relative
start
of
the
fragment
fragmental
part,
it
should
be
relative
to
the
start
of
the
extension
and
upper
layer.
Headers
I
mean
so.
The
changes
are
mostly
all
like
this.
The
next
one
is
on
page
eighteen,
second
paragraph
from
the
bottom
again,
changing
it
to
be
relative
to
the
start
of
the
extension
and
upper
layer
headers
and
the
third
one.
It's
also
at
the
same
same
kind
of
change,
page
19,
fourth,
paragraph
from
the
bottom
same
sort
of
change
and
the
last
one
is
slightly
different.
B
B
So
let's
get
the
doors
closed.
Please
so
another
approach
I
mean
this
text
is
very
awkward,
and
so
this
is
actually
all
the
credit
for
this
and
I
like
it
a
lot,
no
for
the
a
better
way
of
writing
and
then
what
I,
I
and
well,
we
all
came
up
with
since
you
all
approved
this
and
the
ad
reviewed
this
and
the
is
G
we've.
B
You
know
this
sort
of
interesting
that
it
got
this
far
this
way,
so
the
the
problem
was
caused
because
we
added
extension
and
upper
layer
headers
to
the
figures
you
know
and
a
few
places
in
the
text.
So
the
the
tail
out
of
the
text
is
talking
about
the
figures,
and
so
the
PID
a--
here
is
to
fix
that
the
the
fix
the
place
in
the
text
where
it
actually
tells
you
to
put
put
the
extension
and
upper
letter
hair
headers,
is
actually
only
in
the
circle.
B
It's
like
part
two
of
the
text
where
it
says
how
to
create
fragments,
yeah
or
articularly
how
to
create
the
first
fragment
and
that's
where
it
says
it.
So
all
these
observation
was,
if
you
go
back
to
the
the
text
and
the
figures
from
before
we
did
this
change,
that
it
actually
gets
a
lot
simpler
and
you
just
add
the
words,
make
it
very
clear
in
the
text
where
you're
creating
the
first
fragment,
and
so
we
took
a
cut
at
this.
So
I
have
three
page
I:
don't
can
you
read
this
okay?
B
B
B
The
you
know
the
figure
is
now
back
to
per
fragment.
Oh
that's
well
sharper
on
my
screen,
but
yeah
you
can
see
it
changes
it.
It
takes
away
the
extension
and
upper
layer
headers,
and
it's
just
talking
about
it,
the
text,
and
so
you
know,
and
then
there's
also
some
changes
to
the
text.
Let
me
just
go
yeah:
if
can
you
assume
it
back?
Oh
there.
A
B
We
need
to
higher
resolution
displays
yes,
so
this
is
the
next
page
and
you
can
see
it's.
These
are
just
changing
the
figures
and
and
then
so
the
text
in
it.
Sorry,
it's
actually
it's
sort
of
the
bullet
three
where
it's
a
it
starts
talking
about
extension
headers,
because
that
it's
not
just
it's
not
just
done
in
the
I
mean
there
is
actual
text
that
says
what
to
do
so
move
the
this,
the
paragraph
that
defines
what
these
you
know.
What
of
what
except
the
extensions
headers
are,
and
you
know,
upper
layer
headers.
B
The
definition
that
was
a
writ
was
in
the
current
document
earlier
here,
but
it
fits
here
very
well
because
you
can
see
the
beginning
of
that
paragraph
says:
extension
headers
if
any
and
the
upper
layer
headers.
So
these
you
know
and
the
headers
must
be
in
the
first
fragment-
that's
that's
the
behavior,
we're
looking
for
and
then
I
think
there's
one
more
yeah,
and
then
this
is
also
just
makes
the
figure
of
what
the
reassemble
packet
looks
like
a
lot
simpler
so
and
then
yeah
there's
something
at
the
end.
B
But
that's
just
a
remnant
of
me
trying
to
produce
a
zero
and
no
one
draft
to
be
able
to
see
the
changes
to
be
able
to
do
this
diff.
So
I
I
think
this
is
a
much
better
approach.
I
think
it
actually
makes
the
document
simpler
and
but
it's
still
correct
and
it
still
makes
the
check
you
know
he
continues
to
change
that.
The
the
extension
headers
and
the
first
upper
layer
header
are
in
the
first
fragment
just
because
that
that
was
actually
tacked.
It
wasn't
in
the
fig.
You
know
it
wasn't
the
figures.
B
Figures
were
there
to
illustrate
it,
but
it
was
you're
actually
go
back.
I
mean
it's
it's
this.
You
know
item
three,
that
you
know
it's
defining
how
to
create
the
first
fragment.
That's
where
the
real
protocol
definition
was,
and
if
you
notice
that's
not.
There
wasn't
a
problem
with
that
text,
so
it
was
the
text
that
was
trying
to
explain
the
figures
and
where
the
pieces
were,
and
that
just
gets
a
lot
simpler.
If
we
go
this
way,
we
unfortunately
didn't
figure
this
out
the
first
time
around.
B
That's
pretty
good,
so
we
think
that
the
alternative
approach
is
actually
better
than
making
the
specific
changes
to
the
text,
which
in
some
ways
makes
it
more
complicated.
We
clearly
think
that
the
working
group
needs
to
review
these
carefully.
We
don't
want
to
do
this
again,
and
it
might
actually
be
good
for
someone
to
spend
some
time
and,
with
you
know,
the
text
that
we
agree
to
make
sure
actually
go
and
see
if
improve
it,
implement
this,
and
if
it's,
if
it
works
in
the
way
it's
supposed
to
Joe
I.
D
B
B
The
first
is
and
but
so
the
first
is
to
accept
the
errata.
With
the
changes
here
and
and
market
held
for
document
update,
we
would
need
to
figure
out
how
to
describe
either
just
include
a
whole
new
section
of
text
or
or
what
the
changes
are,
and
you
know
it's
I
mean
you
can
imagine
having
a
script
that
actually
you
apply
to
the
old
text,
but
that's
well
maybe
problematic,
maybe
it.
But
you
know
there
are
three
different
errata
here.
So
it's
a
little
complicated.
B
B
They
will
see
the
new
text
and-
and
that
I
think,
has
the
nice
part
about
tying
the
changes
to
the
current
spec
and
there
is
a
new
set
of
errata
tools
that
are
I,
think
being
I'm,
not
sure
the
exact
status
but
I
think
they're
coming
pretty
soon,
and
this
may
give
us
some
better
ability
to
do
this.
The
next
approach
is
to
publish
a
new
RFC
with
you
know,
basically,
an
update
that
updates
section
4.5,
the
part
that
defines
the
fragmentation
header
of
8,200.
B
You
know
it
just
says
this
replaces
you
know,
replace
a
section
4.5
with
this
text.
You
know
so
it
would
be
a
complete
set
and
then
the
8200
would
point
to
the
updating
document
and
then
the
last
change
is
to
just
do
a
whole
RFC
8200
bits.
Obviously
it
would
be
published
with
some
other
RFC
number,
so
my
recommendation
is
to
either
either
do
the
you
know
find
the
best
way
to
do
it
in
the
errata
system
or
publish
a
new
RFC
that
updates
8200.
Of
course,
I
know.
B
E
I
really
like
the
whole
for
document
update
like
approve
the
era
diocese
like
whole
for
document
update
and
probably
do
the
third
thing
after
at
some
point.
If
you
want
to
do
the
update,
let's
do
it
and
one
thing
since
you
talked
about
the
RFC
like
format,
changes
to
there's
also
like
a
project
on
going
to
do
inline
erotica,
so
they
are
see.
E
A
E
A
Was
a
one
problem,
I
think
with
the
three:
is
that
there's
no
direct
correlation
between
the
three
and
a
fix
I
mean
there's
there
were
more
problems
here.
You
know
found
when
when
Bob
and
I
reviewed
this,
so
you
do
you
end
up
with
three
errata
with
the
same
revocation.
You
know
new
text,
which
could
be
a
bit
strange.
E
That
one
to
the
other
ones
in
a
verification
text
or
a
subset
but
shouldn't
be
a
problem.
We
can
talk
about
the
logistics,
but
the
thing
is
like
we
say
we
know
this
is
right.
This
changes
like
you,
need
to
make
a
change
and,
if
you
say
verified
like
when
the
in
line
thing
happens,
the
other
thing
can
proceed
in
paddle.
So,
like
people
can
at
least
see
this
has
been
changed.
E
F
E
A
B
B
B
Let's
at
least
argue
about
new
things,
yeah
good,
any
other
questions,
so
I
think
the
the
next
step
is
to
send
out
to
the
list
you
know.
I
have
now,
and
nice
I'll
send
out
both
up
I'm
not
going
to
submit
this
as
drafts,
but
I'll
send
out
the
text.
You
know
the
original
text,
this
new
proposed
text
and
a
diff,
and
we
would
like
people
to
review
it
closely
and
see
see
if
it's
correct
and
we
didn't
miss
anything
yeah.
H
Okay,
raise
your
hand
if
you
have
no
idea
what
this
draft
is
about.
Oh,
oh
cool
I
need
more
slides
it.
Okay,
the
wigs,
a
long
story,
short
I,
hope
you
know
what
not
six
ways
and
dns64
is,
and
unfortunately,
currently,
if
I
deploy
not
sixteen
dns64
in
the
network.
Some
hosts
might
want
to
resynthesize
themself,
for
example,
if
they
oregano
validating
the
resolvers
on
the
host.
H
So
what
we
trying
to
do
we're
trying
to
get
an
array
option
which
will
allow
routers
to
tell
hosts
what
not
sixty-four
prefix
is
used,
because
it
doesn't
make
sense
because
the
router
knows
where
throughout
the
prefix.
So
it's
a
short
story
of
the
last
two
meetings,
so
zero,
three,
which
I
just
submitted
a
couple
of
hours
ago.
Actually
not
so
many
changes.
We
add
that
support
for
non
/,
96
prefixes
in
case
someone
I,
would
need
it.
H
So,
as
discussed
on
the
previous
meeting,
we
decided
to
have
to
option
lengths
if
a
prefixes
/
96,
then
we
have
short
option
of
length
equal
to
and
we
only
keep
first
96
bits
of
the
prefix.
But
if
we
need
longer
prefix,
you
just
add
prefix
length
at
the
very
end
and
have
some
reader
of
bits.
So
it
would
allow
us
to
save
some
bits
on
the
wire,
because
somehow
we
have
a
feeling
Z
/
96
is
the
most
common
use
case.
So
in
most
cases
you
would
not
need
the
longer
option.
H
It
was
a
current
of
the
mail
about
routers
verifying
what
other
routers
are
saying
in
Khan's
assembly
and
actually
it's
in
line
with
slack
RFC,
48
61,
which
does
recommend
routers
to
verify
option
sent
in
array.
So
we
are
the
text
which
saying
routers
should
look
at
other
arrays
received.
Look
if
it's
the
same
set
of
prefixes
prefixes
with
nonzero
lifetime
prefix
0
lifetime.
Don't
do
anything
except
maybe
log
it
if
you
want,
because
he
obviously
router
should
not
make
any
conclusions,
but
administrators
might
want
to
know.
H
So
it
will.
It
was
supposed
to
be
unresolved
issue
slide,
but
now
it's
kind
of
resolved.
If
you
slide
mark
Andrew,
suggested
that
we
might
want
to
have
exclusion
list
which
will
tell
host
a
set
of
v4
and
v6
prefixes,
for
which
synthesis
should
not
be
done
so
at
what?
Actually?
It's
not
exactly
correct,
slight
admission
last
bits
of
the
prefix
here,
but
here's
a
mock
suggested
to
have
to
use
this
resource,
beats
to
a
DNS
name
in
DNS
wire
format.
So
we've
discussed
it
a
bit.
H
So
we
believe
that
there
is
no
real
reason
to
keep
those
things
in
one
option,
because
it
makes
the
option
format
a
bit
complicated
which
might
actually
slow
down
the
implementation
and
deployment
and
also
I
personally
have
issues
with
a
curator
telling
me
that
ipv6
is
too
complex
and
difficult
to
understand.
So
I
prefer
to
keep
it
simple
and
also
exact
semantics
of
what
of
this
option,
and
what
host
is
supposed
to
do.
Visit
is
not
actually
clear
because
there
is
an
experimental
RFC
for
APL
and
so
via
some
clarification.
H
I
would
be
required
to
explicitly
specify
the
host
behavior.
Also,
actually,
this
option.
It
would
be
particularly
useful
in
ipv6
only
networks
in
ipv6
only
network.
If
host
decides
not
to
do
synthesis
for
a
some
names,
it's
not
clear
what
the
hosts
gonna
do,
but
there
is
no
before
connectivity.
End
of
story
so
also
I
did
some
math
I
might
be
wrong,
but
it
does
not
look
like
we
actually
save
in
bits
on
wire
unless
the
DNS
name
is
really
short.
H
Also,
it's
a
bit
clearer
for
me
if
it's
a
good
idea
not
to
refer
to
have
a
down
array
of
two
experimental
RFC
in
the
standard
track
and
also
is
like
side-effect.
It's
not
really
important,
but
still,
if
you
have
a
separate
option,
some
systems
might
just
prefer
to
still
do
7050
or
use
PCP
or
whatever,
but
still
use
this
APL
option
from
the
network
without
actually
supporting
prefix
one
option,
so
we
discussed
it
with
Mark
and
he
just
posted
a
draft
I,
don't
think
it.
H
The
draft
made
it
to
the
six
month
mailing
list,
but
here
is
a
reference,
so
he
proposed
the
separate
array
option
for
a
pal.
So
again,
as
I
said,
I
don't
think
he
forwarded.
The
draft
was
a
mailing
list.
So
probably
just
have
a
look
and
I
am
soliciting
feedback
on
his
behalf
because
he
could
not
be
in
this
room
right
now.
So
the
only
thing
in
this
case
we
are
not
kind
of
binding
together,
not
trying
to
get
a
brief
brief.
H
Six,
four
and
APL,
but
again
I
really
do
not
see
the
use
case
in
situation
when
we
need
to
have
separate
prefixes
more
than
one
prefix
and
separate
APL
lists.
Honestly,
like
real
operational
use
case
is
unclear.
So
any
comments
questions.
Otherwise,
maybe
we
think
it
might
be
ready
for
the
a
working
group.
Last
call.
D
I
Sis
fun
it's
three
stories:
three
Jumbo's
and
here's
the
great
the
Giant
African
elephant
jumbo,
which
is
a
big
Victorian
story
or
a
big
American
story,
I
hit
with
Barnum
circus
and
we're
going
to
talk
about
Ric
to
675
I'm
Corey.
My
co-author
is
Tom,
and
this
is
a
story
about
the
first
jumbo
jumbo
frames.
Jumbo
frames
are
lovely,
they're,
very,
very
exciting,
they're,
big
Ethernet
frames
up
to
9000
bytes
jumbo
frames
exists.
I
One
of
the
three
Jumbo's
I
assist
with
I
will
insist,
does
not
exist,
but
these
ones
do
exist
and
we
like
them
jumbo
grams.
While
jumbo
grams
are
an
ipv6
function,
where
you
can
send
a
packet
greater
than
64
kilobytes,
you
put
that
package
into
a
frame.
Are
you
sent
across
the
network
there?
We
don't
have
a
layer
2
that
takes
a
64,
kilobyte
frame
or
even
a
bigger
one.
I
So
it
is
a
little
bit
difficult
to
transport
and
at
one
time
in
the
world
of
ipv6,
there
was
some
link
layers
at
least
InfiniBand
had
a
way
of
moving
these
packets
and
I.
Don't
believe
they
now
do.
Current
status
and
to
675
is
referenced
by
17
RFC's.
There
are
three
active
internet
drafts
and
in
the
transport
area
people
keep
asking
us
about
than
what
they
should
say
about
them.
I
They
don't
want
to
maintain
this
code
and
they
have
some
interesting
comments.
So
you
can
look
on
their
list
there.
They
range
from
burning
in
fire
or
please
remove
it,
but
we
can't
remove
it
because
the
RFC
says
it
should
be
there,
but
we
can't
send
the
packet
so
questions
for
six
month.
The
story
of
the
Victorian
jumbo
is
it
got
hit
by
a
train
and
had
a
very
sad
ending.
I
K
I
was
in
charge
of
the
networks
at
CERN,
where
people
were
very
concerned
about
extremely
high
data
rates
within
the
data
center.
They
still
are
by
the
way-
and
this
seemed
like
a
wonderful
idea,
because
it
matched
very
well
what
hippy
and
abandoned,
or
one
or
two
other
technologies
whose
named
Gordon
scalable
could
here
in
him
to
connect
I,
think
I'm,
we're
capable
of
doing
the
point
is
I,
don't
buy
the
argument
that
this
is
damaging
to
BSD
or
any
other
stack
implementation,
because
this
is
an
IDF
standard
which
is
entirely
optional.
K
You
don't
have
to
support
it.
If
you
do
support
it,
you
have
to
do
what
it
says
in
the
RFC.
But
if
you
don't
support
it,
you
don't
have
to
do
anything
right,
except
you
know.
If
this
particular
format
a
packet
arrives
in
your
stack,
you
send
back
an
ICMP
message.
If
you
can
be
bothered
I
suppose
so,
I
don't
see
why
it's
damaging
to
stack
implementers
unless
they
don't
understand
the
voluntary
nature
of
all
IETF
standards.
K
B
Hi
I'm
Bob,
so
just
to
clarify
and
clean
question
based
on
what
you
said
so
regarding
say
the
FreeBSD
code.
Is
it
a
fair
assumption
that,
because
there
there
are
any
links
that
you
can
test
this
with?
If
the
chance
of
this
code
actually
working
is
sort
of
low
because
it
hasn't
been
really
exercised.
I
There
are
people
who
touch
and
chip
on
it,
so
the
code
compiles,
it
still
goes
through
the
checker,
but
it
does
require
you
to
allocate
buffers
and
other
things
in
ways
that
people
don't
really
do,
because
they
don't
really
have
any
way
of
testing.
So
when
I
wouldn't
like
to
bet
that
the
code
works-
and
it
certainly
hasn't
been
reviewed
for
about
ten
years
or
so
yeah,
so
it
is
very
old
code
that
is
never
exercised.
It's.
L
Networks,
I
would
vote
for
moving
it
to
historic
for
a
couple
of
reasons.
First,
the
initial
motivation
for
it.
You
know,
although
brian
has
a
good
point,
the
initial
motivation
has
gone
away.
Modern
line
cards
can
process
many
millions
of
packets
per
second
there's
really
no
need
to
send
a
packet
that
long
you
can
send
two
packets.
Second,
it's
a
good
thing
to
reduce
the
real
meat
to
fluff
in
the
RFC
series.
L
A
Yeah
so
I
think
I
would
more
second
Brian's
Brian's
point
when
I
implemented
v6
in
iOS
for
Cisco,
it
was
unconceivable
to
implement
this
at
all,
because
we,
a
we
didn't,
have
any
buffers
large
enough,
nor
they
we
sought
any
link
layers.
They
can
do
anything
anywhere
near
this.
Is
there
any
way
we
could
solve
this?
You
know
either
by
creating
an
applicability,
RFC
or
you
know,
make
the
message
clear
to
implementers
now
that.
A
There
are
sort
of
funky
stuff
going
on.
You
know,
take
container
networking,
for
example,
where
you
do.
You
know
plumb
things
on
the
same
host
and
you
might
you
know
we
certainly
run
that
today
with
64
km
TAS.
You
could
certainly
imagine
someone
wanting
to
do
that
with
a
you
know:
4
billion,
but
kept
you
if
they
want
to
do
so.
I
mean
I'm
a
little
uncomfortable
saying.
This
is
historic,
because
you
know
brothers
or
oh:
can
we
make
it
some
in
some
fashion
that
it
doesn't?
A
M
I
I
N
K
K
The
yumbo
payload
option
need
not
be
implemented
or
understood
by
ipv6
modes
that
do
not
support
a
touching
into
links
with
MTU
greater
than
65,000
575.
So
you
know
I,
don't
understand
why
anybody,
including
a
BSD
developer,
would
bother
to
implement
this
thing
unless
they
have
to
influence
a
driver
for
a
link
that
supports
65,000,
576
bytes.
You
know
that's
why
I
don't
understand
why
we
need
to
do
anything
except
point:
the
BSD
people
to
a
paragraph
which
says:
don't
bother
with
this.
It's
not
your
problem.
This.
O
I
Is
where
the
where
we
tested
the
code
and
found
the
horrible
problems
that
occurred
when
you
did
try
and
use
it
in
loopback
and
try
and
do
the
buffer
management
and
what
the
heck
and
all
the
other
gremlins
that
crept
in,
which
is
where
this
story
started.
It
is
indeed
testable.
Thank
you
right
and
does
it
what
yeah,
whatever
yep,
whatever
you
build
it
house,
when
you
doing
you'd,
be
well-advised,
please
please
do
that.
Yeah.
E
E
E
The
easiest
way
it's
completely
out
of
pan
so
I,
don't
need
an
ID
to
go
through
the
process
and
at
this
point,
I'd
debug.
This
I
did
this
for
IP
version,
5
and
7
and
9,
and
so
on
so
I
I
know
the
process
now
and
I'm
around
for
a
bit.
So
I'll
just
make
sure
if
this
gets
done
and
now
even
goes
to
Ayane
to
mark
it
as
historic.
So
previously
the
process
was
never
tested.
Vienna
never
marked
those
things
as
he's
starting
because
they
never
got
a
review
me.
I
And
we
need
to
decide
what
to
do
with
other
documents
as
they
appear
in
reference
this
as
well,
because
and
people
are
still
writing
transport
documents,
saying
that
you
have
to
support
this,
which
kind
of
like
and
good
weight,
which
is
super,
but
they
don't
consider
the
checksum
or
any
of
you,
the
other
implications
that
go
with
it.
So
yeah
so
think
about
that
and
I'm
I'll
take
this
output.
Wake
up
from
here.
A
R
A
C
L
Okay,
Ron
Bonica
and
I've
got
three
drafts
in
this
working
group,
one
about
a
compressed
routing
header,
one
about
a
destination
option
to
be
executed
at
the
end
of
a
segment
routing
path,
one
about
one
to
be
executed
in
the
middle
of
a
segment
at
the
end
of
a
segment
in
a
segment
routing
path,
and
this
time
around
I
wrote
an
overview
document
explaining
what
these
three
things
are
doing
and
why
they
exist.
We're
gonna
go
through
the
overview
document
for
a
little
bit,
so
we
have
these
things
called
segment
routing
paths.
L
They
provide
connectivity
from
an
ingress
to
an
egress
and
they
contain
segments.
There
are
instructions
associated
with
each
segment.
There
are
two
kinds
of
instructions:
topological
instructions
and
service
instructions.
So
let's
talk
about
topological
instructions.
Every
segment
in
an
SR
path
is
associated
with
exactly
one
topological
instruction.
It's
executed
at
the
segment
ingress
node.
It
determines
what
the
segment
egress
node
is
and
how
the
segment
ingress
routes
the
packet
to
the
segment
egress,
either
strict
or
suit
loose
source,
routing
and
some
details.
L
What
it
does
is
what
the
instruction
does
is
it
overwrites
the
destination
address
and
it
forwards
either
through
an
interface
or
through
the
least-cost
path,
and
we
encode
and
code
this
in
an
ipv6
routing
header,
you've
seen
that
presentation
before
it's
the
compressed
routing
header,
then
we
have
these
things
called
service
instructions.
They
augment
a
path,
they
don't
define
a
path
and
we
have
two
kinds
of
certain
service
instructions
per
segment
service
instructions
that
can
be
executed
at
any
segment
end
point:
they
typically
don't
influence
routing.
They
don't
influence,
whether
you
go
left
or
right.
L
L
L
Typically,
they
look
an
awful
lot
like
MPLS
service
instructions
and
l3
VPNs,
or
an
e
VPNs,
or
something
like
that,
and
we
encode
those
in
a
destination
option.
The
header
that
precedes
the
upper
layer
header.
Why
did
we
choose
to
encode
them
there,
because
the
destination
option?
Header
that
ADEs
the
upper
layer
header,
is
processed
on
exactly
the
right
node
on
the
path
egress
or
on
the
aggressive,
the
cut
glass
segment?
Now,
why
did
we
go
through
such
pains
to
decouple
service
instructions
from
topological
instructions?
L
L
One
reason
is
so
that
we
could
use
the
right
header
for
the
right
kind
of
instruction
when
we
compare
topological
instructions
with
routing
headers
they
book
they're
both
intended
to
affect
routing.
That's
why
they're
called
routing
headers
and
they're
executed
on
the
segment
ingress
node?
Why
did
we
use
the
do
h
preceding
the
routing
header
for
person
segment
instructions,
because
they're
executed
on
the
right,
node
same
same
question
for
the
destination
header
preceding
the
upper
layer,
header
for
per
path
instructions?
It's
because
they're
executed
on
the
node,
where
we
want
them
to
be
executed
in.
L
We
call
this
SR
v6
+,
but
in
this
formulation
we
have
simplified
identifier,
semantics
in
SR,
b6
and
SRV
6,
plus
we
have
this
concept
of
a
CID
I'm.
Sorry,
we
have
this
concept.
First
of
a
service
instruction
identifier,
a
service
instruction.
Identifier
identifies
a
service
instruction.
It
appears
in
the
destination
option
header
and
it's
not
polluted.
With
CID
or
ipv6
address
semantics.
We
have
a
CID
that
identifies
a
topological
instruction.
It
appears
in
the
RH
and
only
in
the
RH,
and
it's
not
polluted
with
SII
or
ipv6
semantics.
L
We
also
have
an
ipv6
address
that
appears
only
in
the
ipv6
header
and
it's
not
polluted
with
Sid
or
SII
semantics.
It
has
exactly
the
semantics
from
the
ipv6
addressing
architecture.
An
ipv6
address
identifies
an
interface
and
we're
very
careful
never
to
copy
an
identifier
of
one
type
to
a
field.
That's
meant
for
an
another
type.
For
instance,
we
have
SIDS
in
the
routing
header.
We
never
copy
a
Sid
to
a
destination
address
in
fact
they're
different
lengths.
We
couldn't
do
it
if
we
wanted
to.
Why
do
we
do
that?
L
Well,
it's
the
same
reason:
you
don't
copy
a
pointer
of
one
type
to
a
field
that
dereferences
through
another
type,
it's
kind
of
asking
for
trouble.
So
what
is
the
cost
benefit
analysis
here?
Well,
the
cost
is
because
our
SIDS
are
different
from
our
from
an
ipv6
address.
We
have
a
layer
of
another
layer
of
indirection.
A
SID
is
a
key
into
a
data
structure.
We
call
it
a
SID
fib,
the
SID
fib
Maps
acid'
to
an
ipv6
address
and
an
instruction
you
do
a
lookup
and
the
SID
and
the
S
fib.
L
You
find
the
address
and
you
copy
the
ipv6
address
field
to
the
destination
address
of
the
ipv6
header.
We
have
one
more
routing,
header
type,
the
you
know
the
CRH,
albeit
it's
it's
a
simpler
one.
It
has
fewer
fields
than
the
SRH
and
we
have
two
new
destination
options:
one
to
carry
segment
instructions,
one
to
carry
path;
instructions
benefits
ping,
okay,
half
my
time
is
up.
Okay,
we've
already
talked
about
the
rh
@
simplified,
no
tag,
no
tlvs.
The
SID
identifies
an
instruction.
L
It
does
not
contain
an
instruction,
so
it
can
be
encoded
in
relatively
few
bits
and
because
the
SID
is
short,
the
routing
header
can
be
short
even
when
it
contains
very,
very
many
segments
in
the
SID
list
and
there's
no
need
to
augment
OAM,
because
the
only
thing
that
ever
appears
in
a
destination
address
is
an
IP
address,
so
ping
and
traceroute
all
that
stuff
works.
The
other
good
thing
is,
you
can
mix
and
match.
You
can
use
the
routing
header
Terrell,
but
you
can
use
a
V
n
ni,
2d
multiplex.
L
If
you
don't
want
to
use
the
destination
option.
So
if
you're
doing
evpn,
you
could
have
an
ipv6
header,
followed
by
a
routing
header
for
traffic
engineering,
followed
by
a
VPN
and
I.
If
you
want
to
do
just
plain,
ol,
DV
or
let's
say
you
don't
want
to
use
a
VN
and
I,
but
you
want
the
path,
the
track
of
traffic
to
take
the
least-cost
path.
L
L
L
We
have
a
couple
implementations,
one
in
Linux
and
it
has
the
control
plane,
whether
dices
and
all
that
good
stuff.
We
have
a
Juno's
proof
of
concept
coming
soon
and
the
next
steps
are
to
progress.
The
drafts
I'm
not
even
going
to
ask
for
that,
because
the
first
one
has
to
go
first
through
spring
anyhow,
questions.
B
B
E
So
I'm
sitting
less
responsibility
here
so
like
this
is
what
I
said
it's
spring
right
so
like
similar
to
like
what
we
did
with
asara.
It's
like
we
didn't
like
allow
any
kind
of
follow-up
work
for
SRH
until
death
arresting
was
not
right
and
so
I
want
to
go
pretty
much
the
same
way
so,
like
you
know,
spring
tells
like
they
gonna
know.
This
thing
is
like
a
kind
of
architecture
and
they
sign
off
on
it,
and
then
we
start
doing
the
follow-up
work.
F
E
Q
Q
This
has
been
deployed.
The
draft
based
implementation
have
been
deployed
in
multiple
production
networks,
including
Softbank,
channel
telecom
and
elite.
The
details
are
available
publicly
in
the
draft
that
is
mentioned
here
for
deployment
status,
and
there
are
10
platforms
that
support
this
implementation
of
this
draft.
This
is
also
based
on
the
public
information
which
is
listed
as
a
source,
and
there
has
been
interoperability
done
on
this
draft,
and
this
was
done
publicly
in
March
2008
by
EA
and
TC.
Q
Then
they
were
showcased
at
in
April
in
MPs
were
Congress
there
are,
there
were
additional
interoperability
that
was
done
privately,
but
for
the
public.
The
information
is
available
in
the
source
draft
that
is
mentioned
here
now.
Coming
back
to
draft
summary
is
very
simple:
it
is
relying
on
existing
ICMP
mechanism.
It
does
not
define
any
new
mechanism.
Why
CMP?
When
we
have
a
service
6
deployed
there,
obviously
or
nodes
on
orders
are
visible
and
they
work
seamlessly,
then,
for
some
use
cases
define
the
use
of
the
obut.
Q
It
illustrate.
It
provides
some
illustration
on
how
we
can
use
this.
These
tools
for
doing
thing
end
to
end
segment
by
segment,
trace
route
of
behad
segment
by
segment,
and
also
how
is
our
SC
8400
3,
which
is
just
part
monitoring
is
applicable
with
that
and
multiple
production
requirement
is
interrupt
done
and
and
various
implementations
that
are
available,
and
this
work
has
been
mature,
who,
like
the
working
group
threat
of
this
today,.
Q
J
City
I
have
a
couple
comments,
so
first
I
think
it's
a
useful
document
and
it
addresses
tool
that
is
probably
the
most
used
poem
to
ever
traceroute
and
peeing.
So
definitely,
operators
who
appreciate
this
work,
though
I
want
to
point
that
there
is
some
inconsistency
how
their
draft
is
named
and
what
it
addresses.
So
it
refers
to
SR,
v6,
om,
but
I
believe
that
a
service
six
om
is
broader
and
then
just
finding
traceroute,
so
you
might
be
somewhere
along
the
way
working
on
this
draft.
J
The
name
can
be
more
targeted
towards
their
scope
of
the
document.
I
think
that,
looking
at
what
requirements
for
adoption,
that
draft
is
ready
for
adoption
call
and
then
working
group
we
can
discuss
whether
you
know
hold.
It
is
the
right
way
to
do
it
because
so
far
as
I
know,
ping
and
traceroute
in
other
networks
work
without
obit.
So
why
it's
needed!
That's
something
that
we
can
discuss
as
a.
Q
P
L
Ron
Bonica
no
particular
opinion
about
whether
it
should
progress
or
not,
but
a
question
about
a
word
you
use
in
the
draft
and
that
is
to
punt
a
packet
I'm
assuming
to
punt
the
packet
I
assume
you're,
talking
about
punting
from
the
forwarding
plane
to
the
control,
plane
and
I'm.
Assuming
you,
your
your
assumption
is
that
the
device
that's
processing
it
has
distinct
forwarding
and
control
planes,
not
all
devices
habit
of
state
forwarding
and
control
planes,
and
it's
kind
of
a
discussion
about
an
internal
behavior.
Maybe
the
OAM
should
only
talk
about
externally,
observable
behaviors.
L
Q
U
Some
additional
software
are,
they
operate
already
deployed
a
service.
If
I
really
appreciate
this
work
and
I
hope
this
throughout
moving
forward,
and
as
these
drafts
define
the
orbit
at
the
head
of
the
escalator
I
think
would
be
good
to
keep
name
away
and
all
this
other
physics
not
to
change
others.
A
Is
pretty
much
a
matter
of
how
many
spring
people
we
get
in
combination
with
six
man,
people
in
this
room,
so
before
we
do
an
adoption
hum
I
could
I
just
get
a
you
know,
set
of
hands
that
are
the
people
that
are
willing
and
interested
working
on
this
Oh,
fantastic,
good,
excellent,
so
Jory's
in
unit
8
I
call
first,
or
should
we
do
the
hub.
Q
A
B
E
A
Okay,
so
those
in
favor
or
adopting
this
document
as
a
working
group
document
in
six-man,
please
hum
now
and
those
who
oppose
adopting
this
document
in
six-man,
please
come
now,
don't
be
so
silent
people
I
mean
there
must
be
one
objector
excellent.
Then
we
will
take
the
confirm
that
on
the
on
the
list,
fantastic
thanks
a
lot
so
far.
Thank
you
and
I
think
that
was
the
working
group
documents
and
the
active
individual
drafts
sorted
out.
The
rest
of
the
time
here
will
be
spent
on
lightning
talks.
A
A
R
Okay,
since
they
say
the
Jimmy
from
Hobby
Lobby,
so
this
topic
is
the
application.
We
are
ipv6
networking,
so
we
I
P
v6
go
on
move
forward,
okay,
so
this
is
the
architecture
for
the
application.
We
are
ipv6
networking
because
we
know
now,
that's
the
our
the
transporter
no
network,
a
feast
of
the
Challenger
over
the
bottleneck,
because
we
always
the
ban
us
a
user
increase
the
budget.
You
can
notice
at
the
revenue
from
this
service
better.
So
we
think
about
this.
R
The
combine
this
is
the
application
information
with
the
transporter
network
to
provide
a
better
service,
so
there's
a
and
also
the
finer
granularity
the
service
for
the
better
s
area
compliance.
So
this
is
the
purpose,
so
we
think
the
ipv6
is
a
suitable
tool
for
the
purpose.
Because
of
here
we
consider
the
in
the
edge
node
of
the
network.
We
can
encapsulate
the
application.
We
are
information,
so
this
application-
we
are
information-
include
the
application,
ID
ID
and
the
service
parameter.
R
So
this
is
the
parameter
can
be
carried
by
the
packet
through
the
ipv6,
if
general
header
to
the
transport
and
network
edge
node.
So
the
transport
and
network
are
added
in
order.
According
to
the
application,
we
are
information
to
make
him
to
a
suitable,
the
SR
v6,
the
path
to
satisfy
the
SLA
requirement,
and
also
this
is
the
application.
Information
can
be
committed
to
the
SR
v6.
R
The
SR
is
the
extension
header,
so
there's
the
middle
tones
of
the
SR
path
and
also
to
you
would
accuse
killed
to
satisfy
the
asari
requirement
to
propose
device
the
application
information
so
as
the
US
node
of
the
transport
network.
So
that's
the
I,
sorry,
six,
the
feather
will
be
stripped
and
we
will
go
on
to
the
as
the
for
whether
the
package-
and
this
is
a
forward
pass
another
reverse
pass.
Maybe
this
is
a
packet
usually
forward
from
the
cloud
and
to
that
transfer
the
transport
network.
This
is
the
similar
the
process.
R
So
this
is
the
information
probe
host
in
the
draft.
So
the
first
we
propose
the
application
ID
a
we
are
ID
in
the
user
can
be
carried
in
the
hubba-hubba
header
or
carried
by
the
is
ID
header
or
maybe
the
destination
header
depend
on
the
different
scenario,
so
the
application
header.
We
can't
divide
it
into
the
sra
level.
That
means
that's
the
course
granulated
and
also
it
can
also
take
some
of
the
application
ID
or
the
user
ID
or
the
flow
ID.
So
that's
the
user
depend
on
this.
The
difference
is
the
ID.
R
You
had
the
finer
granularity
for
the
application
identification
so
and
also
that
we
also
carry
the
service
requirement
a
parameter.
The
parameter
can
be
the
pan,
wise,
the
delay
and
the
delay
variation
or
the
packet
loss
ratio.
The
dependence
is
a
service
requirement,
a
parameter
it
can
map
to
the
SR
v6
pass
or
for
the
queues
process.
R
Okay.
So
this
morning
we
have
this,
the
18
6a
the
meeting,
so
here
there's
a
user
thanks
to
the
attendees.
So
that's
we
have
this
the
50
plus
these
members.
So
here
we
have
this
to
the
reach
for
the
presentation,
and
that
is
caution.
So
that's
we
discussed
the
possible
application.
Information
can
read
through
by
a
salute
to
the
network
and
also
the
possible
application.
We
are
service,
including
the
detonator,
om
or
the
UNCG
OEM,
and
also
the
at
last
of
the
said
meeting.
R
We
do
the
investigation
and
the
consensus
one
minute,
you
don't
take
the
questions
before
your
time
reserve.
Okay,
okay,
so
that's
the
we
seen.
This
is
all
valuable
because
across
the
area
and
the
multiple
working
group,
so
that's
what
we
would
like
to
apply
the
meaning
easter
to
foster
the
communication.
Okay,
that's
all.
N
R
N
R
V
M
M
So
the
car
in
the
solution
for
supporting
the
IOM
is
to
place
the
IOM
data
into
the
hop
by
hop
options,
header
and
the
destination
options
header,
but
there
may
be
a
risk
if
we
do
it
in
this
way,
we
may
put
push
the
routing
header
out
of
the
parsing
window
under
under
chipset,
so
our
proposal
is
to
separate
the
instruction
part
and
the
recording
part.
We
define
the
uniform
ipv6
service
option
and
as
the
to
carry
the
instruction
part
of
the
path
services,
and
that
depends
on
the
path.
M
If
all
the
node
along
the
path
ipv6
enabled
we
could
place
the
instruction
part
of
the
part
services
in
the
harbor
hop
options,
header
and
if
some
of
the
nodes
along
the
path
I
services
enabled-
and
we
like
to
monitor
the
network
performance
of
the
I
service
expose,
we
could
also
place
them
in
the
Isar
HERV.
So
generally,
the
instruction
part
of
the
historicist
are
fixed,
so
that
could
facilitate
the
hardware
processing.
M
We
also
define
a
unifying
the
container
to
carry
the
recording
part,
and
that
is
to
record
the
service
metadata
of
the
IOM
and
also
probably
other
path
services,
so
that
would
enable
us
to
stop
recording
when
we
found
that
they
are
already
too
much
data.
So
that
could
avoid
reaching
the
hardwire
limitation.
M
And
so
we
could
find
that
there
are
more
and
more
of
our
services
that
we
require
to
process
the
information
carried
in
their
pockets
and
such
as
I
am,
and
we
would
like
to
the
operation
on
the
IOM
to
be
performing
a
hub,
a
hub
minor,
but
at
a
wire
speed
and
how
I
were
currently
probably
due
to
the
lack
of
service
requirements,
as
well
as
the
limited
hardware.
Processing
capabilities
may
be
so
the
hardware
that
the
Hopis
hub
options
are
usually
assigned
to
a
slow
pass.
M
So
that
will
reduce
the
forwarding
performance
and
also
along
the
path
if
the
devices
are
from
different
vendors
and
that
they
may
have
different
the
handlings
of
the
hop
by
hop
options
header.
So
that
will
cause
the
entry
and
service
inconsistency
and
so
the
desire,
the
precising
procedure,
is
not
there.
In
the
currently
existing
specifications,
if.
M
Sure
so
can
we
do
it?
Can
we
solve
it
by
configuration
and
there
may
be
a
few
things
so
if
way
down
that
in
devs
in
this
way,
so
one
thing
is
all
the
options
in
the
header
may
be
treated
in
the
same
way.
Another
thing
is
we:
if
we
do
some
engineering
on
each
option
tab,
we
need
to
check
against
those
options
one
by
one,
so
that
is
also
not
very
friendly.
M
So
we
propose
to
have
a
yin
house,
the
hub
I,
hop
options,
header
and
we
place
all
options
that
are
required
to
be
treated
at
wire,
speed
in
in
this
header
and
then
accordingly,
we
will
need
some
specifications
and
for
the
ipv6
metahit
metadata
header,
and
that
is
unified,
metadata
header
and
that
is
used
to
carry
the
metadata.
So
the
location,
we
recommend
to
place
it
after
the
routing
header,
but
there
are
still
two
options
for
this
two
options.
M
A
J
Greg
nurse
Det
I
share
your
concerns
and
I
will
suggest
you,
rather
than
putting
data
in
a
packet.
Look
at
the
proposal
in
IPP
and
working
group
that
called
hybrid
two-step.
It
puts
in
a
train
packet
which
shares
the
same
encapsulation
which
ensures
that
it
reverses
the
same
path
as
your
trigger
packet.
So
we
use
your
packet
to
trigger
your
measurement
and
you
put
your
measurements
in
a
follow-up
packet.
You're
not
concerned
about
size
and
you're,
not
concern
about
getting
out
of
fast
memory
and
the
procedure.
W
T
And
you
have
five
minutes
yep
lucky
day
Karuna,
ladies
and
gentlemen,
and
today
my
topic
is
past
segments.
Encapsulation
is
a
v6,
so
basically
we
have
introduced
per
segment
in
as
Paris,
because
we
do
need
a
post
segment.
You
identify
the
pause,
but
why
do
we
need
the
pass
segments
in
Si
v6?
That
is
a
question
right
because
the
seed
least
I
know.
T
Se,
as
ID
tried
to
an
identify
the
past,
it's
crazy
right,
but
so
that
is
the
reason
why
we
propose
fixed
when
the
ID,
which
code,
which
is
called
per
segment
right
in
your
pass,
and
it
would
be
insert
in
the
specific,
a
location
which
is
the
last
entry
in
the
seed
list.
So
that
is
the
main
idea.
Let's
take
a
look
up
the
format
of
document
as
I've
a
six
per
second,
basically,
we
propose
to
format
of
the
service
six
per
segment.
T
L
T
L
T
L
L
R
A
Q
Q
Q
Node
is
not
capable
of
recording
the
data
and
is
do
I
need
the
data
from
all
the
node
in
my
network
and
if
I
start
probing
in
bang
on
all
the
node
in
the
in
the
network,
would
I
cause
a
problem
for
deviating
from
the
very
set
of
data
them
trying
to
collect
so
overhead
as
I
go
and
start
collecting
this
data.
If
I'm
sitting
in
SRV
six
Network
segment
endpoint
has
a
very
reason
that
I'm
going
through
a
segment
endpoint
because
I
there
is
a
topological
reason
to
go
through
it.
Q
It's
interesting
point
and
can
I
just
collect
data
on
from
segment
endpoint
only
and
can
I
only
collect
data
from
segment,
but
data
capable
of
recording
the
data.
So
all
of
these
questions
are
answered
by
this
draft.
By
by
using
the
network
program
availability
notion
of
SRV
six,
you
can
only
collect
data
that
are
capable
a
node
which
is
not
capable
recording.
The
data
does
not
have
to
look
into
TLV.
It
will
bypass
everything.
It
doesn't
have
to
always
look
into
and
scan
so
mean
point
in
as
we
collect
I
own
em
data.
Q
We
should
make
sure
that
we
are
not
affecting
the
very
stream
that
we
are
collecting
the
data
from
and
I
believe
that
this
this
graph
is
very
useful.
It
can
collect
from
a
very
strategic
points
and
it
can
only
end
the
nodes
that
are
not
capable
of
recording
the
data
can
skip.
The
TLV
processing,
which
is
expensive
and
I
at
the
moment,
is
lightning
talk.
So
we'll
just
like
to
hear
feedback
from
the
working
group.
A
X
And
this
is
just
all
from
javi
and
I
will
give
a
very
brief
introduction
about
our
work
and
that's
not
actually
the
basic
idea
of
then
that
is
quite
simple
for
some
critical
service
or
flows.
The
current
network
is
not
good
enough.
We
want
to.
We
wanted
to
do
better,
for
example,
bundle,
latency,
extremely
low
data
loss
and
the
low
jitter,
so
we
have
to
make
the
network
do
better
with
a
lot.
A
group
of
new
technologies.
X
Why
the
network
is
not
enough,
for
example,
in
the
network
there
is
congestion
which
can
cause
the
latency
and
and
the
congestion
loss.
So
we
will
use
resource
allocation
to
the
to
along
the
paths
for
10s
service,
and
we
also
use
queueing
management
for
the
10s
service
and
also
if
there
is
other
loss
because
of
meteor
arrows
our
equipment
fili,
we
will
use
a
service
protection.
X
That
means
in
some
particular
know,
the
we
will
do
a
peculiar
replication
and
the
packet
after
replicated
will
go
along
different
paths
through
the
network
and
again
in
another
note,
the
packet
will,
the
redundant
packet
will
be
eliminated
and
the
the
left
one
will
go
through
and
also
to
make
the
10s
ERISA
table.
We
also
have
to
rely
on
the
explicit
pass,
so
this
presentation
is
about
how
to
implement
the
net
in
SR
e6
domain.
X
Here
are
some
requirement
for
the
SRS
6,
for
example,
the
first
one
we
have
to
identifying
the
SRS
6
payload
type,
and
also
we
have
to
find
a
suitable,
explicit
pass
for
the
Dynaflow.
This
is
supported
by
our
six
naturally
and
in
order
to
do
the
service
protection,
as
mentioned
in
the
previous
slide,
we
have
to
to
indicate
the
packet
to
packet,
replication,
elimination
of
the
ordering
function
to
implement
these
functions.
X
We
require
extra
information,
for
example,
the
tunnel
flow
identification
and
sequence
number,
and
also
we
have
to
use
the
as
our
age
to
carry
a
queuing
and
a
forwarding
indication
to
do
congestion
protection,
but
this
part
is
not
covered
in
our
current
version
of
the
draft.
So
what
can
we
do?
We
list
some
option
to
do
this,
especially
for
carrying
flow
identification,
a
sequence
number.
We
can
carry
it
in
as
RIT
TLV.
We
can
carried
it
in
the
same
in
the
list
inside
a
seed
to
to
define
new
functions
and
arguments.
A
You
know,
as
a
non
working
group
forming
golf
I
mean
I'm
sure
they
would,
and
probably
you
would
as
well
appreciate
it
if
you
could
have
a
look
at
their
problem
statement
and
perhaps
post
your
draft
or
subscribe
to
that
list,
because
there
looks
like
there
is
a
lot
of
overlap
it
they
in
the
problem
they're
trying
to
solve
and
also
meet
with,
or
at
least
you
know,
they're
just
in
a
problem
defining
stage,
but
they
weren't
thinking
of
solving
it.
There's
rb6,
but
it
certainly
looks
very
much
like
the
same
problem.