►
From YouTube: IETF99-MPLS-20170721-1030
Description
MPLS meeting session at IETF99
2017/07/21 1030
https://datatracker.ietf.org/meeting/99/proceedings/
B
C
C
E
Okay,
so
this
is
an
update
on
the
armored
document.
There
are
a
couple
of
things
as
we
are
having
discussions
within
juniper
and
also
with
some
of
our
customers
on
you
know
what
we
should
do
with
our
mr
and
how
applicable
is
it
to
their
networks?
We
came
up
with
two
things
that
are
really
important.
E
The
first
is
egress
node
protection.
It's
actually
very
similar
to
what
happens
with
PE
protection
for
VPNs.
What
in
BGP
you
call
pick
edge
or
LDP
protection,
so
a
number
of
things
or
pseudo
wire
protection,
but
but
in
our
Mar
one
of
the
things
is
we
want
to
make
things
very
simple
to
configure.
So
the
question
is
not
just
how
to
do
it
because
we
have
lots
of
techniques,
but
how
to
do
it
in
a
way,
that's
very
easy
to
configure.
E
So
the
problem
is
illustrated
here.
You
have
a
ring,
that's
the
thing
in
blue.
You
have
these
two
purple
dots
or
purple
devices,
which
is
the
Rings
connectivity
into
the
bigger
network
and
if
I
have
node
a
talking
to
a
node
B
outside
the
network,
its
exiting
from
the
purple
thing
called
X.
If
a
link
fails,
Armagh
will
give
you
protection
going
back
to
ax
different
paths
and
then
you
can
continue,
but
if
the
node
X
itself
fails,
what
do
you
do
and.
F
E
You
really
want
to
go
to
the
other
node
and
then
go
into
the
bigger
network,
and
so
the
question
is:
how
do
you
do
this
and,
like
I
said,
we
have
techniques
for
this?
The
other
question
is
how
to
make
this
really
simple
to
configure
how
much
of
this
can
be
done
automatically,
and
this
is
all
part
of
our
trying
to
make
these
rings
as
close
to
self-configuring
in
south
managing
as
possible.
So
so
we
have
some
ideas
and
the
next
version
of
the
draft
will
contain
some
of
those
ideas.
E
We
invite
you
guys
to
comment
on
the
list
if
you
have
thoughts
about
this,
if
you
have
comments
or
in
the
suggestions
that
will
come
out
in
the
next
version
and
if
you
can
see
other
ways
of
doing
this,
the
other
thing-
that's
that's
really
interesting.
Is
this
thing
called
a
half
ring
which
is
either
a
ring.
E
That's
incomplete,
for
example,
there's
your
ring
kind
of
sort
of
just
the
the
dark
black
part
and
either
that
connected
via
cornered
or
node
deeper
in
the
network,
or
they
are
connected
directly,
but
the
ring
is
in
level
1
and
that
connecting
link
is
in
level
2
or
the
ring
is
non
backbone
and
the
connecting
link
is
backbone.
So
we
don't
want
to
leak
the
ring
announcements
from
the
non
backbone
to
the
backbone,
so
it
looks
like
an
unconnected
ring,
and
so
the
question
is:
how
do
you
actually
complete
this
ring?
E
And
how
do
you
get
the
protection
you
want?
Because
if
you,
if
one
of
the
nodes
or
sorry
one
of
the
links
in
the
ring
fails,
the
purple
dot
can't
talk
to
a
lot
of
things.
And
so
you
know
it's
not
really
a
ring,
but
it's
kind
of
a
ring.
The
thing
is,
it's
quite
a
common
or
a
reasonably
enough
common
topology.
E
A
E
I've
one
more
side
but
yeah,
okay,
so
I
pull
to
ask
you
a
question
and
it
just
kind
of
pretty
pregnant.
Do
you
realize
that
this
is
a
working
group
document,
yeah,
yeah
I?
Think
so
so
you
come
back
and
say:
we
within
Juniper
has
discussed
with
the
wild
customers.
There
has
been
no
discussion
whatsoever
on
the
mailing
list,
so
why
don't
you
treat
it
as
a
working
group?
Listen
take
the
live
discussion
to
the
race.
Yeah
I!
E
Will
the
the
thing
that
we
will
you
haven't
dancers
in
2015,
so
the
the
idea
had
offering
cereal
discussion,
with
the
exception
for
one
one
very
good
review
a
year
and
a
half
ago
right.
That's
everything!
It
actually
happened
on
a
list
except
for
one
male
are
asking
for
comments,
one
and
the
announcement
means
so
I
don't
find
it.
You
really
treat
this
as
a
working
group
that
you
treated
a
so
individual
draft.
That's
not
true.
The
the
half
ring
was
a
discussion
that
we
had
internally.
Should
we
bring
this
to
the
working
group?
E
Should
we
actually
consider
this
as
a
problem
for
our
AMA,
which
is
a
ring
technology?
This
is
not
a
ring,
so
if
you
have
discussing
where
you
are
our
customers-
and
there
is
no
discussion
on
the
mailing
list-
it
is
still
treated
as
a
working
group.
Talk
you're,
not
getting
my
point,
it's
not
whether
it
should
be
nice
MIT,
not
talking
about
the
half
ring
they're
talking
about
the
document.
E
E
E
Week
not
last
week,
yeah
okay,
so
you
had
time
to
actually
bring
it
to
a
list
before
the
meeting
I
did
it
in
the
update.
So
if
you
look
at
the
update,
it's
discussed
there,
it's
in
the
in
the
document,
but
for
me
the
bigger
question
is:
is
the
working
group
interested
in
this
problem
I
can
bring
it
to
the
list.
I
can
talk
about
it
here.
I
mean
what
already
you
want
me
to
do
this
in
I.
It
is
in
the
draft
and
I'm
talking
about
it
here.
E
E
Okay,
oh
I
mean
I'm,
not
sure
what
you
need
to
do
is
actually
go
back,
yeah
and
actually
start
and
discussion
on
the
mailing
list
of
all
the
topic
that
you
bring
up
in
the
meetings
right
so
far.
The
topics
that
we've
had
discussions
on
we
have
completed
those
so,
for
example,
how
to
signal
this
in
our
in
RSVP
those
discussion
with
George,
and
we
brought
it
to
the
mailing
list
and
we
put
it
in
the
document.
This
discussion
was
something
that
internally,
we
were
not
sure
we
should
do
this
in
our
Mar,
so.
E
Yeah
because
you
just
wasted
all
my
time,
so
the
the
thing
that
we
want
to
say
here
is
half
rings
are
common
enough
that
even
though
they
are
not
a
ring
and
even
though
they
have
trouble
Gregson
suggested,
we
can
do
the
virtual
links
with
we've
thought
about
that.
But
you
also
need
the
physical
connection
so
that
you
can
do
the
protection
in
the
data
plane.
Should
that
be
an
interest
rate?
Is
that
an
interesting
topic
for
erimar
as
a
technology?
E
And
our
answer
is
yes,
because
there
are
enough
people
who
want
a
solution
to
this
and
that's
why
I
say
that
I
want
to
bring
this
to
the
list
and
I
want
to
propose
solutions,
and
if
either
people
have
better
solutions
or
they
like
the
solution
or
they
think
it
shouldn't
be
solved
in
rmr,
because
it
isn't
a
ring.
You
know
that's
for
us
to
decide.
So
basically,
these
I
think
these
are
both
good
problems
to
think
about
in
the
context
of
RMR.
E
E
The
second
one
is,
is
offering
a
close
enough
where
and
touring
that
we
want
to
solve
the
problem
in
the
context
of
rmr
or
we
could
do
it
in
different
contexts
and
so
we'd
like
to
bring
those
two
points
to
the
list.
Have
people
have
a
discussion
on
that
at
that
point,
I
think
we're
done
with
all
the
technical
updates
to
this
document.
I
ran
into
AC
yesterday,
he
said
before
you
progress
this.
A
Again,
the
problem
with
the
BFD
as
a
method
of
monitoring
continuity
of
unidirectional
paths
is
the
return
path,
might
create
false
negative,
so
it
could
be
because
their
network
that
used
for
reverse
direction
is
less
stable
than
the
forward
direction.
So
then,
that's
why
ability
to
control
reverse
path
might
be
beneficial.
So
the
proposal
is
to
use
reverse
path.
A
A
Spring
LS
beeping
for
spring
networks
introduces
three
new
R
sub
TVs
and
they
can
be
used
to
specify
the
reverse
path.
But
here
isn't
some
interesting
idea
for
the
working
group
to
discuss
and
for
everybody
to
discuss.
Unfortunately,
spring
group
doesn't
meet
this
week
and
I'll
bring
it
to
the
mailing
list
as
well.
In.
A
Archetypes
data
model,
LSB
label
stack,
is
characterized
as
a
list
of
labels
and
we
have
started
discussion
because
they
use
explicit
index.
But
even
if
you
use
explicit
index,
you
still
can
do
our
exact
ordering
based
on
indices.
So
why
not
use
our
explicit
label
stack
and
pass
it
to
the
far
end,
a
remote
BD
node
to
use
as
a
reverse
path
for
their
over
segment
routing
and
they
would
enter
less
domain.
D
A
A
58
80
suggests
that
one
of
the
use
could
be
if
we
have
multiple
sessions
between
the
same
pair
of
nodes,
and
we
want
to
minimize
number
of
reverse
sessions
and
we
do
have
a
codification
of
RFC
58
84,
which
deference
that,
because
you
can
have
a
CMP
domain
between
LSPs
or
multiple
LSP
is
between
two
endpoints
and
you
want
to.
Actually
it's
a
suggested
that
you
monitor
LSP.
So
you
will
have
multiple
B
of
these
sessions
over
MPLS
LSPs
between
the
same
two
nodes
for
the
same
FAC.
A
A
There
might
be
some
extensions
to
that
that
what
can
be
done,
that,
if
we
want
to
note
B
to
monitor
and
report
on
continuity
loss
of
messages,
lots
of
messages
from
node,
a
so
node
B
can
send
in
diag
field
loss
of
control.
It's
actually
it's
effectively.
We
call
it
our
di
when
I
think
that
we
referred
it
in
anti
OSTP
document,
our
di,
be
it
set
with
a
pole
and
a
sequence.
A
A
Discriminators,
so
basically
it
will
be
note
a
start.
Sending
barely
parsley,
usually
once
a
second
leave
the
control
packets,
but
with
all
beef
D
discriminator.
So
that's
when
they're
linked
when
LSP
restored,
it
doesn't
need
to
need
to
have
a
new,
are
OSP
thing
bootstrap
and
it
does
it
in
a
synchronous
mode.
Once
the
session
goes
up
again,
node
a
may
instruct
no
B
to
go
in
demand
mode
and
we
have
effectively
the
same
thing.
A
Okay,
so
that
explains
how
it
fails
in
how
to
stores
and
I
appreciate
comments
and
for
agreement
with
B.
If
the
working
group
are
all
bringing
it
to
discussion
to
the
working
group.
But
again,
I
would
appreciate
the
suggestion,
whether
it's
applicable
more
in
VFD
group,
because
it's
somewhat
changes
or
in
updates
58
84
with
the
new
mode
send.
A
Thirdly,
this
chamber,
okay,
so
the
video
working
group
is
now
completing
its
work
on
busy
for
multi-point
networks,
or
we
can
call
it
beef
D
for
point-to-multipoint
and
broadcast.
So
this
is
start
on
investigating
applicability
of
b
FD
for
multi-point
networks
to
point
to
multi-point
and
to
LS
LS
B's.
A
A
Normally
in
VFD
therapy
of
the
RFC
58
80
there
de
multiplexing
is
done
by
locally
allocated
ma.
You
are
identifier,
so
basically
the
value
that
comes
to
the
node
in
your
discriminator
field.
That
would
be
locally.
A
unique
identifier
discriminator
because
such
is
missing
is
absent
in
point-to-multipoint.
A
Version
there
needs
to
be
some
other
fields,
so
what
multi-point
PFD
suggests
that
it's
turned
by
source
IP
address
discriminator
that
is
assigned
by
there
rude
and
identity
of
their
interface.
It
was
received
so
that
sets
some
interesting
restrictions
on
what
we
can
do
with
the
point-to-multipoint
and
ALS
yes,
and
actually
there's
some
change
in
obviously
state
machine,
because
their
session
is
viewed
as
up
all
the
time.
A
So
the
one
possibility
is
use,
IP,
UDP,
encapsulation
and
then,
as
described
in
RFC,
58
84.
So
for
ipv4
we
use
IP
address
destination
from
127,
/,
8
range
and
or
for
ipv6,
so
another
Martian.
So
we
use
a
destination
UDP
port
assign'd
for
multi
point
BFD
and
the
source
UDP
port
should
be
selected
from
dynamic
port
range.
A
Is
it
possible
to
use
non
IP
encapsulation
because,
frankly,
with
a
very
small
army
of
the
control
packet
size
waste,
especially
our
ipv6
and
ipv4?
Ipv6
is
kind
of
waste
it's
possible.
But
we
need
to
remember
that
there
is
a
requirement
for
multi
point
for
BFD
for
multi
point
networks
to
have
association
to
be
able
to
associate
each
PFD
control
packet
with
a
source
IP
address.
So
the
proposal
here
is
to
use
encapsulation
with
a
CV
channel,
possibly
reuse,
existing
channel
and
then
use
new
source
map.
Id
IP
address
till
TLV.
A
That's
basically,
the
channel
already
been
allocated
for
imperil
STP.
It
uses
it
has
a
registry
of
map,
ID
TVs,
but
it
doesn't
have
I
P
address.
Our
TLD
is
a
source
map
ID
so
and
bootstrapping
might
be
done
either
using
LSB
ping
or
multicast
VPN
fast
upstream.
Failover
has
very
nice
proposal
are
to
use
DGP
BFD
attribute
to
inform
the
leaf.
That
is
a
member
of
the
particular
multi-point
video
session.
I
think
that
there
needs
to
be
done,
some
enhancement
to
the
GPB.
A
A
B
D
F
F
This
was
needed
because
we
can
have
the
same
label
appearing
the
lists
multiple
times,
so
we
have
to
have
an
e
distinguisher
in
there
in
the
list
we
did
meet
with
authors
of
rib
extended
model.
We
think
this
model
has
some
intersection
with
with
MPLS
rib
model
and
we
discussed
with
them
moving
some
of
the
things
that
we
defined
in
MPLS,
because
they're
generic
and
applicable
to
IP
world,
and
they
agreed
to
do
so
so
I'll
go
over
the
agreed-upon
changes.
F
The
first
item
we
updated
is
the
MPLS
label
stack
as
I
mentioned,
and
we
introduced
this
index
the
index.
So
there
was
a
discussion
on.
Should
we
use
the
index
as
an
offset
in
the
label,
stack
we're
talking
about
a
an
ingress
or
a
anode,
pushing
a
number
of
labels,
and
we
are.
We
are
listing
those
labels
indexed
by
a
number,
so
should
this
number
be
equivalent
to
the
offset
in
the
label
stack
so
yang
defines
two
modes
of
ordering
a
list:
either
user
user
ordered
or
system
ordered
a
user
ordered.
F
Basically,
the
way
they
appear
in
configuration
is
the
way
that
the
labels
will
be
slapped
on
the
packet
or
pushed.
So
the
index
is
not
of
relevance
then,
but
the
order
appearing
in
per
figuration.
As
if
we
go
with
this
approach,
then
we
can
always
insert
after
or
before
an
item
or
even
remove
after
and
before.
If
we
use
a
system
ordered
list,
then
the
system
can
choose
any
ordering
that
they
see
fit
the
order
of
configuring.
F
The
labels
is
not
of
importance,
they
can
sort
using
the
index
and,
let's
say,
for
example,
the
index
is
not
consecutive
or
contiguous.
They
can
sort
it
by
index
and
generate
an
offset
off
of
that
and
and
produce
the
label
stack.
So
obviously,
every
time
we
add
a
label
in
that
list,
the
the
back
end
has
to
do
some
sorting
to
produce
the
final
set
of
labels
to
either
push
or
update
on
the
packet.
So
these
are
two
modes
that
we
we
try
to
discuss.
F
Some
are
favorable
of
using
the
index
as
an
offset
I.
Think
I
spoke
about
that.
The
the
the
issue
is
you
wave
using
the
index
as
an
offset
is
if
I
configure
an
index
number
two.
There
must
be
a
check
that
a
previous
label
at
index
one
is
existent
because
you
can't
slap
a
at
offset
number
two
without
having
a
label
before
that.
So
there
is
some
additional
verification.
This
needs
to
be
done.
F
F
So
the
MPLS
routing
types
yang
model
has
the
find
an
MPLS
label
stack.
They
have
defined
an
encoding
which
exposes
the
TTL,
the
traffic
control
and
the
label
value.
So
basically
they
exposed
the
whole
label
when
trying
to
configure
a
label
stack.
So
we
wanted
to
have
a
discussion
on.
Should
we
allow
specifying
TTL
for
non
top
label
for
every
label
in
the
stack
that
we're
trying
to
push?
Should
we
allow
a
specifying
traffic
control
or
traffic
class
per
label
I'm
Greg?
Do
you
want
to
ask
you
a
question
now.
A
I
A
F
F
So
back
to
the
label
encoding
of
entries
in
the
list
we
currently,
we
are
showing
the
label
values
in
the
label
stack
and
on.
The
previous
slide
here
is
composed
of
label
value
increase.
Only
no
TTL
or
traffic
classes
allowed
to
be
added,
but
the
routing
type,
as
I
mentioned,
is
defining
this
grouping
that
exposes
label
value,
TTL
and
traffic
class.
F
Now,
if
we
allow
traffic
class
to
be
configured
on
on
anything
be
on
the
top
label,
then
there
is
some
intersection
with
RCS
defined
for
the
short
pipe,
the
pipe
and
the
uniform
pipe
model
for
the
TTL,
as
well
as
the
traffic
class.
This
is
applicable
at
this
position
time,
as
well
as
in
position
time.
I.
D
E
F
F
F
F
F
A
F
A
F
F
F
I
Job
Brendan
can
I
do
three
shows
of
hands
who
was
in
the
RTG
no
dude
the
other
way
around.
Who
was
not
in
the
RTG
WG
meeting
earlier
good,
that's
no
hands
went
up
who
was
not
in
the
first
MPLS
session,
where
draft
shoe
unified
thingy.
So
that's
about
Oh,
that's
about
ten
people.
Okay,
so
Stuart
had
some
of
this
material
in
his
slides
in
RTG
owg
and
as
an
overlap
with
the
draft
shoe
that
was
in
the
first
session.
So
this
is
the
last
thing
slot
I'm
offering
third
show
of
hands.
I
I
I
There
is
a
already
a
port
allocate
a
UDP
destination.
Port
already
allocated
for
the
payload
is
MPLS.
That's
what
7510
does
so
in
a
little
more
detail.
You
see
from
the
bottom
upwards.
The
payload
is
entirely
unchanged.
You
just
pick
up
the
payload
and
drop
it
underneath
a
an
MPLS
CID
stack
just
like
if
you
were
doing
MPLS
SR
and
you
drop
that
itself
into
a
UDP
header,
just
like
the
Iridium
75
10,
and
then
on
top
of
that
you
put
the
IP
header
to
get
you
across
the
network.
I
You
set
a
source
to
the
sending
s
are
capable
node,
in
other
words,
the
person
doing
this
encapsulation
you
set
the
destination
to
the
next
s
are
capable
now,
because
it's
going
to
process
the
sit
stack
and
you
set
that
pro
to
the
next
protocol
to
UDP,
of
course,
so
SIDS
get
advertised.
There
is
no
change
to
the
way
the
suits
are
advertised
and
configured
at
etcetera,
etc,
etc.
I
This
is
just
the
SR
piece
is
just
SR
and
we
believe
that
all
sit
in
this
way
unless
there's
nothing
new,
so
I
have
three
slides,
say
who
does
what?
In
the
network,
the
source
builds
the
SR
stack
just
like
it
was
a
an
SR
node.
It
encapsulates
setting
the
fields
as
I
just
described
in
UDP
and
then
in
IP.
I
The
little
wrinkle
is
that
to
set
the
destination
address,
you've
got
to
look
at
the
top
CID
in
the
stack
and
say
where
am
I
trying
to
get
to
and
map
that,
but
you
can
take
that
mapping
out
of
the
advertisement
and
then
you
once
you've
encapsulated
you'd,
look
up
and
send
so
it
looks
really
like
7510
with
how
do
I
decide
what
the
end
end
of
my
tunnel
is.
Being
I,
look
up
a
CID.
I
So
if
you're
a
transit
and
you're
not
sr
processing,
it's
pretty
important
that
we
can
get
these
packets
through
nan
SR
nodes
and
that's
fine
if
it's
their
IP
packets
and
they
just
go
no
special
processing,
tour
and
ecmp
where
it
exists.
You
get
using
the
entropy
in
the
source
port,
just
like
7510
TTL
behaves
as
normal.
It's
an
IP
packet
if
you're
a
transit,
SR
node.
I
Well,
there
are
two
things:
if
it's
addressed
to
you,
you
need
to
work
on
it.
If
it's
not
addressed
to
you
and
your
SR,
capable
you
don't
touch
the
packet,
it's
just
an
IP
packet
being
routed
through.
So
if
it
is
addressed
to
you,
you
look
at
the
packet,
you
go.
Oh
it's
UDP!
Oh
it's
MPLS!
In
UDP,
now
I,
look
at
the
SR
stack.
That's
in
there.
I
I
get
the
next
hop
and
now,
from
now
on,
I
behave
just
like
headed
at
the
ingress
I
clapper
said
to
find
the
IP
address
from
the
next
hop
and
I
encapsulate
again.
Look
it
up
and
send
so
a
transit
is
effectively
doing
the
same
work
as
an
ingress
so
to
use
case
pictures
they
are
just
checking.
The
colors
came
out.
Okay
at
the
top
use
case
is
where
this
work
sort
of
started,
which
is
tunneling
between
two
domains.
The
way
7510
is
talking
about
it
and
your
yourse.
I
I
We
think
that
actually,
this
work
is
pretty
obvious.
I
think
one
of
the
comments
we
got
offline
was
yeah.
This
is
just
virtual
interfaces
and
you're
sending
packet,
and
yes,
that
is
exactly
what
it
is-
we're
just
a
little
bit
of
help
to
say
when
you
send
it
out
the
virtual
interface.
How
do
you
know
which
virtual
interface
to
send
it
to?
I
F
K
H
I
I
We
weren't
on
the
agenda
for
the
spring
meeting
this
time
round,
for
obvious
reasons,
obviously
as
to
the
fight
about
where
it
ends
up
being
adopted
and
worked
on
yeah.
Whatever
I
mean
we're
not
actually
changing
the
the
spring
data
play
and
we're
just
doing
an
MPLS
encapsulation,
but
I'm,
not
religious,
about
spring.