►
From YouTube: MPLS WG Interim Meetings, 2021-06-10
Description
MPLS WG Interim Meetings, 2021-06-10
B
A
Okay,
so
you
know
what
what
dawned
in
the
discussions
we
also
had
offline.
Was
that
the
one
thing
that
really
comes
with
the
proposals
from
kiritti
and
stuart
and
us
was
also
the
element
of
conditional
execution
of
certain
actions,
as
indicated
but
by
the
fai
and
in
the
case-
and
you
know
please
correct
me
if
I'm
interpreting
something
wrong
here,
but
in
the
case
of
kiriti,
we
have
up
to
eight
bits
in
the
ttl
field
that
are
assigned
to
whether
or
not
a
particular
fixed
feature
would
be
executed.
A
Let's,
let's
say
independent
or
not
whether
there
is
you
know,
associated
data
below
bottom
of
stack
with
it
and
in
the
case
of
stuart's
our
draft.
It
is
a
single
pointer
that
is
pointing
to
the
block
of
ancillary
data,
which
would
then
indicate
you
know
what
action
it
is.
So
that's
my
kind
of
approach
to
compare
and
and
unify
both
of
these
approaches
from
from
what
they're
giving
to
the
ability
to
conditionally
execute
action.
A
So
kiriti's
proposal,
of
course,
is
a
lot
more
compact
by
allowing
up
to
eight
of
these
actions
to
be
executed,
but
then,
on
the
other
hand,
of
course,
you'd
start
to
be
worried
of
saying.
Well,
will
eight
actions
be
you
know
ever
enough
for
what
we
want
to
do?
Let's
say
in
in
a
year
from
now,
even
if
it
does
look
good
now,
and
so
that's
that's
where
I
was
coming
from,
and
so
when
it
now
now
comes
to.
How
can
we
further
improve?
A
I
think
the
the
main
issue
that
we
have
is
we,
I
think
we
don't
have
good
team-wide
agreed
rules
for
what
and
what
is
not
acceptable
to
be
parsed
going
back
to
what
kiriti
was
just
saying
as
well
in
terms
of
well,
please
come
back
and
tell
us
if
these
things
can
be
parsed
or
not.
So
in
that
respect,
what
I'm
going
to
propose
is
yet
another.
A
You
know
big
question
mark
to
you
know:
can:
can
we
either
figure
out
more
generally
what
we
agree
to
see
as
parsable
and
or
can
we
have
vendors
chime
in
on
these
things,
and
and
and
we
do
it
ad
hoc,
like
I
think,
we've
done
in
the
past.
So
with
that
with
that
saying,
my
my
idea
for
best
of
both
worlds
was
to
simply
generalize
the
idea
from
kurity
by
saying.
A
Well,
let's
just
have
eight
bits
that,
if
they're
on
each
of
them
indicate
that
a
particular
action
is
conditionally
executed
by
this
hub
or
hops
that
are
acting
on
the
fai
and
otherwise
not,
and
then
we
actually
put
the
idea,
which
you
know
actions
associated
with
it.
We
put
that
in
the
bottom
of
stack,
encoding
itself,
and
so
in
this
case
a
simple
encoding
would
be.
Let's
say
we
have
these
three
id
bits
in
a
particular
bottom
of
stack
action
field,
so
that
is
indicating
if
that
is
three
it
indicates.
B
A
So
to
speak,
then,
the
actual
identifier
of
the
action
that
you
know
would
go
in
the
ayanna
registry,
what
we
had
like
fragmentation
or
what,
whatever
else
the
actions
are
we're
interested
in
and
then
the
length
of
the
block,
followed
by
zero
or
more
bytes
of
actual
data
that
we
need.
So
in
the
minimum
case,
with
this
type
of
encoding,
we
would
need
for
each.
You
know,
and
now
extensible
action,
16
bits
to
encode
below
the
bottom
of
stack.
A
You
know
what
the
actual
action
is,
so
we're
not
stuck
with
eight
and
as
soon
as
we're
going
into
actual
data
that
an
action
has
well
would
be.
I
think,
wasting
a
little
bit
more
of
12
bits
to
have
this
mapping
of
a
single
id
bit
to
to
to
an
action
identifier
in
the
bottom
of
stack
yep.
So
that
was
it.
B
C
Number
two,
so
the
h
bit
here
was
to
indicate
that
the
next
31
bits
are
more
actions,
so
the
extensibility
was
supposed
to
be
through
that
h
bit.
But,
having
said
that,
you
know,
I
I
think,
as
you
said,
we
don't
know
what's
efficient
to
do
so.
I
I
want
to
go
sort
of
between
a
ttl
kind
of
structure,
which
is
very
general
purpose,
which
is
typically
what
I
expect
to
have
happen
after
the
end
of
stack,
because
you
have
more
space
to
play
with,
and
you
know
you're
not
contained
with
these
funky.
C
You
can
do
a
good
load
balancing
on
on
this.
Without
going,
you
know
to
a
actual
ip
header
and
looking
for
the
five
tuple
there,
where
you
would
normally
do
load
balancing
so
so
and
then,
if
you
look
at
things
like
no
further
pass
it
out
and
stuff
again,
you
want
to
keep
these
as
much
as
possible
near
the
top
of
the
stack.
So
you
can
take
coding
actions
you
know
or
in
action
speaking.
You
know
in
the
case
of
no
further
password
quickly,
and
you
know.
C
What
to
do,
I
think
the
slice
selector
would
fall
under
that
as
well.
If
people
believe
that
you
know
that's
a
good
thing
to
to
do,
because
the
slice
selector
tells
you
how
to
treat
the
packet
support
top
behavior
for
this
packet.
So
what
what
I'm
trying
to
get
to-
and
this
is
sort
of
a
discussion
point
between
me
and
how
you
as
well
that
there's
this
combination
of-
let's,
let's
hard
code,
a
few
things
that
we
think
are
interesting
important
for
packets.
That's
why
this
also
called
voting
actions.
C
So
it's
important
for
forwarding
actions
and
keep
them
near
the
top
of
staff.
And
then,
if
you
want
to
get
fancier
and
want
to
do
more
things,
then
you
have
a
tlv
structure
and
then
you
put
the
tlb
structure
at
the
bottom.
So
I
think
what
you're
doing
is
finding
yet
another
sort
of
place
in
between
and
I'm
all
for,
making
this
extensible.
C
A
What
is
the
lowest
common
denominator
on
parsing
that
we
would
feel
acceptable
for
any
of
these
advanced
actions
that
we
have,
because
then
we
don't
need
to
do
special
cases,
which
I
think
is
what
you're
implying
for
the
one
most
important
ones
right.
So
if
this
is,
you
know,
for
example,
a
structure
that
is
feasible
for
the
parsers
of
the
you
know
relevant
forwarding
engines
right.
Obviously,
we
can
ignore
forwarding
engines
that
wouldn't
be
able
to
do
the
advanced
actions
anyhow
right.
C
A
Yeah,
and
by
the
way,
there
is
one
more
option
that
I
didn't
mention,
which
is
closer
to
what
you
said.
I'm
just
coming
out
of
this
discussion,
which
is
obviously
that,
instead
of
indicating
you
know
what
the
id
bit
means
it
could
as
well
be
configured
right.
I
mean
you're
coming
from
the
very
extreme,
which
is
it's
in
the
standard.
C
And
and
to
your
point
about
the
network
quite
configured,
we
actually
started
the
fbi
drop
there,
and
so
we
we
did
want
everything
to
be
configured
via
the
control
plane
or
the
management
plane.
The
problem
there
is,
if
anyone
isn't
configured
or
you
know,
how
do
you
deal
with
things
that
don't
know
how
to
deal
with
this
or
or
haven't
been
updated
correctly,
because
it's
one
thing
to
say:
yeah,
everyone
in
should
understand
that
bit
number
three
means
this
and
then,
if,
for
whatever
reason,
one
router
didn't
know
what
that
bit.
A
C
Yeah
yeah,
I
agree,
but
what?
What?
If
you
you
know
in
in
updating
everyone,
so
you
told
everyone
just
what
bit
one
means
with
two
bit
three
and
then
you
updated
every
one.
At
least
you
thought
you
updated
everyone
about
b3,
but
there's
one
guy
that
was
missed,
for
whatever
reason
you
have
someone
who
thinks
he
knows
what
bit3
is,
but
they
have
the
old
version
of
it
anyway,
we
did.
C
D
A
I
would
I
I
have
no
preconceived
notion
of
all
the
actions
the
one
I'm
interested
in
would
have,
maybe
in
the
order
of
32
or
more
bits
of
of
data
after
it
right.
So
in
that
case,
the
the
overhead
of
having
this
id
to
action.
Mapping
of
course,
becomes
much
smaller
than
if
it
was
only.
You
know
bits
where
the
bottom
of
stack
wastes
another
16
bit
to
define
what
they
are.
D
A
D
D
A
A
So
that's
that's
the
new
conditional
thing,
the
the
the
the
sequence
of
action
items
that
are
linked
with
each
other
by
length
and
that
would
be
self-descriptive
with
the
action
being
in
the
field
itself
as
opposed
to
what
we
had.
You
know
an
ip
where
you
had
the
next
header
field
right.
I
think
these
things
we
already
discussed
in
the
past
few
meetings.
Kiriti.
I
think-
and
I
had
that
discussion
yeah.
C
F
F
G
G
F
F
G
F
F
Gals
aren't
in
this
piece
of
thing
at
the
moment
in
this
discussion
on
the
board,
the
girls
are
there,
they
will
be
there
they're
not
here.
This
gal
is,
I
I
mean,
maybe
I'm
looking
at
the
we're
in
the
wrong
club,
we're
in
different
meetings,
but
I'm
looking
at
a
thing
that
says
proposal
on
a
bit
vector
on
the
right-hand
side.
A
So
so,
let's,
let's
let's
say,
for
example,
we
have
some
new
action
for
improved
deterministic
networking
or
whatever
qs.
We
have
right
and
it
has
a
bunch
of
parameters
like
okay
delay
or
you
know
priority
or
whatever
these
these
parameters
are
and
across
the
path
we
need
to
instantiate
multiple
instances
of
those
ancillary
data
blocks.
So
all
these
ancillary
data
blocks
would
have
the
same
action,
which
is
the
id
for
you,
know
cool
new
qs
block
right,
but
then
each
of
them
has
a
different
bit.
Okay.
A
B
F
D
A
C
D
G
F
F
F
F
C
I
think
I
think
the
the
the
wiki
that
you
know
the
data
after
b
of
b
os
wiki,
should
bring
these
things
out
and
see
if
we
can
generally
unify
the
multiple
schemes
that
we
have
for
putting
data
after
end
of
stack.
So
so
we
have
multiple
drafts
and
we
have
an
existing.
We
have
rfcs
as
well
and
if
we
can
somehow
rationalize
all
of
that
and
say,
this
is
what
the
data,
after
the
bottom
of
the
stack
and
before
the
actual
packet
starts.
F
One
obvious
technique
is
we're
going
to
say,
is
to
have
an
ach
there
so
that
if
the
gal
gets
there,
it
knows
how
to
handle
it
and
if
the
other
handler
gets
there,
it
knows
how
to
handle
it.
So
you
could
have
all
this
is
an
ach
type,
but
you'd
still
have
to
get
rid
of
the
information
that
the
classical
gal
handler
would
expect
to
find.
G
F
G
F
G
G
F
That
works
yeah
two
different
gals
pointing
to
different
aches,
is
not
anything
that
we
have
specified
and
it's
not
clear
what
the
right
way
to
solve
it
is
it's
soluble,
of
course
it's
soluble
with
certain
constraints
and
parameters,
but
it
is
not
within
any
of
the
existing
definitions.
How
you
would
do
it.
G
H
Can
I
do
it?
I
have
two
two
questions
here.
One
is
that
some,
when
you
need
to
have
a
multiple
gach
headers,
I
thought
at
least
why
one
suggested
that
today
the
ach
type
is
two
bytes.
If
we
divide
that
up
to
two
bytes
two
fields
and
giving
the
next
header
and
this
header
semantics,
then
you
can
have
put
multiple
jesus
headers
next
to
each
other
right,
that's
that's!
That's
one
suggestion
I
had
and.
G
F
I
I
think
we
need
to
look
at
the
implications
of
doing
that
as
well.
I'm
I
don't
think,
there's
anything
above
256
you
find
in
the
in
the
set
of
gals
that
have
been
defined
so
far,
but
so
we
might
get
away
with
it.
But
a
consequence
of
that
is
that
we
would
limit
the
number
of
aches
to
255
and
we
would
have
to
have
a
different
approach
to
allocation
at
the
moment.
There's
just
so
many
we
don't
care
about
it.
H
F
F
G
D
G
F
So
so
there's
another
trick:
you
can
pull
so
gal
means
there's
an
ach
below
the
bottom
stack.
That's
an
invariant,
that's
so
thoroughly
baked
in
it's
hard
to
change,
but
I
would
point
out
that
there
is
four
bits
of
version
number
there.
So
if
you
want
to
define
a
different
version
of
the
ach
with
different
parameters,
then
that
is
a
possibility.
F
F
F
F
B
F
F
G
F
The
metadata
could
be
a
new
channel
type,
but
we
don't
currently
have
the
ability
to
have
more
than
one
ach
at
the
end
of
the
packet.
So
we're
going
to
change
we,
we
could
have
a
different
sort
of
ach
if
that
is
what
the
consensus
of
the
of
the
group
was,
and
there
is
ways
of
doing
it.
We
have
eight
bits
of
versions
and
that's
right,
four
bits
of
version
and
eight
bits
of
reserve
type
yeah,
and
then
we
have
16
bits
of
channel
type.
B
F
F
F
F
F
F
Right
so
for
for
for
information,
we
haven't
allocated
anything
above
the
x59
there's
one
and
there's
a
small
number
of
well
actually
there's
quite
a
few
spares
below
that.
So
if
it
wasn't
for
those
experimental
ones,
you
could
chop
it
in
two.
If
that's
what
you
wanted
to
do,
but
the
safest
thing
to
do
is
to
create
a
new
ach
a
new
fundamental
ach
type
by
revving
it
to
version
one.
D
G
F
D
G
F
G
D
F
I
mean
one
of
the
questions
is:
will
we
ever
find
a
case
where
a
packet
has
a
legacy
ach
in
it
and
anything
and
some
other
stuff
in
it,
because
presumably
whatever
put
the
other
stuff
in,
would
be
aware
that
there
was
a
legacy
ach
present
and
yeah?
We
just
need
to.
It
might
be
better
to
just
restart
the
stack.
If
you
want
to
do
anything
like
that,.