►
From YouTube: MPLS WG Interim Meeting, 2021-05-27
Description
MPLS WG Interim Meeting, 2021-05-27
A
B
B
So
I
mean
network
programmability
may
be
a
use
case
of
its
own,
or
it
may
be
a
way
to
achieve
some
of
the
use
cases,
but
I
think
use
cases,
at
least
for
me
use
case
is
pretty
clear
and
by
having
network
programmability
be
a
separate
item,
no,
no
less
or
no
more.
A
C
I
I
agree,
we
should
keep
it
yeah,
maybe
separate
or
but
it
has
to
be
covered
in
our
discussion.
So
the
question
was
from
lowell.
Is
the
item
number
three
from
the
last
agenda
was
not
discussed
and
we
won't
either
carry
forward.
D
Today,
in
my
presentation,
the
work
certainly
are
motivated
by
several
use
cases.
I
actually
list
them
all
and
but
I
didn't
give
an
in-depth
discussion,
how
each
of
them
work,
but
definitely
we
can
get
an
idea
or
what
applications
it
can
be
used.
C
Is
it
speaking?
Yes?
Yes,
it's
me,
okay,
okay,
yeah,
I
mean.
Definitely
if
you
want
to
help
also
on
the
use
case,
you
know
describing
the
use
cases
that
that
need
to
be
covered
and
yeah.
B
E
B
Also
say
that
in
my
discussion,
talking
about
the
the
changes
possible
in
the
label
stack,
there
were
several
use
cases
the
idea
of
having
a
single
spl.
That
does
multiple
things.
So
I
can
I
I
mean
I
have
talked
a
little
bit
about
it,
but
I
can
definitely
come
back
to
this.
F
But
clearly,
both
in
your
case
and
in
our
use
case,
the
use
case
is
well.
Our
all
of
our
use.
Cases
are
more
than
what
you
are
covering
in
in
your
proposals,
and
your
proposals
are
also
covering
more
than
the
use
cases
does
so
it's
kind
of
an
orthogonal
thing
between
the
use
case
and
and
the
proposals,
and
we
need
to
sort
that
out.
B
D
A
Right,
I
I
definitely
agree
that
they
they
would
help,
because
the
use
cases
would
transcend
all
of
the
pieces
of
work
and
help
us
decide
which
one
or
ones
we
would
take
forward.
So
I
do
think
it's
important
that
they're
not
buried
in
particular
target
solutions
because
they
have
much
wider
scope
than
that.
B
F
F
C
Okay,
I
I
can
add
her
name,
but
I
don't
want
to
be
intrusive.
C
B
B
A
C
So
we
have,
we
have
one
item
which
we
want
to
talk
about
today
and
we
wanted
to
visit
any
previous
action
items
from
last
time.
I
I
think
we
we
did
cover
you
know.
Last
time
we
said
we
need
to
define
what
what
needs
to
be
carried
in
the
label
stack
what
needs
to
be
carried
after
the
bottom
stack
and
what
things
are
applicable
to
what
segments
of
an
mpls
path.
C
So
if
we
divide
the
path
into
segments,
then
we
might
be
invoking
actions
at
certain
segments.
So
this
was
an
action
item
to
the
team
and
I
think
it
will
go
into
the
use
case.
The
discussion,
I'm
guessing
it
will
go
there
unless
you're
thinking.
Anyone
is
thinking
of
documenting
this
in
another
place,.
B
So
one
of
the
action
items
that
I
had
was
to
create
a
wiki
and
now
I'm
hearing
about
github,
but
I'm
okay
to
do
it
either
place.
I
just
started
the
wiki
for
what
goes
in
the
label
stack,
and
so
it's
not
just
what
the
data
is.
But
you
know
the
issues
around
putting
putting
things
in
the
label
stack
and
potential
changes.
We
can
make,
for
example,
not
using
the
tc
or
repurposing
the
tc
bits
and
the
ctl
bits
so,
like
I
said
I
just
started
doing
it.
B
If
the
preference
is
to
do
this
via
github
just
find
me
at
where
the
github
page
is-
and
I
can
do
it
there.
G
C
Yeah
wiki
would
be
great,
but
then
pointers
from
the
key
to
a
github
would
be
yeah.
Maybe
pointers
from
the
wiki
to
the
github
is,
if
needed,
for
documents
repository
bi-directional
yeah
yeah,
so.
B
C
The
wiki
that
you
have
kiriti
I
mean,
if
you
send
us
a
pointer
to
it
or
even
if
you
create
it
directly
on
on
mpls
page,
would
be
great.
I
don't
know
where
okay.
B
B
D
B
F
B
B
Okay,
so
I
don't
know
if
you
can
see
products,
but
there
is
the
two
subsections
after
agendas
and
meeting
nodes.
Sorry
there's
one
subsection
called
ongoing
design.
Wikis
and
one
is
label
stack
and
that's
you
know
the
starting
point
for
what
I'm
doing
and
to
lowest
point.
We
could
have
a
second
one
that
says
beyond
label
stack
or
whatever,
and
that
could
be
the
one
that
describes
the
design
team's
efforts
on
what
comes
after.
C
Okay,
yeah,
we
did
you're
right,
we
did
separate
them
to
two
tracks,
but
but
then
we
recently
are,
you
know
putting
merging
both
tracks
into
one
meeting
but
you're
right.
They
are
good.
I
mean
the
meetings.
B
There
could
be
a
single
meeting,
but
I
think,
having
these
discussions
be
separate,
will
allow
people
to
focus.
D
F
We,
I
think
we
agree
what
we
said
at
that
working
with
share
meeting
when
we
discussed
this
is
that
we
will
drive
the
meeting
through
the
agenda
so
make
sure
that
everything
is
discussed.
Everything
is
documented.
F
Discussions
are
sufficiently
separated
and
concluded
so
yeah.
I
think
we
agree.
C
All
right
so
back
to
the
action
items
so
we
have
last
time
talked
about.
You
know
we
were
discussing
the
the
idea
of
parsing
and
finding
the
bottom
stack
and
how
you
you
did
express
interest
in
providing
an
example
in
p4.
I
don't
know
if
you
have
an
update
on
that
action
item.
D
Yes,
yes,
but
I
think
we
need
more.
I
need
more
time.
Maybe
we
can
defer
this
to
next
meeting.
I
do
have
something
prepared
sure.
C
All
right,
I
think
these
are
you
know
we
talked
about
you,
know
mutable
and
immutable
data
that
can
be
carried
in
the
mpls
header
or
after
the
mpls
header.
We
talked
about
variable
ancillary
data
when,
when,
when
stewart
was
presenting
the
idea
and
the
idea
of
putting
it
towards
the
end
for
this
variable
length-
and
there
were
a
couple
of
ideas
there,
so
this.
D
A
I
looked
at
the
iom
spec
this
morning
and
it
appears
that
to
prescribe
that
the
packet
pre-allocates
space
for
the
iom,
information.
D
There
are
two
options:
why
is
the
incremental
ones
pre-allocated.
H
Yeah
hi
everyone
so
yeah
there
is
a
preallocated
and
incremental.
I
think
there
are
two
trace
points
that
I
have
seen
in
the
ippm
iom
document.
D
For
the
incremental
option,
it's
a
the
the
data
will
be
pushed
into
the
node
data
immediately
following
the
option.
Header
there's
no
pre-allocated
fitting.
A
D
A
Yeah,
you
know
I
I
just
say
I
read
the
draft
this
morning
and
maybe
the
draft
isn't
clear.
A
That's
what
I
would
have
thought
so
I'm
reading-
and
I
maybe
I
don't
understand
it,
but
I'm
reading
section,
5.4
of
draft
idf,
ippm
iom
data
version
12
and
in
the
middle
of
the
section,
on
incremental
trace
option.
A
A
Now
I
don't
know
w
what
which
of
those
two
is
the
correct
interpretation.
But
I
do
wonder
what
happens
about
p
path,
mtu,
etcetera
if
packets
are
randomly
increasing
the
size
of
a
packet
along
its
path
is
where
nodes
are
doing
that,
but
anyway,
because
someone
just
clarify
what
that
sentence
in
the
middle
of
the
paragraph.
A
A
D
A
I
think
incremental
so
pre-allocate,
I
think,
says
your
node
six.
This
is
where
you
put
your
information
at
least
that's
my
interpretation
of
it,
whereas
incremental
the
encapsulating
node
says
here's
100,
bytes
and
then
node
6
says.
Oh,
I
need
to
put
something
in
here.
I
will
put
the
information
in,
but
I
don't
know
whether
that's
what
it
means
on
it.
Certainly
that's
that's
not
easy
to
define
to
determine
from
the
text
in
the
draft.
C
Okay,
I'll
try
to
search
for
it
or,
if
you,
if
you
paste
it
in
text,
will
be
helpful.
C
It's
recording,
we
are
recording.
I
apologize.
I
didn't
want
to
interrupt
people
when
they
were
speaking
so
I
started
the
recordings.
That's.
I
Fine,
okay,
okay,
I'm
sorry!
I
just
wanted
to
mention
that
my
interpretation
of
incremental
is
as
noted
by
arrakesh,
and
so
it's
each
note
each
iem
node,
if
it's
half
by
half
option
adds
to
the
packet.
So
no
there
is
no
pre-allocated
space
and
the
text
that
stuart
pointed
out.
It's
really
confusing
now
and
I
think
it's
a
critical
to
bring
it
to
discussion,
because
this
document
is
in
isg.
I
A
Yes,
it
is
certainly
critical
to
do
that
now.
The
other
thing
that's
critical
is,
I
couldn't
see
anything
about
how
path
mtu
is
was
dealt
with
and
if
we're
going
to
have
any
form
of
ink
of
packet
size
increment
on
its
path,
we
need
a
whole
bunch
of
text
about
pmtu.
E
A
C
Someone
who
suggested
we
send
an
email
to
the
ip
performance
management
working
group.
Anyone
wants
to
send
that
email
to
clarify
or
during
the
poll
I
heard.
C
Anyone
wants
to
vote
here.
If
not,
the
chairs
will
send
it.
A
F
C
A
A
C
F
One
one
thing:
derek
yeah:
when
we
discussed
extension
headers
last
time,
we
tried
to
place
an
action
item
on
the
author
of
well
on
kirietti
and
how
you
to
actually
look
at
the
mechanism
for
finding
out
if
we
can
use
the
creative
proposal
for
detecting
extension,
headers.
B
H
B
Either
way
I'm
happy
we
haven't
gotten
together
yet
so
I'm
happy
to
reach
out
to
how
you
so
how
you
you,
and
I
should
talk,
offline
and
figure
out
how
we
can
do
this.
A
F
C
C
Okay,
for
you,
I'll
stop
sharing
and
you
go
ahead.
D
D
A
F
D
Okay:
okay,
okay,
I'm
going
to
talk
about
this
nps
extension
header
draft.
The
current
version
is
zero
four,
but
we
can
actually
start
this
work
in
2018
on
the
the
motivation
for
it
is
that,
at
that
time
you
find
many
novel
in
in
network
service
emerging.
D
What's
so
called
the
in-network
service
means
that
this
service
or
application
is
added
within
the
network
no
start
from
the
end
host.
Such
use
cases
include
the
in-situ
oem
for
user
traffic,
telemetry
data
collection
and
network
slicing
by
splits
network
resource
to
support
a
multiple
virtual
networks
and
service
function.
D
Chaining,
which
is
a
we
all
know,
are
used
to
access
different
functions
in
network
using
a
chain
and
the
beer
is
a
new
multicast
protocol
on
and
also
we
find
we
have,
the
segment
routing
and
within
the
second
routine.
We
can
do
our
wireless
kind
of
network
programming.
D
These
are
all
needed
to
add
some
specific
headers
to
the
to
the
package,
to
tell
the
node
what
to
do,
and
there
are
other.
This
is
actually
a
very
active
area.
People
also
propose
to
add
actual
headers
to
the
package
for
net
network
security
functions
such
as
a
ddos
detection
prevention
and,
of
course,
by
using
I
introduced
in
network
service.
We
can
do
a
lot
of
different
natural
telemetry
techniques
to
increa
improve
the
network
visibility.
D
So
there
are
some
requirements.
Common
requirements
for
this
e-network
services
is
that
first
now,
the
user
traffic
needed
to
be
able
to
encapsulate
some
actual
instruction,
header
or
metadata
to
it,
and
also
because
this
is
in
network
services,
and
we
need
to
be
able
to
add
process
and
remove
those
instruction,
header
or
metadata
in
the
network.
D
So
we
can
note,
are
limited
to
only
the
end
host
and
also
it's
very
possible.
We
will
support
multiple
parallel
services
in
a
single
user
package,
so
we
need
to
be
able
to
select
multiple
coexisting
services
on
a
packet
and
so
far
there's
no
standard
solution
for
npos
to
meet
such
requirements.
Yet,
so
that's
why
we
come
up
with
this
idea.
So
the
solution
is
to
introduce
mps
extension
headers
to
the
mps
network
and
we
should
stop
designing
piecemeal
solutions
and
incompatible
solutions
which
compete
some
common
resources.
D
Like
you
know,
if
we
work
in
that
way,
each
one
might
require
some
special
purpose
label,
also
very
commonly
they
will
request
to
use
the
location
after
the
label
stack.
D
So
if
we
do
the
piecemeal
solution
we'll
end
up
with
this
a
bad
situation
and
instead
we
should
define
a
generic
framework
once
for
all
the
basically,
we
can
encapsulate
the
service
instruction
and
header
or
metadata
as
a
extension
header.
D
So
extension
header
is
like
a
common
container
for
all
this
to
meet
the
requirements
for
all
of
the
different
applications,
and
then
we
can
insert
those
extension
header
between
the
mps
label
stack
and
the
payload,
so
this
in
concept
is
very
similar
to
the
ipv6
extension
header,
but
we
all
know
it's
also
very
difficult
to
use
the
extension
heading
mpv6
networks,
so
we
should
learn.
Experience,
learn
lessons
from
the
from
ipv6.
D
So
what's
good
and
bad
about
ipv6
extension
header,
the
good
thing
about
it
is
it's
try
to
keep
the
base
header
and
make
all
the
optional
extension.
Headers
are
flexible,
and
so
we
can
chain
those
extension
headers
together
and
in
this
way
we
can
support
multiple
extension
headers
in
a
single
packet.
D
Also
we
unified
for
ipv6.
It
unifies
the
extension
headers
as
just
another
product
headers
using
the
next
header
indicator,
so
the
the
next
header
is
unified
is
encoded
using
the
unified
net
internet
protocol
number.
D
So
in
this
way,
the
the
up
of
the
upper
layer
particles
like
the
layer,
4
tcp
udp,
is
just
a
look
as
if
another
extension
header,
but
there
are
many
drawbacks
about
ipv6
extension
headers.
The
the
fourth
thing
is
it's
enforced
by
the
rfc
8200
that
the
first
one
is
only
end
host
are
allowed
to
add
and
remove
extension
headers.
D
This
is
a
seriously
limited
usefulness
of
exchange
header
because,
as
I
mentioned
for
many
in
network
services,
those
headers
must
be
added
or
removed
in
network
node
from
and
host,
and
also
the
for
the
ipv6.
Only
one
hop
by
hub
header
is
allowed,
but
you
you
can.
We
can
imagine
we
might
need
to
manage
multiple
of
the
hub
services,
but
in
ipv6
they
are
forced
to
to
use
a
hierarchical
structure.
D
I.E
we
just
need.
We
can
only
support
this,
these
functions
by
making
each
of
this
as
a
hbh
hotbed,
hub
options.
So
just
us
stack
them
again
into
a
single
https
header,
which
is
inflexible.
D
Also,
we
simply
change
this
extension
headers
together,
there's
no
way
to
directly
access
the
original
up
layer
or
payload.
So
in
case
we
want
to
access
a
header
like
such
as
a
tcp
udp,
and
we
need
to
scan
through
all
the
extension
headers.
So
that's
the
is
kind
of
inefficient.
D
So
the
the
the
concept
of
the
ips
extension
header
is
very
simple:
we
just
stack
all
multiple
extension
headers
together.
Actually,
we
also
use
a
usage
to
chain
them
together.
Basically,
you
this
is
a
very
similar
to
the
ipv6
extension
header,
always
keep
jumping.
D
D
So
in
this
way
we
can
unify
this
with
using
the
ip
network
and
also,
we
add
another
summary
of
the
extension
header.
We
call
that
header
of
the
exchange
header
or
he
h,
which
is
used
to
summarize
how
many
extension
headers
we
have
and
the
what's
the
length
of
that.
So
this
can
allow
us
to
jump
into
all
the
extended
headers
in
just
one
step,
and
we
also
add
need
to
add
two
special
next
hazard
tabs.
The
first
one
is
none,
which
means
there's
no
other
extension
headers
behind
it.
D
The
second
second
type
is
a
special
types,
the
unknown,
because
this
is
because,
in
the
current
npr's
design,
there's
no
way
from
the
label
stack
to
indicate
what
type
of
the
payload
is
include.
So
if
we
won't
insert
a
new
extension
header
within
the
network,
we
might
not
have
that
knowledge
as
well.
So
that's
the
easiest
way
to
do
is
to
just
mix
a
next
header
unknown.
So
this
is
a
try
to
be
compatible
with
the
current
nps
practice
and
having
this
extension
headers.
D
We
also
need
to
have
an
indicator
on
in
the
nps
label.
Stack
to
tell
there
are
exception,
headers
need
to
be
processed
after
the
label
stack.
D
So
in
in
two
weeks
ago,
I
have
a
presented
several
optional
ideas
to
support
that,
although
it's
still
pending
to
decide
on
which
one
is
the
best.
D
Also
we
we
can
support
two
types
of
extension
headers.
The
first
is
a
end
to
end,
which
means
this
header
should
only
be
processed
inserted
or
removed
by
the
tunnel
and
the
nodes
like
the
p
device,
but
the
other
hold
by
hope.
Type.
Extension
header
means
to
be
processed
by
every
node
along
the
mpls
following
path.
D
So
this
slides
gives
you
more
details
about
our
encapsulation.
D
The
find
the
pointer
so
the
the
fourth
part
is
the
mps
label
stack
and
within
it
there
are
some
indicators
where
it
is
located
is
a
node.
That
is
to
be
determined.
But
the
point
is
we
need
something
to
indicate
that
after
the
label
stack,
there
are
extension
headers,
then
after
the
label
stacks.
The
first
word
word
is
a
called
header
of
the
extension
header.
D
The
first
nibble
is
reserved.
It
should
avoid
using
some
existing
defined
number
like
a
four
or
six
or
something
else
to
note
confuse
this
with
a
normal
package,
ip
packet
and
then
follow.
This
is
a
the
extension
header
count
to
tell
you
how
many
extension
headers
you'll
follow,
follow
this
work
and
also
the
total
length
of
the
extension
header.
D
Then
next
header
then
the
last
part
is
the
next
header
tell
you:
what's
the
type
of
the
header
immediately
follow
it
and
then
then
you
change
this
header,
one
to
header
end
together.
D
So
each
header,
what
we
didn't
need
to
define
the
internal
structure
of
each
extension
header,
but
each
of
them
has
two
leading
words.
One
is
just
tell
you
what's
the
type
of
the
next
header
and
then
tell
you
what's
the
length
of
the
current
header,
so
this
is
identical
to
the
what's
in
ipv6
extension,
header
and
finally,
on
the
for
the
last
extension,
a
header,
the
next
header
will
to
point
to
the
original
upper
layer
for
particle
whatever
it.
It
is.
D
D
So
we
all
know
there
are
some
limitations
or
constraints
for
hardware
capability
to
process
a
header.
So
the
header
overhead
is
a
big
concern,
but
but
for
ipv6
header
overhead
is
is
big,
but
for
mpos
each
label
is
just
a
four
bytes
four
by
long.
D
D
It
gave
us
more
flexibility
and
the
room
for
for
new
network
innovations
and
by
designing
this
extension
header
idea.
We
do
need
to
have
several
considerations.
The
first
is,
of
course,
the
performance.
D
We
all
realize
that
by
adding
the
extension
headers,
those
headers
are
supposed
to
be
processed
by
the
data
plane,
and
thus
the
performance
is
a
critical
we
should
ensure,
but
then
they
wouldn't
actually
slow
down
the
folding
performance.
So
that's
a
big
concern.
The
second
one
is
the
scalability.
D
So
in
terms
of
the
on
what
kind
of
functions
we
can
support
and
how
we
use
the
existing
resources,
like
the
label
space,
like
number
of
special
purpose
indicator
required.
D
Those
are
all
limits,
the
the
scalability
of
the
solution,
and
we
might
also
consider
about
the
backward
compatibility
to
what
extent
we
want
this
to
still
be
applied
in
the
current
or
legacy
mps
network.
That's
a
big
question
because,
of
course,
by
introducing
any
of
this
new
header,
our
new
extension
headers,
all
these
new
functions,
the
lexi
node
will
not
be
able
to
process
them
or
even
recognize
them.
Then
do
we
really
need
you
know
once
we
enable
this
new
type
of
package,
new
new
new
extension
headers?
D
Do
we
really
need
the
network
legs
network
can
still
at
least
afford
aid,
or
we
just
need
to
require
the
the
entire
network
to
be
upgraded
before
we
can
apply
that.
So
that's
a
big
question
and
the
last
thing
is
flexibility.
D
We
cannot
foresee
once
we
give
this
mechanism,
it's
just
like
a
container,
so
it's
open
to
any
future
innovations.
So
we
should
keep
it
very
flexible
by
note
added
any
artificial
limitations
to
the
solution.
D
So
I
think,
based
on
the
current
existing
some
examples,
we
already
seen
examples
that
you
know
it's
a
very
diversified
applications
and
also
also
we
are
not
clear
but
based
on
my
past
knowledge
that
some
node
will
change
its
size
during
the
transmission.
Some
header
will
change
its
size.
So
so
that's
why
we
shouldn't
give
any.
You
know
artificial
limitations
to
make
it
inflexible,
because
otherwise,
if
we
don't
make
it
right,
then
at
some
point
we
may
face
a
situation.
D
Okay
again,
we
can
now
support
some
specific
services
that
will
be
a
bad
situation
and,
in
addition
to
the
indicator,
dropped
and
this
extension
header
dropped.
It
describes
the
format
of
the
extension
headers
and
we
also
have
a
two
more
drives
talking
about
npr's
extension,
header
architecture
and
operations,
then
for
those
those
two
I
I
will
find
time
to
give
a
further
presentation
about
them,
but
this
is
this
is
all
for
today.
Thank
you
very
much.
D
B
B
So
you
know
it's
probably
worthwhile
for
you
both
to
talk,
but
the
question
I
have
is:
is
it
useful
to
separate
hop
by
hop
extensions
and
sort
of
more
end
to
end,
although
the
end
is
harder
to.
G
D
D
It's
a
good
question,
so,
the
first
of
all,
it's
obviously
those
two
types
of
headers
have
very
different:
behavior
one
only
need
to
be
handled
by
two
nodes
and
another
is
handled
knows
by
the
path.
So
the
reason
we
separate
this
tool
is
the
for
also
for
the
optimization
we
we
I'm
missing
that
point.
Actually,
actually
we
we
should.
We
should
always
insert
the
hbh
help
by
hub
extension,
headers
in
front
of
the
other
e2e
headers.
D
So
in
that
way
you
can
have
a
better
access
to
those
hbh,
because
those
are
processed
perhaps,
and
why
we
do
this,
because
you
know
once
we
have
multiple
extension
headers
the
size
could
be
very
large,
so
you
think
about
the
second
routine
srh
and
iom
header.
Those
are
all
very
large,
then
if
we
don't
limit
their
insertion
location,
then
it's
possible.
It
will
be
located
outside
of
the
packed
window
beyond
the
processing
capability
of
the
chip.
D
Then
we
can
not
see
them
anymore,
but
if
we
put
them
in
front
of
them
in
front
of
the
headers,
then
that
makes
that
will
make
them
easy
to
be
seen
by
most
of
the
devices.
Then
those
can
be
processed.
B
Yeah
great,
I
agree
and
also,
I
think,
there's
a
possibility
that
in
doing
the
hop
I
have
processing
you
absorb
the
hop
by
hop
stuff,
in
which
case
when
you
you
know,
get
to
the
end.
You
only
have
very
little
to
process
so.
B
That
brings
me
to
my
other
point,
which
is
both
you
and
jeffrey
are
using
the
ipv6
sort
of
tlv,
but
the
tlv
is
next
header
type
and
then
length
and
then
value-
and
I
understand
why
ipv6
did
it,
but
I
don't
think
we
should
do
it
in
mpls.
B
B
So
let's
say
I
want
to
put
it
after
extension.
Number
three,
but
extension
number
three
is
already
saying
the
next
extension
is,
you
know
xyz.
Now
I
want
to
insert
something
in
there.
I
have
to
rewrite
this
current
extension
extension,
three
next
pointer
to
be
the
new
one
put
the
new
one
and
so
the
new
one
says
the
next
pointer
is
whatever
was
the
original.
You
know
extension
for
so
yes,
it
would
be
much
much
more
much
simpler
and
much
more
localized.
D
I
I'm
not
sure
because
it
seems
to
be
away
there's
a
next
type
of
current
lens
current
value.
If
you
look
at
the
structure
of
each
header,
yeah
yeah,
you
you,
you
are
right,
but
if
we
need
to
insert
a
new
header,
we
need
to
modify
the
previous
next
header
and
the
yeah.
Of
course,
the
current
header,
you
already
format
that,
because
you
know
where
you
insert
it,
you
already
know.
What's
the
next
header,
what's
the
current
lens,
so
you.
G
D
No
that,
then,
that
that's,
why
that's
a
problem,
because
if
you
only
describe
itself,
then
you
will
keep
all
those
somewhere
else.
You
also
need
to
modify
that
no.
A
H
G
H
B
And
you
know
I
I
think
we
should
start
off
with
the
next
header
saying
you
know
this
is
tcp
or
udp
or
whatever,
and
and
so
then
they
followed
that
philosophy
where
that
came
from.
I
don't
know
so
maybe
you
know
what
stuart
said,
but
we
are
starting
a
fresh
here,
and
so
I
think
we
can
do
this
right,
and
so
I
mean
it's,
it's
not
a
huge
change,
but
I
think
it
makes
a
big
difference
to
people
who
are
parsing,
as
well
as
people
who
are
inserting
and
removing
things.
A
A
So
is
the
assumption
that
every
node
can
figure
out
which
of
this
mess
of
extension,
headers
it
needs
to
process.
If
so,
how
on
earth
does
that
work?
Because
in
the
modern
world
we
we
tend
to
be
making
the
packets
describe
their
own
processing
characteristics
as
they
go
through
the
network
and
not
all
processing
actions
will
have
to
happen
on
every
hop.
D
But
you
I
mean
in
mps,
you
do
use
a
label
to
identify
the
node
so
which
means
even
you
bind
the
header
to
the
label.
You
basically
just
carry
that
in
the
package
right.
C
C
D
A
So
we
built
service
chains
by
having
the
the
the
mps
label
stack
point
to
different
service.
D
So
yeah
for
service
chain-
I
mentioned
as
a
use
case-
I
I
will
just
add
the
nsh
as
a
extension
header,
then
also
by
doing
that,
we
can
support
adding
more
metadata
to
the
that's
much
better
solution
than
current
proposed
in
mps,
because
in
that
way
you
can
only
use
a
label
to
identify
the
the
the
the
chain
to,
but
you
cannot
add
any
optional
metadata
pass
any
metadata
between
the
nodes.
So
if
we
put
the
nsh
as
a
extension
header,
then
we
can
actually
support
the
function.
D
An
array
because
we
carry
that
all
the
information
within
slash
header
we
can
the
node
can
definitely
know
if
it's
a
need
to
process
it
or
not.
D
Extension
header,
so
it
doesn't
mean
so
we
can
use
this
for
any
existing
rfc.
So
you
use
a
existing
rfcs.
Maybe
you
you
shouldn't
use
that
to
do
the
service
function,
training.
B
So
I
want
to
get
off
the
subject
of
service
function
chaining
and
to
the
more
general
question.
I
I
agree
with
how
you
that,
if
you
say
this
is
hot
by
hop,
then
every
node
should
at
least
peak
at
it,
or
I
mean
assuming
it's
within
the
processing
budget
should
peak
at
it
and
say:
does
this
apply
to
me
a
lot
and
if
it
only
applies
to
certain
nodes,
then
maybe
the
self-describing
part
also
says
to
which
nodes
it
applies,
but
in
general
we
are
having.
B
We
have
this
dichotomy
either
every
node
looks
at
it
or
only
the
end
nodes
look
at
it
and
that
you
know
so,
if
you
don't
have
any
hop
thing,
you
know
you
can
just
skip
by
it
and
then
just
pass
it
on
to
the
next
guy.
But
if
there
is
hop
by
hop
you'd
have
to
to
the
best
of
your
capability
process
the
hub
by
hop
pieces
and
see
what
applies
to
you
and
the
processing
could
be
just
you
know,
it
doesn't
apply
to
me,
but
you
have
to
do
that.
C
So
kiriti,
I
think
what
you're
saying
is
that
the
node
itself
can
have
a
policy
to
say
that
either
process
or
not
or
you
can
put
the
policy
inside
the
packet
to
say
you
know
this
node
should
process
it
or
not,
and
I
you
know.
Ideally,
I
would
like
to
see
you
know
in
the
packet
we
can
carry
such
a
policy
if
we
need
to
indeed.
A
D
D
D
C
We
we
yeah
we.
I
would
like
to
see
that
we
we
tackle
the
problem
and
then
find
the
solution,
and
we
agree
on
the
problem.
I
mean
right
can.
A
B
I
think
that
would
be
good.
I
think,
there's
and
you
know,
there's
potentially
since
there's
a
header
of
headers
kind
of
thing,
there's
potential
place
in
there
to
say
here
are
the
the
the
types
of
nodes
that
should
process
this
or
or
maybe
some
you
know,
not
not
specific
node
call
outs,
but
a
way
to
sort
of
encapsulate
nodes
that
are
area.
Border
routers
should
should
process
this
or
whatever
something
right.
B
The
other
thing
I
would
say
is
that
going
further
on
the
the
sort
of
order
in
which
you
put
these
things,
if
you
put
the
hop
by
hop
things
that
you
think
most
nodes
will
process
up
front
and
then
put
the
hop
back
up
ones
that
you
know
are
more
filtered
further
down
and
then
at
the
bottom
you
put
the
end-to-end
stuff,
then
the
the
probability
that
you
have
to
go
deeper
and
deeper
into
the
packet
goes
down.
B
G
So
I
I
think
the
you
know
what
what
you
said
about
the
self-descriptive.
I
think
the
the
the
mistake
that
was
done
in
v6
was
that
this,
the
scheme
of
you
know
pointing
to
the
next
one
that
makes
sense
when
you
go
into
a
different
name
space
like
what
we
do
when
we
go
across
layers
right
from
network
layer
to
transport
and
so
on,
but
here
we're
really
staying
within
the
same
layer
right.
So
that's
why
the
self-descriptive
is
a
lot
more
natural
and
I
think
what
they
just
applied.
G
You
know
principle
across
ip
and
tcp
to
extension,
headers
in
v6,
which
I
think,
but
so
sorry
my
question.
G
B
So
I
think
both
addition
and
removal
of
headers
would
be
good
not
to
rule
out.
Upfront
goes
back
to
what's
how
you
think
about
flexibility
and
to
the
extent
that
you
can
remove
things
you
make
processing
for
everyone
who
comes
afterwards
easier.
B
So
I
think
those
are
good
things
to
keep
in
the
architecture
and
you
know
again,
subject
to
use
cases
betting
this
out.
But
if
you
can
do
that
without
burdening
the
architecture,
I
think
that's
a
good
thing
to
have.
G
So
because
I'm
asking,
because
I
think
very
fundamentally
right
so
srh
had
to
basically
live
with,
not
removing
anything
and
they
try
to
define
that
also
as
a
benefit,
and
I
haven't
tried
to
figure
it
out
that
you
have
more
visibility
about
what
happened
with
the
packet
on
the
receiving
side.
And
so
I'm
wondering
if
we're
talking
about
option,
if
you
know
not,
removing
things
has
could
also
have
benefits
in
the
mpls
world.
B
So
I
I
mean:
there's,
there's
always
a
benefit
that
you
don't
have
to
change
the
overall
packet
length
or
or
stuff,
although
we
don't
have
an
overall
packet
length
or
maybe
it's
out
in
the
ethernet
header-
I
don't
know
but
but
for
me
the
the
value
of
this
is
I
mean
if
you
do
classical
mpls
and
you
have
these
hierarchical
lsps.
B
You
might
say
I
want
to
add
another
iom
or
another,
something
for
that
segment,
which
is
my
hierarchical
lsp
and
then
at
the
end
of
that,
I
want
to
remove
it
and
and
so
that
the
end-to-end
label,
sorry
mpls
packet,
would
have
these
sections
where
it
makes
sense
to
do
certain
things
and
then
remove
them,
and
so
both
insertion
and
removal.
Just
as
you
would
in
certain
remove
labels
you
might
want
to
insert
and
remove
it.
A
There's
a
big
difference
here
we
insert
and
remove
labels
at
the
top
of
stack.
I
think
if
you
want
to
carry
iom
or
some
other
thing
across
a
segment,
you
probably
have
to
terminate
the
stack
and
then
manage
everything
locally.
Otherwise,
you've
basically
got
to
shift
some
unknown
amount
of
information
up
a
bit
and
stuff
some
spare
information
in
and
then
figure
out
where
to
take
it
out
later
on,
whereas
at
least,
if
you
put
it
at
the
top
as
a
block
yeah,
these
are
the
label
set.
These
are
the
oa.
B
I
understand
what
you're
saying
no,
I
get
you
but,
but
I
think,
if
you
think
of
everything
that
comes
above
what
is
here,
the
yellow
piece,
the
in
original
inner
packet
as
stuff
you
put
onto
the
packet?
Yes,
it's
much
bigger
than
the
label
stack,
but
it
is
tough
that
it's
not
part
of
the
original
packet
and
yes
you're
playing
with
that,
and
it
is
harder
to
do
than
just
playing
with
the
top.
You
know
50
bytes,
now
you're,
maybe
playing
with
500
bytes
or
whatever
the
number
it
turns
out
to
be.
B
But
I
think
where
we
are
with
forwarding
engines
today
versus
where
we
were
10
or
20
years
ago.
Some
of
this
can
be
done,
and
so
I
don't
see
that
we
should
rule
it
out
offhand.
B
The
caveat
so
that
you
just
said
that
hey,
if
you
insert
a
header
or
remove
a
header,
you
know
there
could
be
performance
implications
of
that
should
be
spelt
out.
But
to
say
that
you
terminate
a
tunnel
because
you're
entering
a
different
zone.
I
mean,
if
you
just
think
about
hierarchical
tunnels.
You're
defeating.
C
D
So
then
that's
my
current
thinking,
because
if
you
mix
them
together,
then
it's
a
very
bad
right,
because
it's
no
longer
can
be
done
in
fastpass,
then
we,
you
know
just
get
to
the
same
issue
as
that
was
discussed
in
ipv6.
A
B
Also
does
in
a
way
because
a
lot
of
people
say
we
won't
do
extension
headers
in
ipv6,
because
they'll
kill
us
and
so
they're
like
they.
They
blanket
just
block
packets
that
have
extension
headers
for
certain
types,
at
least.
B
True
true,
but
I
mean.
D
B
B
So
I
agree
with
you
but
but
but
I
think
the
lessons
learned
should
should
give
us
a
little
guidance.
G
That's
so
so,
basically,
what
certainly
makes
sense
at
some
point
in
time
when
we
know
what
we
want
to
do
to
be
very
crisp
about.
You
know
fast
and
slow
path,
and
if
anything,
you
know
that
somebody
wants
to
do
would
be
feasible
for
anything
else.
Then
the
fast
path,
I
think
that
should
be
explicitly
highlighted
out
and
maybe
even
explicitly
be
signaled
by
default.
Certainly,
we
should
expect
everything
to
be
in
fast
path
and
either.
G
B
So
was
that
true,
I
I
totally
agree
with
you,
but
I
think
there
is
an
issue
there
that
you
know
individually.
Each
extension
had
to
maybe
process
processable
in
the
past
path,
but
then
you
put
so
many
of
them
that
you
can't
actually
get
through
them
and
that
that's
an
issue
issue
with
ipv6
as
well.
So
yeah.
I
totally
agree
with
you,
but
you
have
to
be
careful
well,
I
was
sitting
against
the
desert
office.
G
For
for
a
long
time
and
complaining
about
b6
not
being
specific
enough
about
this,
so
I
have
my
past
pains
there.
No,
no,
I
think
you're
completely
right
that
at
some
point
in
time,
when
we
become
too
flexible,
the
basic
requirements
may
not
be
sufficient,
but
I
think
at
that
point
in
time
we
can
and
must
provide
very
good
oem
functionality
to
recognize
those
cases
and
we
are
a
controlled
network.
So
we
have
a
lot
more
freedom
and
capabilities.
There.
D
Yeah,
I
I
think
kriti
mentioned
one
scenarios
another
another.
One
is
for
many
platform
like
the
software-based
router
or
switch
there's
no
different
differentiation
between
the
so-called
fastpass
and
slow
pass.
Everything
is
processed
in
the
same
place,
so
so
it's
really
about,
if
you
can
do
it
fast
or
or
you
cannot
do
it
efficiently.
D
So
in
that
sense,
I
think
we
can
at
least
add
a
policy
that,
if
you
cannot
do
that,
you
can
decide
to
not
do
that,
not
to
process
it,
but
you
shouldn't
drop
the
packet.
You
should
still
forward
it.
So
I
think
that
should
be
a
bad,
much
better
policy
than
blindly
drops
a
package
simply
because
you
cannot
process
it.
G
D
B
You
can
advertise
it,
but
but
in
the
spirit
of
you
know
putting
things
in
the
packet,
I
mean,
if
you
go
back
to
this,
and
I
don't
want
to
architect
things
up
front,
but
where
you
have
the
next
header
equals
h1.
If
we
do
self-describing,
you
have
some
space
there
and
you
might
be
able
to
put
in
bits
that
say
if
you
don't
know
what
to
do
with
this
drop
the
packet.
If
you
don't
know
how
to
do
this
process
it
without
worrying
about
it.
B
Not
if
you
don't,
if
you
don't,
have
the
capability
of
processing
all
this,
what
do
you
do
and
I
I
think
the
idea
that
we
can
put
it
in
the
packet
to
some
extent
and
definitely
do
some
in
this
control
plane.
But
the
higher
order
bit
is
being
aware
of
this,
and
not
just
blindly
waiting
into
will
will
have
lots
of
hub
by
hop
and
other
extension
headers.
The
way
ipv6
did
and
maybe
I'm
not
being
afraid
of
them,
but
the
fact
that
we
can
be
much
more.
G
I
mean
the
the
war
burns
from
ip
and
v6
definitely
have
been
that
routers
that
shouldn't
even
do
anything
with
packets
with
particular,
you
know,
router
alert
or
extension
headers
would
punt
them
to
to
to
slow
path.
You
couldn't
prohibit
that,
and
so,
in
the
end
that
new
feature
you
wanted
to
have
completely
failed
because
of
that
backward
compatibility
issue.
Right
so
I
mean
that's
the
worst
case
but,
as
I
said
right
there
there
and
are
you.
G
I
wanted
to
say
that
they're
very
logical,
simple
things
like
is
something
optional
or
not
right.
If
it's
not
optional,
and
you
can't
deal
with
it,
what
you
do,
then,
if
it's
optional,
you
can
simply
ignore
it.
That
would
be
one
of
the
basic
you
know.
Differentiators,
for
example,.
G
If,
for
example,
things
like
yes,
I
would
agree
that
those
are
the
two
you
know
known
things
in
terms
of
ignore
it
or
drop
it,
but
maybe
for
something
it
could
also
be
remove.
The
extension
header.
D
Yes,
it
might
be
useful
to
add
some
of
indicators
to
tell
how
how
to
handle
this
particular
extent.
B
I'm
sorry
to
drop
in
the
middle
of
this
interesting
conversation,
but
I
gotta
go.
I
will
catch
up
on
the
wiki.
I
guess.
C
You
all
right
anything
else
to
how
are
you
I
think
we
you're
done.
Why
are
you
right.