►
From YouTube: IETF-MPLS-20230615-1400
Description
MPLS meeting session at IETF
2023/06/15 1400
https://datatracker.ietf.org/meeting//proceedings/
D
C
F
B
C
C
D
G
Not
severe
one
acceptable
on
my
side.
B
Yeah
I
mean
it's
usable,
we
can
work,
but
it's
odd,
isn't
it.
F
G
E
I
think
when
Loa
muted
it
was
cleaner
but
yeah.
That's
my
impression.
E
Attendance
right
now
and
five
minutes
after
we
should
be
starting
anytime
now:
okay,.
C
E
C
C
E
Okay,
I
think
Greg
is
saying
he
has
no
audio
coming
so
I'm,
not
sure.
If
he's
trying
to
log
in
oh,
he
we
lost
him
all
right,
so
we
can
get
started.
E
This
is
the
another
MP
mpls
M
A
interim
session
and
thanks
everybody
for
joining
today
as
usual.
This
interim
is
a
joint
between
three
working
groups:
Pals
and
net
include
and
as
well
mpls.
E
We
have
representative
Representatives,
at
least
from
two
working
groups
from
chairs
from
two
working
groups
and
thanks
all
for
joining
the
note
12,
because
it's
an
interim,
we
have
to
remind
you
that
these
are
the
rules
for
participating
in
ITF
and
and
feel
free
to
go
through
them
offline.
If
you
haven't
done
that
already.
E
Okay,
I
I'll
move
on,
and
hopefully
by
the
time
we
need
Greg,
he
will
have
audio
but
well
at
that
time.
Okay,
so,
let's
move
on
today,
we
have
oh
before
we
bash
the
agenda,
a
reminder
of
couple
of
pointers:
blue
sheets
no
need
to
bother
because
they're
automatically
recorded
in
case.
You
need
the
the
link
you'll
for
meet
Echo,
a
reminder
for
taking
notes
if
you
can
and
you're
attending.
Please
use
this
link
to
and
I
also
passed
it
in
the
chat
so
that
we
can
collaboratively
take
notes.
E
The
rest
of
the
pointers
are
useful
for
the
working
group
and
as
well
of
we,
we
have
a
pointer
for
taking
action
items
on
the
wiki
on
the
mpls
wiki.
E
All
right,
so,
let's
move
on
to
bash
the
agenda.
Today
we
have
five
items
plus
anything
else
that
we
can
raise
today
or
now
so
feel
free
to
come
to
the
mic.
If
you
want
to
discuss
something
or
add
something
to
the
agenda.
E
E
All
right
so
I'll
go
ahead
and
I
don't
see
anyone
with
hands
raised.
I'll
go
ahead
with,
with
the
with
the
first
item
on
the
agenda,
which
is
the
review
of
action
items.
I
did
record
couple
last
time
we
met
and
we
have
a
Wiki
where
I'm
keeping
track
of
them.
It's
hard
for
me
to
share
it
while
on
meet
Echo.
So
let
me
just
quickly
flip
to
the
the
that
Wiki
and
I'll
pass
a
pointer
to
it
so
that
you
can
review
it
offline.
E
Okay,
I,
don't
know
how
to
send
it
to
everyone.
Now
the
chat
is
the
best
days.
Okay,
so
I
passed
it
in
the
chat
and
the
two
actions
that
I'm
keeping
track
of
as
of
now
is
it
was
investigation
of
the
intersection
of
M
A
with
existing
mpls
features.
We
talked
about,
you
know
having
either
a
pseudo
wire
with
oam
or
even
a
a
beer
packet
with
m
a
header.
E
E
So
let
me
just
pause
and
see
if
anyone
has
any
any
update
on
this
or
they
want
to
put
this
on
the
agenda
for
another
time.
Any
investigation
done
on
that.
E
Okay,
great
all
right,
okay,
so
the
second
I
action
item,
I'm
tracking,
is
we
talked
about
the
first
nibble
last
time
we
met
the
mpls
first
of
all
that
shows
up
in
the
mpls
payload
or
the
payload
of
mpls.
E
E
So
we
wanted
to
investigate
whether
five
the
value
5
is
being
relied
upon
in
another
way,
because
we
established
it's
unreal
unreliable
way
on
a
Transit
node.
So
the
action
item
is
open.
The
owner
is
the
working
group
and
I
don't
have
further
update
from
that.
E
So
but
please
feel
free
if
you
have
any
update
to
share
today.
C
Did
you
send
a
mail
to
the
beer
working
group
or
the
beer
shares
or
something.
D
E
All
right,
that's
that's
about
it
for
Action
items.
For
today
before
we
move
on
anyone
wants
to
add
another
action
item,
I'm
I
guess
we
will
probably
add
something
along
the
meeting
today,
but.
C
Anyone
Eric
I
actually
have
something
more
I
thought
I
had
it
on
the
agenda
when
I
uploaded
it,
but
on
the
that
net
perspective
on
m
a
we
can
put
that
s
number
3B
or
something.
E
Okay,
okay,
I
I.
What
I
captured
is
the
debt
net
discussion
yeah,
so,
okay
I
know
we
have
a
presentation
being
prepared
for
next
meeting
on
that
net.
So
I
can
take
that
as
an
action
item.
If
you
want.
C
I
E
All
right,
that's
it
for
Action
items.
Moving
on,
we
have
a
discussion
on
IDF
mail
aliases.
What
do
you
want
to
tell
us.
C
No,
it's
not
intended
to
be
a
discussion
really,
yes,
so
people
know
ITF
has
two
ways
of
forwarding
males
to
participants.
One
is
amazingly:
it's
the
working
group
mailing
list
that
works
just
fine.
It
can
be
used
as
before,
but
then
we
have
something
we
call
male
aliases.
C
C
So
if
you're
going
to
send
mail
to
working
Group
shares,
please
send
directly
to
our
normal
mail
addresses
and
do
not
use
the
Alias
for
the
time
being,
it
will
be
fixed,
but
I
don't
know
when.
A
C
And
then
we
have
the
I.
Send
the
mail
to
the
death
net
shares
copied
a
couple
of
people
that
is
active
in
the
dev
networking
group
and
said
that
we
wanted
to
hear
from
the
death
networking
group
on
their
perspective
on
m
a
and
I
asked
of
the
response
from
from
giannos,
and
he
told
me
that
Greg
will
talk
about
death
net
than
M
A.
Our
new
light
six
I
think
it
was
that
the
deity
gave
me
I'm
gonna.
Ask
him
to
check
my
my
mail.
C
I
E
E
B
All
right
so
these
were
these
are
three
questions.
We
were
on
the
list,
there's
a
little
mild
discussion
on
the
on
the
list,
but
we
thought
it
was
worth
discussing
a
bit
on
here
because
it's
not
clear
that
everyone
buys
into
these
questions
or
understands
understands
them.
So
next
slide.
Please.
B
So
the
first
question
is
to
determine
whether
the
working
group
is
content,
that
the
hardware
that
we're
likely
to
have
in
the
field
is
going
to
be
deployed
along
an
LSP
when
the
m
a
finally
gets
deployed,
whether
it's
capable
of
modifying
a
field
in
the
in
a
in
a
label
stack
entry
that
is
below
the
top
of
Stack,
without
creating
an
undue
burden
of
performance
on
or
an
undue
burden
on
implementation.
So
next
slide,
please.
B
So
here's
the
background
some
ISD
use
cases
require
a
p-rooter
to
we're,
not
so
much
worried
about
PES,
but
a
some
ISD
use
cases
require
a
p
router
to
be
able
to
update
a
field
within
the
the
in
stack
data.
No
more
fast
re-route
was
one
case
and
Greg
is
going
to
talk
about.
Greg
Tariq
is
going
to
talk
about
that
separately.
B
B
B
So,
for
example,
we
need
to
know
you
need
to
consider
whether
the
forwarder
has
a
read-only
cash
I
I,
don't
know
whether
the
implementations
do
that
they
could
legitimately
do
that
for
the
mpls
as
it
exists
today
does
does
a
right
cause
a
significant
performance
hit.
Does
the
forwarder
support
arbitrary
modifications
of
an
lse
further
down
the
stack
or
is
the?
Is
the
forwarder,
perhaps
a
match
substitute
for
order?
There
have
been
some
people
have
been
speculating
on,
though,
or
actually
deploying
those,
although
mainly
in
the
research
community,
so
I
think.
B
B
H
All
right,
as
I
tried
to
say
politely
on
the
list,
and
maybe
I
was
just
not
clear
enough.
Your
question
as
you
just
phrased.
It
assumes
that
we
have
agreed
that
we
have
a
need
for
modifying
data
deeper
in
the
stack
I.
Don't
believe
we
have
such
an
agreement.
I
don't
object
to
asking
the
question,
but
I
am
very
concerned
about
any
interpretation
of
the
answers
to
the
question
because,
frankly,
I
don't
see
that
it
affects
any
of
the
proposals.
I've
seen
I
look
forward
to
tarek's
discussion
of
the
nfrr.
H
You
know
like
that,
but
the
proposal
that
we
had
on
the
list-
maybe
not
the
current
one-
didn't
do
that
and
when
I
talked
to
the
dead
net
folks.
Well,
yeah
researchers
are
inventing
things.
Researchers
invent
things.
That's
doesn't
create
a
demand
for
us
to
do
it.
We,
as
a
working
group,
have
not
agreed
that
we
have
such
a
need
and
I,
don't
think
any
of
the
current
technical
proposals
for
ISD
or
PSD
or
the
discussion
of
PSD
is
conditioned
on
such
an
assumption.
B
Well,
we
can
have
an
additional
question,
I
suppose,
which
is
do
we
need
to
modify
in
stack
data?
As
do
we
need
to
have
this
feature
in
the
first
place,
that
will
be
a
legitimate
question:
zero.
J
B
J
B
So
I
I
am
now
confused
by
by
by
what
you
said
Tony,
so
are
you
saying
that
we
should
essentially
ask
this
question
or
design
the
thing
and
well
we'll
take
it
for
granted
that
if
the
lead
is
there,
someone
will
figure
out
how
to
do
it.
C
I
It
was
user
error.
Okay,
sorry
about
that.
So
I
I
agree
with
you
that
I
prefer
the
generality
so
that
if
a
use
case
does
come
up
that
requires
it.
We
we
have
support
for
it
in
in
the
framework
and
then
what
was
designing
but
I
would
ask
the
question
which
use
cases
require
it
and
those
really
I
think
it's
incumbent
on
people
who
want
to
standardize
that
use
case
that
they
or
standardized
support
for
that
use
case
that
they
describe
how
it
works.
B
Well,
we
we
of
course
do
have
one
already
in
mpls
that
would
be
ripe
for
binding
into
that
and
that's
the
residence
time
spec
that
a
few
of
us
wrote
a
few
years
back.
But
it
would
seem
obvious
if
you're
doing
M
A,
that
you
would
somehow
or
other
bind
that
into
Mna
rather
than
set
up
a
new
LSP,
because
there
is
no
there's
an
RFC
for
the
residence
time.
B
I
B
So
it
was
for
do
with
time,
transfer
and
the
fact
that
time
transfer
doesn't
work
very
well.
If
you
have
an
unknown
amount
of
delay
of
queuing
delay
in
the
routers.
B
E
I
was
gonna
because
we're
asking
about
the
use
case
I
have
a
slide
that
I
composed,
which
which
may
tackle
the
aspects
of
your
question,
so
it
may
trigger
us.
You
know.
Maybe
this
is
not
supported,
or
this
is
how
we
want
to
solve
it
in
that
way,
or
this
way
so.
B
E
E
Okay,
so
it's
a
single
slide
really
and
it's
a
simplistic
use
case
emanates
from
a
draft
that
was
presented
at
npls
working
group,
a
couple
of
sessions
back
and
it's
about
no
further
fast
readout.
The
use
case
was
about
a
CE
dual
homed
to
multiple
PES
and
then
hpe
having
a
bypass
to
the
other
PE
and
then
there's
a
dual
failure:
not
a
single
failure.
But
in
my
case
here
it's
it's
the
same
concept
but
applied
to
a
simpler
case
so
that
we
can
trigger
discussion.
E
We
have
lsr1
as
a
point
of
a
potential
point
of
local
repair.
Lsr2
is
a
merge
point
for
a
bypass
tunnel
going
through
lsr3
and
we
have
a
packet,
that's
incoming
to
lsr1.
I.
Don't
think
you
see
my
pointer,
but
the
packet
is
the
bottom
on
the
bottom
left.
E
E
H
H
H
H
And
so
this
this
is
not
an
frr.
Specific
thing
is
a
general
issue
that
we
will
need
to
make
sure
we
describe
in
the
processing
does
create
a
corner
case.
If
what,
if
something
that
is
not
M
A
aware,
is
pushing
a
bunch
of
labels
on
but
I,
don't
know
any
way
to
fix
that
problem,
and
that
that's
an
interesting
question,
but
is
not
the
question
that
was
raised
and
has
nothing
to
do
with
in
stack
modification.
E
Okay,
so
Joel
I,
I
I
love.
Your
comment
and
I
would
like
to
answer
all
the
questions
you
asked,
but
I
would
also
love
to
you
know
present
all
the
questions
that
I
composed
and
it
may
open
up
more
discussion.
So
what
I'm
trying
to
say
is
I
would
like
to
continue
on
and
not
you
know,
go
to
the
queue
for
now
until
I
at
least
go
with
one
pass
one
pass
over.
D
E
Problem:
okay,
all
right,
so
we
have
the
packet
coming
in.
The
assumption
is
the
packet
is
coming
in
with
M
A
and
ISD
one,
and
it
arrives
on
lsr1
lsr1
is
affected
by
a
failure.
It
knows
that
it
has
a
bypass
and
it
wants
to
turn
on
this.
No
more
fast
reroute
action
m
a
action.
E
So
the
plr
in
fact
has
to
do
two
things:
it
has
to
set
the
no
more
fastly
route
action
and
it
has
to
impose
the
FR
label
onto
the
stack
so
that
it
steers
the
packet
over
the
bypass.
So
these
are
the
two
things
it
needs
to
do.
E
E
We
also
now
assume
that
ler
is
also
responsible
for
disposing
ISD
Prime.
Now,
whatever
we
changed.
So
that's
question
number
one.
Is
that
a
good
assumption
question
number
two
would
be
once
lsr1
sets
this
action.
Any
router
along
the
path
towards
ler
is
responsible
for
processing
this
new
action,
and
it's
not
to
be.
You
know
it's
not
a
targeted
action
that
can
stop
on
the
merge
point.
E
J
Hi,
so
this
situation
is
actually
much
more
complex
than
you've
described
it
because
you
haven't
talked
at
all
about
scope
and
scope
matters,
a
heck
of
a
lot
here
and
and
there's
a
case
three,
which
you
have
not
shown,
which
is
actually
probably
the
right
thing
to
do.
So.
J
J
You
may
want
to
insert
nfrr
with
select
scope
and
inject
that
at
right,
underneath
the
frr
label,
and
if
you
do
that,
then
once
the
frr
label
is
completed
and
removed,
then
the
nfrr
would
be
removed
and
that's
exactly
what
lsr2
should
do.
So,
if
you're
going
to
inject
nfrr
with
hot
by
hopscope
and
arguably
that's
probably
sub-optimal,
then
you
do
want
to
combine
it
with
isd1
and
case.
One
would
apply
thank.
E
E
All
have
to
consider
select
did
this.
The
select
is
interesting,
but
I'm
not
sure
how
you
can
do
select
in
current
draft.
Maybe
we
can
elaborate
on
that,
but
but
isd1
is
hop
by
hop
the
incoming
ISD
one
is
assumed
to
be
hop
by
hop
and
the
plr
and
the
plr
action
is
also
hop
by
hop.
So
in
this
case
I'm
not
allowed,
am
I
allowed
to
change,
am
I
allowed
to
change
ISD
one
and
add
additional
action.
J
E
Okay,
so
that
was
one
question
is,
as
you
see,
the
ISD
one
is
deep
in
the
stack
it's
below
the
top
label
and
I
have
to
go
and
process
the
you
know
at
least
do
a
write
on
on
the
isd1
and
change
the
whatever
is
needed.
So
that
was
one
way
to
solve
this,
and
it
goes
back
to
question
one
that
Stewart,
asked
and
and
I
think
you're
raising
a
good
point
Stoney.
But
what
case
two
is
similar
to
what
you
know.
B
So
what
the
scenario
is
that
lsr1
is
doing,
link
repair
and
the
case
that
you
have-
which
isn't
quite
shown
here,
is
that
you
actually
took
a
node
failure
and
the
danger
when
you
have,
that
is
that
you
will
get
micro
looping
until
the
system,
eventually
realizes
that
there
is
no,
that
it
is
a
node
failure,
at
which
point
it
would
normally
to
use
the
parlance,
abandon
all
hope.
And
then
we
would
race
to
regular
convergence.
B
So
this
protects
the
network
against
mistaken,
the
mistakenly
thinking
that
you're
preparing
a
leaf
painting
when
you've
got
a
node
failure.
Now
the
danger.
You
could,
of
course,
clear
the
nfrr
bit
to
lsr2,
but.
D
E
B
But
the
problem,
if
you
do
that
and
it
may
work,
but
we
do
need
to
think
very
carefully
about
it.
The
danger
is
that
you
take
another
failure
further
along
in
the
network
due
to
some
shared
wrestling
group,
an
unexpected
shared
listening
group,
and
that
requires
some
piece
of
the
infrastructure
that
you
had
assumed
was
working
but
which
has
failed,
and
so
the
whole
thing
gets
incredibly
incredibly
messy.
B
At
that
point
and
to
the
point
where
normally
the
normal
approach
in
ipfrr
is
to
say
we're
going
to
protect
against
one
single
failure,
anything
else
is
beyond
our
scope
to
repair,
so
that
would
tend
to
push
us
in
favor
of
having
a
global,
no
further
reroute
flag
for
the
the
whole
of
the
lifetime
in
this
domain
it
may
be,
it
may
be
possible.
You
can
think
your
way
out
of
this.
I
B
May
be
possible
that
I'm
being
too
pessimistic,
but
it
doesn't
need
a
a
serious
review
because
classically
we
have
never
tried
to
solve
more
than
one
failure.
E
Actually,
steward,
let
me
comment
on
this,
so
I
I
mentioned
that
the
the
example
I'm
giving
is
the
simplistic
example.
The
real
example
that
triggered
the
no
more
fastly
route
was
a
dual
homing
case.
It's
described
actually
in
the
draft
where
you
have
every
PE,
so
CE,
dual
home
to
2pes
and
every
PE
has
a
you
know
enough
for
our
backup,
pointing
to
the
other
PE,
but
the
CE
dies
completely
or
maybe
the
two
links
are
connected.
B
Applied
to
the
p-rooters
suffers
this
problem,
so
this
is
one
of
the
fundamental
problems
in
in
frr
in
terms
of
the
main,
the
main
infrastructure
getting
the
packet
across
the
network
that
you
make
an
assumption,
there's
only
a
single
failure,
and
if
which
is
the
majority
of
the
time,
there
is,
but
you
do
want
to
stop
collateral
damage.
B
If
there's
a
multiple
failure,
because
there
will
be
other
fairly
innocent,
other
innocent
traffic,
that
gets
impacted
and
you
really
would
prefer
to
kill
the
traffic.
That's
that
can't
get
there
and
leave
the
the
the
other
traffic
to
carry
on
normally
without
a
mega
congestion
incident.
So
I
I,
though
you
were
lucky
you
were
thinking
about.
B
You
were
triggered
by
a
particular
customer
problem
because
there
is
a
general
problem
to
be
solved
and,
quite
frankly,
since
most
of
the
technology
is
applicable
to
that,
we
might
as
well
solve
it
now
as
opposed
to
move
further
on
and
then
we'll
only
have,
then
a
whole
load
of
other
people
will
come
along
and
suggest
that
solving
that
problem
as
well,
so
we
should
solve
the
general
case,
which
will
also,
which
will
has
it
happens,
solve
the
specific
case
that
you
that
you
had
but
can
I
go
on
to
another
point
which
is-
and
this
is
something
that's
always
and
concerned-
I
mean
it
concerns
me
to
some
extent,
with
some
of
the
policies
that
tilfa
Etc
have
have
implemented,
which
is
that,
if
you
put
policy
in
a
network,
you
put
it
in
there
for
a
reason,
and
just
because
you
are
trying
to
get
the
traffic
to
go
in
an
emergency
repair
doesn't
mean
that
that
policy
is
not
important
to
you.
B
So,
for
example,
if
your
policy
was
to
instrument
where
the
packet
went
to
or
if
your
policy
was
to
record
how
long
it
took
or
if
your
policy
was
not
to
go
through
certain
routers
in
certain
parts
of
the
world,
for
example,
then
you
really
need
to
maintain
that
policy
irregardless
of
whether
you're
in
frr
or
not,
and
so
to
have
a
completely
new
policy.
I
believe
would
be
quite
dangerous.
B
So,
for
example,
you
know
you
can
imagine
that
if
the-
if
actually
it
wasn't
a
single
group
there,
but
a
chain
of
routers
and
well
to
be
fairly
choppy
you're,
supposing
you
were
in
Ukraine
and
your
policy
was
not
to
send
your
packets
via
Russia,
well
you'd,
rather
that
they
didn't
go
by
Russia,
even
in
the
in
the
emergency
case.
B
So
a
policy
really
needs
to
be
sticky
and
I
am
concerned
about
the
the
the
case
two
example
here,
where
you
may
create
a
different,
perhaps
lacks
of
policy
in
a
in
an
environment
where
that
would
be.
E
So
Stuart,
just
you
know,
I
I
do
want
to
contain
your.
You
know,
divide
and
conquer
basically
so
case
one,
you
said:
are
you
happy
with
ISD
one
becoming?
Is
the
one
prime
so
that
I
can
turn
on
no
more
fastly
route
action
I
think
you're
happy
with
with
that
assumption?
Yes,
right
now,
the
question
I
have
posed
is:
can
lsr2
disable
the
action
or
will
the
action
persist
below
or
Downstream
of
lsr2.
B
Well,
that's
a
much
deeper
question
and
involves
understanding
what
is
actually
going
to
happen
in
the
network.
If
you
get
a
second
in
the
case
of
IFR
ipfri,
if
you've
got
a
second
failure,
we
need
to
think
that
through
very
carefully,
because
there
are
some
scenarios
where
your
repair
strategy
will
cause
micro
Loops
in
the
event
of
a
second
fader
in
the
network.
Okay,.
E
Now
my
question
was:
genetic
was
not
really
but
no
more
fancy
route
action
once
lsr1
turns
an
action.
It
becomes.
You
know
an
action,
it's
Hopper
hop
action.
So,
as
Tony
mentioned,
I
should
speak
about
this
of
the
action.
It's
a
hop,
I
hope
so
every
node
that
this
packet
now
visits
as
exposed
to
this
new
action
that
lsr1
turned
on.
E
B
E
No,
no
I
didn't
say,
ignore
I.
Think
I
I
said
you
know,
and
the
question
I
asked
will
a
node
like,
for
example,
lsr3
that
has
that
will
see
two
Mna
in
stack
data?
Will
it
process
a
bowl
all.
B
J
E
So
if
we
go
with
sorry,
I
didn't
talk
about
case
two,
but
if
we
go
with
case
2,
as
you
will
note,
the
plr
has
imposed
the
new
M
A
with
isd2
and
with
the
select
scope
and
it
didn't
have
to
edit
anything
below
the
top
of
Stack.
So
it
didn't
have
to
change
anything
in
isd1.
E
So
really
it
did
not
have
to
bother
with
the
question
that
Steward
or
the
concern
that
Steward
had
in
question
one.
If
we
go
with
case
two,
if
we
go
with
case
one,
then
we
are
editing
something
down
below
the
top
of
the
stack
and
we
have
to
agree
on
that.
So
let
me
go
back
to
the
queue
and
low
as
at
the
top.
E
So
in
case
two
I
think
I
posed.
The
question
is
in
fact
case
two:
it
is,
it
is
going
to
be
disposed
of
when
the
m
a
is
exposed
too.
If
you
notice
the
stack,
you
know
the
FR
label
will
be
in.
You
know,
sending
the
packet
to
lsr2
and
at
that.
C
E
C
E
E
Okay,
Joel
you're
at
the
top
of
the
queue.
H
Okay,
karak,
you
alluded
to
something
that
I
was
driving
me
nuts.
In
some
of
the
earlier
discussions.
All
this
discussion
of
will
node
two
will
lsr2
remove
the
label,
the
the
m
a
well.
It
has
to
the
m
a
or
in
case
two.
The
two
mnas
become
sorry
become
top
of
stack
and
have
to
be
removed,
not.
E
H
And
that's
why
you
need
that's.
Why
case
two
is
important,
but
so
no
by
definition,
lsr2
will
not
remove
liisd
to
one
because
it
shouldn't
it's
not
the
type
of
stack
and
will
remove
isd2,
because
it
must
because
it's
top
of
stack
and
the
question
of
whether
NFR
or
there
is
no
one,
no
longer
an
nffr
and
yeah.
H
If
there's
a
failure
further
down
in
the
network,
they
could
try
to
repair
that
and
if
somebody
wants
to
invent
a
way
of
trying
to
describe
global
no
further
past
reroute,
that's
a
whole
different
problem,
but
by
definition
lsr2
must
remove
isd2
or
isd1
prime.
It
doesn't
matter
which
case
you're
in
it's
going
to
get
removed
and
so
I
mean
I
can't
stop
someone
from
doing
case
one
if
they
want
to
implement
it
that
way,
they
don't
even
have
to
implement
it
by
modifying
isd1.
H
In
fact,
I'll
probably
put
on
some
other
labels
because
they
have
to
preserve
TL,
but
that
has
weird
effects
and
that's
their
business,
and
it
will
it's
still
not
going
to
do
Global
because
there
may
be
local
labels
below
ISD
One
Prime.
It's
still
not
going
to
do
Stewart's
Global,
no
further
fast,
where
you're
out
I
personally
find
that
case.
Two
handles
all
the
cases
in
case
one
well,
I
can't
stop
someone
from
doing
it.
I
don't
want
to
describe
it
and
don't
need
to
I.
B
Steward,
so
in
terms
of
scope,
my
assumption
is
the
scope.
Is
the
mpls
network
between
well
between
gateways
to
other
npls
networks,
if
you,
if,
if
if
it's
going
to
be
a
a
multi-domain
thing,
but
it's
within
the
routing
domain,
because
that
is
also
the
scope
in
which
you
could
do
in
this
because
we're
talking
about
ipfrl,
it's
the
it's
within
the
ipfr
scope,
which
is,
generally
speaking,
the
legal
State
scope.
B
The
only
thing
I
would
note
about
case
two
is
that
case
two
pushes
a
whole
load
of
stuff
onto
the
stack,
and
so
we
get
further
into
the
maximum
stack
depth
problem
so
case.
One
is
only
going
to
push
one
label
case.
Two
is
going
to
push
possibly
n
labels.
Certainly
three.
E
Okay,
can
I
can
I
highlight
something
about
case
one
because
before
I
go
to
Hawaii
and
promise
to
come
back
to
Hawaii.
One
question
I
asked
is
is
question
one
and
case
one
is
after
lsr1
sets
this
action
and
assume
the
action
persists,
all
the
way
till
it
reaches
the
ler,
the
destination
original
destination.
E
What
it
really
are
does
not
know
how
to
consume
the
new
act.
The
the
action
that
was
set
I
mean
in
the
in
this
case
it's
just
a
flag
and
no
more
faster
route,
but
there
may
be
an
action
that
has
metadata
and
stack
metadata
with
it
and
the
egress
doesn't
know
how
to
pop
this
data.
So
how
would
plr
confirm
you
know?
The
Ingress
usually
knows
that
the
egress
supports
it.
So,
but
how
does
a
plr
know
that
the
egress
supports
it
and
that's
a
question
that
I
had
a
question?
G
Yeah
I
have
some
comment
for
case
one
first.
The
second
one
reason
we
support
our
excuse
me
so
producer
asked
is
that
it's
a
close
can
be
close
to
the
top
of
stack,
and
so
it
can
be
tailored
for
the
Legacy
devices.
So
if
the
ISD
is
too
deep
down
in
the
stacks,
then
it
can
may
not
be
readable,
reachable
so
to
support
that
I.
G
Remember
we
have
described
there
might
be
multiple
copies
of
the
could
be
all
module,
identical
copies
of
ISD
in
this
in
the
stack
right
when
the
top
one
was
removed,
so
you
can
further
expose
some
other
ideas
below
it.
So
in
this
case
it
implies
that
some
isds
are
below
in
the
last
deck
does
exceeds
the
reachability,
so
so,
which
means
only
the
top
one
can
be
writable
on
the
on
the
forwarding
pass.
G
So
that
will
cause
the
inconsistency,
because
you,
the
the
will,
never
be
aware
of
their
other
SD
copies
Below
in
this
in
this
deck,
so
that
can
cause
some
problem.
If
a
like
a
what
Joe
said
and
always
you
know,
read
all
the
you
know
pop
all
the
labels
and
I
I.
Don't
think
we
won't
support
that,
because
if
we
do
that,
then
it
basically
means
every
node
need
to
check
the
entire
label
Stacks.
Then
it's
just
a
notify,
the
or
effort
to
support
SD.
G
If
we
do
need
to
remove
all
this
label
stack,
we
can
put
everything
post
stack
and
then
we
don't
need
that
as
the
at
all
so
to
to
really
use
takes
advantage
of
the
ISD
I.
Think
there's
some
problem
for
this
kind
of
writable
actions
and
the
full
case
two
there's
a
some
problem.
Remember
the
SD
is
not
only
for
the
single
use
case.
It
can
be
component
to
support
multiple
actions.
So
if
we
put
another
SC2
on
top
of
sid1
now
we
assume
on
the,
for
example,
on
the
rsr3.
E
Can
we
stop
one?
Second?
Can
we
stop
at
case
one
concern
that
you
raised,
because
you
know
you're
saying
you
raise
the
point
about
case
one
where
the
ISD
One
Prime
is
replicated
multiple
times
in
in
the
stack
right
right,
so
that's
outside
I
mean
you're
doing
that
because
of
readable
depth.
Yes,
okay!
E
So
in
here
what
I'm
saying
is
the
packet,
the
ISD
location,
never
changes
in
case
one,
so
the
Ingress
had
made
sure
that
all
nodes
can
read
up
to
isd1
and
and
the
and
the
lsr1
is
just
modifying
a
bit
or
maybe
adding
an
action
in
isd1
Prime
we're
not
so
all
the
validation
should
have
been
done
earlier
on
by
the
Ingress
to
make
sure
that
nodes
on
the
path
can
read
isd1
up
to
isd1
right
and
then
plr
is
just
turning
on
one
action.
That's
it.
G
Yeah
I
mean
you:
you
have
a
one
top
label,
for
example,
before
some
other
label
for
for
switching
on
the
pass.
Then,
if
you
have
actions
you
you
do
need
to
pop
that
label,
then
you
need
to
re-encapsulate
this
Mna.
The
substance.
E
I
understand
your
concerned
about
the
readable
depth,
but
it's
outside
the
discussion.
I
I
think
it's
a
problem,
but
by
itself
that
we
need
to
think
of
it.
But
here
what
we're
talking
about
is,
can
we
modify
isd1,
which
is
below
in
the
stack?
Can
a
Transit
LSR?
Do
that
and
I
think
you're
saying
yes
right:
okay,
yeah!
If.
G
E
I
think
it's
an
issue
that
we
need
to
solve
about.
You
know
readable
depth
when
already
people
have
raised
that
concern.
But
here
what
we're
saying
is
a
node
is
trying
to
modify
the
in
in
stack
data
isd1
and
change
it
to
isd1
Prime.
E
B
So
so
along
the
in
the
history
of
this
discussion,
so
the
question
was
raised
as
to
whether
the
the
ler
I
think
it
was
could
pop
the
new
isd2
information
and
I'd
point
out
that
case.
One
is
unconditionally
correct
right.
You
would
never
create
case
one
unless
you
were
sure
that
the
the
target
was
could
could
dispose
of
TL
MNA
isd1.
B
What
with
case
one
all
you've
done
is
to
set
a
bit,
which
will
be
part
of
your
sort
of
checking
that
both
the
the
various
parties
could
deal
with
it.
So
I
think
case.
One
is
unconditionally
set
case.
Two
has
the
big
danger
that
someone
is
going
to
stick
some
other
piece
of
of
information
or
not
check,
end
to
end
that
the
information
in
isd2
is
processable,
so
cache
one
does
have
some
interesting
and
useful
properties
in
terms
of
validating
that
anything
can
process.
It.
K
Yeah
so
Dave,
acting
on
helping
me
out
because
I
couldn't
get
audio
so
tarek.
You
As,
I,
understood
said
that
what
happens
if
the
node
does
not
understand
ISD,
so
are
you
concerned
that
ISD
comes
to
the
top
and
no
doesn't
know
how
to
handle
it
or
and
how
to
dispose
of
it?.
E
Let
me
qualify
my
question
a
little
bit
more
detail,
so
the
Ingress,
which
I
don't
show
here
in
my
topology,
the
Ingress
before
it
inserted
isd1.
E
So
that
is
that's
clear
now,
when
the
packet
reaches
a
Transit
LSR,
it's
hard
for
the
transit
LSR
to
know
where
is
it
destined
to
by
just
you
know,
looking
at
the
Swap
label,
it
doesn't
know
what
the
target
of
the
packet
is.
It
knows
how
to
swap.
Yes,
I
agree
I
I'm,
maybe
it
will.
E
Maybe
there
is
a
way
to
find
the
target,
but
it's
going
to
be
quirky,
but
I
don't
know,
and
if
we
know
that,
then,
if
we
don't
know
the
target,
then
it's
hard
for
lsr1
to
check
the
capability
of
that
Target
because
it
doesn't
know
it
and
it
would
be
dangerous
to
add
the
action
without
knowing
it
does
it
support
disposing
of
the
action.
E
So
this
is
why
I
said
case,
one
I'm,
not
sure
but
case
two
is
definitely
clear
to
me
because
the
plr
knows
the
merge
Point
destination.
It
knows
the
lsr2
and
it
knows
the
capabilities
of
lsr2,
so
it
can
safely
add
ISD
too.
That's
my
perspective.
K
No
I
I
think
that
you're
right,
so,
if
a
no
does
not
have
information
about
which
node
will
dispose
of
this
ISD,
then
should
not
add
ASD
now.
Would
it
be
a
simple
rule.
E
Correct
yeah,
that's
the
trick
is,
would
LSR
know
which
node
is
supposed
to
dispose
of
the
data
right
I,
don't
know
that
answer
is
clear.
K
Yeah
I
think
that
that's
something
that
we
can
look
into
their
well
okay,
if
we
agree
that
that
should
be
the
requirement,
then
probably
that
needs
to
be
documented
in
appropriate
place.
But
it
seems
like
it's
logical
that
there
are
some
knowledge
about
the
network
and
capabilities,
so
only
with
that
knowledge,
node
can
do
insert
MLA
is.
E
A
Have
just
one
comment:
just
Tony
and
I
already
mentioned
this
about
the
scope
right
and
we
can
only
process
one
Mna
per
scope.
I
mean
that's
what
the
graph
says.
So
one
one
point
about
case
two
is
that
if
there
is
already
an
existing
scope
in
isd1
and
we
put
the
m
a
with
the
same
scope,
then
the
risk
is
that
and
the
bypass
path
that
any
of
that
a
minuscope
won't
get
the
exercise
right.
So
it's
just
one
caveat
to
keep
in
mind,
designing
the
cases
and
solution.
E
Okay,
just
to
confirm
what
you
said:
Rakesh
you're
saying:
if,
if
we
have
two
isds
in
the
stack
with
the
same
scope,
the
draft
does
not
address
that.
E
B
Think
that's
what
Rakesh
said
strongly
pushes
you
towards
case
one
because
case
one
is
clearly.
You
know,
you
know
the
whole.
You
know
that
the
path
can
do
everything,
that's
in
the
the
ISD
description
and,
secondly,
it
avoids
the
problem
of
policy
not
being
correctly
executed
in
this
alternate
path.
I
mean
I.
Think
it
just
seems
the
right
thing
to
do
in
terms
of
compactness
and
correctness.
E
I
I
I
find
it
okay,
because
a
few
statements
they
would.
How
do
you
know
that
any
action
that
any
Transit
node
can
turn
on
is
supported
by
the
ler?
You.
E
B
You
know
you
know
who
can
do
these
actions,
because
you
have
some
capability
mechanism
and
you
must
consult
the
capability
mechanism
as
part
of
computing.
Your
path.
E
B
E
Know
yeah
I
agreed
it's
a
bit
in
this
case,
but
can
we
put
it
I
mean?
Is
that
always
the
case?
Well.
I
B
B
The
the
the
the
constraint
that
Rakesh
put
forward,
which
is
that
you
will
only
process
an
ISD
of
one
class
in
the
packet
or
one
instance
of
an
ISD
of
a
particular
class
in
the
packet,
and
there
are
good
reasons
why
you
would
want
that
rule
to
do
with
other
sorts
of
scoping.
The
mpls
supports.
E
A
A
E
A
F
Yeah,
okay
for
the
I
I
kind
of
agree
with
Stuart.
That
case
two
may
be
problematic.
Due
to
this.
To
know
for
the
one
there's,
maybe
something
we
need
to
notice
is
that
when
we
add
the
IFR
labels
on
the
top,
maybe
the
isd1
prime
will
be
too
deep
for
some
node
to
parse.
F
A
B
E
So
I
I
didn't
see
many
objections
of
towards
isd1
Prime.
You
know
making
the
change
to
ISD
one
I
heard
you
know,
for
example,
Joel
said:
if
someone
wants
to
do
it
this
way,
I
I'm
not
going
to
object.
E
Others
also
did
not
object,
but
one
thing
that
was
still
not
clear
in
case
one
to
me
is
how
would
lsr2
turn
off
the
action
or
does
it
need
to
turn
off
the
action?
So
lsr1
turned
it
on?
Can
a
node
other
than
the
egress
turn
off
the
action.
A
B
A
B
E
H
C
E
B
B
E
Yeah
I
I
think
yeah
that,
like
I
said
from
the
attendees
today
there
isn't
major
objections,
but
your
question
is
still
you
know
on
the
list,
and
people
may
comment
further
Loa
go
ahead
and
maybe
comment
on
your
question.
C
C
Draft
and
if
we
look
for
Tony's
craft
I,
think
Tony
and
I
agreed
a
couple
of
months
ago,
actually
to
kill
that
draft,
and
we
were
waiting
for
some
other
drought
showing
up.
So
what
I
really
was
asking
for
is
what
does
the
status
of
the
draft?
We
are
waiting
for.
C
B
C
B
B
B
E
Can
we
assign
action
items
to
the
editors
of
the
framework
and
the
requirements
document
to
make
sure
that
you
know
these
are
captured.
E
A
B
B
And
it's
kind
of
a
Pity
that
Tony
isn't
here,
because
I
think
she
is
integral
to
the
to
this
next
piece
of
discussion.
So
can
you
go
to
question
two?
Please.
B
So
can
you
get
no
I?
Think
I
got
a
question.
Go
to
the
question
itself.
The
way
I
did
it
was
the
question
and
then
the
background
to
the
question.
That's
it
so
the
questions
too,
which
is
really
a
cheat.
It's
three
questions
right,
so
is
it
possible
for
a
p-rooter
to
determine
that
the
data
carried
immediately
below
the
bottom
of
Stack
is
m,
a
post
stack.
Actually
we
post
about
data
PSD
without
the
labels
that
containing
an
m
a
SPL.
B
B
So
if
you're,
a
p
router
somewhere
in
the
network,
you've
got
to
be
able
to
cope
with
whatever
traffic
the
service
provider
is
putting
through
you
and
if
you're
going
to
deduce
some
information
from
the
from
the
payload,
then
you
need
to
be
able
to
do
it
unambiguously,
because
the
way
routing
sets
up
any
Ingress
and
egress
interface
is
like
to
be
used
by
any
one
of
the
LSPs.
B
Now
I
would
note
that
a
p
router
is
unable
to
determine
if
the
label
stack
contains
a
service
label,
because
actually
all
labeled
below
the
top
are
a
bit
below
its
top
label,
are
in
someone
else's
scope
or
to
determine
the
the
service
associated
with
that
service
label,
because
again
that
that's
just
a
random
20
bits
as
far
as
the
p-rooter
is
concerned,
so
I
don't
think
there
was
a
second
comment.
Was
there
a
comment
about
PE?
Can
you
go
to
the
next
slide
right?
So
in
a
PE
we
we
do.
B
We
do
have
some
help
right.
We
know
that
the
payload
will
either
be
IP
or
it
will
be
some
service,
such
as
pseudo
wire,
some
VPN
debt
net
or
beer
and
I
think
we
could
at
the
PE,
exclude
two
cases.
One
of
the
case
is
the
use
of
m
a
post
act.
Data
in
support
of
an
Ethernet
pseudo
wire
without
a
control
word,
in
other
words,
I-
think
it's
entirely
legitimate
at
the
PE
for
it
to
refuse
any
ethernet
pseudo
are
without
the
control
word.
B
If
M
A
is
expected
to
be
supported,
so
I
think
we
can
easily
deal
with
that,
because
the
PE
is
just
a
a
private
discussion
with
its
prpe
on
the
other
side
of
the
network
as
I
was
writing.
This
I
realized
that
there
was
a
very
rare
and
maybe
now
extinct
case
that
that
existed
in
the
early
days
of
pseudo
wires,
which
and
I
couldn't
remember
the
name
for
it,
but
it
was
the
Juniper
solution
where
they
mapped
a
pseudo
wire
to
an
LSP
I.
B
B
A
service
label
and
a
suitable
first
nibble
I
think
this
points
towards
something
that
Tony
was
proposing.
That
I
was
initially
objecting
to
a
service
label
with
a
suitable
first
nibble
can
be
used
to
be
unambiguously
distinguish
between
the
intended
service
payload
and
then
the
Mna
PSD
following
the
bottom
of
Stack,
that
is
to
say
once
you're
into
the
service
label.
You
know
it's
pseudoir
or
xvpn.
B
You
can
immediately
distinguish
between
M,
A
and
anything
else.
Providing
we
allocate
a
new
label
to
it,
a
new
first
nibble
to
it
and
that's
contrary
to
what
I've
been
arguing
in
the
past,
but
I
can
see
some
sense
for
allocating
a
new
first
nibble
for
it.
B
No,
by
the
way
that
we
do
need
to
consider
the
case
of
a
PE
terminating,
both
types
of
LSP,
those
with
ethernet
PWS
without
the
control
word
and
those
carrying
m
a
PSD
but
I
think
that
is
Catered
for
because
you
can't
process
what
the
payload
until
you.
First
process
the
service
label
anyway,
so
I
think
we're
absolutely
we're
absolutely
clean
solutions
for
a
PE
I'm,
not
sure
we've
got
it
for
a
a
p-rooter.
So
can
we
go
back
to
the
question
itself?
B
That's
two
slides
by
that's
it.
So
the
question
is:
is
it
pot?
Do
we
think
it
is
possible
for
a
p-rooter
to
determine
that
the
data
immediately
carried
below
the
bottom
of
Stack
is
mnapsd
without
the
label
stack
containing
some
sort
of
hint
and
if
it
can,
how
do
we
do
it,
because
I
can't
see
a
way
of
doing
it,
but
I'm
more
than
happy
to
submit
to
someone
showing
me
how
to
do
it,
discuss.
C
B
I
think
it's
any
LSP
passes
through,
regardless
of
whether
so
the
packet
can
contain
an
m
a
it
could
control.
It
could
contain
some
payload
with
a
control
word
or
it
could
contain
both.
The
point
is
that
the
P
router
has
to
be
able
to
operate
independent
early
of
the
M
of
the
mpls
payload.
C
B
B
About
it,
so
the
pa
pa
can
should
be
able
to
construct
whatever
packet
it
wants,
but
the
P
router
should
be
able
to
deal
with
their
deal
with
them
all
of
them
simultaneously.
Once
it's
been
trained
to
to
handle
each
class
of
packet
and
do
its
things,
it
has
to
be
trained
to
do
them
all
simultaneously,
so
it
is
perfectly
legitimate
for
a
p.
Router
should
be
doing
M
A
on
one
packet,
ethernet
pseudo
wire,
with
no
control
word
on
the
next
packet.
B
Only
alternative
is
to
make
classes
of
packet
that
it
can't
handle
correct,
or
rather
in
the
the
classes
where
it
will
make
a
mistake.
You
have
to
make
sure
they're
extinct
from
the
network,
and
that
is
an
incredibly
hard
problem
and
then
actually
it's
an
attack
surface.
If
you
do,
if
you
make.
C
That
requirement
what
you're
saying
here
is
that
the
PE
originates
packets
with
an
m
a
label
in
it
and
a
control
word.
That
is
something
the
else
than
the
PSD
yeah
or
it.
It
does
not
insert
the
control
word
and
thus
only
enclose
the
m.
A
label.
B
B
D
B
A
C
B
C
B
Are
the
only
things
it
can
use
to
help?
It
are
something
associated
with
the
FEC,
but
there's
a
big
reluctance
to
do
anything
other
than
continue
with
the
ipfect
or
some
form
of
special
purpose
label
in
the
stack
anything
else.
It
just
looks
like
random
junk
and
it's
got
no
way
of
knowing
what
it
is.
C
B
E
B
Now
wait
a
minute
wait
a
minute:
let's
just
go
just
pause
the
second.
If
we
assign
a
value
to
it
at
the
PE,
the
PE
can
unconditionally
do
it
because
there
will
be
a
service
label
that
helps
it
because
in
other
words,
we
check
the
service
label
first.
If
the
service
label
says
that
it
knows
how
to
support
all
these
features,
it
will
be
fine
if
the
service
label
says
this
is
an
Ethernet
solar
wire
without
a
control
word,
it
will
deal
with
that
without
doing
any
other
stuff.
B
E
Right,
I'm
agreeing
with
that,
what
I'm
saying
is:
if
we
assign
the
value
yes
and
the
for
the
P
router,
it
will
rely
on
something
else.
It
will
rely.
B
On
them,
well,
the
P
router
will
yes,
P
router
has
to
have
an
m
a
label,
and
then,
by
the
way
it
probably
does
does
what
a
PE
does.
It
probably
looks
at
the
first
nibble
to
understand
what
the
heck
is
is
following
the
bottom
of
Stack.
B
B
Any
other
questions
I
think
this
really
needs
Tony
in
the
in
the
conversation
because
he
was
asserting
that
he
wanted
to
make
a
p-rooter
just
look
at
the
first
nibble
and
I
do
not
see
how
that
is
possible.
B
My
question:
if
you
go
back
to
the
questions,
two
just
go
back
question
two
yeah
my
question:
how
does
it
work
was
not
a
sarcastic
question.
It
was
a
genuine,
a
question
because
if
he
can
see
a
way
of
doing
it,
then
great
but
I
cannot
see
a
way
of
doing
it
and
I'm
and
no
one
has
corrected
me
in
my
thoughts
apart
from
Tony.
B
So
I
really
need
to
understand
what
case
he
is
considering
when
he
says
that
the
first
nibble
is
the
necessary
and
sufficient
for
a
p
router
to
interpret
to
understand
the
packet.
B
B
So
I'm
not
sure
we've
got
all
the
experts.
We
need
to
have
a
a
full
discussion
on
this.
B
So
I
think
maybe
this
thing
needs
to
come
back
when
more
people
are
present
or
it
needs
to
be
discussed
more
actively
on
the
list.
But
this
is
critical
because
I
I,
you
know,
I
cannot
see
how
Tony's
assertion
that
you
only
need
a
first
nibble
works.
E
Right,
I
I
agree.
We
can
stop
I
I
think
you
have
another
question
coming
up,
but
let's
hold
that
for
another
future.
B
E
Okay,
let
me
go
back
to
the
to
the
agenda.
If
there's
anything
important,
we
need
to
say,
do.
B
You
need
maybe
because
I'm
going
to
I
need
to
go
fight.
I
had
a
family
call,
I
need
to
take,
and
I
may
or
may
not
come
back
off.
E
I,
don't
think
we
need
you,
but
we
may
be
concluding
as
well.
All.
E
Okay,
thank
you,
Steward.
Thank
you
for
sharing
for
sharing
these
questions
so
attendees
we,
but
going
back
to
the
agenda.
We
do
have
a
presentation
from
Hawaii,
but
I'm
not
sure
we're
gonna
give
it
it's
it's
worth.
If,
for
the
remaining
time,
it's
up,
you
know
why
you
and
and
Noah,
do
you
think
we
should
go
through
it.
I.
C
Would
actually
I
think
the
20
the
the
thing
with
Mitek
was
that
they
close
the
meeting
pretty
quickly
after
the
expiration
of
the
time,
so
we
only
have
about
20
minutes
and
I.
Think
it's
too
short
to
do
both
the
presentation.
I
have
a
useful
discussion.
C
E
All
right
so,
with
this
I
think
we
we
have
went
over
the
agenda,
important
items
in
the
agenda,
but
at
least
the
ones
we
want
to
go
over
today,
and
we
will
stop
right
here
and
give
you
back
the
remaining
time.