►
From YouTube: MPLS WG Interim Meeting, 2021-05-12
Description
MPLS WG Interim Meeting, 2021-05-12
A
Okay,
do
you
see
my
screen.
B
A
Yeah,
okay,
great
so
as
I
mentioned,
so
this
is
the
proposal
to
support
oem
functionality
in
sfc,
mtls
environment.
Where
so,
let
me
switch
here
so
so.
Sfc
basic
unit
introduced
in
rfc
8595
and
it
emulates
or
simulates
our
nsh.
A
Network
service
header,
so
that
it
includes
their
sff
label
and
sf
label.
It
works
interpretation
is
some
and
works
somewhat
differently,
whether
it's
a
label
swapping
or
label
stacking.
A
But
their
major
issue
that
we
came
across
was
that,
as
in
sfc
nsh,
there
is
no
assurance.
There
is
no
guarantee
or
requirement
that
sf
or
sf
proxy
system
supports
sfp
oem.
A
So
for
that
reason,
in
proposals
that
are
in
sfc
working
group
for
active
sfp
oem,
then
sff
does
not
pass
oem
payload
to
sf
or
set
proxy
and
for
the
case
of
nsh
encapsulation
in
the
data
plane,
the
oem
sfp
om
identified
by
the
protocol
type.
A
So
we
looked
at
mpls
and.
A
The
gal
was
introduced
as
their
indication
of
ach
following
their
mtls
label
stack
and
in
ach
there
are
active,
oem
packets
can
be
encapsulated,
so
that
was
our
proposal
that
signaled
to
sff
by
inserting
the
gal
label
into
their
basic
unit.
A
So
here
their
depiction
of
how
this
basic
unit
or
oem
payload
will
look
like.
A
And
it
will
be
in
a
swapping
mode
or
stacking
mode,
but
when
the
stacking
mode
or
mixed
mode,
because
that
another
valid
scenario
will
have
multiple
units
encapsulating
oem
packet
and
that
results
in
a
gal
label
being
a
repeat
repeat
it
multiple
times.
A
So
that's
effectively
how
we
arrive
to
the
question
of
multiple
gal
labels
in
the
mpls
label,
step.
C
So
could
you
help
so
so
you
want
to
gal
near
the
top,
presumably
because
you
want
to
know
whether
it's
worth
the
expensive,
the
expense
in
the
forwarder
of
going
to
the
bottom
of
stack.
Is
that
correct.
A
Yes,
otherwise,
you
could
just
go
look
well
right,
so
one
of
possible
alternatives
that
we
discussed
is
that
say
that
there
will
be
only
one
gal
label
at
the
bottom
and
then,
regardless
of
depth
of
their
label
stack
each
sf
for
each
packet
will
have
to
find
their
bottom
of
the
stack
label
to
verify
whether
it's
gow.
C
Enough
right-
and
there
has
to
be
one
at
the
bottom
of
stack
anyway-
well
that
that
was
another
at
least
it
has
to
be.
It
has
to
be
at
the
bottom
of
the
stack,
or
you
have
to
remember
that
you're
getting
rid
of
the
last.
I
forget
what
we
call
those
service
units,
but
the
last
cluster
of
three
labels.
C
There
are
two
labels,
the
basic
unit.
So
yes,
yes,
so
you
have
a
modified
basic
you're.
Just
just
checking.
I
understand
this.
You
have
a
modified
basic
unit
and
at
the
bottom
of
stack,
is
either
your
modified
basic
unit
or
a
gal
on
its
own.
I
think
that
has
to
be
the
case.
Doesn't
it
otherwise?
You
couldn't
possibly
know
how
to
parse.
What
follows
the
bottom
of
stack.
A
Well,
what
follows
again,
what
we're
saying
is
that-
and
I
think
that
that's
another
update
to
5586
is
that
if
the
gal
label
is
present
in
the
stack,
then
the
bottom
of
the
stack
must
be
followed
by
ach
right.
That's
what
it
says
at
the
moment.
I
think
doesn't
it
it
says.
D
C
But
you
you
better,
find
a
gal
if
you're
popping
all
this
stuff
off
the
top
there
better
be
a
gal
somewhere
to
tell
you
to
go.
Look
at
the
oam
or
let's
get
rid
of
the
right
and
that's
that's.
A
B
Quite
a
question
correct
the
the
metadata
that
that
you
carry
after
the
start,
the
end
of
the
stack
it
needs
to
be
preserved
all
the
way
until
the
last
sff.
A
A
Then
the
packet
disappears,
so
basically
we
are
not
looking
into
their
communicating
oem
information
with
their
data
packet.
So
it's
a
only
four
active
oem
case
where
the
packet
is
actually
oem
test
packet.
B
Okay
and
that
you
know
that
relates
to
what
stewart
was
saying,
put
it
at
the
bottom
of
the
stack,
if
you
put
it
at
the
bottom
of
the
stack,
then
only
the
last
sff
will
process
it
right.
Yes,
but
the
the
key
is
that.
C
A
Sfc
the
nature
of
sfc
that
we
have
a
sequence
or
chain
of
service
functions
that
are
mapped
and
connected
to
service
function,
forwarders.
So
the
service
function
is
an
adapting
function
to
the
service
itself.
So
an
idea
is
that
service
function
forwarders.
A
They
know
local
service
functions
that
are
connected
to
them
and
are
they
aware
of
the
topology
of
service
functions,
tab
sfp?
It
might
can
be
a
world
balanced.
So
then
there
is
a
difference
between
service
function,
tab
and
the
render
service
path,
which
is
a
physical
topology
in
the
network.
A
But
the
thing
is
that
each
sfp
receives
their
packet
and
then
passes
it
to
service
function,
because
that's
why
the
packet
has
arrived
with
the
label
or
information
that
as
sff
understand
so.
C
The
the
problem
is,
of
course,
is
that
you're
going
to
multiply
the
you're,
basically
going
to
multiply
the
size
of
the
stack
by
50
percent.
E
C
A
But
the
thing
is
that
their
other
benefit
is
that
we
do
not
then
require
each
and
every
node
to
look
on
to
the
bottom
of
the
stack,
because
that's
the
most
deterministic
place
where
we
can
put
the
gal
to
indicate
that
payload
is.
C
C
A
A
C
A
better
look
at
the
no
there's
a
gal
there,
because
it's
got
to
know
how
to
interpret
the
payload
and
you
can't
interpret
the
payload
without
knowing
that
there's
a
whole
load
of
ach
before
you
get
to
the
payload.
A
Well
in
our
proposal:
yes,
every
sf!
That's
and
that's
that's
why
we,
we
came
with
their
proposal
to
insert
gal
into
the
basic
unit
yeah
because
again
so
effectively
the
basic
unit
introduced
as
a
emulation
of
nsh
so
because
we
don't
have
payload
protocol
type,
which
is
a
part
of
an
nsh
format.
So
we
need
to
some
way
of
the
mechanism
that
emulates
nsh
functionality
to
indicate
that
the
payload
is
oreo.
C
Right
well,
so
this
is
an
on-the-fly
suggestion,
given
in
many
ways.
This
is
really
unfortunate,
as
I
don't
know
what
your
delivery
times
are,
but
you
know
we're
in
the
middle
of
this
big
discussion
in
in
mpls
about
how
we,
how
we
do
things,
how
we
do
some
of
these
new
things.
In
the
stack
I
mean,
one
of
your
options
is
actually
to
sequester
the
ttl
of
a
sfl
to
be
a
protocol
type.
C
Not
what
I
would
like
to
use
that
for
people
are
very
well
aware
of
my
preference,
but
nonetheless,
we've
crossed
a
rubicon
that
would
suggest
that
you
could
make
have
a
label
in
the
middle
of
your
triplet.
That
was
the
protocol
type.
If
that
was
the
right
thing
to
do
well,
we
are
crossing
that
rubicon.
I
don't
know
quite
whether
we've
got
there
yet,
but
we're
awfully
close
to
it.
So
one.
E
E
Yes,
a
single
octave.
C
C
But
the
real,
I
think
the
rubicon
we're
crossing
here
is
to
to
to
change
the
way
we
interpret
mpls
label
bit
in
the
special
case,
where
we
know
that
we're
to
do
it
like
that.
C
Yeah,
no,
no,
I
think
we're
on
the
same
page
I
mean
I'm
just
making
sure
that
the
working
group,
my
concern,
is
that
the
working
group
crosses
this
makes
this
big
big
change
to
mpls,
knowing
what
the
consequences
are
yeah
as
a
collective.
All
I'm
saying
is,
I
don't
think
it's
really
a
change
in
what
the
label
means.
C
Well,
I
suppose
no,
I
suppose
I
mean
I
suppose
you
you
could
of
course
have
every
one
of
those
entries
in
some
label
table
and
look
it
up.
No
one
in
their
right
mind
would
want
to
do
it
but
you're
quite
right.
You
could
just
look
this
whole
thing
up
as
a
20-bit
thing
and
get
the
answer.
So
yes,
that's
not
how
anyone
would
do
it.
Of
course,
I
hope
conceptually.
C
B
So
the
idea
of
you
know
a
context:
can
you
a
previous
label,
can
give
you
a
context
for
the
next
label.
B
32-Bits
the
way
you
like
right.
B
E
B
Yeah,
I
was
going
to
say
that
that's
similar
to
the
idea
that
kiriti
was
presenting
the
other
day
where
he
embeds
certain
certain
things
inside
the
label
right
yeah,.
C
But
I
think
johnny's
right
that
actually,
this
would
not
be
a
fundamental
change
to
the
to
the
existing
design
for
how
you
do
sfc
and
mpls,
because
you
just
have
some
more
bits
to
interpret
in
that
in
that
second
label
field.
C
Now
there
is
a
bigger
question
which
is:
do
you
want
to
do
this
as
a
singleton
solution
for
this
problem?
Or
do
you
want
to
wait
and
see
how
the
mpls
discussions
going
on
at
the
moment
play
out
and
do
something
in
sympathy
with
what
their
output
is.
A
Yes,
I
think
that
it
definitely
would
be
better
to
have
a
more
general
solution
rather
than
one
use
case.
C
A
Yeah,
what
what
I
need
to
just
double
check,
because
I
don't
remember
by
hard
what
fields
and
how
processed
in
a
different
scenarios
in
sfc
and
pls,
because
the
process,
interpretation
and
processing
of
a
basic
unit
is
somewhat
different.
In.
A
Basic
unit,
though
it's
still
a
basic
unit,
the
thing
is
that
in
the
swapping
mode,
the
basic
unit
remains
unchanged.
A
No,
there
is
a
modification
that
the
ttl
is
being
processed,
but
their
basic
unit
itself
is
effectively
states
in
the
label
stack
whereas
in
in
the
stacking
mode.
Obviously,
once
the
sff
receives
and
passes
payload
to
the
service
function,
then
the
basic
unit
is
bought.
C
A
Right
but
again
in
so
what?
What
I
need
to
verify
is
that
how
it
will
work,
because
it
seemed,
will
work
in.
A
Swapping
mode
for
stacking
mode,
I'll
need
to
look
at
whether
what's
how
much
of
space
we
have
to
indicate
that
the
payload
is
active
and
what
it
ends
up
so
where
we
can
do
that
because
we
don't
want
to
modify
again.
One
of
the
options
would
be
is
that
then
there
will
be
a
multiplicity
of
oem
special
labels
advertised
by
each
service
function.
Forwarder.
C
No,
no,
I
think
that
so
what
you're
worried
about
is
that
we
have
to
specially
lay.
We
have
to
actually
advertise
every
combination
of
the
sfi
and
the
the
oam
indicator,
whereas.
C
E
A
C
It
was
some
years
ago
yeah,
so,
but
the
the
you
know
you
are
not
gonna
advertise
individually
as
a
label
to
your
favorite
label,
advertising
protocol,
all
the
combinations
of
sfi
and
all
the
combinations
of
a
protocol
type.
What
you
would
do
is
you
would
know
a
priori
because
through
the
iona
registry
or
something
what
the
set
of
protocol
types
were-
and
you
would
you
would
you
would
do
your
processing
on
that
basis,
so
you'd
probably
mask
that
off
and
then
go
and
look
up
the
sfi.
C
If
you
were
doing
it
that
what
you're
doing
it
in
a
classic
label
look
up
for
the
sfi
and
then
you'd
go
and
process
the
the
other
factor
on
your
own.
I.
C
Hopefully
you
know
that
protocol
zero
is.
There
is
nothing
that
you're
going
to
declare
and
if
protocol
is
other
than
zero,
then
you
know
to
mask
it
off.
Look:
do
you
look
up
your
ffi
as
you
would
normally
do
it
and
then
do
whatever
you're
going
to
do
with
your
protocol
type?
C
So
I
don't
think
it's
a
major
issue
with
with
the
forwarder.
A
C
So
the
the
the
case
where
it
would
be
horrible
is,
if
you
were
doing
dual
lookup
in
parallel,
which
some
forwarders
could
do,
but
I
don't
think
that
really
works
with
the
sf
sfi
system.
A
Yeah,
okay,
so
I
will
definitely
follow
on
your
suggestions
to
it.
I
appreciate
it
and
well,
it
was
john's
suggestion.
Actually,
okay,
your
john
and
yours,
to
find
w
which
field
in
a
basic
unit
can
be
used
as
a
payload
protocol
type
indicator.
C
A
D
A
Well,
I
think
that
again,
what
will
the
question
would
be
is
because
whether
we
want
to
interpret
this
protocol
type
saying
that
oh,
it
follows
immediately,
follows
their
label
stack
or
still
say
that
the
ach
immediately
follows
the
label
stack,
but
we
can
discuss
it
greg.
Yes,
I
would.
E
Also
check
the
bgp
sfc
draft.
A
Okay,
well
then,
it
was
very
useful,
at
least
in
my
point
discussion.
So
we
have
an
alternative
solution
to
the
original
problem.
That
seemed
to
provide
a
good
technical
alternative,
and
then
there
will
be
no
requirement
to
update
5586
and
have
multiple
one
question
yeah
anyway.
A
Yeah
one
question
to
the
mpls
group
will
still
be
because,
as
we
in
our
discussion
are
identified,
I
believe
that
5586
allows
gal
label
to
be
anywhere
for
non-mpl
stp
environment
anywhere
on
the
stack,
but
the
processing
of
such
gulf
label,
not
at
the
bottom
of
the
stack,
is
under
defined.
A
So
it
seems
that
5586
allows
gal
label
to
be
not
at
the
bottom
of
the
stack
for
non-mpl
stp,
environment.
C
A
Yeah
but
such
use
cases
under
defined
in
55
86.
So
there
is
no
definition
of
what
happens
when
the
gal
label
is
found
not
at
the
bottom
of
the
stack.
C
All
right,
so
we
should
write
an
update
that
corrects
that
so
that,
whatever,
if
you
go
the
gal
route,
we
should
write
an
update
that
specifically
says
what
the
semantics
are,
so
that
you're
not
operating
in
any
any
ambiguous
sort
of
landscape
as
it
were,
and
no
one
can
claim
that
you're,
not
obeying
the
architecture
and
stuff.
So
we
should
do
that.
But
the
first
thing
to
do
is
to
decide
whether
you
want
to
use
the
gal
or
whether
you
want
to
use
another
approach.
C
D
Okay,
so,
as
I
understand
we'll
we'll
see
john
john
you're
in
there
somewhere.
E
C
But
we
can't
get
rid
of
it,
because
even
if
it's
not
been
implemented,
itu
land
relies
on
it
and
they
may
or
may
not
have
done
it.
So
I
don't
think
it
matters
whether
whether
anyone's
done
it
or
not
the
politics
of
unraveling,
that
after
all
this
time,
would
be
something
that
none
of
us
want
to
live
through.
C
F
C
C
F
F
C
To
do
that,
that's
what
I'm
saying
right,
but
I
think
we
should.
We
should
let
greg
decide
how
he
wants
to
do
his
design
first
and
then
bring
a
proposal
to
the
working
group
and
if
it
because
it's
in
this
context,
then
send
it
across
to
sfc
for
comment.
A
Yes,
yes
again,
so
I
I
had
to
miss
because
I
had
a
conflict
last
open,
dt
meeting,
so
I'll
go
back
review
and
listen
more
to
curate
the
presentation
and,
as
I
understand
we
don't
have
a
meeting
this
week.
So
that
will
give
me
some
more
time
to
prepare
my
being
for
the
next
week
meeting.
C
C
If
it's
easier
to
follow,
I
mean
there,
there
were
two.
There
are
two
things
about
the
kariti
thing
that
just
the
the
his
attempted
presentation,
which
got
interrupted
by
lots
of
people
and
shamefully
me
included.
C
It
was
an
attempt
at
explaining
what
he
explained
at
the
last
ietf,
so
you
might
do
better
to
start
with
that
and
get
the
full
context
and
then
go
and
listen
to
that
section
of
the
joint
at
the
last
week's
meeting,
because
it
was
broken
up
with
a
lot
of
us
sort
of
doing
our
usual
engineering
thing
of
teasing
the
thing
apart.
A
B
Great,
I
guess
we
have
a
counter
proposal
and
you
have
to
follow
up
greg.
A
We
know
again
from
my
side,
I
I
greatly
appreciate
the
discussion
and
suggestions
and
it
looks
like
viable
alternative
and
definitely
less
intrusive
to
the
existing
architecture,
and
if
it
can
be
really
if
this
problem
can
be
solved
by
more
our
general
solution,
which
is
in
line
with
the
idea
proposed
by
kiriti,
it
will
be
just
awesome.
B
Okay,
great
I'll
go
ahead
and
stop
the
recording
if
yeah.