►
From YouTube: IETF-MPLS-20230706-1400
Description
MPLS meeting session at IETF
2023/07/06 1400
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
D
C
C
F
E
All
right
welcome
everybody
to
this
mpls
interim
session.
This
is
part
of
a
series
of
sessions
that
we've
set
up
for
the
discussion
on
mpls
network
actions.
This
work
is
a
collaboration
between
three
working
groups,
mpls
piles
and
net,
and
thanks
to
all
who
participation
from
the
different
working
groups.
E
E
And
we
come
to
the
agenda
today,
it's
very
rather
short
agenda,
it's
time
to
bash
it.
If
you
have
any
concerns
or
you
want
to
add
or
update
any
item,
we'll
go
through
the
actions
and
today
Greg
is
going
to
present
something
about
the
m,
a
from
a
death
net
perspective,
and
we
leave
the
last
element.
The
item
here
for
any
other
business.
E
E
F
E
All
right,
I'm,
not
sure
if
I'm
audible
at
this
time
am
I.
Okay,
you
can
hear
me.
Okay,
I
would
like
to
pause
a
little
bit
and
on
this
action
item
and
make
sure
that
somehow
we're
tracking
it
do
you
think.
Okay,
maybe
an
email
to
the
working
group
May
refresh
this
or
there
were
a
couple
of
discussions
that
happened
on
this
and
some
conclusions
were
drawn.
E
E
A
D
A
D
So
these
are
separate
entities,
but
some
of
them
can
be
collocated.
Usually
it's
a
duplicate,
elimination
and
Order
preservation
functions.
So
if
you
can
imagine
that
effectively
what
it
looks
like
in
a
dead
net
service
sub
layer
is
as
a
multi-segment
pseudo
wire
because
at
their
stitching
PE,
that's
where
at
these
you
have
a
packet
replication
and
then
the
stitching
fee
will
have
a
point
where
packet
by
packet
arbitration
is
done.
D
D
C
C
G
B
So
I'm,
just
wanting
to
lower
really
I
mean
it
seems
to
me
that
it's
obvious
that
if
you've
got
a
PE
that
knows
about
debt
net
and
you
want
to
teach
it
about
PSD,
it
needs
new
code
and
it
needs
to
be
taught
about
it
and
that
is
kind
of
a
given
and
then
it.
It
is
up
to
us
the
design
to
decide
whether
the
PSD
comes
before
or
after,
and
how
the
indication
how
the
indicators
work
I
mean.
This
is
all
you
know.
D
D
D
B
I
think
there's
some
people
who
perhaps
don't
understand
what
the
detnet
model
is,
and
you
might
explain,
you're
starting
to
explain
it
when
you
likened
it
to
a
an
spe
system,
a
pseudo
wire
multi-second
system.
It's
not
quite
like
that,
but
I
think
it
might
be
helpful
if
everyone,
if
you
spent
a
minute
or
two
explaining
what
the
model
is.
D
Yeah,
it's
the
closest
thread,
it's
the
closest
it.
It
is
not
that
because
and
that
that's
what
I
was
trying
to
compare
with
so
because
if
we
have
one
plus
one
protection
in
the
pseudo
wire,
then
the
source
of
their
attack,
the
source
been
chosen
per
channel.
So
we
have
working
and
backup,
even
though
it's
active
backup,
but
in
a.
D
Service
sub
layer,
it's
done
on
a
per
packet
basis
using
the
sequence
number
information
that
is
a
part
of
that
net
control
world
and,
as
you
can
see
now,
we
are
in
the
next
slide.
It's
also
present
in
detnet,
Associated,
Channel
header
so
and
then
death,
net,
SP
or
debtnet
node
in
a
definite
service,
sub
layer
acts
on
a
sequence,
number
information
to
do
packet
replication
depending
on
what
function
is
present,
so
it's
either
replicating
packets
or
doing
duplicate,
elimination
and
Order
preservation.
D
D
I
I'm
about
to
so
again
for
the
deadline
purpose
for
purposes
of
that
net.
We
used
the
Prototype
of
pseudoir,
Associated,
Channel
header
and
extended
it.
So
we
have
a
detnet
Associated,
Channel
header
that
includes
the
channel
type,
so
that
ACH
types
defined
for
pseudo
wire
can
be
used
in
the
death
net
OEM
as
well
as
we
need
to
have
a
sequence
number.
So
this
space
is
lesser
and
in
addition,
it
has
some
additional
information
that
identifies
the
source
of
OEM
packet
and
levels.
D
E
D
A
D
C
D
F
I
A
D
D
D
D
My
previous
understanding-
oh
no,
please!
Yes,
no
you're
right!
So
what
what
encapsulation
of
OEM
portion?
Yes,
you're,
absolutely
right,
it's
determined
by
the
channel
type,
the
value
in
the
channel
type
field.
What
I
was
talking
about
is
how
the
system
can
differentiate
between
a
pseudo
wire
ACH
and
that's
not
ACH,
but
in
if.
F
D
D
No
idea
is
the
node
node.
Id
is
not
part
of
the
channel
type
information,
but
it's
a
part
of
that
net.
Ach
encoding.
So
again,
as
we
already
established
the
system
that
processes
the
processes.
This
packet
is
aware
that
particular
label
represents
that
net
service
label
and
because
it's
a
definite
service
label,
then
based
on
the
first
nibble.
It
understands
that
this
is
that
net
ACH
encapsulation.
E
D
B
D
D
Yeah
I
would
say
it
probably
would
be
strange
if
somebody
wants
to
do
both
on
on
the
same
packet,
because
again,
if
looking
at
the
model
of
multi-segment
pseudo
wire,
so
the
transport
will
be
between
SPS
and
other,
that
net
service
sub-layer
will
be
end
to
end
through
SPS.
So
I
would
think
that
their
forwarding
that
net
forwarding,
sub-layer
OEM
will
be
using
regular
ACH
wow.
D
D
D
Aggregated
flow,
so
it's
I,
don't
know
it's
probably
a
little
bit
upside
down.
But
if
you
look
at
the
bottom,
so
we
have
physical
encapsulation
data
link
encapsulation,
that
four
rig
labels
aggregation
label,
followed
by
that
net
control
word,
as
was
presented
earlier
in
the
slides
and
then
again
forwarded
by
folding
label,
and
then
it
service
sub-layer
label
and
again
that
can
control
word
and
then
on
the
payload.
D
A
D
F
D
D
And
then
the
next,
the
last
question
that
I
posted
here
is
so
where
the
PSD
can
be
located
relative
to
debtnet
control
word
and
that
net
Associated,
Channel,
header
and
I
have
the
next
slide,
which
is
illustrates
two
options.
That
I
was
thinking.
It's
not
that
is
solution
or
possible
solution.
It's
just
to
illustrate
what
I
was
thinking,
so
the
one
is
death
net
control
word
immediately
follows
bottom
of
the.
A
D
Our
bottom
of
the
stack
and
that
kind
of
control
world,
because
What
I'm
thinking,
is
that
if
the
post-tech
data
associated
with
their
debtnet
service,
sub-layer,
then
probably
the
option.
One
is
the
solution,
but
then
the
question
is
so:
what?
If
the
post
Tech
data
being
added
by
a
penalt
on
a
transport
layer
so
where
the
P
node
would
be
required
to
put
the
postek
m
a
header
or
actually
would
it
be
a
well
some
possible
scenario?
Then
a
p
node
in
a
definite
domain
can
add
M
A.
A
D
D
It's
well
actually
I
looked
at
existing
individual
drafts
that
reflected
so
that
post
deck
m,
a
header
I,
just
looked
at
existing
I-
think
it's
a
Jax
draft.
The
group
of
offers
put
together
and
I
just
used
their
header
proposed
encapsulation,
and
it's
not
that
I'm
proposing
posting
data,
encapsulation
I
just
use
what's
available
and
I
I
refer
to
it
as
a
post
stack
m,
a
header.
D
D
E
D
E
C
H
D
And
actually,
that's
that's
a
very
good
point
because
again
I
think
that
in
our
this
in
the
discussions
on
post-tech
data
m
a
so
far,
we
were
concentrating
on
IP
payload,
but
now
death
net
in,
in
my
opinion,
is
it
a
good
example
of
analyzing
their
interaction
with
the
possible
post
deck
data
solution
with
non-ip
payload
and
non-ip
payload
particular
that
uses
control
word
and
ACH.
So
basically,
that
already
has
first
nibble
of
its
own.
D
C
G
G
So
this
means
there
is
something
in
between
end
of
stack
and
startup
post
Tech
data,
so
that
will
facilitate
the
option
one,
and
maybe
there
could
be
some
implementation
that
assumes
or
hard
codes
that
in
that
net,
that
you
know
after
end
of
Stack.
It's
assumed
that
it
is
zero
zero,
zero
with
a
sequence
number
in
that
net.
So
it
may
not
this
way.
If
you
go
with
option
one,
it
will
not
break
the
compatibility
backwards,
compatibility
right.
D
B
D
G
D
E
D
No
like
in
mtls,
so
we
don't
have
indication
of
length
of
the
payload
so
for
OEM,
it's
all
derived
from
the
channel
type,
because
the
channel
type
as
this
is
a
part
of
Ayana
registry,
and
it
defines
the
different
types
of
the
payload.
So
then
the
length
of
that
net
OEM
is
derived
from
their
Channel
type
as
for
pseudoir
mpls
or
it
might
be
in
the
case
with.
D
B
A
E
D
Again,
it
gets
tricky
and
once
I
realized
that
I'm
getting
too
deep
in
the
woods,
so
I
just
backed
off
I
but
yeah.
There
are
a
lot
of
more
detailed
questions
that
will
come,
but
I
think
that
most
of
them
would
be
not
really
that
specific
to
that
net
in
mpls
and
M
a
interaction
but
I
I,
just
probably
only
scratched
the
surface.
F
D
C
D
G
A
G
I
I
Okay,
I,
correct
I
think
you
may
talking
about
the
a
detected
functions
defined
in
the
current
rfcs
well
I
see.
There
are
also
some
enhanced
internet
data
plane
for
the
like
the
bounded,
latency
or
other
features
being
discussed
in
the
dead
networking
group
to
to
have
analysis
about
that
kind
of
information.
D
That's
a
good
question.
Yes,
thank
you
for
bringing
up
their
active,
interesting
discussions,
but
my
understanding
is
that
it's
not
yet
a
working
group
conclusion.
So
basically
there's
nothing
that
we
can
look
at
saying.
Okay,
that's
what
that
networking
group
agreed
on
and
that's
let's
work
with
them
on
how
that
works
in
mpls
data
plane.
H
Yeah,
thank
you
if
I
may,
chime
in,
as
that
networking
group
chat.
Thank
you
response.
So
actually
all
of
these
are
individual
contributions
and
they
are
refining
the
scaling
requirements
and
all
around
the
Revolution,
and
there
is
no
consensus
on
which
Solutions
the
working
group
would
go
with
on
there
and
data
plane
enhancements
and
as
for
the
I
added,
also
to
the
chat
to
the
control
word.
All
the
statements
are
I
think
applicable
for
all
the
other
controvers,
not
just.net,
about
existing
implementations
and
all
kinds
of
stuff.
E
D
E
I
Just
one
quick
feedback,
my
reading
is,
in
the
use
case,
draft
of
M
A.
We
mentioned
the
one
use
case
about
the
upon
the
latency
or
something
similar
I'm.
Not
maybe
we
can
have
more
discussion
with
the
test
that
we
provided.
This
is
a
valid
use
case,
regardless
of
the
detailed
encapsulation,
a
solution.
Whether
this
is
something
that
will
welcome
further
in
the
looking
group.