►
From YouTube: IETF112-MPLS-20211108-1430
Description
MPLS meeting session at IETF112
2021/11/08 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
Okay,
welcome
everyone.
This
is
the
mpls
working
group
session,
I'm
going
to
walk
initially
over
the
status,
update
and
couple
of
logistics
and
pointers,
and
then
I'm
going
to
hand
it
over
to
loa.
We
are
meeting
this
time
for
ietf
112.
This
is
still
a
virtual
online
meeting
and
your
chairs
for
mpls
working
group
myself
tarek
lowa
and
nick
our
secretary
for
ampules
working
group
is
mak
chen
and
unfortunately,
he
won't
be
able
to
attend
for
personal
reasons.
A
A
We
do
have
an
extension
notewell
for
guidelines
for
for
conduct
in
idf
and
basically
it
it
favors
or
encourages
people.
It
means
it
strives.
Itf
tries
to
create,
maintain
an
environment
where
people
should
respect
each
other,
have
decency
and
dignity
each
other
and
doesn't
allow
in
any
space
for
harassment
in
idf
and
that's
basically
I'll.
Let
you
read
through
the
the
text,
but
we
we
do
encourage.
You
know
to
follow
these
practices
set
out
by
itf.
A
In
terms
of
some
useful
pointers,
as
usual
blue
sheet
are
automatically
populated
by
meat
echo
minute
taking
nick
and-
and
I
courage
you
know,
whoever
can
contribute
to
the
minute.
Taking
please
log
into
this
url
and
and
or
you
can
use
the
the
meet
echo
icon
on
the
top,
which
will
take
you
there
as
well.
A
One
important
pointer
on
this
page
is
that
we
now
have
a
github
repo
for
the
mpls
working
group.
We
have
a
couple
of
drafts
that
the
design
team
has
put
up
on
the
repo,
but
I
do
encourage
participants
to
put
their.
You
know.
Work
in
progress
drafts
that
other
people
can
open
issues
on
and
review
and
give
comments.
A
This
is
our
agenda.
Today
we
have
a
couple
of
minutes
to
go
over
more
administrative
things
and
then
we'll
move
on
on
to
the
working
group
status
report
and
then
I'll
hand
over
to
loa
to
talk
more
about
the
open
design
team
report,
reporting
on
that
and
the
activities
that
the
design
team
is
working
on.
A
A
A
A
A
B
A
Yeah,
okay,
then
the
state
stat
status
is
yeah.
I
mean
it's
still
waiting
on
them
for
the
respond
yeah.
The
next
document
we
have
is
a
newly
adopted
document.
It's
a
working
group
document
now
and
we
have
triggered
the
early
code
point
allocation
for
this
draft.
We
have
received
a
request
and
from
the
office
that
it's
it's
suitable
to
do
early
code
allocation.
A
D
Regarding
rar
cpfr,
I
I
mean
this
was
I
mean
it
was
pushed
to
isg
for
application.
I
think
it
just
sat
there
for
some
time
and
I
think
the
ask
was
to
make
enough.
I
mean
the
updates
are
made,
but
the
ask
was
to
go
back
to
the
working
group
and
revisit
it.
I
don't
know
why
it's
stuck
in
the
state.
Is
there
something
that's
expected
of
the
authors.
A
D
E
D
D
A
C
A
C
A
C
A
F
So
sfo
control
I've
done
as
much
as
I
can
do
without
some
feedback
from
other
people,
so
either
informal
feedback
by
someone
by
people
in
the
working
group
reading
it
or
formal
feedback
by
the
working
group
chairs,
putting
it
through
the
mpls
review
process
and
into
last
call.
But
I
can't
do
any
more
work
without
other
people
commenting
on
it.
B
B
G
A
A
A
A
A
Okay,
I
promised
the
report
on
this
draft
in
band
pm
encapsulation,
so
there
was
a
version
that
was
reviewed
by
the
mpls
review
team
version.
One
and
the
authors
took
action
and
addressed
all
the
comments
version.
2
stands
as
is
there's
an
open
issue,
or
maybe
it's
staying
in
line
with
what
is
happening
in
the
mpls
open
design
team.
There
is
a
talk
about
mpls
indicators
and
ancillary
data,
being
you
know,
being
discussed
at
open
design
team.
A
H
A
H
B
B
B
So
we
had
quite
suddenly
five
or
six
drives
that
actually
was
looking
to
using
the
same
place
in
the
labor
stack
as
we
had
been
using
for
the
ach,
and
it
turned
out
that
it
wouldn't
work.
So
we
needed
to
do
something
and
we
had
a
couple
of
people
that
stepped
in
and
said
that
this
is
the
kind
of
an
architectural
question
and
we
need
to
make
be
very
careful
that
we
don't
do
anything.
B
B
B
Indicators
carried
within
the
mp
label,
stack
to
indicate
that
there
are
some
wanted
actions
that
is
not
clearly
strictly
clear
from
the
label
itself.
Anxiety
data
is
carried
with
the
packet
and
is
in
support
for
those
those
actions.
Ancillary
data
has
three
different
forms.
It
can
be
in
stack
data.
This
is,
it
can
be
post
data
or
it
can
be,
we
say
no
data
and
putting
no
data.
There
is
a
little
bit
of
a
stretch,
but
we
have
cases
so
it's
there
next
slide.
Please.
B
B
B
B
Anxiety
data
might
be
complex
and
have
structure
it
might
not
just
be
one
value
or
something
it
could
be
something
more
complex,
and
when
we
specify
new
applications,
they
need
to
resolve
how
to
carry
indicators
and
ancillary
data
without
interfering
with
the
earliest
existence
existing
specifications,
a
one
more
slide.
I
think.
B
B
B
B
B
B
A
C
C
C
I
C
I
I
C
I
C
C
A
F
F
Well,
if
it's
a
pseudo
wire,
you
shouldn't
be
going
and
looking
around
below
the
stack
anyway,
so
it
doesn't
matter
what
is
there?
It's
never
going
to
be
interrogated
other
than
as
part
of
a
normal
pseudowire
operation.
Anything
else
is
not
going
to
go
down
there,
because
you're
saying
you
have
to
put
any
a
an
entropy
label
in
there.
So
I
don't
think
you
need
the
complexity
of
these.
These
two
cases
just
use
one,
and
we
already
have
one
that
works,
which
is
using
id
ip
udp.
C
C
C
C
C
A
C
C
F
Located
by
the
ach
expert
and
they've
usually
been
associated
with
sudoa,
which
is
where
we
developed
all
this
in
the
first
place.
But
it's
not
a
turf
issue
here.
This
is
about
you
know,
doing
the
right
thing
in
a
simple
and
consistent,
simple
and
consistent
way,
and
I
am
very
confused
as
to
well.
I
think
we
need
to
spend
more
time
talking
it
through,
which
is
why
I'm
suggesting
a
side
meeting.
E
E
E
E
E
Well,
so
the
the
comments
we
received
so
far
have
already
been
addressed.
We,
of
course
we
welcome
people
to
review
and
send
them
more
comments.
But
since
this
part
of
the
the
document,
the
module
itself
was
a
split
of
the
segment
routing
model,
it
was
already
intensely
revealed
there.
So
I
personally
am
not
expecting
many
new
comments
coming
in,
so
I
I
I
think
we
should
start
the
working
group.
Adoption
call.
B
E
B
E
B
A
E
E
A
A
E
After
this,
we
created
this
new
mode,
small
module
here
in
mprs.
We
also
create
a
separate
one
for
ict.
You
know
for
iss
and
ospf
each.
So
it's
pretty
much
the
the
same
thing.
It's
just
inside
the
icp
module
icp.
Only
you
know
populate
such
information
right
yeah.
There
is
a
for
example,
ospf
sr
msd,
something
that
purple.
K
E
So
right
now,
like
I
just
mentioned
this,
one
is
a
read
only
right,
so
it
really
depends
on.
I
guess,
for
most
vendors.
This
depends
on
the
hardware.
So,
whatever
the
value
reported
from
the
the
lower
level,
the
hardware
level
and
the
software
is
just
you
know,
you
can
only
use
what
information
available.
E
K
A
A
E
The
tab
is
defined
in
the
the
in
the
rfc
8276
and
it's
also
possible
you,
the
entropy
label
rate
depth,
not
only
just
how
many
you
know
so
far.
You
know
future
there
might
be
more
depth,
but
right
now,
if
I
remember
right,
there
are
the
like
the
number
of
maximum
label.
You
can
read
also
the
where
the
entropy
label
depth.
You
can
read.
H
B
A
J
Right,
thank
you
very
much,
so
I
wanted
to
talk
a
little
bit
about
the
deterministic
qs
for
the
mpls
data
plane
considerations.
I
have
one
draft
that
I'm
trying
to
promote
to
get
into
that
net.
There's
also
work
beyond
that.
So
I
really
would
would
love
to
see
more
people
from
from
mpls
site
to
get
involved
in
that
net
and
see
how
we
can
get
that
draft
adopted,
and
I
think
the
reason
for
that
is
what
I
wanted
to
high
level
up
here.
J
So
there
there
are
different
shapers.
There
is
rfc
2212
and
there's
iets
and
asynchronous
traffic
shaper.
But
the
fundamental
issue,
of
course,
is
that
this
is
highly
undesirable.
You
know
in
our
typical
mpls
service
provider
designs,
which
means
segment
routing
networks,
but
we
really
want
to
have
per
hop
per
flow,
stateless
behavior,
but
instead
source
routing,
so
that
we
have
scalability
load,
churn
of
the
control
plane
and
so
on,
and
that
doesn't
work
with
these
because
they
basically
every
every
shaper
needs
to
be
instantiated
from
an
mpls
label.
J
There
is
the
the
total
number
of
the
shapers
that
you
would
need
could
easily
get
into
the
tenth
of
thousands
in
a
large
service
provider
networks,
and
I
think
we've
got
good
experience
that
even
you
know
this.
This
number
of
you
know
just
routing
states
or
so
is
something
that
we
really
don't
want
when
we
can
avoid
it.
There
is.
J
Know
more
application-centric
issue,
and
that
is
that
the
shaper
solutions
do
introduce
the
maximum
amount
of
jitter,
because
as
soon
as
there
is
no
competing
traffic,
the
curing
latency
is
zero
and
with
the
maximum
amount
of
competing
traffic,
you
have
the
maximum
queuing
latency.
So,
and
this
is
really
highly
undesirable,
especially
a
lot
of
industrial
applications
as
we
we
we've
learned
over
the
years.
So
really
the
industry
would
like
to
have
a
lower
jitter
solution,
and
I
did
present
in
in
that
net
example.
J
J
You
know,
tc
qf,
which
is
per
per
flow,
stateless,
a
very
low
jitter,
independent
of
the
path
property,
so
the
jitter
doesn't
go
up
with
the
number
of
ops
or
the
per
hop
latency
and
it
purely
relies
on
using
the
traffic
class
value
in
the
mpls
label
to
indicate
you
know
the
the
additionally
necessary
parameter
to
enable
this
qs
and
and
and
it
is
per
flow
stateless.
So
we
need
three
to
five
of
those
tc
values.
J
So
I
think
this
is
really
the
only
short
term
option
for
no
mpls
packet
header
changes
and
it
is
not
vaporware,
but
instead
it
was
validated
in
a
2,
000,
kilometer,
wide
area
network
with
100
gigabit
or
faster
high-speed
wind
routers,
and
you
know
fairly
simple.
You
know
us
fpga
code
on
the
on
the
qs
chips.
There.
J
J
So
here's
just
a
little
excerpt.
You
know
how
that
tech
cycle
queueing
and
forwarding
works.
It's
pretty
much
based
on
the
12
year
old,
tsn
solution,
cyclic,
cueing
and
forwarding
packets
are
simply
forwarded
bucket
by
bucket
hop
by
hop
into
cycles
and
then
that
effectively
means
that
the
latency
on
a
hopper
basis
is
exactly
one
such
cycle.
J
Latency
and,
of
course
the
jitter
is
then
the
the
cycle
jitter,
which
can
be
hundred
microseconds
and
the
main
thing
that
needed
to
be
done
to
make
this
technology
work
for
large
networks
was
to
really
put
the
cycle
number
into
the
packet
so
that
you
know
in
tsn
a
packet
is
received
into
the
cycle
based
on
its
timestamp
and
obviously
you
know
when
you
have
latency
on
links
and
when
you
have
jitter
that
doesn't
work.
So
that's
why
the
cycle
number
needs
to
be
in
the
packet.
J
So
now
yeah,
and
we
also
are
doing
you
know
pseudo
code.
So
it
hopefully
should
be
easy
to
understand
how
how
you
know
easy.
This,
ultimately,
is
in
the
forwarding
plane
what
needs
to
be
done,
and
then
it
would
obviously
work
exactly
the
same
way
not
only
for
mpls,
but
also
for
the
ip
data
plane
in
that
net,
with
three
to
five
dscp
values
which
isn't
really,
you
know
a
strong.
J
Okay,
so
I
was
talking
about
you
know
extensible
qs
header
and
here's
a
little
bit
kind
of
that
first
round
highlight
of
what
all
the
issues
are,
that
I
think
we
haven't
tackled
with
qs.net
and
beyond
right.
So
the
first
thing
is
that
the
pre-op-
you
know,
we've
done
that
for
mpls,
but
not
for
ip.
So
you
know
given
how,
in
the
mpls
design
team,
there
were
thoughts
of
you
know,
having
headers
that
would
be
equally
able
to
attach
to
mpls
and
to
ip.
J
J
I
myself
presented
one
more
new
thing
into
a
research
conference,
but
there
have
been
a
lot
of
you
know,
ideas
in
that
space
in
the
past
30
years,
and
they
all
may
need
some
different,
but
a
lot
more
new
packet
header
than
you
know,
just
three
bits.
So,
for
example,
my
solution
would
require
a
timestamp
16-bit,
a
priority
which
might
be
a
sequence
of
four
bit
values
and
other
solutions
might
want
to
have.
J
You
know
other
packet,
header
extensions,
and
then
you
know
there
are
beyond
that
net
things
where
really
we
haven't
had
really
good
discussions.
The
most
obvious
one
from
the
pragmatic
side
is,
you
know
just
the
dscp
side,
the
beer
header,
for
example,
which
was
designed
to
support
both
mpls
and
ip
already
has
dscp.
J
That
makes
it
a
lot
easier
when
you're
passing
ip
multicast
over
mpls,
not
to
have
to
bother
with
the
differences
between
tc
and
dscp,
so
that
would
also
be
very
lovely
to
have
for
operational
simplification
in
an
mpls
extension
header,
and
there
are
other
you
know,
cool
things.
So,
for
example,
the
ecn
stuff
in
l4s
they're
struggling
with
just
two
ecn
bits.
If
if
there
were
more,
this
would
be
a
lot
easier.
There
is,
you
know
for
bandwidth
management.
J
There
were
really
good
drafts
where
you
have
a
weighted
bandwidth
parameter,
and
so
I
think
there
there's
a
lot
more
and
the
question.
Is
you
know
what
scope
would
we
want
to
take
into
account
initially?
But
you
know
how
could
we
make
you
know
mpls
extension
headers
easily
enough
extensible
right
do
we,
you
know
like
in
ipv6,
need
to
create
for
every
new
parameter,
a
new
extension
header.
Do
we
use
a
tlv
or
so
on
right?
J
So
I
think
those
are
the
questions
that
would
be
lovely
to
to
tackle
more,
but
we
need
more
qs
people
in
there
and
not
only
the
mpls
header
folks,
right
so
summary
would
really
be
lovely
to
see.
You
know
one
really
well
working
proving
service
provider
class
bounded,
latency
solution
for
net
with
mpls,
that's
usable.
Now
I
think
that's
our
draft
that
we
have
so
it
would
be
great
to
see
support
for
that.
J
You
know
or
questions
if
you
don't
understand
it,
but
then
of
course,
would
also
be
great
to
start
the
longer
term
qs
effort
to
go
along
with
the
mpls
design
team
effort-
and
I
guess
you
know,
yeah
the
reaching
out
to
the
transport
area
and
the
qs
folks
there
is
is
certainly
a
big
part
of
that
and
I'll
see
what
I
can
get
done
there
yep
and
that's
it.
Thank
you
very
much.
J
So
I'm
looking
for
support
for
that
draft,
even
if
it's
obviously
you
know
happening
in
that
net,
but
I
think
the
kind
of
more
use
case
in
terms
representation
of
the
interests
of
service
provider
networks
with
mpls
that's
to
be
found
here
in
the
mpls
working
group.
That's
why
I'm
kind
of
you
know
the
you're
you're
kind
of
the
the
network
owner
working
group.
So
that's
just
you
know,
please
come
to
that
net
and
and
and
and
work
on
this
and
the
other.
A
L
It's
very
quick
actually,
so
one
comment
I
had
was
the
it's
very
loaded
topic,
definitely
turnless
you're,
comparing
with
cqf
and
ats
stuff.
So
basically,
this
is
a
neat
lot
of
understanding
of
dsn
technologies
and
also
the
requirements
to
differentiate
this.
So,
but
the
question
relevant
here
is
that
you're
asking
for
the
tcn,
which
three
to
five
for
the
cq
of
stuff
right,
so
it
happened
in
the
tsu
working
group
also
for
the
l4s.
We
don't
have
that
many
bits
right.
We
have
only
three
bits
here.