►
From YouTube: IETF106-MPLS-20191118-1550
Description
MPLS meeting session at IETF106
2019/11/18 1550
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
C
D
D
Hi
everyone
welcome
to
the
mpls
working
group
session,
so
Lowa
usually
does
this
opening,
but
he
had
asked
that
I
give
a
hand
and
help
this
time
and
Here
I
am.
This.
Is
the
mpls
working
group
session
at
a
ETF
one
is
106
I'm
Tarek
I
have
Nick
and
lower
next
to
me,
as
working
group
chairs,
we
have
Mac
as
our
working
group
secretary
next
slide
by
the
way.
This
is
the
only
session
that
we're
meeting
this
time
at
IETF
for
MPLS.
D
This
is
the
note
12.
It
states
the
rules
for
participation
and
contributions
to
IETF
if
you're
not
acquainted
with
it.
Please
take
the
time
and
go
through
it
and
get
familiar
with
it.
Everything
that
you
say
in
this
meeting
and
other
IETF
meetings
is
on
record
and
may
become
public.
You
don't
have
to
say
much,
but.
D
We
are
also
streaming
and
recording.
Please
clearly
state
your
name
when
you're
at
the
mic.
This
will
help
remote
participants,
know
the
person
at
the
mic,
as
well
as
the
minute
takers
next
slide.
So
we
have
our
agenda
posted.
There
hasn't
been
many
changes
since
it
was
originally
posted.
We
have
a
full
agenda,
it's
pretty
tight.
D
D
Next
slide,
please
yeah
still
the
agenda,
so
blue
sheets.
We
have
two
blue
sheets,
please
sign
your
name
and
pass
it
on
and
return
it
back
when
you're
done
Thanks
next
one.
We
don't
have
any
errata
this
time
since
last
meeting.
It's
a
good
thing.
We
have
one
liaison
that
came
to
MPLS,
it's
actually
to
multiple
working
groups
from
the
optical
transport
networks
and
technologies.
We
have
a
scott
mansfield.
These
is
working
on
compiling
an
answer
and
getting
the
inputs
from
their
respective
working
group
working
groups
moving
on
to
our
documents.
D
D
We
were
hoping
that
one
will
be
already
are
see
this
time
bye-bye,
this
meeting
I'm
not
sure
it
happened,
but
we
have
several
documents
that
are,
as
I
mentioned,
in
the
editors
queue
as
well
as
in
the
IHG
for
publication,
the
first
one
in
Nice
G,
the
yang
model
for
LDP
I.
We
have
it
on
the
agenda,
we'll
give
it
a
quick
update
today.
D
D
D
Again,
we
have
other
other
drafts,
none
zero,
zero,
which
are
on
agenda.
We
have
the
SFL
control
draft,
we
had
spoken
to
Stuart
last
time
and
he
indicated
that
he's
gathering
some
input
from
the
author's
or
co-authors.
We
would
you
know
if,
if
you
can
come
up
to
the
mic
and
give
us
a
quick
update
there,
that's
also
a
good
thing.
Stuart.
E
D
We
have
a
couple
of
other
drafts
also
on
the
agenda.
I
do
okay,
maybe
in
the
in
the
updates.
I
will
be
talking
about
it.
So
these
are
the
documents
that
are
already
working
group
adopted
and
we're
giving
you
an
update
on
them.
The
first
one
we
have
this
MPLS
PFD
directed
document.
The
current
status
is
stalled.
D
We
have
received
feedback
from
the
RTG
directory
and
there
are
comments
raised
specifically
from
Carlos.
If
the
authors
or
the
or
Carlos
is
here,
we
encourage
them
to
come
up
and
and
share
their
inputs.
We
know
that
there
are
further
discussions
that
are
going
to
happen
face
to
face,
as
well
as
on
the
mailing
list.
They
try
to
come
up
with
the
conclusion
on
this
draft.
D
How
we
want
to
progress,
it
I,
don't
see
any
authors
or
Carlos
okay,
so
the
second
draft
or
working
group
document
the
status
its
the
RMR
MPLS
based
draft
it
was
submitted
to
iesg
for
publication.
We
are
currently
waiting
for
ad
right
up
and
there's
no,
it's
not
it's
not
blocked.
Basically,
the
third
draft.
We
have
LDPR
Omar
extensions.
This
one
is
waiting
on
the
base
erimar
to
be
published,
and
once
that
happens,
we
will
move
ahead
with
requesting
publication
of
this
one.
F
C
G
D
You
then,
for
the
update,
okay,
so
moving
on,
we
have
MPLS
mm
LDP
map
document.
This
one
has
gone
a
review
from
the
mid
doctor
and
the
comments
were
addressed,
but
we're
waiting
for
the
go-ahead
from
the
the
mid
doctor
we
don't
have.
My
understanding
is,
is
we're
trying
to
get
a
hold
of
a
mid
doctor,
there's
a
replacement
in
the
works,
but
so
this
one
once
we
have
the
go-ahead
from
the
mid
doctors
that
all
the
comments
have
been
addressed.
We
will
go
ahead
and
close.
The
working
group
last.
D
The
next
document
we
have
is
MPLS
SPL
terminology.
The
status
of
this
one
is
it's
table
ready
for
working
group
last
call
after
a
minor
editorial
update
of
the
abstract
specifically
and
the
next
steps
we
will
be
going
ahead
with
the
working
group.
Last
call
after
this
update
the
last
draft
it
is,
it
is
submitted
Tori
iesg
for
publication,
and
we
uploaded
a
recent
revision
that
addresses
all
the
comments
we
got
and
we're
waiting
on
the
next
steps.
D
Lsp
ping
registries
update
it
is
on
the
agenda,
so
we
will
be
talking
more
about
it
today.
The
MPLS
SFL
framework.
This
is
the
one
that
I
wanted
to
flag
that
we
triggered
a
working
group
last
call.
Actually
we
triggered
a
a
Paul
I
PR
Paul
in
preparation
for
a
working
group.
Last
call
we
did
receive
two
acknowledgments
from
two
authors,
but
the
rest
of
the
authors.
D
D
D
And
the
last
one:
it's
still
there
related
to
the
part
of
the
SFL
family
drafts.
It's
ready
for
working
group
last
call,
but
we
want
to
proceed
only
after
the
base.
Sfl
document
gets
published,
so
the
next
steps
would
be
to
go
ahead
with
the
working
group.
Last
call
after
we
published
the
base
framework
for
SF,
l
and
that's
it
I
did
promise
Nick
will
cover,
but
somehow
I
kept
going.
H
Good
afternoon,
everyone
I'm
Tom
from
City
my
presentation.
Today's
path
segments
used
in
s
are
in
MPs
interworking.
This
draft
has
been
presented
in
a
stir
meeting
and
we
got
some
feedbacks
and
comments.
So
thank
you
very
much
so
this
time
we
updated
the
term
drafts
and
made
some
clarification.
So,
let's.
H
H
So,
as
the
figures
show
to
SR
MPs
ain't
working,
we
stir
a
path
segments.
For
example,
we
have
three
domains
from
access
network,
aggregation
network
and
call
networks
respectively
and
the
strain
domains,
maybe
or
maybe
older
MPS
networks
before
and
then,
when
we
used
her
when
we
applied
the
SR
architecture
to
the
network's,
we
may
be
used
and
we
may
be
up,
we
may
upgrade
there.
H
S
are
a
technology
to
deploy
desert
largely
to
the
access
network
and
the
core
network,
and
then
we
must
consider
their
scenario
over
SR
in
mpos
in
trucking
under
the
pass
segment.
As
we
all
know,
the
pass
Agana
may
be
used
to
enter
the
head
end
to
correlate
the
bi-directional
passes
and
to
achieve
their
bi-directional
past.
So
we
lead
to
concede.
Consider
their
bi-directional
end-to-end
service
from
their
access
network
to
Colette
works,
for
example,
from
the
load
one
to
load
nine.
H
So
there
are
path
segments
one
two
three
and
are
the
antenna
fires
after
three
domains
and
there
at
the
head
end.
The
path
segments
can
be
used
to
tube
to
do
the
by
directional
correlation
as
the
before
ester
ITF
amperes
per
segment
of
the
draft
described
her,
and
in
this
document
we
define
their
path
segments
to
do
to
do
the
intro
to
make
correlation.
First
we
define
the
path
segments
to
be
and
and
then
fire
off
over
there
NPR's
GE
Turner,
and
then
there
are
path
segments.
H
H
So
we
got
comments
from
last
meeting,
so
we
made
clarification
first
in
SR
and
M
POS
interworking.
There
are
two
models:
nasty
model
and
the
stage
model
in
the
in
estimate,
the
less
term
nasty
modo
the
fungus
age
and
the
path
segments
can
be
combined
to
achieve
the
in
enter
to
May,
stitching
and
the
past
past.
Monitoring
durapan
estate
is
can
be
used
to
to
to
the
intimated
staging
and
as
per
segment,
to
do
therapist
monitoring
and
in
the
button
nurse
TV
model.
H
The
stitching
overpass
segments
could
be
used
that
you
achieved
poster
into
domain
stitching
and
past
monitoring
the
because
their
SR
and
MPs
domains
may
be
deployed
in
incrementally
and
independently,
and
thus
TV
modem
may
be
appropriate
for
this
scenario
under
a
comparison
with
the
bone
in
seat.
As
we
know,
the
policy
could
be
bound
to
a
seat
list
of
selected
paths.
For
example,
Durham
PST
eat
earlier
under
used
to
choose
teach
the
surface
cross
much
much
more
domains
but
alter
a
Bonnie
said.
H
Mark
must
be
provided
and
pushed
onto
the
label
stack,
add
to
the
head
head
end
and
all
over
there.
All
of
them
are
popped
at
and
a
lot
of
men
are
popped
after
the
engine,
or
example
in
in
the
in
transit
to
me,
and
the
gesture
pour
pour
push
pull
out
the
pandan
seat,
which
panda
chill
under
domain
at
the
current
domain,
but
not
popped
out
the
county
seat
of
the
Nestor
domain,
so
they
said
to
me,
must
maintain
their
ponies
it
of
the
last
domain.
H
D
I
The
path
segment
draft,
which
is
the
spring
working
of
document
and
I,
think
the
comment
was
also
given.
I
describes
the
path
segments
of
binding
seed
base
stitching.
So
what
is
new
here
compared
to
that
like?
How
is
this
different,
I
know
it?
It
still
just
teaching,
because
I
know
you
call
it
nesting,
but
it's
this
allows
us
to.
You
know,
go
from
one
end
to
other
end
and
it's
sewn
in
figure
3
in
that
document.
So
I'm
not
sure
what's
new
here,
and
what
is
it
that
this
draft
trying
to
do?
H
C
J
I
K
I
be
I've
tried
to
discuss
with
one
already,
but
we
are
not
able
to
come
to
an
agreement
on
the
fact
that
when
you
define
path
segments-
and
it
has
a
particular
use
for
identification,
only
can
we
start
using
the
same
path.
Segments
now
stitching.
That's
the
crux
of
the
argument:
they
their
thing
is.
We
already
have
the
path
segment,
we
want
to
add
more
functionality
to
it
and,
on
the
other
hand,
we
said,
that's
not
how
it
was
envisioned.
K
H
We
use
the
path
segments
to
do
the
stitching,
but
the
stitching
not
they're
the
same
meaning
waster
the
stitching
before
we
use
their
paths
correlation
to
do
this
to
do
the
stitch
like
the
bidirectional
correlation,
so
I
think
their
procedure
is
the
same
ways
to
bi-directional.
We
also
both
do
their
correlation.
K
The
difference,
basically,
is
that
in
case
of
bi-directional,
there
is
no
forwarding
thing
happening
here
when
I
received
the
spot
segment
on
one
inter-domain
again,
I
need
to
forward
it
on
on
to
the
next
segment.
So
it's
leaving
into
the
same
action
that
a
binding
segment
already
does
when
I
receive
the
binding
segment.
My
job
is
to
decide
what
I
need
to
do
next,
and
we
are
saying
that
I
want
to
use
the
path
segment
to
do
what
binding
segment
already
does.
That's,
where
the
confusion
is.
I
I
I
I
I
I
So
a
draft
is
about
a
year
and
half
old.
It
was
a
spring
draft.
It
was.
It
has
been
presented
in
spring
as
well
as
I
ppm
working
group
and
recently
moved
to
MPLS
with
a
new
name
is
mentioned
so
since
it
was
presented
last
time
we
have
I
did
return
party
LV
block
number
TLV,
it's
a
standards
track
because
there
is
an
iron
accents.
Loopback
mode
is
defined
and
added
some
details
on
p2
MPs,
our
policy
as
well
as
a
CMP
and
some
various
editorial
changes.
I
I
The
one
way
measurement
mode
where
the
reply
is
sent
out
of
band
using
the
existing
7876
mechanisms
for
two-way
measurement
mode.
This
job
defines
a
return
path:
TLV
for
look-back
measurement
mode.
The
return
path
label
stack
is
added
in
the
header
of
the
packet,
so
the
new
return
party
lv4
to
a
measurement,
defines
a
few
types.
I
So
we
had
a
sill
feedback
to
align
this,
the
TLB
with
the
BFD
kind
of
structure.
So
we
have
done
that.
So
there
is
one
one
written
part
TLV
and
it
contains
the
sub
t
elvis
and
it
defines
either
asada
MPLS
label
stack
or
binding
succeed
or
in
case
of
bundle.
You
want
to
send
a
reply
back
on
the
same
incoming
interface
for
loss
measurement.
It
defines
a
block
number
TLV.
I
Replication
seed
is
use
can
be
used
for
p2
MPs,
our
policy.
So
we
welcome
your
comments
and
suggestion.
The
RFC
6334
has
been
implemented
and
deployed
in
many
networks.
It's
been
around
for
a
while.
We
do
believe
that
this
draft
is
ready
for
working
group
adoption
in
MPLS
working
group.
The
IANA
core
points
allocated
by
MPLS
working
group
we've
been
asked
to
keep
spring
working
group
in
the
loop
for
SR
aspects,
so
we'll
update
the
spring
mailing
list
when
we
update
the
drafts
and
about
the
milestones.
I
L
I
L
I
I
E
L
E
I
was
just
reinforcing
what
was
said
from
the
front
that
the
only
way
to
get
a
registry
in
entry
in
the
I
honor
code
points
is
to
specify
that
you
need
it.
So
they've
chosen
to
do
that,
rather
than
virus
an
indirect
route,
some
other.
How,
but
they
do
need
to
say
please
can
we
have
an
allocation
for
this
T
or
the
identifier.
I
I
I
Alternate
marking
method,
Vedic
basically
says
you
need
to
color
the
traffic
right,
so
so
the
coloring
of
traffic
is
done
either
with
synonymous
labels
or
some
other
mechanisms
outside
the
scope
of
this
drug.
But
all
dot
is
defining
the
probe
messages
for
counters
for
the
loss
loss
measurement.
So
you
need
to
say
the
contexts
say
this
counter
is
for
this
color
or
this
block
number.
So
you
can
correlate,
but.
I
C
M
N
Sam
Waldron
a
couple
of
quick
questions
in
this
case.
Are
you
proposing
the
I
haven't
at
the
draft
completely
so
I,
don't
know
exactly
what
the
content
is,
but
the
curious
to
know
are
you
proposing
some
extension
to
existing
mechanism
like
Alice,
pooping
or
something
because
I
want
to
know.
For
example,
everything
is
working,
it's
fine,
but
if
they
LSP
breakage
or
whatever
right,
how
do
you
know
you
are
actually
getting
response
from
the
right
node.
I
N
Mean
like,
for
example,
let's
take,
you
have
LSP
breakage
and
it
pops
a
packet
right.
So
are
you
discovering
that
okay,
this
packet
is
not
distinct
for
this,
so
I'm
not
going
to
process
and
respond,
but
if
it
is
punted
right
you
lose
the
context
of
where
the
packet
has
come
from
and
who's
the
destination
is,
and
in
that
case
you
respond
back,
and
so
you
don't
know
exactly
who
who
is
responding
from.
N
I
D
Dark
I
have
a
question:
Rakesh
I
asked
it
on
the
list
about
the
delay
measurement
for
end-to-end
quickly
when
you
have
easy
NP,
so
you
end
up
your
probes
or
whatever
way,
you're
testing
the
delay
they
end
up
has
been
hashed
on
any
of
the
ecmp
paths.
Yeah,
you
don't
necessarily
exercise
all
the
paths,
but
your
response
was
you.
You
need
entropy
label
and
I
want
to
make
sure
that
you're,
stating
that
entropy
label
is
a
must.
In
this
case
you
cannot
do
hashing
on
any
other
field.
D
I
So
it
is
there
in
the
draft.
There
is
a
section
I
forgot
to
include
this
in
the
slide,
but
the
entropy
label
is
there
in
the
draft
for
ecmp
handling.
This
is
MPLS,
so
there
is
no
IP
header
here.
So
housing
has
passing
either
is
done
using
label
stack
or
entropy
label.
There
is
not
nothing
else
that
you
can
use
for.
E
E
I
I
The
agenda
requirements
and
scope.
The
history
of
the
draft
updates
made
since
last
ITF.
This
was
presented
in
Montreal,
some
summary
and
the
next
steps.
So
this
is
to
transform
transport
the
IOM
data
fields
with
pls
and
cap,
so
the
III
ppm
working
group
has
done
quite
a
bit
of
work
for
IO
am
defining
various
data
fields.
There
are
many
drafts,
are
some
of
them
listed
here,
but
they
will
be.
You
know
more
drafts
and
more
progression
of
the
technology.
I
I
I
So,
since
Montreal,
we
have
addressed
several
comments,
so
one
comment
was
about
incorrect
IP
header
based
hashing,
so
we
have
added
flow
label
based
mechanisms.
There
is
an
example
added
with
past
segment,
ID
various
editorial
changes
as
well.
We
do
have
an
open
item
to
add
procedure
for
hop-by-hop
IOM,
so
just
to
recap,
there
is
an
indicator
label
added
on
the
MPLS
header
and
just
below
this
is
the
IOM
data
field,
so
I
ppm
working
group
has
extensive
procedures
for
IO
am
so
what
this
job
doesn't
really
talk
about?
I
And
in
order
to
not
break
the
IP
header
base
hashing,
there
is
a
second
format
defined
using
a
different
indicator
label
and
right
after
that,
the
first
four
neighbors
are
zero,
so
that
ipv4,
ipv6
hashing
is
not
broken,
and
we
took
advantage
of
the
space
to
put
the
float
labeled
that
as
well
so
basic
procedure
is
that
encap
node
inserts
the
indicator
label
and
iom
data
fields
and
the
d
cap
node
pops.
It
and
text
takes
a
local
timestamp
and
gives
the
the
iom
data
to
for
further
processing.
I
I
I
So
next
steps
we
we
have
some
more
work
to
do
for
hop-by-hop
or
p2,
FP
and
whatnot.
But
meantime
we
welcome
your
comments
and
suggestions.
We
would
say:
MPLS
working
group
is
the
home
for
this
draft.
Now
we'll
keep
a
spring
working
group
in
the
loop
for
the
SR
aspects
and
the
often
this
comes
up
in
IPP
a
working
group
as
well.
So
we
will
keep
that
working
group
in
the
loop
as
well.
P
O
P
O
J
J
J
Why
we
want
to
present
this
droplet
because
we
have
a
deployed
in
our
network.
It
works
really
fun.
It
can't
give
you
some
experience
share,
so
the
requirement
it's
for
the
large
network,
especially
when
we
deploy
our
piece.
The
functions.
It's
really
important
for
us
to
monitor
and
to
end
network
performance
at
the
this
morning,
as
that
happened,
I
give
an
example
that
has
one
biggest
city
Beijing.
We
need
to
deploy
even
more
than
30
key
nodes,
and
it's
really
hard
for
us
to
manage
that.
J
So
we
need
the
curator
in
Banda
Om
to
help
us
to
manage
the
whole
network.
So
the
requirement
here
is
that
we
want
the
OEM
is
in
band.
You
know
we
want
8k
money
to
the
hop-by-hop
performance
and
end-to-end
the
performance.
We
hope
it
can
use
a
unified
solution
to
do
the
post
VP
in
monitoring
and
tunnel
monitoring,
and
we
also
wanted
the
esteem
controller
can
support
such
as
a
telemetry,
something
like
that
to
improve
the
efficiency
and
the
the
intention
of
the
draft.
J
It
break
some
rules,
but
it's
very
easy
to
implement
and
it's
very
effective
to
monitor
the
performance.
It's
a
high
efficiency-
and
here
is
our
deployment
scenario
and
the
left
one
is
our
end-to-end
stitched.
As
our
panel,
we
may
have
a
different
domains
within
one
work
when
that
work,
and
we
can
use
this
solution
to
stitched
the
Asano's
and
on
the
second
one.
J
It
can
provide
the
end-to-end
between
service
performance
monitoring,
and
this
is
a
basic
use
case
in
our
network
and
in
Beijing
and
Shanghai
to
speak
city.
We
have
a
deployment,
the
ice
artist
network
to
carry
5g
base
station
and
we
use
this
solution
to
monitor
the
end-to-end
performance.
It
provides
a
really
good
result
and
our
maintenance
team
give
a
really
good
feedback
and
it's
very
easy
to
implement
it.
J
Our
vendors
also
give
a
really
good
feedback
because
it
did
for
them
the
workload
a
is
very
low,
but
the
performance
really
good
and
a
next
step
we
received
some
concerns,
as
the
first
one
is
a
special-purpose
labor
is
unable
to
assigned.
So
maybe
the
solution
is
that
we
will
hope
to
get
some
something.
Like
the
last
presentation,
we
use
the
extended
special-purpose
labor,
and
the
second
concern
is
that
the
trafficker
class
and
the
ttio
of
NPR's
labor
can't
be
changed.
We
will
not
touch
it
in
next
version
and
this
other
one.
J
We
cut
some
comments
from
email.
It
seems
as
if
our
solution
can
be
used
to
wrestle
the
unfairness
of
performance
requirements,
but
here
we
compare
that
and
we
found
that
the
current
version
of
SF
our
draft
cannot
meet
our
requirement,
including
hop-by-hop
performance
and
the
performance,
our
RSP
and
in
parallel.
So
we
will
update
our
draft
to
follow
the
standard,
but
we
will
keep
the
solution
yeah,
we'll
network,
it's
a
not
so
good,
but
the
word
maybe
works
like
that.
That's
all
Thank
You
Stuart.
E
A
few
comments,
some
of
which
you
sort
of
address
but
I'm,
going
to
touch
on
I'll
touch
on
them
anyway.
So
first
as
I
understand
it.
If
you,
in
order
to
do
you're
in
network
along
the
LSP,
instrumentation
you're,
expecting
the
packet
parser
to
look
at
to
pack
two
labels
in
the
packet,
the
top
label
another.
E
This
is
a
topic
that
we
discussed
extensively
during
the
time
when
we
were
looking
at
the
T
MPLS
OAM
design,
and
the
opinion
of
this
working
group
was
that
that
did
not
conform
to
the
MPLS
architecture
and
was
not
something
that
we
could
support
being
deployed.
It
has
particular
difficulties
in
building
parsers,
because
you've
got
to
get
your
address,
recognition
engine
to
go
and
look
up
two
labels.
E
You
want
to
use
domain
wide
labels
all
right,
so
you
specify
that
the
same
label
has
to
be
recognized
by
any
node
along
the
path.
Now
this
is
an
area
that
the
segment
routing
people
explored
in
depth
and
they
discovered
that
actually,
it
was
impossible
because
all
the
different
platforms
have
a
different
range
of
labels
that
they
allocate
from
their
platform
space.
That
is
why
they
have
the
complexity
of
the
segment
routing
global
label
base.
So
how
can
we
possibly
standardize?
E
Something
here
that
another
working
group
is
explored
in
detail
and
decided
is
impossible
to
do
implement
on
the
deployed
equipped
bass?
In
fact,
it's
a
it's
a
violation
of
the
MPLS
architecture,
because
the
MPLS
architecture
makes
no
comment
of
where
the
label
bases
are
and
whether
you
should
expect
the
same
labels
to
be
in
any
other
router.
E
That's
why
they
do
swapping,
for
example,
here
the
redefinition
of
the
TTL
I
believe
is
a
major
architectural
change
and
the
particular
definition
that
you
use
for
it
when
you
set
it
for
zero
I
believe
is
essentially
an
undefined
operation
in
MPLS.
You
see
you
were
allowed
to
pipeline
operations
when
you
have
to
deal
with
multiple
labels,
and
the
second
stage
of
the
pipeline
is
perfectly
entitled
to
reject
the
packet
at
that
point.
E
So
you
cannot
a
redefine
the
TTL,
and
that
was
a
cause
of
major
discussion
between
the
ITU
in
the
IETF
in
a
previous
design
of
an
MPLS
OEM
I
have
no
idea
what
the
consequences
of
your
redefinition
of
the
TC
bits
would
be.
But
I
would
point
out
to
you,
the
the
the
ecn
people
have
an
interest
in
this
as
well,
because
there's
a
congestion
notification
architecture
based
on
the
use
of
one
of
these
consists
of
Al
use
in
the
network.
E
J
To
keep
the
solution
follow
the
principle
of
NP,
RS,
III
I
think
we
totally
agree
that
and
here
I
just
given
some
feedback
about
this
labor
and
yes,
currently,
the
this.
Maybe
we
can
keep
as
a
TDI,
oh
no
problem,
and
here
the
flow
ID
I,
think
if
it
can
labor
some
flu,
no
problem,
it's
a
within
the
Empire's
architecture
and
we
have
some
consensus.
We
also
rise
to
some
concerns
that
here
we
reused
the
traffic
class
to
indicate
the
lost
measurement
at
column
marking
and
the
TB
measurement
at
column.
Aking.
J
From
my
point
of
view,
there
is
no
clear
definition
of
the
traffic
class
and
the
traffic
class
can
be
used
by
operator
to
indicate
what
traffic
is
there
and
we
can
use
the
definition
but
themselves
use
of
the
traffic
class
bits
to
indicate
that
he
is
a
color
for
the
traffic.
So
maybe
this
solution,
this
labor
can
be
within
the
umpires
architecture
and
the
problem
is
this
labor.
If
we
change
this
labor
to
the
extended
labor,
maybe
the
whole
solution
can
be
under
the
amperes
architecture,
so
yeah.
K
Q
J
Q
I
J
L
C
Last
time,
I
talked
about
the
use
and
misuse
and
abuse
of
some
of
the
registers,
and
we
actually
sorted
that
out
and
getting
home.
We
found
one
new
problem
that
I
actually
also
wanted
to
include
in
this
draft,
and
it
has
to
do
with
again
the
background
we
have.
We
have
had
a
couple
of
changes
over
years
and
some
of
the
graphs
has
been
making
small
changes
in
oracy
81-66.
C
We
tried
to
actually
do
what
we
thought
was
the
intention
and
it
turned
out
that
you
failed
there
also
so,
but
discussing
now
is
mandatory
and
optional
theories.
With
my
background,
pretty
much
within
LDP
a
mandatory
LDP
is
something
that
needs
to
be
in
a
message.
If
it's
defined
to
be
in
the
message,
an
optional
clearly
is
something
that
can
be
there
or
cannot
be
there,
and
the
message
is
still
well-formed.
C
C
So
in
Odyssey,
for
379
and
also
be
it
in
eight-
is
twenty
nine
they
used.
Actually,
they
never
explicitly
used
the
term
mandatory
and
optional
TLB,
but
implicitly
they
had
a
different
meaning.
The
meaning
was
that
if
you
get
a
till
V
or
a
sub
theory
from
a
range
that
is
defined
as
half
of
this
base
lower
half
of
this
page,
you
are
required
to
take
an
action.
That's
also
defined
in
the
document.
That
is
what
we
talked
about.
This
mandatory
deal
way
so
subtly
is
optional.
C
C
Teal
isn't
up
to
you.
Actually
sub
theories
are
not
discussed
at
all
in
any
of
these.
Dr.
documents
is
only
two
theories,
but
sub
teensiest
has
the
same
effect.
If
it's
not
recognized,
you
need
to
send
a
message
back,
so
we
are
saying
that
we
are
removing
the
mandatory
and
optional
and
yes
defines
what
is
required
for
teal
V
sub
T
is
raised
from
those
wrenches
and
I.
C
C
On
the
other
hand,
if
we
don't
do
it
they're
all
about
sixteen
or
seventeen
documents,
that
would
need
to
be
updated
to
actually
make
the
you
make
a
consistent
view
of
sub
the
optional
and
mandatory
theories
in
in
India
list
of
ping
releases.
So
this
is
the
least
hard
way
to
do
it,
and
our
next
step
is
actually
to
go
home.
Do
the
updates
add
text
that
actually
changes
the
document
that
we
need
to
change,
and
then
we
would
be
very
ready.
Working
group
last
call.
C
R
S
S
S
We
also
have
scalability
issue
in
terms
of
the
parameter,
the
sheer
number
of
parameter
we
need
to
fill
in
these
segments
or
defects.
So,
just
to
give
you
a
preview
of
this,
and-
and
this
is
not
to
pick
up
on
one
particular
example-
but
let's
say
we
take
a
look
at
even
existing
fact
for
parallel
or
agency
said
it
has
many
parameters.
That
interest
needs
to
specify
what
is
the
responder
node
ID?
What
is
the
responder
interface
ID?
S
What
is
this
neighbor
node
ID,
neighbor,
interface,
ID
and
because
Inglis
cannot
know
in
some
cases,
like
para
legend
ceases
where
or
which
interface
the
packet
will
lend
to.
Then
we
do
not
have
actually
a
validation
procedure
properly
defined
in
existing
RFC
and
as
we
try
to
define
an
and
n
continue
to
cover
new
seat
types
for
second
outing.
S
We
see
this
some
of
these
definition
that
are
in
individual
drafts
and
and
a
lot
of
this
thing
is
coming
really
from
the
fact
that
the
onm
for
MPLS
or
define
with
control,
plane
and
aeroplane
validation
together.
So
the
information
was
there
so
that
the
nodes
can
validate
data
plane
and
against
important
consistency,
and
that
is
the
root
cause
of
what
we
are
seeing
here
and
today.
We
do
not
have
a
procedure
that,
if
you
want
to
simplify
this,
we
can
just
validate
the
data
plane
itself
and
escaped
the
control
plane,
validation.
S
The
closest
of
that
that
comes
is
an
ill
fake,
but
but
we
don't
have.
The
net
effect
does
not
have
enough
validation.
Building
it
way.
So
motivation
here
is
that
we
try
to
simplify
and
the
effect
definition
define
one
fact,
definition
that
works
for
all
segments,
outing
set
type
set
types,
and
it
actually
is
simple.
So
once
we
deploy,
we
don't
have
to
update
that,
and-
and
second
part,
is
that
it-
it
also
simplifies
the
initiator
job
in
terms
of
filling
the
data
that
is
required
for
validation
and
control.
S
Plane
and
a
replay
validation
is
a
node
behavior
note
local
behavior,
and
it
should
be
done
in
a
node
local
fashion.
So
that's
the
motivation,
so
for
solution
is
really
going
back
to.
If
you
try
to
look
at
from
that
point
of
view,
is
we
really
have
to
look
into
the
MPS
data
plain
data
model
and
and
I
will
explain
it
using
an
example
here
so
from
a
procedure
point
of
view.
One
way
to
look
at
it
is
that
when
we
have
an
LSP
or
when
you're
thinking,
we
have
as
end
point
in
mind.
S
S
Let's
say
his
local
agency
said
it
is
local
prefix,
it's
whether
they
belong
to
the
men.
I'll
go
off
to
the
Flex
I'll
go
so
let's
say
sixteen
thousand
and
eight
one
six
zero
zero
zero
eight
is
is
local
prefix.
It
say
basically
just
bounded
to
that.
I
can
for
n,
for
this
said
for
this
label,
I
can
receive
packet
on
any
interface
and
and
and
I
can
validate,
that
that
data
plane
action
for
a
send
for
this
label.
Cop
label
was
correct.
S
Similarly,
for
the
CID
16
1
to
88,
which
is
for
the
flux,
I'll
go
128,
it
can
receive
an
aura
interface,
but
only
agency
said,
which
is
which
is
set
up
at
node
seven.
You
can
have
multiple
cases.
One
cases
the
agency
said
one
nine
one,
seven
eight,
which
is
bound
to
link
one,
so
the
node
it
creates
is
local
information
that,
for
this
label
type
for
this
agency,
that
I
should
be
receiving
this
packet
on
this
link.
S
One
and
I
should
be
the
endpoint
and
four
nine
seven,
nine
two
seven
eight,
which
is
did
link
on
the
south.
It
binds
their
information
that,
for
any
packet,
receive
a
with
this
label,
an
endpoint
being
me
it
has
to
be
linked
to
and
for
a
federal
agency.
It
would
determine
that
I
can
receive
either
on
link
one
or
link
to,
but
this
is
done.
S
There
is
a
local
decision
when
an
initiator
initiates
the
thing
it
puts
in
the
FAQ,
the
label,
the
target
label
and
the
end
point
the
expected
end
point,
and
it
would
work
also
for
binding
said
you
can
see
how
it
would
work
for
by
Nancy
very
easily
and,
however,
work
for
other
said
type
and
with
that
top
label.
All
I
said:
if
the
it's
a
packet
itself
with
table
level,
six,
one
six:
zero,
zero,
zero;
eight,
it
will
land
it.
No
number,
eight,
don't
know
what
it
would
say
am
I
the
endpoint.
S
Yes,
is
this
my
local
said?
Yes,
so
that's
a
positive
response.
If
the
packet
lines
are
some
other
node,
then
the
endpoint
would
not
match
and
it
may
not
be
the
local
label
for
that
that
node
and
the
validation
will
fail.
Similarly,
if
the
target
is
our
agency
said,
the
endpoint
is
no
d8,
no
rate
is
able
to
validate
whether
it
receive
the
packet
on
the
right
interface
or
not
whether
this
is
being
per
religion
C
or
this
is
being
the
agency
they're
bound
to
one
particular
interface.
S
T
S
T
T
S
T
So
I
mean
it
seems,
like
you
know,
a
lot
of
work.
A
lot
of
the
work
goes
into
actually
getting
the
forwarding,
plane,
validation,
correct,
and
this
is
sort
of
simplifying
the
control
playing
validation,
but
that's
actually
not
the
hard
part
to
do
so.
It
seems
like,
if
we're
going
through
the
trouble
of
doing
this,
we
should
do
it
as
robustly
as
possible
and
not
sort
of
at
least
common
denominator
approach.
No
I
mean
my
take
on
this
okay,
so.
S
Please
come
to
Naaman,
so
there
are
there
are.
There
are
two
approaches
here.
One
approach
is
a
little
bit
approach,
which
is
this
there's
another
approaches,
which
is
the
interfaces
based
approach,
where
you
can
bound
a
specific,
specific
interface
on
which
you
should
be
receiving
or
a
set
of
interfaces.
Okay,
but
you're
not
concerned
with,
like
which
IDP
oh
I,
realize
this
is
what
the
f
is
is
you're
not
concerned
with
those
part.
S
T
So
so
I
mean.
It
seems,
though,
that
defining
two
approaches
is
sort
of
the
worst
of
both
possible
worlds.
I
mean
no
maa
a
robust
approach
and
then
a
least
common
denominator
approach,
then
sort
of
results
in
just
interrupt
problems
and
more
more
testing.
I
also
disagree
with
your
initial
State
and
that
this
is
sort
of
a
process
that
we're
changing
we're
proposing
a
protocol
that
sort
of
robust
to
IETF
process.
That
is,
you
mentioned.
People
are
defining
OAM
effects
when
they're
defining
the
original
segments
I
mean
that
seems
like
you
know.
S
S
You
actually
have
to
go,
and
then
there
is
another
draft
on
the
agenda
once
it
comes,
you
see
that
you
actually
have
to
go
and
get
that
information
from
the
control
plane,
because
it's
not
for
a
human
to
be
entering
all
those
information
or
parameter
is
not
possible,
so
you
get
it
from
the
control
plane.
So.
Q
D
D
There
are
cases
where
the
label
a
collision
can
happen
on
eight,
you
have
multiple
SR
effects,
trying
to
clean
the
same
label
and
there
are
actually
there
stated
in
one
of
the
spring
working
group
documents
how
you
handle
such
collisions,
and
you
have
a
tiebreaking
criteria
now
for
the
egress
to
do
validation,
the
label
is
valid
and
it
will
pick
one
of
the
facts
and
bind
it
to
that
label.
But
the
ingress
may
think
it's
validating
something
different,
a
different
fact.
D
S
U
S
R
This
is
indeed
a
very,
very
straightforward
draft
and
a
couple
of
slides,
probably
more
than
a
couple.
Actually,
you
know
just
to
give
a
lot
of
contextual
details
on
this,
but
you
know
essentially,
if
I
have
to
summarize
what
this
is
about,
is
really
about
asking
for
a
code
point
for
OSPF
b3
for
a
couple
of
information
elements
within
LSP
ping,
and
that's
because
when
we
set
those
up,
we
set
them
up
for
OSPF
generically
and
now
we're
finding
that
we
actually
need
to
differentiate
between
OSPF,
v2
and
v3.
C
R
R
Problem
statement
is
this
is
a
rephrasing
of
what
I
said.
The
main
intention
is
that
we
created
a
couple
of
sub
registries
in
the
LS
peeping
parameters
which
actually
use
a
protocol
field,
and
this
protocol
field
is
really
used
for
doing
control,
plane,
validation
and
verification
of
the
data
plane.
The
protocol
fill
exists
in
the
downstream
detailed
mapping
TLV,
and
it
also
exists
in
the
seeds
for
the
target
fix,
for
there
are
three
of
them
target
fixed
acts
for
segmented
effects,.
R
And
how
we
actually
set
it
up
historically
for
OSPF,
only
I
guess
is-
is
agnostic
to
layer.
Three
OSPF
b2
runs
over
ipv4
and
advertises
ipv4
prefixes
and
reachability
OSPF
v3
runs
over
ipv6,
but
advertises
both
address
families
and
the
other
place
where
we
have
the
protocol
field
defined
for
OSPF
only
is
within
the
label
stack
subtly
in
the
DD
map.
R
And
you
know,
even
though
this
is
a
fairly
straightforward
drafting,
which
we
actually
explain
some
of
the
context
for
when
we
actually
realized
that
we
needed
this,
even
though
it's
really
straightforward,
we'll
really
invite
and
welcome
review
in
that
review.
Comments,
questions,
observations,
constructive
criticism,
and
you
know,
even
though
that
is
a
fairly
straightforward
draft.
Also.
We
actually
request
adoption
on
this
very
first
presentation,
so
thank
you.
Okay,.
C
So
lower
Anderson
Carlos
there
is
so
I
think
this
is
a
very
neatly
to
draft
it
does
what
it's
tells
us
that
you
want
to
do
pretty
clear
is
to
read
I
have
about
one
problem,
so
today
there
is
a
code
point
for
OSPF
in
the
registers.
Are
you
giving
to
use
that
code
point
for
OSPF
v2
in
the
future?
If
that
is
the
case,
you
should
rename
it
correct.
R
And
that's
that's
a
great
question.
Louis!
Oh
you
know
our
experience
say
that
point
is
not
using
deployment
today.
Are
you
saying
it
you're
not
used
at
all,
so
our
yes?
What
we
understand
is
that
is
not
using
deployment
today,
and
if
that
the
case
you
know,
the
easy
thing
to
do
is
to
actually
rename
that
to
SPF
v2.
At
the
same
time,
the
safer
thing
to
do
is
to
obsolete
it
and
get
a
new
one
for
v2
and
we're
really
open
to
doing
either
of
those
I.
C
R
D
R
No,
no
such
a
thing
at
all.
You
know
and
if
anything,
there's
only
silly
answer
so
hopefully
I'll
I'll
give
you
one
that
is
not
too
silly.
The
address
family
is
gonna.
Tell
the
rich
ability
information
address
family
right,
not
the
protocol
that
is
advertised
in
it,
and
in
that
case,
if
you
get
IP,
if
you
get
ipv4
that
can
be
OSP,
v2
or
v3.
So
that's
why
you
cannot
disambiguate.
Basically.
D
R
D
D
This
draft
has
undergone
a
yang
doctor
review
recently
and
we've
addressed
all
of
the
comments
that
came
back
from
the
review.
We
have
no
outstanding
issues
on
this,
so
the
next
steps
are
going
going
ahead
and
requesting
working
group
last
call
no
open
issues.
We
encourage
the
working
group
to
give
us
feedback
if,
if
they
get
to
review
it
again,
the
second
one
is
the
MPLS
static
King
for
static
Ellis
fees.
This
again
undergone
a
yang
dr.
review
and
the
author's
did
address
all
of
the
comments.
D
Now.
Next
we
have
this
MPLS
LDP
hang
craft.
This
draft,
we
version
seven
of
it.
It's
currently
a
non
version.
Seven
and
we
did
go
ahead,
completed
its
it's
working
group
last
call
and
we
did
submit
it
to
iesg
but
part
of
that
process
because
of
the
first
yang
doctor
review
happened
in
22nd
2017
on
an
older
revision.
We
were
asked
to
review
it
again
and
that
happened,
and
there
were
comments
that
came
back
off
the
from
the
last
review.
That
happened.
D
So
the
authors,
my
understanding,
are
looking
into
the
comments
and
they
will
they
will
look
to
address
them.
There
are
also
more
comments
that
came
from
town
patch
about
the
draft,
so
we
did.
We
do
encourage
you
the
author's
to
look
into
them
as
I
mentioned
the
currently,
the
draft
is
in
iesg,
so
we
want
as
next
steps.
We
want
to
address
the
comments
and
give
a
go-ahead
so
that
the
ad
does
the
proper
next
steps.
V
D
So
the
next
draft
is
actually
a
sister
draft
of
the
first
one:
it's
not
it's
not
in
the
it's
not
submitted
to
IES
yet,
and
but
we
understand
it's
close
to
being
complete,
but
just
like
the
first
one,
the
one
I
did
mention
on
the
previous
slide.
It
has
undergone
a
young
doctor
review
and
back
in
2017.
So
most
likely
we
will
go
through
another
round
of
review
and
they
will
trigger
comments.
So
we
we
do,
encourage
the
authors
to
proactively
respond
so
that
we
can
progress
faster
on
this
one.
D
D
Currently,
the
the
draft
is
an
expired
state
as
next
steps.
We
we
want
to
hear
from
the
authors.
If
there
is
still
interest
in
driving
this
draft
forward.
We
want
to
refresh
the
idea
if
so
and
we
move
ahead
with
adopting
the
document.
If
any
one
of
the
authors
is
present
and
wants,
the
comment
feel
free.
U
U
U
So
we
we
jump
on
to
peer
nodes
it
because
peer
adjacency
said
it's
the
same
and
there
is
no
change
from
last
revision.
So
peer
node
said
has
changed
a
little
bit
from
last
revision,
so
we
had
a
address
family
there.
Instead,
we
thought
that
it's
better
to
have
number
of
ipv4
interface
pairs
and
number
of
ipv6
interface
pairs.
This
is
because
the
there
can
be
two
interfaces
on
which
the
peer
load
side
wants
to
load
balance.
U
The
traffic
on
one
is
ipv4
and
as
ipv4
address
and
neither
has
ipv6
address,
and
we
you
should
be
able
to
accommodate
that
and
when
so
so,
the
TLB
structure
has
been
updated
when
there
are
both
ipv4
and
ipv6
addresses
the
IPV
force
will
be
ipv6
will
be
followed
after
the
ipv4
address
pairs.
So
that's
the
update
in
this
revision.
Similarly,
Pierce
X
it
the
same
update.
So
instead
of
having
an
address
family,
we
have
number
of
ipv4
interface
pairs
and
number
of
ipv6
interface
pairs
in
the
TLB
definition.
U
We
request
for
review
and
comments
and
we
also
ask
for
working
group
adoption
it's
being
presented
multiple
times.
This
is
the
third
time
we
presenting
it
and
we
believe
that
this
should
have
been
done
when
the
EPE
sits
were
defined
so
so
as
to
just
avoid
you
know,
having
situation
when
EPE
is
deployed
and
we
don't
have.
Oh
I
am
photos,
so
I
think
this
is
the
really
the
work
needed
to
be
done
quickly.
Yes,.
S
Friendly,
so
I
have
the
same
common.
Can
you
go
back
to
one
slide
see
the
thing
is
this
that
this
is
getting
much
more
complex?
We
need
to
get
simplification,
this
information,
the
amount
of
information-
that's
going
is
button,
one
ingress
button
on
egress.
You
try
to
get
information
to
validate,
essentially
the
forwarding
behavior,
so
what
we
will
be
willing
to
work
with
again.
The
document
that
I
presented
and
we
spoke
offline
is
to
work
with
to
find
an
easier
ground.
S
What
I
would
say
that
we
were
willing
to
work
with
the
authors
of
this
draft
to
try
to
find
and
simplify
it
ground
and
and
and
and
we
believe
it
can
be
achieved,
it
can
be
achieved
by
using
either
the
the
siddell
locator
ID
or
it
could
be
achieved
by
the
interface
addresses
on
which
the
packet
should
be
received.
It
should
be
done
so
that
it
is
not
bound
to
the
egress
pe
will
not
bound
to
the
BGP.
It
can
be
used
for
federal
agencies
of
any
type
with
the
IEP
EPE,
some
other
type.
U
So
if
you
want
a
robust
or
mechanism
that
people
are
used
to
for
so
many
years
with
the
MPLS
I
think
you
have
to
leave
with
coming
up,
you
know
preparing
this,
this
kind
of
effect
and
then
validating
them
on
the
egress.
If
you
want
a
very
generic
mechanism,
I
think
it's
not
going
to
be
that
robust.
It
may
not,
it
might
falsely
defect,
it
might
falsely
detect
something,
and
sometimes
it
may
not
even
detect
I
think
that
was
discussed
in
the
last
presentation
like
in
wha,
in
which
cases
it
it
can
break.
U
S
S
Josh
is
updated
and,
and
and
but
but
the
point
is
not.
The
point
is
that
we
local
information,
remote
information,
locally
s,
number
remote
es
number
Medina,
said
I.
Think
what
we
should
look
for
is
some
simplification.
That
can
we
apply
across
the
board,
not
for
the
EP.
U
only,
but
for
the
IDP
we
can
simplify
there
as
well
and
and
will
be
completely
willing
to
work
on
that
front.
But.
T
So
I
have
a
question
sort
of
I
guess:
safar
commented
on
like
simplifying
even
the
IGP
versions,
which
are
already
defined,
and
what
is
it
8287
I
mean
those
are
you
know,
implemented
interoperability,
tested
deployed,
I
I
mean
I
would
strongly
object
to
anything
that
says
we're
going
to
define
a
second
version
of
those
four
to
what
purpose
I
see.
No,
no
reason
to
do
that
for
the
iGPS.
U
S
Even
if
you
don't
do
that,
this
information,
if
they're
too
much
and
could
be
simplified,
and
we
can
I
mean
we
try
to
do
go
that
route
and
we
can
simplify
and
I
think
we
should
discuss
that
a
bit
more
I,
don't
think
in
the
current
form
it
is.
It
is
the
information
it
would
be
to
buy
difficult
for
both
ingress
and
egress.
U
U
U
So
we
go
back
to
updates
from
last
revision,
so
we
received
a
comment
that
so
we
had
labels
in
the
reverse
path,
TLB,
and
so
you
received
a
comment
that
they
should
be
segments
instead
of
labels.
So
we
took
that
comment
and
updated
this,
so
that
so
there
is
a
reverse
path:
sub
TLV,
which
reverse
path
TLV,
which
is
under
MPLS
OEM
IANA
registry,
and
then
there
are
segments
up
TLV.
U
So
each
six
segments
of
TLV
looks
very
similar
to
what
is
defined
in
SR
policy
lists,
sub
tier
V,
and
it
could
have
either
labels
or
it
could
have
IP
v4
address
and
optional
set
and
ipv6
said
enough
or
optional
sent
so
right
now.
This
draft
is
referring
to
the
IANA
registry
of
SR
policy,
Lee
sub
tier
V,
because
this
this
this
Ayana
code
points
is
a
sub
TLV.
So
right
now
we're
directly
referring
to
it.
U
I
wasn't
too
sure
if
this
is
the
that
is
the
right
way,
or
we
should
define
a
new
registry
for
this
and
looking
for
inputs
from
the
working
group.
So
this
this
looks.
The
segment
sub
T
always
look
exactly
same
as
what
is
defined
in
SF
policy,
sub,
T
Elvis.
So
we
have
three
types:
we
have
taken
type
one,
which
is
a
label
MPLS
label
type
3,
which
is
ipv4,
node,
address
and
optional,
said
and
type
for
ipv6
address
and
the
optional
set.
U
So
we
also
have
another
new
section
added,
so
this
is
for
dynamically
building
the
reverse
path.
So
in
this
example,
our
one
may
not
have
the
capability
to
figure
out
what
the
reverse
path
is
for
when
it's
pinging
from
r1
to
r4.
So
we
have
a
mechanism
how
this
can
be
done
and
the
reverse
path
dynamically
built
as
the
MPLS
trace
route
mechanism
progresses.
So
this
is
applicable
for
only
place
road
procedure.
So
when,
when
ASB
r3
receives
or
trace
around
MPLS
traced
or
packet,
it
finds
out
that
this
packet
is
received
on
an
interesting.
U
U
C
U
U
L
U
L
P
W
W
W
W
At
time,
t2
noed
beter
stone
the
allah
pls
peace
to
prefix,
see
both
the
primary
LSP
PRI
and
the
backup
which
is
tied
to
this
primary.
As
a
result
of
this
any
l2
VPN
and
VPN
services
or
node
B,
which
use
LD
pls
p2
e,
they
see
complete
traffic
laws
till
the
LSPD
converges.
That
is
at
time.
T
for
at
t3,
B
receives
the
link
down
event
for
be
a
physical
link,
and
maybe
here
I
mean
LDP
on
B.
T
M
T
W
W
W
M
X
X
W
X
W
W
W
Shutdown
notification
is
basically
a
fatal
error
and
the
other
possible
thing
is
here:
LDP
needn't
research
session
to
neighbor
immediately
under
saving
on
detecting
allentown
event.
That
is
when
physical
connectivity
to
pier
goes
down.
It
may
be
reasonable
to
wait
for
LDP
hello,
adjacency
to
timeout.
V
P
V
V
If
you
look
at
look
at
ldpr,
SC,
50
36,
when
you
send
a
shutdown
message,
you
can
also
send
an
extended
status.
Tlv,
that's
good
point
that
can
give
extra
information
to
the
receiver,
so
you
can
always
basically
send
an
extended
status.
You
let
receiver
know
that
you
know
you
know
shutting
down,
but
this
is
a
gr
case.
You
know
you,
you
may
wanna
do
whatever
you
want
to
do
so.
Instead
of
shedding,
you
know
blocking
shutdown
message.
You
should
extend
the
shutdown
message
and
use
some
eternity
away.
V
D
So
we
cut
the
queue
after
tarik,
so
tarik
with
juniper.
We
had
conversation
over
the
mailing
list
and
I.
Think
one
of
your
one
of
the
possible
solutions,
you're
presenting,
is
wait
until
the
hello,
it's
timed
out
on
their
JCC
and
then
react
and
flush
the
labels
remote
labels
that
you
know
B
will
get
from
a.
So.
If
you
go
back
to
your
drawing,
you
delay
flushing
the
labels
on
B
until
the
hello
times
out
there
are
those
times
out
is.