►
From YouTube: IETF110-MPLS-20210308-1200
Description
MPLS meeting session at IETF110
2021/03/08 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
We
are
meeting
today
for
two
hours
myself.
My
name
is
tarek.
Saad
lowa,
anderson
and
nick
layman
are
the
working
group
chairs
for
the
for
this
working
group
and
we
have
mac
chen.
As
our
working
group
secretary,
there
is
another
session,
it's
a
joint
session
with
pals.net
spring
working
group
on
friday
session,
and
it's
dedicated
the
discussion
about
certain
aspects
of
mpls
architecture
as
well
as
the
related
working
groups.
I
encourage
you
to
attend
that
meeting
as
well.
A
A
A
A
A
A
A
A
B
D
D
D
We
originally
had
part
of
the
msd
young
defined
in
the
segment
gelatin
mprs
young
module
and
it
was
decided
during
iesc
last
call
that
msd
is
small,
a
characteristic
of
mprs,
rather
than
sr
specific.
So
we
decided
to
put
this
into
a
separate
module
which
augments
the
mprs
base
year,
module
defined
in
rfc
8960
next
slide.
Please.
D
D
D
A
D
It
really
msd
type
so
right
now
there
are
two
types
defined.
If
you
there
is
actually
an
icp
registry
for
the
type
the
current
two
type
defined
as
identity
in
the
model.
One
is
the,
I
think
it's
just
the
basic
msd
type.
It
is
the
number
of
labels
a
node
or
link,
can
read,
and
the
second
one
is
entropy
erld
entropy
readable
label
depth,
as
defined
in
a
different
draft.
We
have
reference
pointers
in
the
draft.
If
you
want
to.
A
C
F
F
So
there
was
a
confusion
in
the
introduction
and
abstraction
key.
It
was
taken
as
a
only
spring
tea
extension,
but
the
draft
is
an
extension
to
the
nail
file
so
many
times
it
is
not
possible
to
have
the
effect
validation
due
to
some
of
the
effect
not
supported
on
some
of
the
routers
like
routers
are
not
upgraded
or
the
fact
is
not
present
like
for
binding,
said
or
the
static
label.
So
in
that
case
we
cannot
go
for
the
fake
validation
to
overcome
these
things.
F
We
went
for
the
neil
feck
now
neil
fake
has
different
problem
so
which
is
like
a
misforwarding
can
occur
and
oh
and
there
is
no
egress
validation,
even
if
the
trace
route
and
the
ping
is
successful
so
to
overcome
nilfek
standard
and
make
it
possible
to
trace
any
path,
irrespective
of
which
protocol
it
used.
We
came
up
with
the
egress
tlv,
so
egress
tlv
is
the
extension
to
neil
feck,
the
kneel
fact
processing.
F
F
F
These
were
the
review
comments,
so
the
first
review
comment
was
why
the
draft
generic
said
draft
and
this
graph
cannot
be
merged.
So,
after
speaking
with
the
author
of
the
generic
set
draft,
we
came
into
the
conclusion
that
both
drafts
are
for
different
purpose,
so
the
validation
level
for
both
drafts
are
different
on
eagles,
really,
the
validation
happen.
Minimum
validation
happen
on
the
data
plane
with
only
egress
ip
is
validated,
whereas
the
set
level
you
are
actually
evaluating
the
associated
sid
on
every
path.
The
second
is
for
egress
tlv,
your
transit
router.
F
If
supporting
the
nilfek,
you
don't
need
to
upgrade
the
transit
router.
Only
ingress
and
egress
need
to
be
updated.
That
is
not
the
case.
With
the
generic
set
for
general
said.
We
need
to
upgrade
all
the
routers.
So
after
discussion
with
the
authors,
we
decided
to
have
both
those
drafts
separately
as
two
different
standard,
since
they
are
on
different
level
next
slide.
Please.
F
F
F
Please
one
of
the
question
was
key:
how
the
eagles
tlv
prefix
is
derived.
So,
if
it
is,
the
agency
said,
label
set
or
any
kind
of
cell
the
egress
tlv
prefix
is
not
decided
on
the
based
of
the
label
used
in
the
path
or
the
lsp
used
in
the
path.
It
is
the
egress
of
the
complete
path
so
where
the
path
ends,
that
will
be
the
prefix
for
the
egress
tlv.
G
H
A
I
I
I
Just
to
set
the
context
for
everyone,
so
this
this
graph
was
added
for
to
support
inter
domain
ping
and
traced
out
the
response
response
for
ping
and
traced
out
comes
via
ip
in
the
inter
domain
case.
Egress
will
not
have
ip
connectivity
to
ingress
so
so
so
ingress
can
add
a
reverse
path:
segment,
tlb,
which
which
will
give
us
the
mpls
header
for
the
reply
to
come
back
from
egress
to
english.
So
few
points
this
is
optional.
Tlb
comes
an
echo
request.
I
I
I
Please
yeah
so
so
initial
subtle.
There
is
no
change
in
the
subtle
v's
logic,
but
the
initial
sub
tlps
was
referring
to
idr
segment
routing
policy
draft.
We
got
a
comment
that
we
should
define
specifically
in
the
in
this
draft,
and
it
should
be
in
the
format
of
that
the
tlv
is
using
the
mpls
om.
I
think
the
type
and
length
had
a
different
diff.
I
mean
different
size
in
the
segment
routing
policy
graph.
I
We
have
specifically
defined
the
subtleties
in
this
draft,
but
it
is
still
mapped
to
the
same
tlb
types
same
types
in
idr
segment
as
as
idea
segment
routing
policy
draft,
this
type
1
sub
tlv,
where
you
can
specify
the
label
which
label
to
use
to
come
back
from
egress
to
ingress
next
slide,
please
so
after
type
one,
if
you
notice
is
type
three
type,
two
is
srv6
sub
tlv,
and
this
draft
and
a
service
is
out
of
scope
for
this
draft.
So
this
is
that's
in
separate
effort
and
it
will
be
taken
up
separately.
I
I
I
So
this
is
pretty
simple
and
stable
draft.
We
haven't
done
much
changes
other
than
specifically
moving
the
tlvs
from
idea
to,
and
reference
from
of,
the
tlb
from
idea
and,
specifically
defining
here
a
request
and
adoption
for
this
draft,
and
that's
all
I
think
if
there
are
any
comments
or
questions
I
can
take
it.
J
I
K
Okay,
so
I
think
there's
a
rfc
called
rfc
70
7110
reply
parts
here
that
is
used
to
specify
the
written
parts
of
lsb
pin.
I
think
I
think
the
use
case
for
this
drop
is
is
valid,
but
I
think
maybe
it's
better
to
use
that
clearly
to
defend
extensions
based
on
that
tier
v.
Different
relevant
extensions.
I
K
K
I
I
That's
why
we
have
given
a
choice
to
the
responder
to
responder,
to
to
select
them
and
to
come
up
with
a
label
in
in
one
of
the
shaped
subtle
if
the
same
srgb
is
the
choice
for
the
label
other
than
that
there
are
cases
where,
if
there
are
two
interac
networks
connected
by
epe,
so
if
you
go
with
the
go
over
the
draft
it,
it
explains
how
to
how
to
learn
it.
I
mean
how
to
build
it
dynamically
when,
as
soon
as
as
traceroute
goes
on.
L
J
M
I
M
M
A
O
N
N
So
this
draft
basically
identifies
a
gap
in
the
existing
definition
and
tried
addressing
the
same.
So
the
problem
is
the
problem
statement
here
is
rfc
8287
defines
the
you
know:
the
ls3
prints,
targeted,
fcc
stack
and
the
semantics
for
initiator
and
the
responder
for
to
validate
the
lsp
paths
in
a
segment
routing
network
with
mpls
data
plane.
Now
this
is
an
example
of
one
of
the
the
prefix
set.
N
So
this
information
that
we
carry
currently
with
the
the
targeted
efficiency
stack
is
sufficient
to
validate
a
single
topology
or
the
default
flex
algo
scenarios,
but
when
we,
you
know,
apply
this
in
multi
topology
or
you
know,
scenarios
involving
flex
algo,
the
the
non-default
flex
algo.
This
information
may
not
be
sufficient
to
perform
the
validation
next.
N
Slide
so
we
have
it
explained
with
one
of
the
the
example
topology
that
involves
multiple
flexible
algorithm.
So,
as
you
could
see
in
this
topology
node
nine
is
advertising
prefix
1.1.1.9
by
associating
it
with
three
different
flex
algos.
So,
as
you
might
be
aware,
for
each
I
know,
flex
algo
will
be
having
unique,
perfect
sense.
So
the
prefix
said
16009
is
advertised
for
flex,
algo
0
or
the
default
flex.
Algo
and
16809
is
advertised
for
algo,
128
and
16.
909
is
advertised
for
flex
algo129.
N
N
So
when
the
probe
is
generated
from
node
0
and
when
node
9
receives
the
packet,
it
may
not
have
sufficient
information
because
we
just
included
the
the
prefix
which
is
1.1.1.9
and
the
respective
you
know,
subnet
mask
along
with
the
protocol
that
is
used
to
advertise.
So
now,
node
9
may
not
have
the
the
relevant
information
to
validate
if
it
is,
if
it
needs
to
be
validated
against,
you
know,
flex,
algo,
0
or
128
or
129.
N
N
Slide
so
this
draft
basically
does
two
things:
one
is
to
extend
the
existing
targeted,
fcc
stacks
of
plp
defined
for
ipv4
and
ipv6
prefix
said,
and
the
next
one
is
by
proposing
you
know:
new
targeted,
fcc
stack
for
multi
topology.
So
let's
now,
first
look
into
the
the
extension
of
the
existing
one.
So
the
ipv4
and
ipv6
prefix
segment
id,
which
are
defined
by
rfc
8287,
have
a
field
of
16
bit
which
is
reserved.
N
So
this
draft
split
that
16
bit
reserve
field
into
two
different
fields
and
the
eight
bit
the
first
eight
bit
field
is
used
as
the
algorithm
field.
So
this
is
backward
compatible
because
you
know,
if
it
is
the
default
flex
algo,
then
the
value
will
be
zero,
and
so
all
the
16
bits
will
be
set
to
zero.
So
this
is
backward
compatible
to
the
existing
implementation
and
if
the
validation
needs
to
be
done
for
a
non
default
flex,
algo
the
respective
algo
field
will
be
included
in
this
new
field.
N
So
the
next
one
is
defining
new.
You
know
targeted
fcc
stack
for
multitopology,
so
in
addition
to
the
previous
one,
which
is
prefix
the
length
protocol
and
the
algo,
the
multi-topology
extension
is
included.
So
this
is
a
new
targeted
efficiency
stacks
up,
dlp,
you
know
being
requested
to
the
ina,
so
the
multi-topology
id
is
appended
to
this.
So
you
know
this
will
be
used
to
identify
which
topology
that
we
are
trying
to
validate,
and
this
draft
proposes.
N
N
N
Now
with
the
introduction
of
this
new
fields
like,
for
example,
the
algo
field
in
the
targeted
fcc
stack
when
node
zero
would
like
to
validate
the
the
lsp
path
towards
prefix
1.1.1.9
over
the
algo128,
it
can
include
the
relevant
algorithm
id
in
the
targeted
fcc
stack
that
could
be
used
by
node
9
to
perform
the
validation
against
the
right
control,
plane
entry
and
it
can
send
the
relevant.
You
know
response
to
the
initiator.
N
N
A
N
A
A
A
G
G
G
The
requirement
is
to
renovate
mpls
and
pin
to
support
verification
between
the
control
plane
and
the
data
plan
for
mpos
places.
The
response
in
part
in
this
draft
mpls
based
sfd,
includes
npos
fc
in
ifc8595
and
srsfc
industrial
service
program
product
for
mpls
at
con.
This
job
proposes
that
service
functions
for
waters
are
responsible
to
process.
The
mpis
have
a
request
and
expand
the
usage
of
the
generic
associated
china
label
to
identify
the
sfpom
packet
and
new
sub
tvs
are
introduced
for
the
fvc
of
the
nprs
basic
unit
ytfc.
G
G
Sfc
violation
to
vm
is
its
subjects
defined
in
the
previous
version
I
deleted
and
sfc
basic
unit
near
sub-tree
is
defined
in
this
version.
Its
usage
will
be
described
in
the
following
slides.
We
also
add
a
reason
about
why
nprs
sfc
service
functions
for
worders
are
responsible
for
mpls
as
a
request
process
that
is
in
mpls
sfc.
The
path
forwarding
decision
is
made
by
service
function
for
waters
based
on
the
basic
unit,
so
these
functions
may
not
be
aware
of
that.
G
G
And
these
two
sub
tvs
are
defined
only
for
sfc
and
os
packet,
forwarding
sfc,
and
s
is
based
on
the
basic
unit
for
sfc,
which
is
two
labels,
so
the
sfc
basic
units
of
trv
is
used
to
carry
the
corresponding
fcc
input
of
the
basic
unit.
The
rd
and
sf
type
fields
are
taken
from
its
control
plane
draft
in
sfc
and
prson,
since
one's
basic
unit
is
related
to
only
one
fec,
to
ensure
that
the
proper
validation
can
still
be
performed.
The
sfc
basic
unit
new
sub-tier
v
is
introduced.
G
G
P
G
G
And
here
are
here
gives
two
examples
of
sending
the
mpls
a
request.
The
left
is
an
service
function,
path
based
on
the
swiping
mode.
The
mpls
docker
request
is
sent
with
one
basic
unit
and
one
gl
in
the
package.
The
ttl
of
the
sf
label
is
set
successfully
to
one
two,
three
and
so
on,
and
the
right
side
is
an
sfp
based
on
microsoft.
G
If
the
operator
wants
to
validate
the
fvc
for
sf2,
which
is
connected
to
sff2,
the
gl
is
putting
two
basic
units
into
accurate
class,
because
when
the
packet
leaves
sf
leaves
as
f1
the
first
basic
unit
and
the
gl
in
it
will
destroy
it
in
the
fec
step.
The
basic
unit
nearsighted
vo,
basically
3,
may
be
carried.
It
is
to
in
order
to
ensure
that
the
number
of
labels
in
downstream
tlp
correspond
to
the
number
of
npcs
in
the
fcc
stack
so
as
f2
so
can
enter
the
fec
validation
procedure.
As
an
intermediate
note,.
G
Okay,
this
is
the
packet
assessing
code.
This
is
package
processing
flow
of
the
service
function
for
order
after
receiving
an
echo
request
as
introduced
before.
If
the
sfc
contacts
label
is
followed
by
a
special
purpose
label
gl,
it
is
recognized
as
an
sp
spf
sfv
on
package,
then
the
sff
will
decrease
the
ttl
in
sf
label.
If
the
ttl
after
decrease
is
not
zero,
the
one
package
is
processed
as
introducing
fc8595.
G
G
G
N
Okay,
yeah.
Thank
you
so
yeah.
I
was
looking
into
the
the
theory
of
operation
that
you
defined,
and
I
understand
that
this
draft
is
targeting
both
you
know
the
legacy
and
pls
and
also
the
segment
routing
mpls
for
sfc
I
mean
the
the
sr
based
sfc
is
going
to
be
a
stack
of
segments
that
will
steer
the
traffic.
You
know
be
defining
the
relevant
service
functions.
N
So
I'm
trying
to
understand
how
this
theory
of
operation
is
sufficient
for
sr
sfc
because
it
simply
says
vikram
and
the
ttm
and
sf
label,
which
which
may
not
be
the
case,
and
if
you
were
to
directly
pop-
and
you
know
straight
to
the
next
service
function,
without
any
additional
check
on
the
the
transit
sffs,
then
I'm
worried
that
we
are
not
actually
doing
the
actual
validation.
We
are
it's
more
like
you
know,
forwarding
it
towards
the
next
service
function,
forwarders.
G
I'm
sorry
that
the
network
didn't
work
right,
so
I
I
only
feel
part
of
the
question
because
this
so
first,
if
I,
if
I
don't,
understand
understanding
right,
you
can
correct
me
and
if
the
in
this
trap
we
will
we
will
in
the
next
version
we
are
only
going
to
discuss
about
the
mplsfc
sfc,
defining
ifc8595
and
you
will
leave
the
assignment
lsfc
to
another
job.
So
is
it?
Is
your
question
based
on
this.
N
M
N
M
J
A
Q
G
A
G
Because
we
because
the
service
function
for
weather
will
identify
that
package
oem
package
in
some
ways
we
think
it's
appropriate
to
use
special,
properly
special
purpose
label
to
indicate
that,
among
the
existing
special
purpose,
labels
and
the
jail
is
maybe
a
suitable
choice
to.
I
didn't
identify
the
package
that
this
is
our
own
package.
G
G
A
Okay,
yeah,
just
you
know,
follow
up
on
my
question.
Some
hardware
will
assume
that
when
once
they
see
the
girl,
the
the
next
is
the
gash
and
there
is
specific
bits
that
should
follow
for
the
gash
header
at
least
the
first
nibble.
Fourth
four
bits-
and
I
I
see
here-
you're
assuming
an
sf
label
without
without
any
regard
to
the
first
nibble.
A
C
C
C
C
C
C
C
C
C
C
The
separate
labels
are
used
for
a
h2h
case
and
up
by
hop
case
idea,
is
to
optimize
their
processing
on
every
hop
it's
a
heavy
processing
and
trying
to
avoid
the
the
processing
on
all
the
mid
notes
and
in
case
of
hop
by
hop
case,
the
trace
options
are
processed
on
each
hop
but
as
well
as
the
edge
nodes,
whereas
in
s2h
case
it's
only
processed
on
the
edge
nodes
and
next
slide.
Please.
C
C
C
second
method
is
to
have
a
global
label
which
is
can
be
allocated
by
a
controller,
in
which
case
you
only
have
one
label
in
case
of
number
one.
You
have
two
labels
and
there
is
a
third
case
where
the
label
is
signaled
by
the
decap
node.
This
also
helps
with
making
sure
that
the
cap
node
is
capable
of
processing
the
iom,
because
it
will
advertise
it
will
advertise
the
the
label
and
in
all
three
cases
the
label
is
carried
at
the
bottom
of
the
label.
Stack
next
slide.
C
C
So
this
is
a
comparison
table
for
the
three
methods.
What
is
the
impact,
the
labels
text
size
and
where
does
the
indicator
label
added
on
the
label
stack
so
the
espl?
There
are
two
two
labels
as
mentioned,
whereas
in
method
two
and
three,
it's
only
one
extra
label
and
it
carried
at
the
bottom.
In
all
cases.
C
C
The
cap
node
will
process
will
find
the
indicator
labels,
it
will
process
the
iom
and
it
will
decap
remove
the
iom
data
and
it
may
take
a
copy
of
the
packet,
along
with
the
iom,
data
for
further
processing,
which
could
include
telemetry,
for
example,
and
after
the
cap,
removing
the
iom
label
as
well
as
data
fills.
It
will
forward
the
packet
just
like
any
data
packet.
It
processes
next
slide.
Please.
C
So
in
case
of
srm
pls
there
is
a
label
stack.
This
was
to
answer
a
question:
where
does
the
path
segment
go
in
this
case?
So
path
segment
would
be
added
just
before
the
iom
indicator
label
values
to
write
the
path
segment
can
identify
the
path,
but
it
can
still
be
used
along
with
iom,
headers
and
next
slide.
Please.
C
C
C
C
This
is
a
comparison
of
the
three
methods
pros
and
cons
in
case
of
number
one:
the
special
label.
You
have
two
extra
labels.
The
global
label
would
be
one
and
in
case
of
the
fec
label,
it's
just
the
regular
label,
with
iom
enabled
so
no
extra
label
on
the
stack
in
case
of
number
one
and
two
they
are
at
the
bottom
number
three
is
at
the
top.
C
C
C
C
C
So
once
you
remove
iom
indicator
label
and
the
data
fills
on
the
dcap
node
and
then
you
have
your
sudo
wire
label
and
control
word
in
the
packet,
and
then
you
continue
the
regular
processing
the
labels
stay
where
the
labels
are
today
in
the
mpls
header
and
the
metadata
stay
together
where
the
metadatas
are
there
today.
So
there
is
no
change
in
the
architecture
for
mpls.
This
should
not
break
any
any
network,
assuming
that
iom
is
supported
and
enabled
on
the
node
next
slide.
Please.
C
This
is
an
example
with
another
control
word.
Sorry.
Another
gsch
type
in
this
case
is
the
same
idea.
We
have
also
the
label
or
indicator
label
at
the
bottom.
You
process
iom
and
then
remove
it
from
the
stack
and
what
you
have
is
another
gsch
channel.
These
are
metadata
can
be
seen
like
tlvs,
so
you
know
the
type
you
know
the
land
for
it
and
you
can
just
find
the
next
metadata
and
there
is
one
to
one
mapping
between
the
label
and
the
metadata
anyway.
So
there
is
no
ambiguity.
A
E
You
can
hear
me
yeah
yeah.
I
just
wanted
a
quick
pointer
forward
to
the
draft
I
have
below
regarding
the
special
purpose
labels
being
used
in
this
draft.
Actually,
it
applies
to
a
few
other
drafts
that
have
been
presented
today.
So
I
would
ask
people
to
wait
for
those
slides
and
and
understand
what
the
proposal
is
and
how
that
changes
their
requests
for
special
purpose
labels
thanks.
A
C
So
the
way
it's
the
gal
on
the
d-cap
node
will
punt
the
packet,
and
in
this
case
we
are
forwarding
the
packet.
This
is
carried
by
data
packet,
so
packets
get
forwarded
downstream,
whereas
in
case
of
gal,
which
is
used
for
oem
packets,
they
get
terminated
on
the
node.
So
that's
how
the
gal
is
defined,
but
definitely
if
I
mean
there
is
existing
network
with
that
behavior
we
could
change
update
the
rfc,
but
there
is
an
implication
on
the
existing
network.
A
C
You
need
to
need
to
understand
the
requirement
because
the
iom
is
carried
by
the
data
traffic
and
gal
is
carried
by
the
oem
packets,
so
you
don't
have
at
least
typically
you
don't
have
a
case
where
you
have
both
oem
and
data.
There's
a
different
traffic
right,
so
you
don't
have
that
case.
But
if
there
is
something
some
scenario
we
can
talk
about,
it.
A
C
A
A
L
R
R
Here
are
some
background
about
this
work.
The
term
vtn
was
introduced
in
the
enhanced
living
draft
in
the
t,
smoking
group,
which
is
basically
a
virtual
underlayment
network
with
customized
topology
and
a
set
of
dedicated
or
shared
network
resources
and
obtained,
can
be
used
as
the
underlay
for
one
or
group
vpn
services,
as
shown
in
the
picture.
R
R
R
R
R
R
R
A
A
No,
I
mean,
if
you
know,
there's
something
called
readable
depth
and
and
if
I
cannot
read
beyond
the
readable
depth,
I
cannot
reach
the
vtn
id.
Then
there
are
other
proposals.
G,
where
the
you
know
the
id
that
this
this
slice,
id
or
vtn
id
slice
aggregate
id
we
call
it
is-
is
within
the
label
stack
not
after
the
end
of
labor
stack,
so
yeah,
I
guess
you
know.
Maybe
we
should
think
more
about
the
presence.
Where
do
you
want
to
put
this
this
identifier?
R
Yeah,
I
agree
there
are
several
candidate
positions
to
put
this
information
in
the
packet
and
actually
there
each
has
its
pros
and
cons
such
as.
If
we
use
an
exten
like
a
header
after
the
label
stack,
we
have
more
flexibility
to
define
format
and
the
lens,
and
maybe
it
can
be
also
variable
lens.
This
is
some
benefit
of
this.
Also,
as
you
mentioned,
there's
some
cost.
We
need
to
consider
so
each
one.
We
may
need
some
more
discussion
about
all
these
candidates.
R
H
H
H
R
H
B
R
A
P
P
So
the
idea
here
is
to
consider
existing
fields
that
we
already
carry
within
the
impellers
header
stack.
So
brief
reminder
on
the
entropy
label
principle:
it
uses
two
label
stack.
The
first
one
is
the
entropy
label
indicator
to
mention
there
is
something
special
following
and
then
the
entropy
label
itself
carrying
the
value
to
be
hashed
for
balancing
the
the
traffic
of
all
the
the
network
over
multiple
paths.
P
R
P
P
P
P
Most
significant
bits
on
lowest
significant
bits
of
the
entropy
labels
filled
and
we
split
it
with
two
different
semantics,
but
globally
it
remains
based
on
ingress
allocation
and
we
use
one
of
the
fields
from
the
former
unused
ttl
field
as
a
flag
set
to
mark
that
we
are
making
use
of
the
slide
id
feature.
Next,
please.
P
The
entropy
label
is
just
treated
as
an
opaque
field
on
which
the
harsh
feature
may
be
performed
so
whether
the
most
significant
mixed
carry
a
specific
value
or
not.
It
remains
fully
similar
to
the
initial
definition
of
the
entropy
label
and
in
case
the
flag
associated
to
the
side
is
set.
The
supporting
implementations
over
the
past
along
the
path
will
be
able
to
do
specific
processing
associated
to
the
pair
slicing
behavior
in
case
something
is
ready
to
personalize
processing
along
the
pass.
L
P
P
It
just
enable
a
particular
processing
associated
to
a
new
definition
of
unused
beast
bits.
So
far
it
reduces
the
entropy
level
signaling
capability
on
the
maximum
size
depths
that
we
already
have
progressing
in
parallel
and
it's
enabled
incremental
deployments
over
operational
fields,
because,
thanks
to
the
pacquiao
compatible
advantages,
it
doesn't
break
anything
and
can
be
deployed
in
a
step-by-step
basis.
H
Yes,
sir,
so
I
was
looking
at
rfc
6790,
section,
4.2,
ingress,
lsr
0.4,
the
ttl
for
the
el
must
be
zero
to
ensure
that
it
is
not
used
inadvertently
for
forwarding.
There
was
quite
a
lot
of
discussion
about
this
at
the
time.
So,
whilst
you
have
an
interesting
idea,
we
do
need
to
make
sure
that
we
aren't
derogating
any
security
promises
that
we
made
in
the
past.
P
Yes,
I
see
your
point.
I
think
it's
relevant
to
make
sure
that
it
doesn't
break
anything
so
far.
I
don't
see
it
as
different
from
any
field
that
remain
reserved
for
future
no,
but
if,
if
there
are
some
specific
issues
that
were
identified
at
that
time,
it's
worth
looking
at
them,
you're
right
right.
H
H
P
R
R
L
P
R
P
R
P
R
B
Okay,
hi
jeff,
hey!
So,
if
you're
going
to
use
entropy
label
for
forwarding,
then
you
change
fundamental
symmetric
enterprise
labels
right
it's
optional
for
load
sharing,
because
you
just
increase
entropy.
If
you
don't
read
it,
you
can
steal
for
the
traffic
you
don't
load.
Charge
is
good.
Now,
if
it's
used
for
forwarding
it's
mandatory
to
be
read
so
in
segment
routine,
your
elephant
can
be
inserted
any
depth
right.
B
So
we've
got
two
constraints:
how
deep
you
can
insert
it?
How
many
pairs,
which
is
an
ingress,
node
and
then
url
d,
which
is
some
transit
and
they
become
mandatory
since
they're
used
for
forwarding
as
well
as
on
pc
computation,
you
need
to
impose
label
stack
that
is
readable
across
every
transit
node.
I
would
like
to
see
these
points
addressed
in
the
draft.
A
P
A
B
C
A
H
Let
me
speak
yeah,
so,
first
of
all,
I
agree
with
the
points
that
both
of
sets
of
points
that
were
just
made.
It
seems
to
mean
being
no
point
in
putting
this
thing
in
a
critical
part
of
the
forwarding
layer,
if
you're
not
actually
going
to
use
it
as
part
of
the
forwarding
decision,
and
that
means
that
you
need
to
have
capability
advertisement
and
the
path
needs
to
verify
that
the
path
the
the
all
the
p
notes
got
this
capability.
So
that's.
H
So
we
need
to
understand
what
more
sophisticated
things
slicers
are
going
to
want
before
we
decide
how
to
do
slice
identification
because
otherwise,
we'll
end
up
just
doing
this
thing
twice
and
we'll
have
all
the
corresponding
issues
of
inter-working
between
multiple
techniques.
Trying
to
do
the
same
thing.
P
Yeah,
I
see
your
point
steward
and
it's
true.
It
doesn't
address
all
requirements
associated
to
any
given
slas,
but
for
simple
cases,
this
proposal
has
the
benefit
of
being
easy
to
to
implement
with
respect
to
existing
specified
features.
So
it's
trade-off
between
what
we
need
to
achieve
and
what
will
be
needed
in
implementation.
M
P
A
E
E
E
Yeah,
I'm
here
I've
got
10
minutes,
but
that
means
the
next
person
after
me
doesn't
have
much
time.
If
julian's
presentation
had
a
lot
of
comments,
this
will
have
even
more
so
I'm
not
sure
how
we're
going
to
handle
that.
But
I
think
this
is
a
pretty
important
presentation
and
that's
why,
anyway
I'll
stop
talking
about
time
and
start
talking
about
my
slides
so
next
slide,
please
thank
you.
I
should
mention
that
you
know
there's
a
decent
set
of
people
who
are
on
this,
including
israel
malik
from
broadcom.
E
So
we've
done
a
little
bit
of
a
polling
of
how
different
powering
engines
use
this
and
they'll
come
in
useful.
So
anyway,
the
the
basic
motivation
here
is
there
are
lots
and
lots
of
requests
for
special
purpose
labels,
and
typically
these
special
purpose
labels
ask
the
forwarding
plane
to
do
something,
and
so,
for
example,
there's
the
no
further
fast
readout
which
effectively
says.
E
E
So
the
the
key
insight
is
that
the
critical
thing
that
forwarding
engines
look
at
when
they're
processing
a
given
label.
So
if
you
look
at
the
top
of
stack,
you
have
to
look
at
the
label
field
to
say
what
do
I
do
with
this?
You
have
to
look
at
the
tc
as
part
of
how
you
treat
the
packet.
You
have
to
look
at
the
ttl,
whether
to
drop
it
or
forward
it
and
you're
going
to
change
the
ttl,
and
then
you
of
course,
have
to
look
at
the
end
of
stack
pitch
and
you.
E
The
primary
reason
for
looking
at
the
end
of
stack
bit
is
to
say
what
else
in
the
label
stack.
Am
I
going
to
process
so
we've
been
talking
about
readable
label
depth,
but
in
principle,
if
you
can
you,
you
would
like
to
go
through
the
whole
stack
and
maybe
get
to
the
end
of
stack
and
look
at
things
there
from
the
point
of
view
of
processing
a
an
ip
header
and
getting
a
better
sense
of
how
to
forward
the
packet
how
to
load
balance
the
packet.
E
There
are
powering
engines
that
look
at
the
label
values
and
they
look
for
things
like
spls
special
purpose
labels.
So
they
look
for
you
know
they.
They
feed
them
all
into
their
entropy
engine,
if
they're
so
inclined
and
and
so
on
so
you're,
looking
at
the
end
of
stack
bits,
you're
looking
at
the
20
bits
of
label
value,
but
the
tc
bits
and
the
ttl
bits
are
not
acted
upon
so
so
then
the
I
mean
given
that
insight.
E
E
E
So,
defining
a
new
special
purpose
label,
or
even
an
extended
special
purpose
label
for
every
new
feature,
is
not
a
great
idea.
I
mean
first
of
all,
we're
running
out
of
special
regular
special
purpose
labels,
and
this
whole
approach
is
expensive,
typically
means
that
you
have
to
do
a
hardware
respin
or
a
microcode
change.
E
I
know
that
there's
going
to
be
all
kinds
of
people
lined
up,
I'm
surprised
it's
just
to
it
for
now,
but
if
we
do
find
a
way
to
make
this
work,
that
means
that
every
code
point
for
a
special
purpose
label
can
actually
do
lots
of
things.
And
if
that
code
point
can
do
lots
of
things,
we
should
in
fact,
maybe
think
about.
If
we
define
new
special
purpose
labels,
how
can
we
do?
How
can
we
make
them?
E
Do
multiple
things
and
also
maybe
go
back
to
all
special
purpose
levels
and
say:
how
do
we
make
them
more
more
effective
so
that,
yes,
we
have
only
15
of
them
that
we
can
use,
but
the
16th
one
being
the
el
extension
label
so
leave
that
aside,
but
can
we
get
a
lot
more
efficient
with
them
and
actually,
even
with
those
15,
do
lots
lots
more
things?
The
the
trigger
for
this
was
the
global
identifier
was
flight
selector,
the
the
guess
field,
and
this
enables
mpls
based
transport
network
slices.
E
Please
so
here's
a
theory
of
operation.
You
have
an
existing
forwarding
label
that
you're
looking
at
so
you
have.
You
know
it's
got
a
tc
bit.
It's
got
this
end
of
stack
bit
with
hopefully
zero,
because
there's
more
coming
up
and
some
ttl
fields,
but
below
that
you
have
this
multipurpose
special
purpose
label
and
the
bits
that
I
have
here
are
slightly
different
from
the
bits
that
I
have
later
in
the
slide,
which
I
was
going
to
present
to
to
pals.
E
But
the
idea
is
that
you
have
a
bit
that
says
there
is
something
beyond
the
end
of
stack
and
maybe
there's
a
bit
that
says
there
is
something
beyond
the
end
of
stack,
but
you
don't
need
to
worry
about
it
now.
This
is
only
for
the
end
to
end
thing
and
there's
a
bit
that
says
there's
something
beyond
the
end
of
stack,
but
it
might
be
interesting
to
you
on
a
hop
by
hop
basis.
E
A
P
A
E
Thanks
interesting
that
I'm
the
one
that
gets
my
time
check
and
everyone
else
gets
whatever,
but
fine
because
you
complained
exactly
yeah
right.
That's
that's
what
happens
so.
The
the
idea,
then,
is
to
encode
in
the
action
bits
that
you
see
here
the
different
types
of
special
purpose
labels
and
based
on
those
action
bits
they
may
be
associated
with
data.
So
if
the
action
bait
is
no
further
faster
out,
there
isn't
any
associated
data.
E
But
if
that
action
bit
says
I'm
an
entrepreneur,
I
carry
entropy,
then
the
associated
data
would
be
entropy.
The
other
thing
that's
important
to
realize
is
that
associated
data
could
be
all
31
bits
again
subject
to
this
whole
question
of
being
able
to
reuse
the
tc
and
ttl
fields.
So
if
you,
if
you
think
about
using
a
single
word
for
both
entropy
label,
I
don't
know
if
everyone's
seeing
this,
but
I'm
seeing
something
funky.
E
So
if
you
see
entropy
label
and
slice
id
instead
of
trying
to
squeeze
everything
into
20
bits,
you
actually
have
31
bits
and
I
think
that
entropy
of
less
than
16
bits,
I
think,
is
pretty
much
useless
and
a
slice
idea
of
less
than
10
bits.
I
I
I
think
10
bits
is
already
too
small.
So
the
idea
that
you
have
15
bits
of
slice
and
16
bits
of
entropy,
I
think,
is
reasonable,
but
if
that's
not
enough,
we
have
an
option
where
you
can
do
more.
E
The
the
high
order.
Bit
of
all
this
is.
I
think
this
is
something
that
the
mpls
working
group
has
to
look
at
and
say:
does
this
really
work
and
can
we
actually
reuse
the
tc
and
ttl
bits
if
you're
not
at
the
top
of
stack?
And
if
you
can?
That
really
opens
up
two
two
ideas:
one
is
that
a
special
purpose
label
can
have
multiple
purposes,
and
so
now
each
code
point
can
actually
be
much
more
effective
and
the
second
is
any
associated.
Data
can
have
a
lot
more
interesting
data.
E
A
A
A
H
Right
so,
first
off,
I'm
a
bit
worried
that
we're
you
tending
to
put
things
in
the
special
purpose
labels
set
when
we're,
we
should
be
putting
them
actually
in
the
fact.
So,
for
example,
you
get
you
quoted
the
case
of
do
not
fast
reroute.
The
obvious
way
of
dealing
with
that
would
be
to
send
the
original
packet
on
effect
that
had
the
property
that
it
was
not
to
be
fast
re-routed,
and
that
would
be
consistent
with
the
existing
mpls
architecture
and
not
need
an
extension.
H
Second,
you
said
that
these
special
purpose
labels
mustn't
be
at
the
top
of
stack.
There
are
some
that
do
go
at
the
top
stack
at
the
moment.
Gal
is
a
good
example
in
a
php
lsp,
so
we
do
need
to
be
careful
about
backwards
compatibility,
although
perhaps
you
meant
the
new
ones
must
not
be
at
the
top
of
stack
and
thirdly,
about
using
putting
other
bits
and
data
in
the
stack.
H
The
itu
wanted
to
do
this
some
years
ago,
and
we
gave
the
quite
a
sort
of
sharp
reprimand
for
suggesting
this
part
of
the
basis,
for
that
was
that
there
was
hardware
in
that
was
deployed
at
the
time
that
would
actually
fall
over
if
you
tried
to
do
it,
but
we
do
need
to
be
consistent
with
ourselves
or
at
least
be
prepared
to
justify
why
we
have
changed
our
minds,
given
the
rather
difficult
conversations
we
had
on
this
very
topic,
not
that
many
years
ago.
Thank
you.
E
E
We've
changed
a
lot
of
things
in
the
forwarding
path,
so
this
idea
that
we
have
deep
stacks
the
idea
that
we
actually
look
well
beyond
the
stack.
I
mean
well
beyond
the
top
label
and
in
fact,
even
hunt
for
the
end
of
stack
and
do
stuff
with
it
was
something
that
was
very
difficult
to
do,
and
sometimes
you
know
we.
We
didn't
want
to
force
that
decision,
but
we've
already
gone
down
that
path.
E
Yes
to
your
question
about
the
the
the
my
suggestion
was
not
that
the
special
purpose
levels
never
appear
on
top
of
stack,
but
the
special
purpose
labels
that
do
twiddle
with
the
tc
and
ttl
bits
should
not
appear
on
the
top
of
stand.
So,
for
example,
in
many
cases
you
do
if
you
do
php,
but
the
ultimate
hop
wants
to
see
a
label.
You
push
level
zero
on
that.
So
you're
you,
I
mean
that's
the
case
where
a
special
purpose
level
is
on
top
of
stack.
E
So
there
is
a
slide
which
we
haven't
gotten
to
which
talks
about
next
steps.
That
basically
says
people
who
have
forwarding
engines
yeah.
Thank
you.
You
were
just
there.
Oh
sorry
about
this
one
back.
No,
it
says
on
top
next
steps,
so
yeah
here
proposed
next
step.
So
the
last
slide
last
bullet
basically
says
asic
vendors.
Please
look
at
this
proposal
and
send
the
author's
feedback.
E
E
Definitely
that
has
to
be
done
and,
to
some
extent
you
know,
being
backward
compatible
is
important
and
you
know
there
are
things
in
the
field
that
will
remain
in
the
field
for
a
long
time
and
the
question
is:
can
we
not
do
damage
with
with
them?
But
at
the
same
time
you
know
the
position
that
we're
in
where
we've
already
overflowed
the
number
of
base
special
purpose
labels
and
the
fact
that
we're
using
these
special
purpose
labels-
you
know
in
this
very
single
purpose
way
is,
is
not
the
ideal
way
of
going
forward.
E
Q
O
O
E
E
The
reason
for
two
bits
is
from
the
iom
proposal,
so
you
can
have
a
bit
saying:
there's
data
beyond
the
end
of
stack,
but
you
don't
need
to
see
it
until
you're
there
egress
and
there's
another
that
says:
there's
data
be
on
the
inner
stack
and
you
might
be
interested
in
seeing
it
even
if
you're
a
hop.
I
hop,
you
know
a
transit
router,
but
we're
basically
assuming
that
what
comes
beyond
the
end
of
stack
is
self
identifying.
E
So
it's
in
a
tlb
format,
and-
and
you
know
how
much
there
is
so
we
don't
have
to
do
a
lot
of
stuff
there.
The
other
part
of
this,
the
bits
that
we
didn't
get
to
on
the
action
bits
essentially
say
that
the
labels
below
the
fai
label
are
actually
not
labels,
but
powering
action
data
and
so
you're
encoding
within
the
label
stack
stuff.
That
might
be
interesting.
For
example,
if
you
look
at
the
eli,
the
eli
basically
said
the
next
level
is
an
entropy
label.
It.
E
It
only
had
20
bits
of
use,
but
I
mean
that
same
idea
is
being
extended
here
and
so
the
action
bits
would
say:
I've
got.
You
know,
31
bits
in
the
next
word
and
31
bits
in
the
word
after
that,
and
so
I
could
have
the
31
bit:
entropy
header
and
entropy
level
and
the
31
bit
yes
class
indicator
and
so
on.
So
so
the
idea
of
the
action
bits
is
within
the
label:
stack,
here's
what's
going
on
and
then
there's
just
this
extra
bit
or
two
bits.
E
A
A
Yeah,
okay,
I
I
I
don't
think
we
can
take
more
questions
jeffrey.
Do
you
think
you
can?
Thank
you
kiriti
thanks
a
lot.
I
think
we
can
follow
up
on
this
on
the
list
as
well
jeffrey.
Do
you
think
you
can
you
can
wrap
up
in
10
minutes,
or
I
mean
you
can
you
can
present
in
10
minutes?
Is
that
something
doable
on
your
side.
S
Go
ahead
yeah,
I
just
I
just
do
30
seconds,
so
this
is
an
update
to
a
presentation.
I
did
last
time,
but
this
time
we
wanted
to
have
more
nprs
specific
discussions
in
the
mqs
group.
We
didn't
have
time
to
do
that,
but
there
is
a
presentation
on
the
same
topic
in
the
joint
session
with
with
pow
on
friday.
S
I
would
encourage
people
to
attend
to
that
session
because,
while
generic
live
function
is
intended
to
be
applicable
to
any
layer,
including
mpos,
there
are
many
mqs
religious
aspects
that
we
want
to
have
a
discussion
within
mqs
group.
Listening
to
today's
presentations.
I
realized
that
this
new
idea
of
vtn,
if
we
are
going
through
forward
with
that
proposal,
that
we
may
also
consider
doing
that
in
the
context
of
a
generic
delivery
function,
so
that
it
is
not
only
used
for
mpos
but
also
used
for
other
forwarding
plane
as
well.