►
From YouTube: IETF113-PALS-20220324-0900
Description
PALS meeting session at IETF113
2022/03/24 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
I
think
we
start
we'll
get
through
the
boilerplate
stuff
first,
so
I
can't
see
the
chat
at
the
moment.
So
if
anyone
which
needs
to
draw
something
to
my
attention,
please
do
so.
I've
asked
nick
to
be
made
a
chair
as
well,
which
will
help
but
hasn't
happened
yet
right.
So
welcome
to
this
meeting
of
the
joint
meeting
of
the
pals
mpls.net
working
working
groups.
A
A
So
the
purpose
of
this
meeting
is
a
joint
meeting
of
the
three
working
groups
and
it's
being
called
to
discuss
the
basic
architectural
issues
and
solution.
Proposals
arising
from
drafts
that
proposed
new
application
uses
at
the
bottom
of
the
mpls
label,
stack
the
general
structure
of
the
meetings
as
follows:
we're
going
to
start
with
a
status
report
on
the
open
design
team
work
to
date
and
then
we're
going
to
go
through
use
cases,
requirements
and
framework.
A
A
A
A
A
I'll
just
leave
this
for
a
couple
of
moments.
So
all
these
this
material
is
available
by
the
data
tracker
anyway,
but
these
are
the
resource
links
for
the,
where
you
find
the
agenda,
where
you
find
the
docs,
where
the
jabber
room
is
where
the
odt
wiki
is,
which
is
where
we've
been
keeping
all
of
the
minutes:
meeting,
information,
etc.
A
B
C
C
C
The
participation
is
about
20
part
participants
each
week
it
might
be
peaks
depending
on
what
topic
is
discussed
and
there
are
about
20
documents
that
the
design
team
are
discussing
next
and
are
using
the
term
documents
a
little
bit
freely
there,
because
some
of
the
discussions
are
on
things
that
are
in
the
wiki
next
slide.
Please
miad.
C
C
Related
to
an
lsp
we
talked
about,
and
here
I
had
a
comment.
That
is
not
very
clear.
What
I
mean
the
square
brackets
are
actually
are
alternatives,
so
we
talked
about
forwarding
actions
and
that's
in
create
this
document.
We
talked
about
network
action
and
then
it's
and
john
drake's
text
in
the
the
the
wiki
and
we
talked
about
mid
miat
actions
as
a
alternative
name,
and
then
there
are
suggestions
that
we
just
talked
about
actions
and
don't
design
them
more
than
that,
and
we
would
actually
like
to
prefer.
C
C
We
have
at
least
two
types
of
documents,
one
one
type
of
document
or
what
I
call
guiding
and
that's.
This
is
not
an
itf
term.
This
is
my
term
and
to
in
that
group
I
count
requirements
framework
in
use
cases,
and
then
they
have
document
that
that
says
specifying,
and
that
is
mostly
the
solutions
document
next
slide.
Please.
C
C
C
C
End-To-End
discussion
is,
we
don't
have
the
consensus
among
the
shares
to
actually
do
the
poll,
so
it's
on
hold.
The
indicator.
Name
will
probably
be
solved
in
the
framework
and
requirement
stress
and
then,
if
we
want
to
use
a
new
or
a
special
purpose
label
or
if
we
want
to
have
a
new
one,
that
is
if
we
want
to
use
an
other
one,
an
old
one.
That's
still
under
discussion
next
slide.
Please.
C
Normally,
the
traditional
mpls
uses
a
control,
pane
and
signaling
between
the
nodes
to
tell
the
lsr
what
to
do,
but
in
myad
we
actually
use
the
data
stream
to
send
information
between
with
the
packet
between
the
nodes
and
that
actually
brings
a
strong
dependency
on
hardware
and
the
design
team
has
had
quite
a
number
of
discussions
on
hardware.
Optimizing
coding.
C
A
E
Okay,
can
you
hear
me
just
a
confirmation
that
you
can
hear
me
hello,
hello?
Yes,
I
can
hear
you
okay,
okay,
great!
Thank
you!
So
hello,
everyone,
my
name
is
tarek
saad
and
I'm
going
to
talk
about
the
use
cases
for
mpls
indicators
and
ancillary
data.
Indeed,
as
lower
mentioned,
there
are
variants
in
on
my
slide.
I
call
them
function
indicators.
E
In
other
cases,
they
are
action,
indicators
and
so
on.
So
I'm
yet
introducing
another
term
to
the
to
describe
these
indicators,
so
we
need
to
the
action.
Take
that
action
to
align
and
pick
up
one
one
term
for
for
the
indicators
description
I
am
presenting
a
bit
on
behalf
of
the
co-authors.
We
are
part
of
the
open
design
team,
the
objective
of
this
document
to
compile
the
use
cases
for
mia
that
that
the
design
team
has
been
discussing
in
the
weekly
calls.
E
E
E
E
There
are
cases
where
we
have
fast
readout
protection
and
after
the
failure
we
read
out
traffic
on
the
on
the
backup
path,
but
then,
on
the
back,
while
the
packets
are
traversing
the
backup
path,
there
could
be
another
secondary
event,
a
failure
event
and
still
a
another.
Fr
can
happen
on
the
backup
path
itself
and
rerouting
the
packets
towards
the
original
pplr.
In
that
case,
there
could
be
a
loop
that
could
happen
between
the
two
plrs,
the
first
plr
and
the
second
event
plr.
E
There
is
an
example
in
the
document
described
where
we
have
multi-homing
and
edge
protection
and
cep
links
fail.
The
the
the
pair
of
pes
are
protecting
each
other,
so
the
first
event
the
pe
would
send
to
the
other
pe
and
then
the
second
event
other
pe
will
send
back
to
the
first
pe,
and
we
have
that
loop.
E
E
E
This
is
one
flavor
of
oem,
where
we
carry
additional
data
inside
the
user,
plain
traffic,
so
such
data
like
telemetry
or
operational
data
like
time
stamps
and
so
on,
is
carried
along
with
the
user
traffic
and
and
these
these
ancillary
data
can
be
updated.
A
lot
by
lsrs
as
the
packet
traverse
the
path.
E
So
there
is
a
flavor
of
ion
that
touches
the
packet
content,
hop
by
hop,
and
there
is
another
flavor,
that's
only
edge
to
edge.
So
the
requirement
is
to
have
such
an
iuem
function
indicator
carried
inside
the
packet
so
that
we
can
alert
the
nodes
that
need
to
process
or
update
the
ancillary.
The
iom,
ancillary
data
next
slide,
please
so
the
third
use
case
that
we
touched
upon
is
related
to
network
slicing
and,
more
specifically,
to
a
network
resource
partition,
which
is
the
underlay
which
is
a
partitioning
of
the
underlay
network.
E
E
So
this
is
the
third
use
case.
The
the
fourth
use
case
is
related
to
time
sensitive
networking.
We
have
compiled
this
use
case
and
we
admit
that
we
haven't
given
it
much
investigation.
Yet
we
need
to
engage
that
net
working
group
on
their
interest
in
in
covering
this
use
case
in
more
detail.
But
here
it
is
the
packet.
E
The
mplus
packet
can
carry
a
timestamp
or
a
time
budget
that
enable
rockers
to
make
queuing
decisions
when
the
packet
is
traversing,
a
an
lsp,
so,
for
example,
they
could
prioritize
sending
out
the
packet.
If
the
time
budget
budget
is
is
shorter
and
as
as
packet
are
forwarded
along
the
path
we
have
a
times
timestamp
or
budget
associated
with
every
hub,
for
example.
E
E
We
know
about
rfc
8986,
which
is
network
programming
in
srv6
data
plane,
the
this
rfc.
With
with
that
functionality
we
get
we.
It
allows
an
operator
on
an
application
to
specify
a
packet
processing
program
that
to
be
encoded
inside
the
packet
and
as
well
a
sequence
of
instructions
inside
the
packet
header.
So
once
we
carry
this
inside
the
packet,
we
can
allow
such
a
program
to
be
run
by
the
network
on
specific
nodes.
E
The
mpls
packets
may
carry
such
such
a
program
instruction
as
a
function
indicator.
So
that's
one
thing
we
discussed
during
the
design
team
as
a
potential
functionality
that
can
could
come
out
from
miad
is
that
carrying
such
a
program
inside
the
packet,
as
well
as
some
arguments
that
we
can
pass
along
so
that
we
can
run
that
function
or
our
program
and
those
arguments
can
be.
The
ancillary
data
carried
with
the
with
the
packet
and
the
last
use
case
that
we
compiled
in
this
report
was
related
to
service
function.
E
Some
of
the
documented
use
cases
were
driven
by
application
requirements
that
we
know
about.
There
are
there's
interest
from
the
field
in
in
solving
these
use.
Cases
other
require
further
investigation
and
validation,
as
I
pointed
so,
we
would
welcome
operators
and
other
experts
to
engage
and
sound
their
opinion
on
this.
F
G
A
A
So
in
part,
this
is
to
make
sure
that
we
we
don't
trip
over
any
of
the
historic
work
in
the
those
systems,
continue
to
work
properly
as
to
why
this
is
tagged,
a
pals
meeting
it
is,
it
is
entirely
sort
of
procedural
and
administrative,
because
we
couldn't
do
it
all
in
one
slot,
and
so
the
we
requested
a
second
slot
to
deal
with
this
particular
thing.
Mpls
will
follow
in
doing
its
normal
work.
H
H
E
H
E
So
good
point:
let
me
let
me
try
to
answer
that
so
indeed,
as
I
mentioned,
some
of
the
application
requirements,
some
of
the
requirements
were
driven
by
by
use
cases
brought
forward
from
the
field
and
the
number
five
was
an
aspiration.
You
know,
as
you
say,
if
we
model
number
five,
we
can
model
any
function
or
any
program
to
be
invoked
in
the
packet.
E
H
And
my
point
is:
if
you
look
at
five,
I
mean
it's,
maybe
a
good
reflection
on
the
other
use
case,
because
if
you
do,
let's
say
have
a
general,
I
in
my
view
five
is
a
bit
of
a
general
structure
to
be
able
to
do
multiple
things
right.
I
at
least
that's
the
theory,
and
if
you
could
see
that
you
can
model
the
other
use
cases
by
doing
five,
that
would
then
I
then
we
have
a
general
generic
mechanism
to
do
multiple
use
cases.
H
E
A
J
J
So
the
the
requirements
we've
got
in
there
were
largely
derived
from
looking
at
the
proposals
for
additions
to
the
mpls
label,
stack.
So
look
at
some
of
the
solutions
that
propose
looking
at
the
use
cases
to
allow
decisions
about
those
actions
based
on
application
data
and
that
application
data.
So
that's
that's.
The
ancillary
data
can
exist
within
or
below
the
label
stack
and
the
actions
can
be
performed
by
intermediate
or
transit,
lsrs
or
terminating
lsrs.
J
Of
for
the
lsp,
I
should
make
clear
that
the
requirements
are
on
the
protocol
design
work
not
on
what
implementations
have
to
support,
as
I
think
is
generally
the
case
for
the
requirements
documents
and
these
projects
in
the
itf
next
slide
is
so.
The
draft
is,
is
structured
into
kind
of
four
sections.
J
J
So
the
first
one
is
the
ancillary
data,
so
this
is
defined
in
this
requirements.
Draft
as
data
relating
to
the
mpls
packet
that
may
be
used
to
affect
the
forwarding
or
other
processing
of
that
packet,
either
an
ler
or
an
lsr,
and
this
data
may
be
encoded
within
the
label
stack,
so
it's
termed
in
stack
data
or
and
or
after
the
bottom
of
the
label
stack
and
that's
termed,
post
stack
data.
J
The
second
major
term,
new
term
is
the
ancillary
data
indicator
or
adi.
So
this
is
an
indicator
in
the
mpls
label.
Stack
that
ancillary
data
exists
in
the
packet.
It
can
also
indicate
the
specific
type
of
the
ancillary
data,
so
it
gives
some
indications
on
how
to
process
the
the
ancillary
data.
In
that
case,
we
also
tried
to
define
end
to
end
and
hot
by
hot,
but
really
these
need
to
be
defined
in
these
really
architectural
concepts
and
they
they
need
to
be
defined
ready
in
the
framework
draft.
J
So
I
won't
dwell
on
those
here
next
general
requirements.
So
this
is
the
first
of
the
main
requirement
sections
and-
and
these
are
mainly
about
ensuring
consistency
of
the
design
with
mpls
and
the
efficiency
of
the
protocol
and
I've
just
copied
a
few
of
the
main
ones
here
from
from
the
requirements
draft.
J
So
so
mpls
today
combines
extensibility
flexibility
and
efficiency
by
using
a
control
plane
context,
combined
with
some
very
simple
data
plane
mechanisms
to
allow
the
network
to
make
forwarding
decisions
about
a
packet
and
we're
not
trying
to
change
or
break
or
be
inconsistent
with
any
of
these
properties.
So
any
solution
must
maintain
these
kind
of
properties
of
mpls
in
general.
J
Any
solutions
to
these
requirements
must
not
restrict
the
generality
of
the
mpls
architecture,
so
what
we
meant
by
that,
I
think,
was
the
ability
of
the
mpls
architecture
to
evolve
and
be
extended
in
future
for
new
solutions,
so
we're
not
kind
of
nailing
down
a
particular
version
of
the
npls
architecture.
Here,
it's
it's
proven
to
be
extremely
flexible
in
the
past
and
by
mpls
architecture
we
mean,
what's
defined
in
rfc's,
3031
and
3032.
J
If
extensions
to
the
mpls
data
plane
are
required,
they
must
not
be
inconsistent
with
the
mpls
architecture,
so
we
are
going
to
try
and
use
the
as
much
as
possible
the
existing
mechanisms
provided
by
mpls,
the
design
of
any
mechanism
should
be
such
that
an
lsr
is
able
to
efficiently
pass
the
label
stack
and
mechanisms.
So
that's
basically
don't
detract
from
the
existing
very
efficient
data.
Plane.
J
Design
of
mpls
and
mechanisms
must
not
add
more
labels
to
the
label
stack
than
is
necessary,
so
try
and
constrain
the
size
of
the
packets,
because
there's
still
a
lot
of
hardware
out
there
in
deployed
networks.
That
would
have
issues
parsing
very
large
packets
next
slide.
So
then
we
have
some
requirements
on
the
ancillary
data
indicators
themselves.
I
won't
go
through
all
these
there's
quite
a
few,
quite
a
few
in
the
draft,
so
I
won't
go
through
them
all
in
this
presentation.
J
I
just
wanted
to
give
you
an
overview
of
the
intention
of
this
section,
so
this
is
a
specific.
These
are
specific
requirements
on
the
design
of
ancillary
data
indicators
and
then
really
address
the
following
themes.
So,
firstly,
the
need
for
an
adi
at
all
coexistence
of
the
adi,
which
is
in
the
label,
stack
with
existing
mpls
mechanisms.
J
Now
require
the
next
section
is
on
requirements
on
the
ancillary
data
itself.
Now
these
are.
These
are
quite
high,
obviously
quite
high
level.
We're
not
necessarily
designing
the
details
of
the
ancillary
data,
but
we
need
to
at
least
have
sufficient
protocol
design
work
to
identify
what
the
ancillary
data
is
and
roughly
what
to
do
with
it.
So
the
high
level
these
are
high
level
requirements
and
then
just
address
a
set
of
themes.
J
The
next
one's
around
price
call
efficiency,
so
ensuring
ancillary
data
is
not
too
deep
in
the
packet,
so
we
don't
have
to
parse
through
a
whole
bunch
of
other
layer,
four
headers,
for
example,
although
three
headers
in
the
packet
before
we
hit
the
ancillary
data,
whether
processing
impacts
the
immediate
forwarding
operation
or
is
or
if
mis-ordering
is
allowed.
So
we
had
a
lot
of
discussion
on
in
the
design
team
on
fast
path
versus
slow
path,
processing.
J
That's
one
one
thing
so,
and
we
identified
a
couple
at
this
stage
and
again
this
is
requirements
on
the
kind
of
protocol
design
work
that
we
need
to
do.
This
is
not
saying
that
everybody
has
to
implement
this,
so
the
solution
is
intended.
It
is
needed.
A
solution
is
needed
to
verify
the
authenticity
of
ancillary
data.
So
if
I
get
some
ancillary
considerate
data,
do
I
know
it's
where
it
came
from?
Is
it
authentic
do?
I
trust
it
and
the
design
shouldn't
expose
or
must
not
expose
confidential
information
in
to
the
underlying
network?
J
We
know
it
needs
a
bit
more
editorial
cleanup,
there's
I
when
going
through,
I
suppose,
a
couple
of
duplicate
requirements,
there's
also
an
additional
set
of
comments
received
on
version
two
which
we
need
to
address,
so
we
think
they're,
fairly
straightforward,
and
once
we've
done
this,
I
think
the
authors
believe
the
draft
is
quite
mature.
Now
it's
been
around
for
several
months
and
through
three
it
would
have
been
through
four
reversions.
By
that
point,
it's
mature
and
ready
for
the
mpls
working
group.
Adoption.
J
G
J
J
K
The
other
thing
that
we've
said
about
insect
data
is
it
there
needs
to
be,
and
I
don't
know
how
you
finally
implement
this.
Maybe
by
having
an
expert
team
or
expert
commentary
in
you
know,
when
you
do
the
allocation
in
ayana,
there
has
to
be
some
sense
of
why
this
is
so
urgent
that
it
needs
to
be
in
stack
versus
post
stack.
K
So
I
think
that's
kind
of
so
those
two
things
are
what
has
been
guiding
us
so
far
in
terms
of
what
we
put
in
stack
and
how
much
we
put
in
stack
there.
Is
this
whole
other
thing
about?
If
you
want
to
go
post
stack,
can
you
actually
reach
it,
and
can
you
do
something
useful
with
it
and
matthew
mentioned
a
little
bit,
but
I
think
we
could
say
more
more
about
that.
J
You
could
generalize
this
and
not
had
a
requirement
that
around
or
along
the
lines
of
what
you
were.
You
were
mentioning
kriti
in
that
sense
that
we
could
say
we
could
provide.
Basically,
some
justification
has
to
be
made
in
us
in
a
solution
for
putting
in
stack
versus
post
stack,
but
why
do
you
need
it
in
stack,
because
that
has
potential?
You
know
if
it's
especially
if
it's
large
could
have
a
significant
impact
on
the
processing.
L
Hello,
so
same
concern
for
a
label,
a
stack
deep
because
there
are
some
chipset
like
broadcom,
widely
used
by
some
vendors.
Only
three
a
label
stack
are
supported
and
I
just
wonder:
is
it
possible
to
reuse
some
kind
of
like
label
bits
or
ttl
or
something
else
for
miats
or
it
should
be
added
somewhere?
As
you
sit
at
the
bottom
or
in
a
stack.
J
I
I
mean
there
are
solutions
that
have
that
have
been
proposed
that
reuse
bits
within,
for
example,
a
special
purpose
label
and
their
solutions
are
being
proposed
that
have
an
extra
additional
flags
field
which
follows
a
special
purpose
label.
So
there's
both
solutions,
kind
of
on
the
table
at
the
moment
in
the
in
in
the
open
design
team.
But
I
think
that
some
of
this
is
is
kind
of
been
some
discussion
around
the
framework
as
to
exactly
how
we
structure
this
in
in
the
label
stack.
K
M
Jeff
and
sure
a
couple
of
points
here
to
try
to
make
successful
number
one.
This
functionality
should
be
clearly
explained
to
consumers
this
technology,
all
of
us
who
built
routers,
we
know
we
would
receive
rfq
from
a
customer
saying
I
want
you
to
support
five
labels.
I
need
two
labels
for
basic
functionality
for
our
scare
over
carrier.
Right,
so
same
type
of
explanation
needs
to
be
provided
to
people
who
are
going
to
use
this
technology.
Otherwise
it's
absolutely
unclear
what
you
need
instead
out
of
stack,
how
do
you
signal
it?
M
C
I
got
the
first
one
in
in
reasonable
time,
at
least
a
couple
of
hours
before
the
deadline.
This
one
was
not
before
the
deadline
and
I
got
a
new
deadline
from
david,
but
it
actually
means
that
it's
my
report,
it's
no
one
else
actually
saw
the
slice
before
they
were
posted.
So
if
there
are
objections
or
want
to
make
changes,
you
can
chime
in
so
next
slide.
Please.
C
C
C
It
should
be
noted
that
all
three
of
us
are
very
busy
and
we
had
very
little
time
to
actually
work
on
the
framework
we
managed
to
make
it.
But
when
we
sat
down
after
actually
posting
it,
we
knew
that
there
were
a
lot
of
work
to
be
done,
and
what
I
say
is
that
in
that
situation
we
actually
got
the
christmas
present
next
slide.
C
C
C
C
C
C
N
N
N
This
requires
nps
packet
to
carry
more
spl
or
espl
per
application,
and
this
will
increase
the
mpls
stack
that
size
drastically.
To
solve
this
problem,
we
need
a
generic
framework
to
build
the
mpls
extension
header,
encoding
format
that
would
carry
multiple
forwarding
instructions
in
the
mpls
label
stack
or
after
the
bottom
of
mpls
label
stack.
N
Our
draft
mainly
complies
with
the
mean
requirements
which
has
been
described
before
so.
The
main
objective
of
this
draft
is
mpls.
Packet
should
be
able
to
carry
two
type
of
forwarding
instructions.
One
is
the
flag
based
instruction
that
does
not
need
any
anchor
data.
Another
one
is
the
forwarding
instruction
that
needs
science
for
the
data.
N
The
second
one
is
mpls
packet
to
carry
additional
data
after
the
bottom
of
stack
and
third,
one
is
any
combination
of
in-stack
and
mpls
mpls
bottom
of
stack.
Forwarding
instructions
could
coexist
in
the
same
impedance
packet.
The
fourth
one
is
the
new
solution
which
we
are
going
to
propose
is
a
backward
compatibility.
N
N
The
appearance
extension
header
mainly
consists
of
two
parts.
One
is
the
mps
extension
header
indicator,
so
this
indicates
the
presence
of
mpls
extension
in
the
packet.
Next,
one
is
the
mpls
extension
header
format,
the
format
in
which
the
mpls
extension
could
be
carried
in
the
mpls
packet
next
slide.
Please.
N
Let
us
see
the
different
options
of
mps
extension
header
indicator,
so
option.
One
is
to
extend
the
existing
eli
el
by
repurposing,
the
els
tc
and
ttl
feed
to
indicate
the
presence
of
the
empire.
Section
header
option
two
is
to
assign
a
new
special
purpose
label
to
indicate
the
presence
of
the
empire.
Succession,
header
and
option
three
is
to
use
user
configured
label
to
indicate
the
presence
of
the
empire's
extension
header.
N
Each
option
has
its
own
advantages
and
disadvantages.
We
could
choose
the
options
based
based
on
our
discussion
on
the
ietf
working
group,
so
here
in
this
in
this
data
structure.
So
if
you
see
there
are
important
fees
there,
the
first
field
is
the
in
stack
data
length
field.
So
this
is
actually
a
three
bit
length
field,
so
this
indicates
the
in
stack
mpls
extension
in
the
order
of
four
bytes.
Some
of
the
parser
would
require
the
length
of
the
instax
mpl
extension
for
the
easy
parsing.
N
The
next
one
is
the
instax
mpls
extension
header
presence
indicator.
This
is
the
bit
field.
That
indicates
the
presence
of
the
stack
extension
header
and
next
one
is
the
bottom
of
the
stack
empire's
extension
header
presence
indicating
a
bit
field
indicates
the
presence
of
the
boss,
mpls
extension
header,
that
the
fourth
one
is
the
hop
by
hop
boss
and
pls
extension
header
indicator.
A
bit
field
indicates
the
presence
of
boss
empire
section
hunter
that
needs
to
be
processed
by
how.
N
So
this
is
the
instax
extension
header
and
its
data
encoding
format.
So
here
we
see
the
main
part
is
the
the
stack
mpls
extension
header.
So
this
contains
the
bit
flag
which
the
ipa
flag,
which
I,
which
we
have
described
before,
to
indicate
the
presence
of
in
stack
empire,
section
generator,
and
apart
from
that,
we
have
the
instant
data
data
length.
This
indicates
the
instax
mpls
extension
length
in
the
order
of
four
bytes.
The
next
one
is
the
instax
mpls
extension
format.
N
This
contains
the
opcode,
so
instead
in
stack
forwarding
instruction
or
code,
this
is
of
8
bit
value
that
defines
the
forwarding
instruction
that
need
to
be
executed
when
it
receives
the
packet
and
next
one
is
in
instax
data.
So
this
is
the
ancillary
data
which
is
required
to
execute
the
forwarding
instruction.
N
So
we
use
the
two
bits
to
control
this
stack
data
processing.
So
one
is
the
d
bit
which
is
shown
in
the
diagram,
so
that
is
this.
Is
the
data
stacking
bit
in
the
case
of
in-stack?
Forwarding
instruction
requires
more
than
20
bits
of
answer
data.
Then
this
bit
is
used
to
extend,
extend
and
carry
more
more
bits
of
fractional
data.
If
this
is
built
to
set,
then
this
will
be
the
end
of
the
anchor
data
for
the
specific
forwarding
instruction.
N
N
So
we're
coming
to
the
in
stack,
forwarding
instruction
op
code
assignment
the
value
one.
We
have
reserved
it
to
carry
the
flag
based
forwarding
instruction.
In
some
cases
the
application
does
not
need
any
forwarding
forward.
It
does
not
need
any
accelerated
data,
so
in
those
cases
they
could
assign
a
bit
by
the
iona
and
they
could
use
the
subcode
and
then
carry
those
kind
of
informations
and
then
value.
N
This
is
the
bottom
of
the
stack
mpls
extension
header
encoding
format,
so
this
contains
the
boss,
mpls
extension
indicator,
so
this
contains
the
this.
Has
the
boss
extension
header
presence
indicator
field.
This
must
be
set
to
indicate
the
presence
of
the
boss
employer
section
header
after
the
bottom
of
the
stack
and
next
bit,
which
is
used
for
this
purpose,
is
the
hop
by
hop
boss,
extension
header
indicator.
N
Next,
one
is
the
boss
data
format.
Here
we
are
defining
a
generic
framework
so
that
carry
so
that
we
could
carry
multiple
forwarding
instruction
with
respect
to
the
boss
forwarding
instruction,
so
the
first
enable
is
a
fixed,
zero,
zero
one,
zero
enable
this
is
used
to
avoid
aliasing
with
any
existing
ipv4,
v6,
etc.
Packets
and
next
level
is
reserved,
and
next
update,
is
the
boss
forwarding
instruction
of
code,
so
this
value
will
be
assigned
by
inr,
based
on
the
application
request.
N
The
next
update
indicates
the
length
of
the
boss
accident
data
in
the
order
of
4
bytes.
This
boss,
accelerator
could
have
its
own
tlv
and
sub
tlps.
Next
update
is
used
for
boss,
mpls
extension
header
flags.
Currently,
two
flags
has
been
assigned
the
one
one.
The
one
flag
is
the
next
next
header
person's
flag.
This
indicates
the
presence
of
another
boss,
mpls
forwarding
extension,
header
and
next
flag-
is
the
hubba
hub
bit
flat.
So
we
can
encode,
multiple
boss,
state,
multiple
boss,
extension
forwarding,
so
we
can
by
by
this
flag.
N
N
So
this
is
an
example
of
the
instax
mpls
extension
header
carrying
the
flag
based
instructions,
as
we
described
before.
Opcode1
is
resolved
to
carry
this
kind
of
forwarding
instruction,
which
does
not
need
any
angular
data
to
process
the
forwarding
instruction
in
the
first.
In
the
first
word,
the
the
ipi
is
set
to
one
indicates:
the
presence
of
the
stack
ambiguous,
certain
presence
and
the
instruct
length
is
set
to
one
indicates
that
stack
extraction.
Header
length
is
of
one
word
in
the
second
word.
The
instruct
forwarding
instruction
of
code
is
set
to
value
one.
N
N
So
this
is
an
example
in
which
in
stack,
mpls
extension
carries
more
than
20
bits
of
data
in,
in
some
cases,
the
application
needs
to
carry
more
than
20
bits.
So
this
is
how
the
the
data
format
looks
like.
So
the
important
thing
here
is
that
the
third
word,
if
you
see
here
so
the
first
bit
of
the
msb,
should
be
set
to
one
to
prevent
the
angular
data
value
from
aliasing,
with
the
existing
spls
on
the
legacy.
Routers.
N
N
N
So
as
a
next
step,
we
would
welcome
review
comments
and
feedbacks
especially
feedback
on
the
mpls
extension
indicators
options.
Also,
we
would
request
a
mpls
working
group
adoption
before
I
complete.
Also,
I
want
to
mention
that
we
have
done
the
hardware
analysis
study
on
the
npr's
extension
headers
and
those
informations
are
provided
in
the
appendix
for
this
of
this
presentation.
People
can
take
a
look
whenever
they
want.
N
E
E
E
N
Okay,
so
it
is
for
each
instruction
the
bit
will
be
set
for
the
op.
Let's
take
an
example,
I
have
a
two
up
codes
up
code,
eight
and
upload
nine
right,
so
8
is
assigned
to
application,
one,
the.
If
that
opcode
8
needs
to
be
processed
by
hub,
then
the
e
bit
will
be
set
to
zero,
and
if
the
up
code
9
needs
to
be
processed
end
to
end,
then
actually
ebit
will
be
set
to
one.
N
So
the
the
full
header
will
be
repeated
for
every
instruction
right,
not
the
full
header
full
header
instance
like
the
the
op
code,
and
instead
data
will
be
repeated
for
multiple,
okay,
the
ipr
equal
to
one
and
the
il
will
not
be
repeated.
Only
the
opcode
and
the
instruct
data,
the
the
in
this
case
right.
You
see
that,
as
the
second
word
will
be
repeated.
J
N
Dropped,
yes,
so
greg.
Actually,
in
our
draft
section
number
10,
we
said
that
we
need
signaling
for
the
compatibility
for
the
earlier
routers
to
support
this
impedance
extension
header.
So
that
will
take
care
of.
You
know
like
make
sure
that
the
router
which
is
going
to
pop
is
aware
of
this.
Okay,
so.
N
N
We
think
it
will
be
helpful
if
you,
if
you
carry
entropy
if
you
reuse
the
entropy
label,
so
this
is
one
of
the
option
that
is
it
so,
and
other
options
is
the
spl
and
another
third
option
is
the
user
defined
label?
So
these
are
the
these
are
these
are
the
options
we
are
keeping
on
table
and
then
our
ietf
server
group
we
can
just
discuss
and
choose
which
one
to
go.
N
O
N
P
We
prefer
to
use
a
single
special
label,
and
this
also,
we
have
another
document
to
talking
about
the
format
of
the
post
stack
data,
how
to
encode
the
extension
headers.
I
think
this
you
know
this
also
published
three
years
ago
and
we
have
continued
to
update
it
until
now.
It's
a
version
six,
so
I
I
think
the
author
here
is
a
proposed
some
kind
of
new
encoding
method
and
should
to
at
least
to
mention
that
document
and
maybe
make
some
comparisons.
Why?
P
D
N
Q
Q
Yeah
to
solve
the
limitation
of
the
label
stack
steps
on
some
transient
nodes.
You
need
to
carry
another
special
special
purpose
label
or
the
entropy
label
indicator
which
can
be
read
by
the
transient
nodes.
In
that
case,
we
will
need
two
special
purpose.
Labels
in
the
label
stack
entry,
one
for
the
instant
data,
another
one
for
the
post
tech
data.
N
N
A
R
R
R
R
R
R
R
R
O
R
R
So,
if
you
want
to
to
indicate
an
extension,
you
do
so,
I
I
mean
sure
to
to
get
you
also
it's
mostly
independence
in
the
way
that
you
can
use
indicators
as
a
general
capability
to
indicate
whatever
you
want,
and
anyone
is
free
to
use
indicator
to
to
signal
something.
So
not
sure
if
this
answer
your
question.
O
O
S
R
B
Hi,
so
thanks
bruno
for
the
presentation
I
think
I
just
had.
One
comment
is
that
I
think
bruno
draft
is,
is
independent
and
it
can
progress
as
a
working
group
document,
while
the
jack
strap
is
more
about
the
asic
or
hardware
friendly
encoding
and
it
can
have
a
you
know,
resort
that
different
encore.
The
indicators
and
eli
bit
can
be
one
of
the
indicator
options.
So
it's
the
the
this
draft.
The
bruno
draft
is
is
independent
and
it
can
progress.
B
M
M
R
A
K
K
We
want
to
write
down
more
about
how
this
works,
in
the
presence
of
you
know
in
a
in
a
brownfield
network,
how
you
deal
with
backward
compatibility
and
so
on,
what
kind
of
extensibility
we
want
and
how
much
the
exact
bit
formats.
As
I
said,
you
know
we're
playing
with
that
still
ayana
allocation
details
and
deployment
strategies
next
slide.
Please.
K
K
K
So
we're
going
to
pose
a
number
of
questions
for
the
working
group
or
maybe
working
groups,
because
there
are
multiple
working
groups
involved,
we'll
pose
it
here.
Hopefully
we
get
some
sort
of
direction,
but
of
course
we
will
repeat
it
to
the
mailing
list
and
and
then
you
know
act
on
it
from
there.
K
K
K
K
I
just
want
this
to
be
ratified
by
the
working
group
so
that
we
can
put
that
particular
question
to
bed.
So
I
give
a
couple
of
reasons
here.
Why
in
stack
is
valuable
in
stack
data
reaching
the
bottom
of
stack
can
be
expensive
or
even
impossible
for
some
chips,
and
even
if
it's
possible,
it's
more
efficient
to
use
in-stack
data
for
stuff,
that's
critical
for
forwarding,
so
the
entropy
label
is
an
example.
K
K
K
K
Should
we
repeat
the
in
stack
data
in
the
post-stack
data
this
was
thrown
out
in
one
of
the
design
team
meetings.
I
don't
think
this
is
worth
it.
I
don't
like
repeating
stuff,
there's
always
the
chance
that
you
don't
you
know,
get
it
right.
You
don't
encode
it
correctly
and
then,
if
there's
a
conflict
which
one
do
you
take
but
again,
I
think
it
would
be
nice
to
get
feedback
from
the
working
group
and
then
you
know
settle
this
next.
K
We
think
that
this
approach
is
very
efficient
and
very
extensible.
An
action
is
essentially
encoded
in
a
single
bit
and
the
position
of
the
bit
the
bit
number
says
what
the
action
is
and
the
value
can
be
zero
or
one
zero
means,
don't
do
it.
There
is
no
associated
data
ever
and
one
means
do
it
to
whatever
the
action
is
and
whether
there's
associated
data
or
not,
and
how
big
it
is,
is
something
that
needs
to
be
put
in
the
iana
registry.
K
So,
typically
it's
either
zero
or
four
octets
of
associate
data.
The
number
of
flag
bits
is
extensible,
so
there's
an
extension
header
that
says,
use
another
label
stack
entry
for
more
flags.
So
again,
there's
been
questions
about.
How
do
we
encode
these
things?
I
think
we
need
the
working
group
to
step
in
and
say
yeah.
K
What
you
guys
are
doing
is
wonderful
because
of
course
it
is,
and
we
do
have
people
who
are
looking
at
this
from
a
hardware
implementation
point
of
view-
and
you
know
we
have
a
co-author
israel
from
from
broadcom,
and
we
have
internal
people
who
write
asics
and
microworld
and
stuff
and
they're
pretty
happy
with
it.
But
again,
we'd
like
the
working
group
or
working
groups
to
say
yes,
go
ahead
with
this
approach.
K
K
The
one
exception
to
this
flags,
being
one
bit,
is
there's
a
two
bit
flag
for
the
combination
of
entropy
label
and
yes
and
there's
a
summary
of
how
this
works
in
the
top
right
question.
I
guess
is
I
mean
what
this
gives.
You
is
a
much
much
more
flexibility
in
how
many
bits
you
have
for
entropy
and
how
many
you
have
for
slice
id,
but
is
this
too
clever-
and
this
is,
I
think,
a
question
for
people
who
want
to
implement
this.
K
K
K
And
I
guess
this
is
the
last
one:
can
the
special
purpose
label
reach
the
top
of
stack
until
now,
we've
been
saying
because
we're
reusing
the
tc
and
ttl
bits?
We
don't
want
it
to
reach
the
top
of
stack,
but
if
we
have
the
right
signaling
that
says
I
can
deal
with
it.
If
the
faa,
spl
or
whatever
you
want
to
call
it
reaches
the
proper
stack,
then
I
think
we
we
have
more
flexibility.
K
The
second
is
to
allow
this
to
happen,
and
you
know
if
you
pop
the
the
the
top
label,
which
is
the
forwarding
label
and
send
the
fai
label
to
the
next
lsr.
It
has
to
be
able
to
deal
with
it
or
the
third
is,
if
you
don't
like
that
happening,
push
a
neutral
label
on
top
of
stack,
so,
for
example,
label
zero.
K
K
So,
as
I
said,
we're
doing
some,
you
know
arm
wrestling
around
some
of
these
bits.
You
know,
continuation
bits
is
what
we
currently
have.
We
have
a
request
to
put
an
explicit
length.
It
makes
it
much
easier
to
know
exactly
how
much
to
pop
the
bid
positions
we
might
want
to
play
with
in
terms
of
put
all
the
things
that
have
no
associated
data
first
or
put
all
the
things
that
are
really
important,
first
or
stuff
like
that
again
semantically.
It
won't
change
anything
that
might
make
it
easy
for
the
hardware.
K
A
A
B
So
I
think
you
asked
for
working
of
adoption
for
this
draft
and
I
just
wanted
to
point
out
that
there
are
also
two
other
solution
drops
as
well,
and
they
are
also
asking
for
working
new
production
as
well.
So
I
I
think
just
to
highlight
there
are
multiple
drafts
requesting
the
same,
so
probably
need
some
more
discussion
on
that,
and
that's
all
thanks.
T
T
Well,
you
can
tell
me,
but
anyway
the
item
number
three.
You
had
a
set
of
bits
indicating
the
functionality,
and
that
seems
good
until
there's
some
ancillary
data
associated
with
those
bits,
and
I
understand
that
it
would
be
implementable
in
in
hardware,
but
what
the
hardware
has
to
do
then
is
is
go
from
a
bit
presence
to
some
data
that
may
appear
later
to
another
bit
being
present
some
data
that
may
appear
after
that
and
it
needs
to
bounce
around.
In
order
to
accomplish
that,
I
have
a
concern
with
that
encoding.
K
So,
as
I
said,
we
have
people
who
are
looking
at
this
from
an
implementation
point
of
view
and
there's
an
algorithm
in
in
the
document
about
how
to
process
this.
It
is
sequential
because
the
presence
of
an
earlier
bit
being
one
makes
you
know,
moves
the
data
around.
So
if
an
earlier
bit
has
associated
data,
let's
say:
there's
an
entropy
label.
That
means
the
first
label
stack
entry
following
this
would
have
the
entropy
label.
If
that
bit
happens
to
be
zero,
the
first
label
stack
entry
would
be
some
other
thing.
K
K
Okay
yeah,
so
we
a
bunch
of
us
got
together.
You
can
see
the
authors
here
to
write
essentially
an
iana
registry
for
the
first
nibble,
which
is
the
first
four
bits
that
follow
the
label
stack,
which
is
look
for
the
last
label,
the
one
with
the
bottom
of
stack
bit
set
and
then
the
first
nibble
after
that
next
slide.
K
So
the
reason
we
want
to
do
this
is
a
lot
of
people
were
thinking
that
the
first
nibble
would
be
similar
to
ip
version
number
and
we
can
use
zero
or
one,
but
we
can't
use
anything
else.
What
this
document
basically
says
is
we've
got
16
values,
we're
going
to
use
all
16,
except
we
are
not
going
to
use
four
and
six.
K
This
is
not
an
ipv
version
number
registry
and
the
reason
why
four
and
six
are
special
is
because
people
came
up
with
this
really
bad
hack,
that
if
it
is
four
or
six
it
might
be
an
ip
address,
it
turns
out
to
be
a
really
bad
hack.
So
this
also
says
here's
a
requirement
and
here's
a
recommendation
next
slide,
please.
K
K
The
recommendation
is,
if
you
want
to
do
load
balancing,
do
not
use
this
hack
that
you
know
if
the
first
nibble
is
four
or
six,
it
might
be
an
ipv4
packet.
It's
really
broken
now.
If
the
previous
recommendation
or
requirement
is
used,
this
shouldn't
be
needed,
but
there's
lots
of
implementations
out
there
that
do
this.
So
if
you
want
good
entropy,
if
you
want
good
load,
balancing
use,
an
entropy
label
use
a
faster
oil
label.
Don't
use
that
hack?
A
E
E
K
K
Yep
yep,
I
think
that's
49.28,
let's
see
so
I
would
say
that
the
right
way
to
do
that
would
be
to
put
a
postdoc
data.
That
says,
and
I'm
going
to
say
this-
please
don't
shoot
me.
This
is
a
protocol
type
for
the
packet
or
something
if
you
really
want
to
get
into
application,
aware
routing,
but
just
trying
to
guess
randomly
whether
the
packet
is
ip
or
not
based
on
one
nibble
is
not
a
good
idea.
K
A
O
H
I
think
it's
important
to
look
at
this
backward
compatibility
thing
I
I
was
trying
to
chime
in
when
jeff
asked
a
question.
Do
we
foresee
a
need
that
we
need
eight
of
these
things
at
the
same
time
when
forwarding
a
packet?
I
also
believe
that
that's
not
realistic
to
do
when
you
want
to
have
a
very
high
performance
routing
right.
H
So
we
have
to
basically
balance
the
solutions
against
how
easy
is
it
to
deploy
versus
the
amount
of
extensibility
it
gives,
and
I
think
this
is
a
very
important
aspect
we
have
to
consider,
because
we,
if
you
look
to
what
what
happened
with
ipv6
and
ipv4,
it's
incompatible
right
and
we
actually
still
struggle
daily
with
this
problem,
and
I
think
it's
a
very
important
aspect.
We
have
to
take
into
account
when
considering
the
solution
that
we
are
going
to
adopt
thanks.
K
Yes,
thank
you.
I
just
want
to
respond
to
vim
and
I
think
there
have
been
some
other
comments
along
these
lines
before
that.
Eight
is
plenty
and
that's
what
we
said
about
the
special
purpose
label.
So
16
is
plenty
we
defined.
I
think
at
the
time
3031
came
out.
We
defined
three
or
four
of
them
right
now
we
have
in
flight
five
or
six
requests
for
special
purpose
labels
before
we
started
this
work
on
the
fai
forwarding
actions
indicator.
K
K
K
A
Q
So
this
is
really
something
we
need
to
consider.
We
need
to
be
very
careful
about
any
changes
to
the
label
stack
and
I
think
how
you
mentioned
that
there
are
some
analysis
about
the
forwarding,
efficiency
and
the
performance.
I
think
this
is
also
useful.
If,
for
every
proposal,
we
can
have
some
hardware
analysis
analysis
provided
so
that
way
we
can
provide
it.
It
can
be
introduced
with
a
backward
compatibility
and
efficiency.
M
Very
close
to
beams
right,
I'm
looking
from
deployability
perspective.
Looking
at
my
network,
I'm
running
depending
where
you
look
three
to
four
generation
of
different
hardware,
software
is
practical.
It
takes
years
to
deploy
forget
about
hardware,
so
I
really
need
to
start
somewhere
where
I
can
deploy
on
today's
hardware
or
actually
yesterday's
hardware
plus
software
to
propagate
basic
stuff.
Like
again,
how
deep
can
I
go?
What's
readable,
with
all
the
staff
had
been
implemented
last
year
or
two
right,
even
in
open
source
software?
M
If
you
look
at
open
source
routing
stuff,
they
all
implemented
extensions
to
a
gps
and
bgpls
last
year.
So
in
order
to
make
it
deployable,
we
need
to
start
with
something
that
is
possibly
already
at
least
partially
supported.
Otherwise
we
are
talking
seven
eight
years
from
now
the
whole
upgrade
cycle
I
mean
we
are
atf,
we
are
doing
running
code
and
we
are
trying
to
do
something.
That's
implementable
right.
So
this
is
where
we
should
start.
T
Yep,
the
really
brief
comment
and
I'll
bring
it
up
on
the
list
as
well
is,
I
think,
with
the
kirti
with
your
draft.
I
think
we
have
a
problem
when
we
go
to
bottom
of
stack
data
and
additional
control.
Words
exist
after
the
bottom
of
stack,
I'm
interested
to
see
how
we
solve
that
problem,
so
I'll
bring
it
up
online
thanks.
I
So
I
agree
with
what
vim
mentioned
so
I'd
like
to
explore
her
comment.
I
think
bruno's
draft
provides
a
very
good
start
for
the
working
group
working.
We
should
start
it
for
this
world.
Eight
bit
support
is
it
provides
good
enough
for
for
the
initial
use
cases,
and
then
the
draft
also
does
not
require
any
extensions,
meaning
extension
is
that
backward
compatible.
I
So
it's
is,
in
my
opinion,
very
good
start.
The
other
point
is
that
before
working
group
adopt
any
solution,
there
has
to
be
more
discussion
on
the
framework
stuff
that
lua
and
team
started
some
other
consideration
within
the
working
group,
and
this
is
something
for
a
long
run
and
we
should
not
rush
into
a
one
particular
solution
at
the
moment.
We
need
a
little
bit
more
better
to
start
the
work
in
the
right
direction
for
the
long
term.
I
U
U
So
to
add
a
follow-up
on
how
it's
coming
down
about
the
in-stack
data,
so
allowing
instructed
does
not
mean
that
we
would
casually
put
anything
into
the
stack,
so
I
think
architecturally
we
should
allow
it
now
and
in
the
future,
when
any
proposal
comes
up
to
add
specific
data
into
the
instax
for
some
functionality.
At
that
time,
the
working
group
will
decide
whether
that's
a
good
idea
or
not,
for
that
particular
future.
R
R
F
F
G
I
believe
that
mpls
working
group
should
consider
adopting
draft
bruno
for
a
solution
that
for
things
that
can
be
tackled
with
it,
you
know
today
or
sooner
and
in
the
in
parallel.
The
design
team
can
continue
working
on
the
more
elaborate
framework
and
the
analysis,
but
I
think
it
would
not
be
good
to
get
that
proposal.
Adoption
on
for
the
draft
bruno
adoption.