►
From YouTube: IETF111-MPLS-20210728-2130
Description
MPLS meeting session at IETF111
2021/07/28 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
We
are
still
virtually
meeting
this
time
and
hopefully,
next
time
we
will
be
in
person
meeting
the
chairs
of
mpls
working
group
are
myself
dark,
loa
and
nick,
unfortunately,
nick
was
not
able
to
meet
with
us
this
time.
But
myself
and
lo
are
here-
our
secretary
is
max
chen
and
he
will
you
know,
he's
he's
doing
a
great
job,
helping
multiple
things
and
he's
going
to
take
minutes
as
we
go
along
thanks
mack.
A
A
Itf
some
administrative
reminders,
blue
sheets-
I
think
it's
done
automatically
nowadays
with
meet
echo.
Please
get
into
the
queue.
If
you
want
to
ask
ask
a
question:
do
not
unmute
yourself
and
immediately
and
speak
unless
being
asked
to
by
the
chairs
for
those
who
use
jabber.
There
is
the
link
there,
but
you
can
use
the
chat
provided
by
medeco.
That
also
works,
and
it's
been
archived
minutes
are
being
taken
in
kodi
md.
The
link
is
there.
I
also
put
it
in
the
chat.
A
A
A
B
B
A
A
Okay,
we
have
two
documents
in
the
rfc
editor
queue.
One
of
one
of
them
would
be
on
the
agenda.
I
won't
mention.
I
will
let
cameron
comment
on
it
and
the
second
one
is
in
misrep.
So
if
the
authors
want
to
comment
on
that,
you
know
feel
free
to
come
to
the
mic.
As
usual,
we
in
terms
of
documents
in
iesg.
We
have
one,
it's
it's
waiting
on
the
go
ahead.
A
C
A
D
D
A
Yeah
some
of
the
the
working
group
documents
we're
they're
waiting
for
some
feedback
from
the
working
group
before
we
progress
further
to
working
group
class,
call
so
feel
free
working
group
to
engage
and
provide
feedback
on
those
documents
we
have.
We
have
a
document
for
the
yang
mldp
and
we
will
it's
on
the
agenda.
We'll
talk
about
it
and
the
one
which
is
just
been
refreshed
and
authors
will
resume
traction
on
that.
A
Maybe
before
I
flip
sorry,
so
we
have
a
number
of
of
the
individual
drafts.
They
are
candidate
for
working
group
adoption
and
we
already
kick-started
the
process.
The
re,
some
of
them
got
review
comments
and
the
authors
are
working
on
the
review
comments.
Addressing
and
specifically,
we
have
asked
you
know
these
two
drafts,
draft9n
and
draftkratty.
A
A
B
A
Header
drafts-
indeed,
indeed,
those
and
and
in
fact
yeah-
draft
compeller,
mpls
mspl
4a-
was
presented
in
as
well.
I
should
have
mentioned
that
we
had
a
joint
session
yesterday
with
pals
in
that
networking
group
and
some
of
the
drafts
were
presented
there
and
if
attendees
are
interested
in
those,
they
can
go
back
to
the
joint
session
and
see
the
materials.
A
B
E
E
Click
so
for
ldp
yang,
it
has
been
last
update,
was
in
march
2020.
That
was,
you
know,
to
be
published
rfc
and
it
was
submitted
to
isg,
and
it
is
as
tariq
mentioned.
It
is
sitting
right
now
in
rfc
editor
queue
due
to
a
misreference
and
pending
on
rocking
working
group
policy
model,
which
itself
was
a
thing
submitted
to
isg
for
publication
in
jan
this
year
with
revision
27.
E
But
I
see
their
more
revision
has
been
uploaded
and
the
isg
status
for
for
this
particular
routing
working
group
policy
model
is,
is
it's
waiting
for
ad
go
ahead?
Perhaps
with
the
revised
ids
are
needed,
so
I
guess
once
routing
working
group
policy
model
moves
or
ldp
and
will
finally
get
published,
there's
nothing
pending
from
our
side.
E
So
mldp
yang,
so
I
think
that's
where
things
have
been
bit
slow
lately,
just
to
remind
us
that,
where
we
are
right
now
and
in
over
the
course
of
the
last
few
itfs,
so
we
had
for
mldp
yang
has
gone
through
already
yang
director
review,
an
early
review
that
was
currently
done
by
ac
lindam
on
a
revision.
Three
of
the
the
working
group
document
very
detailed
comments,
and
they
were
addressed
and
review
was
completed
and
acknowledged
by
ac
and
on
behalf
of
author.
E
Thank
you
ac
for
taking
time
to
do
detail
review
and
after
that
working
group.
Last
color
was
initiated
on
revision
six
and
it
was
close
with
with
some
comments
which
were
addressed.
So
current
revision
we
have
is
revision,
eight,
but
really
that
was
submitted
march
2021,
but
really
in
in.
In
all
that
sense,
there
had
been
no
major
update
to
the
to
this
model
since
division
o5,
and
one
of
the
main
reasons
have
been
that
during
this
time
it
is
same
set
of
other
there's.
E
A
overlap
of
authors
that
are
trying
to
drive
the
both
ldp
yang
and
mldp
yank
and
authors
were
trying
to
prioritize
ldp
yang
to
push
to
isg
and
the
last.
You
know,
commerce
that
we
are
getting
so
it
it
slacked
a
bit
and
afterwards
afterwards,
I
think
for
very
season.
It
hasn't
been
updated.
So
this
is
the
current
status
and
next
slide.
E
So
mldp
yang
was
an
offshoot
of
ldp
young,
of
course,
so
it
inherits
lots
of
those
issues
so
which
really,
if
I
have
to
enumerate
some
of
them,
you
know
we
have
to
make
them
nmda
style.
Yang
security
sections
have
to
be
updated.
We
have
to
specify
you
know
default
values
for
some
of
the
parameters,
the
detailed
discussion
or
what
is
base
and
what
is
extended.
E
You
know
feature
that
we
had
on
ldp
similar
similar
things
are
for
mldp,
but
having
done
those
discussion
already
in
ldp,
it
should
be
a
smooth,
smoother.
You
know
journey
for
mldp,
that's
what
what
we
believe.
So
what
we
are
writing
right
now
doing
is
that
we
are
working
on
applying
all
the
applicable
changes
that
were
already
provided
on
ldp
yang.
As
part
of
the
you
know,
ad
review,
routing
and
director
review,
gen
art
and
security
director
reviews-
and
there
are,
there-
are
significant
of
them
and
we
are
trying.
E
A
E
No,
it
is
not,
but
but
actually
I
remind
my
ourselves
that
in
even
ldp
yang
model,
ldp9
mldp
is
of
course
off
because
that
ldp
yang
multi
topology
was
we
had
put
that
out
of
scope
in
upfront,
so
in
ldp
yang
as
well,
multi
topology
is
out
of
scope.
Having
said
that,
if
the,
if
the
a
multi,
topology
and
mltp,
you
know
it's
because
it's
going
through
working
group
now,
we
can
definitely
have
a
separate
yeah,
but
short
answer
is
that
ldp
or
mldp
does
not
cover
a
young
model.
A
B
B
So
please
go
to
the
next
slide.
I
have
a
so
if
we
have
been
going
around
and
around
a
bit
to
actually
find
out
what
we
should
do,
but
I
think
that
now
we
have
a
pretty
good
understanding
of
what
we
what
you
want
to
do.
We
want
to
some
before
we
actually
start
deciding
on
solutions.
We
need
to
understand
what
we
really
want
to
do
and
that
we
call
requirements
and
for
to
actually
get
the
requirements
in
shape.
We
need
to
start
looking
at
use
cases.
B
B
B
C
No,
I
just
have
basically
one
not
counting
this
one.
So
if
you
go
to
the
next
slide,
I
also
don't
have
much
time,
but
I
just
want
to
give
a
quick
recap:
we
we
kept
this
document
alive.
I
made
a
few
small
changes,
but
basically
the
main
point
of
the
document
was
to
get
a
code
point
so
that
we
can
an
spl
so
that
we
can
do
an
early
allocation
so
that
we
can
do
an
implementation
and
then
that
whole
thing
sort
of
got
sidetracked
because
with
the
fai
the
forwarding
actions
indicator.
C
We
said
we
don't
need
a
code
point
for
this.
We
needed
four
point
for
fai,
but
if
you
do
that,
then
this
would
become
just
a
bit
within
that.
So
the
the
question
of
whether
we
proceed
with
the
fai
or
whether
we
have
to
have
a
spl
for
nffr
no
further
fast
reload
has
to
be
resolved,
but
that
still
leaves
us
sort
of
hanging
in
terms
of
the
early
allocation.
C
The
other
thing
I
wanted
to
talk
about
was
that
we
think
that
the
technical
foundation
for
the
draft
is
pretty
solid.
We
have
done
a
fair
number
of
examples.
We
have
taken
into
account
the
feedback
we
got
on
the
mailing
list
and
the
la
at
the
last
idf.
We
didn't
talk
much
about
this,
but
mostly
because
of
the
everything
was
redirected
to
talking
about
fai.
A
Okay,
thank
you,
I
think
from
you
know,
from
from
my
side
at
least
and
let's
lower
common,
we
want
to
progress
with
adoption,
and
I
don't
see
that
the
you
know
the
special
purpose
label
or
the
fai
is
going
to
necessarily
block
adoption
of
the
document,
given
that
we,
you
know
that
the
the
mp
design
team
is
converging
on.
You
know
not
assigning
an
spl
per
application,
so
that's
my
perspective
is,
if
you
think
the
document
is
in
a
good
shape
to
progress,
we
will
we'll
get
it
into
the
process.
B
C
So
I
I
think
we
would
especially
because
we
now
talk
about
an
extension
header
so
of
the
11
bits
that
you
know
go
with
the
tc
ttl
field.
We
probably
we're
likely
to
have
used
them
all
up
because,
like
I
said,
we
have
six
outstanding
requests
anyway,
so
we're
probably
close
to
using
them
all
up,
but
we
have
an
extension
bit
and
definitely
the
extension
bit.
We
won't
use
up-
hopefully
not
in
this
coming
idea
for
two,
so
we
should
create
an
eye
on
our
registry.
C
B
F
Hi,
this
is
a
question
more
for
tarek
and
lowa,
so
the
for
example,
mpls
iom
in
the
similar
boat,
where
there
is
an
indicator
label
being
asked,
and
then
we
spin
up
the
mtrs
design
team
and
maybe,
if
we
use
a
indicator
label
or
fai
to
say
there
is
ioa,
and
so
we
will
create
the
society
express
review.
And
then
we
do
the
document
because
of
this
design
theme.
B
F
Okay,
yeah,
no,
that's
good
to
know
because
there
will
be
some
churn
as
part
of
the
mpls
design
team
could
be
fai,
and
maybe
I
don't
think
we
have
converged
here.
But
if
working
group
is
okay
to
take
documents
in
that
shape
and
work
on
it
and
churn
it
as
a
design
team,
you
know
agrees
on
the
solution.
B
A
Okay,
I
also
agree
that
should
not
hold
the
process
of
being
adopted
document.
But
if
in
place
where
you're
asking
for
the
spl,
you
can
elaborate
and
say
you
know,
we
have
options
that
we're
considering
in
edition.
You
know
so
that
the
reviewers
of
the
document
understand
that
you're,
you
know
considering
other
options
as
well.
F
Yeah
yeah,
I
think
I
mean
looking
when
we
did
the
mplsrt
experts
review.
The
comments
came
as
a
the
mpls
label
stack
getting
too
big
as
part
of
the
review
and
that's
how
all
this
design
teamwork
started
and
then
fai
proposal
came
as
well
so
and
then
the
drop
was
on
hold.
So
I'm
just
asking
for
some
clarification,
but
if
I
think
there
is
some
good
answer,
so
we
can
request
for
adoption.
G
G
G
Then
the
source
and
destination
node
usually
will
trigger
the
protection
mechanism
by
this
signal
degrade
in
fact,
but
when
signal
segment,
routine
or
mpls
network,
the
intermediate
node
has
no
knowledge
of
forwarding
labels,
so
signal
degrade.
Defect
can't
be
spread
to
eight
node
to
trigger
the
end
to
end
protection
mechanism,
so
we
think
we
should
have
a
mechanism
to
solve
this
problem
next
slide.
Please.
G
G
We
think
the
ccm
message
is
the
best
choice
for
two
reasons:
first,
the
cci
made
it
designed
to
be
used
for
force,
detection
promotes
performance,
monitoring
and
protection
switch
over
and
secondly,
the
system
is
transmitted
in
the
past
periodically.
So
it's
better
to
use
this
message
to
carry
the
sd
flag
in
the
ccm
flex.
They
choose
a
flag,
it's
a
reserved
in
the
flag
field.
G
G
Compared
with
the
last
version,
we
update
this
contact.
The
first
is
end
the
background
of
mprctp
network
in
the
draft.
Secondly,
further
clarify
the
scenario
and
problem
and
remove
one
solution
to
focus
on
the
npr's
tpom
solution
in
ampere's,
wc
and-
and
I
only
request
and
also
and
one
co-author
zinfandra
from
say.
A
G
H
With
our
request
here
and
because
we
see
there
are,
it
is
the
the
problem
originally
from
the
npr's
tv
so
and
we
would
like
to
ask
npr's
working
group
and
to
assign
a
our
or
the
ia
and
not
to
assign
a
one
bit
from
the
flag
field
and
to
let
let
the
authentication
can
be
spread
to
the
networks
so
that
this
is
the
main
goal
of
this
draft.
Actually,
from
previous
draft
and
previous
meeting
that
we
present,
the
importance
of
the
indication
of
signal
degree
degrade
degrade.
H
A
I
And,
given
that
the
channel
type
you
did
assign
to
itu-t
g.8171,
so
I
think
that
year
era,
indication
assignment
should
work
within
itu
dot
8171
rather
than
mphttp
working
group.
Of
course,
at
sharing
information
with
mpls
working
is
useful,
but
I
think
this
assignment
should
be
also
agreed
in
itot
g.8132
and
that's
my
comment.
Thank
you.
B
B
J
A
B
I'm
kind
of
trying
to
read
the
the
documents
and
I'm
I
need
more
time
to
look
at
this.
But
the
thing
is
that
all
of
the
code
points
are
allocated
by
decision
in
the
mpls
working
group
outside
from
the
mp
networking
group.
You
can
send
in
the
request
or
whatever
you
want
to
do
yeah
and
we
can
action
on.
H
Yeah,
not
enough
clarification
for
the
the
confusion.
Actually,
as
the
authors
of
this
draft
that
we
also
confused
about
the
location
that
where
we
should
apply
for
this
for
this
apply,
which
should
request,
we
should
apply
for
this
request.
So,
but
I
because
I
I
read
a
lot-
I
read
some
documents
on
drops
and
it
said
that
all
the
related
after
the
joint
work
between
itt
and
itf,
all
the
all
the
extension
work
based
on
npr's
at
tpe
should
be
should
belong
to
itf.
H
So
we
apply
this
request
here.
Another
reason
is
that
the
the
itot
standards
is
close
to
almost
five
years,
so
we
we,
we
think
it's
better
to
start
initiating
this
work
from
itf,
if
possible,
if
possible,
or
if
it
need
necessary
that
itf
can
send
a
liaison
to
itot
to
see
how
we
can
do
this
facilities
work,
because
this
actually,
this
modification
is
very
small.
H
A
Okay,
I
think
the
feedback
law
I
gave-
and
I
also
support
him.
As
you
know,
we
will
need
to
do
a
little
bit
background
investigation
on
this
and
and
get
back
to
you.
I
suggest
you
send
an
email
to
the
working
group
elias
as
well,
so
that
you
know
we
can
you
know
anybody
else
else
wants
to
comment.
They
can
also
comment
on
that,
but
we're
going
to
get
back
to
you
from
the
chairs.
I
G
G
A
K
Okay,
yeah,
so
just
a
little
bit
of
background
and
history
about
this
draft.
So
initially
this
draft
was
submitted
somewhere
around
2011
and
after
that
I
think
there
was
no
not
much
interest
within
cisco
and
the
transpanders
and
maybe
even
at
the
field,
and
this
graph
was
kind
of
died
and
after
that
101
this
was
presented
again
and
it
died
for
the
second
time
and
it
was,
we
didn't,
have
any
much
progress
in
this
area
for
some
point
of
time.
K
But
now
there
are,
there
is
interest
in
this
particular
work,
not
only
interest
with
respect
to
implementation,
in
fact
deployment
as
well,
and
that
is
the
reason
I
am
bringing
the
draft
again
back
to
working
group
and
just
to
give
back
the
content
is
the
exact
same
as
what
was
revealed.
So
there
is
not.
There
is
no
change
as
of
now
and
all
the
updates
are
planned
after
this
idea.
K
K
So
what
this
draft
is
extending
is
how
to
achieve
same
mdr
functionality
for
mldp,
so
ndp
was
730
7307
defined
for
unicast,
but
this
draft
is
defining
how
to
achieve
the
mtr
functionality
with
point
to
multipoint
mldp
protocol,
and
it
has
both
for
mp
element
and
for
type
wildcard
amp
effect
element,
and
it
also
introduce
a
capability
for
empty
multipoint
capabilities.
So
basically,
all
the
ldp
neighbors
when
they
are
exchanging
their
capabilities.
K
K
So
earlier
there
was
a
two
draft
which
I
think
has
been
merged
into
single
working
group
draft,
which
is
idf,
lsr,
flex
elbow
and
it
it
defines
different
algorithms
and
how
to
carry
it
within
igp.
So,
basically,
this
flex
elbow
is
nothing
but
providing
you
a
lightweight
mechanism
to
define
a
constraint
based
topologies.
Now
this
you,
we
can
think
of
this
way
that
when
we
are
talking
about
multi
topology
within
a
single
topology,
you
may
have
multiple
flex
algorithms.
K
K
So,
in
order
to
support
this
flex
algo,
what
what
we
have
done
is
in
the
slide
3.
We
did
talk
about
7307
tlb,
which
was
our
address
family
definition,
so
that
had
16
bit
16-bit
result
so
out
of
16-bit
now
8-bit
will
be
used
for
ipa,
and
this
ipa
is
nothing
but
going
to
provide
information
about
which
flex
algorithm
is
being
used.
K
And
how,
while
while
doing
mldp
effect
exchange
so
combination
of
mtid
plus,
ipa
is
going
to
create
a
unique
effect.
So,
while
building
a
point
to
multi
point
tree
when
peers
are
exchanging
their
effect
for
label
bindings
multicast
level
bindings,
so
the
mldp
effect
will
carry
both
empty
id
and
ipa.
So
when
for
any
given
route
with
mpid
empty
id
plus
ipa,
it
is
going
to
give
a
unique
fact
or
a
unique
tree
within
a
given
flexible
and
that's
all
it
had.
K
So
any
questions
any
comments.
So
the
plan
is
to
update
the
draft
because
there
is
some
cleanup
needed.
There
are
some
old
reference
of
older
drafts,
which
have
been
either,
which
have
become
now
either
working
group
draft
or
there
are
couple
of
drafts
which
have
been
merged
or
there
are
some
new
rfc
which
have
been
created.
So
we
will
clean
up
the
draft
and
then
we
will
request
for
more
comments
from
working
group
and
adoption
as
well,
and
there
is
already
implementation
existing
for
this
draft.
A
C
C
So,
just
a
quick
recap:
what
the
this
is
proposing
is
to
use
an
arp
mechanism
with
a
small
change
in
the
hardware
type
so
that
the
box
x
can
say
I
would
like
label
to
reach
y
and
the
router
t1
can
say:
okay,
here's
a
label
it'll
do
all
the
stitching
necessary
and
then,
when
x,
sends
packets
with
that
label.
They'll
end
up
in
y,
so
we're
using
an
a
reply.
Request
request
reply
mechanism
very
much
like
arp
to
get
labels.
C
C
So
so
we
have
that
linux
prototype
there's
also
a
prototype
for
tungsten
fabric,
which
is
a
data
center
sdn
solution.
It's
an
open
source
from
the
linux
foundation.
Today,
tungsten
fabric
uses
mpls
over
udp
for
sending
packets,
because,
typically
data
center
fabrics
are
ip,
but
a
lot
of
people
are
asking
for
mpls
based
data
center
fabric.
The
problem,
then,
is
how
do
I
get
my
server
to
be
part
of
that,
and
lrp
is
a
solution
to
that.
A
prototype
for
junos,
which
is
our
operating
system,
is
also
in
progress
and
in
in
recent
updates.
C
C
C
If
you
send
an
if
you
send
a
request
and
you
get
a
reply
and
then
for
some
reason,
things
change-
you
have
to
somehow
withdraw
that.
So
we
handled
many
of
those,
and
I
think
we
can
continue
doing
some
work
there.
But
meanwhile,
I
think
we're
in
a
pretty
stable
place
and
so
we're
requesting
for
working
group
adoption.