►
From YouTube: MPLS WG Interim Meeting, 2020-05-07
Description
MPLS WG Interim Meeting, 2020-05-07
A
A
We
will
be
giving
a
a
couple
of
updates
for
documents
in
the
upcoming
slides
those
documents
we
didn't
give
update
for,
or
we
had
missing
progress
report
in
the
first
meeting
that
we
had
and
this
time
we
have
the
reports
loa
has
promised
to
give
the
updates
it's
a
bit,
there's
a
bit
of
irony
in
there
in
the
report,
so
I
want
him
to
talk
about
it.
Lo
are
you
still
tuned
in.
A
C
A
A
A
The
current
editor
is
not
yeah
he's
admitting,
basically,
that
he's
not
fit
for
the
job,
so
that's
lower.
I
think
I
think
at
least
so
there
are
some
should
implications
to
resolve
and
the
the
there
are.
There
is
some
text
in
the
in
the
document
and
it
should
be
clarified
if
there
is
additional
text
needed
around
the
should
implications.
A
The
the
draft,
as
is,
proposes
mixing
the
experimental
and
private
spaces.
I
think
the
private
is
to
be
kept.
Oh
sorry,
the
experimental
is
to
be
kept
in,
the
private
will
be
merged
in
the
experimental,
but
but
I
think
there
is
no
conclusion
of
conversions,
so
the
working
group
chairs
are
working
on
a
proposal
for
a
consensus,
and
this
this
will
be
driven
by
the
chairs
over
an
email.
That's
my
understanding
at
least
that's
correct.
D
A
E
B
A
A
All
right:
okay,
okay,
we
we
have
two
two
documents
to
report
on
as
well.
The
spl
terminology
it
received
it
was
in
working
group.
Last
call
received
some
comments.
We
expect
a
new
revision
to
be
published
that
address
the
comments
that
were
received
and
we
expect
the
working
group
last
call
to
be
closed
next
or
actually
it
might
be
closed
already.
That's
my
understanding
from
nick
and
the
shepherd
will
prepare
a
write-up
next
in
preparation
for
the
publication
to
proceed.
A
F
A
F
H
D
D
D
D
I
I
D
Yeah,
I
agree
with
you,
so
if
we
can,
if
it's
necessary,
we
can
have
some
more
extension
to
such
as
igp
or
bgprs,
so
we
can
use
that
to
advertise
the
such
as
the
flow
id
esp
support
ability,
but
I
think
for
the
application
scenario.
Currently
we
can
use
the
configuration
I
mean.
Maybe
we
can
use
the
network
management
system
to
configure
the
node
on
the
capability
so
that
it
knows
if
it
can
support
the
flu
labor
through
id
labor,
so
that
maybe
works
at
this
moment.
D
A
C
J
So
this
the
name
of
the
draft,
has
been
changed
to
reflect
to
mpls
working
group
so
before
it
was
a
spring
working
group
document,
so
the
version
is
changed
to
0
0
after
the
name
change
next
slide,
and
also
with
this
we
are
covering
so
the
draft
was
named
inter
a
s
and
we
change
the
name
to
inter
domain,
because
the
same
solution
is
applicable.
When
you
know
multiple,
I,
the
network
network
consists
of
multiple
igps
and
the
end-to-end
path
is
built
using
either
label
stacking
or
mechanism
such
as
bgplu.
J
J
J
J
G
I
J
Yeah,
so
this
use
case
is
specific
to
a
single
operator
who
is
owning
all
the
domains
and
want
to
run
an
end-to-end
mpls
ping
entries
route
so
security
perspective.
So
we
can
so.
The
ping
is
in
this
particular
example,
the
thing
or
the
next
slide.
We
can
see
the
trace
route,
it's
not
visiting
the
internal
nodes
in
the
domain,
if
it,
if
it
is
not
allowed
to
so
that
will
be
decided
by
whether
the
border
routers
will
propagate
the
ttl
or
not.
J
J
J
J
As
an
mpls
packet
with
one
zero
one
zero
as
the
top
label
and
in
the
addition,
it
will
include
its
own
nodes
on
the
top
in
the
reverse
path
segment
list.
If
you
see
the
abr3
is
sending
reverse
path
segment
list
with
one
zero,
three
zero,
its
own
node
fit
on
the
top,
and
then
that's
how
the
trace
route
continues.
So
the
next
trace
echo
request
from
the
pe
one
will
have
the
reverse
path
segment
list,
consisting
of
one
zero,
three
zero
and
one
zero
one:
zero!
J
So
we
have
added
clarification
in
the
document
and
there
were
also
some
questions
with
respect
to
ipv4
and
ipv6
sits
being
used
together,
and
then
we
have
added
clarification
that
if
we
have
a
network
which
is
you
know
like
core,
is
pure
ipv4
and
then
metros
are
pure
ipv6
networks.
In
this
such
cases,
we
will
not
be
able
to
run
mpls
ping
and
trace
route
end
to
end.
That
is
out
of
scope
of
this
document.
J
A
I
I
J
I
J
H
H
Slideshow,
it's
good!
Thank
you.
Okay.
This
draft
aligns
the
the
problems
problem
statement
when
the
signal
degrade
needs
to
be
detected
and
indicated
in
the
segment
routing
of
over
mpr's
network,
so
the
yeah
okay.
So
what
what
is
the
definition
of
signal,
failure
or
signal
degradation
signal?
Failure
is
is
regarded
as
as
absence
of
the
network
resources
it
is
because
of
the
the
physical
function
and
availability
of
port
or
link
or
the
equipment.
H
And
meanwhile
the
signal
degradation
is
a
kind
of
that
is
a
quantifiable
decrease
of
the
signal
quality
and
it
results
from
the
the
fiber
impairment
or
the
wdm
transmission
arrow,
so
signal
degradation
can
be,
can
be
described
like
a
transition
face
the
equipment
or
the
link
is
not
totally
shut
down,
but
the
quality
is
the
detail:
real
deteriorated,
okay
and
next
slide,
please,
okay!
So
let's
see
what
it
was
in
in
history
and
what
we
should
do
in
future.
H
It
specified
the
protection,
switching
particle
associated
with
signal
failure
and
rfc
7271
introduced
five
capabilities
of
the
linear
protection
used
for
used
in
npr's
tp
network,
and
one
of
the
capabilities
is
the
support
of
the
protection
against
to
against
to
signal
degradation,
and
we
also
found
there
are
two
other
internet
drafts
from
from
other
authors
shares.
The
similar
idea
describes
the
the
signal
degree,
degradation
detection
at
the
at
the
lsp
or
software
level,
and
also
specify
this
the
protection
mechanism.
H
It
is
a
fact.
The
fact
is
that
the
signal
degradation
is
not
mentioned
in
any
draft
of
these
in
any
draft
of
sr,
amperes,
oem
or
vfd
mechanisms.
So
we
believe
it
is
valuable
to
investigate
the
necessity
of
the
support.
The
necessity
of
supporting
signal
degrade,
degrading
signal,
degrade
detection
and
triggering
the
relative
protection
mechanisms
in
sr
ampere's
networks.
H
D
H
Active
pm
is
not
always
online
and
the
passive
pm
consume
too
much
network
resources
so
so
far
if
they
are
not
feasible
and
efficient,
and
the
third
one
is
the
we
found
that
fault
management
does
not
seem
to
be
good
enough
for
the
for
the
detection,
for
example,
the
bfd
in
and
the
the
signal
degradation
is
not
detectable
in
the
sp
in
the
bfd
case,
because
the
signal
degradation
may
cause
the
quality
deteriorate
and
make
okay.
Because
the
signal
degrade
degradation
doesn't
mean
there
will
there
will
be
a
packet
loss
so
there.
H
H
And
but
we
think
that
the
lower
layer,
the
lower
layer,
fault
management,
like
the
oem
alarms,
might
be
an
option
to
to
detect
the
the
signal
degradation.
But
there
are
there's
also
issues
because
they
they
they
use
different
parameters
in
different
layers
and
and
we
think,
compared
to
the
mpst
and
the
lsr
routers
in
me.
K
A
I
A
I
Okay,
thank
you.
It's
very
interesting
and,
as
you
said,
I
think
that
we
have
some
history
discussing
this
and
if
my
recollection
is
correct,
the
reason
why
it
was
not
followed
on
and
nothing
exists
is
that
there
was
seen
the
benefit
of
following
layered
architecture
and
networking
and
matching
it
with
a
layered
oem
approach.
I
L
I
Sometimes
we
have
a
different
name
for
it,
but
we
have
been
discussing
their
extended
bfd
draft
and
extended.
Bfd
draft
has
new
capabilities
added
to
the
fault
management
so
effectively,
making
it
a
swiss
knife
from
oam
and
giving
bfd
performance
monitoring
capabilities,
but
again
it's
not
necessarily
bfd,
but
fault
management
protocol
with
edit
performance
monitoring
capabilities.
H
Yeah,
I
I
totally
agree
with
you
about
the
the
different
layers.
Actually
they
have.
The
different
layers
should
take
care
of
the
the
issues
inside
within
this
layer,
but
we
see
there
are.
There
are
different,
I
mean
different
kinds
of
of
lower
layer,
design
or
low
layer
network,
sometimes
that
the
the
the
lower
layer
doesn't
take
care
of
the
of
the
issues
of
the
signal
degradation
at
this
added
it
on
layer.
So
with
we
see
there
is
a
there.
H
So
we
we
think
that
it
should
be
it
it.
It
is
the
different
layer,
the
the
relation
between
different
layers
is
not
strictly
isolated
and
also
there.
There
are
also
I,
if
I
remember
correctly,
there
are
also
other
working
group
and
they
define
the
the
the
some
unified
oem
mechanism
to
to
go
across
the
different
layers.
So
we
we
want
to
bring
this
topic
and
we
we
want
to
know
that
the
first
steps
we
want
to
express
that
there
is
a
requirement
to
to
to
ask
for
the.
H
Ask
for
the
behavior,
as
for
the
the
the
things
that
should
be
done
in
this
case
and
the
second,
we
want
to
know
how
people
think
this
problem
should
be
should
be
how
they,
how
they
think
this
problem
should
be
solved.
You
know
we,
actually.
We
would
like
to
discuss
that.
The
the
general
picture
that
how
how
we,
how
we
should
deal
with
the
problem
like
this.
C
A
Next
question
is:
I
think
that
why
was
next?
This
is
tariq
and
the
first
part
of
my
question
I
think
greg
asked
put
it
put
it
exactly
in
a
good
way
in
a
layered
network,
you
would
want
to
handle
events
detected
within
the
layer
faults,
for
example,
and
not
unusual.
This
is
usually,
but
you
have.
Maybe
you
have
a
case
for
propagating
faults
up
and
in
the
layer
stack,
that's
fine.
A
We
can
take
that
discussion
and
forward,
but
my
second
comment
is
the
last
bullet
on
your
next
step.
Claims
that
you
know
this
is
specific
to
sr
and
pls,
and
my
understanding
is
sr
pls
sr
is,
is
just
a
signaling
control,
plane,
signaling
mechanism,
so
whatever
scheme
your
or
whatever
benefits
you're,
seeing
with
with
this
approach,
might
carry
over
to
other
signaling
mechanisms.
H
Yeah,
I
understand
your
question.
Actually
we
we
actually
have
showed
that
there
is
a
history
that
they
they
have
a
similar
design
in
the
mpls
tp
network,
and
we
think
that
actually,
it's
not
so
specified
to
actually
this
this
issue.
This
problem
is
not
specified,
it's
not
only
special
as
our
mprs
it's
actually.
It
is
true.
H
It
should
be
taken
in
the
in
the
general
npr's
data
plane,
but
we,
but
we
think
that
it's,
no,
it's
not
so
valuable
to
to
work
on
a
whole
whole
general
solution
for
all
the
for,
for
the
for
the
for
all
the
different
types
of
mpls
different,
different
different
types
of
the
mps
data
plane-
and
I
think
the
sr
sr
is
the
is-
is
the
popular
as
the
sr
is
the
popular
npr's
data
plane
and
they
use
ren
nowadays.
So
we
think
that
is
yeah
it
is.
H
K
Part
of
the
discussion
point
is
that
you're
looking
for
enough
degradation
that
you
can
consider
the
event
a
hard
trigger
to
take
some
action
like
protection
degradation
itself.
If
it's
reported
in
sort
of
a
sliding
scale,
you
know
rather
than
a
binary
thing
or
if
a
floating
point
type
thing
is
useful
for
telemetry
purposes,
even
if
it's
not
quite
ready
to
be
used
as
a
trigger.
K
So
a
common
example
is
you're
having
degradation
of
a
link
due
to
laser
problems,
and
that
may
show
up
as
an
example
at
the
forwarding
error
correction
layer
as
increased
numbers
of
thickers
reporting.
These
things
up
the
stack
is
helpful
because
it
lets
you
see
in
your
network
that
you
might
have
an
outage
impending.
K
H
A
F
F
F
So
p2mp
transport
has
been
a
challenge
in
second
routing,
mainly
because
segment
routing
is
built
on
a
model
of
stateless,
core
and
single
point
provisioning
at
ingress,
routers.
So
to
do
a
p2mp
transfer.
Today
we
have
to
use
ingress
replication
where,
in
order
to
reach
x
number
of
leave
nodes,
we
have
need
to
use
x,
number
of
p2p
tunnels.
F
An
alternative
approach
would
be
to
use
a
control,
you
know
controller-driven
pcmp
trees.
This
approach
can
achieve
maximum
traffic
optimization,
but
it
requires
the
controller
to
dynamically
provision
or
manage
so-called
replication
segments
or
branch
nodes.
These
replication
segments
are
essentially
per
you
know:
p2
and
v3
stay
on
transit
routers,
so
your
coordinator
will
not
be
status
anymore.
It
will
become
stateful
and
also
this
approach
require
requires
some.
You
know,
communication
channels
between
your
controller
and
transit
routers,
which
may
not
be
you
know,
always
be
possible
in
some
networks.
F
F
A
F
J
F
F
F
So
in
this
draft
we
model
this
special
kind
of
processing
on
a
transit.
The
node
as
a
a
new
type
of
segment
called
the
bot
segment
and
the
set
of
a
bar
segment
is
called
a
bicep
so
and
then
a
p2m
chain
basically
becomes
a.
You
know
a
list
of
sets
with
both
sets
of
the
transit
lymph
nodes
in
their
corresponding
positions
in
in
the
sydney
slide.
Please.
F
F
So
we
will
talk
later
that
you
know,
bot
seconds
are
very:
are
a
routable
segment
in
a
very
similar
manner.
As
note
6
note
segments,
the
green
chain
goes
to
l3
and
l4.
It's
taking
some.
You
know
explicit
path
and
then
siblings,
basically
consists
of
you
know
a
sequence
of
adjacency
set
followed
by
b3,
which
is
the
bot
set
of
l3,
and
then
you
know
a
sequence
of
adjacencies
to
the
to
the
tail
end.
L4.
F
The
node
f
is
a
receiver.
It's
a
leave.
Node
of
both
streams.
Therefore,
its
bot
set
appears
in
the
second
list
of
both
red
ring
red
chain
and
green
chain.
So
this
basically
shows
that
in
both
segments
are
common
segments
that
are
completely
shareable
by
all
multicast
streams
and
the
p2mp3
chains
next
slide.
Please.
F
F
F
This
shows
the
generic
you
know,
general
forwarding
flow
of
a
bot
segment,
so
the
incoming
packet
is
p
and
the
active
set
of
packet
happens
to
be
the
bot
set
of
the
current
node.
So
what
we
do
is
that
we
replicate
p
to
make
a
copy
p1,
okay,
so
for
p
we
like
to
forward
downstream,
so
we
perform
next
on
the
bot
sit
and
then
we
forward
p,
based
on
the
next
sit
on
the
packet
for
the
red
car.
The
the
the
copy
p1
we'd
like
to
you
know,
process
it
locally.
F
F
F
So
here
when
we
in
some
cases
the
packet
may
have
a
service
label.
So
we
need
to
be
very
careful
when
we
pop
the
p2mp
chain
labels.
We
need
to
know
where
you
know
if
there's
a
service
label
in
the
packet.
So
in
that
case
here
we're
using
a
special.
You
know,
extended
special
purpose
label
called
the
end
of
chain
label.
F
We
insert
that
label
between
the
service
label
and
the
ptml
chain
labels.
So
when
we
do
the
popping
we're
going
to
pop
the
chain,
labels
and
the
eoc
label
and
then
we'll
leave
the
service
label
with
the
package
for
local
processing,
if
the
pack
doesn't
have
a
service
label,
then
we
just
you
know
pop.
F
A
A
K
A
F
A
A
A
L
L
So
let
me
go
to
the
next
slide,
so
just
a
quick
recap
reminder
for
a
current
status
for
mldp
yang
draft.
This
draft
has
gone
through
young
director
doctor's
early
review.
We
had
addressed
all
the
comments
from
ac
who
did
a
very
good
job
with
the
with
a
detailed
review
in
revision.
Five,
the
document
went
through
working
group
last
call
and
ipr
pearl
in
in
last
fall,
and
we
had
received
some
working
with
blasphem
called
comments
from
some
of
the
working
group.
L
L
So
ldp
mldp
yang
augments
ldp,
so
it
has
a
strong
dependency
in
ldp
yang.
So
last
few
months
or
focus,
the
team
is
actually
the
team.
Mostly
it's
the
same
team
that
working
with
both
ldp
and
mldpn.
So
our
focus
has
been
to
push
an
ldp
yank
to
isg
for
rfc
publication.
Address
all
the
comments
that
we
received
from
yank
doctors,
area,
doctors,
doctrine
and
gen
art
review
comments.
L
Mldp
right
after
ldp
has
basically
ldp
has
become
stable
at
isg
level,
so
that
is
the
current
status
of
mlepn,
given
that
it
has
a
strong
dependency
on
ldp
and
so
next
slide
or
two
I'm
gonna
just
quickly
talk
about
lep
young
and
then
finish
with
the
mlb
and
the
next
steps,
so
ldp
yang
status,
thanks
to
from
working
group
chairs
and
dr
mcshefford.
Thank
you
area,
director,
deborah
and
isd
reviewers.
The
draft
is
now
proposed
standard.
It
is
right
now
in
rfc
editor
queue.
L
However,
I
think
it's
going
to
stay
there
for
a
little
bit
because
of
this
reference.
We
have
a
dependency
on
routing
working
group
policy
model
and
I
was
told
that
this
model
basically
is,
is
about
to
get
to
working
with
last
call
after
they
have
addressed
the
younger
kazoo.
So
I
expect
a
little
yank.
You
know
to
stay
in
this
this
state
for
for
a
little
bit,
but
we
don't
plan
to
make
any
change.
It's
already
ready
for
publication.
L
So
what
did
we?
You
know?
What
did
we
do
with
all
the
yang
in
last
couple
of
months?
That
most
of
it
also
applies
to
an
ldp
act
that
you
have
to
do
there
are
there
are
some
I'm
only
capturing
the
major
comments
here?
There
are
minor
comments
as
well.
The
major
things
that
you
have
to
change
in
lap
was
to
define
your
own
identity,
ordinary
for
ldp
protocol,
so
we
picked
mldp,
and
but
we
have,
we
constrained
this
to
a
single
instance
from
day
one.
L
Our
scope
as
a
highlighted
document,
was
first
given
instance,
ldp
or
mldp.
There
were
quite
a
bit
of
discussion
and
debate
over
why
ldpipv6
is
not
in
a
base
model,
because
we
have
two
models
in
our
yank
based
and
extended.
So
there
was
an
explanation
that
that
we
have
given
in
the
document
itself,
as
well
as
on
the
email
exchange
that
yldp
v6
was
non
not
considered
as
an
ace
feature.
So
same
thing
will
apply
for
an
ldp
and
there
are
examples
which
we
did.
L
There
are
comments
about
security
sections
and
that's
about
to
really
pinpoint
actual
vulnerable
and
sensitive
items
from
from
yang
and
manageability
perspective,
so
that
section
was
enhanced
significantly
during
isg.
There
were
a
few
other
comments
which
were
made
on
ldp
draft,
but
they
are
really
beyond
ldp's.
You
know
addition.
It
was
more
like
a
routing
label
comments,
for
example,
why
we
are
using
md5.
Can
we
not
use
crypto
algorithm?
L
Why
md5
key
has
to
be
string
and
this
and
that
why
we
cannot
do
this
for
filtering
policy
and
routing
policies?
So
so
we
were
just
complying
to
what
itf
routing
working
group
base.
Charts
have
specified
and
we
are
just
augmenting
them,
but
we
still
address
some
of
those
comments
to
the
best
of
our.
You
know
compromising
capability,
so
we
we
extended
our
password
authentication
to
have
any
cryptal
go
algo,
including
mp5.
L
Their
discussion
about
containers
presence
was
just
labeled
and
all
this,
and
then
then,
and
basically
request
to
simplify
the
document
through
a
single
tree,
you're
complying
to
an
mba
and
there
were
lots
of
nationalities
to
fix.
So
that
was
a
lot
of
commenter
led
yang
and
last
few
months
we
made
sure
that
we
have
just
all
of
those
or
reply
and
close
close
with
our
usgs.
L
L
The
routing
policies-
and
you
know
other
other
alignment
with
ldp
so
having
you
know,
state
all
this
so
for
mldp.
Our
next
step
is
really
to
align
for
mldp
model
with
ldp
model
changes
that
we
already
done
as
we
as
we
speak.
We
are
already
working
on
this.
We
wanted
to
have
a
draft
posted
before
this
session.
L
We
could
not
meet
the
deadline,
but
within
a
week
we
we
are
planning
and
hoping
to
submit
a
draft
that
will
address
most
of
the
comments,
similar
comments
that
led
had
so
and
then
we
hope
that
this
will
make
mldp
yang
progress
smoother
than
ldp
yank,
because
lots
of
comments
we
have
already
addressed
upfront
because
it
goes
really
soon.
So
our
plan
is
to
basically
now
apply
its
extending
on
an
led,
yank
and
submit
within
read
now
one
question:
personally,
I'm
confused
after
having
done
that.
L
Mldp
has
already
went
to
work
in
the
class
call.
So
after
making
those
changes,
which
will
be
a
bit
significant,
do
we
think
that
we
need
to
reissue
what
we
would
call
again
on
this
objective
revision
of
the
ldp?
That
will
be
there
in
a
week
or
so
the
question
for
chairs
and
working
group
we
are
asking,
but
from
our
side
we
are
okay
either
way,
I
think
that's
my
last
slide.
Sorry
any
questions,
any
comments,
and
especially
on
my
last
question,
to
the
working
group
and
cheers.
A
C
L
I'll
just
respond
first,
so
yes,
the
working
glass
call
happened
last
september
and
finished
in
october.
That
was
revision.
Five
revision.
Six
is
just
a
reception.
There's
no
change,
but
revision.
Seven
is
gonna.
Post
will
address
all
the
key
comments,
so
it
will
be,
it
will
be
a
bit
of
delta.
So,
yes,
it
will
not
be
smooth.
Minor
changes
are
in
there.
So
yeah
I
I
would.
B
M
C
A
C
I
C
I
Okay,
so
what
what's
the
motivation
point
to
multi-point
lsps
or,
as
we
discussed
today
earlier
and
segment
running
srm
pls
to
stay?
We
have
two
rfcs
published
for
bfd
for
multipoint
networks
and
existing
solution.
Vfd
or
for
mpls
does
not
apply
to
point
to
multiplied
case,
as
the
case
for
sbfd
does
not
apply
to
multi-point
lsps
next
yep.
I
You
want
to
skip
this,
no
I'll
go
quickly,
so
bfd
for
multi-point
networks
uses
demand
mode
and
the
multiplexing
session
is
different
from
their
asynchronous
mode,
and
thus
there
are
some
explanation
in
published
rfcs
so
that
the
receiver
of
the
control
message
uses
three
tuple,
which
includes
my
discriminator
information,
source,
address
and
identity
of
multiple
point.
Three
next
slide.
I
I
I
I
I
I
But
there
is
no
mechanism
defined
in
this
rfc
how
the
ingress
or
head
can
be
notified.
So
this
is
what's
being
defined
in
rfc
8563
and
it
outlines
three
methods,
so
they
had
a
notification
and
telstra
solicitation
with
a
multi-point
following
where
the
poll
messages,
which
is
a
bfd
control
message
with
the
paul
bit
set
being
sent
over
the
multicast
distribution
tree
and
then
the
tails
responded.
I
Over
the
unicast
path,
with
the
final
bit
set
and
had
notification
with
a
composite
polling
where
this
head
combines
multi-point
polling
with
their
directed
unicast
polling,
that
is
send
on
disjoint
path
from
the
multicast
distribution
tree.
So
all
these
two
methods
are
well
defined
in
rfc
and
documented
in
rfc
8563.
I
So
that's
just
to
outline
how
it
operates
so
in
red,
so
this
is
a
multicast
distribution,
three
and
multicast
paul
from
their
ingress
pe
one.
They
are
transmitted
over
their
distribution,
three
to
tails,
the
ingresses
p,
four
five
and
six,
and
they
in
turn
send
back
unicast
final
to
p1
over
their
blue
line.
I
I
A
A
J
G
M
A
M
M
So
when
we
boil
this
down
to
you
know
the
the
verification
or
the
oem
part.
You
know
it
requires.
Defining
and
implementing
different
types
of
you
know
targeted
sec
stack
for
each
of
those
sets,
which
introduces
quite
a
few.
You
know,
scalability
challenges
in
terms
of
you
know
different,
defining
differences
and
then
implementing
then
requiring
a
domain
wide
or
you
know
a
node-wise
software
upgrade.
So
that's
the
problem.
I
know
we
are
trying
to
solve.
M
M
So
it's
not
only
about
you
know,
defining
and
implementing,
but
also
from
the
challenges
in
terms
of
you
know
how
we
use
it.
For
example,
the
initiator
is
now
required
to
collect
a
lot
of
information
for
different
types
of
segment
ids
and
include
that
in
the
lsp
echo
request
and
on
the
other
side,
that
the
responder
is
required
to
look
into
absolute
amount
of
data.
M
That's
received
in
the
echo
request,
processor
and
you
know,
responded
back
so
we
took
one
step
back
to
see
if
there
is
a
a
more
generic
way.
Instead
of
you
know,
defining
a
targeted
species
set
for
each
and
every
set.
Is
that
a
generic
way
that
we
could
solve
it?
And
that's
what
you
know
we
did
it
here.
M
The
solution
basically
defines
one
generic
method
or
one
generic
targeted
efficiency
stack
subtly,
which
basically
carries
the
segment
id
alone
from
the
effect
pro
validations
point
of
view.
We
basically
use
the
responder
or
the
validator
will
use
the
incoming
segment
id
in
the
targeted,
fcc
stack
and
perform
two
types
of
check.
One
is:
is
it
the
lsp
endpoint
for
that
particular
segment
id
and
did
it
receive
it
from
the
right
incoming
interface?
So
we'll
see
how
in
a
couple
of
slides?
M
M
So,
in
our
case,
node
one
is
the
initiator
which
generates
the
echo
request
and
include
the
set
that
needs
to
be
validated,
which
will
be
the
same
set
that
will
be
included
in
the
data
plane
header
for
a
moment.
Let's
assume
that
that's
the
default
algorithm,
which
is
16008,
so
this
value
will
be
included
in
the
echo
request
and
the
packet
will
be
forwarded
and
the
note
8
when
it
receives
it,
uses
this
information
to
check.
M
If
the
lfc
endpoint
is,
you
know,
node
8,
which
is
pretty
straightforward
for
prefix.
It
basically
needs
to
check
if
you
know
it's
the
owner
of
that
particular
prefix
set
and
then
two
it
performs
a
check
about
you
know,
did
it
receive
it
on
the
right,
the
incoming
interface,
for
example?
If
it
is
a
default
set,
or
you
know,
flex
algo
said
it
basically
will
check
if
it
receives
the
probe
on
an
interface
which
is
associated
to
the
respective
no
algorithm.
M
This
is
another
example,
which
is
for
parallel
adjacency.
In
this
case
note,
7
have
a
parallel
adjacency
9378,
which
can
be
load
balanced
between
link
one
or
link
two,
for
you
know
adjacency
node,
eight.
So
again,
the
procedure
is
the
same.
The
initiator
in
this
case
node
one
when
it
generates
the
echo
request,
will
include
the
adjacency
set
in
this
case
9378
and
send
the
probe
packet
node
8.
When
it
receives
it
again,
you
know,
performs
two
checks.
This
is
the
terminator
in
this
case.
M
Yes,
and
it
also
will
check
if
it
can,
if
it
received
it
on
the
right
interface.
In
this
case,
you
know
either
on
link
one
or
link
two,
so
this
is
also
applicable
for
the
parallel
resistance
is
safe.
Where
you
know
the
lsp
is
actually
load
balance
between
different
end
points,
so
in
this
case
note
7
have
9378,
which
can
be
load
balanced
to
node,
8
or
node
888.
M
Now,
because
we're
just
including
you
know
the
sig
value
in
the
lsp
echo
request
respectively
of
you
know,
I
mean
note:
7
will
take
a
any
local
decision
based
on
entropy
or
other
forwarding
influence.
It
may
forward
the
traffic
to
node,
eight
or
eighty
eight
in
this
case
the
respective
over
the
node,
is
actually
receiving.
They
can
use
the
information
in
the
echo
request
to
perform
this
validation.
Like
you
know,
am
I
the
lsp
endpoint
and
did
I
got
it
from
the
right
interface.
M
Now,
through
this,
I
was
explaining
that
you
know
we
are
in
addition
to
mid
lsp
endpoint
we
also
will
perform.
Did
I
receive
it
on
the
right
interface?
So
we
included
one.
You
know
method
that
could
be
used
to
perform.
That
check,
which
is
you
know,
pretty
simple
by
just
maintaining
a
table,
but
there
might
be
different
other
options,
which
is,
you
know,
completely
an
implementation
choice,
but
we
included
one
that
we
are
explaining
here.
M
M
In
this
case
you
know
16
the
prefix
sets
that
belongs
to
both
alph0
and
algo128,
assuming
that
all
the
interfaces
are
associated
to
those
algorithms,
no
date
will
have
the
table
populated
such
that
it
can
accept
or
it
can
receive
the
profit
set
from
any
of
the
interfaces,
but
on
the
other
hand
it
will,
it
will
have
the
adjacency
design
by
note
7
and
will
have
the
relevant
incoming
link
associated
to
those.
You
know.
Adjacency
sets
so
in
a
nutshell.
M
You
know
the
idea
is
to
try
using
one
adjacency
targeted,
assisting
stacks
of
dlv
that
could
be
used
to
you
know,
perform
the
validation
for
different
types
of
sets,
so
it
drastically
reduces
the
amount
of
information
that
is
required
to
be
you
know,
collected
by
the
initiator
or
even
inject
into
the
pro
packet,
and
it
also
reduces
the
information
that
needs
to
be
processed
by
the
responder
and
because
you
know
this
was
this
is
a
proposed.
I
said
it's
more
generic
in
manner.
M
M
M
A
Thank
you
and
again
yeah.
I
don't
think
we
have
questions
rooms
for
questions
to
begin
with,
and
I
don't
think
anybody
is
in
outstanding,
so
we
will
assign
reviewers
from
the
working
group
as
usual,
to
give
feedback
to
the
working
group,
and
then
we
will
take
an
adoption
if
the
working
group
is
interested
in
progressing
this
work,
I
want
to
apologize
to
the
attendees
that
we
are
a
couple
minutes
late
and
hopefully
that
does
not
collide
with
other
meetings
you
had
with
this.