►
From YouTube: IETF114 PALS 20220726 1400
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
Okay,
very
good,
so
I'm
andy
malice,
I'm
chairing
this
session,
which
is
the
joint
pals,
mpls
and
detonate
session,
and
I'll
be
talking
more
about
what
we're
doing
here,
I'm
being
ably
assisted
today
by
tariq
saad
who's
sitting
up
at
the
front
table.
He
he's
able
to
take
over
if
anything
bad
happens
to
my
internet
connection
here
at
home.
Also,
I'm
assisted
by
dave,
cinecrop
dave's
is
taking
the
the
minutes
for
today
and
in
fact,
if,
if
any
of
you
would
like
to
help
take
minutes,
that
would
be
greatly
appreciated.
A
All
you
have
to
do
is
go
to
the
ietf
agenda
page
and
in
the
line
for
pals.
One
of
the
icons
in
the
right
says
notes
for
note
taker,
if
you
just
click
on
that.
That
brings
up
the
note
taking
tool
and
you'll
notice.
That
dave
has
already
populated
that
with
today's
agenda
and
he's
just
adding
notes
after
each
item
in
the
agenda
as
they
as
they
come
up
in
the
meeting
and
you're
all
free
to
take
notes
there
as
well.
It's
a
cooperative
effort-
and
I
think-
and
I
think
everybody
who
helps
on
that.
A
A
Here
are
some
meeting
tips
just
because
this
is
a
hybrid
meeting.
So
we
have
some
notes
here
for
the
in-person
participants
for
those
of
you
who
are
sitting
in
the
room.
Please
make
sure
that
you
sign
into
this
session
using
meet
echo
light,
and
if
you
take
a
look
at
the
little
diagram
on
the
slide,
it
shows
you
the
icons
that
are
to
the
right
of
the
pals
session.
A
What
you
want
to
do
is
you
want
to
click
on
the
meet
echo
light,
which
is
an
icon
that
looks
like
a
phone
and
that
will
bring
you
up
and
you
need
to
use
that
in
order
to
be
able
to
get
into
the
queue
you
will
not
be
recognized.
If
you
just
stand
at
the
microphone,
you
actually
have
to
get
into
the
queue,
so
I
can
see
and
manage
the
queue
from
here
at
home,
and
I
would
also
like
to
note
that
I
have
the
ability
to
give
you
the.
A
If
you're
a
speaker,
I
have
the
ability
to
give
you
control
of
the
slides
and
you
can
use
that
application
to
take
control
the
slides
to
move
them
back
and
forth.
So
if
you're
speaking
and
you
would
like
control,
just
ask
and
I'll
be
able
to
hand
off
control
to
you
also.
I
would
like
to
point
out
that
you
that,
for
those
you
who
are
in
the
in
the
room,
please
keep
your
mask
on.
A
For
those
of
you
who
are
at
home
like,
I
am,
please
make
sure
your
audio
and
video
are
off
unless
you
are
actively
cheering
as
I
am
or
you're
doing
a
presentation
and
please
use
a
headset
if
you
have
it.
Although
I
did
a
mic
check
with
christian
earlier,
I
was
able
to
hear
christian
just
fine,
so
share
good
shape.
Christian.
A
Next,
so
the
purpose
of
this
meeting-
this
is
a
joint
session
for
the
pals
mpls
and
networking
groups.
It's
focused
on
the
work
of
the
joint
open
design
team
for
the
mpls
network,
action
indicators
and
mpls
and
slurry
data.
This
is
a
work
that's
been
going
on
for
just
about
a
year
now
I
think
and-
and
it's
been
extremely
active
and
while
all
of
the
active
activity
happens
by
email
on
the
mpls
email
list,
we've
been
doing
joint
sessions
for
pals,
mpls
and
detonate,
while
we're
actively
actually
at
the
ietf
meetings.
A
So
the
overview
of
today's
agenda
is
we
have
one
item
actually
for
the
pals
working
group,
because
the
you
know
pals.
This
is
the
only
meeting
for
pals
and
we
have
one
item
of
work
for
pals,
which
is
private
line,
emulation
and
signaling.
Then
we're
going
to
have
tariq,
give
us
an
open
design
team
report
to
give
us
the
status
of
where
the
work
currently
stands
in
the
open
design
team.
Then
we're
going
to
have
a
bunch
of
drafts
for
the
op
for
the
joint
design
team
on
mnia
and
mad
requirements
m
a
headers.
A
The
post
stack
header
extension
and
special
purpose
label
for
forwarding
actions.
Note
that
the
open
design
teamwork
is
continuing,
it
is
not
completed
and
open
calls
will
continue.
Post
ihtf
114.
All
those
calls
are
announced
on
the
on
the
mpls
email
list.
A
So
if
you
want
to
participate,
you
really
need
to
be
on
the
mpls
email
list.
So
this
is
the
more
detailed
agenda.
Actually
I'm
not
going
to
go
into
this
in
great
detail
because
it's
available
online,
it's
also
available
in
the
note
taker
tool.
So
if
you
just
open
up
to
the
note
taker
page
you'll
be
able
to
see
this
as
well.
So
so
I'm
not
going
to
keep
this
open
right
here.
A
We
do
have
some
online
resources
that
are
helpful
both
today
and
ongoing
yeah
you
here's
the
pointer
to
today's
agenda,
the
note-taking
tool
known
alternatively,
as
ether
pad
code
imd
and
hedge
doc.
It's
that
url
right
there
that's
the
same
url
you
get
if
you
go
to
it
from
the
ietf
agenda,
page
we're
on
jabber
as
well.
The
jabber
is
integrated
with
with
meat
echo.
A
So
you
should
download
the
zulip
app
for
your
phones
and
and
get
acquainted
with
zulip
for
for
the
next
ietf
meeting.
There
is
a
wiki
for
the
mpls
open
design
team.
It's
at
that
url
right
there
and
the
wiki
is
where
we
announce
all
the
agendas
for
the
open
design
team
calls
all
the
ongoing
work
is
documented
there.
A
They
are
keeping
on
top
of
that
in
real
time
and
they
will
help
you
out
and
finally,
there's
also
a
meat
echo
technician
who
is
monitoring
the
session.
So
if
there
are
any
meat
echo
issues
that
come
up,
we
can
get
right
in
touch
with
the
medical
guys
as
well,
and
that's
my
final
slide.
So
I'm
going
to
close
this
deck
and
move
on
to
christian.
Let
me
open
that
deck
right.
There
wait
one
second.
A
B
Okay,
thanks
andy
thanks.
Everybody
appreciate
the
time
it's
an
honor
to
have
the
first
slot.
In
this
session.
I
would
like
to
introduce
to
the
pals
group
the
concept
of
private
line
emulation
it
has
been.
You
know
I
presented
that
already
at
itf
108
back
then
at
the
best
working
group,
and
my
purpose
here
would
be
to
introduce
you
to
the
concept
as
well
as
give
an
update
on
the
the
the
progress
we
made
through
the
last
couple.
B
Some
of
you
may
wonder
why
such
a
pals
ish
draft
and
a
very
tdm
centric
draft-
and
you
know
there
is
something
happening
at
the
lower
layer
of
the
transport
and
what
is
actually
happening
is
that
packet,
switching
through
the
innovation
in
silicon
is
becoming
the
most
cost
effective
way
to
switch
information
at
the
electrical
level.
B
What
also
is
happening
is
that
dwm
and
coherent
transmission
technology
is
moving
in
in
the
form
of
pluggables
into
routers,
and
that
kind
of
begs
the
question:
does
it
make
sense,
and
this
is
really
at
the
lower
transport
level?
It's
not
at
the
you
know,
I
guess
routing
control,
plane
and
service
level
right,
it's
more
on
the
more
boring
side
of
the
house
of
the
network.
B
You
know:
do
we
really
need
a
tdm,
switching
layer
and
predominantly
that
is
today
otn
or
can
they
actually
get
rid
of
it
and
really
let
everything
be
packet
switched
or
routed?
B
And
when
we
do
that,
of
course,
that
you
know
begs
the
question
as
a
follow-up:
what
do
we
do
with
our
tdm
switch
services,
or
also
known
as
private
lines?
Let
me
go
to
the
next
slide.
You
know,
a
lot
of
things
can
be
done
with
pseudobuyers
right
and
ethernet's.
Utilizing,
evp
and
vpws
is
doing
a
great
job
right.
The
first
draft
part
of
the
session
is,
you
know,
called
you
know,
ple
or
private
languation
and
is
about
the
data
plane
and
it
address.
B
It
is
addressing
the
the
gap
that
we
have,
that
we
cannot
act
at
the
bit
level
and
be
more
transparent,
maybe
because
I
want
to
be
completely
transparent
for
ethernet
to
also
support
synchro's
ethernet
for
some
special
cases,
or
maybe
I
want
to
carry
fiber
channel
and
non-ethernet
technology,
and
this
draft
is
somewhat
taking
what
has
been
done
in
the
past,
with
rfc
four
five:
five:
three
and
four
structure,
agnostic
transport
over
packet
and
is
adopting
or
let's
say,
widening
the
scope
to
higher
speed
interfaces
like
10
gt,
100
kg
fiber,
channel
of
various
rates
or
even
otn
or
sonic
sdh
again,
the
underlay
is
mpls,
but
also
these
days
you
know,
srv6
is
a-
is
a
a
suitable
underlay.
B
The
second
draft
I
want
to
put
your
attention
to
is
essentially
adding
the
signaling
pieces
into
the
mix,
and
here
because
nowadays
you
know
evpn
and
evpn
vpws
is
a
more
modern
way
of
signaling
pseudo-wires.
The
idea
is
to
have
extensions
to
signal
those
tdm
into
or
this
interface
specific
attributes.
B
Now,
from
a
data
plane
perspective,
it's
really,
you
know
a
evolution
of
what
has
been
on
the
setup
right
and
what
we
are
defining
is
two
encapsulation
of
three
encapsulation
types
which
which
are
largely
agnostic
to
any
kind
of
you
know,
information,
that's
in
the
signal,
but
due
to
the
let's
say,
to
a
more
optimized
implementation
for
for
carrying
odu
or
carrying
very
high
capacity,
200
giga
400
gig
interfaces.
B
We
have
defined
some
some
alignment
where,
in
the
otn
case,
we
do
a
od
uk
frame
alignment
and
for
the
200
gb
and
400
gig
we're
aligning
with
the
10
28
bit
blocks
that
have
been
defined
for
those
ethernet
technologies.
For
the
rest,
the
proposal
is
really
to
keep
things
the
way
they
are
right.
We
have
an
rtp
header
with
sequencing
and
rtp
timestamps.
We
have
a
control
with
l
and
r
bit
so
pretty
much.
B
B
Let's
say
what
has
been
done
in
the
past
and
again
expanding
the
the
scope
and
adding
a
few
bits
and
pieces
in
terms
of
tlvs
to
to
signal
the
specifics
of
those
new
interface
types
that
are
now
being
emulated,
but
to
a
large
extent
you
know
the
I
would
say
the
approach
is
identical
and
what
we
are
proposing
is
essentially
to
adopt
bgp
instead
of
ldp
next
slide.
B
So
so
much
for
the
introduction,
as
I
said,
I'm
I
presented
already
iitf
108..
Since
then
we
had
quite
a
bit
of
progress,
even
though
I
have
to
say
that
the
technology
may
not
be
in
fashion
right,
but
we
have
you
know
strong
interest
from
operators
like
verizon,
deutsche
telekom
and
also
sienna
and
silence
have
joined
us
and
through
that
and
various
feedback.
We
got
from
the
folks
mentioned
here.
B
We
also
got
some
more
recent
feedback
again,
thank
you
for
everybody,
who's
providing
input
and,
more
recently,
we
added
the
10
28
bit
block
alignment
for
supporting
very
high
capacity,
200
gig
and
400
kg.
This
is
probably
a
little
bit
more
futuristic,
but,
as
networks
may
maybe
build
based
on
800
gig
and
maybe
1.6
terabit
ethernet
interfaces.
You
know
this
is
something
that
will
be
asked
by
the
market
as
well
and
last
but
not
least,
from
the
feedback.
B
B
So
this
is
actually
all
I
have.
Hopefully
this
gave
you
a
good
introduction.
We
would
appreciate
more
more
feedback
and
input.
B
We
have
been
actively
talking
from
cisco
side
to
a
lot
of
customers
and
we
have
shown
we
have
seen
great
interest.
So
we
really
believe
that
this
is
something
that
is
of
interest.
Not
only
you
know
is
of
interest
for
everybody,
and
we
would
recommend
or
ask
for
input
and
feedback
and
potentially
adopt
the
draft
and
make
this
a
workshop
document.
So
we
can
progress
and
make
the
the
document
complete
and
finally
an
rfc.
B
Last
but
not
least,
I
think
recently
there
was
a
discussion
about
pseudo-wires
and
ldp
and
s-segment
routing,
and
I
was
wondering
that
potentially
the
signaling
draft,
which
hasn't
you
know,
had
too
much
of
progress
yet
could
be
a
potential
solution
to
to
address
some
of
the
topics
that
have
been
discussed
there
and
would
like
to
to
get
your
feedback
on
that
one,
and
with
that.
Thank
you
very
much.
A
Okay,
thank
you
very
much
christian.
Do
we
do
we
have
any
questions
for
christian
before
we
move
on
to
the
joint
meeting.
A
D
I
see
it
thanks
perfect,
so
my
name
is
tariq
saad
and
I
was
delegated
to
give
a
report
on
the
mpls
network's
action
network
actions
activities
and
a
status
update
on
the
work
that
the
design
team
has
been
engaged
with,
as
well
as
the
working
group.
D
So
let
me
proceed
before
I
do
that.
I'm
happy
to
take
questions
on
this,
but
if
it
is
of
nature,
the
debatable
nature
or
controversial,
there
is
a
there's,
a
slot
that
we
left
open
towards
the
end
of
the
session
feel
free
to
bring
it
up
at
that
time.
But
if
it's
a
quick
status,
update
question
I'm
happy
to
take
it.
D
D
It's
currently
a
joint
activity
between
three
working
groups:
mpls
pals
and
debt
net,
the
chairs
from
the
three
working
groups,
coordinate
agendas
and
decisions,
and
they
do
meet
periodically.
The
open
design
team
meeting
happens
every
week
on
thursday
11
a.m.
Eastern
time,
as
I
mentioned,
the
chairs
are
meeting
also
weekly
and
it
happens
on
tuesday.
D
We
have
good
participation
from
the
working
groups
and
usually
we
see
around
15
to
20
participants.
Every
week
there
was
a
a
review
of
documents
that
were
active
actively
produced
by
the
design
team
and
members
and
the
taxonomy
of
or
the
report
was
left
on,
the
wiki.
So
people
want
to
check
that
we're
leaving
a
link
to
it.
D
I'm
I'm
okay
to
take
questions
now
or
yeah.
So
I
see
someone
raising
their
hands
and
let
me
ask
andy:
do
you
want
to
take
questions
now
or
I'm?
I'm
okay
by
myself,
yeah.
A
If
they're
quick,
absolutely,
why
don't
you
go
ahead?
John
don.
E
D
E
A
F
D
I
will
proceed
then
in
terms
of
updates,
since
last
time
we
met.
So
this
is
the
third
report,
indeed
that
we
are
producing
to
the
the
working
group
and
the
updates.
This
time
include
some
working
group
documents
that
got
adopted.
Let
me
go
through
them
and
review
the
status
of
each.
So
there
was
the
use
cases
for
mpls
network
action
indicators
and
pls
sincerity
data
this.
D
D
We
have
the
second
document
which
tackles
the
requirements
for
mpls
network
actions
and
mpls
ancillary
data.
This
document
also
got
adopted
in
may
2022
and
the
working
group
and
the
design
team
are
regularly
refining
this.
The
requirements
in
the
document-
and
this
usually
happens
either
on
the
email
list
or
during
the
weekly
meeting.
D
Yeah
the
numbering
changed
for
some
reason.
This
should
be
number
three,
oh
one.
Second,
maybe
I
yeah
number
three,
that's
what
I
was
expecting.
The
third
document
that
the
the
design
team
tackled
was
the
framework
for
mpls
network
actions,
and
this
document
got
recently
adopted.
The
name
still
hasn't
changed,
but
we're
expecting
it
to
change
anytime,
but
indeed
the
working
group
has
decided
to
adopt
this
document.
D
D
D
D
We
tried
to
converge
on
some
of
the
common
streets,
how
to
tackle
them
during
the
weekly
design
team
meeting,
but
unfortunately,
that
did
not
conclude
so
that
the
open
design
team
chairs
decided
to
craft
two
polls
and
and
send
it
to
the
email
list
of
the
npls
working
group.
In
order
to
see
you
know
a
convergence
and
move
forward.
D
So
the
polls
were
left
open
for
almost
three
weeks
to
gather
as
many
feedback
as
possible
and
subsequently
the
chairs
decided
or
concluded
and
shared
the
results
of
the
polls.
D
We
will
go
through
the
results
and
of
the
consensus
call
on
this
slide
and
the
subsequent
slide.
The
first
poll
that
happened
was
to
make
sure
that
the
framework
is
solution,
independent,
which
makes
sense,
but.
D
So
80
is
not
so
80
means
ancillary
data
here
and
not
the
area
director.
So
we
want
to
make
sure
that
the
framework
can
convey
the
ancillary
data
inside
the
packet
in
in
either
multiple
places
as
well
as
can
be
signaled
in
the
control
plane.
An
m
a
packet
may
carry
the
ancillary
data
in
one
or
both
places,
including
inside
the
mpls
stack
or
after
the
empire
stack.
D
D
The
second
poll
was
a
call
to
converge
on
whether
to
repurpose
the
existing
any
existing
spl
for
m
a
action
data
indicator,
for
example,
an
spl
that
was
thoroughly
researched
was
the
entropy
label
indicator
or
whether
we
should
allocate
a
new
spl
for
this
purpose.
D
So
the
conclusion
on
this
poll
was,
you
know
the
responses
showed
that
we
have
a
strong
consensus,
that
we
want
to
allocate
a
new
spl
for
m
and
no
need
to
repurpose
any
existing
spl.
For
this
purpose.
D
We
also
concluded
that
any
other
application
other
meaning
none
m,
a
application
that
per
that
proposes
to
repurpose
any
existing
spl
will
need
to
go
through
the
normal
working
group
process
if
they
wish
to
do
so.
So
we
do
have
a
proposal
and
we
we're
going
to
go
through
that
towards
the
end.
The
last
slide,
but
this
is
the
conclusion
on
this
poll.
D
In
terms
of
next
steps,
the
open
design
team
that
is,
tackling
m
a
still
is
meeting
weekly
and
they
have
they
have
a
lot
still
to
do
in
terms
of
defining
the
solution.
D
So
I
I
mentioned
there
is
a
review
of
documents
that
tackle
or
that
the
proposed
different
solutions-
and
you
know
we
went
over
that
last
time
and
we
met
in
the
design
team
and
we
we
thought
that
there
is
resemblance
in
terms
of
some
proposals
and
the
chairs
are
encouraging
authors
of
such
solutions
that
look
alike
to
collaborate
together,
and
you
know
report
back
in
the
weekly
design
team
on
the
progress
of
alignment.
D
So
I
did
mention
that
there
was
a
call
or
a
poll
to
conclude
on
the
reuse
of
a
special
purpose
or
repurposing
of
special
purpose
labels
for
different
applications
other
than
other
than
what
it
was
meant
to.
D
So
we
did,
we
did
agree
as
a
working
group,
as
well
as
a
design
team,
that
it
will
not
be
part
of
the
m
a
work
we
do
have
a
draft
that
is
proposing
the
use
of
entropy
label
indicator
to
indicate
a
slice,
id
presence
and
any
other
and
some
other
actions
as
well.
There
were
other
drafts
that
that
highlighted
that
such
reuse
is
dangerous.
D
We
are
I'm
leaving
both
drafts
here
for
for
people
to
check,
but
the
conclusion
here
is
is
that
we
will
leave
the
working
group
process
to
drive
the
progress
on
such
a
proposal.
So
if,
if
we
see
that
we
will
go
through
the
regular
rough
consensus
to
see
if
such
a
proposal
can
progress
or
not.
D
So
this
was
my
last
slide
on
the
activities,
as
well
as
the
status
update
of
the
design
team.
I
hope
I
kept
honesty
here,
but
if
anyone
else
from
the
design
team
wants
to
add
or
update
any
of
what
I
mentioned
feel
free.
A
I
don't
see
any
hands
being
raised,
so
thank
you
very
much
tariq
and
we're
going
to
move
on
to
matthew
now
who's
going
to
present
the
requirements.
Draft.
G
So
this
is
just
a
short
overview
of
where
we
are
with
the
requirements
for
the
requirements:
draft
for
mpls
network
action
indicators
and
ancillary
data,
and
since
the
last
ietf
john
drake
has
has
joined
the
the
author
list
and
and
helped
us
a
lot
with
this
draft.
So
thanks
john
and
next
slide.
G
So
so
this
document
captures
or
is
intended
to
capture
the
key
requirements
for
mpls
network
actions
that
affect
forwarding
or
other
processing
of
the
mpls
packets,
including
requirements
on
network
action.
Stub
stack
indicators,
so
that's
that's
referred
to
as
the
the
m,
a
label
or
the
special
purpose
label.
G
That's
used
to
indicate
a
set
of
network
actions,
the
mps
network,
actions
themselves
or
indicators
themselves
and
any
ancillary
data
required
to
perform
the
indicated
action
and-
and
this
is
a
product
of
as
you
of
the
mpls
open
design
team
and
the
the
requirements
are
largely
driven
from
a
number
of
proposals
for
additions
to
the
mpls
label,
stack
to
allow
decisions
about
actions
based
on
on
application
data
and
just
to
clarify
these
requirements
are
on
protocol
design.
G
So
in
in
may,
I
think
we
went
through
an
adoption
process.
There
was
an
individual
draft
which
had
reached
version
four
and
we
had
around
30
comments
which
were
made
on
which
were
made
on
the
list
and
were
collate
collated
by
lower,
and
the
process
we
took
was
to
essentially
adopt
the
the
document
wholesale
but
add
the
in
that
first
new
version.
Add
those
comments
to
an
appendix
a
which
is
the
working
group
adoption
comments,
because
there
are
quite
a
lot
of
comments,
so
you'll
see
in
the
draft.
G
There's
there's
still
an
appendix
containing
the
the
comments
and
some
responses
to
the
comments,
and
we
we
published
the
draft
as
the
working
group,
drafters,
mpls,
miad
m,
a
requirement,
zero
and
then
subsequently
corrected
the
name
to
the
m,
a
requirements
that
addresses.
G
We
hope
the
comments
in
in
the
in
the
working
group
adoption
and
on
the
subsequent
meeting,
discussion
and
and
in
the
subsequent
revisions.
So
we
intend
to
remove
appendix
eight
shortly
next
slide.
G
So
the
main
changes
we
align
the
terminology
with
the
framework
draft,
so
essentially
what
we.
What
we've
done
between
these
two
documents
is
that
we
have
a
core
set
of
terminology
defined
in
the
in
the
requirements
draft
and
then
the
framework
is
is
kind
of
a
superset
of
that
with
any
new
terminology.
That's
required
outside
of
the
requirements
to
describe
things
in
the
framework.
G
G
We
also
also
clarified
that
a
solution
solution,
specs,
must
support
or
may
support
user
defined
actions,
so
it
may
support
user
defined
actions
and
if
they
do,
they
must
explicitly
reserve
a
user-defined
range
in
their
iana
policy
for
any
registry
that
they
defined
and
we
also
reorganize
the
requirements
into
appropriate
sections
around
the
network.
Action
sub
stack
indicator,
the
network
action
indicators
and
the
ancillary
data,
and
also
a
set
of
generic
requirements
next
slide.
G
So
the
the
structure
that's
changed
since
the
last
ietf
is,
is
the
terminology
which
contains
new
terms
needed
to
define
new
objects
in
mpls,
a
set
of
generic
or
general
requirements,
which
is
a
set
of
design
principles
that
underline
this
work.
Requirements
on
the
network,
action
indicator,
sub
stack
requirements
on
the
net
action
indicators,
requirements
on
ancillary
data
and
the
appendix
containing
the
working
group
adoption
comments
which
we
intend
to
remove
shortly
next
slide.
G
G
We
really
appreciate
further
review
and
comments
posted
to
the
mpls
list
or
brought
up
in
the
mpls
open
design
team
meetings,
but
the
authors
believe
the
draft
is
getting
pretty
mature
now
and
we
hope
that
from
a
quality
perspective,
it's
close
to
what
you
would
expect
from
a
working
group.
Last
school
document.
A
Thank
you
matthew.
Are
there
any
questions
for
clarification
for
matthew
and-
and
I
do
want
to
remind
people
that
we
have
about
40
minutes
reserved
for
open
discussion
following
all
the
presentations?
So
if
we
want
to
have
any
extended
discussion,
we
can
have
it
then,
and
I
see
that
lowe
has
his
hand
up
so
lower,
go
ahead.
H
A
question
for
matthew
what
I
didn't
really
follow,
what
you
said
about
ayan
already
stressed
for
user-defined
actions.
I
think
user-defined
actions
smile
allocate
whatever
they
want
in
diana
and
that's
of
the
problem.
The
problem
is
that
the
probably
in
the
standards,
part
of
the
registry
need
some
code
points
to
be
used
for
the
user
defined
actions.
G
G
G
Well,
actually,
I
just
posted
one
on
monday,
which
is
version
two,
which
is
the
one
I
I
referred
to
here.
I
apologize
it
just
missed
the
the
cutoff,
so
I
I
posted
it
as
soon
as
as
it
opened
again
on
on
over
the
weekend.
A
A
I
Control
my
slides
that'd
be
awesome.
Okay
I'll
do
it!
Thank
you
yeah!
So
hi.
My
name
is
ball
x.
So
I'm
going
to
present
the
presenter
draft
jags
mpls
mna
header,
on
behalf
of
our
authors,
mr
jags.
A
I
Much
better
yeah
coming.
I
I
Yeah,
so
as
part
of
this
presentation,
this
is
my
agenda
which
I'm
going
to
discuss
today.
I
The
first
will
be
the
scope
of
our
draft
and
then
we're
going
to
discuss
on
the
high
level
solution
what
we
took
to
achieve
the
and
then
next
one
is
the
network
action
indicator
and
then,
like
I'm,
going
to
discuss
on
the
in
stack
network
action,
encoding
format,
different
formats
and
the
corresponding
examples,
and
the
next
one
is
the
backward
compatibility,
how
we're
gonna
achieve
with
our
solution
and
the
advantages
of
our
solution
and,
finally,
the
next
steps.
I
What
what
we
want
to
do
with
our
draft
next
slide,
please
as
a
part
of
the
scope
right
so
like
we
are
providing
a
solution
for
in
stack
and
postdoc
mna
encoding
format
based
on
the
m,
a
requirements
according
to
the
draft
mentioned
here,
aligning
with
our
mna
framework,
which
is
mentioned
here
next
slide.
Please,
okay,
it's
part
of
the
high
level
solution.
I
Level
solution
which
we
took
to
come
up
with
a
solution
for
m
a
header
encoding
to
extend
to
action
the
existing
mpls
header
for
mna.
So
we
need
the
two
main
things.
The
first
one
is
the
mpls
network
action
indicators.
So
the
top
level
we
want
to
have
a
label
to
indicate
the
presence
of
network
action,
sub
stack
and
the
next
one
is
the
a
little
bit
more
granular.
I
So
we
provide
the
slab
flags
to
indicate
the
presence
of
in
stack
and
post
network
actions
the.
Secondly,
like
apart
from
the
network
action
indicator,
we
need
we
need
to
encode
the
network
action
encoding.
So
we
can.
We
should
come
up
with
a
format,
so
there's
a
format
actually
like
which
describes
how
the
in
stack
and
post
network
actions
are
going
to
be
encoded
next
slide,
please,
okay!
So
let's
go
deep
dive
into
the
network
action
presence
indicator.
I
As
I
told
you
like
at
the
top
level,
we
have
this
network
action.
Sub
stack
indicator
see
a
new
bspl
will
be
allocated
by
iron
for
this
purpose,
as
so,
this
bspls,
tc
and
ttl
material
field
will
not
be
repurposed
and
then
and
then
used
for
any
encoding
to
maintain
the
backward
compatibility.
I
So
apart
from
this,
we
we're
going
to
encode
some
flags
in
the
next
lse
lse
so
which,
which
is
going
to
have
granular
indicators
like
in
stack
network
action
presence
indicator.
So
this
indicates
the
presence
of
the
instax
network
action
that
are
encoded
in
the
packet,
as
shown
as
shown
in
the
figure
one.
The
instruct
network
actions
can
be
two
types
like
one
is
the
flag
based
that
doesn't
require
any
ancillary
data
and
another
another.
I
One
is
the
network
action
that
requires
an
ancillary
data,
so
we
call
it
as
an
opcode
based
that
requires
a
necessary
data,
so
the
next,
the
second
indicator.
The
main
indicator
is
the
post
stack
indicator.
So
this
indicates
the
presence
of
the
post
network
actions
that
are
encoded
in
the
packet,
so
so
by
using
this
indicator,
so
we
can
identify.
We
can
we
can
encode
both
the
stack
and
post
stack
data
simultaneously
using
the
same
nasi
header
next
slide.
Please.
I
So,
as
I
told
you
before,
like
the
first
one
is
the
flag
based
in
stack
mpls
network
action
encoding.
So
this
is
this.
This
is
the
india
network
action
which
doesn't
need
any
angular
data
to
process
the
specific
network
actions.
So
here
actually
like
there
are
two
parts:
one
is
the
in
stack
network
action
header.
So
these
are
the
flags
and
some
couple
of
values
which
which
would
which
would
help
us
to
encode
the
the
these
stack
network
actions.
I
So
the
ini
is
the
field
you
know
like,
which
is
a
detailed
field
which
indicates
the
presence
of
the
in
stack,
mpls
network
action
and
then
the
il
is
the
instructor
data
length.
It's
a
three
bit
value
in
the
ttl
field.
This
this.
This
indicates
the
total
length
of
the
in
stack
header
encoded
by
the
specific
nasi
indicator,
so
the
length
is
represented
in
the
in
terms
of
units
in
the
unit
of
word.
I
This
does
not
include
the
the
header
or
the
header
word
and
the
last
last
one.
I
want
to
tell
you
that
is
ine.
It's
an
in
stack
na
extension
indicator,
so
in
in
currently
we
can
encode.
You
know
like
maximum
of
eight
additional
seven
additional
words
apart
from
the
base
header.
So
if
you
want
to
extend
more
than
seven
in
the
future,
then
this
flag
would
be
used
to
extend
the
sub
stack
as
well.
I
So
the
second
part
of
the
second
part
is
the
flag
based
in
stack
network
action,
encoding
format.
So
here
actually
like,
we
have
a
flag
based
nai.
So
this
is
actually
the
19-bit
field
in
the
label
field
and
the
msp
will
must
be
always
set
to
one
to
prevent
aliasing
from
the
spls
and
the
and
this
each
each
and
every
bit
field
will
be
assigned
by
ayana
for
a
specific
application.
I
So
if
application
a
wants
an
flag
based
indicator,
so
then
they
could,
they
could
request
for
ion
number
and
then
big
position,
and
then
they
could
use
that
so
that
that's
gonna
dictate
what
the
network
action
for
that
has
to
be
done,
and
there
is
an
e
bit
which,
which
is
going
to
indicate
that
any
any
one
of
the
flag
based
indicator
is
hub
by
hop
or
at
the
or
it
is
end
to
end.
I
So
if
you
say
like
any
one
of
the
flat
flag
is
the
by
hop
then
hop.
I
hope
that
this
e
field
will
be
zero
else.
Actually,
the
e
field
will
be
one
so
there's
another
field
is
like,
and
the
tc
field
will
be
repurposed
to
use
to
add
additional
data
length.
I
This
is
actually
two
bit
field
in
the
ttl
to
indicate
the
length
of
the
additional
word
that
that
are
encoded
to
carry
the
additional
flag
based
network
indicator,
for
example,
currently,
like
we
can
encode
a
19
19
offset
fields
here.
So
if
you
say
like
the
20th
application
is
coming
and
requesting
for
additional
for
a
foreign
flag
based
indicator,
then
the
then
the
adl
will
be
set
to
one
so
that
we
can
add
another
lse
to
encode
the
the
flat
best
indicator
next
slide.
Please.
I
So
this
is
the
second
part
of
the
in
stack
network
action,
the
encoding,
so
this
is
actually
opcode
based.
So
this
is
the
kind
of
network
action
that
needs
an
accelerated
data
to
process
the
network
actions.
I
So
here
the
the
third
word
is
going
to
describe
like
what
is
the
op
code
and
accelerate
data,
and
some
of
the
informations
I'm
going
to
describe
now
so
in
this
in
this,
in
this
upward
approach,
like
upcode
approach,
is
basically
a
kind
of
a
tlv
format
which
is
successfully
used
in
many
protocols
today
and
many
asics
are
supporting
today.
So
here
the
the
is
in
nai
up
code
is
the
eight
bit
field.
I
This
indicates
the
instax
network,
app
action,
opcode
that
that
should
be
assigned
by
the
info
for
a
specific
application.
The
characteristics
of
the
upgrade
must
be
defined
while
the
solution
is
developed
and
requested
for
the
value
from
the
inr.
I
The
ancillary
field
are,
you
know,
like
the
is
20
bits
in
total
12
bits
from
the
from
the
label
field,
and
the
eight
bits
from
the
ttl
field
will
be
used
for
to
encode
the
data
corresponding
to
the
sub
code,
and
the
adl
is
the
additional
data
length
and
some
of
the
applications
might
need
to
encode
more
than
40
bits
of
data
in
the
answer,
the
ancillary
field,
so
those
applications
can
use
this
field
to
extend
their
encoding
of
ancillary
data
and
the
last
one
is
the
ebit.
I
So
this
is
actually
a
end-to-end
processing
bit
the
same
as
the
above.
So
if,
if
it
is,
if
this
specific
op
code
has
to
be
processed
or
by
hop,
then
this
field
should
be
set
to
zero
else.
This
will
be
set
to
one
can
at
least
move
the
next
slide.
Please,
okay!
I
So
now,
let's
see
some
of
the
examples,
so
so
that
you
know
you'll
have
some
idea
like
how
this
encoding
is
going
to
work
so
this
for
the
example,
one
is
the
pure
flag
flag
based
mpls
network
action,
where
the
where
actually
I'm
encoding
and
bit
flag,
bit
flag
position
of
one.
The
application
big
question
one
is:
is
going
to
send
it's
an
it.
It
wants
it
network
actions
to
be
processed
in
on
the
different
nodes.
I
So
here
so
here,
actually
the
adl
field
will
be
zero
because
we
are
not
adding
any
additional
word.
Apart
from
the
general
general
control,
encoding
flags
and
the
end
in
the
end,
as
I
told
you
before,
the
ebit
is
going
to
be
set
based
on
the
whether
the
processing
is
going
to
be
for
this
oneness
end
to
end
or
it's
hop
by
hop
next
slide,
please.
I
So
this
is
the
case
you
know
like
I,
my
I
have.
I
have
two
applications
needs
to
encode
their
flag
based
nis.
The
the
first
application
is
having
the
bit
push
and
one
and
second
application
is
having
the
bit
portion
20
right.
So
the
the
the
application
20
cannot
encode
their
big
position
in
the
in
the
first
flag
based
ni,
so
they
need
to
use
the
second
second
word
to
encode
the
encode,
the
bit
20..
I
So
since
actually
we're
adding
one
more
word
to
that,
the
adl
field
is
going
to
be
set
to
one.
So
this
this
will
help
us
the
help.
The
the
hardware
to
identify
that
the
flag
based
fields
are
know
like
is
going
to
have
additional
word,
and
then
it
can
process
easily.
So
it'll
be
like
a
more
hardware
friendly
next
slide,
please,
okay!
So
there's
a
third
example
where
actually
like
we
are
going
to
encode
the
plain
op
code
based.
I
We
don't
have
any
flag
based
here
so
here
in
the
example
like
we
are
encoding
the
opcode
value
10,
that
is,
the
application
which
has
been
assigned
up
code
value
10,
is
going
to
carry
its
corresponding
axillary
data
with
it
so
that
all
the
all
the
nodes
can
process
their
network
actions
correspondingly
here
actually
like,
since
the
application,
10
application
of
code
10
doesn't
need
a
angular
data
more
than
20
bits.
I
The
adl
field
is
set
to
zero,
so
that
indicates
that
you
know
like
the
up
code
type
10
has
the
angular
answer,
data
which
is
within
the
20
bits
offset
next
slide
please.
I
The
fourth
example
is
the
case
where
the
the
up,
the
network
action,
is
needs
and
data,
but
which
it
needs
more
than
20.
Bits
of
data
needs
to
be
encoded,
so
in
this
case
actually
like,
since
it
needs
some
more
than
20
bit
of
data.
So
we
need
to
spill
into
the
next
word,
so
so
the
adl,
the
additional
data
length
value,
will
be
set
to
one.
I
So
this
will
indicate
the
hardware
that
the
the
upgrade
upgrade
12
corresponding
informations
are
relying
in
the
next
word
as
well,
so
it
can
take
those
buffers
and
then
process
it
correspondingly.
I
So
this
this
gives
a
more
flexibility
and
asic
to
process
it
in
an
easy
manner
and
also
like
for
in
in
some
cases
right.
The
midnotes
may
not
implement
a
specific
op
code.
So
if,
if
they,
if
they,
if
they
don't
implement
those
specific
op
quotes,
then
actually
they
can
skip
those
of
course
and
then
go
to
the
next.
I
I
So
it
knows
that
the
the
two
word
has
not
been
used
and
then
you
can
skip
to
the
third
one
and
then
start
processing
the
next
next
stop
code
available
in
the
stack
so
that
that's
what
actually
could
be
very,
very,
very
helpful
in
skipping
the
the
unknown
up
codes
and
processing
the
data.
Similarly,
like
e
e
will
be
set
based
on
the
you
know
like
end
to
end
processing
or
hop,
I
hop
processing
next
slide,
please,
okay,
so
here.
I
Actually,
this
is
the
example
where
the
packet
is
carrying
both
the
flag
based
and
upgrade
based
the
flag
base
here
is
carrying
the
the
offset
one
for
the
flag
based
and
up
code
10
with
angular
data,
which
is
less
than
or
equal
to
20
20
bits
has
been
carried
here
and
that's
what
you
can
see
here,
so
the
essence
actually
does
not
crossing
their
limit.
The
adl
is
zero
for
the
both
the
cases
next
slide,
please.
I
So
this
is
actually
like
some
it's
a
multiple
op
code
based
and
flag
based
informations
are
carried
in
this
packet.
So
here,
if
you
see
the
blackberry
flag
based
nai,
we
have
offset
one
and
four
has
been
carried
as
well
as,
if
you
see
the
opcode,
if
you
see
the
upcoder
based
nis,
we
have.
We
are
carrying
upgrade
10
and
20.
I
and
then
like
when
we
see
the
length
I
l
field
right
since
actually
like
apart
from
the
general
header
encoding,
so
we
are
adding
a
two
more
word.
That's
the
reason
I
I
l
equal
to
two
is
set
there,
so
that
will
tell
the
asic
that
you
know
like
it
is.
It
is
encoding
this.
My
number
of
bytes
next
slide,
please,
okay,
so
the
this
is
the
backward
compatibility.
You
know
like
how
the
solution
adopted
and
then
what
we
thought
about
it.
I
So,
when
we,
when
we
introduce
this
mna
and
then,
if
the
when
the
header
no
at
the
head,
node
needs
to
encode
this
mna
into
the
mpls
stack,
then
it
should
it
should.
It
should
depend
on
the
mma
capability,
so
the
control
plane
needs
to
inform
about
the
semantic
capability
of
the
end
node.
That
needs
to
be
that
needs
to
process
the
m
m.
So
in
worst
case,
you
know
like
if
you
say
like
there's
some
change
in
the
topology,
and
that's
it
in
that
case
right.
I
So,
even
though
the
the
end
node
is
not
aware
of
this
mna
capability,
since
we
are
using
the
spl
this
packet,
since
our
spl
is
not
is
not
able
to
process
by
the
specific
node,
the
specific
packet
will
be
dropped
in
this
case.
I
These
the
second
comparability
is
like
ecmp
icmp
behavior,
for
here
actually,
like
the
the
labels
in
the
label,
stack
does
not
change
for
for
a
flow,
so
so,
like
you
know
like
the
ecmp,
is
going
to
remain
same
for
that
specific
flow.
So
we
are
not
disturbing
the
acmp
flow
as
such.
I
Third
one
is,
like
you
know
like
so
in
our
design.
We
make
sure
that
any
of
the
mid
notes
or
legacy
notes
you
know
like
it-
doesn't
interpret
our
data
for
an
base.
Spl
spls,
which
we
already
defined.
I
The
fourth
one
is
the
the
the
the
ultimate
node
with
the
detailed
propagation
behavior
does
not
corrupt
the
m,
a
stack.
That's
the
reason.
No,
like
we
skipped
encoding
the
information
in
the
top
level
in
the
in
the
in
the
in
the
bspls
ttc
tdl
field,
and
then
we
used
the
next
next
word
to
encode
the
those
common
flags
encoding
flags
for
the
mna.
I
The
last
one
is
since
actually
like.
We
have
opcode-based
offsets
to
place
our
postac
data
wherever
we
like,
so
this
can
coexist
with
any
existing
dash
or
any
other
architectures.
We
have.
I
A
One
second,
I
I
see
that
greg
and
tariq
have
their
hands
up
because
we're
past
time
on
this
talk,
I'd
like
to
reserve
your
comments
for
the
general
discussion
time.
If
that's
fine,
so
just
keep
them
in
mind
and
and
come
back,
then
thank
you.
Okay,
jags.
I
Yeah
sure
so
yeah,
so
this
is
the
main
advantage
I
just
I
want
to
highlight.
You
know
like
our.
Our
architecture
is
more
flexible,
since
it's
upcode
based
it
can
be
placed
anywhere
in
the
stack
and
the
next
one
is
the
mnen
coding
is
extensible.
I
Since
it's
opcode,
like
you
know,
we
have
a
flash
to
extend
the
up
codes
even
in
the
future.
The
the
fourth
point
is
very
very
important
for
our
our
case,
because
this
is
actually
hardware
password
friendly
the
length
field
of
m.
A
substract
allows
to
easily
skip
the
sub
stack,
as
I
described
before,
and
network
action
opcode.
The
answer,
data
and
the
scope
and
length
right,
so
the
ttl
tlb
kind
of
format
has
been
encoded
here.
So
this
is.
I
This
is
easy
for
the
hardware
to
process
the
data
and
then
they
can
use
the
existing
parser
to
parts
of
data
and
the
next
one
is
that
the
msd
efficiency.
I
So
since,
actually
we
encode
all
these
flags,
so
the
msd
is
sufficiently
used
the
backward
compatibility
with
the
existing
network.
We
make
sure
that
it's
not
disturbed
and
the
last
one
is
it's
ecp
friendly.
So
even
actually
like,
if
any
anybody
wants
to
encode
the
data
which
needs
to
be
changed
even
even
for
the
same
flow
that
could
happen
by
changing
by
changing
the
information
in
the
dtl
field.
Yeah.
Next,
please,
that's
my
last
play
yeah
thanks.
Thank
you
very
much
and
welcome
my
review
comments
and
feedbacks.
I
There
are
strong
interests
for
from
multiple
vendors
and
operators
on
the
solution
and
we
request
mpls
working
report
option.
Thank
you.
A
A
A
Clear
yep
we
can
hear
you
great
would
would
you,
would
you
like
me
to
move
the
slides
or
would
you
rather
do
it
yourself.
L
Yeah,
it's
extraordinary,
I'm
I'm
the
first
on-site
presenter
good
to
see
everybody
again
today,
I'm
going
to
give
you
a
quick
review
about
update
of
our
npr's
extension
header
draft
next
slide.
Please.
L
Yeah
we
published
the
initial
version
in
2018
and
since
then,
it
has
been
evolved
to
version
zero.
Seven
today
is
based
on
the
numerous
discussions
in
the
open
design
team,
and
now
the
title
is
a
change
to
ips
post
stack
extension
header
to
reflect
or
focus
on
in.
This
draft
is
only
on
how
we
encode
the
mps
network
actions
after
the
label
stack
and
also
we
in
this
new
version.
We
align
the
terms
with
what's
defined,
specified
in
the
mlna
requirements
and
framework
documents,
and
we
also
add
several
new
authors.
L
Yeah
first,
a
quick
recap
about
what
mpls
extension
header
is
about.
Obviously
we
will
need
some
indicators
in
the
label
stack
to
tell
us.
We
have
extension
headers
after
the
label
stack,
but
how
it's
defined
is
out
of
scope
of
this
document.
In
this
document
we
only
specify
how
the
extension
header
itself
is
encoded
after
the
label
stack.
L
As
you
can
see
in
this
figure
up
to
the
label
stack,
we
will
first
have
a
header
of
extension
header,
which
is
basically
a
summary
of.
What's
what
follows
it
tells
you
how
many
header
extension
headers?
You
will
have
what's
the
total
length
of
that,
and
it
also
provides
the
information
about
the
original
high
upper
layer
protocol
type.
L
So
this
is
will
be
useful
to
tell
you
with
the
original
protocol
layer,
4
protocols
in
the
packet,
and
also
it's
tell
you
what's
the
next
headers
type
and
after
this
summary,
you
will
see
a
set
of
standard
containers.
L
Each
of
them
is
a
extension
header
which
will
contain
a
specific
network
action
and
each
container
has
a
standard,
starting
with
a
standard
words.
Tell
you
the
next
headers
type
and
the
current
headers
lens.
This
is
a
very
similar
to
ipv6
extension
header.
L
If
you
are
familiar
familiar
with
that,
so
with
this
arrangement
we
will
support
up
to
15
extension
headers
in
a
single
package,
and
then,
if
we
based
on
the
length
arrangement,
we
can
support
the
maximum
length
of
all
the
extent
headers
can
be
up
to
1k
bytes
in
the
single
packet
and
we
do
allow.
You
only
have
this
header
of
exchange
header
but
followed
by
zero
extent
headers.
L
L
First,
we
want
to
share
the
code
point
with
ip
protocol
numbers,
which
means
we
will
apply.
I
need
to
apply
new
protocol
numbers
from
the
same
same
registry
and
the
new
type
defined
in
this
document
is
of
the
first
one
is
a
num
which
means
no
next
extent,
header
and
the
payload.
After
this
extent,
header.
This
is
the
last
one,
so
this
can
be
used
for
special
packages
such
as
the
probing
package.
L
The
second
type
is
unknown,
which
means
this.
This
can
only
be
used
in
elasticstation
header,
which
basically
tell
you.
Okay,
what's
a
payload
type,
is
we
don't
know?
This
is
a
compatible
with
the
current
practice
in
ips
and
the
next
type
is
a
mpls
means.
Another
nps
label
stack
follows
its
current
extension
header.
This
is
a
very
useful
for
the
hierarchical
use
cases
in
which
you
have
a
multi
level
of
manufacturable
stack.
L
And
all
the
extension
headers
can
be
skipped
in
one
step,
because
we
know
the
overall
size
of
these
headers,
so
it
allows
us
to
quickly
access
the
original
up
layer
protocol
and
also
we
explicitly
support
two
type
of
extension,
headers
end-to-end
tab
and
help
help
type,
and
we
require
the
end-to-end
type
exchange.
Headers
must
be
located
before
the
oh,
a
bit
below
the
hop
by
hop
because
hope,
high
hop
would
not
need
to
be
processed
every
hop.
L
So
you
you
have
to
put
a
hph
type
first
and
followed
by
and
then
after
that
you
will
have
the
end
to
end
type.
So
this
can
help
us
to
optimize
the
performance,
and
you
can
see
each
extension.
Header
is
just
a
stand
standard
container
and
it
allows
to
freely
define
newer
applications
in
the
future.
To
put
it
in
the
extension
header
next
slides.
Please.
L
And
we
have
several
other
companion
documents
with
this
one.
The
first
one
is
actually
a
summary
of
a
possible
method
for
the
exchange
header
indicator,
but
we
we
don't
want
progress
this
document
further.
L
This
is
not
a
network
action
architecture
is
actually
about
the
network,
the
the
network
architecture
to
operate
this
mps
extension
header,
for
example.
It
describes
several
terms
like
the
extension
header
pass,
was
this
relationship
with
a
little
switching
pass
and
we
will
have
extension,
header
capable
and
incapable
nodes
and
how
we
will
announce
such
capabilities
in
the
network.
L
Such
concept
is
actually
is
common
also
to
the
in
in
stack
network
action
and
therefore
it's
possible
to
involve
this
document
for
the
a
network
architecture,
because
we
think
the
concepts
are
covered
in
this
document,
so
very
useful
there.
L
The
last
complaining
document
is
about
mps
extension,
header
label
stack
operations,
it's
a
kind
of
optimized
performance,
optimization
document.
L
Basically,
since
the
label
sensor,
action
itself
can
be
deeply
embedded
in
the
package,
then,
if
we
we
can
based
on
the
top
label,
we
can
tell
there
is
some
actions
in
the
package
that
will
be
useful
help
the
node
to
to
decide
if
we
want
to
examine
the
label
stack,
folder
or
not.
L
So
the
idea
of
that
you
can
use
some
extension
header
forward.
Eq
equipment
class
label
effect
label
to
indicate
that
if
one
node
actually
figure
out
there
are
some
there.
G
L
L
So
this
document
is
already
pretty
mature,
after
many
repeat
different
regions.
So
therefore,
we
also
request
the
working
group
to
adopt
this
as
a
solution
for
supporting
postdeck
network
actions
in
mpis
and
well
also,
we
we
will
next
step.
The
key
work
is
to
determine
actually
what's
the
extension
header
indicator
scheme.
L
We
will
we
need
to
make
that
coherent
with
also
the
indicator
for
in
in
stack
network
actions
and
also
as
the
next
network,
we
will
expand
the
scope
of
other
exchange
header
companion
document
to
make
it
suitable
for
the
mna
work.
Thank
you.
M
L
Yeah,
this
is
a
this
document
is
about
the
post
that
encoding,
and
I
think
this
is
an
independent
part
which
can
be
developed
in
parallel
with
a
insect
with
the
indicator
and
also
the
instead
action.
M
I
I
think
it
will
be
more
helpful
to
discuss
the
solution
that
addresses
all
requirements
that
adopted
by
the
working
group,
not
a
partial
solution.
Thank
you.
A
A
A
N
Okay,
yeah
thanks.
So
if
you
just
stop
on
this
slide,
I'm
presenting
I
did
make
a
big
mistake
of
not
adding
tony
tony's
name
to
the
author
list.
He
did
help
a
lot
so
mia.
F
N
So,
as
I
mentioned,
tony
did
help
you
know
restructure
this
and
took
part
in
a
lot
of
discussions
both
internally
as
well
as
in
the
open
design
team,
and
he
is
fairly
active
there.
His
co-author
on
several
drafts
there
next.
N
J
N
Change
is
to
replace
a
continuation
bit
with
length
fields
and
I'll
get
into
that
in
a
second,
but
the
the
upshot
of
this
is
we're
fairly
confident
that
this
can
be
implemented
efficiently
and,
in
fact,
that's
where
we'll
go
next
next
slide.
N
So
the
big
change
that
we
have,
we
would
have
we
just
have
these
things
called
continuation
fields
or
continuation
bits
and
essentially
a
continuation
bit,
will
tell
you
when
a
particular
block
ends.
So
the
whole
fai
block
at
some
point
has
to
end.
So
if
the
fai
and
I'm
going
to
call
it
fai
for
now,
but
we
should
probably
change
the
terminology.
N
So
we
moved
from
having
continuation
bits
for
the
whole
fai
block
for
the
standard
in-stack
data
and
for
the
user
in
stack
data
user-defined,
exact
data.
So
we.
J
N
N
Also
from
the
point
of
view
of
the
draft
itself,
there
have
been
a
lot
of
improvements
in
readability
and
so,
for
example,
separating
the
description
of
the
label
stack
entry,
which
has
all
the
flags,
but
the
flag
definitions
are
in
a
different
section,
so
it
reads
better
so
so
those
are
the
two
big
changes
between
the
previous
version
and
this
version
at
this
point,
we're
just
you
know,
twitting
bits,
so
we
think
that
we're
really
close
in
terms
of
a
technical
solution
next
slide.
N
So
we
think
that
the
draft
is
ready
for
working
group.
Adoption
we've
been
discussing
this
for
over
a
year
at
this
point
internally,
we've
done
a
lot
of
fine
tuning,
and
so
so
we
think
it's
ready.
N
In
addition,
we
would
like
to
start
doing
some
prototypes
of
this,
both
on
our
chips
and
also
you
know.
Hopefully,
the
broadcom
folks
will
do
some
on
their
chips,
and
each
of
us
has
multiple
types
of
chips,
so
we
can
get
a
sense
of
how
it
is
how
easy
or
how
hard
it
is
to
implement
this
on
a
variety
of
chip
types
to
do
that
it
would
be
nice
to
have
an
early
allocation
of
a
bspl
for
fai.
N
So
I
don't
know
how
these
I
don't
know
how
to
draw
a
dependency
diagram
between
the
three
requests
here,
but
we'll.
Let
the
working
group
cheers
work
that
out
questions.
A
N
H
N
H
And
then,
when
I
look
at
this
document,
I
find
it
fairly
complete
on
isd,
but
it's
much
weaker
on
psd.
Are
you
do
you
agree
on
that,
or
is
it
intended.
H
G
N
Agreed
so
that
was
actually
the
intention.
This
draft
primarily
focus
on
the
isd
part
and
it
points
to
jeffrey's
document
and
I
think
jeffrey
and
how
you
have
combined
so
it's
sort
of
like
you
have
an
ic
document.
This
is
the
ifc
document
and
then
you
have
another
document.
That's
the
pse
document
and
that's
the
one
that
how
you
and
jeffrey
are
writing
so
yeah.
H
F
H
D
Thank
you
kiriti.
I
I'm
a
co-author,
but
I
can't
help
that
there
are
some
resemblance
in
terms
of
handling
in-stack
actions
in
this
solution,
as
well
as
in
the
solution
that
jax
presented
earlier.
So
my
question
now,
as
a
open
design
team
co-chair,
there
is
a
and
we're
trying
to
incite.
You
know:
alignment
between
the
different
solutions,
so
are
there
plans
to
you
know
see
if
you
can
converse
with
the
other
solution.
N
N
So
at
this
point
what
I
would
like
to
do
is
to
implement
what
we
have
here
and
get
some
feedback
from
what
does
it
actually
take
to
implement
this
on
different
kinds
of
hardware
and
yeah?
And
then,
if
my
courses
say
you
know,
there
is
some
some
scope
for
alignment,
I'm
happy
to
think
about
it.
But
right
now,
that's
not
where
my
focus
is.
H
Great,
when
you
said
implement,
are
you
meaning
some
type
of
alpha
implementation
for
for
tests
or
something,
or
are
you
actually
going
for
a
full
product
code.
N
More
like
alpha
more,
you
know,
internal
implementation.
You
know
yeah.
N
N
Yeah,
so
if
others
I
won't
want
to
implement
theirs,
and
then
we
can
have
some
standards
or
not
standards,
but
some
metrics
by
which
we
compare
solutions.
That
would
be,
I
think,
very
helpful,
but
from
from
our
point
of
view,
we
just
want
to
see.
Did
we
specify
this
well,
you
know,
for
example,
continuation
bits
versus
sizes
which
works.
O
N
L
Yeah,
this
is
not
question,
but
just
a
comment.
L
I
I
think
it's
a
very
good
idea
to
actually
compare
the
different
solution,
proposals
from
the
different
perspective,
like
the
overheads,
the
performance,
but
in
this
sense,
in
this
design,
I
think
performance
is
a
very
critical,
so
we
have
to
do
it
carefully
and
on
one
side
we
can
ask
more
asic
experts
to
join
the
work
to
evaluate
scheme,
and
meanwhile
we
can
also
do
the
some
kind
of
software
based
evaluation,
as
it
also
can
be,
do
very
quick
and
give
us
a
sense
of
what's
of
performance.
N
Yeah,
so
you
have
a
good
point,
but
we're
going
to
take
it
in
steps.
So
the
first
thing
is:
is
the
proposal
that
we
have
implementable
reasonably.
N
The
second
step
is:
oh
here's,
our
proposal,
here's
the
metrics
from
our
proposal.
If
someone
else
were
to
do
a
different
proposal,
then
we
can
we
agree
on
the
metrics.
Then
we
can
compare
them,
but
we
want
to
start
with
something
right.
So
we'll
start
with
this
proposal,
but
but
you're
right.
Eventually
we
can
get
there
and
say
here's
some
common
metrics
and
let's
compare
different
implementations.
L
Yeah,
so
so,
basically,
there
are
several
different
type
of
ideas.
One
is
using
the
catalog,
followed
by
the
action
itself
and
just
to
use
a
conventional
chain
leg
structure
right
and
it's
some
other
even
combined
the
two
together.
So
I
I
think,
there's
a
great
imp
implication
on
the
on
the
performance
issue.
So
it's
a
very
critical
to
access.
It.
L
P
It's
not
necessarily
a
question
to
kiriti,
but
it's
more
of
a
working
group
question
is
like
I
think,
for
a
psd.
We
somehow
are
converging
somehow,
as
in
a
single
document,
with
what
why
buu
is
presenting
right
at
the
feeling
for
isd.
We
have
to
probably
competing
solutions.
P
P
I
first
of
all
is
that
aligned
within
the
working
group
as
an
objective,
because
if
you
focus
on
your
thing
and
someone
else
focus
on
his
thing,
then
we
have
like
how
do
we
converge
on
on
getting
towards
a
single
most
optimal
solution
to
implement
which
works
on?
I
would
say
most
hardware.
N
Yeah
so
from
my
point
of
view,
I
just
want
to
know
if
this
particular
approach
works
is
sufficient
and
so
on,
and
so
you
know
independent
of
itf.
We
want
to
do
the
implementation
and
take
back
learnings
and
then
bring
it
back
to
the
drop
and
so
on.
The
convergence
point
is
really
important
and
that's
a
working
group
thing,
and
so
it
would
help
if,
for
example,
the
alternative
solution
did
a
similar
thing
and
then
we
could
compare
them.
You
know
across
some
metrics.
I
don't
know
what
the
metrics
would
be
like.
O
M
N
N
That's
why
the
working
group
gets
a
big
props.
H
Yeah
yeah,
I
kind
of
I
can't
answer
what
the
working
groups
take
on
this
is
just
now.
We
need
to
discuss
it
a
bit,
but
I'm
pretty
much
on
the
same
page
as
as
we
miss,
we
should
take
decisions
that
relates
to
the
standard
based
on
how
we
best
actually
re
reach
to
a
implementable
and
compatible
solution.
So
I
don't.
I
don't
think
there
is
any
kind
of
differences
about
that.
N
Yes,
of
course,
and
you
know
like
I
said,
we
had
a
lot
of
internal
discussions
and
some
of
the
decisions
that
we
made
we
want
to
validate.
That
did
we
take
the
right
answer
to
it,
and
so
I
mean
this
will
be
valuable
feedback
to
the
working
group
as
well
as
for
ourselves
and
our
implementation.
N
D
On
the
same
topic
and
again
as
a
coach
here,
I
I
totally
understand
where
you're
coming
from
kriti
and-
and
there
might
be
valid
reasons
for
diverging.
N
Yeah,
so
I
don't
even
want
to
jump
to
that.
I
want
to
start
with
a
report
of
how
this
particular
implementation
worked
out
and
what
we
learned
from
it,
and
then
we
can
talk
about
where
converge
I
mean
they
can
happen
in
parallel,
but
I
think
doing
the
implementation
would
shed
a
lot
of
light,
but
I
think
in
parallel
we
should
discuss.
N
Are
they
pointed
with
which
we
can
converge
are
the
points
that
are
pretty
incompatible?
What
would
the
shape
of
the
final
solution?
Look
like
again,
I'd
have
to
discuss
with
my
co-authors,
but
you
know
I'm
open
to
those.
A
C
K
K
What
has
been
done
in
passing
suspicion?
Yeah
is
zafar
ali.
What
has
been
done
in
past
in
cases
like
this,
like
we
mentioned,
this
is
data
plane,
so
we
have
to
be
extremely
careful
in
in
moving
forward
with
solution
is
to
define
metric
that
can
compare
solutions
that
can
give
feedback
to
the
working
group
in
terms
of
what
is
what
solution
works,
better,
what
works
whatever
involved,
and
that
has
been
approached.
I've
been
taking
many
times
by
many
working
groups
in
making
decisions
like
this.
K
A
N
Okay,
oh
this
is
the
nfr.
N
Okay,
sorry
next
slide,
please
this
is
going
to
be
quick.
The
nffr
nffrr
draft
was
a
standalone
graph
saying
I
want
a
new
code
point,
a
new
special
purpose
label
and
we've
changed
it
and
said
we
just
want
a
bit
or
whatever
it
turns
out
to
be
an
action
in
the
m
a
document.
N
So
we've
gone
from
asking
for
a
based
special
purpose
label
to
an
action
bit
so
that
we
can
actually
tell
a
router.
Please
don't
do
for
the
past
few
hours
and
the
second
part.
So
if
you
go
to
the
next
slide,
so
in
the
beginning
we
had
a
lot
of
discussion.
We've
incorporated
all
the
feedback
we
bought.
We
got
brought
down
with
this
whole.
You
know
based
special
purpose
labels
and
whether
we
have
our
own
standalone
or
whether
we
incorporated
something
else
so.
N
So
the
problem
is
acknowledge,
people
basically
say
we
need
to
move
forward
with
this
or
or
this
is
a
useful
thing
to
move
forward
with.
No
other
alternatives
have
been
proposed.
There
were
some
feedback.
We
incorporated
that.
So
we
think
this
is
ready
for
working
group
adoption
and
we
will
consider
this
as
part
of
the
prototype
for
the
previous
document.
N
So
when
we
prototype
the
fai
document,
one
of
the
things
there
is
a
no
for
the
fast
field
output
and
we
will
implement
that.
C
Yeah
hi
ketan
talaliker
about
this
problem,
acknowledge
and
solution
acceptable.
I
think
there
are
control
plane
based
solutions,
at
least
for
some
of
the
use
cases
which
I
have
started
a
mail
thread,
and
maybe
we
can
discuss
further.
So
I
I
believe
we
should
discuss
that
and
probably
also
consult
best.
You
know
where
the
evpn
work
is
happening.
There's
a
control,
plane,
solution
there
and
maybe
same
for
perhaps
spring
at
least
those
are
the
two
that
I'm
aware
of
and
yeah.
N
N
So
when
is
going
to
respond
as
a
co-author
but
yeah
how
you
can
come.
R
I
yeah
hi.
This
is
one
from
juniper.
I
aware
recently.
Last
two
years
ago
there
was
another
proposal
for
address
this
solution.
We,
when
this
draft
was
first
published,
we
mentioned
in
the
in
the
talk
why
this
solution,
we
feel,
is
better
because
it's
more
scalable
from
evpn
perspective.
R
In
addition,
the
same
solution
also
applied
for
layer,
3,
vpn
or
other
use
cases.
We
feel
just
so
one
solution
not
only
applied
to
different
type
of
evpn
service
and
also
to
different
other
type
of
service.
So
that's
the
really
the
benefit
for
this
solution.
It's
simple
and
that's
yeah
yeah.
Thank
you.
C
Yeah,
I
I
understood
what
what
was
said
and
I
think
it's
best.
We
discuss
this
and
I
would
suggest
maybe
including
the
best
working
group,
perhaps
because
it's
yeah
I
I
I'm
not
saying
that
the
best
the
individual
draft
is,
let's
say,
all
complete
and
all
good
and
ready.
Perhaps
you
know
it
can
be
improved
so
yeah.
We
can
continue
the
discussion.
M
L
Okay,
yeah,
okay.
I
think
this
is
a
interesting
use
case
because
it
has
some
unique
features.
We
need
to
consider
in
our
mna
discussion,
because
in
my
understanding
this
action
is
actually
applied
on
the
inserted
on
the
following
mps
label:
switching
paths:
it's
not
starting
from
the
edge.
L
So
if
you
allow
such
kind
of
actions
it
implies
in
our
requirement.
We
do
allow
to
insert
or
remove
some
certain
actions
on
the
following
paths.
So
my
personal
opinion
is:
we
should
allow
such
kind
of
behavior.
This
will
make
our
this
mma
more
flexible,
but
I
don't
think
it's
a
currently
reflecting
the
requirement
or
architecture
documents.
So
we
should
discuss
that
further.
Okay,.
D
M
Wanted
to
remind
that,
no
forr
is
a
part
of
the
use
cases
document
adopted
by
the
working
group.
Thank
you.
Thank
you.
A
Okay,
how
you
I
saw
your
name
flash
for
a
moment
and
then
then
go
down,
so
I
think
you're,
probably
okay,.
A
Okay,
very
good,
so
I
think
you're
all
set
karini.
Thank
you
very
much.
Thank
you
now
from
from
this
point
on,
let
me
close
kuwaiti's
slide.
A
And
turn
my
own
camera
on
okay,
great.
So
from
this
point
on,
we
have
open
discussion
time.
So,
if
there's
anything
that
anyone
would
like
to
bring
up
regarding
anything,
that's
been
discussed
or
anything
else,
that's
going
on
with
the
open
design
team.
Now
is
your
chance
either
remotely
or
in
the
room.
I
would
like
to
remind
you:
if
you're
in
the
room,
don't
just
walk
up
to
the
mic.
Please
use
the
the
tool
to
get
into
the
queue,
so
we
can
manage
it
correctly.
Tariq
you're
next.
D
Tarik
saad
and
my
question
was
to
dragon
I
I
don't
know
if
the
plan
was
to
bring
back
slides,
but
I
don't
need
that
they
presented
ini
and
ine
to
indicate
actions
in
the
stack
and
post
the
stack.
My
question
is
about
the
order
of
invocation
of
actions.
D
A
I
So
if
you
ask
I'll
just
repeat
the
question
so
that
I
understood
your
question,
so
we
have
a
ini
and
pni
so
you're
asking
that
ini
is
for
the
instructor
indicator
and
the
pns
for
the
post
stack
indicator
so
asking
like
which
one
whether
in
stack
or
post
stack,
is
going
to
be
the
first.
D
I
Okay,
so
the
order
actually
like
in
the
order
like
what
we
encode.
That's,
why
you
said
it's
more
flexible,
like
you
know
the
application
up
code,
10
and
application
20
right,
so
the
20
can
come
first
and
then
can
come
second,
so
it's
more
flexible
like
it's,
whatever
the
hidden
things
that
the
order
should
be.
It
can
encode
that
way
in
the
instax
data
wise
right,
so
instagram
is
supposed
to
post
track
data
so
that
actually
like
we
haven't
covered
it.
I
Probably
we
can
talk
to
hawaii.
Who
are
you
so
who's
our
you
know
like
post
stack,
encoding
partner,
so
we
can
discuss
with
them
and
then
we
can
come
with
that.
N
N
M
Nursky
erickson,
so
my
question
to
kiribi,
so
am
I
understanding
correct
that
you.
M
Intend
to
to
cooperate
with
how
you
for
the
post-tech
data
encoding.
N
Yes,
indeed,
so
the
idea
would
be
I
mean
our
implementation
will
focus
on
the
in-stack
piece,
and
you
know
I
have
a
bit
here
and
can
I
parse
it
and
can
I
get
the
associated
data
not
for
nffrr,
but
maybe
for
the
slice
id
and
so
on.
But
there
will
be
a
bit
that
says
there
is
postac
data
and
then
we'll
see
what
it
takes
to
implement
to
to
reach
the
post
act
data,
but
the
post
stack
data
format
will
be
what's
defined
by
how
you
and
jeffrey.
N
M
So
that
means
that
you
support
the
idea
that
encoding
of
instant
data
and
poster
data
will
be
different
using
different
encoding,
yeah.
Okay,
interesting
thanks.
N
A
Q
Okay,
so
my
first
comment
is
about
the
postdeck
data.
I
think.
According
to
the
previous
poll
result,
it
shows
that
the
psd
is
a
necessary
component
of
the
mna
framework
and
resolution
and
from
the
today's
discussion
it
is
clear
that
we
are
converging
on
the
single
solution
for
the
psd
encoding,
so
that
maybe
it
is
a
a
good
thing
to
move
forward
post
that
data
encoding
first.
Q
According
to
the
poll
again,
we
think
that
it
shows
that
people
agree
that
isd
may
be
used
well,
there's
also
some
concerns
about
to
suggest
to
minimize
the
use
of
the
isd,
so
it
seems
that
it
would
be
better
to
define
isd
as
an
optional
component
so
that
we
can
allow
a
mechanism
to
carry
the
indicator
plus
the
psd
only,
and
the
second
thing
is,
if
we
want
to
minimize
the
use
of
isd
as
it
seems,
the
length
of
the
isd
should
be
constrained
and
the
format
should
be
easy
to
pass,
because
we
have
seen
the
proposals
to
carry
the
isd
multiple
times
in
the
level
stat.
Q
Also
we
also
unders.
The
first
thing
is:
we
may
need
to
consider
the
possible
changes
to
the
label
stack
operation
introduced
by
the
isd.
So
these
are
the
some
concerns
about
isd
design
and
following
these
considerations,
we
have
just
just
submitted
a
new
draft
on
the
encapsulation
this
week.
I
will
post
it
to
the
chat.
Okay,
thanks.
H
H
Do
we
actually
think
that
if
you
look
at
psd,
for
example,
we
can
actually
take
them
in
the
order
they
are
specified
and
then
just
go
through
the
entire
entire
chain,
or
is
it
like,
depending
on
act
which
actions
we
have,
the
order
could
be
be
different.
D
My
question
now
is
on
terminology
of
the
framework
draft,
but,
coincidentally,
it's
related
to
what
law
is
asking.
There
is
a
term
we
introduced
in
the
frame
framework.
Is
network
action,
sub
stack,
you
know
it
gives
the
illusion
is
it's
a
stack
and
there
is
an
order
of
how
we
push
to
the
stack
and
then
pop
or
if
we
want
to
do
popping,
I'm
not
sure
if
we
are
going
to
allow
popping
of
an
action
from
the
sub
stack.
D
So
that
would
be
one
thing
to
clarify
and
the
stack
is
you
know
it
has
an
order
in
nature
like
a
nature
of
stack,
it's
like
there's
an
order
of
who
pushed
first
and
where
that
entry
sits.
So
with
that,
you
know
placing
the
order
of
the
stack,
be
the
order
of
invocation
of
the
action.
H
D
At
least
if
we
can
clarify
within
isd
because
the
framework
draft
talks
about
sub
stack
or
action
network
action,
sub
stack.
B
E
Okay,
so
so
the
solution
has
its
out.
Basically,
a
solution
has
to
define
what
the
order
of
operations
for
the
network
actions
are.
Now
that
could
be
anything
deterministic
you
can
go
according
to
code
point
numbers
you
could
go
top
to
bottom
left
to
right.
You
could
go
right
to
left
bottom
to
top
whatever
you
want
to
do
as
long
as
it's
deterministic
and,
of
course
it
has
to
be
specified
in
the
solution
document.
H
L
Ahead:
okay,
yeah,
I
I
think
for
psd.
The
only
requirement
we
suggest
is
to
put
the
hope
by
hope,
type
before
the
end
to
end
type,
because
in
on
the
past
past
note
you
you
never
need
to
look
beyond
the
hope,
I
hope
extension
headers.
So
that's
the
obvious
optimization
other
than
that.
L
I
don't
think
we
should
dictate
any
order
of
execution,
because
that
totally
depends
how
you
implement
that
in
many
platforms
I
I
know
that,
actually
they
do
the
header
parts
up
front
and
then
in
actual
factory
for
a
processing
pipeline
they
decide
which
which
one
to
actually
execute
first
with
the
order
of
execution.
So
in
that
sense
we
we
shouldn't
dictate
the
order
of
actions.
J
I'm
going
to
say,
following
up
on
what
tony
said,
it's
also
possible
to
define
a
composite
network
action
which
is
a
set
of
individual
network
actions
in
a
specific
order.
A
O
I
had
a
quick
question:
if
there's
a
case
where
you
had
both
in
stack
and
post
stack,
I
guess
in
parallel,
would
there
be
any
performance
issues
with
and
probably
order
of
operations
kind
of
what
we're
talking
about
with
the
mna
actions
of
you
know,
processing,
post
stack
first
and
then
and
then
in
stack
or
maybe
not
doing,
both
in
parallel,
because
that
seems
like
there
may
be
performance
issues
related
to
that.
Thank
you.
A
Was
that
question
aimed
to
anybody
in
particular.
O
I
I
just
it
was
for
anybody
who
could
answer.
I
just
a
question
that
I
thought
of
how.
How
would
that
work
and
would
would
would
there
be
an
order
of
operation
if
you're
processing
pull
stack
and
then
you
also
had
in-stack
data
first,
would
you
want
to
process
in-stack
first
before
post-stack,
or
vice
versa?
N
Yes,
so
the
the
idea
of
in
stack
data
is,
it
should
be
the
stuff
that
is
more
critical
and
because
it's
more
critical,
you
want
to
put
it
closer
to
the
top
of
stack.
You
know,
cause
a
lower
penalty
or
impose
a
lower
penalty
on
getting
to
it
and
doing
things.
N
So
there's
this
implicit
thing
that
anything
that
you
put
in
stack
is
more
urgent
and
then
the
post
stack
staff
also
has
x
and
the
additional
thing
that
there
will
be
some
things
that
are
hop
by
hop
and
some
things
that
are
end
to
end
so
post
stack,
you
would
never
put
something
that's
in
stack,
which
is
end
to
end.
That
would
be
a
waste
of
in
stack
space.
N
So
so
that's
kind
of
the
answer
to
your
question
again
that
in
stack
data
will
generally
be
more
urgent
and
stuff.
You
want
to
do
first,
post-stack
data
will
be
generally
stuff
that
you
is
more
optional
and
some
of
it
will
definitely
be
pushed
only
to
further
end.
So
it's
not
the
hop
by
harvest
end
to
end.
A
Great,
thank
you.
Now
we
have
five
minutes
left
in
the
session
and
meet
echo
is,
is
pretty
strict
about
meetings
ending
on
time,
so
I've
locked
the
queue
with
two
people
left
rock
cash
and
then
how
you
so
rakesh
go
ahead.
F
Hi
from
cisco
system,
so
just
to
answer
that
question
on
the
order
in
which
the
network
action
to
be
executed,
the
jack
strap
has
a
very
good
solution
for
it,
which
is
opcode
base
and
the
end
cap
node
can
add
the
of
course
in
a
certain
order.
F
It
can
be
24
and
10
or
whatever
order
that
end
cap
note
desires
the
midpoint
to
perform
the
action.
That's
one
good
feature
about
it.
The
second
thing
is
that
an
awkward
itself
can
be
defined
as
a
series
of
flags,
and
it
has
a
meaning
that
it
needs
to
be
executed
in
this
order,
so
that
also
allows
us
to
do
the
operations
at
midpoint
without
any
ambiguity
in
a
certain
order.
So
there
is
a
lot
of
flexibility
in
the
draft
to
help
with
this
situation.
Thanks.
L
Yeah,
I
I
don't
think
the
urgency
is
a
criteria
to
put
it
in
stack
or
post
stack,
because
obviously
some
actions
will
require
a
large
header
overhead.
You
simply
cannot
put
it
in
stack
because
a
size
too
big
to
put
in
the
stack
you
have
to
put
in
post
stack
so,
but
it
might
be
very
important
to
for
that
action
so
and
also
from
the
hardware
design
perspective.
L
D
D
Okay,
I
was
gonna,
ask
a
question.
Oh
my
goodness,
I
forgot
anyways,
I'm
sorry
I'll.
A
H
A
You
can
take
it
to
the
list,
please,
okay,
and
with
that
I
would
like
to
close
today's
pals
mpls
and
detonate
joint
session,
I'd
like
to
thank
everyone
who
participated
both
remote
and
in
person,
and
we
will
see
you
all
at
iatf
115..