►
From YouTube: MPLS WG Interim Meeting, 2021-04-22
Description
MPLS WG Interim Meeting, 2021-04-22
A
B
The
agenda
today
is
that
we
will
talk
about
the
mpls
payload
and
the
metadata
and
mpls
payload
discussion
of
the
this
is
a
continuation.
From
last
time.
The
discussion
on
the
first
nibble
applicability
of
the
generic
delivery
functions
to
mpls
jeffrey
zhang
volunteered
to
talk
about
this
applicability
of
the
catalog
that
we
talked
about
last
week
for
metadata
blocks.
B
I
think
edward
suggested
that-
and
there
was
a
follow-up
email
on
this.
So
if,
if
he's
present,
we
can
talk
about
that
and
we
have
the
multi.
The
presence
of
multiple
gals
generic
associated
label
in
the
same
label
stack.
So
that's
something
that
greg
wanted
to
talk
about,
and
I'm
hoping
he's
also
present,
and
he
can
talk
about
that.
B
C
B
Yeah,
okay,
that's
yeah!
I
will
see
how
we
can
steer
through
the
agenda,
but
you're
right.
We
have
one
and
a
half
hours
this
time.
It's
not
two
hours.
I
hope
the
the
webex
got
updated
on
your
calendar.
B
Is
there
any
preference
at
least
the
word
from
your
side?
How
do
you
want
you
know?
I
I
suggested
this
order,
but
you
know
we
can.
We
can
jump
to
any
one
of
these
bullets
now.
I'm
fine.
B
Okay,
all
right,
I'm
okay
to
take
minutes,
but
if
anybody
can
help
18
minutes
as
well,
that
would
be
great
anybody
is
willing
or
has
some
free
hands
for
typing
minutes
volunteer.
B
If
you
can
do
so,
please
shoot
me
an
email
with
whatever
minutes
you
took
and
we
consolidate
and
publish
them
towards
the
end.
B
Okay,
there
was
a
thread,
an
email
thread
about
you,
know
the
what
what
mpls
payloads
exist
today
and
you
know
how
we
identify.
If
we
do,
we
need
to
identify
what
an
mpls
payload
is,
so
it
was
suggested,
that's
dominantly
ib
and
ethernet,
and
that's
probably
true,
but
we
also
have
you
know
a
oem
data
that
can
be
carried
today.
B
We
we
do
want
to
extend
this.
The
the
I
I
presume,
the
objective
is
that
we
can,
you
know,
carry
more
more
than
just
ipe
and
ethernet.
C
What
we
do
already-
and
I
think
it's
important
to
remember-
that
pseudo
wires,
for
example,
a
whole
family
of
things
in
pseudo
wires
that
get
carried
over
mpls
and
then
and
det
net
is
also
carried
over
mpls.
So
I
don't
think
it
matters
that
most
of
the
traffic
is
ip
or
ethernet.
What
matters
is
that
there
are
many
is
that
there
is
a
large
variety
of
mpls
payloads
out
there
and
we
have
to
whatever
we
do.
They
have
to
be
able
to
continue
to
operate.
B
C
B
Indeed,
yeah
yeah
definitely
yeah.
That's
what
I
meant
in
the
packet
there's
a
field
that
says
what
what
is
the
payload,
but
indeed
the
control
plane
could
have
programmed
the
the
the
label
at
the
egress
with
a
context,
but
for
a
transit
node.
It
will
remain
an
open
question
because
the
control
plane
wouldn't
have
programmed
that
label.
It's
not
the
owner.
The
transit
wouldn't
be
the
one.
C
Well,
unless
it
needed
to
be
so,
the
I
can
never
remember
greg
will
remind
me
what
it's
called
the
the
transit
time
calculator
that
knew
what
the
payload
that
kind
of
knew
that
a
control
word
was
there,
even
though
it
was
looking
at
the
top
label,
so
the
top
feck
knew
about
it.
C
So
we
can
always
tell
the
the
p
root
is
what's
going
on
if
we're
prepared
to
grant
a
new
fact.
So
this
is
all
about,
I
think,
essentially
the
sr
family
of
protocols
wanting
to
know
what
is
being
carried
without
using
the
control
plane,
which
is
how
we
have
normally
done.
It.
B
Right
yeah,
the
context
is
not
programmed
with
the
top
label
and
we
need
to
indicate
that
we're
carrying
something
in
the
payload
right.
D
C
B
You're
getting
multiple
payloads,
multiple
data,
which
is
the
second
bullet
really
I'm
jumping.
Would
you
need
a
cascade
of
what's
next,
so
you
have
a
kind
of
a
next
header,
pointer
or
next
header
type.
E
Indeed,
I
think
there
was
some
there
was
a
proposal
in
in
in
the
past
that
tried
to
provide
the
explicit
identifier,
particular
identifier
in
it,
to
mps,
but
as
we
know
that
the
current
mps
doesn't
have
such
mechanisms,
maybe
it's
better
to
have
a
you
know
explicit.
You
know
product
identifier
defined
in
mps
header
to
do
that.
F
I
I
agree
with,
I
think
it's
a
useful
feature
to
know
the
people,
what
the
exactly
payload
is
so
since
here
we
are
also
proposing
we
can,
we
will
support
more
function,
instruction
headers,
so
this
time
we
think
I
think
we
should
make
this
thing
right.
If,
whatever
we
design,
we
should
be
able
to
point
to
point
out
what's
a
particle
following
the
header
following
the
nps
label
stack
and
as
a
by-product
of
that,
we
also
know
actually
what's
in
the
payload,
I
think
that's
a
good
feature.
B
I
I
think
it's
fair
to
ask
for
a
good
feature,
but
I
I
you
know
I
I
stand
by
steve
just
so
that
we,
you
know
we
have
a
strong
reason.
F
Because,
if
you
add
anything
in
between
you
will
you
will
need
to
know
what
it
is?
So
if
you
have
this
in
place,
then
it's
just
a
you
know
for
free.
You
will
know
what's
in
the
payload,
so
I
think
that's
just
a
a
a
product
by
product
of
this
design
actually
to
solve
it.
I
think
I
think
missing.
The
indicator
of
the
payload
is
actually
a
drawback
of
the
current
mpls
specification,
so
we
can
fix
that.
B
Okay,
so
just
to
capture
the
the
thought
you're
saying
that
if
you
carry
multiple
metadata,
then
a
next
header
type
would
be
useful.
Yeah
you're
gonna
need
to
know.
A
Could
I
say
about
something
about
this
big
because
it's
the
similar
problem,
which
we
have
in
spring
in
so-called
programmability,
but
why?
All
this
programmability
from
my
point
of
view,
really
a
little
bit
makes
sense.
It
makes
sense
why
it
makes
sense,
because
if
you
have
many
flaws-
and
you
try
to
be
really
really
good
regularity,
you
would
like
to
have
separate
separate
behavior
of
one
flow
from
another
flow
and
as
a
result,
you
have
many
flows.
A
If
you
have
many
flows,
then
you
have
a
n
square
problem
and
this
ends
a
problem
is
difficult
to
solve
on
control,
plane
level,
but
it's
easy
to
solve
on
the
data
plane
level,
because
if
you
have
separate
flow
which
has
separate
the
different,
for
example,
type
of
metadata
from
different
flow
and
then
it
would
be
easier
to
look
to
this
particular
thing
without
control,
plane
strain
because
n
square
problem
for
control,
plane.
Sap,
for
example,
is
a
is
very
difficult.
For
that
reason.
It
it
has
a
little
bit
sensor.
A
H
C
G
This
is
just
for
different
flows.
What,
if
to
distinguish
between
different
flows,
is
that
what
this
proposal
is
for.
I.
B
Not
sure
about
the
different
flows,
I
I
I
don't
know
what
what
he
meant,
what
you
meant
edward
by
multiple
flows,
because.
A
Different
services,
for
example,
different
services,
one
service
needs-
needs
one
treatment,
another.
You
always
need
different
treatment,
and
if
you
have
many
such
things,
it
is
not
scalable
for
control
plane,
but
it's
still
scalable
for
the
airplane.
C
Well
in
one
good
internet
pseudo-wire,
you
could
also
be
in
the
same
pe,
be
terminating
an
atm
pseudo
wire
or
a
tdm
pseudo
wire.
C
G
C
C
Hang
on
a
second,
though
the
pseudo
I
will
deliver
an
ethernet
packet.
That's
the
end
of
its
job.
Different
pseudo
wires
are
identified
by
different
pseudo-wire
labels.
E
C
C
G
G
I
I
may
say
something:
I
think
that
the
existing
mpls
architecture
already
solves
the
problem
of
payload
type
or
metadata
identifiers
for
aggressed.
Ldrs
is
already
done.
The
only
problem.
As
I
see
it
is
if
you
need
to
understand
the
payload
type,
which
I'm
not
sure
is
really
necessarily
some
other
some
meta
data
presence
by
the
transit
telescopes,
because
they
do
not
know
anything.
I
Usually
the
accuracy
layer
usually
is
one
that
has
allocated
end
to
end
the
the
application
label,
be
it
a
vpn
label
of
pseudo-wire
label
or
who
cares
or,
and
so
it
knows
exactly
what.
What?
What?
What
is
supposed
to
follow
and
can
use
that
the
transit
telescopes-
and
that
is
exactly
the
data
by
scalability
of
mpls,
doesn't
know,
typically
doesn't
know
anything
about
these
vehicles
and
what.
I
Doing
it
differently
will
reverse
the
the
n-square
problem.
That
edward
has
has
mentioned
from
the
control
plane
the
data
plane
and
saying
that
this
problem
is
simple
to
handle
in
the
data
plane,
I
think,
is
an
exaggeration,
especially
since
we
have.
I
Well,
one
of
mpls
labels
is
all
there.
It
is
for
in
most
cases,
but
if
you
go
to
n
square,
you
will
find
the
you
will.
This
will
be
consumed
very
soon.
A
Let
me
let
me
propose
particular
example.
Imagine
the
situation
that
for
troubleshooting
purposes,
for
example,
you
would
like
to
put
time
stamp
in
some
particular
metadata
here,
the
time
time
stamp,
or
maybe
some
other
information
doesn't
matter
which
should
be
put
in
the
middle
of
the
network
in
the
transit.
A
In
this
case,
you
need
to
look
which
one
packet
has
this
particular
metadata
metadata,
which
one
packet
does
not
have
this
metadata.
Then
you
should
look
in
this
information
of.
E
A
I
You
provide
an
excellent
example.
They
have
pointed
that
this
problem
has
been
studied
and
stuart
greg.
I
Some
other
people,
including
myself,
have
already
published
an
rfc
on
there,
which
says
it's
exactly
the
rfc
that
stuart
has
a
refers
to
under
the
title
of
which
deals
with
the
president's
time,
which
is
formed.
You
can
consider
that
as
a
variation
of
data
of
timestamps
measuring.
I
Lsp
residence.
J
I
What
down?
There
was
very
simple,
you
know,
which
you
know
you're.
The
console
plan
tells
you
where
the
notes
that
can
handle
this
measure
the
the
residence
on
the
on
your
on
a
pass
allocated
and
the
detail
of
the
of
of
this
brackets
package
carrying.
It
is
adjusted
so
that
these
packets
or
these
lsrs
always
catch
your
packet,
and
you
use
the
generic
location
associated
channel
label
gal
and
an
appropriate
header
to
indicate
that
it
has
been
trapped
due
to
ttl
exploration.
I
B
D
Asked
can
I
ask
a
clarifying
question
when
we
talk
of
payload
type?
Are
we
talking
about
the
original,
the
preload
type
like
iv,
packet
or
ethernet
packs,
or
are
we
talking
about?
Well,
we
need
to
know
that
if.
C
B
Yeah
I
I
agree
that
there
is
an
indicator
that
is
needed
to
say
that
we're
carrying
metadata
whatever
then
we
agree
on
the
indicator
is,
but
once
we
know
that
metadata
is
there,
the
structure
of
the
meditator
should
be
extensible,
so
so
that
know
either
we
have
a
a
a
structure
that
is
chained
cascaded.
F
By
the
way,
I
I
think
the
term
metadata
here
is
kind
of
misleading,
because
we
are
not
only
talk
about
data
here.
Actually,
we
are
thinking
about
some
some
header
with
instructions
and
metadata.
So
I
think
it's
a
term
here
right.
C
D
Okay,
so
I
I
I
have
a
feeling:
that's
both
problem,
we're
indicating
that
the
the
what
kind
meta
data
is
following
and
if
we
need,
if
needed,
to
to
tell
what
the
original
panel
type
is
those
that
can
actually
be
be
solved
by
in
the
gdm
proposal.
Maybe
we
can
come
back
to
that
later.
I
Do
we
need
that
for
all
the
packets
or
just
for
some
specific
packets,
because
my
guess
is
that
we
need
no
do
not
need
it
for
all
the
packets,
because
mpls
is
working
quite
nicely
without
this
today?
If
we
needed
for
some
specific
packets,
then
I'd
say
that
putting
something
like
grav
at
the
top
of
the
label
stack,
which
would
indicate
that
the
generic
associated
header,
which
defines
the
the
the
type
of
data,
follows
the
label
step.
I
And
if
it's
all,
that
the
difference
with
gull
is
that
the
router
glisten
would
be
requested
to
put
it
back
on
the
packet
it
transmits
after
handling
similar
to
what
we
will
do
with
the
router
alert.
So
it
would
be
a
kind
of
combination.
I
B
Multiple
proposals,
in
fact
presented
in
ietf-110-
I
think
in
the
objective
in
the
meeting,
is
to
agree
that
we
are,
you
know
at
least
define
the
requirements
and
are
we
on
the
right
track
and
then
you
know
we
can
talk
about
solutions.
I'm
sure
there
are
multiple
that.
C
There's
there
are
certainly
multiple
indicator
methods
and
that
we
need
to
work
through,
and
there
are
multiple
structures
that
we
could
think
about
for
whatever
we're
going
to
call
this
stuck
the
stuff
after
the
stack
before
the
payload
there's
the
classic
eh
type
methods,
there's
also
a
method
that
I
submitted
over
in
rtgwg.
C
That
uses
pointed
techniques
that
I
think
is
actually
more
powerful
than
the
eh
techniques,
but
that
that's
really
in
its
infancy
at
the
moment.
So
yeah,
I
think
we're
at
the
moment
just
sort
of
in
terms
of
solutions
collecting
together
the
various
doing
two
things
we're
connecting
the
requirement
and
collecting
the
candidate
solutions.
So
we
can
map
them
to
the
requirement.
B
Yeah,
okay,
I
will
note
it
down
what
you're
proposing
alex.
A
But
just
just
one
important
point,
this
particular
technique,
or
this
particular
way
how
to
disclose
that
we
have
additional
header,
should
be
compatible
to
the
current
operation
of
current
boxes,
and
it
means
that,
of
course,
after
the
label
stack,
they
will
try
to
you
to
see.
Is
it
ip6
or
apd4
follow
and
if
they
will
see
that
it's
a
pv4
or
ipv6,
but
in
reality
it
would
be
not
ipv4
or
ipv6.
They
could
break.
C
There
is
absolutely
no
question
that,
if
what
follows
is
not
v4
or
v6,
you
have
to
you,
you
have
to
do
two
things.
You
have
to
defeat
any
attempt
to
to
do
in
packet,
inspection
on
it,
and
we
know
how
we
do
that,
and
you
have
to
indicate
what
the
heck
it
is
somehow,
rather
either
in
the
control
plane
or
in
the
data
plane
and
yeah.
You
have
to
provide
some
way
of
figuring
out
what
on
earth
you're
supposed
to
do
to
it,
and
there
are
several.
C
There
are
two
entities
that
may
need
to
know.
There's
there's
the
p
router
that
may
need
to
know
if
the
expectation
is
that
it
will
do
something
on
the
packet
on
the
fly
and
there's
also
the
the
pe
router,
which
is
clearly
going
to
have
to
dispose
of
this
lot.
A
Then
one
additional
indication
could
be
some
special
number,
three,
seven.
Whatever
from
ip
address,
I
mean
ip
particle
type
space,
because
if
we
will
take
any
permission
to
use
something
from
ip
protocol
space
like
three,
for
example,
it
would
be
enough
for
indication.
It
would
be
definitely
fine.
A
A
B
C
C
B
C
B
So
if,
if
we
have
an
indicator,
as
was
mentioned,
that
I
am
carrying
something
under
the
mpls
header
and
the
first
nibble
is
zero,
then
we
can
we
can.
We
can
extend
now
the
the
payload
and
we
can
define
a
new
tlv
if
we
need
it.
D
Right
so
I
think
we
are
getting
into
the
solutions,
so
maybe
we
we
can
talk
about.
C
D
K
C
I'll,
but
I
think
we
can
certainly
say
there
is
a
requirement
that
you
know
from
the
label
stack
that
what
follows
is
that,
if
you
want
to
indirectly
interpret
what
follows
you
have
to
have
some
indication
in
the
label
stack
whether
that's
a
thing
in
the
label?
Stack
that
tells
you
that
the
thing
after
the
label
stack
will
tell
you
what
it
is
or
whether
it's
something
in
the
label
stack
either
directly
or
through
the
control
plane.
C
That
tells
you
that
is
up
for
discussion,
but
fundamentally
the
the
label
stack
has
to
tell
you
some
way
or
other
that
what
follows
the
label
stack
is
something
you
need
to
interpret.
H
Compatibility
that
is
fair
because
the
threat
we
had
it
it
looked
very
much
like
people
wanted
to
continue
to
use
that
as
a
design
sector
for
the
future.
H
I
mean
yeah,
I
I
I
think
it
seems
that
the
that
the
main
point
is
for
backward
compatibility
reasons.
It
may
be
unwise
for
for
payloads
to
use
the
first
nibble
with
the
value
four
and
and
not
run
into
backward
compatibility
issues
or
six
six.
Yes,
so
so
only
for
the
purpose
of
backward
compatibility.
H
F
It
is
a
fair
point,
but
there
are
also
some
other
code
point
has
already
been
reserved
so
for
backward
compatibility.
Maybe
it
is
a
wise
to
just
maybe
request
another
nibble
value
to
follow
the
no.
C
C
C
Anyway,
a
p
root:
it
cannot
tell
whether
it's
got
a
a
random
ethernet
packet
carrying
out
carried
over
the
mpls
label,
stack
or
so,
or
something
special
sure,
but.
F
C
H
Let's
split
it
apart
right,
so
I
think
stewart
your
first
conclusion
for
the
future.
We,
we
must
not
rely
on
this.
I
think
that
sounds
good.
That
would
be
great
if,
if
that
can
all
be
agreed
upon
and
then
the
addendum,
in
terms
of
should
we
you
know,
do
something
additional
beyond
that
for
backward
compatibility
reasons,
it
still
seems
to
be
well.
C
I
think
we
need
to
find
a
different
solution
for
identifying
the.
B
H
I
think
that
that
I
think
that
is
clear
right,
but
just
saying
that
you
know
for
the
future,
we
will
use
control
plane
or
something
in
the
mpls
header
to
to
provide
the
identification.
H
C
It's
not
a
question
of
non-upgraded
srs.
Is
it
it's
a
question
of
lsrs
anywhere
in
the
network
that
are
sticking
packets
in
with
random
data?
After
the
stack
exactly.
I
Right,
I
may
add
it
is
not
the
matter
of
upgrade
because
with
evpn
there
are
quite
a
few,
absolutely
new
boxes,
using
some
quite
new
forwarding
hardware
that
can
not
use
the
control
world
in
the
evpn
consolation
of
the
internet
frame
they
say
sent
because
when
it
comes
to
bound
packets,
because
these
packets
are
sometimes
sometimes
require
within
ibn
an
additional
label
in
the
uk
encapsulation
the
so-called
esl
label
and
that
competes
for
hardware
resources
in
the
asex
that
does
the
encapsulation
with
the
control
work.
I
C
M
C
B
B
The
ship
has
sailed
okay,
so
your
the
point
I'm
hearing
is
that
the
problem
exists
today
and
the
result
of
the
problem
is
that
load
balancing
will
be
incorrect.
B
B
One
one
result
is
and
that
we're
living
with
this
today
right,
yes
yep,
I
I
I
think
it's
fair
to
you
know
the
ask
to
be
backward
compatible.
Is
a
fair
ask.
So,
whatever
we
come
up.
C
H
That
behavior
of
you
know
the
payload
inspection
was
from
the
point
on
that.
You
know
the
ecmp
extensions
were
done
considered,
not
to
be
ideal.
You
know,
isn't
there
over
decades
the
ability
to
really
retire
that
old
behavior
in
terms
of
not
caring,
I
mean
I
was
at.
I
was
raising
it
as
a
question
right.
I'm
saying.
E
C
No,
I
think
in
practice
it's
going
to
be
in
the
network
for
the
foreseeable
future.
I
mean
it's
a
perf,
it's
been
a
perfectly
legitimate
technique
and
I
mean
no
one's
no
one's,
even
no
one
has
ever
delegitimized
it.
So
you've
got
to
expect
it
to
be
there
for
the
whole
of
the
deployment
lifetime
of
the
current
a6
and
more.
B
I
agree,
but
but
there
is
one
thing
extra
I
think
that
tortellis
is
asking
is
if
we
define
this
special
header
that
comes
after
the
mpls
sp
mpls
label
stack.
This
special
header
should
not
start
with
a
value.
Four
and
that's
you
know.
L
B
That's
that's
a
straight
four
or
four
or
six.
Sorry.
I
mean
that
the
first
nibble
that
we
come
up
with
for
the
special
header
should
not
be
four
or
six.
L
Put
there,
but
if
we
agree
then
yeah
well,
if
we
want
to
exclude
some
numbers,
then
I
will
throw
five
number
excluded
because
it's
yeah
allocated
for
beer
over
mpos.
C
So
but
the
point
is
that
you
know
we
may
or
may
not
have
a
view
as
to
what
that
number
first
number
should
be,
but
we
can't
rely
on
it
to
know
what
is
going
on
there,
because
if
beer
was
only
relying
on
the
five,
then
it's
going
to
get
messed
up
with
or
going
to
get
confused
with
ethernet
packets.
That
start
with
five.
D
C
D
The
from
the
pseudo-wire
control
walls,
things
like
that,
I
I
forgot
the
exact
reason,
but
as
far
as
I
I
understand
it,
we
just
want
to
make
sure
that
this
beer
header
is
not
treated
as
ipv4
ipv6.
D
When
I
say
you
have
a
tunnel
a
beer
package
through
some
past,
where,
for
example,
you
do
not
support
beer
and
those
transit
routers
on
their
tunnel
may
treat
the
beer
header
as
ip
header.
C
H
Five
or
zero:
no,
no!
I
understood
that's
true,
but
I
don't
think
for
for
for
our
new
header
extension.
We
need
to
avoid
five.
D
I
I
agree:
that's
we
we
do
not
need
to
avoid
it,
but
since
the
beer
are
already
a
specified
is
going
to
use
five
all
right.
Let's
I
agree
with
with
greg
that's.
We
should
avoid
any
number
that
is
already
assigned.
B
H
C
That's
true,
so
I
think
what
this
is.
The
the
critical
thing
is
not
that,
first,
that
first
nipple
value
other
than
to
note
all
kinds
of
undesirable
things
that
can
happen.
The
critical
thing
is
to
figure
out
how
we
know
that.
What
follows
the
bottom
of
stack
is
something
special
from
the
label
stack,
because
the
the
bottom
label
basically
tells
you
how
you're
going
to
process
the
payload
and
that's
true
whether
it's
an
ip
package
or
an
or
an
or
a
pseudo
wire
packet.
C
D
Yeah,
I
think
I
agree
yeah
and
in
fact,
when
we
get
to
the
gdf
thing
you
will
well,
I
can
tell
I
can
say
that
the
the
gdfr
proposal
for
those
who
very
very
very
well
they
did
this
this
model
and
the
concept
yeah
well.
M
So
the
gdp
proposal
uses:
how
do
you
put
the
next
header
value
there,
you
put
a
special
label
or
how
is
it?
Oh,
oh!
Well,
yeah.
We.
B
Okay,
so
so
back
to
stewart's
question:
would
an
indicator
in
the
label
stack
be
useful,
like
a,
I
think,
without
defining
what
the
indicator
is.
I
think
this
is
what
I
heard
is
something
in
the
label.
Stack
indicates
or
alerts
of
the
presence
of
a
special
header.
C
After
so,
there
always
has
to
be
something
in
the
label
stack
now,
whether
it's
a
special
purpose
label
or
whether
or
whether
it's
just
done
through
the
top
of
stack
fact.
C
The
position
holds
that
the
label
stack
has
to
tell
you
that
if
you
want
to
do
anything
in
the
p
router,
the
label
stack
has
to
tell
the
p
router
that
it
is
to
do
this,
and
it
is
safe
to
do
this.
B
C
Right
but
the
the
it
is
indeed
the
case
that
that
we
need
to
consider
that
when
we
decide
how
to
do
how
to
to
do
this
indication,
but
the
fundamental
principle
is
that
the
stack
has
to
tell
us
some
way
or
other
that
a
p
router
is
to
process
something
beyond
the
end
of
stack,
and
it
has
to
also
implicitly
or
explicitly
tell
it
how
it
knows.
What
that
thing
beyond
the
end
of
stack
is
yes
I'll
capture
this.
C
Fundamental
to
the
mpls
design
that
one
of
the
labels,
before
the
top
of
stack,
has
to
be
set
up
in
such
a
way
that
it
tells
the
p
router
that
what
follows
is
something
for
it
to
process
if
it
is
required
to
process
it.
If
the
p
router
is
not
required
to
do
it,
then
the
only
requirement
is
that
either
a
label,
a
label
of
some
sort-
tells
the
pe
router
what
to
do.
C
But
it's
also
a
requirement
that
unconditionally
the
pe
router
has
to
know
what
it
is
to
do
with
the
information
beyond
the
end
of
stack,
because
it's
either
going
to
forward
it
as
an
ip
packet
or
it's
going
to
process
it
as
a
pseudo
wire
or
it's
going
to
go
and
dispose
or
process
some
metadata,
stroke,
meta
instructions
or
whatever
we
call
it.
C
D
But
if
you
have
a
special
label
as
an
indicator,
then
it
serves
both
purposes.
B
I
I
have
a
question
stewart:
if
a
packet
traverses
a
router
that
is
not
supporting
this
new
mechanism
that
we
will
come
up
with,
is
it
acceptable
that
we
forward
the
packet
as
usual
today.
C
So
that
depends
on
the
function
right.
So
if
the
function,
if
the
net,
if
the
designer
of
the
application
and
the
design
of
the
network
is
just
putting
the
stuff
in
as
advisory
and
gather
the
information
et
cetera,
where
you
can,
then
absolutely
you
want
a
legacy
router
to
just
forward
the
packet.
C
But
if
it
is
important
to
you
that
every
router
on
the
path
do
this
operation,
for
example,
because
you
were
trying
to
find
the
accumulated
dwell
time
in
the
in
the
in
the
packet
or
because
you
want
to
do
iom
for
every
hop
in
the
packet.
C
Then
it's
kind
of
not
acceptable
that
you
went
through
a
legacy.
Router
that
ignored
this
and
that's
something
we
need
to
get
our
heads
around,
because
you
could
argue
that
you
should
never
give
a
packet
to
a
router.
That
can't
do
what
you
expect
to
do
with
it.
C
It
all
depends
on
how
important
that
service
is.
You
see,
there's
two
schools
of
thought
in
fast
reroute
right,
one
of
which
is
your
job
is
to
get
the
packets
there
unconditionally.
Who
cares
when
they
get
there
as
long
as
they
get
there
and
there's
another
school
of
thought,
which
I
argue
is
equally
valid,
and
it
is
applicable
kind
of
to
this
to
the
philosophy
we're
discussing
here
that
if
I
set
up
a
policy,
then
I
expect
everyone
on
the
policy
to
to
abide
by
the
policy.
A
From
my
point
of
view,
there
is
one
principal
decision
which
should
be
made
here:
should
it
be
possible
to
look
in
extension,
headers
in
metadata,
etc?
Should
it
be
possible
on
the
p
route
or
on
transit,
or
should
it
be
only
for
pe
because
only
for
p,
it's
easy
to
add
the
additional
label
and
that's
it
and
everything
is
fine,
but
but
for
p
router
we
have
much
less
number
of
options
which
we
could
do.
Therefore,
in
principle
we
should
decide.
Should
we
give
the
capability
for
this
extension
here
to
be
checked.
C
E
C
A
It's
very
logical:
it's
very
it's
expected
answer
from
my
site.
Then
I
don't
understand
how
any
label
could
help,
because
any
label
for
p
router
will
be
not
possible
to
understand
what
it
means,
because
it
has
local
significance
for
ingress
and
egress
pe.
For
that
reason,
then
label
will
not
help
right.
Oh
hang.
C
On
a
second,
so
a
special
purpose,
ladies
and
gentlemen,
yeah
okay,
right
right,
there's
one
case
right
or
a
a
different
fec
at
the
top
of
stack,
which
is
how
we
did
it
in
8169,
would
also
do
it.
So
those
are
the
only
two
ways
you
can
check
that
a
p
router
can
tell
either
from
the
fact
or
from
a
special
purpose
label
somewhere
in
the
label.
Stack:
okay,
okay,.
A
Could
they
propose
very
small
proposition?
What
if
we
will
call
this
metadata
as
enhanced
header
to
be
very
similar
to
ipv6,
because
it's
for
the
same
purpose?
Okay,
the
structure
may
be
different
here.
Well,.
C
A
Of
course,
we
should
do
differently,
but
why
not
to
keep
the
same
name?
It
would
be
not
ipv6
enhanced
here
with
mpls
enhanced
header.
The
third,
the
first
word
in
pls
would
be
different:
mpls
header,
yeah,
they're
called
extension
headers
in
v6
by
the
way,
okay
extension
yeah,
okay,
let's
extension
here,
why
not
to
call
the
same
okay?
Of
course,
structure
would
be
different
here.
C
B
B
C
C
C
Can
help
you
right?
I
can
help
you
write
the
note
if
you
want,
but
I
do
think
it
would
be
appropriate
to
get
their
opinion,
because
I
am
worried
that
about
this
clap
potential
clash.
B
All
right,
I
took
that
action
item.
We
went
over
these
two
bullets
here.
I
think
we
can
talk
about
the
genetic
delivery
function,
jeffrey
as
yeah
as
a
that's
one
solution,
but
I
don't
want
to
you
know
hint
that
this
is,
I
mean,
let
me
put
it
out:
do
is
there
interest
in
in
going
over
the
gdf
or
general
generic
delivery
function
as
as
a
means
for
this
solving
this
problem.
C
Well,
we
should
clearly
give
jeffrey
the
chance
to
explain
to
us
all,
and
I
I
don't
know
whether
everyone
was
here
last
time
he
explained
it.
We
should
certainly
give
him
the
opportunity
to
explain
it,
but
I
do
think,
as
you
said,
we
need
to
reserve
judgment
on
whether
we
would
select
this
solution
and
we
should
be
encouraging
others
to
put
forward
alternatives
because
we'll
live.
B
B
Yeah
agreed
yeah
I'll
note
this
down
and
I'll
I'll
pass
the
ball
back
to
you.
Jeffrey
go
ahead
with
the
slides
that
you
prepared.
If
you
have.
D
D
D
D
So
what
if
we
extract
those
functions
out
and
apply
them
to
any
layer,
whether
it's
ip
layer,
mpos
layer,
beer
or
even
ethernet?
So
that's
the
thought
and
what
we
call
this.
A
generic
generic
delivery
functions
basic
between
any
two
points
at
layer,
two
layers,
three
near
two
point:
five:
whatever
layer
initially
is.
We
were
thinking
about
the
two
points:
for
example
the
lsp
ingress,
egress
beer,
ingress,
egress,
ip
source
destination,
nodes
things
like
that,
that's
so
in
the
iom
terms,
that's
like
the
edge-to-edge
functions.
D
Pop-Up
things
will
have
not
really
thought
about
it
yet,
but
maybe
we'll
think
about
it
and
see
if
they
can
apply.
But
at
this
moment
it's
mini
edge
to.
D
Edge
okay,
so
how
is
it
related
to
to
the
topic
for
today?
Obviously,
we
want
this
gdf
to
be
applicable
to
to
be
used
with
mpos
data
plan,
and
we
also
like
to
see
that
some
proposed
npos
extensions
to
use
gdf
when
they
are
generic
and
not
really
mpos
specific.
D
So
that's
why
we
want
to
bring
people's
attention
to
this.
There
are
some
implications
that
we
already
talked
about
today,
for
example,
we
need
a
label
to
indicate
that
a
gdf
or
header
car
follows,
and
in
that
header
we
want
to
set
that
first
label
to
be
0,
0,
0
0,
and
then
there
is
a
relationship
with
gach.
D
Okay:
okay,
it's
a
little
bit
of
history,
so
it
was
originally
targeted
at
the
transport
area
and
it
was
presented
in
109
and
then
morphed
into
the
intel
area.
D
The
drafts
that,
in
that
version
we
addressed
issues
that
stuart
pointed
out.
D
And
we
presented
it
in
the
110
by
the
way
my
steward's
primer
drafts
was
referring
to
the
older
version
that
that
did
not
have
those
problems
addressed,
but
by
in
the
current
version.
Those
problems
have
been
addressed
so
now.
In
this
yesterday,
I
posted
a
zero
one
version.
We
have
greg
mursky
joined
as
a
co-author
with
editorial
changes.
D
We
removed
the
the
label
signaling,
because
in
the
previous
version
we
didn't
use
a
special
label
and
we
so
we
we
signal
regular
labels
to
indicate
the
gdf
or
edge
that
follows,
but
now
we
think
that
the
working
group,
if
this
is
adopted,
I
mean
this
solution
is
adopted.
Then
then
that
I
think
that
will
be
a
open
to
use
a
special
label.
So
for
now
we
just
got
rid
of
the
label
sigma
text.
D
In
fact,
some,
if
needed,
we
could
treat
this
generic
delivery
function.
Header
as
a
gsh
header
in
particular.
Currently,
the
channel
type
is
two
octave
long
and
that
can
be
viewed
as
a
tuple
with
the
next
header
followed
by
this
header.
So
it
will
become
clear
in
the
next
slide.
D
So
this
is
the
the
header
format
started
with
zero:
zero,
zero
nibble
with
reserved
four
bits
there
and
then
header
lens.
Then
it
has
a
next
header
and
this
header,
this
header
basically
tells
that
what
this
particular
header
is
about
is
it's
for
a
generic
fragmentation.
D
Is
it
for
iom
or
whatever,
and
the
next
header
will
tell
tell
us
what
comes
after
this,
this
header-
it
could
be
another
gtf
page
or
could
it
could
be
a
the
real
payload,
for
example,
ip
or
ethernet
or
whatever?
That's
why
I
say
that
this
is
actually
is
as
a
byproduct
will
allow
us
to
tell
what's
the
the
pay
notes
comes
after
mpos
label
stack,
whether
it's
a
some
metadata
if
they
are
put
into
this
gta
page
or
if
it's
some
other
ipo,
isn't
it
real
pedals?
D
So
this
is
the
idea.
D
So
now
about
first
level
in
the
in
this
proposal,
the
only
purpose
is
to
prevent
a
transit
node
from
mistaking
this
as
an
ib
header.
D
So
as
long
as
it's
not
zero
or
four
or
no,
no,
it's
not
a
four
or
six,
it's
fine
from
from
gdfh's
point
of
view,
but
I
think
we
we
in
in
earlier
discussion.
I
think
we
are
leading
towards
zero,
zero,
zero,
zero
right.
So
basically,
whatever
the
working
group
deems
appropriate,
it's
fine
with
us.
D
So
at
the
third
bullet
here
we
already
talked
about
it.
So
by
using
this
gta
bridge,
we
can
tell
what
comes
after
the
the
bos
label,
whether
it's
some
g
other
gdf
or
one
by
one
chained
together
or
the
the
real
ip
or
nprs
or
whatever.
That
can
be
easily
done.
D
This
is
a
another
example,
the
generic
fragmentation,
so
we
have
the
next
header
oops
that
tells
that
if
another
hdfs
header
follows
or
if
it's
itunes
loads-
and
this
header
says
there
is
a
fragmentation
and
there
are
fields
there
for
fragmentation
purposes
and
now,
if
you,
if
you
want
to
indicate
the
real
payloads
after
this
one,
you
can
use
the
next
header
and
even
if,
when
you
do
not,
even
if
you
don't
use
the
fragmentation,
you
can
still
use
the
fragmentation
header
to
indicate
a
pedal
type.
D
That
comes
after
that.
So
in
that
case,
then
identification
or
offset
all
those
fields
are
just
zero.
But
of
course,
if
we
deem
that
this
is
a
a
good
feature
to
have
to
indicate
what
the
real
payload
is
after
the
npr's
label
step,
then
we
can
define
a
real
a
code
point
to
just
for
that
purpose.
Instead
of
relying
on
this
fragmentation
pattern.
D
So
anyway,
this
is
just
a
by-product,
so
this
is
basically
the
the
the
high
level
overview.
I
have
quite
some
backup
slides.
I
don't
have
to
go
through,
but
this
just
explains
how
we
view
that
we
can
use
these
two
to
to
support
ion,
at
least
for
the
edge-to-edge
scenario,
the
harbor
hub.
We
need
to
think
about
it
further.
D
This
is
the
example
where
we
can
have
many
things:
lung.
Together
we
can
have
iom,
we
can
have
a
fragmentation
gdf
or
any
gdf
or
with
and
then
followed
by
a
pseudo
wire
or
plus
gach.
All
those
things.
D
And
then
we
talk
about
how
we
can
use
gsh
to
to
do
gdf
if
we
extend
the
gash
to
to
data
traffic
as
well
currently.
B
I'm
not
sure
it
still
holds
in
correct.
I
don't
guess,
is
that
true,
the
the
did,
the
the
the
gash
used
for
oem
only.
L
Well,
what
we
carry
we
carry
only
well,
it's
in
81
69.
It
carries
ptp
control
messages
so
in
in
fact
it
might
be
viewed
as
carrying
control
information.
So
I
I
looked
at
55
89
worrying
that
should
not
carry
anything
but
control
management
or
em
messages
and
ptp
is
control.
Protocol.
D
Right
so
I
think
in
the
email
email
discussion,
my
impression
was
that
some
people
were
open
to
extended
data
use
of
data
traffic
as
well.
So
this
is
just
to
say
that
if
that
is
the
case,
if
that
is
opened
to
your
earth
for
use
by
data
traffic,
then
the
gdp
can
use
the
gsh
mechanism.
A
N
A
Have
a
question
about
this
particular
draft?
What
would
be
in
the
last
one
next
here
there?
Probably
it
would
be
ipv6
before
indication,
something
like
this
right.
D
Right
so
the
first
one,
the
the
first
stack
says
that
this
is
for
iom
and
that's
followed
by
followed
by.
E
D
A
Because
there
are
some
duplicity
here
I
mean
next
year
this
here
there
it's
it's,
it's
some
duplicity!
You
don't
need
double
this
information.
Maybe
it's
possible
to
use
just
this
here
there
and
it
would
be
enough.
D
Well,
actually,
this
I
think
it's
important
to
be
to
have
this
next
header
to
to
point
out
what
comes
after
this,
for
example,
when
you
have
multiple
headers,
whether
it's
gdf
or
some
other
things.
I
think
it's
it's
it's
important
to
have
that.
D
I
think
last
time
when
we
talked
about
the
gsh,
if
we
want
to
have
multiple
gsh
header,
for
whatever
reason
then
and
and
assigning
the
channel
type
will
become
become
a
messy
if
you,
if
we
just
use
a
current
one
fields,
proactive
field,
but
you
can.
M
The
next
header
is
obviously
the
protocol
space
right,
iona
protocol
space,
the
one
byte,
but
the
gdf
type
here
is
it.
Is
it
also
you're
seeking
from
the
protocol
space
the
ip
protocol
space
the
regular
protocol
space
now.
M
Local
right,
local-
that
is
g.
I
think
instead
of
this
setter,
maybe
it's
a
gdf
type.
You
are
saying
basically,
yes,
yes,
yeah.
I
think
that
will
be
easy
to
understand.
Okay,
I'll
change
that
and
and
as
earlier
stuart
mentioned,
the
label
stack
both
pe
routers
and
p.
Routers
should
be
able
to
identify
that
gdf
is
being
followed
here.
So
you
need
to
have
a
special
label
or
effect
need
to
be
there
that
that
is
common
for
this
proposal.
Is
it
that
documented
or
no.
D
So
the
the
initial
version
has
a
a
signaling
to
to
use
a
regular
label
for
the
for
the
egress
node.
To
know
that
if
this
tdf
follows,
if
we
want
to
to
extend
this
to
far
by
heart,
behavior,
which
in
the
which
we
need
more
thinking
and
a
special
variable,
will
be.
B
Jeffrey,
if
an
idea
or
a
thought,
can
you
carry
a
gash
gash
header
in
inside
the
gdf
header
yeah?
C
C
Follows
he's
shown
it
as
carrying
a
zero
zero
one
and
an
ach,
but
presumably
it
could
have
been
four
zeros
and
then
a
pseudo-wire
payload.
D
B
Here
I
I
see
that
he
encapsulated
another
mpls
header,
a
complete
mpl,
so
this
is
the
first
mpls
header,
another
mp,
but
what
I
was,
what
I
meant
is
you
have
a
gdf
header,
and
you
know
inside
of
it
this
possibly
the
first
or
the
second
sub
header
is
the
gash.
D
Yes,
right
now,
this
slide
is
like
that,
but
I
think
so
the
the
gdf
actually
can
and
gsh
can
actually
very
much
emerge
or
integrate
it.
I'm
actually
open
to
using
the
existing
gsh
format
to
to
to
do
this,
but
as
long
as
we,
we
actually
make
this
2d
jerk
so
that
the
same
thing
can
be
used
for
non-mpls
as
well.
I
think
we
can,
that
can
be.
That
can
be
done.
N
My
question
would
be
about
the
impact
on
the
existing
implementation,
so
with
that
you
practically
hide
the
cellular
label.
So
that
means
all
the
correct
ecmp
implementation,
which
considered
only
the
certifier
label
and
does
not
look
inside
the
packet,
but
inside
that
they
will
not
be
able
to
do
ecmp,
because
your
gdfh
indicator
label
will
be
the
same
and
would
be
assumed
as
a
service
label
right.
So
the.
C
So
the
fat
pseudo
wire
doesn't
work
anymore,
but
I
was
going
to
actually
generalize
this
because
I
had
a
very
similar
sort
of
observation,
which
is
that
you
can
really
the
the
p
routers
cannot
see
any
of
that
second
label
stack
and
so
you'd
better
make
sure,
there's
nothing
that
they
need
to
know
that
you've
hidden
from
them
and
if
they're,
if
it
is,
you
have
to
reproduce
it
in
some
other
way
earlier
in
the
label.
Stack
so
ecmp
is
is,
is
is
certainly
one
of
those.
C
Certainly
it
would
also
apply
if
I
suppose,
if
there
was
a
an
entropy
label
down
there,
you
wouldn't
see
it.
D
Yeah,
this
actually
goes
back
to
tortoise
comments
going
forward
in
a
modern
network,
it's
better
for
the
for
the
for
the
ecmp
to
total,
based
on
news
and
new
solutions,
but
as
long
as
we
make
sure
that
the
legacy
boxes
do
not
mistakenly
create
a
non-ipv
packet
as
ip
packet.
C
Well,
we've
got
the
entropy
labeled
is
the
diff.
Is
the
method
of
choice
for
ecmp
in
in
pure
mpls
right.
H
C
H
Level
comment
on
on
on
on
the
gdfh,
so
first
of
all,
I
think
the
ambition
is
is
is
great.
I
think
that
generic
would
to
me
only
be
you
know,
a
good
label
if,
if
this
was
really
proposed
and
accepted
not
only
to
be
used
for
mpls,
but
also
for
ipv4
and
ipv6,
and
we
know
how
difficult
it
is
to
get
something
new
in
there,
especially
for
ipv4.
H
If,
if,
if
we
don't
have
that
ambition,
then
I
think
we
should
stick
to
to
saying
something
like
label
stack,
independent
extension,
header
or
so
with
you
know
the
ability
to
be
used
with
other
protocols,
but
not
with
our
intent
to
go
there
at
this
point
in
time,
which
I
think
is
still
a
very
useful
thing
to
do,
which
is
basically
saying.
Okay,
let's
make
sure
that
we
don't
put
anything
into
this
type
of
extension
header
that
would
tie
it
to
mpls.
H
So
at
that
point
in
time
then
comes.
I
think
really
that
question,
which
I
think
jeff
was
also
alluding
in
a
side
sentence
to
which
is
how
what's
what's
the
mechanism
by
which
we
determine
who
has
to
look
into
it
and
if
we
have
multiple
of
those
in
which
order,
because
the
the
way,
for
example,
and
how
this
was
done
in
ipv6
with
oh,
this
particular
copy
hop
header
goes.
First
then
comes
this
other
header,
and
so
that
is
very
convoluted
and
bad,
and
I
don't
think
that
the
current
proposal
here
has
any
better.
H
You
know
solution
to
that
problem
of
specifying
the
you
know.
Semantic
relationship
between
multiple
headers
in
some
offline
rfc
that
you
know
is,
is
really
hard
to
ensure
being
implemented
consistently
across
the
the
different
platforms.
H
So
that's,
I
think
something
we
can
certainly
learn
from
ipv6
on
how
not
to
do
it
when
we
want
to
do
this,
so
I
think
that's
that's
the
first
thing
and
then
I
think
the
the
the
biggest
thing
of
my
worries
is
that
this
draft
currently
doesn't
attempt
to
define
a
must,
be
supported,
encoding
structure
for
the
data
inside
the
header,
and
I
think
that
is
really
crucial
and
important,
because
I
really
want
to
stop
us
having
to
go
through
the
trouble
of
every
time
we
do
another.
H
You
know
extension
header
or
even
a
new
tlv
in
an
extension
header
to
argue
whether
or
not
that
can
be
supported
by
existing
hardware
parsers
right.
So
I'd
really
love
to
have
a
you
know:
standardized
parsing
requirements
that
you
know
in
terms
of
oh.
This
must
be
able
to
support
8,
16,
32-bit
values,
and
maybe
even
you
know,
we
need
to
be
able
to
support
plvs,
lvs
or
just
values.
Right,
so
I
mean
values
being
the
classical
thing
that
ipv6
was
doing,
but
I
think
tlv's
being
the
most
flexible
one.
D
Boost
can
definitely
be
added
those
details
and
now
it's
at
it,
it's
infant
stage.
Basically
this
idea
this
concept.
If
it's
get
accepted
by
most
people
here,
then
we
can
work
on
it
together
in
more
details
and
about
the
the
term
generic.
I
don't
know
how
we
can
re
much.
We
can
really
do
for
ipv4
or
ipv6,
but
at
least
I
can
see
that
this
is
very
good
thing
to
have
for
for
beer,
and
I
do
not
know
how
people
are
view.
D
H
So
right,
so,
I
think,
even
just
for
the
purpose
of
understanding
that
the
flexibility
is
sufficient,
it
would
be
good
to
understand
how
would
one
do
with
this?
You
know
type
of
extension,
headers
the
functions
that
we
already
have
in
extensions
headers
in
v4
and
v6,
not
saying
that
that
need
to
be
standardized
or
be
put
somewhere
high
in
the
priority
list,
but
just
as
a
validation
point
of
the
flexibility
right
and
I,
with
respect
to
you,
know
the
encoding
and
all
these
other
things,
maybe
maybe
it's
better.
H
Instead
of
trying
to
have
a
you
know
single
document
for
all
these
aspects,
to
to
consider
that
you
know
we,
we
have
multiple
different
building
blocks
right.
So
one
of
the
building
blocks
is
you
know
how
do
we
what's?
What's
the
semantic
interlinking,
multiple
extension
headers,
the
other
one
is
what
is
the
encoding
of
you
know
the
data
within
an
extension
header
and
the
third
one.
I
think,
then,
is
well
what
a
specific
semantic
extension
header
that
that
that
we
want
to
prioritize
working
on.
E
J
Be
used
so
the
best
we
we
can
do
is
just
to
to
indicate
the
type
of
header,
but
we
can
not
do
further
things
such
as
to
defining
the
inner
structure
of
each
header.
H
We
have
been,
we
have
been
doing
standardized
parsing
and
you
know
modeling
of
of
that,
both
on
the
management
plane
with
yang.
We
have
done
it
with
the
seabor
ctdl
in
the
control
plane.
None
of
these
imply
a
specific
semantic
of
what
what
you
define
right.
That's
that
part
to
the
use
case
and
individual
specs
and
defining
the
permissible
structure,
data
types,
16-bit,
8-bit
and
so
on.
H
I
think
that
is
core
and
important,
because
if
you
look
at,
for
example,
standardized,
you
know
models
for
forwarding
hardware
that
say
what
can
you
do
with
p4?
Then
you
immediately
stumble
into
the
point
that,
because
all
the
past
forwarding
playing
protocols
were
just
list
of
fixed
length
values
the
the
language
to
program.
E
J
Kind
of
header
defined
also
for
each
many
of
these.
They
are
already
very
flexible.
For
example,
they
can
support
optional,
always
wow,
so
you
know
I,
I
think
it's
kind
of
beyond
the
scope
for
mpos
to
define.
What's
the
service,
we
can
also.
H
I
I
completely
disagree.
Mpls
was
the
first
one
that
defined
by
itself
through
the
label,
stack
architecture
very
flexible
and
must
be
able
to
implement
a
dynamic
structure
of
a
header
right
and,
if
we're
simply
thinking
that
continuing
to
go
on
with
extension,
headers
in
the
way
that
ipv6
has
done
it
will
simply,
you
know,
fall
into
exactly
the
same
track
that
ipv6
ran
into,
which
is
very
inconsistent,
very
incomplete
support
of
extension,
headers.
C
I
think
we
can
do
better
than
tlv's.
I've
got
a
proposal
to
make
at
a
future
meeting
the
the,
but
I
can
tell
you
for
sure
that
tlvs
have
been
taken
out
of
active
specifications
in
or
certainly
in
tmpls,
I'm
sorry
mpstp
rather
than
pstp,
because
of
the
difficulty
of
implementing
them.
No
one
wanted
to
use
them.
H
That's
basically
what
we've
done
all
in
the
past
and
that's
what
made
ipv6
extension
headers
so
unsuccessful
right
because
you
didn't
take
the
this
is
permissible.
This
is
agreed
upon
syntactic
and
coding.
You
know
you
didn't
take
that
out
of
the
picture
and
and
agreed
on
that
up
front.
H
C
H
I
I
think
it
is
a
good
question
of
saying
well,
is:
is
there
something
where
functions
like
or
similar
to
a
firewall
is
something
we
want
to
be
able
to
support
better
and
if
so,
how
right
and
something
like
self-descriptive
is
always
the
way
on
how
firewalls
like
these
things
right.
So
firewalls,
you
know,
have
been
parsing.
You
know
a
lot
of
protocol
stacks
and
always
have
done
better
when
it's
self-descriptive
in
the
packets.
H
So
I
mean
that
in
favor
of
tlv
right.
I
completely
agree
that,
for
the
high
speed
forwarding
hardware,
especially
of
the
past,
povs
were
more
difficult,
but
I
think
that
is.
That
is
also
just
a
myth
for
for
current
hardware
or
next
generation
hardware
right,
I
think
we're
proliferating
historical
data
by
not
taking
the
step
of
of
of
adding
more
flexibility.
B
I
think
this
is
a
discussion
that
we're
having
towards
the
end
of
our
meeting
today.
We
we,
I
don't
think
we
concluded
on.
Is
it
this
strict
encoding
or
is
it
should
we
leave
the
encoding
of
the
headers
lenient
or
flexible?
B
So
I
some
action
items
for
the
next
meeting
is:
maybe
we
come
back
to
this
and
their
advantages
and
disadvantages
could.
A
They
make
a
comment
to
finish
this
particular
slide.
Could
you
make
a
comment
about
this
particular
slide?
I
see
here
elite.
Oh
folks,
light
has
disappeared,
but
I
see
here
on
this
particular
last
slide
a
little
bit
improvement,
because
what
you
see
here
is
lttv
type.
Two
type
is
two
times
and
I'm
still
not
happy
about
redundancy,
but
what
I
have
additionally
understood
that
if
you
will
put
just
after
zero
byte,
okay
in
the
beginning,
you
have
to
have
zero
byte
to
have
compatibility
with
old
platforms
and
just
after
zero
byte.
A
You
will
put
next
header
the
first
next
here
there,
which
is
really
about
next
here,
they're
not
related
to
anything,
not
just
next
theater
and
then
next
structure.
Next
structure
would
be
only
one
next
here,
which
is
really
next.
Here
I
mean
in
this
case
you
could.
You
could
cancel
this
redundancy
and
I
don't
understand
why,
in
this
particular
picture
for
second
stuff,
which
is
ggf
xyz
stuff
for
second
stuff,
you
have
zero
byte
again
why
you
need
here:
zero
byte
again,
the
first
time
you
need
zero
byte.
A
I
don't
understand
why
not
to
break.
I.
A
Yeah,
but
you
could
treat
zero
bite
as
something
special
which
is
not
participate
in
your
metadata.
You
could
treat
it
as
something
special.
C
You're
right,
you
could
have
another
value
in
this
as
it
is
shown,
but
if
what
you
wanted
to
do-
and
I
don't
know
whether
it's
a
valid
case
or
not-
is
to
push
these
things
at
different
stages
in
the
passage
of
the
packet
through
the
network,
then
having
the
s,
the
identical
subheader,
whatever
it's
called
is
of
some
value.
C
A
C
A
When
you
push
the
header
again
on
the
transit
node,
for
example,
you
push
the
header
with
some
offset,
you
calculate
offsetting
hardware
and
push
header
and
to
calculation
offset.
You
could
calculate
offset
as
a
previous
header,
plus
one
byte,
which
is
which
is
redundant,
which
is
zero
byte,
which
we
should
keep
and
then
it's
the
same
easy.
I
don't
understand
the
challenge
you
just.
A
But
the
previous
one
bite
we
treat
as
not
the
one
which
belongs
to
this
particular
structure.
The
zero
byte
is
just
something
not
related
to
to
us
and
we
everything
else
will
treat
the
same.
Well,
wait.
Wait.
C
C
A
Okay,
but
if
you
will
push
second
one,
because
you
just
open
the
metadata-
you
just
open
new
here-
that
probably
you
need
to
id
some
indicator
that
you
have
this
here,
the
right
and
when
you
will
edit
this
indicator,
you
will
redeem
this
zero
byte,
which
you
should
you
write.
C
A
A
E
C
Yeah
yeah,
but
it
also
maintains-
and
I
don't
know
whether
we
should
do
this
it
also-
I
can
see
reasons
we're
not
doing
it
right.
It
also
maintains
32-bit
alignment,
which
may
or
may
not
be
important.
A
Okay,
there,
okay
for
alignment.
Yes,
I
don't
understand
you,
but
for
alignment,
it's
still
a
good
question:
do
you?
Is
it
possible
to
keep
alignment
because,
yes,
your
mpls
labels
label
stack
is
probably
aligned
to
four
bytes.
Okay,
it's
fine,
but
before
these
four
bytes,
it's
questionable
what
what
what
you
haven't,
how
long
it
would
be
before
this.
C
C
B
We
have,
we
have
already
exceeded
yeah
the
time
that
we
all
allotted
it's
it's
a
very
good
discussion.
I
did
note
down
your
point.
Edward
about
you
know,
redundant
first
nibble
in
second.
C
A
And
additionally,
if
you
will
follow
my
logic
and
entity
after
first
redundant
byte,
which
is
needed
of
course,
after
this
you
will
do
the
next
year,
which
would
be
additional
next
year.
The
just
next
year,
therefore
start
all
this
story.
Then
then,
even
next,
even
tt
I
mean
it's
ltt
value
tt
will
be
reduced
to
ltd.
You
don't
need
to
two
time
to
time
type,
so
maybe
I
will
put
it
in
the
alias.
So
what
I
mean
here,
but
okay.
B
A
In
first
one
it
would
be
related
not
just
to
the
first
iom
stuff,
it
would
be
related
to
zero
stuff.
So
we
will
let
it
e.
In
the
beginning
of
three
bytes.
C
A
C
Agree
on
the
ltv
and
if
you
go
and
look
at
the
tcr
draft
that
we
put
over
in
rtgwg,
that
gives
you
some
really
good
reasons
why
ltv
is
a
is
actually
a
better
structure.