►
From YouTube: IETF-MPLS-20230629-1400
Description
MPLS meeting session at IETF
2023/06/29 1400
https://datatracker.ietf.org/meeting//proceedings/
B
C
A
Maybe
turret
but
yeah.
D
Yeah,
what
what
I
would
like
is
to
upload
them
so
that
we
can
share
them
and.
C
B
I
figured
I'd,
send
it
to
both
of
you
and
you
could
figure
it
out.
Let
me
make
sure
I
sent
it
to
the
right
address,
for
you,
I
think.
B
B
B
C
C
E
C
A
D
Yes,
so
I
I'm,
looking
for
what
we
can
do
with
meat
Echo
and
as
chairs
I,
don't
think
we
can
bump
out
any
one.
We
don't
have
that
privilege
or
or
if
we
should
to
begin
with,
but
maybe
we
can
ask
for
meat
Echo
support
on
that.
B
A
Thought
there
was
a
meet
that
could
help
somewhere
yeah.
D
F
A
B
C
D
I
don't
see
steward
I
was
gonna
say
that
we
we
have
ten
attendees
right
now
and
many
missing
in
action,
including
Stuart
I,
know
that
you
have
time
constraint
and
we
should
get
started.
So
let
me
just
go
through
the
administration
slides
and
by
then,
hopefully,
we'll
have
more
people
joined.
B
C
B
May
have
forgotten
I,
don't
remember
seeing
an
an
email
from
you
with
the
agenda
other
than
the
request
for
slides
yeah.
C
A
Did
not
get
an
announced?
Okay
so
that
something
happened.
I
checked
my
outbox
and
see
what
happened.
B
H
It
was
also
listed
on
the
mpls
meetings
on
the
dose
tracker
when
I
ended
up
having
to
go
search
for.
C
A
If
anyone
wondering
what
I'm
doing
yeah
I'm
just
checking
what
happened
to
my
mail
I
think
I
sent
yesterday,
the
I
can't
find
it
so
I'm
problemist
one
way
or
another:
okay,
but
anyhow
I
uploaded
the
new
agenda
and
the
slides.
So
we
should
be
ready
to
go
if.
A
Presentation
where
do
I
share
the
I
can
share
the
agenda.
I
mean
okay,
good,
hang
on
it's
there,
okay,
so
as
usual,
and
we
get
started
and
I
think
when
we
get
to
post
the
the
share
slide,
we
opt
directly
to
what
to
hear
what
Greg
and
Tony
has
to
say
and
then
try
to
get
Stuart
back
online
and
so
next
slide.
Please
yeah
and
that's
the
note
well
shouldn't
be
any
surprises
for
anyone.
It
should
be
familiar
with
the
content
of
that
slide.
A
So
go
ahead.
The
previous
slides
has
that
one,
the
administers
administrative
slide.
So
if
anyone
anyone
that
can
participate
in
taking
notes,
please
do
so
I
think
this
is
updated.
Yes,
it
is
okay,
next
slide
and
again
again,
that
is
fairly
simple.
We
are
doing
one
again,
the
bashing.
We
postponed
the
action
items
until
Sarah
gets
back.
A
I
D
Hello
and
everyone
I
am
back,
but
on
my
Hotspot
iPhone,
so
I
might
drop
out
cell
I
have
power
outage
I'm,
not
sure.
What's
going
on
in
the
neighborhood.
D
Okay,
we
have
three
open
Action
items,
I'm
going
to
go
through
them
and
update
them
offline,
while
I
present
them
the
first
one
is
the
investigation
of
any
existing
PS
features.
So
the
owner
on
of
this
action
item
is
the
working
group
and
we
wanted
proposals
to
solicit
proposals
on
how
to
tackle
that
the
presence
of
MN
apsd
with
existing
mpls
features.
We
didn't
have
any
update
last
week,
so
I'm
hoping
we
have
something
this
week
or
we
can
postpone
for
next
week
as
well.
D
So
the
second
second
action
item:
it's
an
open
action
item
and
we
have
a
presentation-
will
be
done
by
Greg
on
that
net
intersection
with
m
e
and
that's
later
for
July.
The
6th.
D
And
okay.
D
Happen:
okay,
all
right
and
the
last
open
action
item
we
have
is
a
discussion
on
the
agenda
today:
the
presence
of
multiple
isds
and
specifically
we're
tracking
any
updates
that
are
needed
in
the
in
the
working
group
documents
that
we
have.
D
D
D
A
I
was
trying
to
do
my
best,
but
we
actually
ready
to
get.
We
need
the
Chinese
slides.
Oh
I
need
the.
D
I
D
Yeah
I
mean
this:
is
it
two
slides
I
have?
Are
you
sharing
or.
B
B
The
the
situation
that
that
caught
my
eye
is
that
the
current
protocol
draft
doesn't
deal
with
what
has
to
happen
when
an
MMA
aware
node
is
pushing
labels
onto
a
stack
that
has
at
least
one
hop
by
hop
m,
a
sub
stack
and
presumably
that's
visible
to
it
within
the
visible
region.
Otherwise
we
don't
know
what
it'll
do.
Similarly,
the
reason
I
say
an
m
a
aware
node
is
we
can't
specify
what
an
m
a
unaware
node
a
legacy,
node
whatever
you
want
to
call
it
does,
because
it
does
whatever
it
already
does.
B
But
an
aware
node
needs
to
comply
with
the
drafts
and
behave
in
a
way
that
allows
other
things
to
comply
with
the
drafts
and,
for
example,
that
the
draft
says
that
a
node
needs
to
examine
only
one
hop
by
hop
and
then
a
sub
stack
and
only
needs
to
look
in
its
visible
region,
four
things.
Unless
it
gets
an
indication
it
should
do
otherwise.
So
that's
what
we're
trying
to
address
next
slide.
B
So
what
does
it
have
to
do
if
a
node
is
pushing
labels
onto
the
stack
and
it
isn't
itself
adding
a
hop
by
hop
in
a
sub
stack?
Then
it
has
to
check
for
the
case
of
it's
pushing
the
hop
by
hop
sub
stack
outside
of
the
visible
label
range.
If
it
does
that
in
order
to
preserve
visibility,
it
has
to
copy
the
hop
by
hop
m
a
sub
stack
into
the
stuff
it's
pushing
on
in
such
a
way
that
it
is
visible,
fairly
straightforward.
You
got
to
do
this.
B
B
This
is
minimal
Behavior.
If
an
act,
if
a
node
wants
to
Define,
if
an
action
wants
to
Define
additional
behaviors
I
thought
the
action
can
Define
whatever
it
wants,
and
we
can
debate
whether
that's
the
right
thing
or
the
wrong
thing
to
do,
but
independent
of
any
specific
actions.
This
is
a
general
requirement
for
pushing
on
label
stacks
and
particularly
pushing
on
label
Stacks
that
include
ahap
by
hop
m.
A
sub
stack,
that's
what
I
said
to
the
list.
That's
what
I'm
saying
now.
Questions
are
welcome.
F
I
have
a
question
like
so:
do
you
really
need
to
copy
the
content
or
just
indicating
that
that
is
hop
underneath.
B
Now
that
you
have
to
copy
the
content,
because
as
far
because
the
rules
in
the
stacks
in
the
I
mean
we
could
make
up
an
action
to
try
to
work
around
this,
that
says,
You
must
dive
deeper
into
the
stack
but
we're
trying
to
keep
the
whole
the
the
actions
visible
in
the
visible
region
of
the
stack.
So
my
proposal
was
you
you
could
that
you
copy
the
content.
I,
guess
you
could
we
could
Define
an
action
that
you
have
to
add
to
your
stack.
B
F
But
the
thing
is
that
jonak,
if
you
have
multiple
hobby,
hop
options
right
so
then
we
need
to
copy
all
the
eBay
options.
No.
B
You
only
have
to
copy
the
next
one.
This
is
the
trick.
You
only
have
to
copy
the
one
you
can
see,
because
by
definition
it
has
a
copy
of
any
lower
ones
and
usually
they're
all
identical.
So
there's
only
one.
You
need
to
examine
it's
recursive.
The
recursion
automatically
takes
care
of
the
other
problems.
F
So
no
I
mean
like
if
you
have
a
two
different
up
codes:
how
to
help
up
codes
encoded
right
so.
B
App
codes
from
the
second
one
into
the
first
one
and
you,
but
you
don't
have
to
go
looking
for
a
third
one
to
copy
because
by
definition
the
second
one
had
the
same
content
included
the
content.
It's
a
the
higher
ones
are
a
superset
of
the
lower
ones.
So
you
only
have
to
do
it
once
and
it
just
works.
B
If
you're
worried
about
label
stack
depth,
then
the
other
alternative
is
to
create
a
difficulty
where
you
have
to
go.
Diving
looking
for
things,
and
so
I
was
trying
to
avoid
that
in
particular.
In
the
very
common
case,
where
the
only
thing
being
pushed
on
is
one
new
action,
it
seemed
to
make
much
more
sense
to
copy
the
stuff
up
than
to
tell
people
you
have
to
go
looking
past
your
visible
data,
your
visible
depth,
but
I
will
grant
you
putting
defining
an
action
that
says:
go
look
for
the
next.
F
H
Is
there
an
assumption
here?
Maybe
I
missed
it,
but
there's
an
assumption
here
right,
you're
doing
like
a
hierarchical
LSP,
so
you've
got
a
label
start
coming
in
with
hot
by
help
Mna
in
it
and
then
you're
pushing
another
label
stack
on
top
of
that,
but
some
intermediate
early
art
and
and
that
and
then
you're
copying
the
the
hot
by
help
M
A
from
that
into
the
that
outer
LSP
are.
B
Yeah
and
copy
the
the
behavior
here
is
to
copy
the
stuff
that
came
in
into
the
stuff
you
pushed
on,
because,
by
assumption
by
the
definition
of
a
hot
by
hop
LSP
a
hop
I
hop
m,
a
sub
stack,
it's
supposed
to
apply
to
all
label
all
lsrs
along
the
way,
so
you
can't
mask
it
now.
If
somebody
wants
to
Define
an
action
that
says,
don't
do
that
they
can
define
an
action,
but
this
is
the
default
required
Behavior.
J
A
H
Lsr
for
that,
the
in
that
tunneling
LSP
is
not
an
LSR
for
the
for
the
LSP
that
you're
carrying
it's
only
an
avatar
at
the
edges
of
it.
So
if
you
think
of
an
ldp
over
RSVP
case
or
a
bgplu
over
RSVP
or
over
SRT
type
of
case,
it's
only
visible
where
you
swap
that
in
a
label.
So
I'm
not
sure
that
the
hot
by
hot,
that
the
lsrs
for
that
outer
tunnel
are
actually
hops
for
the
inner
LSP.
B
H
B
No,
it
doesn't
have
to
know
the
capabilities,
because
if,
if
an
LSR
ignore
doesn't
understand
an
action,
it
ignores
it.
So
there's
no
problem
with
if
there
are
lsrs
that
don't
understand
the
action
that
the
original
head
ends
put
on,
that
does
we
don't
get
a
break
from
that.
The
question
is:
if
we
assume
it's
tunnel
mode,
one
can
one
could
argue
and
I
think
you
are
arguing
that
the
outer
that
the
original
M
A
substance
is
not
intended
to
apply
to
the
inner
tunnel.
B
Sorry
sorry
I
should
have
let
you
finish.
I
really
hope
it's
not
Case
by
case,
because
that's
a
nightmare
and,
for
example,
given
that
this
is
all
within
one
domain,
we're
not
mpls
doesn't
run
into
well.
Mpls
can
be
interdomain,
but
that's
a
different
case.
The
general
case
is
this
is
all
in
within
one
domain
and,
for
example,
if
you're
doing
ioam
in
an
intra
domain
case.
B
If
somebody
pushes
some
labels
in
the
middle
of
the
domain,
for
example,
to
do
a
reroute,
you
would
want
the
ioam
to
be
collecting
data,
preferably
by
direct
export
from
the
rerouted
path,
so
that
you
get
reported.
This
is
the
actual
pass.
It
took,
not
the
one
you
think
it
took,
and
so
there
seems
to
be
a
off.
It
seems
like
the
default
case.
Is
you
have
to
push
yeah?
H
Yeah
I
think
I
think
to
say
it's
not
doesn't
run
into
domain.
I
mean
I,
agree,
you
wouldn't
you
know
it's
not
that
common
to
have
say
an
end-to-end
RSVP
LSP
across
multiple
domains,
but
the
the
kind
of
principle
of
being
able
to
chop
things
up
into
domains
and
have
tunnels
across
those
domains
and
then
have
BCP
or
ldp
labels
within
those
tunnels.
That's
very
commonly
deployed
so
yep.
B
That's
why
I
corrected
what
I
was
saying
that,
but
but
at
least
in
the
intra-dome
internal
case,
you
would
normally
expect
the
hot
by
hap
labels
actions
to
apply
to
the
the
thing,
and
we
have
no
good
way
to
to
distinguish
them.
I
mean
oh,
creating
two
different
cases
saying
at
a
domain
boundary
you,
you
don't
copy
in
it
at
a
internal
boundary.
You
do
copy
frightens
me.
Well,.
B
I
hate
I
hate
having
local
policy
decisions
that
require
different
Behavior
by
routers,
because
that
complicates
implementation
and
complicates
diagnosis,
and
you
don't
know,
what's
going
on
so
I
really
prefer
getting
a
stable
decision.
That
is
where
alternative
behaviors
are
indicated
by
things
in
the
actions
themselves,
but
that's
just
my
opinion
not,
but
as
currently
written
that
the
current
draft
doesn't
talk
about
this
case.
We,
the
the
clear
thing,
is
we
have
to
describe
what
we
want
to
have
happen.
B
H
K
You
hear
me
now:
yeah
yeah,
hi,
okay,
okay,
yeah,
oh
yeah,
thanks
for
this
analysis,
actualizing.
This
is
something
missing
in
the
current
existing
document.
I
think
this
is
maybe
one
option
of
the
behaviors,
but
I'm
not
sure
this
should
be
the
default.
One
actually
for
different
cases
has
just
discussed
with
Matthew.
Maybe
different
behaviors
will
be
required,
like
in
this
case,
Joe
mentioned
that
the
a
copy
of
the
content
of
this
the
next
hub
MMA
should
be
copied.
K
B
I,
if,
if
there
is
that's,
why
I
said,
if
there's
an
action
that
wants
to
cause
a
different
behavior,
that
is
specific
to
the
action,
this
is
the
default
required
behavior.
In
the
absence
of
an
overriding
action.
I
do
not
want
to
have
some
nodes
deciding
they
have
to
copy
and
some
nodes
deciding.
They
should
be
inserting
things
into
other
m,
a
sub
Stacks
that
if
you
want
that
differentiation
that
is
clearly
triggered
by
some
specific
action
and
that
action
should
Define
that
behavior,
not
the
default
base.
Matthew's
case
is
a
different
point.
B
His
point
is
that
independent
of
the
actions
there
may
be
a
situation
where
we
need
to
do
something
different.
That
requires
more
analysis.
I
really
hope
it
turns
out
not
to
be
the
case,
but
I
can't
tell
and
I'm
not
going
to
try
to
I
certainly
am
not
going
to
assert
that
he's
wrong,
because
he
raises
a
valid
case,
but
in
terms
of
if
you
have
some
specific
action
that
requires
copying
it
down
that
the
action
that
defines
that
not
having
a
knob
that
you
have
to
implement
so
that
all
routers
have
to
implement
that.
B
Even
if
they
don't
implement
the
specific
action
that
might
require
that
I
I,
we
should
be
aiming
to
avoid
creating
multiple
choices
for
how
actions
behave
and
how
how
lsrs
behave,
because
every
time
we
introduce
a
choice,
we
complicate
the
test,
the
interoperability,
we
complicate
the
testing
and
we
complicate
the
implementation.
So
we
want
to
avoid
choices.
That's
the
ietf
preference,
that's
distinct,
one
of
the
historic
distinctions
between
the
ITF
and
the
itut.
B
If
there
are
cases
where
we
must,
then
we
do
have
to
allow
choices
and
that's
why
I
need
more
time
to
think
about
Matthew's
case
but
having
an
action
that
causes
you
to
copy
things
into
other
sub.
Stacks
well,
I
want
to
see
the
proposed
action,
and
then
we
can
debate
whether
we
agree,
that's
what
it
should
do,
but
if
it's
needed
it
should
be
in
the
description
of
the
action
not
having
descriptions
of
multiple
required
different
required
behaviors,
where
the
operator
has
to
configure
it.
That's
that's
a
recipe
for
failure.
B
K
For
me,
I
agree
that
for
each
specific
application,
where
you
should
the
also,
if
you
avoid
the
different
options
or
beef
behaviors,
but
if
we
already
observe
the
possibility
of
different
use
cases
which
require
different
behaviors,
maybe
in
the
like
the
base
document,
we
should
make
people
aware
that
this
is
all
the
required
behaviors
to
make
this
mechanism
work
as
a
complete
solution
before
we,
instead
of
when
we
introduce
a
new
application,
and
we
need
to
update
that
this
based
argument
right.
B
And
we
thought
that
I
disagree
until
we
have
an
action
defined.
That
requires
a
different
Behavior.
There
is
no
point
in
describing
a
different
behavior
and
anybody
who
cares
about
that
action
will
read
that
action
and
know
they
have
to
implement
it.
We
are
not
going
to
require
implementers
to
implement
behaviors,
for
which
there
is
no
use
case.
B
So
it's
until
the
action
is
defined
that
causes
things
to
get
copied
into
other
sub
stacks.
There's
no
need
to
describe
it
and
when
the
action
is
defined,
that
action
describes
it.
And
then,
if
we
adopt
that
as
a
working
group
thing
and
then
we
publish
it
folks
who
implement
it
will
do
it.
But
there
is
no
expectation
that
every
router
is
required
to
implement
every
action
that
was
part
of
Matthew's
point.
K
Yeah
I
think
last
time
Stuart
mentioned
in
the
case,
which
is
two
indicator:
no
for
the
first
result
and.
B
He
asked
he
said
he
described
a
case
that
is
not
the
same
as
the
currently
described.
No
further
fast
reroute
I
I
called
it
stop
reroute,
but
you
could
call
it
whatever
you
want,
but
it's
a
different
Behavior
we're
going
to
need
two
different
actions,
one
for
the
current
thing,
one
for
what
stewards,
when
Stewart
writes
up
a
description,
I'm
not
going
to
attempt
to
read
his
mind
about
why
the
draft
he
points
to
requires
it
when
there's
a
write-up
of
an
action
that
does
the
make
sure
nobody
anywhere
on
the
path
does
reroute.
B
K
D
E
Sorry
meet
Echo
is
not
letting
me
turn
my
mic
on.
So
I
would
like
to
take
an
issue.
Take
issue
with
something
Joel
said
about
what
happens
when
we're
inserting
an
action
into
a
label
stack
that
has
hop
I
hop
when
we
are
inserting
new
actions.
E
If
the
semantics
that
we
are
inserting
has
a
SK
has
a
applicability
throughout
the
length
of
the
label
stack,
then
the
node
that
is
doing
the
insertion
is
going
to
have
to
amend
all
of
the
hop
by
hop
headers
throughout
the
label
stack
and
in
fact,
in
the
general
case.
The
point
is,
you
have
to
amend
all
the
hop
by
hop
headers
that
you
can
find
that
cover
the
length
of
the
semantics
that
you
want
for
that
action.
B
Can
we
agree
on
that?
No
I,
so
I
I
I
two
two
disagreements.
First
I
think
there's
only
two
plus
two
meaningful
bounds
because
and
a
note
inserting
things
isn't
going
to
know
the
significance
of
the
various
nodes
in
the
middle
of
the
label
stack
either.
It
applies
for
the
length
until
the
thing
it's
inserted
gets
popped,
which
is
the
normal
case,
or
it
applies
to
the
whole
thing.
B
E
B
Because
because
the
originator
didn't
think
it
needed
entropy,
so
only
over
the
scope
over
which
this
pushed
label
the
pushed
labels
are
being
defined.
Does
this
node
really
have
control,
and
it's
defining
that
it
wants
to
add
entropy
over
that
scope?
That's
fine!
It's
privilege,
but
I
would
not
assume
that
by
default
it
has
to
go,
find
all
the
other
label
sub
stacks
and
add
entropy
to
them
and
first
figure
out
if
they
already
have
entropy
and
see
what
what
decide
what
it
does
with
the
entropy
that
it
already
has.
B
Identifier
only
applies
over
the
scope
over
which
we're
pushing
it.
You
can't
there
may
not
be
an
NRP,
a
slice
to
be
bound
to
beyond
that.
It
only
knows
the
scope
over
which
it's
it's
directing
the
traffic.
If
it
wants
to
direct
the
traffic
over
Inlet
work
resource
partition
over
the
part
it
has
charge
of
because
it
pushed
those
labels
on
it
does
so,
but
it
was
if,
if
the
packet
was
supposed
to
be
directed
to
a
a
network
resource
partition
over
the
whole
domain,
then
the
entry
should
have
done
that.
B
B
D
Okay,
thank
you
I'm
next,
so
I'm
going
to
go
ahead.
Last
time
when
we
presented
the
the
bypass,
you
know
adding
an
action
we
said
we
could
do
it
in
two
ways.
One
is
adding
a
new
ISD
sub
stack
and
the
other
was
to
amend
the
existing
one.
D
D
So
can
we
amend
the
existing
one
and
I
guess
from
what
I'm
hearing
it's
a
discussion
of
what
is
the
scope
of
the
a
new
action
being
added?
If
it's
just
between
the
plr
and
merge
point
or
between
the
new
Ingress
and
a
new
egress,
then
we
have
choices
there.
But
if
it's
a
global
scope,
that's
a
we
could
amend
the
existing
hop
help
so.
F
B
Scope
we
have
to
amend
all
the
sub
stacks.
I
cannot
construct
any
situation
in
which
it
makes
sense
to
amend
just
the
top
sub
stack,
because
then
you
don't
remove
it
at
the
end
of
at
the
bound.
You
don't
remove
the
new
information
at
the
boundary
of
the
then
pushed
labels,
but
you
remove
it
at
the
next
point
because
it
because
it's
not
going
to
get
copied
further
down,
so
it
would
be
a
really
strange
case
to
be
modifying
just
one
other
one
that
we've
been
discussing
the
case
of.
B
Do
you
need
to
modify
all
of
them?
We
can
have
that
discussed,
and
that
needs
to
be
discussed
more
on
the
list.
I
really
don't
like
that,
but
I
can't
I
can't
assert
we
don't
we
should
we.
We
should
never
do
it.
We
need
to
discuss
that
on
the
list,
but
modifying
just
the
top.
One
produces
just
a
mess.
B
D
D
J
Right,
it
looks
not
on
the
list
all
right
well
that
myself
back
on
I
I
I'm,
not
sure
whether
I
am
correct
about
maximum
redundant
trees
requiring.
J
Nfrr
being
sticky,
but
the
the
fundamental
reason
for
concern
is
that
it
no
further
reroute
on
in
the
presence
of
any
failure
is
so
fundamental
to
IP,
fast
reroute,
that
it
makes
me
incredibly
nervous
if
it's
not
sticky
and
I
need
to
go
back
and
look
at
some
work.
I
mean
hit,
you
know,
maybe
15
years
ago
or
so
and
remember
what
the
specific
cases
were,
but
we
often
got
into
trouble
if
we
tried
to
repair
a
following
a
little
repair
to
the
extent
where
the
general
consensus
of
the
IP
fast
reroute
Community.
B
J
J
I'll
have
to
go
back
and
think
what
we
did
20
years
near
nearly
20
years
ago.
I
suppose
why
we
came
to
that
conclusion,
but
it
is
absolutely
fundamental
to
to
what
we
always
do.
J
B
My
my
memory
I
mean
Stuart
I
was
there
my
memory
was.
That
was
the
case
of
if
you
get
a
second
failure,
while
you're
on
the
failure,
recovery
path,
no.
J
J
No,
the
problem
is
that
it's
just
too
complicated
to
work
out
what
all
the
strategies
are
and
which
ones
crash
that
the
general
consensus
was
that
we
would
never
even
attempt
it.
But.
J
I'll
have
to
go
and
look
at
that
really
early
work
and
find
out
why
we
decided
to
do
that,
but
abandon
all
hope
was
a
standard
thing.
We
did.
J
I'll
find
I'll
see
if
I
can
find
out.
Some
remember.
B
Was
as
I
said,
if
we,
if
we
agree
if
nffr
needs
this,
don't
ever
do
that
or
if
we
Define
two
actions,
one
nfrr
over
recovery
path
and
one
never
refused
to
do
frr
anywhere
further
in
the
path.
Those
are
specific
actions
which
we
can
Define
as
requiring
pushing
it
on.
Even
if
the
general
Behavior
says,
here's
what
you
do,
because
even
if
you're
pushing
that
action
into
other
things,
you
still
have
the
problem
that
other
actions
which
don't
need
to
be
pushed
into
every
individual
thing
require
this
base.
B
Behavior
to
preserve
the
semantics
of
hot
by
hap
m,
a
sub
stacks.
A
Okay,
so
a
couple
of
questions,
smaller
questions,
I
hope.
So
we
we
have
this.
You
have
described
consecutive
copying
of
one
network
action
up
into
the
stack.
How
much
will
this
course
a
stack
to
grow
and
if
it
does,
is
it
the
problem.
B
Well,
it
would,
it
will
cause
the
stock
to
grow
less
than
if
you
take
the
entire
stock
you're,
adding
and
copy
it
into
everything
below
it,
and
you
still
have
to
somehow
I
mean
Matthew.
The
the
that
there
wasn't
some
somebody
suggested,
the
other
alternative
of
putting
in
single
action
into
the
new
sub
stack.
That
says,
go
look
for
the
next
one!
That
is
a
viable
alternative
and
we
should
evaluate
that
which
does
reduce
the
label
growth.
That's
that's
the
one
attraction
of
that
alternative.
A
B
I
believe
we
have
the
problem,
no
matter
what
Behavior.
We
dissolve
the
fact
that
you
need
to
meet
the
requirement
that
you
only
have
to
examine
one
hop
by
hop
label.
One
hopper
hop
sub
stack.
If
we
want
to
change
the
base,
Behavior
to
say,
You
must
examine
all
hop,
I
hop
sub
stacks.
B
That
would
be
different,
but
I
wasn't
trying
to
change
that
base.
Behavior
it's
in
the
in
the
draft
we've
adopted
as
a
working
group.
A
A
Okay,
nothing
else
not
framework,
not
requirements,
not
use
cases.
B
I
I
wasn't
thinking.
I
wasn't
expecting
I
believe
that
this
behavior
is
an
implication
of
what
is
already
in
the
requirements
and
the
framework
it's
just.
We
didn't
put
it
into
the
the
ISD
description
document,
so
we
and
as
long
as
it
gets
into
the
ISD
description
document,
implementers
will
know
they
have
to
do
it.
B
The
120
is
editing
what
I
don't
remember.
I,
don't
remember
the
draft
names,
the.
C
E
One
correction
I
did
an
editing
pass
on
it,
but
I
have
handed
editorship
back.
Oh
because.
B
E
B
Well,
the
first
of
these
two
bullets,
for
example,
appears
to
be
absolutely
necessary
and
not
subject
to
argument
and
so
I
would
require,
and
that
needs
to
be
said
in
the
document.
We
need
to
agree
on
what
has
to
be
said
about
the
second
of
these
two
bullets
and
that
needs
to
be
discussed
on
the
list,
which
is
why
I
prefer
list
discussion
to
interim
discussions.
B
E
D
Thank
you,
Joel
and
Tony
on
this.
Next,
we
want
to
switch
to
the
discussion.
A
A
So
you
will
be
back
on
the
mailing
list.
I
think.
C
D
The
you
know
what
I
need
to
switch
off
my
hotspot,
so
are
you
able
to
click
on
the
the
share,
slides
button
and
you'll
see
the
presentation
from
Jimmy.
D
D
I
C
A
E
A
K
So
here
is
some
analysis
about
the
limitations
with
the
MMA
ISD,
and
the
purpose
is
not
to
say,
I
think
is
not
useful.
It's
just
to
show
the
possible
limitations
in
the
current
design,
and
also
with
this
limitations
in
mind,
we
may
consider
in
some
scenarios
PSD
will
be
needed.
Okay,
let's
page
this.
K
We
first
firstly,
I'd
like
to
remind
people
that
the
purpose
of
the
ISD
design
is
one
of
the
purposes
that
to
make
the
m
a
information
close
to
the
top
of
the
label
stack
so
that
the
Legacy
devices
can
parse
and
process
it
and
I.
Actually,
it's
not
just
for
the
luxury
devices.
It
can
also
help
to
make
the
some
of
them
a
information
readily
accessible
for
all
the
network
nodes
along
the
path.
K
But
this
also
indicates
that
the
size
of
the
ISD
should
be
relatively
small,
like
the,
for
example,
three
RCS
or
even
less.
This
is
a
based
on
some
of
the
data
we
collected
from
the
existing
devices
capability.
Otherwise,
you
will
have
a
bigger
data
for
the
m.
A
it
would
be
need
to
be
encapsulated,
as
PSD
as
putting
it
in
IST
would
make
the
purpose
of
the
easily
accessible
for
the
Legacy
and
for
the
other
nodes,
not.
K
K
Among
this
label
stack
tabs.
We
also
need
to
consider
some
of
the
labels.
Usually
we
need
two
or
more
labels
for
the
tunnels
and
for
the
service
Etc
for
Segment
routing.
We
would
need
more
labels
being
used
for
the
tunnels
with
this,
and
it
leaves
the
Maybe
three
to
five
rses
for
the
total
length
of
the
ISD,
and
if
we
consider
the
size
of
the
ISD,
it
will
include
the
MMA
label
and
followed
by
a
format
brse.
K
E
E
E
E
K
K
For
the
PSD
it
may
we
can
have
another
analysis,
maybe
if
needed.
K
K
K
That's
why,
in
the
previous
page
yeah
the
last
one
is
we
also
need
to
consider
if
we
need
to
encapsulate
multiple
isd's
into
the
label
stack.
Let
me
have
some
requirements
on
the
number
of
RCs.
The
increase
node
is
capable
to
impose.
So
this
is
another
thing
we
need
to
consider
which
can
bring
some
limitation
to
the
size
of
the
ISD
can
be
supported
by
the
Ingress
node.
K
K
K
E
K
K
D
Want
one
second,
Tony
I
think
that
yeah
I
mean
the
Jimmy's
trying
to
ask
questions
on
the
proposal,
so
I
I
appreciate
Tony
coming
in
and
answering
the
questions,
but
we
have
Greg
also
on
the
Queue
I
want
to
give
him
a
chance
to
pick
his
raising
step.
D
And,
and
do
you
want-
and
you
know
basically
asking
questions
at
any
time-
Jimmy
or
I
I
guess
you're
asking
questions
so.
D
Yeah,
it's
valuable
that
yeah.
G
G
So
we
need
to
have
possibly
extension
or
use
extensions
that
already
exist
in
igp
and
vgp
that
were
introduced
for
similar
situation
with
the
entropy
label,
but
I
think
that
it's
up
to
developers
to
decide
what
options
in
ISD
M
A
they
want
to
support
and
on
what
platform.
So
I
think
that
the
question
the
main
question
that
raised
or
concern
expressed
is
not
really
there.
So
it's
not
technical.
It's
you
know
business
decision
what
you
support,
so
thank
you.
G
Yeah
I
I
believe
that
the
whole
motivation
of
this
saying
that
ISD
m
a
must
be
applicable
on
all
existing
platforms
deployed
regardless
of
their
physical
computational
capabilities
is
not
technical.
G
G
That
we
have
to
leave
for
ISD
with
certain
inconveniences,
as
you
pointed
out,
that
take
make
this
data
space
somewhat
awkward.
But
again,
if
you
look
at,
for
example,
a
proposal
on
supporting
IEM
decks
as
instant
data
m
a
it
might
be,
not
pretty,
but
it
will
work
so
again.
C
K
K
Yeah
I
think
we
I
agree.
We
need
to
discuss
the
technical
issues,
but
we
also
need
to
consider
the
reality
of
the
network
if
we
want
to
make
this
mechanism
really
applicable
and
really
can
be
deployed
in
the
Brownfield
Network.
We
also
need
to
consider
the
imitational
capability
of
the
existing
Hardware
is
something
we
I
think
we
have
been
considered
in
the
in
the
past
right.
G
I
agree
with
you
that
we
might.
G
Okay,
so
there
is
all
joke:
medical
joke.
The
guy
comes.
K
K
G
Yes,
I
think
I'm,
talking
guide
comes
to
the
doctor
and
says
Doctor
I
pressed
this
every
everything
hurts
doctor
looks
at
him
says
you
have
a
broken
finger.
G
Okay,
so
if
a
network
is
a
limited
capacity,
then
it
should
not
use
ISD
m
a
and
vendors
and
implementers
must
understand
their
implication
of
introducing
ISD
M
A
in
their
existing
Networks
so
and
work
with
operators
on
how
to
overcome.
C
D
C
D
Let's
do
this
is:
is
this
the
last
slide
Nick
for.
I
D
K
Okay,
okay,
sorry
I
I
think
I
reconnected.
So
this
is
about
the
format.
The
second
bullet
is.
Do
we
allow
the.
E
Okay,
Jerry
was
about
to
ask
whether
tlv's
format
is
supported
in
the
opcode,
and
the
answer
is
that's
completely
up
to
the
opcode.
The
action
gets
to
Define
what
its
ancillary
data
is
like
and
it
may
be
TLD
formatted.
It
could
be
an
MIT
Tico
macro.
It
could
be
a
list,
s
expression,
we
really
don't
care.
You've
got
30
bits
of
opaque
data,
do
whatever
you
like,
have
fun.
D
Bad
here
feel
free
to
manage.
I
I
was
going
to
say
that
Tony
had
tried
to
answer
your
question,
but
I'll
just
go
on
go
on
silent
now,.
K
Okay,
okay,
the
point
is:
if
we
introduce
the
tlv
format
for
the
data
field
of
the
code,
we
need
to
deal
with
the
like
the
different
IRS
RAC
formats,
and
also
the
S
bit
in
the
which
is
in
the
middle
of
the
data
field
and
with
the
tlv
we
will,
it
will
introduce
some
difficulty
if
you
did
for
different
combination
of
the
tlvs,
you
will
need
to
put
the
data
at
different
position
and
then
you
also
need
to
consider
the
not
to
conflict
with
the
aspect
right.
K
This
is
something
we
need
to
consider
in
addition
to
the
previous
in
other
data
packet
or
the
data
plane
extensions.
K
K
Can
we
accommodate
this
into
the
a
specific
up
code
in
the
ISD
because
of
this,
like
the
the
position
of
the
aspect
and
other
fields
introduced
in
the
different
areas
formats?
So
this
is
something
I
think
it
would
be
a
little
bit
difficult
for
the
M
A
ISD
encoding.
G
K
No
I'm
saying
we
have
a
specific
application
for
if
we
want
to
use
the
iom,
we
have
iom
data
format
already
defined
as
a
independent
encapsulation,
which
is
can
be,
which
was
designed
to
be
applicable
to
different
data
transport,
like
all
the
network
data
plane
like
the
IPv6
or
mprs.
G
Yeah,
if
I
may
yes
but
I
again,
look
at
it
as.
C
G
Have
and
not
something
that
must
to
have
and
that's
the
result
of
ippm
working
group
defining
its
format
without
consideration
of
data
plane.
Issues
on.
C
G
Hand
we
have
mechanisms
in
IP
that
and
mpls
doesn't
use
an
IP
encoding.
One
of
the
examples
is
icmp
think
so:
NFLs
decided
to
implement
this
functionality
differently,
and
actually
there
are
some
things
that
were
developed.
Some
functions
that
were
developed
for
MLS
LSP.
C
G
G
Has
different
constraints
and
we
must
make
the
best
out
of
what
we
have.
K
Yeah,
that
is,
that
means
additional
effort
is
needed,
because
that
the
application
may
not
be
designed
for
IPv6.
It
is
designed
for
a
unified
as
a
unified
application
for
different.
K
Foreign
and
maybe
that
night
will
be
something
we
can
consider
as
the
applications
we
which
is
being
worked
on
in
a
specific
working
group,
and
they
may
want
to
okay,
have
a
unified
encapsulation
for
different
data
playing.
Okay.
G
For
that
net,
can
we
put
it
on
the
back
burner
and
talk
about
it
next
week
because
I'll
be
presenting
that
net
and
it's
view
because
we
are
discussing
in
the
devnet
with
chairs.
K
Okay,
okay-
and
this
is
not
not
only
about
the
death
net
and
iom
I-
just
give
use
them
as
examples
like
different
working
groups
are
working
on
different,
maybe
data
playing
mechanisms
and
they
they're
not
aware
of
the
difference
between
a
data,
IPv6,
MPS
or
ipv
V4.
K
Okay,
I
think,
then
we
come
to
the
processing
limitations.
This
is
a
about
something
we
discussed,
maybe
in
the
previous
one
or
two
weeks,
but
whether
we
can
change
them.
Some
of
data
in
the
MMA
ISD
actually
I,
think
the
draft
already
mentioned
that
to
avoid
impact
to
the
traffic
flow
forwarding
to
the
balancing
the
first
20
base
at
the
previous
label.
Field
of
every
LC
in
the
ISD
must
not
be
changed.
K
So,
let's
leave
a
very
small
room
for
the
writable
data
in
the
different
RC
formats
like
for
the
LC
form
might
be
all
the
data
are
not
allowed
to
be
changed
for
the
former
C.
There
are
seven
bits
left
and
for
format
D
in
there's,
11
bits
and
another
processing
limitation
is
something
we
discussed
last.
If
we
want
to
modify
the
LCS,
which
are
not
at
the
top
of
the
label
stack,
let's
require
a
new
Behavior
to
the
MPS
implementation.
K
K
Okay,
I
think
this
has
been
discussed
recently
and
just
here
it
just
the
documents
as
a
one
possible
limitation
in
the
ISD
processing
and
for
some
of
the
use
cases,
and
this
may
not
be
required,
but
as
a
solution,
we
need
to
consider
these
limitations.
K
We
hope
this
limitations
can
be
understood
by
the
amperes
working
group
participants
and
the
documented
in
the
suitable
document
in
the
working
group
and
for
some
of
the
applications
which
required
to
break
these
limitations
like
the
data
size
or
encoding
or
processing
PSD
will
be
needed
I
for
the
iom
cases
in
some
modes.
The
data
size
and
encoding
would
require
to
maybe
to
exit
the
limitation
with
the
ISD
and
the
death
net
is
a
similar
case.
No
further
fast.
Reroute
requires
some
specific
data
processing,
which
brings
some
difficulty
to
the
ISD
processing.
K
Okay,
so
it
says
to
answer
the
questions
of
the
working
group
chairs
for
the
first
one,
I
think
the
iom
and
that
had
two
possible
use
cases
which
would
need
a
PSD
due
to
the
data
side
limitation,
and
in
this
in
this
presentation
we
didn't
talk
about
the
complexity
of
the
PSD
or
the
ISD.
He
said
just
about
the
capability
and
the
limitations
with
the
ISD
design
and
for
the
as
data
and
stack
tabs
increase.
K
Regarding
the
compatibility
issue
with
the
PSD.
Previously
we
discussed
the
possible
order
between
the
PSD
and
other
post
stack
data
I
post,
that
information
I.
Guess
we
have
reached
some
consensus
that
the
PSD
will
be
the
immediately
follow
following
the
bottom
label,
and
other
information
will
be
followed,
postdoc
data,
so
that
will
be
a
resolution
to
this
compatibility
issue.
E
G
D
G
G
Interaction
with
their
death
net
because
I
don't
find
their
in
this
presentation.
Any
technical
cases
that
indicate
that
depnet
would
benefit
from
PhD
and
I
can
say
that,
from
our
analysis
that
we're
doing
in
a
definite
group,
it's
quite
opposite.
Actually,
PSD
is
not
a
good
case
for
that
net.
Secondly,
on
amount
of
data:
yes
in
case
of
incident.
C
G
Yeah,
it
defines
the
mode
that
adds
operational
State
and
the
information
in
the
packet.
Some
environments
might
decide
to
use
it,
but
I
think
that
it
would
be
unwise
to
do
it
in
npls
network
and
definitely
it's
absolutely
prohibitive,
behavior
in
death
net,
where
the
resources
for
the
data
traffic
must
be
planned
ahead.
So
I
think
that
a
direct
expert
is
a
reasonable
option
for
npls
data
plane
to
use
to
get
this
on-paf
information
and
that
can
be
done
in
ISD.
We
already
have
a
proposal
for
that.
G
So
with
everything
else,
I
don't
see
a
lot
of
concerns.
Thank
you.
E
So
I'd
like
to
point
out
that
the
Legacy
implementations
that
have
difficulty
dealing
with
arbitrary
arbitrarily
large
ISD
are
going
to
have
even
more
issues
dealing
with
PSD
a
typical
Legacy
implementation
is
only
going
to
be
able
to
see
some
way
into
the
top
of
the
label.
Step,
say
64
bytes
and
if
it
can
only
see
64
bytes
of
label
stack,
there's
no
way
it's
going
to
also
be
able
to
see
PSD.
K
Yeah
with
psds
I
think
the
benefit
is
some.
The
luxury
devices
does
not
need
to
be
aware
of
this
PSD
data
and
right
and
with
the
ISD
there's
a
possibilities.
It
need
to
understand,
I
mean
label
and
it
won't
try
to
pass
the
ISD,
but
this
exceed
the
capability
of
the
hardware,
and
that
is
something
we
don't
want
to
see
in
the
in
the
in
the
network.
E
K
As
a
negative
way,
you
consider
some
application
yeah
if
we
consider
what
application
is,
cannot
be
parsed
by
Lux
in
order
with
either
sdl
PSD.
That
I'm
not
sure
whether
this
is
a
still.
We
want
to
use
ISD
to
carry
this
information
or
not.
So
this
is
a
limitation
with
ISD
I'm,
not
saying
the
PHD
is
a
solution
to
the
Legacy
device,
just
to
say
that
if
we
want
to
lock
the
device
to
pass
ISD,
we
need
to
consider
the
limitations.
K
The
Galaxy
Device
cannot
support
yeah
that
that
means,
if
we
consider
the
luxury
device,
is
not
our
Target.
We
can
revisit
whether
it's
a
deserve
to
be
put
in
the
label
stack
or
it
is
a
more
applicable
to
as
a
PSD.
K
K
I'm
not
saying
about
the
I,
don't
know
I'm
talking
about
a
specific
application.
If
the
due
to
the
limitation
of
the
kit
Hardware
in
the
Luxy
node,
it
cannot
be
passed
in
either
as
the
PSD,
whether
we
still
want
to
put
it
in
the
ISD
or
we
just
with
some
of
the
limitations,
as
we
discussed
in
the
slides
always
has
them
use
a
more
extensible
mechanism.
K
E
D
I
I
have
a
similar
question
to
what
Tony
is
trying
to
highlight
if
I
cannot.
If,
if
there
is
a
concern
with,
is
you
know,
ISD
beam
present
in
the
stack
and
the
stock
growing,
then
how
is
this
concern
appeased
by
putting
it
in
the
PSD
and
assuming
I
can
read,
you
know,
I
can
read
after
the
stack,
so
in
both
cases
you
will
have
to
process
and
read
the
the
data
wherever
you
place
it.
D
So
if
a
node
can
I
mean
if
a
Transit
node
cannot
process
a
a
huge
stack,
it
cannot.
D
K
C
D
K
Yeah,
maybe
I
can
quickly
answer
your
question.
I
mean
that
if
we
we
know
that
for
a
specific
application,
the
Luxe
nodes
cannot
parse
it
or
cannot
process
it,
but
regardless,
whether
it
is
in
ISD
or
PSD.
So
this
application
will
only
be
understood
and
processed
by
the
new
hardware
right
then
we
need
to
consider
water.
K
It
is
beneficial
to
put
it
in
ISD
or
whatever.
It
is
better
to
put
it
in
the
PSD.
So
we
don't
need
to
consider
the
support
for
the
Legacy
Hardware
as
a
as
part
of
our
consideration,
because
no
matter
which
place
it
is
put
in
the
packet.
The
Legacy
Hardware
cannot
process
it
to
this.
For
this
kind
of
applications.
We
need
to
consider-
and
it's
sorry.
D
D
I
think
you're
saying
Legacy
devices.
That's
what
I'm
asking
is
it
Legacy
devices
that
you're.
D
K
D
D
K
D
Have
the
same
point:
I
mean
if
it's
a
limited
Hardware,
then
how
is
it
helping
putting
the
the
metadata
after
the
stack?
If
it
is
limited
Hardware,
then
it
will
not
be
able
to
process
the
data
after
it's.
K
Actually,
yeah
it,
it
is
not
able
to
process
it,
no
matter
it
is
in
ISD
or
PSD.
In
this
case,
we
need
to
consider
what
is
the
benefit
I'll
put
it
in
ISD
and
what
is
the
benefit
of
putting
in
PSD,
because
we
don't
is.
The
target
notice,
will
not
be
the
Legacy
Hardware
nodes
right
for
this
kind
of
applications.
We
need
to
consider
which,
which
place
is
more
suitable,
not
just
too
easier
to
be
accessed
in
the
package
right.
A
Yeah
I'm
kind
of
I
may
be
a
little
bit
confused,
but
I
think
what
I
hear
he's
saying
is
that
if
you
have
a
limited
Hardware
and
you
enable
M
A
on
it,
then
there
are
cases
that
you
probably
not
will
be
able
to
process,
and
it
may
will
be
made
worse
if
you
actually
increase
the
label
stack
out
of
what
the
specific
device
has
a
say:
maximum
label
depth
so
trying
to
find
out
kind
of
a
reasonable
size
that
we
can
increase.
A
I
D
Okay,
loan,
Nick
and
I
think
we
are
close
to
the
end
of
our
meeting.
I'm,
not
sure
if
Jimmy
still
has
anything
else,
they
had.
A
So
if
we
are
closing
the
meeting,
I
would
like
the
the
shares,
including
Stuart,
to
stay,
so
we
can
coordinate
a
little
bit
before
we.
We
shut
the
meeting.
D
Okay,
I
just
sent
it
out.
I
will
start
it
now,
so
we
can
jump
on
the
WebEx
it
shouldn't
have
should
have
started.
So
please
join
me
there
and
thanks
everyone
who
is
still
on
the
call-
and
you
know
we'll
see
you
next
time
in
a
many
interim
meetings
that
we
have
regular
ones.
Thank
you.