►
From YouTube: MPLS WG Interim Meeting, 2021-05-20
Description
MPLS WG Interim Meeting, 2021-05-20
A
A
Okay,
let
me
share
the
agenda
that
was
composed
over
this
week.
Give
me
a
moment.
A
Great,
thank
you
so
much
for
confirming
okay.
So
as
usual,
we
have
okay,
we
have
our
start
page.
Then
we
have
the
design
team
page.
A
We
are
keeping
the
week
by
week
agenda
and
notes
as
well
as
the
recording.
So
you
know
how
to
find
them.
There
was
a
glitch
with
webex
invite
I'm
hoping
that
it
was
resolved.
I
know
that
the
mac
and
toilets
were
working
on
it.
I
don't
know
if
any
one
of
them
is
on
the
call
I
haven't
seen
so
they
can
comment.
A
Yeah
good
question:
I
know
there
was
a
bit
of
confusion
on
the
change
of
the
start
time.
Do
you
have
more
to
add?
Did
we
confirm.
B
B
A
A
B
When
I
told
mike
to
set
up
the
meeting,
I
used
4
p.m,
cet,
which
this
is,
and
I
should
have
used
4pmcest,
which
is
an
hour
earlier.
A
We
are
where
we
are
this
week.
What's
the
plan
for
next
week,
exactly
I
was
going
to
say
exactly
said
greatly
said
stewart.
So
are
we
planning
to
change
it
back
or
stick
with
us.
B
I
actually
would
like
to
change
it
back,
but
it's
not
something
that.
A
We
can
leave
it
as
a
poll
for
after
you
know,
if
you
will
okay
yeah.
D
Okay,
if
we
leave
it,
then
I'll
update
the
the
wiki
accordingly
and
send
that
as
email
just
to
reconfirm
now,.
B
A
Right
so
that
that
was
on
this
and
then
we
have
the
agenda
for
today.
The
first
will
be
discussion
that
stewart
will
drive.
He
has
published
an
interesting
draft.
I
am
maybe
midway
through
it,
that's,
but
so
he
will
be
presenting
that
next
and
then
we
have
an
action
item
from
previous
meetings
to
do.
A
Some
use
case
discussion
for
what
we're
tackling
in
these
design
meetings,
not
sure
if
we
can
converge
on
a
presenter,
and
the
last
was
a
request
from
from
song
to
present
his
his
already
existing
draft.
Now
any
anyone
anyone
wants
to
bash
this
agenda
or
update
speech.
A
A
A
A
No
okay
looks
good,
so
we
go
ahead
to
2a.
I
guess
before
doing
that
we
have
a
pointer
to
slides
here.
Are
these
the
latest
slides?
Did
I
hear
you
correct
stewart
say
that
you
will
be
updating
them?
No
wait.
Those
are
my.
B
With
the
ancillary
slides.
A
Okay-
and
you
want
me
to
open
those
or
you
want
to
go
ahead.
B
B
Oh
there
they
are
okay,
okay,
so
if
I
started
to
think
about
what
the
relationship
between
indicators-
that
is
something
in
the
stack
that
tells
you
that
you
have
something
after
the
stack
that
you
need
to
take
care
of,
and
I've
started
to
think
about
what
do
we
really
want?
So
if
you
look
at
the
second
from
the
left,
I
think
this
is
where
we
actually
started.
We
have
one
indicator
in
the
stack
and
then
we
have
data
after
the
boss
that
we
need
to
take
care
of
the
first.
F
A
Are
self-contained?
Really?
That's
not
what
no?
No,
that
that
what
steve
said
is
both
are
accurate.
I
mean
there
are
cases
where
everything
would
be
contained
within
the
stack
and
he
had.
I
thought
kiriti
was
on
the
call,
so
he
would
interject,
but
there
were
cases
where
he
had
something
that
would
come
or
an
indicator
to
to
process
something
after
the
bottom
of
stack.
B
B
A
Don't
have
to
be
right,
at
least
that's
where.
B
So
the
fourth
one
is
something
I
want
to
want
to
discuss
if
it's
possible-
and
that
is
that
you
have
two
different
indicators
in
the
stack
and
you
have
two
different
sets
of
data
after
the
stack
that
you
need
to
take
care
of
before.
D
You
before
you
go
there
can
I
just
for
number
three
reconfirm
that
we
have
evidence
or
that
somebody
chimed
in
and
said
there
is
evidence
of
of
this
insofar
as
that
they're
not
numbered
right.
So,
but
I
guess
the
point
would
be
that
the
lower
indicator
would
be
too
far
in
the
stack
to
to
search
it.
F
Or
more,
not
necessarily
too
far,
but
I
think
it's
more
expensive.
So
I
think
that
the
what
we
were
being
told
last
week
was
that
sometimes
you
you
may
be
able
to
get
to
the
bottom
of
stack.
You
may
be
able
to
look
at
everything,
but
it
might
be
expensive.
You
take
a
cash
hit
or
something
or
other
okay.
So
in
some
cases
you
it's
helpful
to
have
a
a
an
indication
early
on
whether
or
not
you
need
to
go
and
search
the
stack.
Sorry,
it's
not
shirts
to
stack
or
anymore.
F
It's
read
the
stack,
isn't
it
greg
greg.
D
But
but
my
my
my
question
I
wanted
to
ask
is:
do
we
have
an
indication,
you
know
or
or
degree
of
of
the
problem?
If
we
already
need
to
search
for
bottom
of
stack
right
because
we
are
searching
for
a
bottom
of
stick,
you
know
it's
the
you
know
additional
searching
for
the
deeper
indicator
and
additional
pain.
F
This
is
about
not
searching
unless
you
have
to
that's,
why
they've
done
it,
no.
D
No,
but
wait
a
second
so
in
this
particular
case
in
number
three.
The
assertion
is
that
we
will
need
to
look
for
the
ancillary
data
anyhow
yeah.
Yes,
yes,
but
it
could
be
quite
expensive
to
look
for
it
right,
but
what
I'm
saying
is
if
you
need
to
search
for
the
answer,
you're
you're
right
in
so
far
as
that
we
don't
know
off
the
top
of
our
head,
whether
we
need
to
look
for
an
indicator
right.
But
if
we're
saying
well,
you
know
we
need
to
look.
F
G
D
No,
no
and
understand
the
issue.
What
I'm
saying
is:
do
we
have
an
indication?
Okay,
so
there
are
two
issues
right
seeking
in
general
and
we're
going
to
get
to
that
right.
So,
but
I'm
saying
if,
if
you
already
are
seeking
at
least
to
bottom
off,
stack
right,
if
you're
not
going
to
get
rid
of
of
of
seeking
to
searching
for
bottom
of
stacks,
no,
they
don't
always.
D
F
Some
people
found
it
very
expensive
to
go
to
the
bottom
of
stack
and
do
the
five
tuple,
but
they
were
saved
by
the
fact
that
by
this
stage,
we'd
already
invented
entropy
labels,
so
in
segment
routing
ordinary
segment
routing
there
is
no
need
to
search
for
anything
other
than
the
entropy
label
and
the
what
the
entropy
label
people
did
was
to
put
one
earlier
in
the
stack
so
that
you
didn't
have
to
do.
The
cache
miss.
C
D
D
F
Saying
that
in
I
don't
know
I
was
missing,
I
was
missing
another
one.
If
lower
had
made
the
first
one
have
no
orange
in
it,
then
you
would
never
have
had
to
do
anything
other
than
look
at
the
top
label.
True.
A
A
But
if
I
have
the
stack,
the
full
stack
yeah,
I
need
to
parse
it
to
find
the
right.
You
know
indicator
and
flags
and
so
on.
Well,.
A
Yeah,
you
know
that
the
point
is
that
this
one
is
closer
to
the
top,
so
parsing
it
will
be
less
expensive.
That's
what
I'm
trying
to
answer
yeah.
D
F
F
D
It
if
we
need
to
have
an
indicator
right
then
you're
right
if
having
the
indicator
earlier
on,
is
a
way
to
ensure
that
we
wouldn't
need
to
search
that
deep
in
stacks
that
don't
have
indicators.
But
all
I'm.
D
That,
when
we
do
have
or
indicators,
we
don't
care
about
right.
But
if,
if
we
have
indicators
in
the
stack,
then
isn't
the
overwhelming
cost
here
to
to
search
for
bottom
of
stack.
D
That's
what
I'm
thinking
about
okay,
so
I
did
send
I
think,
last
week
or
so
a
couple
of
more
detailed
question
in
that
respect
for
lois
draft,
I'm
not
sure
if
he
has
found
the
time
to
incorporate
them,
and
so
that's
that's
exactly.
You
know
these
relative
costs.
That
would
be
better.
It
would
be
very
good
to
understand
and
and
see
that,
for
example,
what
you
said
stewart
searching
for
the
bottom
of
stack
is
the
most
expensive
operation
that
whether
we,
for
example,
can
come
to
agreement.
I
I'm.
A
I'm
hearing
different
from
you
know
unless
I'm
misreading
ignace
he's
basically
citing
what
I
said
that
parsing
is
expensive,
more
expensive
than
finding
the
bottom
of
sack.
A
Do
you
think
that
is
we
can
take
an
action
night
and
then,
with
your
question
here
in
terms.
F
Now
he's
right,
ignorance
is
right
because
to
find
an
indicator,
I
have
to
check
the
value
of
the
thing,
whereas
to
find
bottom
stack,
I
only
have
to
find
a
one
bit,
although
I
do
have
to
do
a
or
an
end
operation
on
each
of
the
stacks
to
do
it.
It.
G
Seems
like
the
same
type
of
match,
operation
same
thing
for
passer.
It
doesn't
matter
if
you
look
a
particular
value
to
pass
a
word
or
look
a
particular
bit.
I
mean
what
I
mean
here
is
that
if
you
think.
G
Bottom
stack
is
expensive,
then
you
can
you
know
in
the
indicator,
you
can
add
extra
information
to
tell
you
where
you
find
can
find
the
bottom
stack
all
the
data
after
the
button.
H
Colleagues
basically
comment
that
is
far
most
of
the
implementation
aspects,
so
it
depends
if
you
do
horizontal
vertical
processing,
if
that's
horizontal
in
in
one
register
and
you
fit
all
of
your
labels,
checking
for
the
bottom
of
stack
bit
is
not
expensive.
H
H
Processing,
it
is
expensive.
That
means
you
need
in
general,
one
memory,
access
per
one
label,
and
that
is
really
expensive.
H
I'm
talking
about
the
generic
compute
platforms,
any
x86
platform,
which
is
available
over
the
last
10
years.
He
has
256
bit
registers,
you
just
need
to
use
that
and
your
data
needs
to
be
friendly
for
those
registers.
The
cost
of
accessing
32-bit
label
or
128-bit
label
is
the
same
if
they
are
friendly
to
those
registers.
D
Well,
what
you're
just
saying
is
that
if
you
can
process
a
certain
limited
label
stack
with
all
the
labels
in
parallel
because
they're,
let's
say
128
or
256,
then
I
would
also
contend
that
the
search
for
an
indicator
would
be
the
same
as
the
search
for
a
boss
within
that
paragraph.
Well,.
F
G
So
in
case
of
p4
programming,
that's
the
exactly
same
when
you
program
the
password.
It
doesn't
matter
if
you're
looking
for
a
word
or
a
bit.
F
Hang
finding
one
particular
value
of
a
number
of
bits
is
fine,
but
indicators
may
be
a
range
of
values
depending
on
how
how
we
do
it,
whereas
bottom
stack
is
always
just
one
bit.
G
Yes,
but
in
terms
of
password,
it's
just
more
branches
in
the
passing
graph.
But
still
you
know.
D
No,
I
I
I
I
I
think
I
take
that
from
from
from
ignace,
so
so
so
lower.
I
I
think,
would
be
good
if
we
can
basically
try
to
capture
these
things
in
in
your
questionnaire
document.
Right.
B
Okay,
yeah,
I
would
try
to
do
that.
The
the
thing
I
wanted
to
illustrate
is
a
little
bit
less
detail
than
what
you're
discussing
now.
What
I'm
saying
is
that
in
the
third
dot
case
there
is
a
rule,
you
can
only
have
one
indicator,
even
if
you
repeat
it.
So
when
you
find
the
first,
you
can
look
for
the
bottom
of
stack
in
the
fourth.
There
are
there.
A
F
Well,
it
depends
it
depends
what
you're
trying
to
say
right,
and
I
think
you
know
I
get
into
a
lot
more
detail
later
on
right,
but
I
think
supposing
one
is
saying,
or
for
example,
no
fast
reroute
and
another
one
is
saying:
latency
based
performing
parameters,
you
probably
need
both
of
them.
Don't
you.
D
Think
so
I
think
that
number
four
is
exactly
the
example
that
basically,
we
can
be
used
for
the
argument
we
had
on
number
three
right,
which
is
that
searching
for
multiple
indicators.
The
reason
why
searching
for
indicators
may
be
most
likely
be
more
difficult
or
expensive
than
searching
for
bottom-up.
D
A
Okay
differently,
low
and
tourless,
I
look
at
it
as
the
blue
is
applicable
to
any
node.
You
know
until
you
reach
the
top
label,
you
know,
and
and
the
orange
is
applicable
to
this
segment
behind
it
right
this
label.
L,
but.
D
That
wouldn't
be
the
logic
if
orange
would
be
entropy
spl.
A
No,
I'm
not
saying
entropy,
I'm
saying
actions
genetic
connection,
so
whatever
actions
are
in
the
blue,
whatever
actions
are
in
the
blue
are
applicable
to
this
effect.
A
A
Anywhere
I
mean
I
mean
people
have
put
the
eli
el
closer
to
the
vpn
label,
so
that
you
know
it
doesn't
care
about
the
transport
label.
If
you
have
multiple
or
no.
D
A
I
I
what
I'm
trying
to
say
is
you
know
if
you
want
the
entropy
to
be
applicable
end
to
end
lsp
end
to
end
you
better,
maintain
the
entropy
all
the
way
till
you
reach
the
end.
The
end
point.
D
Was
trying
to
get
to
the
point
that
if
we
want
to
seek
for
multiple,
I
think
we
agree
that
it
most
likely
is
more
expensive
than
seek
for
an
individual.
D
G
My
opinion
is
that
you,
you
guys,
keep
saying
that
parsing,
the
entire
labor
stack
is
defensive,
but
I
said
it's
no
sad
case.
I
I
don't
think
parsing
the
label
stack
expensive,
but
the
processing,
the
data
after
it
is
more
actually
much
more
expensive.
G
If
you
look
at
how
the
processor
is
implemented,
it's
a
it's
always
pipelined.
You
have
a
parsing
graph,
you
just
read
the
each
field,
a
header
by
header,
or
here
is
label
by
label.
You
might.
If
you
have
a
deep
label
stack,
you
might
slightly
increase
the
total
passing
latency,
but
that
won't
affect
the
person's
throughput.
G
You
will
still
basically
have
one
one
cycle
per
packet
throughput.
So
so
my
my
point
is.
F
F
D
G
F
F
G
Cycle
throughput
notes,
one
cycle.
Latency
I
mean
you
can
depends
on
the
depth
of
the
label
stack.
You
have
a
longer
latency,
but
since
you
have
a
pipeline,
then
you
you
can
do
that
in
basically
per
second.
You
will
finish
passing
one
package,
but
the
question
is:
how
many
pipeline
steps
can
you
afford?
That's
a
depend.
Difference
of
chip
by
cheap,
like
some,
for
example,
the
the
the
barefoot
chip
claim
is.
I
I
remember
it
it's
more
than
500
bytes.
You
can
develop.
D
D
Can
parse
that
depth?
Yes
exactly,
but
that
does
that
isn't
related
to
to
to
the
number
of
sequential
steps
in
your
parsing
definition,
if
you
have
basically
parsing
chain
of
you
know
effectively
five
headers
after
each
other,
that's
basically
means
you
have
a
pipeline
depth
of
five.
It
has
nothing
to
do
with.
F
F
So
is
that
so
I
think
the
requirement
has
to
be.
Can
I
have
multiple
elements
of
auxiliary
data
and,
if
I
do,
how
do
I
know
which
ones
apply
to
me?
A
I
I
can't
edit
the
the
slide,
but,
but
there
is
a
there
is
a
case
where
you
know
the
indicator
has
data
and
you
know
inside,
and
it
doesn't
need
any
anything
after
the
bottom
of
stack.
That's
correct!
There
are
two
approaches
to
do
that.
Yes
right
so,
and
in
that
case
you
know
it
goes
back
to
the
column
number
four.
I
can
have
a
blue
and
an
orange
where
the
where
the
actions
inside
the
blue
are
different
than
the
orange,
and
I
really
could
care
less
about
them.
A
Bits,
actually,
we
I
mean
and
kirit's
draft.
He
said
that
I
can
have
an
indicator
which
is
32
bits
and
in
in
in
it's
you
know
I
can
follow
it
up
with
another
label.
So
it's
an
extended
type
of
thing
so
either.
A
F
A
Oh
okay,
yeah,
but
my
point
is
I
mean
there
are
cases
where
column
one
with
multiple
indicators
in
it
multiple
indicators
right,
it's
it
doesn't
have
any
ancillary
data
after
the
bottom
stack
and
it's
true
what
stewart
said
you
can't
do
the
elaborate
you
know
time:
stamping
inside
the
label
stack-
and
you
know
I
mean
so
so.
B
Tarek,
could
you
have
one
combination
between
one
and
four.
F
A
Yeah,
I
mean
very
obvious
use
case
that
we
already
have
you
know.
A
couple
of
drafts
on
an
mpls
working
group
is
carrying
the
slice
identifier,
which
is
you
know,
varying,
maybe
16,
bits
or
or
so,
and
and
that's
supposed
to
be
contained
inside
the
label
stack.
So
I
don't
need
a
pointer
to
go
and
fetch
it
after
the
bottom
of
stack.
A
That's
one,
maybe
carrying
a
path
identifiers,
you
know,
for
an
sr
path
could
be
another
one,
and
there
were
some
flags,
as
was
mentioned
about
our
flag,
and
I
mean
yeah.
That's
it.
B
So
but
I'm
trying
to
to
put
the
question
in
some
way
what
is
allowed.
F
B
F
B
B
B
B
Okay,
and
then
I
think
that
tarik
says
that
okay,
we
can
have
number
four,
but
we
can
also
have
indicators
that
don't
have
any
auxiliary
data.
A
Sure,
no
problem,
what
I'm
saying
is
two
cases
are
missing
here
in
in
you
know,
and
these
are
the
two
cases
one
one
is
the
on
the
one
on
the
left
here,
where
you
repeat
the
indicator,
and
you
don't
have
anything
after
the
us
and
this
repetition
is
just
so
that
you
know
you
help
the
hardware
find
the
indicator
and
actions
closer
to
the
top
here.
It's
actually
they
are
different.
G
I
I
think,
there's
a
yes
another
case
missing
here.
All
these
cases
here
implies
that
the
indicator
is
associated
with
the
label
in
front
of
it
or
and
also
for
the
later
three
cases.
It
also
implies
that
one
indicator
is
just
associated
with
one
data.
G
H
F
Can
I
suggest
that
we're
doing
this
the
wrong
way
right?
We
should
start
off
understanding
what
information
we
want
to
carry
in
the
stack
itself,
not
the
indicators
or
anything,
but
what
technical
information
we
want
to
carry
in
the
stack
other
than
pointers
to
fib
entries,
and
we
should
understand
what
data
we
want
to
carry
after
the
stack.
F
A
F
A
A
B
B
A
Some
text
I'm
willing
to
volunteer,
but
if
more
volunteers
can
come
up,
you
know
I
want
to
give
chance
for
other
people
to
contribute,
but
I'll
I'll
try
to
help
as
well.
D
Well,
I
I
laura:
what's
what's
what's
your
plan
with
the
question
document
right,
that's
where
I
thought
contribution
would
start
first,
because
it's
more
general,
as
opposed
to
you,
know,
trying
to
come
up
with
the
solution
pieces.
This
is
looking
more
like
exploring
the
whole
solution
piece
and
that
might
become
very
large
if
we
can't
limit
it
up
front
by
by
the
answers
to
the
questions.
Well,.
B
B
B
D
A
A
The
options
towards
this,
I,
what
I
heard
steven
say,
is:
what
data
do
you
want
to
carry
inside
the
label
stack
and
what
data
you
would
like
to
see
after
the
label
after
the
bottom
of
stack,
so
starting
from
what
is
it
that
you
want
to
carry
inside
and
what
is
it
you
want
to
carry
out.
F
E
B
A
Okay,
I
do
want
to
give
a
chance
to
steward.
Is
it
the
right
time?
Are
we
done
with
this
lower
with
this
step.
A
A
Okay
I'll
pass
the
ball,
then,
to
stewart
to
talk
about
the
the
pointer
data
pointer
and.
F
Okay,
so
hopefully
I
am
sharing
the
right
screen.
Am
I
yeah
yeah
yeah,
okay,
so
so
what
this
is
about
is
noting
that
with
kiriti's
spare
bits
we
can
construct,
we
can
use
them
as
pointers
and
looking
at
some
of
the
consequences
of
that,
how
do
I
get
to
the
next
one?
F
Let
me
go
to
here
right,
so
background
motivation.
So
there
are
certain
cases
that
benefit
from
my
ancillary
data
and
I'll
explain
later
on
why
I
use
the
I've
been
using
the
term
ancillary
data
which
needs
to
be
processed
or
accessed
as
part
of
the
forwarding
decision.
F
So
our
problem
is
to
decide
how
to
add
that
information
to
mpls
packets
that
it
in
a
way
that
is
suitable
for
efficient
high
speed,
forwarding
easy
for
more
the
more
modern
hardware
to
add
this
feature,
but
back
was
compatible
in
terms
of
at
least
the
basic
forwarding
operations
with
legacy
hardware.
F
So
the
approaches
we've
had
so
far
have
been
really
around
putting
indicators
in
the
in
the
stack
to
so
right.
The
approach.
So
if
I
rely
on
the
forwarder
finding
out,
if
there's
any
applicable
ancillary
data
below
the
blossom
of
stack
and
deciding
which
of
the
ancillary
data
applies
to
this
hop,
so
it's
not
clear,
sometimes
in
some
of
the
things
we've
discussed
in
various
places.
F
How
I
know
whether
this
particular
piece
of
below
the
bottom
of
stack
information
applies
to
me
at
this
hop
some
of
the
methods
make
it
easier
to
use
this,
but
some
of
them
don't
none
of
them.
I
think
deal
particularly
well
with
ancillary
data
is
that
is
at
different
hops.
So
if
you
have
three
bits,
two
bits
of
ancillary
data-
and
one
applies
at
hot
one
and
three
and
the
other
at
hop
two.
Only
for
example,
then
it's
some
of
these
methods
are
require
more
sort
of
implicit
deduction
than
explicit
instruction.
F
So
here's
what
we
thought
right.
So
if
we
can
use
the
so-called
spare
bits
in
the
top
top
of
stack
label
as
a
pointer
to
auxiliary
data
applicable
at
this
hop,
so
the
semantic
is
process
as
described
by
label,
one
top
of
stack
using
the
information
pointed
to
by
label
two
and
note
that
you
can
point
to
anywhere
inside
that.
If
we've
got
enough
bits
we'll
be
able
to
point
to
anywhere
inside
that
ancillary
data,
if
there
is
not
a
pointer
label
at
label
2,
then
you
just
forward
exactly
as
you
would
before.
F
Equally
well,
you
forward
exactly
as
you
would
before.
If
you
don't
understand
the
pointer
mechanism,
so
a
legacy
router
would
look
at
top
of
stack
and
continue
using
that
effect,
none
the
wiser
about
what
else
it
was.
It
was
finding,
but
a
a
a
a
router
that
understood
this
would
say:
oh
there's
a
pointer
or
no,
there
isn't
a
pointer,
so
I
just
carry
on
as
if
they're
with
what
I,
what
the
top
of
stack
tells
me
to
do.
F
F
We
already
had
extensive
discussions
about
the
expense
of
parsing,
the
ability
to
specify
which
ancillary
data
is
applicable
to
this
particular
forwarding
label.
There
are
no
deductions
or
I'm
sure
what
the
other
website
there
are.
No
deductions
inside
the
the
paths
are
needed.
So,
for
example,
if
you
look
at
the
way
an
extension
header
mechanism
is
worked,
it
is
worked.
You
kind
of
have
to
deduce
which
bits
of
it
apply
to
you
and
I
think
it's
quite
a
general
and
extensible
technique.
B
F
Get
there
oh
okay,
all
right,
I
mean
I,
I
do
eventually
get
there
right,
so
it's
a
sort
of
a
didactic
explanation
in
the
sense
that
this
is
how
we
thought
of
it
and
then
how
we
sort
of
added
to
it.
So
the
the
we've
done
that
one.
So
my
assumption
for
this
point
in
the
in
the
discussion
is
that
the
pointer
will
be
some
function
of
a
special
purpose
label.
All
right.
F
We
could
make
the
top
two
labels
a
a
tuple
that
is
sort
of
the
way
that
yakov's
approach
was
where
you
see
the
first
label.
You
know
that
the
second
one
is
some
piece
of
metadata
or,
in
my
case,
appointed
to
a
metadata,
but
that
has
some
some
problems.
We
need
to
change
the
fact
of
the
top
stack
to
do
that.
F
We
no
longer
have
full
legacy
compatibility,
at
least
on
the
top
label,
and
we
need
more
labels
in
the
global
label
table
because
we
will
need
labels
for
effect
with
and
without
the
pointer
mechanism
to
follow,
and
the
problem
with
that
is
not
only
is
it
is
the
increasing
cost
of
distribution
of
the
labels
in
the
management,
but
I'm
particularly
concerned
that
some
lsrs,
particularly
pe
lsrs,
are
already
saturating
the
global
label
table.
That
was
an
issue
we
thought
we
found
in
sudowers
where
people
were
saying.
F
Actually,
you
know
we
need
more
than
we
can
get
in
the
million
in
in
the
label.
Space
we've
got
available,
so
we
do
indeed
we
do
look
at
an
alternative
and
rather
controversial
approach
later
in
the
draft.
F
So
this
is
what
I
had
in
mind
in
terms
of
a
pointer
lse
all
right,
so
we
have
a
label,
that's
the
trigger
label.
That's
probably
you
know
that's
possibly
an
spl
a
naught
to
16,
but
it's
the
trigger
is
the
important
thing
the
pointer
is.
I
I
sequestered
the
the
ttl
are
in
proposing
me
sequestered
the
ttl,
the
flags.
I
have
one
use
for
a
flag,
which
was
whether
I
was
going
to
point
in
in
units
of
an
octet
or
point
in
units
of
well.
F
I
said
16
bits,
but
I'm
not
sure
whether
that
shouldn't
be
32
bits.
The
problem
with
pointing
in
anything
other
than
octets
is
that
you
need
to
put
padding
in
the
in
the
auxiliary
data,
but
that's
all
in
the
noise
compared
to
the
you
know
the
content.
The
concept
is
that
I
point
to
what
I
want
to
do
rather
than
infer
where
it
is,
which
instance
of
it
is,
and
what
I'm
supposed
to
do
with
it.
F
So
the
the
first
thing
to
do
is
to
note
that
you
can
have,
of
course,
multiple
pointers
pointing
to
the
same
element
of
of
ancillary
data.
So
this
would
be
how
you
might
construct
a
a
segment
rooted
system,
but
don't
don't
worry
we
we,
we
got
some
more
stuff
later
on
right.
This
is
how
you
do
a
second
root
system,
so
they
come
in
tuples
really
and
you
would
have
to
pop
the
top
of
stack
and
the
pointer
and
but
each
of
the
pointers
points
to
the
same
piece
of
ancillary
data.
F
That'd
be
more
efficient,
and
this
is
kind
of
the
thing
that
gets
into
us
into
the
all
the
areas
where
we
were
having
trouble
in
the
in
discussion
with
lower
if
you
can
have
a
single
pointer
that
refer
that
is
used
by
multiple
labels.
F
So
the
sort
of
mechanism
that
I
was
looking
at
here
is
that
I
have
a-
and
I
need
a
better
word
for
it-
that
we
have
a
different
sort
of
swap
operator
within
the
stack.
So
what
I
would
do,
if
you'll
notice
here
is
I'm
going
to
pop
label,
one
that
leaves
label
two
at
the
top
of
stack,
which
it
can't
be.
F
So
I
really
need
to
swap
label
three
and
label
two.
You
know,
and
this
allows
a
method
of
encoding,
a
pointer,
that's
common
to
a
number
of
top
of
stack
labels
in
the
in
the
in
the
label
stack
without
burning
up
double
the
number
of
labels
in
the
stack
to
encode
it,
which
is
the
obvious
and
simple
way
to
do
it
for
segment
routing.
F
So
it's
more
efficient
in
stack
space,
it's
a
slightly
more
complex
pop
operator
and
we
do
need
to.
We
would
need
to
do
a
correction
to
the
pointer,
although
tallis
was
put
was
suggesting
that
if
the
pointer
was
relative
to
bottom
of
stack,
we
but
but
that
requires
us
to
find
the
bottom
of
the
stack,
but
if
it
were
relative
to
the
bottom
of
stack,
that
might
be
a
different
approach
that
doesn't
need
the
correction,
but
that
means
we
have
to
find
bottom
of
stack
ourselves.
F
So
the
problem
we
need
we
have
with
this
is:
how
do
we
stop
propagating
the
pointer?
So
we
could
have
a
sort
of
a
ttl
in
the
pointer.
It
says
how
many
times
you're
going
to
do
this
propagation.
We
could
have
a
bit
in
the
top
of
stacked
label.
Perhaps
we
could
have
a
different
effect
for
the
top
and
stable
act
which
I
don't
like
doing
or
we
could
have
a
another
label
in
the
stack
that
says
when
you
get
here
pop
the
pointer
as
well.
So
there's
a
number.
F
This
is
work
in
progress,
very
much
working
progress,
but
I
wanted
to
get
to
people
to
understand
that
pointers
have
all
kinds
of
interesting
properties,
so
we
can
have
multiple
pointers.
Clearly,
I
think
you,
this
is
your
question:
wasn't
it
lower?
So
we
might
put
a
point,
for
example,
latency
based
forwarding
information
and
iom
iom
and
lbf
are
probably
too
big
to
go
in
the
stack
itself.
F
I
think,
and
you
would
treat
those
as
a
as
a
group
for
all
of
those
operators
that
I
was
talking
about
before,
so
you
would
pop
toss
one
and
pointer
two
as
a
group
or
you
might
do
a
group
swap
where
you
move,
where
label
four
came
to
the
top
of
stack
and
labeled
two
and
three
slid
down
one
when
you
popped
label
one.
I
think
people
probably
understand
the
the
issue.
F
Okay
and
of
course
one
of
the
things
about
this
is
that
in
some
cases
you
might
want
to
use
a
piece
of
ancillary
data
on
more
than
one
hop
and
in
other
cases
you
might
want
to
use
different
pieces
of
ancillary
data,
and
this
allows
you
to
have
whatever
mix
and
match
you
want
now
before
people
say.
Oh,
this
is
way
too
complicated,
etc.
F
The
mark
of
a
good
design
is
that
anything
you
ask
it
to
do.
It
can
just
do,
and
I
I
doubt
that
we
would
have
this
sort
of
complexity
very
often,
but
if
we
wanted
to
have
it,
we
needed
to
have
a
real
application
for
it.
Then
we
could
incorporate
it.
F
So,
a
few
details,
one
of
the
things
that
we
need
to
to
talk
about
which
we
haven't
talked
about
today
at
all-
is
disposition.
F
Ancillary
data
needs
to
be
removed
before
the
payload
is
passed
out
of
the
domain,
and
this
can
be
a
lot
more
complicated
than
just
throw
away
some
number
of
bytes,
for
example,
we
might
need
to
specially
dispose
of
the
iom
data
in
a
particular
way,
or
we
may
need
to
do
some
special
disposition
function
on
the
packet
itself.
For
example,
if
what
we
had
was
a
pseudo
wire,
we
may
have
to
rebuild
the
the
real
payload.
F
We
could
have
a
special
purpose
label
at
the
bottom
of
stack.
That's
something
else
that
we've
talked
about,
or
we
could
use
a
pointer
at
the
bottom
of
stack
to
point
to
some
auxiliary
data
that
describes
the
disposition,
and
I
think
that
is
also
quite
a
powerful
approach.
That
tells
you
what
you
would
need
to
just
discard
what
you
would
need
to
analyze
what
you
would
need
to
pass
to
another
entity,
for
example
the
iom
handler,
and
what
you
would
need
to
do
to
reconstruct
the
packet
for
instance.
F
So
it's
a
very
powerful
approach
to
have
a
disposition
and
set
of
ancillary
data
pointed
to
by
the
by
a
label
at
the
bottom
of
stack.
F
So
what
about
this
is
my
sort
of
controversy?
Sort
of
point
right,
so
spls
are
in
very
short
supply
we'd,
rather
not
use
an
espl
unless
we
had
to
so
the
question
I'm
asking
is:
can
I
use
a
regular
label
as
a
pointer
label?
So
I'm
not
talking
about
global
labels.
In
the
sense
people
have
talked
about
global
labels
for
years
right.
I'm
talking
about
the
case
where
we
have
a
small,
tiny
number
of
network
wide
agreed
labels
that
are
specially
recognized
by
the
forwarder.
F
These
labels
will
not
go
to
the
fib;
they
will
be
handled
like
a.
They
should
be
handled
like
a
regular
spl,
so
don't
take
them
to
the
fib,
just
treat
them
as
a
normal
label
that
you're
going
to
handle,
especially
because
you
know
about
it.
So
what
would
we
have
to
do
to
that?
Well,
when
clearly,
we
have
to
modify
the
forwarder,
but
not
sort
of
greatly
compared
to
what
we
do
at
the
moment.
F
The
big
problem
is
that
we'd
have
to
modify
the
label
manager
because
the
label
manager
would
have
to
not
allocate
these
labels
now.
F
Clearly,
we
only
have
to
allocate
do
this
to
some
label
managers,
because
in
some
cases
the
labels
are
not
used
in
the
router
at
all,
because
this
is
this
business
we
found
in
sr
where
different
global
label
bases
were
were
different.
So
if
the,
if
the
regular
label
used
for
this
purpose,
is
below
the
label
base,
that's
just
a
forward
or
action.
F
If
it
is
above
it,
then
we
then
there
is
some
work
to
exclude
these
from
normal
allocation,
but
I'm
going
to
contend
that,
although
that's
hard
work
in
the
sense,
it's
work
to
be
done.
It
is
not
computationally
hard
or
intellectually
hard
and
of
course
we
can
use
this
with.
You
can
do
some
combination
of
spl
and
this
technique.
I
don't
know
whether
this
would
fly,
but
it's
worth
thinking
about,
because
spls
are
short.
F
And
finally,
why
have
I
been
calling
this
ancillary
data?
So
I
went
to
my
standard
place
to
go
and
look
up
terms
is
the
oxford
english
dictionary,
so
I
went
and
looked
up
metadata,
and
this
is
data
whose
purpose
is
to
describe
and
give
information
about
other
data-
that's
not
really
what
we're
doing
here.
F
So
I
then
looked
up
auxiliary
data,
which
is
a
helpful
assistant,
affording
aid
rendering
assistance
and
giving
support,
etc.
Well,
that
sounds
better,
but
actually
ancillary
is
the
best
one
of
all,
because
this
is
designating
activities
and
services
that
provide
essential
support
to
the
functioning
of
a
central
service
or
industry.
So
I
think
ancillary
data
is
the
right
term
not
going
to
die
in
a
ditch
about
it.
But
that's
where
I
got
the
term
from
and
that's
the
end.
A
I
have
a
question
first,
thank
you
for
the
very
good
presentation.
Stewart
there
is
a
slide.
They're
not
numbered.
I
don't
show,
I
don't
see
a
number,
so
I
can't
sorry.
A
Multi-Pointer
slide
that
one
yeah
that
will
do
the
idea
is
that
you
have
a
a
pointer
label,
multiple
pointer
labels
back
to
back.
F
F
Do
the
instruction
pointed
out
by
toss
the
top
of
stack
l1,
which
may
be
which
is
usually
forward
and
get
closer
to
somewhere,
but
it
has
all
the
mpls
semantics
it
could
have
assisted
by
the
information
pointed
at
by
0.1
and
also
assisted
by
the
information
pointed
at
by
pointer
to,
and
I
make
no
the
art
the
architecture
if
you
like,
the
philosophy
has
just
got,
has
just
gone
from.
F
A
Is
fine?
I
understand
that
my
question
is
you
you're
can?
Can
we
consider
this
as
a
one
pointer
label
it
which
is
composite,
and
the
reason
I
ask
is
because
you
know
and
again
in
kiriti's
proposal,
we
thought
that
we
only
need
one
spl
label.
That
says
this
label
is
a
composite.
So
it's
a
top
again.
It's
a
tuple
becomes.
F
Supposing
you
wanted
to
do
iom
on
some
parts
of
the
the
path
but
lbf
on
all
parts
of
the
path,
so
you
want
to
do
you're
debugging
an
lbf
problem,
so
you
need
pointer
one
everywhere,
but
in
some
cases
you
need
pointer
one
and
pointer
two,
because
what
pointer
two
is
saying
is
tell
me,
you
know
what
is
recording
the
packets
and
parameters
here,
because
I
can't
find
out
why
this
thing's
not
getting
through
in
time,
for
example,
so
and
I'm
sure
that
you
know
once
we
have
this
concept,
we'll
find
all
kinds
of
cool
things
to
do
with
it.
D
Can
I
just
add
one,
you
know
big
benefit
that
I
think
you
know
wasn't
highlighted
very
much,
because
I
think
we
all
started
from
putting
together
how
well
this
helps
avoiding
the
scanning
right.
But
I
think
the
other
big
thing
that
we
hadn't
gotten
to
in
in
the
in
the
second
track
is
how
do
we
structure
ancillary
data?
You
know
when
it
is
different
blocks
which
may
be
variable
size.
D
D
You
know
ancillary
data
blocks
right
so
I
mean
I
could
basically
take
any
existing
ipv6
extension
header
and
make
it
one
of
the
ancillaries.
F
D
F
Are
absolutely
correct
that
pointer
two
could
be
into
an
existing
extension
header
in
the
payload
itself,
yeah.
D
It
I
mean
whether
or
not
we
want
to
go
beyond.
Let's
say
a
big
blob
of
multiple
components
of
ancillary
data,
specifically
for
mpls
or
beyond.
That's
advanced
right,
but
even
just
the
fact
of
do.
We
need
to
come
up
with
a
new
structure
to
link
multiple
ancillary
blocks
with
each
other.
We
don't
need
that
layer
of
complexity
here
when
we
already
have
the
pointers
in
the
label
stack.
D
And
it's
a
simplification
of
just
take
any
sequence
of
ancillary
data
blocks
that
may
even
come
from
different
places
right
so
hey.
I,
like
this
extension
header
that
maybe
ieee
did
fine.
It's
an
accidental,
redata
block,
I'm
pointing
to
right.
So
I
mean
there
are
these
two
big
blobs
of
of
benefits
that
this
approach
brings
right.
One
is
get
rid
of
the
scanning
which
you
know
cannot
be
parallelized,
because
it's
it's
it's
a
sequential
pipelining
operation
and
the
other
one
is
the.
G
But
let
me
give
you
a
potential
disadvantage
of
using
a
pointer
here,
because
the
data
could
be
could
change
its
size
during
the
transmission
and
also.
F
F
How
does
it
change
its
size
without
stripping
the
entire
stack
off
and
rebuilding
it?
I
oem,
for
example.
Oh
well
probably
you
would
point
you
would
point
to
the
ioam
block,
but
the
ion
block
is
not
going
to
yeah.
G
F
G
Why,
if
I
just
keep
the
you
know,
I
don't
keep
the
pointer
to
each
block.
I
just
tell
you
where
the
bottom
stack
is
then
I
just
use
a
you
know,
change
all
the
block
together.
Then
I,
if
I
change
the
size
of
one
block,
it
doesn't
change.
Anything.
Excuse
me,
excuse
me,
how
do
I.
F
D
I
I
think
we
understand
what
what
forwarding
plane
hardwares
can
do
right
and
if,
if
you
want
to
have
a
sequence
of
ancillary
data
blocks,
each
of
which
can
change
its
size,
you
know
hop
by
hop.
Then
you
ultimately
end
up
with
having
to
build
a
parsing
chain.
That
needs
to
be
sequential.
For
this
n
number.
G
F
Excuse
me,
I
wasn't
finished,
can
I
say
something:
can
I
say
something
it's
my
presentation.
Can
I
say
something
right
look
if
there
is
variable
length
data
that
can
expand
in
the
middle
of
a
packet,
you
have
to
rewrite
the
whole
of
the
front
of
the
packet
right
now,
a
that
seems
extremely
unlikely.
F
It
seems
that
no
one
would
want
to
do
that,
but
if
you
did
then
you'd
have
to
do
it,
knowing
how
you
were
changing
the
stack
itself
and
change
the
pointers
accordingly,
but
I
cannot
believe
that
anyone
is
going
to
take
the
take
a
block
of
data
in
the
middle
of
this
packet
and
stretch
it
by
moving
the
hoppy
rebuilding
the
whole
of
the
header
in
front
of
it.
D
So
I
was,
I
was
trying
to
say
that
you
know
the
the
best
compromise
if
somebody
really
feels
a
dire
need
to
do
that,
and
I'm
not
quite
sure
about
the
desire
in
iom
to
do
that.
But
the
past
analysis
of
this
has
been
done,
that
this
would
be
the
last
block
of
ancillary
data
right.
So
you
can
make
an
exception
for
that
when
you
can
deal
with
that,
but
you
know
I
don't
think
that
any
of
the
alternatives
would
result
in.
D
You
know
faster
and
better
parsing
than
what
we're
doing
here
right
so
but
yeah.
It's
it's
a
longer
discussion.
C
Maybe
one
other
point
is
also
actually,
even
if
you
could
do
this,
you
could
also,
since,
since
basically
the
pointers
are
defined
by
the
offset
well,
you
could
then
you
would
then
really
need
to
have
a
rule
that
funds,
if
you're,
adding
iom
data
and
so
forth,
put
it
at
the
bottom,
but
not
at
the
top.
Then
then
the
offsets,
don't
change,
you're
right.
G
Remains
the
same
as
you
can
yeah
aom
is
just
one
example:
it
will
change
size.
Okay,
you
can
note
assume,
there's
only
one
block
where
you're
changing
size.
That's
first.
Second,
maybe
on
the
pass.
F
G
Yeah
you
can
build
a
pointer,
that's
a
my
point.
Is
the
extra
work
right
you
need
to
recalculate
the
offset,
then
you
need
to
get
the
entire
label
stack
to
fix
all
the
pointers.
So
that's
a.
C
And
even
in
this
case,
how
you
this
would
be
only
the
case,
if
you
can,
if
you
say
you
can
really
insert
it
in
arbitrary
position
if
you
could
insert,
but
they
for
the
iom.
I
think
that
is.
That
is
a
valid
use
case.
Where
you
want
to
add
stuff:
okay,
fine,
add
it,
but
then
basically
put
it
at
the
bottom.
I
think
that
is
that
that
is
a
very
fair
restriction
convention
that
you
could
make.
D
And
that's
exactly
what
I
said
right
and
it's
it's
it's
it's!
It's
always
look!
If
you,
if
you
have
a
sequence
of
ancillary
data
whose
length
you
don't
can
can
can
know
up
front
right,
you,
you
have
a
sequential
parsing
right,
whereas
if
you
have
a
certain
you
know
maximum
number
of
sequence
of
pointers,
you
can
process
in
parallel
right.
So
the
number
of
steps
you
need
to
take
in
the
parsing
is
is
just
optimized.
This
way
you
have
to
weigh
one
versus
the
other.
That's.
D
D
G
G
No
because
parsing
is
easy.
I
I
insist
that,
because
I
I
know
how
it
has
implant
implemented
in
asic
right,
then
you
know
the
the
two
difficulties,
because
you
know
some
had
some
some
structure
of
the
extension
header.
They
also
support
multiple
erv
options.
This
doesn't
make
a
hierarchical
architecture.
G
A
So
yeah
it's
a
useful
discussion.
I
think
you
know
about
the
cost
of
parsing
versus
processing.
G
G
F
F
F
F
A
The
offset
a
unit
in
your
proposal
pointer
offset
yes,
it's
an
octave,
that's
what
you
were
proposing
right.
Oh.
F
So
I
actually
the
I
wasn't
sure
whether
it
needed
to
be
octets
or
words
or
long
words,
and
that's
a
that's
a
design
decision
right
and
the
the
the.
The
reason
why
you
might
prefer
long
words
is
that
clearly
you
can
go
as
far
back
in
you
can
go
256
long
words
into
the
back,
there's
more
than
you'll
ever
need,
but
the
cost
of
that
is
that
you
have
to
put
padding
inside
auxiliary
data
units.
So
you.
E
F
I
I
have
that's
what
I've
got
in
here.
This
is
only
the
sort
of
sketch
for
discussing
with
with
my
peers,
as
it
were
about
how
we
might
do
this,
so
I'm
happy
with
whichever
makes
sense
after
we've
analyzed
the
the
issues
a
bit
more.
So
this
is
just
a
zero
zero
draft.
It's
a
it's
a
sketch
and
clearly
you
still
hear
me.
A
Yeah
my
question
was:
do
you
think
if
we
make
the
offset
in
in
sorry,
the
question
is:
if
we
made
the
offset
in
ancillary
data,
what
did
we
call
it
header
if
you.
F
F
E
F
A
G
G
D
G
But
you
you
are
imagining
some
some
device
that
doesn't
exist
today,
right
for
all
the
device.
Today
I
always
say
is
that
that
cost
is
exactly
the
same.
D
G
G
G
D
C
F
As
I
understand
it,
there's
a
different
version
of
p4.
You
need
to
describe
pointer
methods
properly,
people
live,
is
it
p4
can't
do
with
pointers
very
well,
but
p4
live
does
a
better
job,
so
I'm
not
even
convin,
and
we
certainly
should
not
limit
our
thinking
to
the
thinking
of
what
the
p4
designers
had
in
mind.
G
F
D
There
is
a
cost,
so
I
mean
people
have,
you
know,
used
p4
to
describe
things
and
then
measured
performance
right
and
the
performance,
depending
on
what
your
parsing
program
was,
was
vastly
different
right,
because
the
underlying
hardware
that
this
is
compiled
into
can
be
vastly
different
right
and
just
just
just
because
you're
saying
I
can
show
to
do
this
in
p4
doesn't
give
you
any
knowledge
about
the
performance
of
it.
I.
F
H
Stuart
it
would
a
little
bit
depend
what
you
call
production
if
you're
talking
about
academic
production.
Yes,
if
we
are
talking
about
say
large-scale
commercial
deployments,
then
no-
and
it's
not
evident
that
there
will
be
any
in
a
foreseeable
future
right.
E
H
So
the
uptake
will
be
to
be
seen
in
the
market,
and
market
will
eventually
show
that
if
we
are
talking
about
what
is
deployed
and
operated
right
now
before
is
mostly
an
academic
experiment.
But
that's
it.
D
G
You
twice
p4
doesn't
provide
you
any
implementation.
That
is
just
a
description,
but
the
description
is
a
generic
for
any
implementation.
It's
just
describe
a
finite
state
machine
to
scan
through
the
header,
so
the
basic
operation
of
it
is
to
find
the
current
location
plus
offset
to
find
the
next
location.
And
but
it's.
G
You
use
you
can
note,
you
know
why
design
kind
of
operation,
so
in
that
sense
it
is
basically
the
cost
for
passing
the
header.
Even
either
you
have
a
single
chain
or
you
have
a
you
know,
just
a
stack
all
the
pointers.
It's
just
you
put
the
information.
D
I've
basically
seen
a
couple
of
these
performance
things
where
change
of
protocol
headers,
you
know
through
p4,
were
analyzed
and
then
basically
the
longer
the
chain
was
the
the
lower
the
throughput
on
especially
high-end
a6
and
obviously
high-end
asic.
4P4
typically
means
data
center
asic.
So
not
typical.
When
around
that.
That's
that's.
G
D
A
Thank
you
so
much
thanks.
We
are
getting
closer
to
the
end
of
our
meeting
a
lot
of
time.
I
want
to
make
sure
that
we
are
capturing
all
action
items
for
the
next
meeting
and
I
want
to
tell
you
that
we
could
not
give
you
the
floor
this
time.
So
maybe
we'll
move
your
request
the
next
week,
but
for
the
action
items
I
do
want
to
assign
you
an
action
item.
You
know
to
you
know
you've
already
flagged
that
there
are
some.
You
know
p4
implications
for
the
parsing.
A
Maybe
if
you
can
talk
about
it
next
time
or
document
it
on
our
wiki,
can
I
give
you
this
action
item?
Are
you
okay
to
take
it.
A
Okay,
other
action
items
we
have,
we
have
to
define
the
you
know
what
data
we
want
to
carry
within
the
mpls
label
stack
and
what
data
do
we
want
to
carry
after
the
bottom
of
the
stack
and
what
segments
should
the
data
be
applicable
to
so
that's
an
action
item
to
you
know
all
of
us.
Please
contribute
to
it
either
on
the
wiki
or
we
have
a.
A
We
have
a
the
the
email,
the
email
mail
list
and
we
have
a
document
that
laura's
driving
we
can
contribute
to
as
well.
D
D
About
performance-
and
if
so
you
know,
how
do
we
make
judgments
about
that?
But
maybe
there
are
other
criteria
as
well.
So
I
think
that's
the
big
open
question
that
lower
tried
to
start
in
in
his
document
and
I
think
any
help
on
you
know.
Those
criteria
would
be
very
helpful
for
the
process.
A
F
F
No,
no,
no!
No
first
off.
We
need
to
go
back
and
decide
what
we're
going
to
do.
Then.
We
need
to
look
at
how
we
would
package
those
in
terms
of
in
the
stack
or
below
the
stack,
and
then
we
need
to
figure
out
what
the
optimum
design
is
and
when
we're
figuring
out
the
optimum
design,
we
need
to
be
absolutely
sure
that
it's
a
design.
That
means
we
are
unlikely
to
have
to
revisit
this
decision
for
say,
20
years,
which
is
how
long
we've
had
mpls
so
far.
D
Okay,
I
don't
understand
the
how
but
the
the
what
I'm
I'm,
I'm
not
quite
clear
if
it's
not
example
use
cases
with.
Okay
here
are
three
different
type
of
functions
and
they
need
to
be
processed
on
these
steps.
That
would
be
what
I
could
understand
as
the
what,
if
that's
not
the
one,
then
I
need
a
better
expectation.
A
It's
similar
to
what
you're
thinking
told
us
the
what
should
be
driven
by
a
use
case.
I
agree:
okay,
okay,
so
I
don't
think
I
have
other.
I
will
send
an
email
about
the
timing
and
that's
an
action
item
on
me
and
anything.