►
From YouTube: MPLS WG Interim Meeting, 2021-04-29
Description
MPLS WG Interim Meeting, 2021-04-29
A
Part
well
again,
and
one
thing
is
that
and
that
came
up
as
a
question
in
a
discussion
among
contributors
to
this
work,
that
in
this
proposal
we
are
not
considering
the
case
that
there
are
multiple
ach.
A
So
in
this
proposal
their
assumption
is
and
actually
we're.
B
A
To
make
it
explicit
in
a
document
that
there
is
only
one
ach
as
a
payload.
C
A
Well,
how
their
node
that
finds
the
gal,
not
in
the
bottom
of
the
stack
process
it
so
it's
not
yet
firmly
specified
in
a
document,
but
what
it
should
conclude
is
that
there
is
ach
that
follows
the
label
stack.
A
So
how
that
uses
this
information,
it's
yet
to
be
defined,
and
we
can
discuss
that.
But
what
basically,
the
gal
interpretation
is
very
simple:
no,
no
matter
where
you
find
the
gal.
It
indicates
that
there
is
one
ach
that
follows:
the
label
stack.
C
That
is
correct.
That's
the
only
thing
we
can
probably
that
we
can
say
for
sure
that
that
gal
implies
a
an
ach
at
the
bottom
of
stack
exactly
once.
D
A
A
C
Yes,
yeah,
I
mean
yeah,
so
presumably
what
you'd
have
to
do
is
to
do
whatever
lam
action
you
you're
supposed
to
do.
Then
you
ought
to
pop
the
gal
and
do
what
the
next
label
is.
Didn't
you,
yes,.
A
A
So
it's
not
encoded
in
in
the
data
plane,
at
least
it's
how
I
think
about
it
of
it,
because
there
could
be
a
different
things
that
be.
C
Done
if
there
are
only
two
actions
you
could
take
you
either
pop
it
and
continue
on
with
the
next
one
or
you
terminate
the
packet
at
this
point.
A
And
that's
basically
why
there
is
this
placeholder
section.
C
So
why
would
you
why
would
you
put
since
you
have
to
put
the
ach
on
before
you
put
the
label
stack
on?
Why
would
you
put
a
gal
higher
in
the
stack
that
was
going
to
do
anything
other
than
do
some
oam
action
pop
it
and
continue?
Because
if
it's
not
going
to
do
that,
you
might
as
well
just
not
bother
with
the
rest
of
the
stack
and
you
might
as
well
put
the
gal
at
the
bottom
of
the
stack
and
revert
to
a
previously
known
solution.
A
C
A
How
you
know,
then,
will
the
label
stack
yes?
Well,
if
we
insert
gal,
they
will
stack
for
the
oem
packet
will
be
different
from
the
label
stack
for
the
data
packet,
but
you
know
it
happens,
anyways
if
we
use
gal
okay,
if
you
use
gal
at
the
bottom
of
the
label
stack,
it
makes
other
label
step
of
the
pack.
Data
and
oem
are
different
already.
A
So
yes,
but
because
it's
a
special
purpose
label,
then
the
impact
is
only
on
the
length
of
label
stack,
not
how
it's.
C
Processed,
so
so
so
so
just
be
clear:
what
do
you
want?
What
do
we
want
to
happen
right
so
we're
we're
we're
we're
going
down
this
label
stack
and
we're
throwing
away
labels
and
the
gal
arrives
at
the
top
we're
going
to
go
away
and
do
some
oam
function.
Are
you
saying
that
we
go
back
and
we
pop
the
gal
and
we
pop
them
play
without
looking
at
it
for
sfc
mpls?
C
Yes
right,
so
how
would
we
know
to
to
do
that?
Presumably
part
of
the
ach
action
would
be
pop
the
next
label
unconditionally,
because
otherwise
it's
a
very
dangerous
thing
to
put
in
there.
Isn't
it.
E
Well,
the
thing
is
that,
let
me
let
me
jump
in
here
how
many
labels
do
you
pop?
Because
sfc
is
you
know
you
can
have
multiple
stops
in
your
sales
function?
So
if,
if
you,
if
you're
going
to
pop,
maybe
it's
not
enough
to
pop
one
label.
C
A
Well,
the
basic
unit
is,
is
defined
as
two
labels,
so
that,
in
my
understanding
you
you
cannot
have
multiple
service
functions
following
their
sff
label.
A
So
so
you
you
might,
if
you
have
multiple.
A
Service
functions
connected
to
the
same
sff,
then
you
either
use
a
label
swapping
model
or
you
have
to
use
multiple
basic.
A
Units
all
right,
so
this
is
and
and
and
again
the
the
basic
unit.
As
I
understand
they're,
it's
a
context
label
so
on
the
wire.
C
Unit,
I
have
a
question
you're
right,
you're
right,
you're,
right,
you're,
right
anyhow,
this
worked
but.
D
Do
we
want
to
decouple
the
pr
you
know
the
proposal
to
have
multiple
gals
in
the
stack
from
the
applications
trying
to
leverage
this
this,
the
the
the
couple,
the
the
discussion?
D
You
know
you
know
one
one
thing
is
to
tackle
the
presence
of
the
gal
multiple
times
and
the
other
thing
is:
okay.
There's
a
new
applications
trying
to
write
on
this
or
do
you
want
to.
A
Actually
law
asks.
D
A
Good
question,
because
that
did
not
appear
in
our
discussions
within
contributors
to
this
work,
whether
it's
specifically
for
sfc,
mpls,
environment,
the
multiple
labels
or
it's
a
broader
like
non-mpl,
stp
environment.
So
and
that's
something
that
yes,
I
agree.
It's
open
for
the
discussion.
So
we
might
decide
that
multiple
gal
labels
to
be
used
only
environments
described
in.
A
E
You
say
why
and
whether
it
is
ssc
or
some
other
reason
why
this
having
multiple
gals
is
useful
and
then,
second
to
the
point
that
steve
stewart
was
going
going
to
say
how
you
process
it.
But
I
mean,
if
you
say
it's
in
the
sfc
context,
then
you
have
to
pop
the
sfc
labels.
E
So
I
I
think,
while
you
can
decouple,
if
you
don't
have
a
reason
for
doing
this,
then
it's
very
hard
to
think
of
this
from
the
abstract.
And
the
second
thing
is
you
know
what
exactly
you
do
is
also
important.
C
So
can
I
make
a
process
suggestion
here?
This
sounds
like
it
needs
a
discussion
between
the
authors
of
rfc,
a
voice,
call
between
85
95,
authors
and
and
greg
to
just
work
out
exactly
what
should
be
done
and
then
make
a
proposal
to
the
working
group,
because
I
think
we're
going
to
be
we're
in
the
minutiae
of
85
89
here.
Aren't
we-
and
this
probably
doesn't
need
the
entirety
of
this
group
to
at
least
come
to
an
opinion
on
what
is
what
should
be
done.
D
With
greg,
I
agree
with
stewart
here
that
there
are
details
that
are
still
needs
to
be
ironed
out.
I
think,
and
I
think
we
have
yeah,
given
that
the
audience
today
might
not
all
be
interested
in
in
in
the
gal
use
case.
C
I
think
they
yeah,
I
think
the
best
thing
to
do
is
for
the
the
the
group
that
wrote
that
rsa,
which
me
and
I
see
john,
is
on
the
call-
and
I
see
probably
adrian,
is
on
the
call.
Is
he
on
the
on
the
corner
this
week?
C
Okay?
Well,
he
probably
needs
the
three
of
us
plus,
whoever
else
you
think
you
want
to
invite
just
to
try
and
have
a
common
opinion
and
try
and
work
through
all
the
minute
detail
before
giving
it
you're
talking
in
front
of
the
32
other
people
on
this
call
in
this.
C
I
suspect
it
needs
to
be
an
open
meeting,
but
just
on
there
I
mean,
because
of
all
these
sort
of
current
geopolitical
sort
of
things,
it
probably
needs
to
be
an
open
meeting.
Doesn't
it.
D
No
problem
I'll
take
an
action.
I
already
noted
down
in
the
minutes
that
we
are
suggesting
this
meeting
and
I'll
take
the
action
item
to
set
it
up.
A
Yeah,
okay,
great
and
I
agree
with
stuart
proposal.
Let's
have
a
more
specific
discussion
for
this
and
after
that
we'll
see
if
there
is
anything
that
we
want
to
come
to
the
wider
audience.
D
A
Well,
because
we
are
distributed
might
be,
you
know
you
can
see
who
must
be
there.
So,
okay,
let
me
let
me
then
trigger
an
email
and
yeah.
A
A
A
I
agree
with
stuart:
it's
probably
has
to
be
open
meetings
with
a
number
of
people
strongly
invited
yes,
okay
with
that,
I
stopped
sharing
and
give
it
back.
D
Okay,
let
me
go
back
to
the
nation
again
and.
D
The
next
item
we
have
here
is
the
idea
of
multiple
ash
channels
after
the
bottom
of
stack,
and
we
talked
last
time.
I
I
have
the
minutes.
Whatever
was
recorded
from
the
meeting
last
time.
We
did
talk
about.
You
know
the
payload,
mpls,
payload
and
jeffrey
presented
the
gdf
solution,
which
allows
a
next
header
value,
and
so
anyone
wants
to
comment
on
this
or
you
know.
I
know
we
talked
about
it.
Last
week
there
were
a
couple
of
action
items.
D
F
Eric
I
have
one
comment
on
this
to
be
able
to
follow
up
in
the
future.
I
would
like
a
pointer
to
the
minutes
from
april
21st
in
the
minutes
for
today.
F
So
what
you
discussed
er
last
time
was
probably
not
that
much
track
too.
It
was
pretty
much
track
one
and
we
want
to
have
as
much
as
we
can
documented
in
track,
one
for
on
the
things
that
we
are
discussing.
D
That's
a
fair
point:
yeah
I
I
agree
and
yeah.
The
point
I'm
trying
to
raise
is
that
we
discussed
it.
Last
week
we
captured
two
main
requirements.
If
you
remember,
the
label
stack
should
be
able
to
indicate
to
a
transit
node
that
there
is
a
special
header
follows
after
the
bottom
of
the
stack.
D
D
How
do
we
encode
it?
There's
a
gdf
proposal.
There
was
idea
of
having
lv
a
length
and
value
or
a
value
only
or
type
in
length
and
value,
which
is
you
know
some
someone
pointed
that
it
might
be
a
performance
impacting.
D
D
F
Actually,
I
have
a
question
because
I
got
confused
somewhere
down
the
line
and
that's
why
I
put
the
question
or
the
again
the
item
in.
So
what
is
the
relationship
between
the
number
of
gals
in
the
stack
and
the
number
of
achs
after
the
bottom
of
stock
fit.
A
Well
again,
I
I
try
to
mention
that
in
a
presentation
in
our
proposal,
multiple
gal
only
indicates
single
ach
okay,
the
multiple
ach
is
not
been
considered.
F
A
So
if
somebody
needs
multiple
ach
and,
as
I
understand,
multiple
ach
achieved
by
a
different
shim,
which
has
can
be
parsed.
So
basically
there
is.
I
understand
that
it
has
ach.
A
That
indicates
their
special
metadata
and
the
metadata
has
its
own
shim,
which
can
be
parsed,
and
there
could
be
a
multiple
metadatas
under
the
one
single
ach.
F
F
A
No
again,
I'm
I'm
not
I'm
not
saying
that.
What
I'm
saying
is
that,
because
I
understand
that,
if
we're
talking
about
a
generic
function,
that
the
proposal
is
that
there
is
a
new
ach
type
and
nch
type
indicates
that
there
are
multiple
metadata.
A
D
E
I
I
think
we
should
first
solve
the
multiple
gals
problem
and,
and
the
author
said
that
they'd
go
off
and
figure
it
out
and
come
back
and
if
there's
no
one
proposing
multiple
achs,
I
don't
know
why
we
should
go
there,
but
because
what
greg
is
saying
is
you
know
he
just
wants
one
seh,
so
let's
at
least
resolve
that
and
table
the
multiple
aches
until
someone
says,
here's
why
I
want
to
do
it
and
then
we
can
figure
out
how
to
do
it.
E
D
Yeah
yeah,
we
took
an
action
item,
I
signed
it
greg
and
you
know
the
the
authors
of
that
rc.
So,
let's
let's
push
this
discussion
to
next
week
or
depending
on
the
track,
and
we
can
come
back
to
it
if
you're.
Okay,
with
that,
the
one
team.
E
Sorry,
sorry
and
four:
the
indicator
is
a
gal.
D
That
was
the
question
from
from
he
was
asking
about
the
presence
of
multiple
gals,
okay,
okay,
yeah
so
load.
Do
you
still
want
to
ask
number
four
in
the
context
of
a
different
different
indicator,
or
was
it
only
in
the
context
of
a
gal.
F
D
There
was
a
suggestion
to
add
it
multiple
times
and
the
reason
to
add
it
was
that
you
know
you
could
not
read
further.
There
is
a
limit
on
the
read
depth,
so
I
guess.
C
E
So
the
problem
is
that
it
might
be.
You
can
go
beyond
that,
but
there's
a
performance
penalty,
and
so
when
you
hit
that.
D
C
D
That's
a
good
point
yeah,
but
but
the
first
one
it
will
give
you
the
the
action
that
needs
to
be
done
and
the
subsequent
ones
are
relevant
to
the
next
trans
or
downstream
transit
nodes
or
egress
nodes.
D
E
D
Anything
to
add
on
this
point,
though:
no
okay,
next
next,
I
have
a
question
questions.
Draft
loa
did
you?
Are
you
questioning?
Oh,
this
is
a
draft.
C
D
If
you
have
the
link,
I
appreciate
the
fact
you
send
it.
F
F
F
D
D
Okay,
all
right,
if
any
volunteers
want
help
with
the
formulating
questions.
Well,
I
thought
one
of
the
questions.
C
I
I
I
thought
the
one
of
the
questions
about
whether
you
were
going
to
run
out
of
bandwidth
flooding
msd,
I
thought
was
kind
of
resolved
because
I
can't
imagine
anyone
doing
this
thing
without
a
an
igp
or
it's
equivalent
and
you
would.
It
will
be
trivial
to
flood
that.
So
certainly
there
is
no
flooding
scaling
issue
with
the
flooding
msds.
C
D
Yeah
and
that's
one
question:
I
think
he
wants
to
capture
all
the
questions.
Yeah.
C
No,
no!
No,
but
I
think
it's
it's
lower's
got
it
as
an
open
question.
I
cannot
possibly
believe
that
there's
a
scaling
issue
with
flooding
the
msd
capability,
I
believe
you're
right,
but
that
also
means
that
you
need
to
have
an
igp
well.
Well,
if
you
haven't
got
an
igp,
you've
got
a
management
system,
that's
doing
the
moral
equivalent
of
it
haven't
you
haven't
you.
F
So
the
management
system
will
tell
every
new
network
the
capabilities
of
every
other
network.
F
Path:
okay:
I
need
to
think
about
that.
It's
it's
not
entirely
clear.
C
So
if
you've
got
an
idea,
I
think
we're
cool
there's
an
igp
in
there.
It's
done
all
right.
I
mean
we
may
not
have
the
the
code
in
the
the
the
the
the
tlvs.
C
I
don't
know.
I
suspect
we
do,
but
it's
kind
of
done.
It's
not
not
a
problem.
If
there
is
not
an
igp,
then
you
must
be
using
a
management
system
and
the
management
system
had
better
know
the
capabilities
of
all
of
the
routers
and
the
management
system
is
the
only
thing
that
can
authorize
the
construction
of
an
lsp,
because
it's
the
only
thing
that
knows
enough
context
to
create
the
lsp,
and
since
it
knows
the
capability
of
all
the
members,
it
would
know
what
the
msd
was.
C
F
Then
let
me
come
back
and
I
think
I
think
I
think
you're
right,
but
I
need
to
think.
D
Okay,
I'll
switch
to
the
next
point
here
and
we
still
have
a
little
time
kiriti
the
the
discussion
on
the
you
know
the
indicator
and
the
label
stack
and
how
it
helps
genetic
indicator.
D
Do
you
have
some
slides
you
wanted
to
share,
or
you
want
to
talk
about
it?
Oh.
E
I
I
mean
I
have
the
same
slide
that
I
shared
at
the
special
meeting
that
we
had,
but
I
I
you
know
for
me:
there
are
a
couple
of
things.
I
haven't
attended
all
of
the
open
design
team
meetings,
so
I'm
not
sure
exactly
where
we
are.
E
The
big
things
that
I
would
like
the
group
to
tackle
is
hey
the
idea
that
we
we
use.
You
know
off
the
32
bits
in
the
mtls
label.
We
use
31
bits
as
opposed
to
trying
to
just
use
the
top
20
bits.
You
know
once
you,
the
top
20
bits
say
that
there's.
E
There
is
no
reason
to
say:
oh
and
the
last
eight
bits
are
ttl
or
the
exp
bits
or
the
tc
bits
are
telling
you
what
traffic
class
this
is
so
so
that's,
I
think,
the
the
one
big
thing
and
second,
if
you
do
that,
then
you
can
incorporate
many
more
functions.
C
E
A
single
indicator,
and
so
what
this
draft
said
was
how
you
put
into
one
indicator,
multiple
functions,
which
I
think
is
an
important
thing
to
solve,
because
the
dichotomy
between
you
have
a
one
labels
indicators,
special
paper
purpose
label,
and
then
you
have
the
extended
special
purpose
label,
which
means
you
need
two
labels
to
do
anything.
And
then,
on
top
of
that,
you
may
have
further
information
that
you
want
to
do.
And
then
you
have
multiple
of
those.
E
I
think
that
whole
system
is
very,
very
taxing
both
on
the
label
stack
and
on
forward
forwarding
forwarding
processors.
So
this
idea
that
you
can
you
you
put
multiple
functions
into
a
single
indicator.
E
I
think
is
one
that
we
need
to
think
about
and
pursue,
and
this
idea
that
we
reuse
the
the
bits
so
that
we
have
20
31
bits
that
we
can
use,
for
example,
not
that
I'm
a
big
fan
of
it.
But
if
you
were
to
say
let
me
reuse,
the
mpls,
sorry.
E
Eli
to
be
both
an
eli
and
something
else
trying
to
divide
20
bits
into
two
things
gives.
E
Room,
whereas
if
you
have
31
bits
just
a
little
better,
so
from
all
those
points
of
view,
I
just
want
to
know
where
the
design
team
is
in
terms
of
that
discussion
and
how
we.
C
E
Well,
thanks
thanks
stuart
yeah,
so
so
I
mean
the
the
other
thing
is
that
we
have
many
requests
for
special
purpose
levels
right
now,
so
the
idea
that
we
can
consolidate
them,
I
think,
is
important
as
well,
but
yeah
thanks
for
that
stewart.
E
So
how
do
we
proceed?
And
this
is
the
question
for
tariq
and
and
laura.
D
I
think
what
you
know
the
the
design
team
charter
was
is
to
agree
on
certain.
You
know
I
I
think,
there's
some
agreement
starting
to
come
together.
There
were
other
people
suggesting
other
ways
to
do
to
carry
you
know
in
the
label,
stack
applications
or
functions.
You
want
to
want
to
hear
their
view
or
point
of
view
as
well.
There
are
competing
drafts
to
yours
as
well,
and
and
if
there
is
enough
consensus
on
this
idea,
I
think
the
working
group
can
move
ahead.
C
But
I
do
think,
there's
a
I
think.
The
first
part
of
what
kriti's
observation
is
really
really
powerful
and
we
need
to
do
look
at
all
of
the
other
possibilities
associated
with
realizing.
We've
got
some
spare
bits.
Yes,.
F
F
It
could
be
that
I've
been.
I
wasn't
on
the
meeting
last
last
time
and
I've
been
I've
been
traveling
a
bit,
so
I'm
kind
of
not
really
up
to
speed.
But
let's
say
two
to
three
weeks.
I
think
we
can
get
nearly
nearer
to
making
a
decision
or
as
much
of
the
decisions
that
we
need.
G
One
of
the
problem
that
we
have
quite
a
few
proposals
and
it
seems
that
there
needs
to
be
a
little
bit
more
understanding
of
how
you
know
agreeing
on
one
proposals.
Particular
items
would
impact
the
other
proposals
and
kind
of
getting
to
that
point
that
everybody
understands
that
I'm
not
quite
sure
how
how
we
most
efficiently
do
that.
E
So
I
think
you
know
one
thing
is
to
have
that
arm
wrestling,
but
I
think
a
different
approach
is
to
say
what
are
the
things
that
we
want
to
achieve.
You
know
to
stuart's
point
this
idea
that
we
have
more
bits
and
that
we
can
use
for
different
things.
You
know
if
a
we
agree
that
that's
a
powerful
idea
and
b,
we
say:
okay,
given
that,
how
do
we
use
it?
How
do
we
encode
it?
What's
the
technical
details,
what
do
we?
What
are
we
trying
to
achieve
with
that?
E
I
think
that
would
be
a
first
step
towards
them.
Saying:
okay,
let's,
let's
figure
out
exactly
you
know,
let's
then
go
to
the
armrest,
but
I
think
starting
the
arm
wrestling
upfront
is
probably
not
the
most
effective
way.
G
I
guess
the
other
question,
of
course,
is
always
you
know:
how
do
the
different
vendors
feel
about
a
particular
change
in
the
encoding
being
feasible?
You
know
for
current
or
future
platforms,
I'm
not
sure
what
kind
of
the
the
typical
ways
on
how
that's
being
vetted
within
mpls.
E
So
you
know,
I
think,
there's
a
sort
of
bigger
question
there.
A
lot
of
things
that
are
put
into
the
mpls
architectures
from
20
plus
years
ago
were
based
on
what
we
could
do
in
the
forwarding
plane
then,
and
and
what
we
can
do
in
the
forwarding
claim
today
is
so
much
you
know
so
different,
if
not
so
much
more.
E
So
I
think,
coming
back
to
this
question
of
you
know
the
question
that
we're
asking.
What
do
vendors
think?
I
think
that
is,
you
know
an
important
part,
and,
and
so
we
did
talk
to
broadcom,
and
so
we
have
an
author
from
broadcom
as
a
co-author
on
the
draft,
but
I
think
the
other
part
of
it
is
what
do
vendors
think
in
general,
not
just
for
this
draft,
but
in
terms
of
some
of
the
things
that
are
going
on
or
that
were
written
down
in
mpls.
E
You
know
20
years
ago,
if
you
look
at
rfc,
3031
or
3032,
you
know,
are
there
things
there
that
we
need
to
change?
So
this
idea,
for
example,
that
the
tc
bits
or
the
ttl
bits
have
to
be
treated
in
a
particular
way.
Are
there
things
that
we
need
to
rethink
there?
E
There's
always
the
question
of
what
what
about
backward
compatibility
and
what,
if
there's
a
you
know,
even
if
it's
capable
of
different
things,
if
there's
a
router
that
doesn't
have
the
new
microphone
or
the
new
whatever
it
is,
that
helps
it
do
do
forwarding?
How
does
it
deal
with
this?
So
I
think
one
is
the
question
of
given
that
this
opens
up
a
lot
of
possibilities.
How
do
we
use
those
possibilities?
E
What
do
we
do
with
them
and
two
is:
what
do
you
do
in
terms
of
moving
the
mpls
architecture
to
a
new
place,
given
the
very
different
forwarding
capabilities
we
have
today
from
20
years
ago?
E
And
what
do
you
do
about
legacy
and
I
don't
mean
legacy
in
a
bad
way,
but
you
know
a
router
that
has
old
code,
even
if
it's
capable
of
all
kinds
of
fancy
things
if
it
encounters
this
packet,
what
does
it
do
so?
I
think.
B
E
Like
three
different
things,
I
would
like
to
focus
on
the
first,
but
I
think
the
other
two
are
also
important
and
we
might
come
back-
and
I
think
this
is
part
of
what
stuart
was
saying
in
that
the
special
meeting
on
friday
on
the
last
event
of
the
ietf,
the
last
etf,
but
rethinking
the
mps
architecture-
and
I
don't
know
if
it
was
specifically
in
europe-
the
completely
different
capabilities
we
have.
But
I
think
that's
a
that's
slightly
orthogonal,
but
that's
a
step.
We
need
to
do
as
well
in
the
working
group.
G
Right
so
I
mean,
as
far
as
you
know,
the
general
principles
of
encoding
right,
so
I
think
some
of
these,
these
things
that
were
kind
of
done
more
started
out
as
work
around
by
by
vendors,
for
something
mpls
didn't
have
in
terms
of
you
know
just
trying
to
figure
out.
If
the
payload
is
you
know
ip
or
not,
and
we've
been
spending.
For
example,
I
think
the
meeting
that
you
were
in
there
on
on
discussing
you
know
the
the
first
nibble
of
the
payload.
G
Afterwards
right,
right
and
and
those
type
of
things
are,
you
know
sure
they're
is
that
something
you
know
that
we
feel
we
might
even
want
to
retire
at
some
point
in
time
sure
we
can
always.
You
know,
try
to
say
well,
we
before
we
retire,
something
we
need
to.
You
know
figure
out
that
we
have
a
safe
transition
story
right,
but
when
it
comes
to
you
know
the
whole
storyline
that
steward
was
explaining.
You
know
on
that
friday.
It
seemed
like
there
is.
G
You
know
some
amount
of
technology
that
we've
accumulated,
for
which
we
have
already
or
could
in
this
effort
here,
find
better
solutions
right.
B
G
E
What
would
be
the
benefit
of
that?
How
would
I
use
it?
How
would
I
do
that
encoding,
and
that
is
orthogonal
to
the
question
that
you
were
just
talking
about?
I
think
they're
related
and
I
think
they
both
need
to
be
tackled,
but
I
think
we
can
at
some
level
separate
it
and
then,
if
one
impacts
the
other,
we
can,
we
can
come
back
to
it,
but
we
can
carry
them
out
as
two
different
tracks
or
two
different
pursuits.
B
Yeah,
I
have
a
question
for
the
design
team.
I
like
the
new
architecture.
The
way
mpls
is
approaching,
but
are
we
going
to
use
any
use
case
as
our
driving
example?
I
have
missed
past
meetings,
so
I
don't
know
about
it.
These
are
the
use
cases
that
will
fit
in
the
current
design
and
will
benefit
from
what
new
things
we
are
going
to
do
here.
D
There
was
two
use
case:
two
main
use
cases
that
were
drivers
to
the
to
this
design
team
being
put
put
together,
and
one
was,
was
the
idea
of
doing
oem
and
segment
routing
networks,
iom
specifically
in
c2
oem,
and
the
other
one
was
to
carry
a
slice
identifier
in
the
packet
and
other
other
identifiers
as
well.
D
C
The
one
that's
driving
a
group
of
us
is
latency
based
forwarding
where
you
need
to
know,
and
then
indeed
that's
what
going
for
as
well,
but
we
have
different
views
on
how
to
do
it.
B
E
G
This
this
this
would
go
down
to
you
know
better.
You
know
qs
parameters,
yakov
has
you
know
the
demand
for
per
hop
stuff
in
an
sr
fashion
like
for
hob,
we,
I
think,
would
start
with
something
on
a
path
based
like
in
the
extension
header,
and
I
think
it
would
be
valid
to
say
that
you
know
better
qs
would
be
something
to
consider
both
for
within
the
stack
and
in
the
extension.
G
D
Okay,
I
took
connection
item
to
add
use
cases
any
any
other
comment
on
from
the
other
proposals.
Authors.
E
So
I
understand
that
use
cases
are
important,
but
I
think
this
idea
that
we
step
back
and
rethink
what
we've
put
into
the
you
know.
Mpls
architecture,
I
think
that's
an
important
thing,
because
otherwise
a
lot
of
people
in
design
for.
E
Still
today,
every
time
someone
says,
I
want
a
new
special
purpose
label.
It's
always
a
single-use
special
purple
table.
I'm
only
new
special
about
this
label
for
no
further
fast
react.
I
want
to
use
special
purpose
for
for
hot
iphone
om.
I
want
the
second
one
for
entonum.
You
know
that
that
thinking
is
not
going
to
change,
and
so
I
think
this
idea
of
stepping
back
and
rethinking
the
actual
architecture,
even
if
it's
as
small,
as
you
know,
the
first
nipple
after
the
label
stack,
I
think
we
need
to
you
know
actually.
F
G
I
think
that
wasn't,
I
think
what
we
were
talking
about
right
now,
wasn't
a
disagreement
with
that.
But
just
you
know
many
many
people,
including
myself,
can
wrap
their
heads
back
around
abstract
concepts
when
they
can
try
to
map
them
to
a
few
practical
examples
which
are
these
use
cases
to
validate
them.
G
Is
you
know
what
what
really
is
an
architecture
right,
because
I
think
the
one
thing
I
I've
been
seeing
not
very
very
clearly,
you
know
differentiated,
is
you
know
the
the
parsing?
G
You
know
architecture
versus
then
you
know
how
the
semantic
is
driven
from
that
and
I
think
it
it
would
really
be
helpful
to
become
more
clear
about
you
know
what
parsing
we
think
is
feasible,
and
then
you
know
the
semantic
that
can
be
driven
from
that
separately
right
because
I
think
the
semantic
driven
from
that
is
getting
a
lot
closer
to
use
cases.
It's
not
only
about
what's
in
the
packet,
but
also
what
can
what?
E
So
the
problem,
I
think,
is
that
we
don't
want
to
be
prescriptive
about
how
people
you
know
do
that,
but
I
think
there's
a
number
of
this.
For
example,
I
mean
I'm
not
a
big
fan
of
the
multiple
gal
draft,
but
because
I
think
it
isn't,
you
know
set
up
to
why
it
should
be
or
why
muscle
gals
are
interesting.
E
E
You
know
15
years
ago,
and
I
think
those
are
the
kind
of
things
that
we
should
re-revisit
and
address
and
say
some
of
the
things
that
have
been
written
down
may
not
apply
anymore,
and
so
those
those
are
the
kinds
of
things
that
I
would
like
to
capture,
not
that
we
come
up
with
a
fancy
new
architecture
and
definitely
not
that
we
come
up
with
a
way
of
doing
parsing.
E
But
what
we
capture
these
restrictions
that
we've
put
in
and
say
hey:
here's,
for
example,
the
earlier
discussion
on
readable
depth.
It
may
not
be
anymore
that
you
can
only
look
three
three
labels
deep,
but
if
you
do
look
beyond
that,
there's
a
there's
a
penalty
and
so
there's
a
value
to
optimizing
that,
but
it
doesn't
have
to
be
an
absolute.
G
I
think
the
one
one
of
the
problems
I've
been
seeing
with
with
the
data
plan,
whether
it's
mpls
or
ip
right,
is
that
the
way
we
really
specify
you
know
the
encode,
the
the
representation
of
a
header
on
the
wire
and
the
information
elements
in
it
is
ascii
art
right.
So
maybe
you
know
something
like
parsing
could
be,
maybe
better
word
for
that
would
be.
D
I
just
want
to
comment
that
this
idea
of
modeling,
the
the
format
of
the
data
in
a
packet,
was
proposed
recently
in
the
control
planes
by
tony
tony
p
at
idf.
So
the
idea
of
you
know
rather
than
writing
text-based
encoding
using
a
model
to
to
to
format
the
control
plane
packets.
Now,
if
the
data,
I
think
what
you're
saying
is
the
data
plane,
data
packet
also
can
follow
it's
interesting
proposal
and
yeah.
G
I
mean
so
so
the
one
way
I've
been
looking
at
it
is
just
look
at
the
you
know
way
on
how
you
can
specify
in
something
that
looks
a
little
bit
like
a
c
structure,
a
packet
header
parsing
in
p4,
which
is
also
very
much
an
abstraction
of
what
you
know.
An
implementation
which
might
be
quite
different
on
different
platforms,
would
do
underneath
it
right
and
that
particular
model
of
p4
isn't
really
well
suited
to,
for
example,
capture
something
like
a
variable
stack
that
we
have.
G
So
I
think
what
we
we
can
draw
some.
You
know
good
good
background
from
something
like
p4,
but
we
would
probably
have
to
come
up
with
something
ourselves,
and
I
think
what
tony
was
saying
is
something
which
you
know
would
allow
any
possible
packet
header
to
be
encoded,
which
might
be
good
thing
to
do,
but
obviously,
for
the
scope
of
mpls.
Maybe
we'll
have
something
more
constrained.
E
You
have
to
watch
the
fine
line
of
not
being
prescriptive.
So
yes,
p4
is
a
is
a
much
better
language
than
others
like
openflow
tried
to
be
many
years
ago,
but
we
have
our
own
way
of
doing
forwarding.
E
So
if
you
can
be
sufficiently
abstract-
and
you
can
say
this
is-
and
maybe
you
know
very
scoped-
I
mean
people
does
all
kinds
of
qualities,
but
if
you
scope
it
to
mpls
40,
yes,
I
understand
the
problem
exists
for
ipv
as
well,
especially
ipv6,
but
at
least
as
far
as
this
working
group
is
concerned,
if
you
scope
it
to
mpls
label
stack
processing
and
maybe
a
little
bit
beyond
the
label
stack
because
you
know
there's
stuff
beyond
that
and
if
you,
if
you
scope
it
to
that-
and
you
say
this-
an
informational
document-
not
not
a
standard
strike
yeah.
D
Okay,
we
still
have
five
minutes.
I
think
the
to
the
end
of
the
meeting
I
wanna
propose.
Maybe
do
we
want
to
hear
from
the
other
proposals
of
the
carrying
information,
the
label
stack
or
having
an
indicator.
There
were
at
least
one
or
two
other
ways
to
do
that.
D
I
can
poke
the
office
of
the
other
drafts
to
present
their
view,
or
we
can
follow
up
on
what
you
said.
Kuriti
is
take
a
step
back
and
see
a
genetic
way
to
solve
the
problem
rather
than
having
point
faces,
and
then
band-aids.
E
Yeah
I
mean,
I
think
it
would
be
useful
to
hear
from
the
other
authors,
but
you
know
we
don't
want
to
get
too
bogged
down.
You
know
getting
their
views
as
important
getting
their
specifics,
maybe
not
as
important
and
then
hopefully
we
can
step
back
and
say
e.
This
is
a
problem.
That's
worth
solving.
E
D
I'll
put
them
in
the
minutes
and
I'll
talk
to
you.
No
problem,
yeah,
okay,.
F
Just
one
thing:
we
talked
about
getting
the
coordinators
for
trek
one
and
track
two.
I
sent
out
the
mail
today
and
if
someone
is
interested,
please
talk
to
the
mpls
shares
or
yeah
talk
to
me.