►
From YouTube: IETF111-PALS-20210727-2300
Description
PALS meeting session at IETF111
2021/07/27 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
My
name
is
andy
mallis,
I'm
one
of
the
co-chairs
of
the
pals
working
group,
stuart
bryant,
is
also
a
co-chair
of
the
pals
working
group,
but
he
actually
will
be
taking
more
of
a
role
of
an
active
participant
in
today's
meeting
rather
than
in
a
chair
role,
and
because
of
that
tariq
saad
from
the
mpls
working
group
has
kindly
volunteered
to
help
me
chair
this
meeting
here
today.
Tariq
will
primarily
be
watching
the
the
queue
and
also
he'll
be
watching
the
chat,
room
and
and
he'll.
A
Let
me
know
if
there's
anything
in
either
of
those
that
need
paying
attention
to
that.
I
I've
been
neglecting
because
I'm
running
the
slides,
I'm
planning
on
running
all
the
slides
tonight
that
make
the
in
this
meeting.
That
makes
it
easier
rather
than
trying
to
have
everybody
share
their
own
screen,
and
so
when
people
are
speaking
I'll
just
be
be
happy
if
they
just
say
next
slide
when
they
want
me
to
move
to
the
next
slide,
and
with
that
I
will
do
exactly
that.
A
So
this
is
the
notewell
slide.
I'm
sure
you've
all
seen
this
many
times
already,
so
just
be
aware
that
that
you,
that
everything
that
we
talk
about
today
is
covered
by
the
nut
well
and
when
you
have
a
chance,
you
can
find
it
online
on
the
ietf
website
and
you
can
check
it
out
now
the
purpose
of
this
meeting.
As
we
I
said,
this
is
a
joint
meeting
for
pals,
mpls
and
detonate.
A
This
meeting
is
going
to
be
discussing
basic
architectural
issues
that
have
come
up
from
drafts
that
have
been
proposing
new
applications
for
mpls
and
the
label
stack
and
different
ways
to
use
the
bottom
of
the
mpls
label
stack
a
very
high
level
agenda
overview.
Is
that
we'll
be
concentrating
in
two
primary
areas?
The
first
is
an
update
from
the
mpls
open
design
team
calls
that
have
begun
following
the
previous
ietf
meeting,
and
then
we'll
have
technical
discussions
of
in-stack
indicators
and
metadata
encoding
options.
A
I
want
you
all
to
note
the
open
design
team
work
has
not
completed
the
weekly.
They
have
weekly
calls.
These
calls
are
open
to
everybody.
They
will
be
continuing
following
iatf
111.
They
are
announced
on
the
mpls
email
list.
So
if
you
are
very
interested
at
all
and
participating
with
these
calls
just
watch
the
mpls
working
groups,
email
list-
and
you
will
see
that
all
the
calls
are
announced
there,
along
with
information
on
on
how
to
join
the
calls.
A
This
is
today's
agenda.
We're
starting
out
with
my
intro
just
five
minutes,
then
stuart
will
be
giving
us
a
summary
and
status
of
how
the
mpls
open
design
team
has
been
working
since
it
started
following
the
previous
ietf
meeting,
then
we
will
have,
as
I
said
before,
two
primary
technical
areas
we'll
be
talking
about.
One
will
have
the
in
stack
indicators
with
karidi,
stuart
and
haiyu
song,
all
speaking,
and
then
we
will
have
metadata
and
coding
options
with
how
you
again
and
jeffrey
zhang.
A
We
have
35
minutes
reserved
just
for
discussion
of
the
draft.
So
what
I
would
like
to
ask
people
to
do
is
during
the
presentation
of
the
address.
If
you
have
a
question,
only
ask
it:
if
it's
a
question
for
clarification
of
a
point
on
the
slides,
that's
being
presented
and
then
following
the
presentation
of
all
the
slides,
we
will
go
into
the
detailed
technical
discussion
and
the
main
reason
we
want
to
do
that.
A
So,
as
I
said,
only
ask
questions
for
clarification
and
we
will
have
a
detailed
discussion,
35
minutes
or
so
following
the
presentation
of
all
the
slides,
and
then
we
will
close
with
stuart,
giving
a
five
minute
summary
of
everything
that
we've
talked
about
and
what
our
steps
will
be
going
forward,
and
this
is
our
online
resources.
I
would
like
to
point
out
that
most
everything
that
we're
doing
is
online.
A
I
would
like
to
thank
all
of
the
presenters
today
for
getting
all
their
slides
in
and
plenty
of
time
so
everything's
been
uploaded
to
the
meeting
materials
page.
So
if
you
want
to
download
any
of
the
slides,
they're
all
available,
they're
all
online
on
the
meeting
materials
page
for
itf
111,
you
can
find
the
agenda
at
the
url
you
see
on
the
slide.
It's
also
available,
of
course,
through
the
agenda
page,
we
are
taking
notes
using
etherpad
or
or
code
imd
they're,
both
exactly
the
same
thing.
That's
the
url
for
it
right
there.
A
You
can
also
get
the
url
from
the
agenda
page
as
well.
What
I
would
like
you
to
do
is
if
you
open
that
page
you'll
see
that
there
are
that
today's
agenda
has
been
already
copied
into
there
and
after
each
of
agenda
item
you'll
see
a
thing
that
says
star.
Star
notes:
go
here,
star
star,
that's
where
I'd
like
people
to
type.
A
So,
if
you
have
any
notes,
questions
comments
of
you
just
like
to
take
track
of,
what's
going
on
in
the
meeting
feel
free
to
type
it
in
right,
there
dave,
cena
crop
will
also
be
who
dave
sent
a
crop
by
the
way
I
should
have
introduced
him
earlier.
He's
our
working
group
secretary
and
he'll
be
taking
separate
offline
notes
and
then,
following
the
meeting
he's
going
to
merge
his
offline
notes
with
everything
that
was
typed
into
code
imd
as
well,
so
everything
will
be
recorded.
He'll
also
be
looking
at.
A
What's
typed
into
the
chat
window,
he
could
because
that's
just
stays
put
in
in
in
the
jabber
room
and
he
can
incorporate
anything
that
was
of
substance
that
comes
up
in
the
jabber
room
as
well,
so
that
will
all
appear
in
the
in
the
minutes
following
the
meeting.
If
you
have
any
technical
issues
at
all
meet
echo,
the
meeting
audio
send
an
email
to
support
ietf.org.
A
The
ietf
has
has
basically
taken
all
their
their
possible
things.
You
could
need
help
for
and
put
it
into
one
email
spot
support
ietf.org
and
we
also
have
a
live,
meet.
Echo
technician,
who's,
monitoring,
jabber
the
chat
window,
which
is
the
same
as
jabber
during
the
meeting.
So
if
any
technical
issues
pop
up
and
you
type
them
in
there-
they'll
be
seen
by
one
of
the
mean
echo
technicians
as
well-
and
that's
my
that's
my
closing
slide
here
now,
I'm
going
to
move
on
and
the
first
agenda
item
is
going
to
be
stuart.
A
B
B
Thank
you
right,
so
I
should
emphasize
that
this
report
is
being
presented
on
behalf
of
the
mpls
open
design
team
and
much
of
this
material
was
coordinated
in
the
meeting
we
had
last
thursday
next
slide.
Please
right
so
the
odt
has
met
15
times.
It
first
met
on
the
8th
of
april
2021
and,
as
andy
has
said,
this
meeting
is
open
to
anyone
who
wishes
to
to
participate
all
the
minutes.
B
Meeting
recordings
decisions
and
some
of
the
design
work
is
recorded
on
a
wiki
in
the
mpls
area
of
the
ietf
wiki
and
the
url
is,
is
on
the
screen
next
slide,
please
so
the
background.
So
the
mpls
working
group
received
the
number
of
technology
pro
proposals
for
in-stack
function,
indicators,
auxiliary
data
indicators,
auxiliary
data
structures
to
be
carried
below
the
bottom
of
stack.
I
I
tend
to
use
the
term
auxiliary
data.
I
think
it
is
better
than
than
metadata,
and
so
that's
what
I
tended
to
to
do.
B
So
a
summary
of
the
operations
of
of
mp,
the
operation
of
mpls
and
the
proposals
that
were
initially
received
were
put
together
by
myself
and
published
as
an
internet
draft.
There
are
a
couple
of
errors
in
that
draft
that
need
to
be
corrected
and
I've
got
zero
one
ready
to
to
go
shortly.
B
So
this
is
sort
of
a
background
to
get
everyone
up
to
speed
with
the
sort
of
design
philosophy
and
the
the
essential
specs
that
you
need
to
know
to
understand
how
the
mpls
data
plane
works
together
with
a
couple
of
lines
on
each
of
the
proposals.
B
How
to
satisfy
the
underlying
needs
in
a
way
that
enhances
the
capability
of
mpls
without
tying
our
hands
and
limiting
what
we
can
do
in
the
future.
The
mpls
and
pals
teams
formed
an
open
design,
team
and
invited
net.
I
think
we
invited
teas
as
well,
but
they
decide
they
decided
that
they
didn't
wish
to
actively
participate.
B
Pals
is
involved
because
it
was
the
first
working
group
to
carry
ancillary
data
below
the
bottom
of
stack.
It
did
this
for
two
reasons:
the
the
control
word
many
of
you
will
be
familiar
with,
and
also
the
the
oam
that's
associated
with
the
control
word.
So
we
were
the
first
people
to
do
this,
and
so
we've
got
quite
an
interest
in
a
long
term
sort
of
interest
in
the
subject.
Net,
of
course,
also
does
something
very
similar
in
terms
of
control.
Word
next
slide.
Please.
B
Right
so
the
we
we
identified,
the
following
work
items
that
needed
to
be
to
be
done:
first
off
to
look
at
and
examine
label
the
label
stack
proposals
that
were
presented
so
things
like
repurposing,
the
tc
and
the
ttl
fields
use
almost
the
entire
label
in
a.
B
Label,
that's
not
at
top
of
stack
as
a
data
field,
introduce
something
that
people
have
been
calling
forwarding
action
indicators.
So
this
is
ancillary
and
additional
instructions
compared
to
the
top
of
stack
label
and
one
of
the
proposals
is
to
reuse.
The
entropy
label
indicator
as
an
fai
and
then
after
the
bottom
of
stack.
We
have
data
to
be
to
be
carried
at
least
in
most
cases.
B
So
a
number
of
proposals
been
put
on
the
table,
an
mpls
extension
header,
I
think,
really
sort
of
very
similar
to
ipv6
genet
the
generic
delivery
function.
Iom
would
need
to
go
below
the
bottom
of
stack
and
then
we
have
some
questions.
Is
it
a
requirement
to
have
multiple
auxiliary
data
items
after
the
bottom
of
the
stack?
Is
it
one
packet
one
aad
or
is
it
multiple
ancillary
data
items?
B
Should
the
action
headers
be
end
to
end
persistent,
that
is
to
say,
should
we
record
all
the
actions
that
happened
on
a
packet
or
and
or
should
we
so
they're
there
at
the
at
arrival
or
or
is
it
okay
to
discard
them,
and
how
do
we
instruct
some
knows
to
take
actions
along
the
path,
but
not
others
next
slide,
please.
B
We
started
some
work
very
fledgling
work
on
understanding
the
use
cases
and
applications
for
this,
because
that's
a
really
good
way
to
drive
design
decisions
and
so
far
we've
identified
in-situ
oam
network
slicing
networking.
That
is
time
sensitive
or
time,
critical
that
that
may
need
some
additional
information
and
and
mpls
network
programming
is
for
candidate
use
cases
and
we're
interested
in
people's
opinions
on
those
and
also
whether
there
are
additional
use
cases
that
we
should
consider
next
night.
Please.
B
So
we
we've
come
to
a
number
of
agreements
in
the
design
team.
Of
course,
such
agreements
need
to
be
ratified
by
the
rest
of
the
the
the
working
group
and
we'd
like
to
have
some
discussions
in
this
session
about
some
of
this.
So
we
think
that
and
we,
the
the
the
agreements
are
documented
on
the
wiki
at
the
the
page
the
url
shown,
so
we
wanna,
we
think
it's
important
to
limit
the
number
of
new
assignments
of
base
special
purpose
labels
as
much
as
possible.
B
We've
got
about
half
left
and
when
they're
gone
they're
gone,
we
have
a
standardized
associated
channel.
This
comes
from
the
pseudo-wire
work
and
a
mechanism
for
indicating
it
the
so-called
gal
gash
system.
B
So
far,
that's
gal
gash,
I
didn't
say
the
ach
next
slide.
Please
new
mechanism
to
carry
metadata
needs
to
have
a
well-defined
method
of
handling
types
and
versions
that
are
not
understood
or
supported
by
a
receiving
router.
B
We
need
a
mechanism
to
indicate
the
presence
of
metadata
or
actions
on
an
mpls
packet.
We
therefore
need
an
instant
method
to
serve
this
purpose.
Any
instant
method
is
is
in
scope.
Theory
here
is
that
it's
expensive
to
go
and
have
a
look
at
the
bottom
of
a
deep
stack
and
so
we'd,
rather
not
do
it.
Unless
we
had,
we
know
there
is
something
of
interest
down
there.
B
B
B
B
The
final
statement
we
conclusion
we
came
to
is
that
the
coexistence
of
oam
mechanisms
and
auxiliary
data
encodings
needs
to
be
designed
in
the
new
mechanism,
that
is
to
say,
we
can't
design
a
really
cool
data
plane
and
forget
that
we
need
to
have
an
oam
there.
We
have
to
do
the
oam
as
a
day,
one
design
next
slide.
Please.
B
So
the
work
will
continue.
At
least
that's
that's
our
proposal.
We
will
discuss
some
of
the
issues
that
were
raised
here
and
some
more
issues
in
this
in
this
session.
B
We
need
input
from
the
working
groups
on
this
work
and
we
really
encourage
those
who
are
interested
in
this
to
to
participate
in
the
meetings
which
are
currently
at
or
the
four
o'clock
uk
on
a
on
a
thursday
at
the
moment.
So
any
questions
please.
C
Stay
with
week,
yeah
hi.
My
question
is
about
the
extended
headers
that
we're
thinking
of
carrying
in
the
ancillary
data.
Are
they
all
going
to
be
processed
in
the
fast
path,
fast
data
path,
or
we
think
maybe
it
will
be
punted
to
the
slow
path
for
further
processing
or
both.
B
Well,
I
think,
all
of
the
the
above
we
have
some
that
have
to
be
done
in
the
in
the
fast
path.
For
example,
no
fast
reroute
would
be
a
good
example
of
one
that
you
had
to
do
in
the
in
the
fast
path.
B
Clearly,
the
actions
that
happen
end
to
end
that
will
deter
that
will
depend
on
whether
they
are
a
function
that
has
to
be
addressed
as
this
packet
goes
out
or
whether
they
are
something
that
can
be
addressed
in
parallel
with
the
dispatch
of
the
the
packet
that's
carrying
it.
For
example,
if
we
wanted
to
indicate
some
oam
action,
then,
like
record
some
of
our
am
action,
we
could
imagine
doing
that
in
parallel
and
punting
the
packet
to
the
to
the
slow
path.
E
E
E
Presenting
that
work,
but
but
you
know
I-
I
think
it
would
be
useful
to
align
these
two.
B
G
H
Okay,
so
one
one
piece
of
information
to
what
stewart
said:
it
was
not
the
peace
working
group
that
was
invited
from
the
beginning.
It
was
the
the
spring
working
group,
it
might
have
been
a
mistake
not
to
invite
peace,
but
it
was
a
spring
working
group
and
they
decided
to
stand
off
a
bit
yeah.
I.
H
Many
participants
from
spring
are
actually
taking
part
in
in
the
design
team.
H
F
Yeah,
so
I
was
also
in
six
men
there.
So
roughly
agree
with
what
kiriti
was
saying.
I
think
the
important
part
is
to
figure
out
all
the
different
relevant
cases,
for
you
know
slow
path,
or
this
fast
pass,
and
I
think
the
most
important
one
is
that
we
need
to
be
able
to
say.
F
Ignoring
of
all
the
things
must
be
possible
in
fast
path
right.
You
don't
want
to
have
notes
that
don't
even
need
and
support
that
stuff
and
then
because
it's
in
the
packet,
it's
being
punted
yeah.
We
do
know
that
we
can
try
to
avoid
the
problem
with
the
control
plane
to
a
large
extent,
but
that
may
require
a
lot
more
complexity
than
we
want
to.
That
was
the
main
comment.
Sn6
man.
A
Okay,
very
good
and
let's
go
on
to
the
next
presentation
and
karidi
is
going
to
be
our
next
presenter
and
if
you
wait
one
second
karini,
I
will
change
the
slides
here.
We
are
it's
unmute
right
and
I
can
hear
you
and
okay.
I
will.
I
will
change
the
slide,
so
just
say
next
slide.
E
So
this
draft
started
by
you
know:
we
wanted
to
open
the
discussion
into
the
use
of
the
tctl
fields
to
increase
expressiveness
of
a
base,
special
purpose
label
and
potentially
it
could
be
used
for
extended
special
purpose
labels
as
well
the
the
right
now
when
we
have
a
special
purpose
label.
We
only
use
the
20
bit
field
in
the
special
purpose
label
and
if
we
have
auxiliary
data,
that's
only
again
20
20
bits
and
it's
like.
Okay,
we're
we're
wasting
a
third
of
our
label,
the
entire
label
field.
So
let's
actually
use
it.
E
E
So,
instead
of
hard-coding,
what
the
value
is,
we
said
you
know
this
could
be
determined
by
a
policy.
It
could
be
something
like
a
firewall
policy.
It
could
be
other
ways
of
distributing
this
information,
but
then,
if
everyone
agrees
that
the
first
seven
bits
of
a
special
purpose
label
or
the
label
following
a
special
purpose-
labeled
has
this
meaning,
then
that
could
be
determined
by
configuration
rather
than
by
standardization.
E
E
Now
the
the
thing
to
remember
is
when
mpls
was
defined
20
odd
years
ago.
We
really
didn't.
You
know
the
forwarding
engines
were
much
more
limited,
even
the
amount
of
space
that
they
had
to
work
with
was
much
more
limited.
So
the
goal
was
to
do
this
efficiently
in
today's
forwarding
pipelines.
Next
slide,
please.
E
So
essentially,
what
a
base
or
a
special
purpose
label
base
or
otherwise
does
is
indicate
forwarding
actions
and
sometimes
associated
data.
So
the
forwarding
actions
you
have
you
know
router
alert
or
there
are
no
further
fast
rear,
which
is
still
a
draft,
but
they
basically
say
take
the
following
action
in
the
forwarding
path
and
the
associated
data,
which
is
sometimes
in
the
label
stack
like
in
the
entropy
label,
indicator
or
flow
id
or
the
slice
indicator,
or
sometimes
it
is
after
the
label
stack.
E
E
We
have
a
lot
more
ideas
now
we
have
actually
six
in
the
pipeline
and
we
have
eight
labels
left,
so
we
just
burn
all
of
them
this
way.
So
the
the
forwarding
actions
indicator
basically
says.
I'm
just
going
to
say
that
I
have
a
bunch
of
forwarding
actions
and
then
I'll
set
the
flags
to
tell
you
which
actions
you
should
actually
be
taking
and
also
which
associated
data
you
have
so
a
single
forwarding
actions
indicator
can
actually
do
multiple
things.
E
So
the
idea
was
to
solve
all
these
problems,
as
well
as
the
problem
defined
in
the
next
slide,
which
is
next
slide.
Please,
which
is
the
scarcity
which
you
know
stuart
talked
about,
and
you
know
it's
it's
a
real
issue.
So
eight
of
the
16
base
special
purpose
labels
have
been
allocated.
E
There
is
a
way
to
to
have
extended
special
purpose
labels,
but
then
you
burn
two
labels
for
every
one
of
those,
and
you
know
that
that
ends
up
using
a
lot
of
label
space
from
a
forwarding
path.
Point
of
view:
it's
not
ideal.
There
are
requests
for
six
base
special
purpose
labels
of
the
eight
remaining.
E
So
the
the
fai
proposal
allows
a
single
base,
special
purpose
label
to
capture
10
actions
and
I
say
10
because
you
have
11
bits
from
the
tctl
fields
and
if
you
use
one
for
extension,
because
people
have
already
said:
oh
just
only
10
actions
per
label
is
not
enough,
which
fair
enough.
You
can
then
say
I
will
use
one
of
the
bits
to
say
the
next
label
or
the
next
four
octet
field
has
another
31
actions
of
which
again
one
could
be
an
extended,
an
extension
field.
So
you
have
30
actions.
E
If
you
go
down
that
path,
then
you
know.
Yes,
you
have
to
burn
a
few
more
label
fields,
but
you
get
a
hell
of
a
lot
of
actions
encoded
and
maybe
we
don't
talk
about
scarcity
anymore
and
we
may
never
have
to
use
extended
special
purpose
labels.
Now
I
know
that
they've
been
already
too
allocated,
but
essentially
this
would
really
solve
the
problem
next
slide.
Please.
E
So,
as
stewart
alluded
to,
there
were
two
tracks
in
the
design
team
and
we
didn't
quite
stick
to
that,
but
we
more
or
less
did.
One
is:
what
do
we
do
within
the
label
stack
and
the
other
was
what
we
do
after
the
end
of
stack.
So
you
could
call
that
payload,
which
is
not
really
the
payload
from
the
customer
point
of
view,
but
it
is
what
comes
after
the
label
stack.
E
So
we
call
that
ls,
fad
and
pl
fad
associated
data
in
in
the
draft,
and
if
the
payload
data
is
self-describing,
then
you
know,
maybe
you
don't
need
to
actually
go
into.
You
know
having
a
different
indicator
for
each.
You
could
just
say
there
is
data
after
the
end
of
stack
and
then
you
go
find
it
and
then
parse
it.
There
are,
of
course,
other
approaches
next
slide,
please.
E
So
the
zero
zero
version
had
an
opaque
data
field
which
was
about
the
semantics
of
the
data,
was
determined
by
policy
but
wasn't
elaborated
in
the
draft.
This
topic
came
up,
so
you
know
we
put
it
back
in
the
01
version.
There
was
also
an
fa
header
for
expansion
of
the
flags,
but
it
was
not
elaborated
since
both
these
issues
were
raised
in
the
design
team
discussions.
E
So
in
the
oven
version
we
elaborate
on
the
use
of
the
fa
header
for
expansion.
So
there's
a
single
bit
that
says
the
next
four
octet
field
has
31
more
bits.
Presumably
one
of
them
will
be
used
for
further
extension,
but
you
know
so
you
get
either
30
or
31
more
actions
that
you
could
do.
E
Also,
after
a
discussion
with
how
you
I
I
started
describing
when
you
should
put
data
in
the
label
stack
itself
versus
in
the
payload,
so,
for
example,
the
eli
of
course.
At
that
time
we
didn't
think
a
lot
about
this.
We
said
we
want
the
entropy
label
right
there,
so
we
can
make
a
forwarding
decision
on
ecmp
right
when
you
see
it,
but
then
there
are
other
things
that
may
be
similar.
E
For
example,
a
slice
indicator
is
something
you
want
to
have
right
there
so
that
you
put
the
path
and
put
the
packet
on
the
right
path.
So
so,
but
of
course
not
everything
wants
to
be
there.
So
a
good
example
of
that
is
a
flow
id
which
currently
there's
a
draft
by
someone
else
who
says
I
want
a
flow
id
in
the
packet,
but
it's
more
for
om
purposes.
So
I
think
there's
a
valid
discussion.
E
There
are
only
four
bits
so,
depending
on
whether
you
count
in
four
octet
or
eight
octet
chunks,
you
can
try
to
get
to
the
end
of
stack
faster,
but
you're
not
guaranteed
to
get
to
the
end
of
stack,
so
you
actually
get
to
a
label.
And
then
you
follow
the
end
of
stack
bits
until
you
find
one
which
is
zero
and
then
the
next
word
is
the
end
of
stack.
E
So
this
is
a
little
bit
different
from
what
was
proposed
in
stewart's
document,
but
has
some
of
the
same
flavor.
Also,
the
o1
version
updates,
processing
of
the
ls
fad
and
the
examples
next
slide.
E
So
there
are
many
discussion
points.
One
is
that
the
fai
must
be
processed
efficiently
in
the
data
path,
so
a
tl
structure,
for
example,
would
be
very
flexible,
but
it's
not
very
efficient
in
terms
of
space
and
processing,
so
we
use
flags
instead,
there
might
may
be
other
approaches.
E
E
E
The
rationale
of
when
to
put
data
in
the
label
stack
versus
in
the
payload,
and
you
have
to
reach
it.
Even
if
you
can
reach
it
efficiently,
it's
still
a
little
further
away
and
there's
always
the
issue
of
how
much
of
the
of
the
header
of
the
packet.
Do
you
read
into
your
forwarding
engine,
so
you
can
process
it.
E
So
this
is
a
lot
of
this
depends
on
the
forwarding
engines
you
use
and
what
what
is
considered
efficient
in
the
data
plane.
So
I
think
this
rationale
should
be
spelt
out
some
more,
and
this
is
another
thing
that
might
be
in
common
with
what
the
six-man
work
on
hop-by-hop
headers.
E
E
E
How
do
you
change
a
configuration
across
the
network
in
a
meaningful
way?
You
know,
but
but
the
idea
is
a
very
attractive
one,
so
I
think
it's
worth
debating
it
again
and
maybe
solving
some
of
these
problems,
so
the
issues
are
listed
next
and
then
the
the
other
thing
is
that
it's
not
mutually
exclusive.
To
have
standard
actions
that
you
know
the
fai
contains
the
entropy
label
and
the
gist
label,
and
by
the
way
it
also
contains
more
data
which
is
determined
by
policy.
E
You
can
have
both
so
they're,
not
mutually
exclusive.
Another
thing
I
should
say
is
the
idea
of
indicators
in
the
fai
and
pointers
are
also
not
mutually
exclusive.
I
you
know
offline.
I
was
thinking
of
ways
where
we
can
put
the
two
ideas
together
it
it
isn't
in
the
draft
right
now,
nor
has
it
been
discussed,
but
at
the
next
mpls
design
team
we
might
bring
up
this
subject
next
slide.
I
think
that
might
be
the
last
slide.
A
So
and
we
we
have
one
question
from
from
tourism
and
I
would
would
like
to
end
the
queue
just
with
toilets,
because
we
are
a
bit
behind
time
now
so
tallest,
yes,.
F
Right
so
in
six
men
there
was
also
one
draft
they
discussed,
which
was
kind
of
a
generic
next
generation.
Router
alert
also
programmable
right.
So
maybe
the
discussion
point
two
about
you
know.
The
programmability
of
the
semantic
of
of
these
things,
together
with
the
equivalent
idea
from
from
six
men,
is
something
to
be
brought
up
in
lsr
or
routing
working
group.
To
ask
for
you
know:
do
you
folks
feel
we
can
have
an
appropriately
strong?
E
Sure,
and
and
and
there
was
a
vigorous
debate
on
forwarding
sorry
on
router
alert,
but
we
should
definitely
have
that
thanks.
I'm
done.
B
Right
so
next
slide,
please.
B
So
what
I'm
we're
talking
about
here
is
a
specific
solution
for
using
pointers
and
showing
how
they
add
value
to
the
design
of
packets.
B
Pointers,
allow
specific,
rather
than
implicit
data
or
or
actions
to
be
located,
and
they
allow
an
association
of
direction
as
to
what
data
carried
in
the
packet
you
want
to
use
in
processing
a
heart.
There
is
a
draft
that's
being
presented
in
rgbwtwg.
B
That
gives
you
a
much
more
complete
idea
of
where
this
could
go
and
and
describes
quite
a
powerful
sort
of
language
if
you
like
for
packet
design.
So
as
an
advert
for
that
next
slide,
please.
B
So
certain
use
cases
benefit
from
auxiliary
data
being
part
of
the
forwarding
decision.
So
what
we
need
to
do
is
to
figure
out
what
figure
out
a
way
of
doing
this.
That's
suitable
for
high
speed,
forwarding
works
with
existing
hardware
and
his
back
was
compatible
in
terms
of
forwarding
with
legacy
hardware.
Next
slide,
please.
B
So
the
approaches
so
far
that
have
been
looked
at
are
rely
on
the
forward
finding
out
if
there
is
any
applicable
auxiliary
data
below
the
bottom
stack
and
deducing,
which
of
that
is
hazardous
data
needs
to
be
applied
at
this
hop,
and
we
already
do
this.
B
For
example,
when
we
sneak
a
look
at
the
transport
fields,
for
example,
for
load
balancing,
some
methods
makes
it
easier
to
use
if
these,
if
there
is
data,
but
not
where
the
data
is
none
of
the
proposed
methods
and
really
deal
well
with
the
case
of
auxiliary
data
that
is
different
at
different
hops.
B
So
the
approach
that
we're
describing
here
builds
on
the
the
draft
that
kiriti
proposed
at
the
last
ietf
meeting
and
but
instead
of
using
the
toss
and
ttl
bits
as
a
as
pointers
and
stuff
as
regular
indicators
we're
going
to
use
them
as
as
pointers
next
slide.
Please
I'm
going
to
propose
using
that.
So
the
core
idea
is
to
use
some
spare
bits,
in
inverted
commas,
in
the
non-top
of
stack
field
as
a
pointer
to
the
specific
ancillary
data
that
is
to
be
used
at
this
hop.
B
So
the
semantic
is
forward
according
to
the
top
label
l1
using
the
assistance
of
the
information
pointed
at
by
the
pointer
label
l2,
so
it
forwards,
it
was
normally
when
l2
is
not
a
pointer,
so
you
you're
not
requiring
that
a
pointer
follows
the
top
of
stack.
So
it's
a
normal
mpls
label
stack
most
of
the
time,
but
if
we
wish
to
insert
a
pointer,
we
can
do
so
and
that
pointer
directs
us
to
specific
content
of
interest
next
slide
please.
B
Indeed,
we
know
whether
we
want
to
look
at
the
bottom
of
stack,
and
we
know
specifically
where
it
has
the
ability
to
specify
which
ancillary
data
is
is
applicable
to
a
particular
forwarding
label.
It
simplifies
the
packet
password
is
there
are
no
deductions
or
discretion
needed
in
how
it's
going
to
operate,
and
it's
inherently
general
and
extensible
next
slide,
please.
B
So
our
assumption
to
start
with
is
that
this,
the
pointer
will
be
a
special
purpose
label
of
some
sort,
but
we
could
make
the
top
of
stack
indicator.
We
could
make
the
top
of
stack
pointer,
but
that
means
we
need
to
change
the
fact
of
the
top
of
stack
label.
In
other
words,
to
say
we
we
could
change
the
fact,
which
is
what
we
did
with
the
the
rfc
that
records
the
time
spent
at
a
node.
But
that's
not
really.
B
B
We
label
one
needs
a
point
at
l1
l2
label
two
which
will
later
on
become
the
the
top
of
stack,
needs
the
pointer
at
l4,
and
they
both
point
to
the
same
auxiliary
data.
So
you
can
see
the
the
the
stack
when
we
start
on
the
stack
when
we
pop
l1
and
l2
as
a
as
a
pair,
and
it's
not
particularly
efficient
next
slide.
Please.
B
In
order
to
to
do
any
of
this
ancillary
data
inclusion
in
the
folding
decision,
when
you
move
the
pointer
of
course,
you're
gonna
have
to
do
a
correction,
but
that's
only
subtract
four
bytes
from
the
the
pointer
there
are.
There
is,
of
course,
a
problem,
which
is:
how
do
we
know
when
to
stop
propagating
the
pointer?
Do
we
do
this
with
some
sort
of
ttl
in
the
pointer?
Do
we
do
this
with
a
bit
in
label
three
that
says
whether
propagate
or
not?
B
Do
we
do
it
with
the
effect
of
a
label?
Three,
I
guess
I'd
rather
not,
or
do
we
point
to
a
piece
of
auxiliary
data
which
says
what
we
are
when
we're
to
to
pop
the
spl
next
slide.
Please.
B
B
And,
of
course,
you'll
notice
that
we
can
do
this
in
groups,
so
pointer,
one
is
only
used
once,
but
pointer.
Two
is
is
used
twice
because
there
are
case
occasions
where
multiple
hops
need
to
point
to
the
same
piece
of
ancillary
data.
To
do
their
job.
Latency
based
forwarding
is
a
is
a
good
example
of
that
next
slide.
Please.
B
Now,
when
we
presented
this
in
the
design
team,
the
first
one
of
the
issues
that
came
up
was:
what
do
you
do
about
ancillary
data
that
needs
to
grow?
B
An
example
of
this
is
one
of
the
classes
of
iom,
so
our
thought
is
that
you're
going
to
have
to
always
shift
the
stack
up
and
put
the
the
the
the
increased
data
in
with
any
sort
of
growing
ancillary
data.
B
But
what
we
can
do
is
we
can
take
some
some
learnings
from
the
way
that
disk
operating
systems,
work
and
I'll
put
the
expansion
space
insert
that
into
the
the
label,
the
ancillary
data
block
after
the
existing
ancillary
data
and
have
a
pointer
from
the
block
that's
expanded
to
the
expansion
to
the
expansion
block.
We
can
do
this
as
many
times
as
we
need,
so
we
can
learn
from
the
way
that
disks
operate
and
expand
ancillary
data
if
that
is
needed
for
certain
types
of,
but
usually
oam,
operation.
B
Next
slide,
please
something
that's
important
to
understand
with
all
of
these
techniques
is
the
need
to
describe
the
disposition
of
the
ancillary
data,
so
once
the
ancillary
data
once
the
packet
has
got
to
the
edge
of
the
network,
we
need
to
remove
the
ancillary
data,
and
this
can
be
a
lot
more
complicated
than
just
simply
dispose
of
end
bytes,
and
there
are
a
number
of
techniques
that
we've
explored
for
for
for
for
finding
the
the
disposition
data,
we
can
follow
the
same
technique
as
we
do
in
pseudowar,
which
kind
of
says
you
know
what
follows
the
bottom
of
the
stack.
B
We
can
have
an
spl
at
the
bottom
of
the
stack
a
bit
like
a
gal
to
say
what
to
do,
but
the
most
powerful
thing
to
do
is
to
make
the
bottom
of
stack
lse
point
to
auxiliary
data
that
describes
the
disposition.
This
is
much
more
powerful
than
any
of
the
implicit
methods
that
we've
used
in
the
past
next
slide.
Please.
B
This
is
just
a
a
trivial
sort
of
concept
of
how
it
would
work
and,
if
you've
studied
the
work
that
kariti
has
proposed,
you
would
understand
this
next
slide.
Please
so
this
is
a
a
short
note
that
spls
are
in
short
supplies
is
a
heretical
note.
Really,
I
suppose,
espl's
take
twice
the
sax
base.
B
I
was
wondering
whether
we
couldn't
use
a
regular
label
as
a
pointer,
so
I'm
not
talking
about
global
labels
in
the
way
that
the
mpls
segment
routing
people
were
I'm
talking
about
needing
a
small
number
of
labels,
which
we
agree
to
use
network
wide
for
this.
So
we
take
some
labels
out
of
the
regular
global
pool
and
we
assign
them
to
this
purpose.
B
They
don't
need
to
be
a
common
label
block
in
the
sense
that
sr
needed
it,
because
it
doesn't
matter
whether
the
they
can
appear
in
the
fib
or
not.
If
they
can
appear
in
the
fib,
then
you
just
need
to
pre-allocate
them.
If
they
can't
appear
in
the
fib,
then
these
are
special
labels
that
are
handled
by
the
forwarder,
and
so
the
forwarder
would
handle
them
in
its
own
way.
According
to
this,
this
forwarding
semantic.
B
E
Good
thanks
for
the
presentation,
so
a
couple
of
questions
one
is
effectively
and
and
you've
kind
of
said.
This
you're
burning
a
special
purpose
label
if
you
use
special
purpose
labels
for
a
particular
type
of
auxiliary
data
or
ancillary
data
that
you
point
to
so
that
label
basically
says
if
you
follow
the
pointer.
The
data
that
you
get
has
this
semantic
and
I
think
the
the
value
of
you
know
trying
to
get
multiple
uses
out
of
a
special
purpose
label.
E
So
I
think
that
there's
a
way
to
combine
the
use
of
you
know
use
the
tctl
bits
to
indicate
what
the
actions
are
to
indicate
essentially
the
semantics
of
these
pointers,
and
then,
actually,
you
know,
follow
the
pointers
to
get
to
the
data
that
you
need
to
get
to.
So
that's
that's
one.
D
B
Design,
what
I'm
quite
intrigued
with
is
that
you
can
do
some
very
powerful
constructs
if
you
point
to
things
rather
than
imply
that
they're
there
that
they're
somewhere.
E
Well,
yeah,
so
that's
the
other
part
of
what
I
was
going
to
say
is
there
is
this
section
that
I
put
in
the
01
version
of
my
draft,
which
is
when
do
you
put
data
right
there,
where
you
need
it
and
when
you
put
data
that
you
point
to
you
know
which
you
can
point
to
at
the
end
of
stack
or
beyond
the
end
of
stack,
and
I
think
that's
another
discussion
that
is
worth
having
from
the
point
of
view
of
you
know
when
we
did
the
entropy
label,
I
mean
when
we
did
gal.
E
We
said:
okay,
we're
going.
I
mean
we
didn't
have
a
pointer,
but
you
just
look
for
the
end
of
stack
and
then
beyond
that
you're
going
to
have
this
associated
channel
and
then
go
do
your
stuff
there,
but
with
the
entropy
level
is
that
we
have
to
have
that
right
there.
So,
at
the
point,
that
forward
is
trying
to
make
a
decision
it's
there.
So
I
think
there
are
some
things
that
you
want
in
the
label
stack.
You
want
at
your
fingertips,
so
to
speak.
It's
almost
like.
E
If
you
continue
your
discussion
or
analogy
of
the
disk,
it's
like
that
cache
that
you
have
that's
right
there
and
then
you
point
to
the
disk
and
then
that's
where
the
longer
term
storage
is
so.
You
know,
I
think
that
that's
another
thing
that
needs
to
be
fleshed
out
some
more
and
then
the
last
thing
I
would
say
is
that
label
stacks
are
getting
very
big,
so
I
think
we
have
to
talk
to
a
few
people.
E
That's
why
we
had
someone
from
broadcom,
israel,
who
was
a
co-author,
because
we
wanted
to
discuss
what
would
it
mean
for
a
forwarding
engine
like
what
broadcom
bills?
You
know
we
have
our
own
asic
team,
so
we
we
can
tell
you
that,
but
you
know
we
want
to
get
sort
of
a
wider
experience
of
what
asics
can
do.
What
is
easy,
what
is
hard
and
that's
why
I
say:
there's
some
overlap
with
six
man
trying
to
define
what's
the
right
way
of
processing
this
stuff,
and
you
know
how
much
of
it
you
process
but
yeah.
E
I
think
there's
some
there's
definitely
good
things
on
both
sides
and
we
should
continue
this.
This
discussion.
E
C
Yeah
hi,
quick
question
normally
extended,
headers
are
processed.
Sequentially
are
the
way
you
describe
them.
Stewart
as
if
we
are
processing
one
extended
header
in
singleton.
Do
we
need
to
dis
design
it?
You
know
in
our
encoding
such
that
you
know
we
don't
process
the
headers
sequentially.
Is
that
what
you're
thinking.
B
Yes,
I
mean
you
see,
there
are
some
cases
and
the
the
the
other
draft
I
pointed
to
really
does
go
down
into
exploring
some
of
these
cases
in
a
lot
more
depth,
but
it's
not
an
mpls
design.
There
are
some
cases
where
you
want
to
skip
over
a
piece
of
data
to
to
process.
There
are
some
cases
where
you
want
to
share
a
specific
piece
of
data,
but
only
on
some
hops.
B
A
A
I
Yes,
thanks
andy
just
266
same
time,
I
just
combined
the
you
know
two
slots
to
present
this
nps
extension
header
there.
It's
actually
include
the
four
cohesive
related
drafts.
Next
slides,
please
yeah.
First,
like
I'd
like
to
send
our
clauses
on
robin
tianyan,
aloha,
jeffrey
jim
stewart
and
some
contributors,
kiriti
bruno
and
andy.
I
I
also
would
also
like
to
thank
all
the
chairs
and
attendees
in
the
mps
open,
dt
weekly
meeting.
There
are
a
lot
of
fruitful
discussions
to
help
us
to
improve
the
drops
and
in
the
following
slides
you
will
notice
some
texts
are
labeled
in
red
color.
Those
reflects
newly
updates
to
those
jobs.
Next
slides,
please
yeah.
First,
let
me
recap
some
motivation
for
this
work,
so
we
observe
there's
a
some
new
services.
I
Overuser
package
emerge,
for
example,
on
the
nc2oam
network,
slicing
service
function,
chaining,
beer
segment,
routing
and
network
security
and
network
telemetry.
All
of
these
need
to
add
some
special
metadata
or
instruction
to
the
packet
header,
and
when
you
sync
them
in
the
piecemeal
method
you
some
of
them
will
claim.
Okay,
we
can
stack
this
data
just
between
the
label
stack
and
the
original
payload,
but
soon
we
will
find
in
many
cases
we
might
want
to
support
multiple
such
applications
in
one
packet.
I
I
Also,
we
want
to
make
this
really
flexible
on
the
label
switch
paths
any
node.
I
is
able
to
add
process
and
remove
some
instruction,
header
or
metadata.
So
in
this
very
flexible
configuration
you
know
we
have
to
have
some
mechanism
to
to
support
that.
I
So
that's
why
we
we
think
about
how
we
can
do
this
efficiently
in
mps
become
up
with
the
idea
of
a
extension
header
next
slides,
please.
I
I
I
So
for
us
we
need
to
meet
multiple
requirements.
The
first
one
is
the
flexibility
in
this
figure
you
can
see,
we
have
a
single
label
switch
path.
There
are
some
nodes,
are
extension
header
capable
like
a
d,
f
and
g
and
some
other
nodes
are
extension
header
incapable
and
we
can
build
multiple
extension
header
parts
on
this
label
switch
paths
we
can
start
and
end
at
any
node.
Of
course,
those
no
start
starting
point
and
ending
point
must
be
extension,
header
capable.
I
So
this
kind
of
flexibility
need
to
be
supported
and
also
extensibility.
Right
now
we
have
seen
already
seen
several
use
cases,
but
eventually
we
can
expect
there
will
be
more
use,
cases
emerge
and,
third,
we
need
to
care
about
the
performance,
because
this
is
in
for
the
in
impos
on
pass
processing.
So
it's
a
very
important
and
to
guarantee
all
the
user
packets
can
be
efficiently
forwarded
and
the
last
the
backward
compatibility
is
also.
D
I
I
The
second
set
of
solutions
is
just
to
extend
the
generic
ach
mechanics.
Let's
use
the
gill
to
indicate
some
extension
header,
and
maybe
we
have
some
special
encoding
to
put
the
extent
header
in
the
sh,
and
the
third
kind
of
solution
is
to
overload
the
new
semantics
to
the
some
existing
special
purpose
labels.
For
example.
We
can
put
it
in
to
the
extension.
No
entropy
label
indicator
the
last
solution.
Possible
solution
is
you
know,
without
using
any
special
purpose
label.
I
We
have
a
decided
to
know
to
go
to
the
gale
and
gsh
pass
for
us.
The
special
use,
a
single
special
purpose
label,
is
preferred,
and
also
there
are
proposals
have
been
made
like
the
fai
to
overload
the
as
the
indicator
with
some
other
forwarding
functions.
I
Yeah,
so
so,
in
this
slide
we
show
some
a
proposal
to
how
to
encode
this
extension.
Header
indicator
a
special
purpose
label,
so
the
first
part,
the
label
part,
is
just
a.
I
just
need
to
claim
a
new
special
purpose
label
number
and
the
cost
field.
We
are
redefined
to
them
to
be
the
sum
flag
view.
For
example,
we
can
define
the
first
beat
as
a
h
flag.
Each
flag
simply
means
there
are
there.
I
There
are
hbh
extension
headers
in
the
payload,
so
it
can
be
used
to
help
the
some
non-uh
and
ehp
animals
to
avoid
unnecessary
extension,
header
checking,
because
if
these
they
see
they
are
internal
nodes,
they
just
stop
searching
anymore
and
also
the
eh
off
size
can
be
used
to
provide
to
provide
the
offset
of
the
the
for
the
you
know,
the
the
header
of
the
extension,
the
first
word
of
the
extension
header
part.
I
So
this
is
only
useful
if
the
extension
header
is
not
at
the
bottom
of
stack
and
also
we
could
use
fewer
bits
as
offset
to
save
some
other
bits
to
save
zombies
for
some
other
functions.
I
Okay,
then
below
the
bottom
stack
will
be
the
npr's
extension
header
part,
so
the
the
the
extended
header
will
start
with
a
because
there
are
multiple
extension
headers,
stacked
together
and
so
each
extension
header
will
indicate
the
length
of
itself
and
also
the
type
of
a
next
extent
header.
So
essentially,
all
the
extension
headers
are
formed
from
a
chain
just
like
scipv6
exchange
header
and
we
suggest
to
adopt
the
same.
I
I
After
the
current
extend
header.
We
reach
the
end
of
the
packet,
so
this
is
used
for
special
packages
like
the
some
probing
packets.
The
second
special
type
is
unknown.
It
can
be
only
used
in
the
last
extend
extension.
Header
in
the
chain
indicates
the
the
payload
type
is
unknown
and
the
third
type
we
recently
added
is
mpls
tab,
which
means
there
will
be
another
nps
label
stack,
follows
this
extension
header.
I
So
this
is
interesting
because
in
some
use
case
we
might
have
a
multiple
nps
stack
sections
and,
for
example,
for
the
studio
wire
application
on
top
of
another
nps
infrastructure
and
for
some
other
tunnel
internal
use
cases.
So
we
can
have
a
multiple
section
of
mps
labels
separated
by
the
extension
headers
and
also
we.
We
need
to
support
the
case
where
the
gale
and
the
ach
are
present
in
the
in
the
packet.
I
So
if
there
are
sh
in
the
packet,
then
the
extension
headers
will
be
located
immediately
after
the
sh
acs
header
field
and
we
allow
all
the
extend
headers
to
be
jumped
in
just
one
step.
So
that's
why,
in
the
header
of
the
extension
header,
we
define
the
total
length
of
the
extension
header.
I
So
if
we
want
to
access
a
original
upper
layer
header,
we
can
jump
to
that
section
immediately
and
also
we
want
to
support
both
end
to
end
type
or
holdback
hub
types
and
for
the
efficiency
we
require
to
put
the
end-to-end
extension
headers
behind
the
hph
extension
headers
next
slides.
I
I
The
first
four
bits
are
reserved.
Then
the
next
four
bits
extension
header
counter
to
indicate
how
many
extension
headers
we
have
in
this
in
this
package,
so
which
means
also
we
can
have
up
to
15
extension
headers
in
the
package
allowed.
I
Then
after
that
is
extension,
header
total
length.
So
this
can
be
used
to
skip
all
the
extension
headers
to
reach
the
upper
layer
then
follow
that
we
have
our
original
upper
layer
particle
type
field,
it's
labeled
in
red,
so
we
can
which
can
tell
okay,
what's
the
type
of
the
upper
layer
particle,
and
then
we
have
a
tab
for
the
next
header.
I
I
So
there's
a
you
can
see,
there's
also
a
possible
optional
field,
it's
a
subtype
extension,
so
it's
just
a
which
can
be
used
to
extend
the
extension
header
types
and
with
this
configuration
we
can
allow
the
total
length
of
the
extension
header
to
be
1k
byte
and
also
we
can
support
the
case.
There's
zero
extension
headers
and
only
the
header
of
extension
header
exist.
I
Please
also
have
ways
to
optimize
the
4d
performance
using
fec
labels,
because
right
now,
if
we
don't
have
any
other
method
to,
we
have
to
segan
through
the
entire
labor
stack
to
find
the
extension
header
indicator.
I
So
if
it's
below
the
toss,
the
the
the
top
of
stack
there
could
be
have
some
performance
impact
and
so
to
to
solve
this
problem.
When
it's
establishing
the
labor
switch
parts,
we
will
assign
two
fec
labels,
and
why
is
a
means?
Okay,
this
just
folding
the
package.
There
could
be
extension
headers.
You
need
to
search
for
it.
If
you
are
extension,
header
capable,
but
another
means
there's
no
extension
header
in
the
package.
I
It's
explicitly
to
tell
that
the
fact
so
for
the
e
extension
header
in
capable
nodes,
they
just
do
the
regular
forwarding,
but
there
are
extension
header
capable
nodes
if
they
receive
a
regular
label,
so
they
will
need
to
examine
if
there
are
extension
headers
in
the
packet
or
not.
So
if
yes,
they
will
use
a
you
know
if
there's
a
extension
header
in
it.
If
you
can
use
a
continue,
use
a
regular
label
to
forward
the
packet.
I
If
it's
fine,
there's
no
extension
header,
they
will
switch
to
the
no
extension
header
fact
label
to
forward
the
packet
and
for
the
each
capable
nodes.
If
they
receive
a
no
extension
header
label,
it
will
know:
okay,
there's
no
lab
no
extent
header
in
it
and
if
they
just
if
it
also
doesn't
add
any
new
label,
a
new
header
to
the
packet,
it
just
needs
to
forward
this
package
with
a
no
eh
fcc
label.
I
I
It's
built
on
common
industry
practices
and
keep
performance,
flexibility
and
extensibility
in
mind,
and
we
also
believe
extension
head
is
especially
compelling
for
mps,
because
mps
label
stack,
the
overhead
is
much
smaller
than
ipv6
and
mps
is
also
protocol
independent.
I
A
Okay,
very
good.
I
see
one
person
in
the
queue
babu
take
it
away.
J
Yeah,
this
is
the
concept.
Wise
is
very,
very
good,
but
what
I
feel
is
that
you
know
like
implementing
in
the
hardware
will
be
a
pretty
complex
and
also
like.
If
you
do
that,
then
we
might
need
to
change
all
the
routers
if
you
want
to
support
any
new
features
which
needs
this
kind
of
announcement.
I
Yes,
so
in
terms
of
packed
parsing,
it's
no
no
more
difficult
than
the
current
practice,
but
yes
with
any
added
extension
header,
you
need
some
more
packed
processing
so
that,
therefore
I
believe
in
most
cases
you
will
control
how
many
extension
extension
headers
allowed
in
the
same
packet.
K
Yeah,
so
when
this
proposal
was
just
got
very
at
the
very
beginning,
I
my
impression
was
that
there
were
concerns
about
the
header
of
extension
it
itself.
K
Since
I
did,
I
missed
some
design
team
meetings.
I
I'm
just
curious
if
there
were
any
follow-up
discussion
on
that
and
if,
if
it
is,
if
we
had
already
have
consensus
to
keep
that
header
extension
or
not
to
use
the
header
extension
header.
I
Yeah
you,
you
sound
a
little
bit
broken.
I
can't
hear
you
clearly.
Can
you
just
replace
your
question
in
one
sentence.
K
Okay,
so
at
the
very
beginning,
I
think
there
were
people
who
do
not
like
the
head
of
extension,
header,
okay,.
D
K
I
Okay,
I
so
I
don't
remember
we
have
further
discussion
on
that,
but
the
point
of
a
header
of
extension
header
is
to
use
to
summarize
you
know
the
lens
some
information
about
header,
to
help
us
to
reach
the
upper
layer
easily
so
because
there's
no
more
space,
I
think
in
the
label
stack
to
this
to
to
provide
the
same
amount
of
information.
So
that's
why
we
started
it
to
start
the
extension
header
section
with
a
another
header
is
one
word
header,
so
that's
the
purpose
of
it.
I
D
Greg
so,
in
my
understanding,
correct
that
the
proposed
headers
are
immediately
follow
the
label
stack.
I
D
D
Okay,
have
you
considered
how
it
works
if
there
is
a
gal
label
in
the
label
stack
or.
D
I
A
Yeah
that's
covered
in
the
draft
as
well.
We
have
one
more
person
to
weak
and
then
I
would
like
to
cut
off
the
the
cue
there
such.
C
A
week,
okay
quickly,
a
packet
may
arrive
with
extended
header
on
the
router
and
that
router
wants
to
add
or
insert
extended
headers.
It's
not
clear
to
me
how
you
can
insert
extended
headers
in
this
case,
and
how
do
you
pop
you
know
those
extended
headers
at
different.
I
Legacy
yeah
yeah,
it's
easy
to
add
a
new
header
into
a
chain
right.
You
just
find
the
right
location.
Then
you
modify
the
previous
headers
next
header
field
and
you
put
it
after
this
header
and
the
chain
also
set
its
next
header
to
the
value
of
the
you
know
the
next
header
type.
So
that's
it!
What
deletion?
You
can
do.
The
similar
thing
you
just
need
to
modify
some
some
field
in
the
in
the
previous
extension
header.
A
B
Stuart,
can
you
make
it
quick
yeah?
I
just
wanted
to
clarify
clarify
a
point
that
how
you
were
saying
that
you
could
put
an
extension
editor
after
the
ach.
There
is
no
length
mechanism
in
the
ach
at
the
moment,
so
existing
aches
can't
have
extension
headers
after
them.
You
wouldn't
find
them.
A
K
K
K
So
what
if
we
extract
them
out
and
apply
to
any
layer
where
it
makes
sense,
for
example,
ip
mpos
beer
or
even
ethernet?
So
we
call
this
generic
delivery
functions.
It's
basically
between
any
two
points
at
the
layer:
2
layer,
3
layer
2.5,
for
example,
between
two
ethernet
nodes
between
lsp
ingress,
egress,
ip
desk
source
destination
and
nodes.
Things
like
that
next
slide.
Please.
K
So,
in
the
earlier
revisions
of
the
drafts
we
have
the
proposed
this
header
for
generic
delivery
functions.
I'm
listening
talking
about
it
here,
just
as
fyi,
because
we
are
actually
thinking
of
changing
that
anyway,
you
can.
You
can
see
that
here
we
have
a
next
header
and
then
this
header
next
header
will
come
come
from
the
ip
protocol
number
space.
K
It
could
point
to
a
another
gdf
header
or
ipnex
header,
and
this
header
uses
its
own
number
space
for
different
gdfs.
With
that
we
let's
say
we
have
multiple
gdp
support.
That
way,
we
don't
need
to
take
one
number
from
ip
focal
number
space
for
each
gtf
that
that's.
That
was
the
intention
and
the
outer
header
or,
for
example,
npr's
label
or
a
beer
protocol
field.
Ipx
header
will
indicate
that
gdf
which
follows
next
slide,
please.
K
So
as
the
the
mps
design
team
in
this
discussion
going
on,
and
and
also
a
better
understanding
of
the
mpos
extension
headers,
and
now
we
have
some
new
thoughts
about
on
how
to
encode
the
gtx
gtf
headers,
so
a
gdf
being
generic.
That
means
it's
likely
to
be
applicable
to
ips
as
well.
K
So
therefore,
there's
really
no
need
to
to
have
this.
Have
this
header
to
indicate
what
it
is.
We
can
just
use
certain
ip
extension
headers
at
other
layers.
If
we
need
to
make
small
enhancements,
we
can.
We
can
do
that.
K
So
we
do
not
need
to
have
ip
next
header
code
point
to
indicate
that
the
next
header
is
a
gtf
either
unless
in
the
future,
or
we
run
into
some
so-called
gdfs,
but
they
are
truly
not
applicable
to
iop.
In
that
case,
if
we
want
to
save
a
number
from
the
ip
protocol
number
space,
then
we
can
have
a
gdf
type
and
then
then
we
have
subtypes
to
indicate
what
kind
of
gf
it
is.
K
So
if
we
do
that,
then
the
mqs
label
stack
or
beer
header
will
need
a
way
to
point
to
a
iphone
extension
header.
K
K
So
if
I
use
mqs
extension
header
for
to
do
fragmentation
and
reassembly,
you
can
see
that
we
would
use
the
npos
head
of
extension
header
and
it
will
in
that
heh.
K
The
enhancement
is
needed
because
in
case
of
ip
or
ipv6,
the
source
and
destination
destination
address
are
used
together
with
the
identification
and
to
know
that
which
which
fragments
are
together
because
identification
number
is
solved
could
be
the
the
same
for
different
packages
from
the
from
different
nodes.
So
we
need
to
use
the
source
and
destination
address
as
the
context
now
with
mpos.
K
K
To
indicate
that
the
sender
information
is
included
and
because
when,
when
you
use
this
fragmentation
for
different
layers,
the
sender
information
may
may
have
different
lengths.
So
now
we
use
the
we
actually
need
to
encode
the
header
lens
there
that
in
the
ipv6
fragmentation
case,
the
header
lens
field
is
actually
reserved.
It's
not
used,
but
here
we
we
actually
use
that
field
to
to
indicate
the
length
of
that
header.
K
K
Please,
even
though
this
is
not
the
beer
session,
I
I
thought
I'll
talk
about
it
quickly.
So
beer
is
a
a
as
another
forwarding
and
plan
for
multicast
and
each
beer
packer
carries
a
beer
header.
So,
as
in
the
part
of
the
the
in
the
beer
header,
there
is
a
protocol
field.
K
We
would
assign
a
new
point
for
that
protocol
field
to
indicate
there
is
a
extension
header
follow
that
follows,
and
so
when,
when
the
protocol
is
set
to
that
protocol
set
to
that
code
point,
it
means
that
after
the
regular
beer
or
header
there
is
this
extension
header
are
following
that.
K
We
can
either
start
with
something
like
the
mpos
header
of
extension
header,
or
we
can
simply
just
need
the
eight
bits
number
to
indicate
what
that
next
header
is.
So
it
depends
on
on
the
discussion
and
whether
or
we
really
want
the
heh
or
not.
K
That's
why
I
was
asking
the
question
earlier
so
then,
after
that
you
can
see
that
purple
color
or
is
the
the
ip
extension
header
used
for
for
fragmentation,
and
here
we
don't
even
need
that
standard
information
here,
because
in
the
beer
case
we
that
bf
irid
fields
after
the
protocol
field
can
be
used
to
amplify
sender
and
that,
together
with
identification,
can
be
used
for
a
fragmentation
and
reassembly
purpose.
K
The
next
slide,
please,
so
I
we
have
not
got
a
chance
to
update
the
corresponding
our
draft,
because
this
the
news
thoughts
came
very
recent.
After
or
or
more
discussions
on
the
nps
extension
header,
but
so
we
will,
we
will
seek
more
comments
and
then
we
will
update
the
drafts
accordingly.
A
So
now
we
have
about
25
minutes
by
my
watch
for
open
discussion,
so
the
floor
is
open
to
everybody
for
what
whatever
you'd
like
to
talk
about
as
a
result
of
all
these
presentations.
E
Andy
my
question
for
jeffrey
is
it's.
I
think
a
really
intriguing
idea
to
use
common
formats,
especially
data
plane
formats
between
say,
ipv6
and
mpls,
and
beer,
and
the
value
of
that
is,
if
I'm
writing,
if
I'm
writing
microcode
for
the
forwarding
plane.
Maybe
you
know
if
I
can
find
a
way
of
doing
it
in
a
more
modular
fashion,
then
I
can
say
plug
in
this
microcode.
E
You
know
I'm
going
to
parse
the
header.
Oh,
this
is
ipv6,
but
I'm
going
to
call
this
microcode
as
a
subroutine.
Oh,
it's
mkls.
It
doesn't
matter
I'll
still
call
this
thing
as
a
subroutine.
Maybe
there'll
be
a
few
tweaks,
because
a
few
fields
move
around.
So
I
guess
the
question
is:
does
that
actually
play
out
in
in
real
life
I
mean?
Have
you
talked
to
anyone
in
the
forwarding
path
to
see
if
we
can
actually
do
that
kind
of
reuse
of
microcode.
K
I
have
actually
not
got
the
chance
to
to
to
check,
but
my
thinking
is
that
it
just
so.
It
may
just
make
sense
to
to
do
that.
I
I
would,
I
would.
K
C
Hey
my
question
is
not
necessarily
to
jeffrey,
but
to
the
design
team.
We
have
seen
so
far.
Maybe
three
encoding
different
different
encodings
of
metadata
after
the
end
of
stack
mpls
and
the
stack
and
my
question
is
how
how
do
we
want
to?
We
definitely
want
to
pick
eventually
one
encoding,
the
standardized
and
do
you
think
we
should?
C
B
Speaking
now,
yes,
so
a
proposal
I
made
to
the
design
team
a
little
while
ago
was
that
we
really
need
to
understand
the
applications.
B
Any
solution
really
should
be
generic,
etc,
but
understanding
what
we're
trying
to
do
is
always
a
good
way
of
sort
of
focusing
the
the
design.
So
I
think
we
need
to
understand
what
we're
going
to
do
with
this
and
then
it'll
be
more
obvious,
which
one
we
should
we
should
pick.
D
So
first
stuart.
Thank
you.
I
appreciate
your
comment
earlier
about
ach
and
that's
my
question
to
actually
in
continuation
with
tarek
suggested.
D
So
should
we
have
a
list
of
requirements
and
would
their
backward
compatibility
with
ach
be
one
of
the
requirements
for
any
potential
encapsulation
scheme?
K
Speaking
and
muted,
so
about
the
coexistence
of
ach
and
the
extension
header,
I,
the
design
team
concluded
that
we
we
wanted
to
support
that,
and
my
understanding
is
that
ach
we
we
we
will.
We
will
know
when
the
ach
ends
right.
So
as
long
as
we
have
fly
in
the
labor
state
stop
to
indicate
there
is
an
extension
header
and
then
we
also
know
that
there
is
a
ach
because
of
the
existence
of
gao.
D
My
understanding
of
ach
is
that
it
is
only
known
if
this
ach
is
supported,
so
there
is
no
explicit
indication
of
the
length
of
bca
and,
for
example,
residence
time
measurement.
D
That
includes
ptp
messages,
so
parsing
it
only
possible
if
the
node
supports
this
type
of
ach.
D
There
is
no
right
current
ach
and
again
in
my
understanding,
for
example,
if
I
don't
want
to
compare,
but
the
scheme
that
stuart
proposed
to
me
appears
that
it
can
easily
support
or
coexist
with
ach.
B
D
B
D
But
but
again
I
I
just
don't
want
to
extensively
discuss
this
point,
but
just
to
have
this
as
a
requirement
and
when
we
get
to
evaluate
different
proposals,
understand
what
ach
currently
is
and
how
it's
been
defined
and
how
it's
been
used.
So
not
all
nodes,
support,
oach,
correct.
B
A
B
And
when
I
look
at
some
of
the
proposals,
I
fear
that
we
have
lost
sight
of
that
cardinal
principle
in
the
design
of
mpls,
that
it
should
be
simple
and
that
the
control
plane
should
should
take
an
important
role
in
interpreting
what
the
actions
are.
So
please
please,
let's
try
to
have
a
simple
design
that
goes
fast
and
it
is
not
sort
of
buried
in
complexity.
E
E
E
If
we
come
up
with
a
comprehensive
way
of
encoding
data
after
the
bottom
of
stack,
then
we
can
fold
ach
into
that
and
and
then
sort
of
deprecate,
at
least
the
gal
label
and
the
current
way
of
doing
ach
and
carry
the
useful
parts
of
that
in
a
way
that's
compatible
with
how
we're
going
to
do
stuff.
After
end
of
time,
thanks.
K
Make
three
points.
I
hope
I
remember
that
those
three
points
about
a
game
for
the
coexistence
of
ach
and
extension
header.
K
If
we
say
that
we
are
going
to
not
allow
the
quiz
instance
or
if
we
are
going
to
say
that
we
were
just
implement
the
sh
function
as
a
using
an
extension
header,
then
yeah
we
saw
the
problem,
but
if
we
do
to
to
allow
air
coexistence
and
now
that
I
know
that
there
is
no
lens
in
the
ach
header,
then
I
realized
that
how
you
actually
talk
about
that
for
ex
the
the
indication
of
the
existing
extension
header.
K
K
K
I
guess,
if
we
have
a
requirement,
then
we
want
to
support
it,
but
I
guess
the
definition
of
complexity
is
complex.
It's
a
pointer
resolution,
a
complex
solution.
I
guess
that's
also
subject
to
discussion.
K
G
In
line
the
security
set,
being
backwards,
compatible
comes
with
price
and
specifically
to
gal.
Gadge
price
is
rather
high,
given
the
semantics
so
and
in
all
my
years
in
the
industry,
I've
never
seen
it
actually
deployed.
So
I'm
not
maybe
representative
here,
but
we
really
need
to
do
proper
analysis.
How
much
it
is
needed,
try
to
move
it
into
more
generic
function
or
potentially
just
put
it
to
bed.
I
mean
if
it's
not
very
much
deployed
in
use,
making
new
solution
backwards,
compatible
brings
price
and
complexities.
That's
not
justifiable.
D
Well,
definitely
in
one
geographical
area
ach
is
deployed
broadly
and
supported,
whether
it's
sufficient
for
us
to
consider
or
ensure
the
backward
compatibility.
That's
a
different
question,
but
at
the
same
time
so
it's
been
designed.
We,
I
don't
think
that
it's
possible
to
really
get
reliable
information
of
what's
being
deployed
and
say:
oh,
nothing
is
sufficient
scale
being
deployed
elsewhere
of
the
geographical
area
we
know
about,
so
that
we
can
ignore
it
again.
I
would
rather
keep
it
as
a
requirement.
B
No
I'm
going
to
dispute
the
idea
that
gao
that
the
ach
is
not
widely
deployed.
I
believe
it
is
quite
widely
deployed
in
pseudo-wires,
which
is
where
it
was
designed
for
and
the
the
tendency
has
been
to
move
to
that
as
the
oam
technique.
Deprecating
some
of
the
earlier
techniques,
at
least
as
I
understand
it,
I'm
prepared
to
be
told
I'm
wrong.
K
K
My
understanding
is
that
if
you
have
a
router
that
only
only
understands
a
sh
and
then
there
is,
but
then
there
is
also
a
extension
header
following
it.
I
don't
think
that
causes
like
a
backward
compatibility
issue,
because
the
the
the
the
legacy
load
node
will
just
process
the
ach,
which
is
right
after
the
bottom
of
a
stack
label
as
before,
and
it
just
doesn't
process
the
extension
headers
and
by
design.
That's
fine,
because
extension
has
just
a
new
functionality.
K
If
you,
if
you
your
router,
that
the
node
does
not
support
it,
then
what
can
you
do?
It
does
not
support
it
right.
So
it's
not.
It's
not
a
issue
specific
to
coexistence
of
the
ach
and
extension
header.
E
Kuwaiti
what
I
said
about
ach
the
idea-
and
you
know
I'm
not
talking
about
how-
how
well
it's
deployed
or
how
much
it's
deployed
it's
really
about
when
we
redesign
as
the
design
team
is
doing
at
least
one
track
of
the
design
team,
the
the
stuff
that
goes
below
bottom
stack
instead
of
trying
to
coexist
with
the
current
definition
of
ach
the
the
idea
is
that
it
it
incorporates
the
ach
information
in
a
way
that
makes
everything
much
more
extensible,
and
so
we
we
don't
tie
our
hands,
trying
to
incorporate
aches
the
way
it
exists
today,
but
we
incorporate
the
information
that
ach
carries
in
a
way
that
makes
the
overall
architecture
simpler
and-
and
that's
basically
the
thing
that
we
need
to
do.
E
I
think,
rather
than
actually,
you
know
throwing
it
out,
which
is,
I
think,
the
wrong
thing
to
do
or
trying
to
coexist
with
it
as
it
is
today
if
there
is
a
way
to
coexist
without
making
the
arc.
You
know
without
restricting
ourselves
limiting
what
we
can
do
and
making
it
very
complex.
E
There's
a
similar
discussion
happening
with
six
man
on
router,
alert
and
part
of
what
they're
trying
to
do
as
adrian
put
it
in
that
meeting,
they
would
dance
around
the
issue
of
router
alert
when
they're,
defining
or
trying
to
redefine
how
to
do
hop
by
hop
and
one
of
the
discussion
points.
There
is
no
just
forget
how
to
alert.
In
that
case,
I
think
you
can
actually
do
away
with
router
alert,
but
in
this
case
I
think
we
have
to
re-encode
ach
so
it
fits
into
other
new
architectures.
E
B
Take
this
in
a
number
of
phases
right,
so
we
we,
we
can't
break
lsps
pseudo-wires
that
are
running
across
the
network
that
happen
to
be
using
ach
at
the
moment
right,
so
in
terms
of
discard
and
and
compatibility,
etc.
We
can't
break
those.
They
have
to
be
able
to
still
live
in
the
network.
B
In
terms
of
whether
you
can
put
an
ach
and
a
an
extension
header
in
the
same
pack
of
some
sort
in
the
same
packet,
then
I'm
going
to
dispute
what
I
think
was
jeffrey
said,
because
when
it
comes
to
disposition,
you've
got
to
know
that
it's
there.
So
if
you
get
into
a
legacy
node
that
discovers
a
an
ach
processes
that
and
then
there
is
a
an
extension
header
afterwards,
there's
a
big
danger
that
that
information
is
going
to
get
passed
and
passed
as
payload
to
some
poor
unsuspecting
next
hop.
B
So
we
can't
you
co,
you
can't
just
hand
wave
over
the
existence
of
both
the
the
disposing.
Router
has
got
to
know
how
to
get
rid
of
everything
that
sits
between
the
bottom
of
stack
and
the
real
payload
to
be
delivered.
B
So
and
finally,
I
kind
of
agree
with
what
kiriti
is
saying,
though,
which
is
that
in
cases
where
we
want
to
use
an
oam
mechanism
of
the
sort
that
ach
provides-
and
we
want
to
do
something
new-
we
probably
need
to
migrate
the
oam
information
into
a
format,
that's
compatible
with
our
new
ancillary
data
structure
and
system.
So
thank
you.
A
K
Okay,
I
just
want
to
clarify
that
the
competitive
compatibility
issue
is
not
specific
to
the
coexistence
of
ach
and
extension
header.
It's
the
the
the
extension
head
itself
support,
even
without
the
ach
in
the
in
the
picture
we
have.
We
have
to
be
careful
that
so
what
if
you
lsp
egress
receives
a
a
packet
with
extension
header,
but
it
does
not
know
how
to
deal
with
it
that
that's
a
generic
general
compatibility
compatibility
issue.
A
B
Right,
okay:
well,
I
will
attempt
to
summarize
what
I
think
are
the
key
takeaways
from
this
first
is
that
we
should
probably
extend
an
invitation
to
the
work
to
the
tease
working
group.
Lou
is
at
liberty
to
say
no,
no,
we
don't
need
to,
but
I
think
we
should
probably
extend-
and
you
should
note
to
the
members
of
the
t's
working
group
that
we
exist
and
are
doing
this
work.
B
There's
clearly
a
tie
in
with
the
work
that
six
men
are
doing
on
hot
by
hop
headers
there's
some
mutual
learning,
not
necessarily
the
same
solution,
same
technical
solution,
but
some
mutual
learning
to
be
done,
and
I
think
it
would
be
useful
to
have
a
joint
session
with
with
them.
B
A
number
of
these
proposals
could
usefully
be
merged,
certainly
the
work
that
karisi
has
done
and
the
work
that
that
the
people
I've
been
working
with
have
done
could
be
usefully
merged.
We
need
to
see
how
we
can
merge
with
the
the
ad
the
the
the
more
complex
approaches
for
describing
the
data,
the
the
ancillary
data
definitions.
B
And
finally,
it's
quite
clear
from
this
discussion
that
there's
a
lot
of
ach
coexistence
matters
that
are
still
unresolved
and
some
quality
time
will
need
to
be
spent
by
the
design
team
working
on
that
and
trying
to
find
a
way
of
finally
putting
a
resolving
that.
I'm
not
sure
that
I've
missed
anything
else,
that
any
of
the
other
chairs
want
to
want
to
to
say
so
I'll
put
it
over
to
to
them
to
to
add
their
comments.
A
A
H
C
It's
along
the
same
line.
I
wanted
to
say
that
we
have
a
use
case
wiki
that
we
started
somewhere
on
the
you
know
the
wiki
that
you're
pointing
on
it's
another
page
or
a
pointer
listed
there.
I
extend
this
invitation
to
everybody
interested
to
describe
use
cases.
We
did
identify
a
couple
of
them
and
they
were
noted
on
the
slides
that
stewart
had
presented
so
yeah
I
mean.