►
From YouTube: IETF-MPLS-20230622-1400
Description
MPLS meeting session at IETF
2023/06/22 1400
https://datatracker.ietf.org/meeting//proceedings/
D
C
D
D
D
D
Let's
get
started
so
this
is
the
mpls
m
a
interim
for
today.
This
is
part
of
a
series
that
we've
set
up
and
I
can't
remember
this
is
this
is
meeting
number
five,
but
doesn't
matter
much
and
as
usual,
this
is
a
collaboration
between
three
multiple
between
three
working
groups
and
we
have
participation,
hopefully
from
all
three.
D
D
D
Okay,
I,
don't
see
anyone
besides
Loa
and
I'm,
hoping
Loa
is
not
yeah,
he
did
turn
off
the
mic,
so
we
have
a
list
of
action
items.
I
was
hoping
to
switch
to
it,
but
I
will
have
to
turn
off.
My
sharing
I
still
have
one
slide
and
it
is
part
of
the
action
items.
So
let
me
flip
to
the
slide
and
then
I
will
go
to
updating
the
action
items
after
going
through
that
slide.
D
So
one
of
the
action
items
that
we
are
tracking,
let
me
flip
to
it
and
we
can
update
them
as
we
go,
was
why
beer
picked
up
the
value
5
for
mpls.
First
nibble
and
I
I
did
investigate
the
RFC
8296,
where
they
did.
You
know
the
mpls
encapsulation
Forum
beer
and
they
introduced
this
allocation
of
value
5
for
the
nibble.
The
claim
is,
they
are
doing
that
so
that
they
don't
confuse
ecmp
Logic
on
transient
lsrs
as
usual,
so
not
to
confuse
it
with
any
other
IP
packet
for
load
sharing.
D
But
the
more
interesting
part
also
is
the
a
bfr
that
receives
a
packet
with
any
other
value
in
the
first
nibble.
It
should
discard
the
packet
so
they're,
actually
using
it
as
a
sanity
as
well.
So
if
a
bfr,
which
could
be
a
Transit
LSR,
receives
such
a
such
a
packet
and
it's
not
five,
then
the
first
interval
is
not
five,
then
they're,
counting
it
as
a
invalid
packet
and
I
thought.
D
So
some
other
indication
in
the
packet
will
will
dictate
that
this
is
an
M
A
and
then
the
first
nibble
would
do
sanity.
But
in
any
case
this
is
about
beer
first
nibble
and
the
beer
first
novel
as
they
are.
You
know
they
document
here.
They've
allocated
five
for
two
reasons:
one
is
the
ecmp
logic.
The
second
is
a
sanity
kind
of
thing,
so
that's
number
one
and
I
will
stop
a
little
bit
here
and
if
anyone
wants
to
comment
or
ask
questions,
I
see,
Loa
is
raising
his
hand.
C
D
D
D
Okay,
the
second
thing
I
want
to
talk
about,
and
maybe
and
I
did
present
the
header,
the
beer
header.
For
that
reason,
is
they
have
an
entropy
inside
the
if
you
notice
that
they
have,
you
know,
presented
a
a
header
for
the
payload
of
mpls
and
the
first
nibble
is
obviously
the
first
nibble.
They
have
also
a
version
which
comes
right
after
the
first
nibble
and
then
they
are
sending
the
entropy
there.
D
So
hopefully
this
in
this
can
trigger
discussion
on
the
next
action
item,
which
is
how
did
we?
How
do
we
intend
to
address
a
packet
carrying
M,
A
payload,
as
well
as
other
mpls
existing
features
payload
and,
if
that's
already
addressed,
maybe
some
can
confirm,
but
at
least
as
far
as
I
know,
it's
not.
D
D
D
D
D
D
B
D
E
E
E
Basically,
we
can
partition
the
existing
Technologies
into
three
different
categories:
one.
We
call
that
passport
mode,
which
means
the
information
is
carried
in
the
user
packet
and
and
every
node
on
the
pass.
Some
new
data
will
be
added
to
it,
and
another
branch
is
called
postcard
mode
in
this
this
modes.
The
data
will
not
be
carried
in
the
user
user
packet.
E
We
call
that
hybrid
mode,
so
iom
Trace
in
RFC
9187,
is
a
example
of
the
passport
mode
technology
and
lmdx.
In
RFC
9326
is
an
example
of
the
instruction
based
postcard
mode
technology,
and
we
have
another
draft
called
pbtm,
which
is
a
marking
based
postcard
mode
technology
and
there's
a
yet
another
draft
called
hybrid
two
steps,
which
is
a
hybrid
mode
technology.
E
E
The
other
node
intermediate
node
only
need
to
you
know,
collect
the
data,
add
and
add
data
to
the
packet
based
on
the
instruction
header
and
finally,
is
a
has
low
bandwidth
consumption
compared
with
other
schemes,
but
it
has
a
Hazel.
It's
a
drawbacks.
The
first
one
is
yeah.
It
doesn't
need
to
change
the
package
at
every
node
and
visual
inflates
the
packet
size.
E
If
you
have
a
very
long
pass,
then
the
data
added
to
the
packet
will
be
significant
and
also
it
has
an
encapsulation
needs,
because
it's
a
big
chunk
of
data
in
any
transport
protocol.
You
have
to
consider
where
to
encapsulate
this
instruction,
header
and
the
data,
and
it
has
its
own
security
vulnerability,
although
there
are
some
other
drops
talking
about
how
to
authenticate
the
data
but
to
basically
the
the
we
have
no
time
to
to
to
encrypt
the
data.
E
So
it's
basically
the
plain
data
will
be
carried
in
the
packet,
and
you
know
if
the
data
were
intercepted
by
the
malicious
users
or
some
other
attackers.
They
will
live
against
the
session,
maybe
very
sensitive
information
in
the
network
and
also
it
has
a
data
package
Faith
sharing
problem,
which
means
once
the
user
packet
is
dropped.
The
data
also
lost,
and
then
you,
you
won't
know
where
the
data
is
packet
is
dropped.
So
it's
difficult
to
figure
out
the
light
and
on
the
other
hand,
if
we
can
for
the
Postcard
mode,
it
has
many
advantages.
E
Maybe
the
only
single
single
bit
in
the
existing
header
field
is
needed
to
indicate
that
so
it's
overhead
is
a
relatively
low
compared
with
postcard
mode
and
also
the
encapsulation
may
be
avoided,
but
it's
only
true
for
the
marketing
based
postcard
mode
for
the
instruction
based.
We
still
need
to
consider
encapsulation,
even
though
the
header,
the
instruction
header
itself,
is
a
smaller
and
it's
a
potentially
more
secure
in
in
this
in
this
mode,
because
we
will
use
a
stand
in
Standalone
or
independent
postcard
packet
to
send
the
stands
collected
data.
E
D
A
So
it's
out
of
band
and
can
be
collected
using
any
management,
buses
or
hybrid
mode
or
actually
hybrid
two-step
protocol,
because
hybrid
two-step
protocol
is
not
intended
to
generate
measurements,
but
only
to
collect
and
transport
operational
State
Telemetry
information
that
being
generated
using,
for
example,
IEM
direct
export
or
alternate
marking
method.
So
as
such
hybrid
two-step
is
addressing
only
part
of
the
problem
which,
as
you
pointed
out,
for
example,
for
the
Postcard
mode
or
what
mode
that
you
refer
as
a
postcard.
E
E
But
if
you
look
at
this
figure
here,
we
only
focus
on
the
on
those
side
of
technology
which
need
to
collect
data
on
every
node
on
the
path
not
includes
some
end-to-end
type
of
Technologies.
So
if
I
I
refer
the
iom
choice
only
in
rxc
9197,
but
actually
in
9197,
there
are
different
options
for
iom,
including
the
end
to
end.
B
E
A
That's
yeah.
Thank
you.
I
would
argue
that
auto
networking
method
is
not
exclusively
end
to
end
and,
as
was
demonstrated
from
the
first
publication,
is
experimental
document
and
now
as
a
full
standard.
The
transit
nodes
are
capable
of
measuring
packet
loss
and
packet
delay
and
obviously
some
other
information
can
be
associated
with
this
measurements,
because
packet
can
be
inserted
in
the
batch,
but
I
think
it's
outside
the
scope
of
your
presentation
and
let's
proceed
further.
Thank
you.
Yeah.
E
Okay,
thank
you
and
let
me
continue
for
the
discussion
on
the
postcard
mode
advantages
and,
in
addition
to
this
more
secure
and
also
it
has
a
better
property
to
detach
the
pet
jobs
location
because
because
each
node
on
the
path
we'll
send
the
postcard
as
a
user
package
drop
somewhere
and
the
previous
postcards
are
still
available
with
the
partial
data
and
of
course,
after
that,
you
can
no
longer
see
the
postcard
for
this
packet.
Then
at
least
you
you,
you
can
still
collect
partial
data.
It's.
E
Debug
the
network,
while
finding
out
where
the
package
is
actually
dropped,
so
that's
a
good
feature
of
postcard
mode,
but
again
the
curse
mode
has
its
own
disadvantages.
The
first
one
is
a
data
correlation,
because
each
node
will
send
a
piece
of
data
to
The
Collector.
So
you
The
Collector,
will
get
us
a
set
of
this
postcard
and
there
might
be
many
other
packets
or
many
other
flows,
or
all
this
all
sends
the
postcard
packages.
E
So
the
The
Collector
need
to
correlate
this
postcards
to
make
sure
which
set
of
postcards
belong
to
a
same
or
original
user
package.
This
is
sometimes
it's
a
not
easy
to
do.
You
need
some
extra
matters
to
to
achieve
that,
for
example,
in
the
iom,
direct
export,
we
have
two
in
add
some
optional
data
views
to
indicate
ID
and
the
flow
ID,
and
something
like
that
and
to
help
the
collector
to
correlate
this
data
and
for
the
pbtm
for
the
marking
base
that
postcard
mode
is
a
the
data.
E
Correlation
task
is
even
harder,
so
we
need
to
take
many
serious
matters
to
to
achieve
that
and
also.
Secondly,
it
has
a
high
higher
data
export
overhead,
because
each
node
will
stand
a
standalone
postcard
packet,
which
is
has
its
own
header
and
the
data.
So
there's
some
of
offers.
The
summary
analysis
and
such
data
will
increase
Network
bandwidth,
consumption
and
also
it
has
a
higher
configuration
overhand
each
node,
especially
for
the
marking
based
postcard.
We
have
to
configure
each
node
through
the
management
plane
before
the
operation
to
tell
them.
E
E
The
the
the
the
problem
is
similar
to
the
passport
mode,
so
we
have
to
figure
out
how
to
encapsulate
this
header.
So
so
we
can
see
each
of
this
technology
has
its
own
pros
and
cons
and
therefore,
as
a
protocol
designer
Lacross,
we
we
just
need
to
provide
some
mechanism
to
support
them.
We
can
know
to
make
a
decision
for
the
users,
because
we
don't
know:
what's
your
application
is
not
real.
What's
their
preference
to
use
these
Technologies
I
think
each
of.
E
A
The
other
thing
is
that
what
I
want
to
point
in
it
I
see
consider
it
to
be
a
benefit
of
direct
expert
or
postcard
mode,
as
you
refer
to
it
is
that
it
can
be
done
out
of
band
so
not
to
use
the
same
resources
as
used
by
their
data
traffic.
So,
although
yes
Telemetry
information
is
helpful,
but
it's
not
critical,
so
that's.
Definitely
it
can
use
different
class
of
service
somewhere
from
their
management,
plane
and
I.
A
Don't
really
agree
that
we
should
not
analyze
the
benefits
and
consider
benefits
that
are
characteristic
to
one
method
or
another
when
we
decide
of
what
would
be
supported
and
standardized
in
npls
network,
because
if
we
understand
the
implication
that
particular
method
is
will
cause
in
mpls
data
plane.
We
need
to
be
cognizant
and
aware
of
it
and
not
let
everything.
C
A
C
C
If
we
want
to
discuss
a
MPS
iom
in
general,
we
should
actually
dedicate
a
presentation
for
that
and
try
to
focus
on
the
question
why
we
had
it.
This
is
not
to
say
that
we
don't
need
the
overview
here.
I
think
that
was
good
and
the
discussion
is
actually
also
enlightened,
but
we
should
try
to
concentrate
on
the
questions
asked.
C
B
D
Okay,
thank
you.
One
more
question
from
me
is
the
ability
of
every
router
in
the
postcard
mode
to
export
OEM
data.
You
know
in
the
postcard
mode,
I'm
presuming
the
direct
sport
mode.
Every
router
has
to
be
able
to
export
this
OEM
data
because
it's
not
carried
in
the
packet
it's
done
out
of
band.
Is
that
a
pro
or
a
con?
Is
that
something
good
or
bad.
E
E
So
next
slide,
so
next
last
time
talking
I'm
going
to
talk
about
a
use
case
for
the
PSD.
We
call
that,
across
the
main,
Internet
working
use
case
I
assume
in
the
network.
We
have
a
multiple
different
network
domains
which
is
for,
if
each
of
you
run
a
different
protocol,
for
example,
between
the
two
IPv6
domains
will
have
a
MPS
tunnel
between
that
and
for
the
from
the
network
operator
perspective
would
be
the
lack
to
collect
Telemetry
data
on
every
node
on
this
networking
pass.
E
That
is,
we
want
to
support,
hope,
I,
hope,
iom
trees,
even
their
Kano,
innate
with
the
like
to
use
a
so-called
uniform
mode
to
to
to
make
every
node
in
a
tunnel
visible
to
another
operator
and
which
means
Ubuntu
also
collect
data
on
each
MPS
node
in
this.
In
this
scenario,
so
in
that
case,
suppose
the
user
decide
to
use
the
io
iom
trees
in
IPA
V6
encapsulation,
depending
according
to
a
current
active
draft.
E
We
would
copy
this
extension
iom
header
from
the
instruction
from
from
the
extension
header
of
IPv6
to
the
MPS
PSD
and
then
in
the
MPS
Network,
the
actual
IO
am
data
will
be
added
to
the
to
to
the
PSD,
as
shown
in
the
speaker
when
this
packet
leaves
this
ampere's
domain
and
the
MPS
header
will
be
removed.
Now
the
entire
iom
data
will
be
copied
back
to
the
IPv6
extension
header
field
to
overwrite
the
previous
previous
one
or
the
old
one.
E
Comply
applies
to
other
types
of
actions
for
for
which,
if
the
data
size
is
too
large,
it's
not
suitable
for
the
ISD
encapsulation.
It
need
to
be
carried,
the
post
stack
and
it's
a
need
for,
because
in
the
other
domain
it
will
be
carried
early
character,
user
in
the
extension
header,
and
then
it's
moved
to
the
MPS.
We
need
to
keep
the
data
intact.
The
format
intact
and
because
of
the
size
of
the
data
is,
is
an
impossible
or
improper
to
be
encoded
in
the
in
the
in
stack.
A
E
This
chaos
case
can
be
sold
with
ASD
and,
first
of
all,
because
the
overhead
could
be
quite
large.
Even
we
consider
a
relatively
simple
scenario
with
a
small
number
of
hops
in
the
network,
and
it
will
end
a
small
amount
of
data
to
be
cleared
that
each
for
each
hop.
Then
the
data
when
we
add
up
the
data,
the
hydro
sets,
will
still
be
too
big
to
fit
in
ISD.
E
B
E
We
have
this
again
and
it's
a
very
straight
walk
forward
to
implement
that
once
we
have
the
draft
ready
and
the
last
questions
on
is
the
compatible
there's
a
are
there
any
compatibility
issue
with
PSD
I
think
this
is
a
general
to
all
the
use
cases
they're
trying
to
use
PSD
right.
We
have
seen
some
existing
Works
like
so
so
they
they
all
claim,
claim
the
location
immediately
after
the
label
stack
and
before
the
original
payload.
E
So
I
think
we
need
to
solve
that
problem,
and
if
we
still
want
to
use
those
Solutions,
then
we
need
to
consider
where
we
will
locate
this
PS
PSD
it's
after
that
or
before
that
and
or
another
alternative
Solutions.
We
try
to
unify
uni
unify
the
solution
by
you
know
even
trying
to
include
those
use
cases
into
the
PSD
and
the
reformats
them
using
the
same
mechanism.
Then
then
we
have
a.
We
will
have
a
single
PSD
based
solution.
We
can
support
all
the
existing
use
cases
I
think
from
the
long
term.
E
E
E
A
Yes,
this
one,
so
a
couple
of
comments
that
I
would
like
to
make
I
am
is
for
limited
domain,
so
I
really
don't
see
how
The
Limited
domain
being
defined
in
RFC
9197
for
IM
and
I
am
direct
expert
because
it
doesn't
change.
This
scope
can
be
extended
to,
inter
or
the
main
scenario
that
you
consider
here,
because
in
my
understanding
it's
clear
that
IM
will
be
separate
in
each
of
these
domains
that
use
different
data
plane.
A
E
E
E
With
the
limited
domain,
let
me
this
is
related
to
your
first
question.
So
it's
about
the
it
was
a
definition
of
say,
limited,
limited
domain
if
I
think,
if
the
whole
network
is
under
the
operation
of
single
Network
operator,
a
single
management
domain
and
can
be
considered
as
still
I
think
this
can
be
considered
a
limited
to
me.
So
since
there's
a
under
the
chart
of
the
one
administrator,
it
can
monitor
the
entire
Network's
performance
so
to
get
the
whole
performance.
E
Now
is
because,
as
you
said,
it's
very
hard
to
for
the
different
operators
on
to
to
collaborate,
there's
a
trusty
issue
and
there's
a
security
issues
as
difficult
to
solve
now,
but
from
the
technical
itself,
I
I,
don't
think
as
a
it's
unconceivable
to
actually
deploy
this
to
the
you
know,
to
cross
the
different
domains
and
if
there's
a
even
higher
level
entity
which
can
be
consistent,
considered
a
big
limited
domain,
then
everybody
every
smaller
the
main
trustless
entity.
Then
it's
certainly
doable
to
do
this.
E
E
E
A
I
think
yeah
I
think
that
this
is.
This
is
not
correct.
Interpretation
of
ITF
understanding
of
a
limited
domain
I
think
it's
a
RFC
8799.
So
I
really
wonder
if
this
is
a
realistic
scenario
that
we
need
to
discuss
because
again
it
violates
their
scope.
Applicability
of
IAM
and
Define
proposed
describes
based
on
the
mechanism.
That
is
not
really
being
agreed
to
how
to
do
this.
A
B
E
I'm,
basically
down
because
it's
a
this
slide
that
shows
some
example.
How
the
you
know
the
data
will
be
added
to
the
to
the
node
in
this
scenario,
and
you
can
see.
Finally,
we
might
have
up
to
19
RC
works
of
data,
but
if
we
want
to
use
I
iom
three
allocation
mode,
then
we
need
to
reserve
that's
that
space
for
at
all
the
nodes,
so
which
means
every
no
need
to
handle
up
to
18
wordsworths
of
data.
So
that's
obviously
too
much
for
the
in-stack
encapsulation.
D
For
you,
can
you
keep
that
slide?
You
know
for
a
moment.
I
have
a
question.
So
are
you
thinking
of
trading
iom
data
similar
to
the
TTL?
You
know
they
are
in
the
pipe
model,
and
you
know
in
mpls,
when
it's
traversing
IP
packet
traversing,
an
mpls,
you
can
either
you
know
copy
the
ipttl
to
mpls
or
basically
tunnel
the
packet
across
that
will
appear
as
one
hop.
D
E
Okay
for
the
particular
field,
I
think
we
there
are
some
already
existing
standards
or
jobs
to
describe
the
behavior
of
that
and
for
the
aom
itself
is
it
can
collect
a
wider
range
of
data,
for
example
the
timestamp
or
or
of
the
data
which
I
think
is
very
important
to
measure
the
past
latency
or
no
latency.
So,
for
that
is
a
independent
of
you
know
what
type
of
node
it
is
so
so,
as
for
the
other
fields
like
the
tto
I,
think
those
details
we
need
to
for
the
discuss.
D
D
E
D
E
B
E
D
E
E
E
D
D
E
Different
techniques
can
solve
the
problem
and
achieve
the
acquire.
The
same
information
right,
but
the
mechanism
very
different,
and
there
is
an
alternative
solution-
doesn't
mean
we
can
exclude
others
and
only
stick
to
one,
because,
as
I
said
again,
there
will
there
are
pros
and
cons.
You
cannot
make
a
decision
for
the
users.
A
B
A
Can
arrive
it
based
on
their
understanding
of
state
of
the
art
of
IPv6
header
support
in
the
network,
although
it's
being
discussed
that
most
of
many
operators,
they
drop
any
IPv6
packet.
That
includes
any
extension
header.
So
so
you
know
go
ahead
and
improve
it
with
the
information
that
is
not
relevant
to
your
customer
and
customers
would
not
pay
for
it.
But
I
think
that
if
we
ought
to
make
a
decision
on
which
option
to
support
for
Telemetry
on
that
Telemetry
protocol
in
mph.
A
So
it's
on
us
to
make
this
decision
so
with
good
understanding
of
all
implications
that
the
particular
mechanism
protocol
will
have
on
mpls
data
plane.
So
I
I
see
it
differently,
quite
opposite
to
what
you
stated
yeah,
not
that
we
cannot
make
a
decision.
I
believe
that
we
must
make
the
decision.
Thank
you.
E
Well,
yeah,
so
that's
exactly
our
personal
opinion,
but
mine
is
that
we
are
now
just
Define
the
mechanisms
to
hold
the
SD
and
the
PSD.
It
should
be.
You
know,
Note
3
exclude
any
any
possible
potential
use
cases
because
for
for
one
thing
we
already
have
this
solid
use
cases
and
for
another
thing
we
can
notice.
E
E
E
D
A
C
Right
one
thing
is:
we
actually
should
try
to
trigger
the
discussion
on
the
mailing
list.
All
right,
I
think
I
have
questions,
but
I
have
to
do
a
little
more
thinking
about
it
before
I
ask
them,
so
it
would
be
good.
I
I
can
maybe
initiate
it
when
I'm
actually
understand
what
I.
What
I
need
to
ask,
but
mainly
mailing
list
is
good.
We
should
use
it.