►
From YouTube: IETF113-MPLS-20220324-1200
Description
MPLS meeting session at IETF113
2022/03/24 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
A
Okay,
I
think
we
have
a
tight
agenda
so
we'll
get
going
welcome
to
the
ietf
113
mpls
working
group
session.
This
is
a
hybrid
online,
with
physical
presence,
not
so
much
of
a
physical
presence
there.
As
was
pointed.
A
My
name
is
tariq
and
the
other
working
group
chairs
co-chairs
that
we
have
are
lowa
and
nick.
Our
secretary
is
mack,
he's
going
to
be
helping
us
on
minute.
Taking
today,
I
see
him
in
the
queue
I
I
want
to
welcome
our
new
ad
andrew
alston.
A
It's
my
pleasure
and
our
pleasure
to
work
with
you,
hello
and
looking
forward
to
working
with
you.
So
let
me
proceed
to
the
next
slide.
Then.
A
This
is
our
usual
note.
Well,
it
governs
the
intellectual
property
at
itf,
as
well
as
the
code
of
conduct
if
you're
participating
in
this
conference
and
you're
abiding
by
these
rules
so
make
sure
you
read
them
and
understand
them.
A
A
A
So
this
is
our
agenda,
for
today
it
is
pretty
packed
the
the
status
slides
are.
We
have
almost
11
or
12
slides
that
we
compiled,
but
I
will
not
go
through
all
of
them
in
the
interest
of
time
and
it
is
the
right
time
if
anyone
wants
to
bash
this
agenda,
change,
anything
or
add
or
remove.
Please
sound
your
opinion,
I
do
see.
Zafar
is
in
the
queue,
so
I
will
stop
right
here
and
allow
you
to
go
and
ask
go
ahead.
C
Yeah
so
many
things
there
is
a
dra.
There
is
a
slot
for
policy
or
an
npls
result
label
we
use.
I
could
not
find
a
working
group
document.
Oh
sorry,
not
working
with
any
any
document
associated
with
this.
All
I
see
is
some
slides
that
are
non-technical
and
full
of
fud
and
attacks.
So
I
I
just
wonder
about
that
being
selected
at
the
agenda
item.
A
A
It's
a
policy
on
special
purpose
label,
reuse.
The
design
team
had
worked
on
it
and
tony
had
given
the
presentation
talk
on
it
and-
and
we
thought
it
would
be
useful
for
the
working
group
this
time
to
listen
to
the
talk
in
general
rather
than
just
the
design
team.
A
D
A
So
I
will
proceed
unless
anyone
else,
I
think
laura.
Is
there
in
the
queue
as
well?
Do
you
want
to
add
anything
yeah.
B
E
I
would
be
happy
to
write
it
up
as
a
if
as
a
draft,
if
people
feel
it's
really
necessary,
you
know
if
people
think
it's
contentious.
Yes,
if
people
will
simply
accept
it
and
go
with
it,
then
why
bother.
A
I'll
move
I'll
move
on,
and
next
we
have
an
errata
that
was
reported
since
last
time
we
met
it's
against
rfc
6512
from
the
looks
of
it.
You
know
there
is
a
editorial,
maybe
or
a
typo
enter
es.
It
should
be
intra
aes,
but
it
it
might
have
a
technical
meaning
associated
with
it.
We
will
have
to
sync
up
with
ad
on
this
and
and
see
how
you
know.
A
On
the
next
slide,
we
we,
since
last
time
we
have
had
a
new
rfc.
We
want
to
thank
the
the
authors,
the
shepherd,
as
well
as
the
working
group
on
working
on
and
producing
this
document.
We
do
have
two
other
rfc
sorry
documents
that
are
in
the
rfc
editor
queue.
A
A
A
Okay:
okay,
thanks,
we
we
do
have
a
new
document
that
was
adopted
since
last
time
we
met-
and
I
I
I
don't
want
to.
We
do
have
a
set
of
documents
that
were
updated
and
I,
like
I
promised
I
will
not
go
through
the
full
status
report.
I
will
leave
it
for
the
working
group
to
to
inspect
the
slides
if
they're
interested.
A
So
I
will
switch
to
the
next
item
on
the
agenda.
Unless
anyone
has
any
specific
question
rakesh,
I
see
you
in
the
queue
so
feel
free
to
go
ahead.
D
Yeah,
I
have
very
quick
comment
on
that
draft
itf
and
pls
6374
sr,
so
we
have
requested
the
working
group
last
call
on
it.
I'm
not
sure
if
you
track
it
separately
or
not,
but
just
note
thanks.
A
Thanks
for
the
reminder,
we
do
have
you
know
a
list
of
documents
that
have
requested
the
adoption
yeah.
A
Okay,
I'll
change
the
deck
to
the
first
presenter,
who
is
going
to
be
wreck-ish?
I
believe.
Yes,
it
is
rekash.
A
A
I
will
give
you
the
the
control
on
the
slides
are
cache
as
well.
You
should
be
able
to
flip
through
them
from
the
bottom
of
the
screen.
D
D
D
So
what
this
is
the
draft
is
about
the
carrying
you
know,
iom
data
fields
with
mpls
encapsulation,
so
there
is
a
work
going
on
in
ippm
working
group.
There
are
a
couple
of
drops
on
the
iom
data.
I
believe
they
have
finished
working
blastport
as
well.
This
is
for
edge
to
edge,
as
well
as
hop
by
hop
iom.
D
So
just
a
brief
history
of
this
draft.
It's
been
around
for
more
than
three
years
now
it
used
to
be
in
spring.
It
was
presented.
There
then
moved
to
mpls
working
group,
because
it's
a
generic
application
to
mpls
data
plane.
Last
year
we
did
the
mplsrt
expert
review
and
they
were
good.
Suggestions
came
out,
one
of
them
being
used
gsch
for
the
iom,
so
we
have
included
that
suggestions.
D
Draft
was
renamed
to
focus
on
mpls
all
mpls
data
plane.
There
were
some
concerns
raised
with
requesting
of
the
multiple
espls
and
impact
on
msd.
That
might
be
the
reason
why
we
trigger
the
dt
design
theme
as
well,
based
on
some
review
comments.
So
we
have
updated
draft
to
address
those
comments
as
well.
D
D
So
this
is
the
iom,
gach
type
we
defined
to
carry
the
iom
data
fields.
This
was
based
on
the
impedance
rt
expert
review
feedback
that
this
is
a
good
option
for
it.
So
we
have
added
that
in
the
draft
there
are
two
indicators
used
to
be
different:
espl
labels,
but
based
on
feedback,
one
option
is
to
define
the
two
flags.
One
indicates
that
there
is
iom
data
present
after
the
bottom
of
the
stack,
and
there
is
a
second
flag
that
says
it
needs
to
hop
by
hop
processing.
D
D
So
yeah
we
talked
about
the
option
types.
So
if
it's
end
to
end
iom
defines
the
option
types
for
into
end
to
it.
It's
actually
called
h2h
processing
and
then
hop
by
hop
processing.
D
D
D
For
hub
by
hub,
there
is
another
flag
defined
that
says
that
iom
needs
the
hub
by
hope.
Processing
procedure
is
very
similar
to
edge
to
edge
case,
except
now
you
have
a
byte
of
processing
required,
flag
set
and
midpoint
or
intermediate
node
will
process
the
iom
data
based
on
the
flag.
D
So
welcome
your
review,
comments
and
suggestions
on
this
important
work
and
many
thanks
for
all
of
the
review
and
comments,
including
mplsrt
expert
review.
We
are
requesting
working
group
adoption
and
whatever
the
open
items,
we
can
take
it
up
as
part
of
the
working
process.
F
Yes,
thank
you
for
presentation,
as
you
mentioned
so
there
I
am
encapsulation
in
mpls
is
one
of
their
cases
for
miad
and
it's
reflected
in
the
draft.
So
can
you
clarify
what
type
of
encapsulation
this
draft
proposes.
D
Yeah
so
this
was,
there
is
a
gsch
type
defined
based
on
the
mpls
rta
feedback
to
carry
the
iom
data
field,
and
then
there
is
a
second
indicator:
that's
defined
as
bits
in
the
ttl
field
of
a
label,
label
being
entropy
label
or
spl
or
network
programming
label
to
be
discussed
as
part
of
the
working
process.
D
F
D
Yeah,
so
this
is
based
on
the
mprsrt
expert's
suggestions
to
use,
gach
and
incorporated
draft.
If
miad
comes
up
with
a
different
header,
then
it
can
be
adapted
as
part
of
the
working
process.
A
Thanks
greg,
okay,
I
have
a
question
rakesh.
You
say
that
the
the
the
the
iuem
header
metadata
or
the
they
have
this
extension
header
that
you're
proposing
should
be
inserted
by
the
by
the
ingress,
node
or
any
node.
D
So
we
call
it
the
end
cap
node
that
adds
the
iom.
End
cap
will
add
as
part
of
the
end
cap.
D
D
So
this
is
these
are
two
options
we
can
elaborate
and
agree
on
which
one
is
the
right.
One.
A
Okay,
I
I'm
just
concerned
about
the
when,
when
the
one
egress
ls
lsr
of
one
lsp
tries
to
remove
the
whole
thing,
the
whole
header-
and
you
want
part
of
it
to
persist,
and
maybe
I
should
read
that
section.
Thank
you.
A
A
Yeah,
I
I'm
it's
not
letting
me
share
your
slides,
so
I'm
not
sure
it's
telling
me
okay.
Okay,
now
it
is.
D
Yeah
I
just
released.
I
was
the
share
slide
more
so
I
just
released
it,
and
maybe
that
was
the
reason.
Oh
that
was
it
then.
Thank
you.
Okay.
Let
me
find.
A
A
G
Okay,
hello,
everyone,
I'm
xiaomi,
I'm
presenting
lsb
ping
for
sr
pass
seats.
This
chapter
was
presented
at
ietf
109.
This
is
the
second
time
is
presented
next
slide.
Please.
G
Okay,
right
now,
past
segment,
two
is
mps.
Data
plane
is
defined
in
draft
spring
ampere's
path
segment,
which
has
passed.
The
working
group
last
call
in
spring
working
group
path.
Segment
is
normally
used
by
the
egress
nodes
for
past
identification.
G
G
This
draft
provides
three
target
fact
sub
to
v's
for
past
segment,
when
pass
segment
is
used
to
identify
an
sr
policy.
The
target
effect
sr
policy
is
perceived.
Sub
v
is
included
in
the
spping
message
when
pass
segment
is
used
to
identify
an
sr
policies.
Candidate
pass
the
target
effect
as
a
candidate
passed
perceived,
sub
tuv
is
included
in
svp
message
when
pass
segment
is
used
to
identify
a
segment
list.
The
target
effect
as
a
segment
list
passive
sub
to
v
is
included
in
the
spp
ping
message.
G
This
slide
illustrates
the
format
of
sub
policies
passed
it
sub
to
v
as
specified
in
segment
routing
policy
draft.
A
sr
policy
must
be
identified
through
the
tuple
head
and
color
and
endpoint.
G
G
G
G
So
the
authors
believe
this
chapter
is
straight
forward
and
it's
ready
for
working
group
adoption.
Thank
you.
A
No
questions,
I
have
a
quick
question
for
you.
Please
is
the
path
segment
only
relevant
at
the
egress,
or
would
the
transit
node
be
interested
in
this
path?
Segment
id.
G
Yes,
in
the
zero
zero
version
of
this
job
to
we
have
no
decision
on
whether
it's
only
to
egress,
node
or
is
also
relevant
to
transient
nodes,
and
after
revision,
we
decided
to
decided
to
change
it
to
just
for
egress
node
to
check
to
validate,
because
we
think
past
segment
from
the
the
discretion
of
the
past
segment.
Working
group
draft,
we
think,
is
just
relevant
to
the
egress
note.
That's
the
decision
from
the
authors.
A
Thank
you
we'll
move
to
the
next
presenter.
I
guess
I
don't
see
anyone
on
the
mic
trying
to
ask
a
question.
Okay,.
A
Thanks,
I
think
greedy
is
next.
Let
me
find
your
set
of
slides
deprecating.
I
I
think
I
can
hear
you
okay
all
right
this.
This
is
a
fairly
straightforward
draft.
Many
thanks
to
ron
for
pushing
me
to
do
this
and
for
preparing
the
slides
so
next
slide.
Please.
I
So
the
proposal
is
fairly
straightforward:
the
lsb
ping
rfc
8209
80
80
229
basically
says
use
a
router
alert
option
in
the
ping,
packets
and
we'll
explain
in
the
next
few
slides.
Why
that's
not
a
good
idea
and
why
it's
unnecessary
and
so
we're
proposing
to
remove
this.
This
option
from
lsb
ping
and
in
the
process
we'll
reclassify
7506
to
historic,
7506
registers,
routing
alert
option
for
ipv6.
I
You
have
to
say
why
you
want
to
use
it,
so
it
basically
says
we
want
to
use
it
for
mpls,
so
we
don't
need
it,
and
this
is
the
only
use
of
it.
So
it
becomes
historic
and
the
reason
for
doing
all
this
is
that
router
alert
does
pose
some
security
issues.
So
you
can
read
rfc
6398
to
understand
those
those
issues
and
it
also
allows
the
six-man
effort.
I
That's
looking
at.
You
know
how
to
resurrect
the
hop
by
hop
options
and
what
to
do
about
it.
They're,
considering
whether
we
need
router
alert
in
ipv6
and
they
might
get
confused
that
you
know.
Lsp
ping
really
needs
it.
So
this
gives
them
the
freedom
to
say
we
don't
need
that,
and
the
biggest
thing
is
that
we
really
don't
need
router
alert
in
lsp
ping.
I
So
here's
what
an
lsp
ping
packet
looks
like
you
got
to
read
this
from
the
bottom
up,
so
you
got
the
label
stack.
You've
got
an
ip
header
inside
that
and
in
the
echo
request
the
router
alert
is
mandatory.
I
Then
you
have
a
udp
with
a
well-known
port
number
saying
this
lsv
ping,
and
then
you
have
the
actual
contents
of
the
lsp
ping
next
slide.
Please
so
echo
reply
looks
quite
similar.
A
couple
of
things
that
are
different.
I
don't
believe
you
actually
need
an
mpls
label
stack
in
the
ip
header.
The
router
alert
is
optional,
but
then
you
have
the
udp
header
and
then
you
have
the
reply.
Contents
next
slide.
Please.
I
I
I
I
It's
like
yeah,
so
it's
total
paranoia.
Two
levels
are
plenty
and
I
don't
believe
anyone
actually
implements
using
router
alert
in
the
lsb
ping
and
even
if
they
did
it's
a
simple
change
to
remove
it
and
it
doesn't
add
any
protection
next
slide.
Please.
I
Now,
for
the
echo
reply,
it's
a
different
motivation
and
this
one's
even
more
questionable.
The
reply
has
several
modes.
One
says
I
don't
care
about
the
reply.
I
just
want
to
ping
in
the
forward
direction,
not
not
used
very
much.
I
I
So
I
think
we
would
like
to
have
the
working
group
look
at
this.
You
know
give
us
feedback
in
terms
of
especially
if
anyone's,
actually
using
it.
If
anyone
actually
thinks
it's
useful,
I
don't
believe
so,
but
you
know
I
think
the
working
group
should
review
it.
I
I
think
it's
fairly
straightforward
to
adopt
this
and
actually
move
it
on
to
to
you
know
to
the
next
stage
and
to
classify
or
reclassify
7506
as
historic
and
probably
it
would
be
nice
to
tell
the
I
think.
It's
six
man,
that's
doing
the
hobbyhop
stuff
in
ipv6
and
tell
them
hey
if
you
thought
mpls
needed,
router
alert,
it's
no
longer
the
case.
F
Mapping
of
ipv4
loopback
range
has
no
special
meaning
in
ipv6,
and
at
least
one
operating
system
allows
use
of
these
addresses
and
they
get
out.
So
ipv6
has
only
one
single
loopback,
which
is
a
address
one.
I
Okay,
that's
good
to
know
the
reason
why
we
actually
said
use.
The
whole
range
was
to
give
a
little
more
chance
for
entropy,
because
lsp
ping
in
the
hop,
I
hope,
the
traceroute
mode.
You
want
to
explore
all
the
different
paths
and,
if
you're,
including
the
ip
address
in
your
exploration
in
in
your
ecmp,
that
would
help.
I
So
that
would
be
a
little
bit
painful,
but
we
still
have
the
ttl
set
to
one.
So
thank
you
for
pointing
that
out
greg.
We
will
look
at
that
and
come
back
to
you,
but
you
know
I.
I
still
think
that
we
should
remove
this,
but
ron
and
I
will
consult-
and
hopefully
the
working
group
will
also
give
us.
F
B
I
B
J
B
No
okay,
can
you
clarify
that
sure.
A
Thanks,
thank
you
or
kiriti,
we'll
move
to
the
next
presentation
and
we
have
tony.
E
So
there
are
currently
two
proposals
on
the
table
for
reusing
eli
for
indicating
the
the
miad
structure
these
are
listed
here.
These
are
both
based
on
draft
ukraine,
and
I
wanted
to
talk
about
that
a
little
bit.
E
Well,
what
is
our
deployment
critical
path?
Our
working
group
convent
needs
to
converge
on
what
we're
doing.
We've
got
software
development.
We
go
forward
right,
forwarding,
plan
and
signaling
code.
We've
got
testing
deployment,
it's
probably
going
to
take
us
about
three
years
to
get
something
deployed
here.
E
E
E
E
Most
new
platforms
will
have
software
driven
npus
miad
must
be
supportable
on
legacy
platforms,
there's
no
point
otherwise,
so
legacy
platforms
that
will
add
me
at
support
will
not
require
hardware
changes.
That's
why
their
legacy
so
claim.
3
is
kind
of
irrelevant
me
and
cannot
wait
for
new
hardware.
E
E
E
Claim
five,
an
intermediate
node
can
compute
the
ecmp
hash
with
the
el
field
and
avoid
inconsistent
load
balancing
of
traffic
flow.
That
can
happen
when
an
mpls
extension
header
alters
the
label
stack
assuming
the
ad
includes
el.
This
is
always
true,
regardless
of
the
spl,
so
this
is
not
actually
true.
E
E
E
D
Rakesh
yeah
hi,
so
thanks
tony
for
the
presentation.
Unfortunately,
I
see
most
of
the
arguments
against
the
claims
are
false,
and
not
not
very
analytical,
specifically
for
claim
one
about
faster
deployment
and
claim
for
about
signaling
extensions.
D
If
you
look
at
the
history,
entropy
label
was,
you
know,
developed
10
years
ago,
and
we're
still
doing
protocol
extensions
there
is
there
are
new
drafts
in
pce
and
whatnot
we're
doing.
Protocol
extensions
so
should
not
underestimate
the
amount
of
work
required
for
protocol
extensions
for
new
spl.
It
will
take
another
10
years
for
uspl.
D
If
you
look
at
the
history,
adding
a
one
bit
flag
in
the
eli,
just
to
say
is
me
is
capable,
is
definitely
a
lot
less
work
lost
a
lot
less
protocol
work,
lot,
less
software
development,
easy
to
certify
and
deploy
and
less
impact
on
operators
oss
system
as
well.
So
I
think
it's
definitely
faster
deployment
and
it's
also
backwards
compatible
because
of
that
big
end
cap
node
will
not
add
any
ear
life
that
will
expose
on
the
legacy
node.
D
So
from
that
point
of
view,
it's
also
a
safe
to
go
in
brownfield
network,
so
I
think
both
conclusions
for
one
and
four
that
you
have
are
completely
false.
Thank
you.
J
Okay
on
slide
three,
you
note
that
the
of
course,
the
extension
header
processing
itself,
so
then
some
any
maya,
wherever
that
formatted
would
is,
would
be
done
in
microcode.
However,
I
think
the
I
think
the
claim
is
really
indicating
that
the
existing
label
stack,
walking
and
detection
of
an
entropy
label
indicator.
That
spl
would
remain
the
same.
I
think
that's
the
important
distinction
there
so,
of
course
we're
gonna
do
whatever
miad
processing.
J
J
C
So
my
comment
is
regarding
the
claim
two
slide.
Five.
The
claim
two
is
correct
as
correct
as
two
plus
two
equals
to
four
math
jack
presentation
and
pulse
working
group
explained
the
point
on
how
to
reuse
el
reduces
the
label
stack
size
very
well
or
reference.
That,
in
fact,
is
the
other
one.
If
you
add
a
new
spl,
you
add
two
additional
label
and
also
carrying
entropy
in
entropy
and
eo
as
well
as
spl
mean
you
are
adding
two
additional
label
in
this
track
as
well.
C
So
I
mean
I,
I
don't
see
any
way
you
can
basically
support
or
or
claim
that
claim.
Two
is
false.
E
C
Like
going
back
to
what
vin
mentioned
during
pals
and
what
rakesh
mentioned,
we
have
a
defined
entropy
label
and
it's
not
fully
and
correctly
deployed
as
of
today.
Even
so,
assuming
that
you're
going
to
migrate,
everything
to
the
new
spl
is
just
visual
thinking
and
you
have
to
deal
with
it
and
then
you
will
have
to
deal
with
the
full
label
pushing.
So
you
have
to
carry
for
some.
C
You
have
to
carry
for
entropy
label,
for
some
node
we
have
to
carry
spi
is
just
just
a
message:
it's
just
full
label
you,
you
will
end
up
with
four
labels.
You
are
married.
You
are
getting
married
with
full
label
stack
for
for
a
simple
thing,
so
this
is,
please
don't
make
such
games.
E
E
All
of
this
is
doing
me
add
everything
that
assumes
that
we
are
doing
me
ad
already
has
signaling
that
we
are
only
selecting
the
ad
capable
routers.
C
K
Can
you
go
back
to?
Can
you
go
back,
go
forward
to
slide
18,
please.
K
I
agree
with
you,
but
I
I
I
would
have
like
that
summary
to
be
part
of
you,
the
summary
you
you,
you
showed
us
so
much
it's
it's
fair.
A
H
Quick,
a
couple
of
clarifications,
one
is:
does
the
miad
proposal
plan
to
cover
entropy
and
all
other
special
labels
that
are
out
there,
or
is
it
just
entropy,
and
is
that
something
that
was
been
kind
of
agreed
in
the
requirements
that
this
is
miaad
would
be
encompassed
everything.
E
While
I
can't
speak
to
what
all
proposals
are
going
to
do
of
the
proposals
I
have
seen,
there
are
opportunities
for
adding
lots
and
lots
of
various
things
onto
one
spo,
and
I
am
assuming
that
we're
going
to
basically
try
to
cram
as
much
functionality
into
one
spl
as
we
can.
H
Okay-
which
of
those
two
could
you
refer
to
that,
because
I
think
I
was
able
to
see
it
only
in
one
proposal,
the
jags
draft
that
covered
entropy,
maybe
I
missed
the
other,
which.
E
H
Clarifying
question
or
last
second
and
last,
this
is
about
miad
right.
I
wanted
to
know
your
views
on
the
draft
decline
and
what
it
proposes
and
do
you
see
any
problems
with
that.
B
E
L
A
L
A
Voice
is
very
faint,
can
you
repeat.
L
Wait
is
this
better?
No,
okay,
avoid
the
mask.
What
I
was
trying
to
say
is
also
clarify
that
that
most
of
the
claims
are
not
in
the
context
of
bruno
and
because,
where
I'm
coming
from
is
the
following
tony
right,
so
we
have
I,
in
my
view,
we
have
learned
from
the
past
and
I
take
the
example
of
ib4
and
ipv6,
which
is
maybe
not
the
right
context.
L
But
if
we
change
too
many
things,
it's
going
to
take
a
long
time
before
it's
adopted,
and
I
think
you
alluded
to
some
of
your
claims
in
the
presentation
and
we
have
to
probably
segment
the
extensions
that
we
want
to
do
in
mpls
in
two
phases.
In
my
view,
right
one
is:
what
can
we
do
with
the
minimum
effort
and
I
in
any
proposal,
I
do
agree
that
we
have
to
do
micro
code
change,
but
we
have
to
see
with
the
legacy
systems
that
we
have.
L
L
E
Well,
there's
no
question
that
they're
taking
it's
going
to
take
some
time
for
me,
ed
to
get
adopted
and
get
out
there
and
there's
no
question
that
having
all
the
functions
is
going
to
take
an
arbitrarily
long
amount
of
time.
The
only
question
on
the
table
really
is:
does
reusing
eli
save
us
time
in
getting
deployed,
and
I
don't
see
that
it
does
anything
towards
that.
A
Can
we
take
it
to
the
list
when
all
right?
Thank
you
running
out
of
time.
I
I
do
want
it's
not
a
question.
Tony,
it's
just
a
sharing
a
concern.
We
said
ancillary
data
can
change
along
the
path
of
the
packet.
A
I
So
first
first
comment
is
that,
thank
you
tony
stewart
and
john
for
this.
I
think
it's
very
important.
I
Second
thing
is:
I
wish
you
had
spoken
up
at
the
pals
joint
meeting,
and
third
is:
if
we
do
this
hack
and
even
bruno's
draft
consider
for
me
constitutes
a
hack
we're
not
making
forward
progress.
We
really
want
to
make
forward
progress
in
mpls.
Thank
you.
A
Okay,
thank
you
and
I'll
switch
right
away
to
the
next
set
of
slides
by
you.
I
think
it's
extension
headers
try
to
give
you
the
time
that
you
asked
for
it,
but
we
will
go
over
time
go
ahead
or
you
yeah.
Thank.
M
You
yeah,
so
I
have
probably
five
minutes
to
cover
this
slice
and
I
I
will
be
on
behalf
of
our
to
give
an
overview
of
a
set
of
related
drafts
centered
on
the
theme
for
mprs
extension
headers
to
enable
extensible
in-network
services
in
nps
networks.
M
Yeah,
first
a
little
bit
history,
we
started
his
work
in
middle
of
2018
and
after
that
this
has
been
involved
a
lot
today,
it's
already
the
version,
zero
six
and
also
later
in
2019,
we
decided
to
split
the
document
and
spin
off
a
part
to
discuss
options
for
the
exchange
header
indicator
and
also
we
have
two
other
documents
covering
the
architecture
network
architecture
of
using
extension,
headers
and
some
other
operational
optimizations
to
make
the
processing
faster.
M
So
the
basic
motivation
for
this
work
is
that
we
have
seen
recently
there
are
a
lot
of
in-network
services.
Our
user
packages
are
introduced.
M
This
in
these
use
cases
include
in-situm
network,
slicing
service
function,
chaining,
multicast,
segmentality
and
network
programming.
We
can
see
some
common
requirements
to
this
applications.
M
First,
we
do
need
to
encapsulate
some
actual
instruction,
header
or
metadata
in
user
package,
and
also
these
headers
are
needed
to
be
added
removed
or
processed
totally
within
the
network,
and
also
these
applications
are
mostly
orthogonal,
which
means
multiple.
Such
applications
may
be
stacked
together
in
and
coexisted
in
a
single
package,
and
also
since
they
are
applied
to
user
package,
they
they
should
support
fast
data
planning
processing,
that's
a
requirement,
a
performance
requirement.
M
We
need
to
care
about,
and
so
so
now
the
issue
is
that
we,
so
we
should
also
consider
to
support
these
new
applications
in
nps
network.
Therefore,
we
have
this
work
next,
next
slides.
Please.
M
Yeah,
so
solution
is
a
ips
extension
header
and
we
shall
stop
designing
piecemeal
and
incompatible
solutions
which
competes
the
same
resource.
We
have
seen
several
proposals
just
like
this:
they
they
specify
some
new
special
purpose
label
and
they
claim
the
location
after
the
label
stack
to
fit
actual
header
and
metadata.
M
But
if
you
consider
multiple
such
applications
to
be
applied
at
the
same
time,
there
will
be
there'll
be
issues
about
that,
so
we
should
have
a
generic
framework
once
for
all
so
the
in
this
proposals
we
have
this
extension
headers.
We
will
put
this
extended
headers
between
the
nps
label
stack
and
the
payload,
and
the
the
in
stack
indicator
to
tell
you.
Have
this
effective
headers.
M
So,
except
header
is
not
new.
It's
already
been
used
in
ipv6,
but
there
are
some
issues
about
ipv6,
there's
a
header.
We
should
learn
some
lessons
from
that,
the
first
that
that
for
ipv6
the
extent
header
can
only
be
added
and
removed
by
the
end
host.
But
here
clearly
we
need
to
support
in
network
adding
and
remove
and
also.
I
M
There's
only
one
hotbed
hub
header
is
allowed
so,
which
means,
if
you
you
have
multiple
hbh
functions.
You
have
to
put
all
of
them
as
options
in
the
single
hp,
hd
header.
Therefore,
you
create
a
hierarchical
structure
so,
but
for
the
simplicity,
simplicity,
we
should
allow
multiple
hbh
headers
together
to
be
chained,
so
we
will
have
a
flat
structure
for
processing
and
also
for
ipv6.
We
need
to
scan,
through
the
other
extension
header,
to
reach
the
original
layer
for
headers.
M
It
can
be
slow.
If
so
so
here
we
should
allow
the
we
can
skip
all
the
exchange
headers
in
just
one
step
to
access
a
layer
for
headers
if
needed,
and
in
ipv6
says,
if
you
meet
no
exchange
headers,
it
will
drop
the
package
here.
We
should,
you
know,
just
ignore
no
exchange
headers
and
still
keep
forwarding
the
package
just
make
sure
you
know
the
for
the
combat
compatibility
issues
and
also
for
ipv6.
M
M
M
You
can
see
here
we
have
a
four
group
of
possible
solutions
which
cover
all
the
possibilities
on,
as
I
think
in
other
talks.
These
are
discussed
today,
but
there
are
some
conclusions
from
the
open
dt.
M
We
will
not
go
to
the
gale
gsh
pass
and
also
in
this
job
to
be
indicated
that
we
prefer
to
use
a
single
special
purpose
label
as
an
indicator.
Next
slice.
M
Maybe
we
just
give
the
details
next
slice.
This
is
how
we
specify
the
special
purpose
label
and
for
the
extension
headers.
A
Sorry,
I
just
wanted
to
let
you
know
for
you.
If
you
can,
you
know
summarize
what
you
want
to
say.
We
are
over
time
but
I'll.
I
promise
to
give
you
some
time
and
I
think
meet
echo-
will
not
close
the
session.
Yeah.
M
Okay,
then,
okay,
let
me
just
escape
this.
M
Eight
right
now
it
extension
header
right,
yeah
yeah,
so
we
we,
we
could
support
multiple
extension
headers
in
one
package
and
we
simply
change
them
together,
and
we
also
use
the
next
header
type
to
indicate
the
next
extension
header.
We
have
some
several
special
next
headers
are
provisioned
to
support
different
cases.
For
example,
noun
means
there's
no
further.
Extension,
headers
and
unknown
means.
This
is
a
lasting
stage.
M
E
M
M
Yeah,
this
is
the
details
that
you
can
find
in
our
draft
on
how
how
we
define
the
format
of
this
exchange
headers.
You
can
see
that
basically,
the
structure
is
very
similar
to
the
ipv6
exchange
header,
but
with
some
extra
information
about
that
next
slides.
M
Maybe
this
more
details
about
how
to
optimize
the
operation
you
can
refer
to
our
drafts
for
the
details.
Next
slides.
M
It's
a
most
simple,
simplest
way
which
can
minimize
password
for
finite
state
machine
and
also
the
steps
which
can
which
is
good
for
both
storage
and
the
latency
and,
as
I
said
before,
we
put
the
hbh
headers
before
the
e3
headers,
so
to
maximize
the
usability
given
the
limited
header
buffer
size
and
also,
we
prefer
to
put
the
extension
header
indicator
at
the
bottom
stack
for
simplicity
and
backward
compatibility,
and
we
have.
We
could
use
a
the
fvc
labels
to
avoid
unnecessary
label
stack
scanning.
M
I
just
escaped
this
slide,
so
you
can
read
our
jobs
for
more
details
next
slide.
So
the
summaries
we
believe
stage
header
is
a
generic
solution
for
nprc
natural
services.
It's
built
on
a
common
industry
practice
and
the
key
performance.
Flexibility
and
extensibility
is
in
mind.
A
Thank
you.
We
don't
have
much
time
actually
with
overtime
and
I
did
close
the
queue.
I
have
any
questions,
please
take
it
to
the
email
list
and
at
this
time
I
will
ask
my
co-chairs,
if
there's
anything
else,
they
want
to
share
before
we
close
this
session.
A
Lower
you
want
to
speak.
I
see
that
you
have
the
mic
on.
A
Okay,
all
right,
thank
you
so
much
for
a
very
productive
session.
We
will
we'll
see
you
next
ietf
or
even
the
design
team
weekly
meeting
thanks
a
lot.