►
From YouTube: IETF112-PALS-20211108-1600
Description
PALS meeting session at IETF112
2021/11/08 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
It's
just
a
little
after
eleven,
I'm
andy
malus,
I'm
going
to
be
sharing
this
combined
ietf,
112,
pals,
mpls
and
detonate
session.
The
session
is
being
recorded,
as
are
all
of
these
sessions.
A
As
I
said,
I'm
chairing
stuart
and
tariq
are
my
co-chairs
for
this
session
as
well,
although
I'll
be
doing
most
of
the
heavy
lifting
in
terms
of
the
slides
and
and
moderating
the
speaker,
cue
and
so
on,
our
working
group
secretary
is
dave,
cena
crop
dave.
Thank
you
very
much
dave
put
together
the
agenda
and
dave
will
be
taking
the
minutes
for
the
session
as
well
and
by
the
way
the
minutes
are
available
on
ether
pad
slash
hedge
docs,
slash
code
imd,
whatever
they're
calling
it
these
days.
A
So
please,
if
you'd
like
you,
can
watch
along
and
you
can
even
type
in
to
help
out
with
the
minute
taking
which
will
be
done,
live
in
the
ether
pad,
slash
hedge
doc,
okay,
with
that
and
go
on
to
the
next
slide.
This
is
the
note
well.
This
is
something
that
you've
all
seen
before,
and
so
I
don't
think
we
need
to
go
into
it
in
any
great
detail.
A
So
the
purpose
for
this
meeting
this
is
a
joint
session
of
pals
mpls.net.
A
This
is
the
third
such
meeting
that
we've
had
since
ietf
111
we're
discussing
basic
architectural
issues
that
have
arisen
from
drastic,
proposing
new
applications
and
uses
at
the
bottom
of
the
nps
label
stack,
and
that
was
the
actually
the
initial
intent
and
it's
kind
of
groans
from
there.
And
if
you
were
in
the
mpls
session
last
period,
then
you
got
to
hear
lower,
give
a
really
good
summary
of
of
how
we're
coming
along
and
and
where
things
stand
right
now.
A
So
I
highly
recommend,
if
you
weren't
in
the
mpls
session
previous
the
that
you
go
to
the
meeting
materials
and
you
look
in
the
mpls
session
and
take
a
look
at
lowest
slides
from
the
last
session
as
well,
so
a
quick
overview
of
the
agenda.
It
follows
right
here:
I'm
actually
not
going
to
read
it,
because
the
next
slide
is
going
into
the
agenda
in
in
much
more
detail.
The
open
design
teamwork
has
not
completed.
We
will
be
continuing.
The
open
design
team
calls
following
this
ietf
meeting.
A
Then
kuriti
has
two
talks,
one
after
the
other,
the
first
on
the
mpls
first
nibble
and
next
on
the
special
purpose
label.
Now
we
have
30
minutes
allocated
to
kuriti's
two
talks
and
what
I'm
going
to
let
greedy
do
is
basically
manage
that
time
himself.
So
as
long
as
treaty
stays
within
the
the
30
minutes,
he
can
feel
free
to
switch
from
one
talk
to
the
next
talk
when
he
feels
comfortable
to
do
so,
then
we're
going
to
have
the
network
function
indicator
from
john
drake.
A
A
So
we'd
like
to
ask
that
you
that
you
keep
them
your
major
discussion
points
for
item
seven
on
the
agenda
and
finally,
stuart
is
going
to
be
listening
along
he's,
going
to
be
taking
notes
and
then,
at
the
end,
we're
going
to
give
stuart
10
minutes
to
basically
summarize
what's
been
going
on
what
he's
heard
and
what
we
would
like
to
do
going
forward.
A
So
with
that,
first
of
all,
do
we
have
any
questions
on
on
the
agenda
or
any
comments
that
people
would
like
to
make
right
now
before
we
we
we
get
started
and
I'm
not
seeing
any
hands
raised.
So
let
me
move
on
to
my
last
slide.
A
A
You'll
notice,
on
the
left,
of
course,
in
meet
echo,
there's
the
notes
section
or
or
the
the
discussion.
That's
exactly
the
same
as
the
jabber
room
for
pals.
So
you
can.
You
can
want
to
do
the
the
java
discussion
either
way
either
directly
in
meat
echo
or
via
your
favorite
jabber
client.
We
also
have
an
open
design
team
wiki
for
the
implants
open
design
team
group.
So
I'd
like
to
appoint
you
with
that,
and
the
wiki
is
always
there.
A
If
you
have
any
issues
with
meet
echo,
the
meeting
audio
or
so
on,
send
an
email
to
support
iatf.org
and
they
will
have
someone
help
you
and
we
also
have
a
meet
echo
tech,
who's
monitoring
jabber
for
this
session
and
for
all
sessions.
So
with
that
I'm
going
to
switch
to
matthew's
deck.
So
if
you
wait
one
second,
thank
you
and
matthew.
Take
it
away.
B
Thanks
andy,
hopefully
you
can
hear
me
yes,
so
this
first
presentation
is
about
the
requirements.
Draft
for
mpls
label
stack
indicators
for
ancillary
data,
so
this
is
something
that
I've
been
editing
along
with
stuart
who's,
been
been
helping.
Thank
you
and
next
slide.
B
So
so
this
draft
specifies
the
requirements
for
indicators
in
the
mpls
label.
Stack
of
ancillary
data
that
exists
below
the
label
stack,
and
the
intention
is
that
this
will
be
a
product
of
the
mpls
open
design
team.
This
is
version
0
of
the
draft,
so
this
is
just
a.
This
is
the
first
revision
of
the
draft,
and
the
intention
is
that
it's
it's
going
to
describe
the
behavior
of
the
protocol
mechanisms
and
procedures.
B
So
so
just
to
be
clear,
this
is
not
implementation
requirements
and
we
want
to
be
able
to
identify
the
toolkit
through
these
requirements
and
any
new
protocol
work.
That's
that's
required.
B
The
primary
objective
of
this
is
to
avoid
piecemeal
solutions
to
different
emerging
applications
for
these
indicators
in
the
mpls
label
stack,
and
we
want
to
be
able
to
ground
the
work
very
clearly
on
existing
mpls
architecture.
B
So
it's
implicit
in
the
context
of
the
the
lsb
or
flow
I've
encoded
within
the
label
stack,
so
it's
actually
explicitly
encoded,
as
in
stack
data
in
the
label
stack
or
it's
after
the
bottom
of
the
label
stack
but
not
considered
part
of
the
payload
or
it's
within
the
payload,
and
we
need
an
ancillary
data
indicator
this.
So
this
is
an
indicator
in
the
mpls
label.
Stack
that
ancillary
data
exists
in
the
packet.
B
It
could
optionally
also
indicate
the
specific
type
of
the
ancillary
data
next
side,
so
I've
I've
kind
of
summarized
some
of
the
there's
a
couple
of
pages
of
high
level
requirements
in
in
the
draft
as
it
stands
and
and
I've
clustered
these
together
on
the
next
few
slides
I've
only
called
out
the
key
ones
from
from
the
draft.
A
lot
of
these
requirements
were
kind
of
gleaned
from
discussions
in
the
open
design
team
or
from
some
of
the
existing
proposals
for
for
solutions.
B
B
So
the
first
one
is
that
mpls
combines
extensibility
flexibility
and
efficiency
using
control,
plane
context,
combined
combined
with
a
very
simple
data
plane
to
make
forwarding
decisions
about
the
packet,
and
we
want
to
maintain
those
principles.
So
any
solution
must
maintain
these
properties
of
mpls.
B
Any
solution
for
for
this
also
must
not
restrict
the
generality
of
the
npls
architecture,
so
it
must
be
applicable
across
multiple
different
applications,
multiple
different
domains,
multiple
different
use,
cases
for
mpls.
B
It
must
be
able
to
coexist
with
and
not
obsolete,
existing
mpls
mechanisms,
so
we're
not
we're
not
looking
to
obsolete
the
existing
mpls
data,
plane
and
control
planes,
for
example,
and
it
needs
to
work
in
it
to
some
extent,
at
least
in
in
an
existing
network
which
uses
existing
control
planes
and
data
planes.
B
B
Next
slide
so
now
there's
a
set
of
protocol
capability
and
backwards
compatibility
requirements.
B
So
this
is
really
about.
You
know:
defining
the
the
the
requirements
for
capability
advertisements,
capability,
negotiation
procedures,
making
sure
that
bad
things
don't
happen.
For
example,
adis
are
not
delivered
to
notes
that
that
cannot
process
them
and
then
start
discarding
data,
for
example.
B
So
so
the
first
one
is
of
these
is
that
neither
an
adi
nor
these
ancillary
data
must
be
delivered
to
a
node
that
is
not
capable
of
processing
it
and
care
needs
to
be
taken
in
the
coexistence
of
ancillary
data
and
existing
post-stack
data
mechanisms.
So,
for
example,
things
like
the
gach.
B
Next
slide,
please
so
then
there's
some
sort
of
high
level
requirements
for
for
the
protocol
development
development
work.
So
any
solution
needs
to
accept
the
principle
that
special
purpose
labels
are
the
mechanism
of
last
resort.
B
So
the
the
reason
this
is
in
there
is
that
we
have
a
very
limited
pool
of
free
special
purpose
labels
we
can
use
and
ideally
we're
trying
to
avoid
either
allocating
special
purpose
labels
per
application,
which
is
part
of
the
reason
we're
doing
this
work,
ideally
we'd
like
to
avoid
allocating
any
special
purpose
labels
in
for
these
protocol
mechanisms,
because
it's
such
a
limited
bulk.
B
B
The
mechanisms
required
to
enable
an
adr
inserting
adis
to
determine
whether
or
not
the
path
can
pass
the
label
stack
and
process
the
adi
at
the
location.
This
is
inserted,
so
this
is
really
saying
you
need
to
insert
if
you're,
targeting
an
adi
for
a
particular
downstream
lsr.
You
must
be
sure
that
they
can
actually
see
parse
the
label
stack
to
a
sufficient
extent
to
be
able
to
read
that
adi.
B
We
need
to
be
able
to
support
this
for
point-to-point
support
to
monitor
paths,
but
we
only
expect
what
a
specific
adi
to
be
supported
for
one
or
the
other
data
plane.
Mechanisms
for
adis
must
be
independent
of
the
control
plane
type,
so
it
should
work.
You
know
with
ldp
rsvp
bgp
static
labels,
igp
advertised
labels
and
so
on,
so
basically
anywhere
where
you
can
use
the
mpls
data
plane
today,.
B
A
must
be
defined
for
the
control
planes
to
be
able
to
determine
the
the
ability
of
downstream
lsrs
and
odrs
to
accept
and
process
given
adi,
and
it
should
be
possible
to
include
indicators
for
ancillary
data
for
multiple
applications
in
the
same
label
stack.
But
each
adi
only
supports
one
application.
B
Next
slide:
okay
and
we
started
to
write
down
some
security
requirements
as
well.
I'm
not
a
security
expert,
but
I've
seen
some
of
this
work
going
on
in
other
working
groups
related
to
what
you
can
expose
within
a
an
outer
or
underlay
protocol
header
depend.
You
know,
based
on
on
what
it's
carrying
so
there's
a
couple
of
requirements
in
in
in
this
draft
as
it
stands.
So
the
first
is.
C
B
B
Thank
you.
So
the
next
steps
to
clean
up
any
any
duplicate
requirements
in
the
draft
we'd
like
to
continue
to
gather
requirements
from
emerging
applications
and
also
there
will
be
some
some
kind
of
companion,
architecture
and
framework
document.
I
think
that'll
exist
that
will
hopefully
help
to
drive
some
of
the
requirements,
and
we
would
really
appreciate
some
review
and
feedback
on
the
on
the
list
and
into
the
open
design
team.
Thank
you.
D
I
think
that
one
first
of
all,
we've
been
using
special
purpose
labels
for
other
things,
but
especially-
and
I
know
that
there's
a
specific
solution,
but
the
fai
approach
essentially
lets
you
use
one
special
purpose
label
for
lots
of
things.
D
So
I
think
that
that
sort
of
persimmony
of
special
purpose
labels
can
perhaps
be
you
know,
pull
back
a
little
bit
if
you
say
that
when
you
do
the
special
purpose
labels
you
try
to
do
multiple
things
with
a
single
special
purpose
label,
so
I
think
that
ability
for
a
special
purpose
level
to
carry
many
more
functions
and
many
types
of
adi
if
you
were
doing
one
adi
per
spatial
purpose
label.
Yes,
I'm
totally
with
you,
but
given
a
new
mechanism
where
a
single
special
purpose
label
can
be
used
in
a
multi-purpose
fashion.
D
B
Yeah,
I
think
that's
that
makes
sense,
because,
of
course,
what
we're
trying
to
do
here
is
to
provide
a
framework
or
a
set
of
a
mechanism
that
will
work
for
many
future
future
applications
for
for
adis.
Rather
so,
if
presumably,
if
we,
we
can
have
one
one
special
purpose
label:
we're
not
going
to
be
we're
not
being
replicating
multiple
different
specials
for
special
purpose
locals.
D
D
No,
it's
not
this
one.
Okay,
maybe
I'll!
Look
over
this!
Oh
yeah,
this
one,
this
one
yeah!
Thank
you!
Thank
you!
Okay,
so
neither
an
adi
nor
ancillary
data
must
be
delivered
to
a
node.
That's
not
capable
of
processing
it.
When
we
did
elis,
we
said
hey,
you
know
we
will
ship
this.
If
someone
can
handle
it
great,
they
can
do
a
much
better
job
of
load
balancing
if
they
can't.
D
Okay,
there's
no
harm
no
foul,
and
I
think
we
have
to
be
careful
that
if
we
classify
adis
into,
if
you
see
this,
you
must
process
it,
and
if
you
can't
process
drop
the
packet,
then
I
would.
I
would
go
with
this
particular
thing
that,
ideally
you
don't
even
deliver
it
to
a
node.
If
you
know
that
it
can't
process
it
well,
the
next
one.
D
Sorry,
sorry,
sorry,
let
me
just
finish,
but
if
it
was
like
this
is
an
optimization.
If
you
can
process
it
and
you
know
do
better
with
the
packet
go
for
it,
if
you
can't
process
it
no
big
deal
and
and
so
that
distinction,
for
example,
let's
say
that
a
slice
identifier
is
really
important.
You
want
that
end-to-end
guarantee
for
that
slice,
and
so,
if
you
send
it
to
a
note
that
doesn't
understand
it,
then
you
know
bad
things
will
happen.
D
Then
you
really
don't
want
to
send
it
to
that
node.
So
I
think
that
that
first
bullet
may
have
to
be
softened
as
well.
Okay,.
F
A
G
A
G
H
A
Okay,
very
good
I'll,
just
use
the
laptop
in
that
case,
okay,
very
good,
thanks
for
letting
me
know
by
the
way,
and
now
what
we're
going
to
do
is
we're
going
to
switch
to
the
next
top,
which
is
going
to
be
greg.
So
let
me
switch
to
greg
slides.
A
A
I
Okay,
there
we
go
okay,
great!
Thank
you,
andy,
okay,
so
this
is.
J
Resulting
from
our
discussions
in
that
on
oem4.net
over
the
mpls
data
plane
next
slide.
Please.
J
So
there
deterministic
networking
data
plane.
We
are
working
with
the
mpls
and
and
for
mpls.
The
two
sub
layers
been
identified:
it's
a
deadnet,
a
service
sub
layer
and
a
forwarding
sub
layer.
So
for
their
procedures
we
are
using
their
pseudo-wire
architecture
and
for
their
detonate
service,
sub
layer
need
to
use
the
sequence
number
and
that
net
flow
identified
using
the
label
and
their
sequence
number
in
a
control
world.
J
So
that's
why
we
identified
as
a
deadman
control
word
and
the
use
of
that
control
word
in
is
mandatory.
Okay.
So
on
this
figures,
you
can
see
that
effectively.
What
we
have
is
that
that
net
is
using
a
multi-segment,
pseudo-wire
approach.
J
So
in
the
figure
would
just
remind
how
their
encapsulation
looks
and
we
have
a.
J
Label
stack,
then
s
label
that
identifies
their
detonate
flow
and
this
is
the
bottom
of
the
stack
label
and
that
immediately
follows
the
deadnet
control
world.
So
that's
takes
care
of
their
data
traffic
next
slide.
Please.
J
So
in
control
word,
the
first
nebo
is
all
zero
and
then
it
full
using
their
sequence,
number.
J
And
the
sequence
number
is
a
critical
for
that
net
because
in
the
service
layer,
nodes
dedicated
nodes
can
be
placed
with
a
packet,
replication,
duplicate,
elimination
and
order,
preservation,
functions,
sub-functions
and.
J
For
duplicate,
elimination
and
order
preservation,
the
sequence
number
is
critical
essential,
so
that's
the
payload
must
have
the
thickness
number
and
the
sequence
number
space
is
circular
so
and
monatomically
increasing
okay
next
slide.
Please.
J
So
here
you
see
the
service
layer
being
presented,
serviceabler.net,
where
we
have
placed
replication
point,
duplicate,
elimination
and
ordering
so
the
pre-off
as
an
acronym
for
all
these
mechanics,
that
used
in
a
service
sub
layer,
is
effectively
a
pair
packet,
proactive
protection.
J
So
it
might
look
similar
to
1.1
protection,
but
in
the
classical
one
plus
one
protection,
their
destination
selects
one
source
to
receive
the
packets,
whereas
with
the
pre-off.
What
happens?
Is
that
packets
being
replicated
at
replication
by
replication
function
and
then
they
can?
They
will
travel
on
this
joint
paths
at
somewhere.
There
will
be
an.
J
Order
preservation
and
elimination
functions,
so
the
elimination
function
is
just
to
eliminate
unnecessary
copies.
So
thus,
in
the
definite
domain
we
can
achieve
our,
we
can
decrease
their
packet
loss.
J
So
the
oem
for
the
service
sub
layer
is
is
important
and
what
we
have
considered.
We
consider
it
to
use
ach
and
use
reserved
field
as
a
sequence
number,
so
that
oem
packets
can
be
processed
in
a
way
similar
to
the
data
packets
and
by
the
pre-op,
replication,
elimination
and
other
preservation
functions
in
the
main.
J
J
And
what
we
are
considering
now
is
that
again,
so
what
is
being
presented
today
is
only
individual
draft.
It's
not
yet
been
discussed
by
that
working
group,
because
our
meeting,
I
believe
on
wednesday,
so
you
can
see
here,
is
that
new
format
for
that
net
ach
so
the
first
nibble
is
still
is
one.
J
But
version
is
one
as
well,
so
we
are
taking
the
next
version
number
and
it
has
a
sequence
number
and
a
channel
type,
and
then
the
second
32-bit
word
is
used
for
note
id
and
some
other
fields
that
we
still
thinking
of
how
they
interpret
it.
But
we
just
put
the
level
flags
and
the
session
identifier
for
placement
so,
but
they
might
be
considered
for
now
as
reserved
as
well,
but
in
general.
So
what
we're
proposing
is
we're
proposing
to
change.
J
To
take
a
next
step
from
ach
as
defined
for
the
pseudo-wire,
and
that
was
previously
up
to
now
defined
in
that
networking
group
document.
As
one
32-bit
word
and
using
the
version,
versioning,
extender
applicability
and
use
of
deadnet
ach.
J
Yes,
that
is,
might
be
not
good
enough
and
that's
very
good
question.
So
what
might
happen
and
again
that
we'll
discuss
more
in
more
details
in
that
note
group
is
that
the
sequence
number
will
be
moved
to
their
second
word
and
that
space
can
be
reused
for
some
other
elements
that
we
think
that
are
needed
in
that
net
service
sub
layer,
because
the
reason
why
we
introduced
this
new
format-
and
it
was
because
of
our
analysis
of
service,
sabler
and
deathmatch
and
bill
watts.
D
So
I'm
happy
to
hear
that,
because
one
of
the
things
that
I
was
thinking
is
that
that
space
of
the
first
nibble
is
really
short,
and
you
know
that
first
nibble
came
from
a
hack
and
I'll
talk
about
it
in
my
section,
but
I'm
thinking
that
we
need
an
extension
field
that
says
here
are
subtypes.
D
So
if
you
say
0
0
1
is
definite
oem,
then
you
could
say
I
have
subtypes
of
the
deadnet
om
and
so
extend
the
space
that
way,
as
opposed
to
try
to
live
within
that
that
really
small
space
of
just
16..
So
I
think
there
are
ways
that
we
need
to
think
about
this,
so
that
we
can
really
use
that
mfn.
The
first
level
more
effectively.
J
Out
yeah,
actually
what
we
are
taking
advantage
here
and
that's
might
be
a
good
recommendation
for
more
generic
mechanisms,
is
the
versioning.
D
I
have
some
function
that
I
have
an
updated
version
of
the
same
function,
but
if
I
have
a
different
function
that
still
falls
under
oam
for
that
net,
then
you
know
so
I
I
think
it's
useful
to
to
step
back
and
think
how
you
want
to
do
this.
So
you
can
have
version,
you
can
have
multiple
sort
of
sub
functions.
J
Okay,
thank
you
all
right
and
we'll
probably
have
more
discussions
so
welcome
to
that
net
meeting
this
week
and
I
think
that
that
will
be
a
last
slide
or
less
substantive
slide.
D
D
So
the
mpls
first
nibble
is
the
high
order,
four
bit
field
of
the
first
octet
after
the
last
label
in
the
label
stack,
so
you
pass
the
label
stack,
you
say:
oh
here's,
the
label
with
the
end
of
stack
bit
or
the
bottom
stack.
That's
set.
Okay.
The
first
thing
that
I
see
after
that
take
the
first
octet.
Take
the
high
order,
four
bits:
that's
the
first
nibble
and
it
became
special
for
a
few
reasons.
D
First
thing
that
you
know
people
started
using
it
for
is
for
load
balance,
we'll
get
we'll
get
into
that.
So
the
the
point
is
that
that
first
nibble
became
important,
and
so
what
and-
and
there
have
been
a
few
rfcs
that
have
dealt
with
it
indirectly.
D
So
what
we
decided
to
do
is
to
step
back
look
at
what
it's
being
used
for,
look
at
how
it
should
be
used
and
then
based
on
that
make
some
recommendations,
and
so
we
want
to
come
up
with
a
requirement
and
a
recommendation
on
the
use
of
the
first
nibble
and-
and
you
know
stuff
around-
that
we
want
to
registry
for
first
nibble
values
and
we
want
to
register
for
postdoc
data,
so
sort
of
the
first
nibble
also
is
used
for
to
tell
you
what
is
going
on
in
the
packet.
D
So
next
slide,
please
so
just
to
make
sure
we're
all
on
the
same
page.
Here
you
see
ahead
of
you
know,
on
top
of
the
label,
one
that
you
see
would
be
a
layer,
2
header
saying
this
is
an
mpls
packet.
Then
you
see
a
bunch
of
labels.
You
see
the
last
label
with
the
s
end
of
stack,
which
set
to
one
the
first
nibble
after.
That
is
what
we're
calling
the
mfn
or
mpls
first
level.
D
So
there
are
two
cases
in
one
case:
you
actually
have
the
payload,
the
actual
packet
being
carried
over
mpls
directly
after
the
last
label.
This
is
how
a
lot
of
things
started
when
you
were
doing
mpls
for
traffic
entering,
took
an
ipv4
packet
and
just
stuck
it
in
there.
When
you
did
mpls
for
vpns
ipvpns,
which
came
first,
you
again
do
the
same
thing,
so
you
had
a
bunch
of
labels.
D
D
I
want
to
put
some
extra
metadata
before
I
actually
start
the
packet.
So
the
case
from
the
left,
you
also
could
have
had
a
layer,
2
packet.
You
could
have
had
an
ethernet
packet
saying
I
want
to
do
a
pseudo
wire
or
I
want
to
do
vpls,
I'm
going
to
give
you
a
bunch
of
labels.
The
last
label
is
my
vpn
label.
My
vps
label,
my
pseudo
wire
label
and
I've
got
a
layer,
2
packet.
D
In
some
cases
we
said
no,
we
want
to
put
a
header
in
front
of
those
two,
so
typically
a
control
word
and-
and
so
then
we
said:
okay,
if
you're
going
to
put
a
control
word
that
will
help
with
a
few
things.
For
example,
let's
not
use
the
first
novel
being
4
so
that
someone
who's
looking
at
this
won't
mistake
this
packet
for
a
an
ipv4
packet
and
try
to
do
some
fancy
load
balancing
on
it.
D
So
then,
that's
where
we
started
putting
a
post
stack
header,
which
is
what
I'm
going
to
call
it
so
control
word
om,
word
or
words
a
bunch
of
sort
of
extra
metadata
before
the
actual
payload
starts.
D
D
Let's
use
it
also
for
the
type
of
post-stack
data,
that's
carried
if
you're,
so
the
the
heuristic
number
one
works
for
the
case
on
the
left
in
the
previous
slide
curious
or
the
the
indication
of
the
type
of
postdoc
data
works
for
the
case
on
the
right,
where
you
put
values
that
are
different
and
then
say,
oh,
this
is
going
to
tell
me
something
useful
about
what
kind
of
data
I
have
so
essentially
that
post
stack
data
started
off
being
control
words.
D
Initially
the
survive,
control
word
then
a
death
net
control
word,
but
now
it
can
also
be
a
beer
header
or
a
gach
or
something
so
you
know
that
they
suppose
stack
data
in
two
ways.
One
is
a
signal
in
the
control
plane:
hey
I'm
doing
that
net
as
greg
just
said,
that
net
must
have
a
control
word,
so
look
for
it
or
hey
I'm
doing
survivors
and
I
have
this
option
to
carry
and
control
word.
I'm
using
it.
So
expect
a
control
word
for
beer
and
for
jch
it's
actually
heralded
by
a
label.
D
So
there's
a
gal
label.
Excuse
me
or
there's
a
beer
label
that
says
what
comes
next
is
a
postdoc
data
which
is
of
type
beer
or
of
type
gach.
D
D
D
You
can
have
an
ipv4
ipv6
packet
or
you
can
have
any
kind
of
layer,
two
packet
and
if
it's
a
layer,
two
packet,
you're
gonna,
do
potentially
bad
things,
because
you'll
interpret
in
the
cases
where
the
first
nibble
is
a
four
or
a
six,
we'll
interpret
the
packet
as
an
ip
packet
and
try
to
load
balance
on
fields
that
are
not
meant
for
lower
dancing,
so
the
theoristic
can
fail
badly.
D
Now,
given
that
you
know
we
said
we
want
things
to
continue
working
as
they
are.
You
know
we
have
this
big
caveat,
but
that
should
continue
to
work,
but
at
the
same
time,
to
the
extent
that
we
can
prevent
confusion
of
an
ipv4
or
ip
version
number
with
the
mfn.
We
should
do
that
and
we
have
new
and
better
ways
of
load
balancing
packets,
so
we
should
start
using
those
as
well
next
slide.
D
D
I
think
we
should
point
out
that
there
are
these
issues,
but
hey
if
you
have
an
implementation
today
that
looks
for
the
mfn
and
tries
to
load
balance
on
it
keep
going,
but
we
should
lay
the
groundwork
for
better,
more
efficient
implementations
and
lay
the
groundwork
for
easier
identification
of
the
psd
when
there
is
psd-
and
you
know,
to
the
extent
that
we
can
make
it
self-contained
so
much
the
better
next
next
slide.
D
So,
in
the
case
of
an
ethernet
payload,
the
mfn,
if
it
is
you
know,
carried
as
a
naked
layer
two
over
mpls,
then
that
that
first
nibble
is
part
of
the
destination
address
the
part
of
the
oui.
D
So
we'll
talk
about
that
in
a
second,
the
current
psd
types.
You
know
when
we
say
here's
a
control,
what
we're
staying
away
from
four
and
six,
but
even
they
were
saying:
okay,
we'll
use
five
for
beer
and
we'll
use
one
for
oam,
but
you
know
what,
if
there's
a
new
version
for
ip
that
is
like
seven
or
maybe
they
want
to
reuse
ip
version
one.
What
do
we
do?
It's
like?
Let's
not
even
go
there,
let
us
stop
confusing
the
ip
version
number
and
the
mfn
and
so
again
for
backward
compatibility.
D
If
you
see
a
406
and
you
want
to
try
to
recognize
that
as
an
ip
packet
and
do
load
balancing
go
for
it,
you
know
understand
the
problems
that
you
can
have,
but
if
you
see
any
other
value,
even
if
there's
a
new
ip
version,
one
please
do
not
use
one
as
I
can
go,
look
for
ippacket
or
ip
headers
or
do
do
not
use
seven
for
that.
So
let's
decouple
the
mfn
and
the
ip
version
numbers
next
slide.
D
Okay,
so
we
we
want
to
be
careful,
also
not
to
try
to
back
door
an
mpls
protocol
field
in
here,
so
the
mfn
kind
of
sort
of
was
used
as
a
protocol
field,
at
least
to
recognize
ipv4,
ipv6,
yeah.
Okay,
we
will
leave
that
in
for
backward
compatibility,
but
no
more.
D
What
we
will
use
the
mfn
for
is
to
identify
the
type
of
poststack
data.
So
zero
means
a
control
word,
one
means
om,
five
means
beer,
you
know
and
and
so
on.
This
is
why
we
need
a
registry.
So
that's
what
we're
gonna
do
right.
D
The
other
thing
we're
going
to
do
is
to
say
for
all
non-ipv4
non-ipv6
payloads.
They
must
be
a
psd.
There
must
be
this
kind
of
header.
That
says
I
have
a
control
word.
It
might
only
be
I'm
going
to
put
something
non-zero
here,
non-496
here,
but
other
than
that,
I'm
not
going
to
do
anything
else,
and
so,
if
you
do
that,
then
you're
not
going
to
have
any
confusion
of
non-ipv4
packets
being
treated
as
ipv4
and
load
balancing
happen
there.
D
So
there's
a
there's,
a
recommendation
for
this,
but
we're
trying
to
make
this
a
this
requirement
going
forward.
So
existing
implementations,
yeah
they'll,
do
what
they
do
and
they
understand
the
the
sort
of
what
trouble
they
can
get
into.
D
There
is
a
recommendation.
That's
a
more
like
a
requirement.
There's
a
recommendation
that
for
load
balancing
purposes,
don't
even
look
for
those
things.
It's
actually
a
lot
more
efficient
to
use
a
fat,
solar,
wire
or
an
entropy
label,
and-
and
you
actually
get
much
better
load
balancing.
You
do
less
work
and
you
get
better
load
balancing
by
by
doing
that.
D
So
so
the
recommendation
is
to
use
faster
wire
or
entropy
labels
for
load
balancing,
and
it
worked
for
more
than
just
ipv4.
D
And
the
mandate
or
the
requirement
is
going
forward-
implementations
can
can
only
have
naked
payload
of
ipv4
and
ipv6
any
new
versions
of
ip
or
any
other
layer,
2
or
layer.
1
packet.
That's
carried
here,
must
have
a
post
stack
data.
D
The
other
thing
that
would
be
nice,
I
think,
is
to
keep
the
recognition
passing
of
the
psg
completely
in
the
data
plane.
So
again,
we'd
like
to
create
an
mfn
registry.
Today
we
have
an
overlap
between
zero
would
which
could
be
a
control
word
for
pseudovirus
or
for
that
net.
You
have
to
resolve
that
in
the
control
plane,
but
to
the
extent
that
we
can,
if
you
say
here,
are
unique
registries
for
different
types
of
postdoc
data,
then
I
think
we,
whoever
is
doing.
D
So,
like
I
said,
existing
implementations
can
continue
to
be
used
with
the
caveats
that
we've
mentioned
pseudowire
and
that
net
control
words
will
work,
as
is
no.
Changes
are
to
be
made
to
them,
or
if
there
are
changes
made
like
greg,
was
suggesting.
You
know
it
is
in
the
context
of
stuff
that
they're
working
on
the
the
one
that
I
think
is
much
more
difficult.
Is
the
gal
ach.
D
Post-Stack
data
continues,
as
is
the
br1
probably
will
continue
as
is
and
beyond
that,
that
particular
mfn
will
be
used
for
beer.
Any
new
ideas
for
psd
should
have
a
new
mfn
code
point.
So
you
know
this
idea
of
reusing
existing
code
points
and
and
saying
I'll
signal
it
in
the
control
plane
to
the
extent
that
we
already
have
it.
We
keep
keep
it,
but
if
we
can
say
going
forward,
we
won't
use
it.
Then
I
think
people
who
write
microcode
will
be
happier.
D
On
the
other
hand,
as
we
were
discussing
with
greg,
we
have
a
very
small
space
for
the
mfn,
so
it
would
be
nice
to
say
new
code
points
for
mfn
are
followed
by
a
sub
function
registry
as
well,
and
that
way
we
can
extend
the
msn,
but
that
that
problem
does
have
to
be
tackled
so,
but
but
we
need
to
for
the
starting
point.
We
need
an
mfn
registry
and
and
corresponding
chord
points
next
slide.
D
So
here
is
sort
of
a
proposal.
This
is
not
in
the
draft.
The
draft
is
something
that
we
came
up
with.
I
should
have
mentioned
this.
There
are
several
of
us
who
talk
together
about.
You
know
that
we
need
a
registry
for
mfn
and
and
what
all
should
go
into
it,
but
in
the
offline
discussions
you
know
and
and
these
thoughts
that
the
mfn
space
is
really
small,
we
could
have
something
like
you
know.
D
You
have
an
mfn,
that's
four
bits
existing
elephants,
yeah,
they
are
what
they
are,
but
new
ammo
fans,
you
might
introduce
a
subtype.
What
greg
was
talking
about
is
the
version
number
so
so
something
that
says
I
can
extend
the
mfn
space
a
little
bit,
so
I
don't
have
to
burn
a
new
top-level
mfn
bit
for
every
new
type
of
psd.
D
I
want
to
know
where
the
real
packet
starts
and
the
total
length
of
the
psu
will
say
if
you
don't
want
to
process
the
psd
just
go
on
to
the
end
and
there's
your
customer
packet
and
forward
that
as
you
need
to
so
I
this
is,
like
I
said,
just
a
proposal,
but
it
captures
two
important
things
that
we
need
to
tackle.
One
is
how
do
we
make
the
mfn
space
bigger
and
two
is?
How
do
I
skip
the
psd
altogether
and
get
to
the
customer
packet
and
beyond
that?
A
Okay,
I
actually
had
a
quick
question
just
based
on
your
last
slide
myself.
I
I
assume
that
that
will
be
in
the
next
revision
of
the
draft.
Yes,.
A
Okay,
very
good.
Let's
move
on
to
to
hyu
and
and
then
loa.
L
My
question
is
that
I
think
the
use
of
this
first
label
is
to
a
wide
ambiguity
due
to
the
lack
of
any
effective
indicators
in
the
label
stack.
But
from
now,
if
we
are
designing
this
ancillary
data,
we
need
to
define
a
indicator
in
the
label
stack.
If
we
have
that
in
place,
then
it
seems
says
why
we
should
care
about
this
first
neighbor
anymore,
because
we
know
for
sure
what
what
follows
a
label
stack.
So
that's
my
question.
D
So
that
I
actually
I
try
to
tackle
that
in
my
next
presentation,
but
but
I
I
agree
with
you,
I
think
there's
this
place
for
things
in
stack
and
there's
place
for
things
post-stack
and
I
I
think
we
have
both
levels
in
our
hands
and
I
think
what
we
should
come
up
with
is
the
ideal
or
you
know,
from
what
we
see
now
the
best
possible
view
going
forward.
So
I'm
with
you.
A
K
G
D
Right
and-
and
so
I
think,
where
we
are
kind
of
going
is-
maybe
every
mfn
would
have
such
a
qualifier,
and
you
know
everyone
going
forward-
might
have
eight
bits,
but
the
ones
that
have
already
defined
it.
You
know
in
greg's
thing
he
had
four
bits
for
a
version
number.
As
steward
just
mentioned,
we
have
four
bits
for
a
qualifier,
I
think
going
forward.
D
So
I
you
know,
I
I
think
we're
all
saying
the
same
thing.
The
one
thing
we
didn't
talk
about
is
the
total
length
of
psd,
which
I
don't
think
people
would
disagree
with
from
the
point
of
view
of
being
able
to
skip
the
psd
and
knowing
where
the
end
of
the
psd
field
is.
So
I
know
where
the
packet
starts,
the
actual
payload
yeah.
M
And
the
whim
is
next
yeah,
so
my
my
questions
relate
to
the
same
thing.
As
far
as
I
understand
the
psd,
can
I
it's
it's
ancillary
data,
but
potentially
could
have
multiple
contexts
if
I'm
understanding
it
correct
and
as
a
result,
don't
yeah
and
then
to
indicate
which
piece
is
what.
D
So
very
good
question:
I
would
like
the
psd
to
be
self-describing,
you
know
in
the
in
stack
data,
you
have
very
limited
space.
You
want
to
try
to
fit
everything
into
32-bit
chunks
and
it's
not
even
full-third
ruby
chunks.
So
what
you
end
up
with,
is
you
don't
use
tlb
structures
there?
You
use
the
indicator
flag
structure
there
in
the
psd
after
this
first
sort
of
header
that
says
this.
My
mfn
type.
This
is
my
subtype.
This
is
the
total
length.
D
Then
you
sort
of
say:
okay,
now
you
have
a
tlb
structure,
it
could
be
a
tlv,
it
could
be
next
header.
It
could
be
whatever
structure
you
want,
but
it's
self-describing
and
so
you're
able
to
parse
it
you're
able
to
do
multiple
functions.
You
know
some
of
them
might
have
a
lot
of
data.
The
in
stack
in
situ
oam
could
go
in
there,
a
bunch
of
other
things
could
go
in
there
and
so
the
the
psd.
D
M
We're
in
agreement
yeah?
No,
no,
I
think
yeah
so,
but
I
I
I'm
trying
to
make
a
point
that
we
need
somehow
an
an
event
of
some
sort
to
indicate
also
potentially
for
the
order
right
I
mean
or
because,
depending
on
the
use
case,
it
might
matter
which
part
of
the
psd
comes
before
the
other.
I
don't
know
I
mean.
D
Okay,
you
have
a
very
good
point
so
so
this
is
one
of
the
things
that
the
ipv6
guys
also
struggle
with.
So
the
idea
is
that
there
is
one
mfn
right,
that's
the
first
nibble
and
it
says,
there's
psd
and
that
and
that's
why
there's
a
total
length
of
psd
that
total
length
of
psd
can
be
broken
up
into.
Let's
say:
tlv
structures,
I'm
not
wedded
to
tlb.
But
let's
just
say
because
I
like
to
work
in
something
concrete,
so
I
can
have
multiple
tlvs
there.
D
So
I
can
have
something
that
says
this
is
in
situ
data.
The
length
is,
you
know,
30
bytes
and
now
here's
the
value
and
then
there's
something
else
that
says
this
is,
I
don't
know
some
other
psp
data.
The
length
is
16
bytes
and
here's
the
value.
So
I
I
have
all
of
those
now
organizing
those
and
putting
them
in
the
right
order
is
really
important
because
you're
processing
these
in
the
data
plane,
and
if
you
run
out
of
time
you
know
if
you
process
them
sequentially,
then
you'd
like
the
important
ones
up
front.
D
That
is
a
second
order
issue
that
I
don't
want
to
get
into,
but
you
don't
have
a
new
mfn
for
each
of
these.
I
don't
think
that
we
need
to
burn
a
new
mfn.
We
have
a
one
top
level
header
that
says:
here's
the
type
of
mfn,
so,
let's
say
mfn
value.
Nine
is
this:
is
the
new
miad
generally
extensible
mfn
post
track
data?
M
Yeah
so
katie,
my
point
is
just
I:
there
is
a
few
considerations.
We
have
to
take
into
account
right.
We
don't
have
to
solve
it
right
now,
but
I
think
it's
good
to
list
them
somehow,
and
maybe
some
of
them
are
not
important.
Some
of
them
are,
but
I
think
it's
good
to
list
the
things
we
should
consider
for
this
and
then
see
what
would
be
the
best
solution
for
it.
Somehow
right.
A
Yeah,
okay,
I've
closed
the
queue
because
we're
starting
to
eat
into
the
time
for
for
greedy's
next
talk
so
for
greg
and
stuart.
If
it's
really
really
short,
we
can
do
it
now,
but
otherwise,
I'd
like
to
ask
you
to
wait
for
the
discussion
period,
so
jeff.
J
Another
question
I
get
very
good
feeling
that
it
might
look
similar
to
ipv6
extension
headers
and
that's
something
that
we
can
discuss
in
on
the
list
and
actually
we
have
advantage
because
they
suffered
their
pains
and
got
their
cuts.
So
we
can
learn
from
their
experience
and
see
how
we
can
apply
it
to
what
what's
a.
G
So
just
quickly
something
the
working
group
needs
to
be
under
no
illusion
about
is
that
there
will
be
random
raw
ethernet
packets
floating
around
the
networks
for
the
foreseeable
future.
There's
no
way
of
forbidding
them
and
in
any
network
where
that
they
happen,
then
you
can
make
no
assumptions
about
that
first
nibble.
G
G
Without
you
know,
many
other
qualifying
things
that
tell
them
that
this
is
not
a
regular
ethernet
packet.
They
happen
to
pick
up.
D
G
But
I
don't
see
how
we
can
move
forward
and
abide
by
the
other
important
principle
that
we've
always
had
in
mpls,
which
is
that
we
don't
obsolete
any
existing
lsps
right.
Let's
do
it.
We
really
do
need
to
move
yeah
yeah,
yeah
yeah,
we'll
discuss
it
at
a
later
time.
D
Sure,
okay,
so
thanks
andy
for
the
next
slides.
So
here
this
is
about
the
forwarding
actions
indicators.
So
next
slide
wait
one
second
yeah.
D
So
some
of
the
questions
were,
you
know:
when
should
some
indicators
or
data
be
in
the
isd
versus
the
psd
and
we've
had
a
little
bit
of
talk
about
this,
but
maybe
not
enough.
So
I
think
we
need
to
do
more
of
that.
The
other
is
what
should
be
said
about
the
psd
in
the
isc.
So
in
the
in-stack
data.
What
do
I
say
about
the
post-stack
data
and
one
big
consideration?
D
There
is
the
in-stack
data
is
much
closer
to
hand
typically
than
the
post-track
data
which
you
have
to
pass
the
entire
start
to
get
to
the
third.
One
is
what
about
extensions.
I
mean
you
know
initial.
The
very
first
version
had
seven
or
eight
indicator
fields.
Sort
of
present.
There
was
a
field
that
said:
here's
how
you
extend
it,
but
we
haven't
gone
into
details
about
that.
D
So
what
if
we
need
more
indicators
in
the
same
fai
block
and
then
another
discussion
was
around
what
about
standard
indicators
that
someone
doesn't
understand
and
then
what
about
non-standard
indicators,
sort
of
user
defined
or
provider
defined
indicators?
I
think
that
would
be
a
very
nice
thing
to
add,
but
how
would
you
handle
it
so
sort
of
trying
to
bring
all
this
together?
If
you
go
to
the
next
slide,.
D
So
you
want
to
encode
this
very
compactly
compactly.
You
want
to
process
it
pretty
quickly
and
you
must
respect
the
bottom
of
trackpad
because
you
are
still
looking
at
what
theoretically
seems
to
be
a
label,
so
the
instax
data
you
want
to
be
very
careful
with
passimonious
with
and
you
want
to
process
it
quickly.
D
Next
slide,
the
post
stack
data:
you
have
you
know
your
label
stack
is
over.
I
mean
you've.
You've
hit
the
bottom
of
stack
label,
and
now
you
can.
You
can
be
a
lot
freer
with
things,
so
it
does
not
have
to
be
ultra
compact.
You
still
don't
want
to
carry.
You
know
gigabytes
of
data
in
there,
but
it
doesn't
have
to
sort
of
fit
into.
I
look
like
a
label,
even
though
I
have
all
this
other
information,
you
don't
have
to
respect
the
bottom
stack,
but
so
it's
a
lot
easier
to
work
with.
D
Ideally,
at
least
I
think
it
should
be
self-describing,
so
a
tlb
type
approach,
and
you
know
we
can
have
the
discussion,
you
know.
Is
it
a
next
header?
Is
it
a
tlb?
Is
it
something
else,
but
that
is
reasonable?
We
we
now
have
more
space
to
work
with.
D
So
given
this,
we
don't
have
to
put
too
much
information
in
the
isd
in
the
in
stack
data
about
what's
coming
after
the
postdac
data,
and
if
you
put
a
lot
of
information
there,
it
can
also
lead
to
confusion
if
the
in-stack
data
says,
oh
and
by
the
way,
expect
in-situ
om
and
I'm
just
picking
that
as
the
first
thing
that
comes
to
mind
in
the
I
in
the
psd
and
the
ps3
doesn't
have
it.
D
You
know
that
what
am
I
supposed
to
do
or
if
it
says
there,
isn't
any
institute
data
and
then
suddenly,
when
you're
passing
it,
you
find.
C
D
So
one
suggestion
is
the
indicators
should
only
say
who
should
look
at
the
psd,
it's
an
optimization
just
because
the
psd
is
so
far
away
or
potentially
far
away,
and
so
the
worst
case
is
that
every
hop
looks
at
the
plc,
which
means
you
scan
the
entire
label
stack.
You
come
to
the
bottom
label
and
say:
okay
now
I
have
the
psd
I'm
going
to
scan
it
and
see
if
there's
something
interesting.
D
But
ideally
you
know
you
could
optimize
that
away
by
saying
I'm
going
to
use
two
bits:
zero,
zero,
meaning
you
could
go
look
at
the
psd,
but
you
don't
have
to
zero
one
saying
if
you,
if
you
want
to
you,
can
but
if
you're
the
egress,
you
must
and
in
a
sense
that's
kind
of
a
overkill,
because
the
egress
is
going
to
see
it
anyway.
D
If
there's
one
zero,
every
hop
should
look
at
the
psd
and
then,
if
there's
one
one,
every
hub
must
look
at
the
psd,
and
this
goes
back
to
what
matthew
was
saying
in
in
terms
of
these
are
the
things
that
I
don't
want
to
send
to
a
node
that
doesn't
know
how
to
process
it.
The
other
ones
are,
you
know,
well,
maybe
zero
one
about
the
egress,
but
that's
only
the
egress.
D
If
you
think
about
the
per
you
know
the
hop
by
hop
thing,
and
if
you
have
a
must,
if
you
don't
understand
this
you're
gonna
drop
the
packet,
then
don't
even
route
it
over
knows
that
potentially
won't
understand
it.
So
this
is
suggestion
that
you
have
these
two
bits
in
the
isd
that
tell
you
who
should
or
may
you
know,
may
should
or
must
look
at
the
psd,
but
it
doesn't
tell
you
anything
more
than
that,
because
you
know
it's:
it's
you're
going
to
look
at
the
psd
when
the
time
comes.
D
If
you
have
cycles
to
do
it,
etc.
You
really
want
to
process
the
ist,
because
that's
what's
much
more
immediate
next
slide.
D
So
there's
this
whole
other
thing
that
we're
talking
about
handling
extensions
and
so
those
in
the
first
version
the
zero
zero
version
of
the
draft.
It
said
there
could
be
extensions,
but
didn't
talk
about
it
in
version
one
we
started
trying
to
put
more
into
it,
so
the
idea
was
to
put
an
ebit
that
says:
if,
if
the
e
beat
is
zero,
that
means
you're
done
and
ebit
is
one.
That
means
there's
more
bits
and
the
next
one
will
also
have
an
e
bit
and
so
on.
D
So
you
can
keep
processing
indicator
flags
until
the
e
bit
goes
back
to
zero.
So
it's
sort
of
it's
an
inverse
of
how
the
bottom
of
stack
bit
works,
and
so
I
decided
what
if
we
flip
it,
and
then
we
can
reuse
this
bit
for
other
things.
D
D
So
so
I
decided,
let's
invert
this
and
use
this
bit
for
more
than
just
extensions.
So
next
slide,
please
and
and
this
was
a
result
of
lots
of
different
discussions
both
in
the
working
group
and
outside
the
working
group.
So
the
current
thing
is
that
you
have
this.
What
well?
It's
not
the
current.
If
you,
if
you
flip
the
in
ebit,
you
have
something
that
says
this
is
the
bottom
of
indicators.
D
So
if
you
flip
the
current
meaning
of
the
ebit
as
long
as
it's
zero
that
you
have
more
and
when
it
says
one
you're
done
so,
if
you
have
a
very,
very
simple
fai
label
with
just
you
know
three
or
four
indicator
flags,
the
very
first
one
would
have
the
one
set.
D
But
if
you
have
more,
you
put
zero
and
then
you
have
more
bits
and
then
you
know,
if
you
have
even
more,
then
you
put
zero
again
and
then
finally,
you
say
one-
you
say:
okay,
I'm
done
with
the
indicator
section
the
flag
section,
so
you
can
see
on
the
on
the
right.
That's
the
flag
section.
So
the
next
thing
you
have
is
the
standard
data
corresponding
to
those
flags.
I
have
this
data
so
there
might
be,
you
know,
entropy
label,
there
might
be
a
slice
identifier,
they
might
be.
D
You
know
whatever
other
standard
data
we
have.
But
again
you
might
have
a
problem
that
someone
says
I
don't
I
mean
where
it
starts
is
pretty
simple:
it's
where
the
indicators
end
where
it
ends.
Well,
I
don't
know
because
I
know
only
how
to
process
these
two
bits,
and
so
I
get
16
bits
or
32
bits
or
whatever,
and
then
after
that,
if
there's
more,
I
have
no
clue.
So
what
do
I
do
and
we
don't
have
a
tlv
structure?
So
how
do
I
manage
that?
D
D
Yeah,
I'm
just
saying
that
again
what
if
there
are
50
standards
fields-
and
I
only
understand
five
of
them-
how?
How
do
I
deal
with
that?
What
if
there
is
user-defined
data?
How
does
an
implementation
know
where
it
starts
and
where
it
ends?
So,
let's
reuse
this
off
kind
of
thing
and
for
all
these
purposes.
So
the
next
slide
please.
D
So
this
is
what
it
would
look
like.
So
in
parallel,
you
can
see
the
end
of
stack
bits
which
are
going
to
be
all
zero.
There
will
be
some
labels
in
the
front,
some
labels
at
the
bottom
and
then
the
last
label,
which
has
the
end
of
stack
or
bottom
of
stack
bit
set,
and
then
you
have
this
thing.
That
is
the
bottom
of
section
bit,
and
so
in
this
one
fai
block,
you
have
zero
zero,
zero
one
that
says.
Okay,
these
are
indicators,
then
the
meaning
flips
and
at
zero
zero
zero
one.
D
D
So
if
you
reuse
that
bit
then
what
you
basically
have
is
30
bits
per
label
that
you
can
play
with
for
anything,
and
these
these,
the
end
of
stack
bit
is
completely
has
to
be
preserved,
yeah
just
so
that
your
label
stack,
the
entire
label
stack
is
sacrosanct,
and
then
you
have
this
end
of
section
bits
that
tell
you.
I've
got
the
indicator
section.
I've
got
a
standard
data
section.
I've
got
user-defined
data
again.
D
This
is
just
a
proposal
and
I
know
andy
will
say,
write
it
down,
so
that
people
can,
you
know,
throw
things
at
it,
but-
and
I
totally
agree-
but
I
wanted
to
present
it
here
so
that
people
have
an
idea
what's
coming
up
next
slide,
please
so
so
here's
just
a
quick
view
of
someone
who
is
looking
at
this.
The
cross
hatches
that
are
you
know,
top
right
to
bottom
left
in
orange.
Are
things
you
understand?
The
cross
hatches
that
are
top
left
to
bottom
right
in
red
are
things
you
don't
understand.
D
So
if
you
look
at
the
first
fai
label,
it
has
these
11
bits
that
you
should
be
trying
to
work
with,
and
you
understand
some
of
them,
but
not
all
of
them.
There's
some
extensions,
so
you
say
fine,
I'm
going
to
process
what
I
understand,
I'm
just
going
to
skip
the
rest.
I
know
that
when
I
get
to
that
b
bit
equals
1,
then
the
flags
are
over
and
then
I
start
processing
the
standard
data.
D
I
only
understand
a
little
bit
of
it,
but
I
know
if
I
keep
processing
until
the
b
bit
is
one
again
standard
data
is
over.
I
do
understand
a
little
bit
of
the
policy
stuff
or
the
user-defined
stuff.
Again
I
know
when
that
is
over,
and
so
I
have
come
to
the
end
of
the
fa
approach.
So
by
reusing
that
one
bit
I
can
define
break
up
my
fai
block
into
the
flag
section,
the
standard
data
section
and
the
user-defined
data
section
and
again
this
is
just
an
illustration
of
how
this
proposal
would
work.
A
I
actually
have
the
queue
closed
and
the
reason
is
that
we
have
that
we
have
to
move
on
to
john's
talk,
but
if
people
have
any
questions
or
comments,
please
wait
and
write
it
down,
and
then
you
can
ask
it
after
john's
talk.
So
with
that,
john.
If
you
take
the
mic-
and
I
will
put
up
your
slides.
A
John,
are
you
there
if
adrian
told
me
that
john
was
having
issues?
So
if
john,
if
you're
still
having
issues,
then
adrian,
can
you
speak?
A
A
A
N
You
can
take
it
over
okay
next
slide.
N
Okay
first
thing
is
this:
this
work
on
network
functions
is
derived
from
kurdish
drafts,
where
you
basically
have
a
special
purpose
label
and
then
a
bunch
of
bit
flags
that
identify
forwarding
actions
and
what
adrian
and
I
are
trying
to
do-
is
basically
just
generalize.
It
and
flush
it
out,
and
so
we
are
using
the
term
network
functions
rather
than
forwarding
actions.
N
We
have
two
special
purpose
labels.
One
is
hop
by
hop
and
one
is
end
to
end
and
the
p
nodes
only
look
at
the
hop
I
hop
special
purpose
levels.
N
This
was
a
suggestion
from
both
adrian
and
stewart
and
basically
it
allows
both
types
of
network
functions
to
evolve
independently
without
any
interference
and
both
are
completely
extensible
and
we
are
not
changing
non-label
fields
in
the
spls
and
then
what's
going
to
happen
is
when
you
define
a
network
function,
you're
going
to
use
it's
going
to
be
defined
in
an
rfc
of
some
sort.
N
We
defined,
whether
it's
hot
by
hop
or
end
to
end
what
bit
it's
going
to
use
in
the
network
function,
flags
which
I'll
describe
below
and
whether
it
has
ancillary
data.
If
it
does
have
ancillary
data,
what
is
the
ancillary
data?
Is
it
in
stack
or
after
stack,
so
that
you
basically
will
know
you
don't
need
any
indicators?
You
will
know
all
of
the
characteristics
of
the
ancillary
data
just
from
its
definition.
N
So
we
have
this
network
function
label
stock,
black,
which
is
an
spl
network,
function,
flags
and
in
stack
ancillary
data.
The
spls
we
already
talked
about
the
network
function.
Flags
is
basically
it's
what
we're
gonna
it's
gonna,
be
basically
a
registry
and
whenever
we
define
a
new
network
function,
we're
going
to
define
a
new
bit
which
identifies
that
network
function.
N
One
is
that
there's
no
reason
that
the
we
couldn't
have
two
or
more
label
stock
entries
for
a
given
network
function,
and
the
other
thing
is
that
we
probably
want
to
add
the
continuation
bit
for
the
ancillary
data
so
that
we
will
know
precisely,
even
though
that
doesn't
understand
the
ancillary
data
we'll
actually
know
when
the
label
stock,
black
label
stack
block
ends
anyway,
at
the
bottom,
there's
just
a
picture
showing
what
it
looks
like
next
stack.
Please.
N
And
the
way
it's
gonna
work
is
that
the
network
function
flags
are
in
order
and
a
given
node
will
understand.
The
network
function
flags
up
to
a
given
bit
position.
N
Basically,
the
labels,
the
label
stack
block,
goes
opaque
when
a
given
p
router
doesn't
understand
any
additional
network
functions,
and
so
what
that
means
is
there
will
be
basically
a
given
set
of
network
function
file
a
set
m
whose
network
function
flags
are
set
and
understood
by
that
node,
and
so
that
basically
says
the
size
of
m
is
less
than
or
equal
to
n
and
then
within
m,
there's
going
to
be
three
sets.
N
There's
a
set
x,
which
is
network
function,
flags
with
no
without
ancillary
data
network
function,
flags
with
in
stack
ancillary
data
and
network
function
flags
with
after
stack
data,
and
so
basically
you
will
have
a
set
of
network
function,
flags
that
are
set,
and
then
you
will
have
the
in
stack
ancillary
data
for
those
network
functions
in
the
stack
in
order
and
then
the
after
stack
data
is
in
the
same
order
as
the
network
function,
flags
that
were
set
in
the
packet
and
obviously,
if
the,
if
any
one
of
these
sets
is
empty,
there
is
no
ancillary
date
of
that
type
and
that's
it.
D
A
couple
of
comments,
one
is,
if
you
have
a
special
purpose
label
that
says
this
is
hop
by
hop
and
another.
That
says
this
is
any
two
I
mean
and
only
to
be
processed
by
the
end
nodes.
How
am
I
supposed
to
know
that
if
I
haven't
reached
that
position
in
the
in
the
label
stack.
N
D
So
let's
say
that
I
have
various
labels,
you
know
maybe
they're
segment,
writing
labels,
so
there's
like
five
labels
and
then
there's
an
spl
down
there.
That
says
I
have
data
that
should
be
processed
by
every
hop
or
you
have
a
similar
situation
where
you
have
five
labels
on
top,
but
I
have
data
that
is,
you
know
really
interesting
end
to
end.
D
I
have
to
come
down,
I
mean
you
know
I
can
do
my
forwarding
just
by
looking
at
the
top
label,
but
I'm
going
to
have
to
come
down
to
look
through
the
stack
and
say.
Is
this
interesting
for
me
now
or
is
this
interesting
for
me?
Only
if
I
was
an
endnote
is
that
how
you're
seeing
this
that
I
have
to
parse
the
label
stack
anyway.
Looking
for
the
for
these
spls
and
say,
oh,
this
is
the
spl
that
is
applicable
to
me
as
a
p,
router
or
not.
N
This
one,
what
we
said
was
the
the
hop
by
hop
spl,
always
precedes
the
end
to
end
spl.
Okay,.
D
D
Yes,
I'm
I'm
trying
to
see
what
is
different
and
there
are
a
couple
of
things
that
are
different.
One
is
in
my
proposal.
I
don't
want
anything
that
is
end-to-end
to
be.
D
D
N
D
Well
so
the
first
thing
is
this
whole
thing
about
network
function.
I
object
to
that
simply
because,
if
it's
related
to
forwarding,
I
don't
want
people
to
think.
Oh,
I
can
put
in
some
tutoring
computable
function
in
here.
I
just
want
an
action
that
I
do
right
now
and
yeah.
This
is
more
like
maybe
marketing
or
something
but
by
saying
function,
you're
talking
about
things
that
could
be
heavyweight
by
saying
action.
D
It's
like
something
I
do
now
and
move
on,
but
network
actions
is
good
yeah,
but
but
the
the
higher
order
of
it
is
the
the
way
that
I
had
to
find.
It
is
that
these,
following
actions
that
are
going
to
be
encoded
in
the
label,
stack
and
then
there's
going
to
be
a
bunch
of
other
things
that
you
want
to
do,
that.
D
You'll
encode
in
the
post,
stack
data,
and-
and
so
if
it
is
not
hop
by
hop
put
in
the
post
stack
data
and
if
you're
putting
in
the
post
fact
data,
then
you
end
up
with
all
I'm
going
to
tell
you
is
whether
you
need
to
look
at
the
post
stack
data
or
not,
and
so
I
can
put
things
that
are
hop
by
hop
in
the
post
stack
data,
but
post-type
data
is
generally
end-to-end,
but
anything
that
I
need
to
do
on
a
hop-by-hop
basis,
the
the
majority
of
it
I'll
try
to
put
in
in
stack
data.
D
E
Thank
you
thanks,
john
for
proposing
this
many
of
the
things
you
know
I'm
okay
with.
I
just
want
clarification
on
the
flags
and
the
metadata
post
tag
data.
E
Sometimes
a
flag
might
be
present
and
in
the
function
flags
as
you
call
them
or
forwarding
action
flags,
but
the
the
metadata
is
missing
for
that
type
length,
value
or
whatever
we
come
up
with,
like
the
data
associated
with
that
flag
is
not
in
the
post-stack
data.
Would
this
can
be
considered
as
invalid
packet
in
that
case,
or
this
is
something
we
need
to
still
define.
E
N
Actually,
what
when
we
define
a
particular
network
function,
we
specify
this
as
an
additional
part
of
the
behavior
yeah.
You
know
for
some
I
actually
like
network
actions.
Now,
I
think,
that's
good,
but
for
some
network
actions
you
know
for
some
reason
the
ancillary
data
just
didn't
get
put
in,
but
that's
okay
for
another
network
action,
throw
the
packet
away.
G
G
All
right,
so
a
couple
of
things
first
off,
if
you,
if
this
is
this
indication,
that's
in
the
stack
in
patients
in
the
stack
it's
inconvenient,
to
put
it
right
at
the
very
top
of
the
stack,
for
example,
in
segment
routing,
then
you
may
consider
an
indicator
for
the
presence
of
an
indicator
which
may
be
either
a
you
know,
a
real
indicator
or
the
use
of
a
fact
that
says
whether
it's
worth
searching
for
anything
of
interest
further
down
in
the
in
the
label
stack.
G
So
there
are
other
toys
that
we've
that
we've
got
to
bear
in
mind
in
terms
of
end
to
end
data,
I
think
karichi
sort
of
said
it.
But
I
want
to
be
absolutely
clear
above
the
top
of
the
of
the
bottom
of
stack.
There
has
to
be
some
indication
that
this
stuff
is
below
the
bottom
of
stack.
Otherwise
you
could
never
find
it.
There
be
sure.
G
G
N
D
Can
can
I
just
answer
stuart.
There
is
definitely
hop
by
hub
psv
yep
and
there
is
end-to-end
psv
yep.
What
I
did
suggest
is.
D
G
G
N
D
D
What
I
understand
this
proposal
is
saying
is
you've
got
all
four
combinations
and
I
don't
see
any
reason
for
putting
end
to
end
data
in
the
label
stack
put
it
after
the
label
stack,
you
know
let
the
label
start
get
be
done
with
when,
when
you
get
to
the
egress,
you
know
you're
ready
to
handle
the
post
tag.
So
that's
the
one
piece
of
this
that
I
don't
get.
L
L
I
understand
there
are
some
legacy
designs
with
user
labels,
but
we
just
keep
that
as
is-
and
we
should
continue
to
add
more
on
that
because
I
I
I'm
saying
that,
because
recently
I'm
doing
a
lot
of
research
on,
I
actually
write
the
the
passwords
for
the
different
style
for
header
header
design,
and
I
find
all
those
complications
in
the
labels
that
will
just
it
doesn't
help
most
of
times.
It
just
makes
things
more
complicated.
L
N
In
the
definition
of
the
process
for
evaluating
proposals
is
that
proposals
are
checked
with
the
hardware
designers
for
the
various
vendors
that
are
working
on
this
initiative.
That's
part
of
the
process.
L
I'm
just
express
my
you
know
perspective,
so
that's
all
I
I
got
now
for
now
right.
D
A
question
in
that
there
is
data
that
you
need
to
put
in
stack
that
you
want
right
there,
so
you
can
process
it
pretty
urgently.
So,
for
example,
a
slice
identifier,
you
cannot
treat
a
packet
correctly
if
you
don't
know
what
slice
it
belongs
to,
and
so
you
want
to
see
that
slice
identifier
right
there,
so
that
you
can
actually
do
that
anything.
You
put
a
post
stack,
you
have
to
parse
the
label
stack
to
get
there
and
that
that
can
be
an
onerous
task
for
every
hop
to
do
the
entropy
label.
D
I
know
you
were
saying
a
legacy.
I
I
don't
know
that
I
would
consider
this
legacy,
but
the
entropy
label
is
not
you
have
to
do
it,
but
you
can
do
a
much
better
job
load
balancing
without
going
to
the
end
of
stack
and
figuring
out.
What's
going
on
there,
because
you
have
a
nice
hash
right
in
front
of
you.
So
there
are
things
that
you
need
right
there
and
there
are
things
that
you
can
say
after
weight
or
the
things
that
you
say
I
would.
K
K
Yeah,
it's
something
different.
This
is
more
a
working
group
share
position,
I'm
concerned
about.
We
have
eight
base
spls
left
and
if
we
take
25
of
those
for
handling
the
the
indicators,
then
I'm
I'm
I'm
concerned
because
I'm
getting
on
the
low
side
of
available
spls.
N
Lower
yeah
I
mean
once
we
have
the
two
spls,
then
we
can.
Basically,
the
hop
by
hop
and
end
to
end
functions
are
pretty
much
extensible
without
any
more
spls.
K
Keeping
it
straight
is
a
very
strict
regime
on
how
we
allocate
them.
So
one
thing
is,
we
should
look
at
if
we
can
do
it
as
efficiently
with
just
one
baseline
base
spl,
and
I
don't
think
it's
any
way
around.
That.
D
First
of
all,
I
don't
see
a
reason
to
carry
in-stack
data,
which
is
end-to-end.
I
mean
if
there's
if
it
is
not
urgent
for
every
hop
to
do
put
it
in
the
end
of
put
it
post
stack
so
having
one
spl
saying,
I've
got
data,
that's
in
interesting
for
everyone.
That's
going
that's
going
to
process
this
and
then
having
just
bits
that
say
there
is
post
stack
data
for
for
everyone
or
this
post
actor
just
for
the
end
to
end
guys
or
there's
no
post
stack
data.
D
G
So
that
I
made
to
to
john
that
I
think
you
know,
maybe
I
could
encourage
people
to
think
about
is
whether
we
need
physical
definitions
of
these
bits
or
logical
definitions
of
these
bits.
So
this
is
mpls
right
and
mpls
gets
around
a
lot
of
these
resource
limitations
by
mapping
through
the
control
plane.
G
So
you
could
have
an
lsp
wide
or
even
a
network-wide
set
of
mappings
between
the
functions
and
the
physical
bit
that
they
will
occupy
in
the
in
the
network,
and
that
would
seem
if
that
would
reduce
the
number
that
we
that
we
needed
also.
I
am
sure
that
if
we
go,
we
think
a
bit
harder
about
the
encoding
we
can
probably
get
down
to
one
spl
for
both
functions.
F
Yeah
thanks.
I
I
just
wanted
to
to
wonder
about
kiriti's
point
there
of
the
for
end-to-end
data,
because
I
think
end
to
end
is,
can
be
blurred
a
little
bit
where
it's
a
a
routing
operation
that
has
to
take
place
at
the
final
router.
F
I
you
know
think
of
pop
and
go
type
operations
and
there
it's
not
quite
clear
to
me
whether
this
is
sort
of
the
end-to-end
data
that
you
put
after
the
stack,
because
it's
what
you
do
after
you've
written
the
label
or
you
it's
entering
data
that
you
do,
because
you
are
at
the
end
of
the
of
the
path
and
you
are
about
to
rip
the
label.
N
F
A
K
K
N
Correct-
and
I
think
that
there's
been
previous
discussion
about
that
in
some
of
the
proposals
from
huawei.
K
D
So
from
my
point
of
view,
if
everyone
I
mean,
when
I
say
hop
by
hop,
it
doesn't
necessarily
mean
everyone
along
the
along
the
path
has
to
process
it.
It
means
that
I
mean,
if
you,
if
you
have
this
simple
dichotomy
into
the
end
of
tunnel
and
hop
by
hop,
then
for
the
hop
I
hop
things
you're
saying
and
that's
why
I
want
to
have
a
shoot
and
a
must
right.
D
If
you
have
cycles
and
and
you
can
go
down
and
look
at
whether
whatever
it
is,
you
can
process
this
and
you
might
get
there
and
say:
there's
nothing
really
much
for
me
to
do
here.
D
D
That's
exactly
what
we
said
so
then
I'm
struggling
to
understand
what
is
you
know
the
fourth
case.
What
is
the
case
where
you
put
something
in
the
data
in
the
label
in
the
isd
that
is
really
only
to
be
processed
by
the
endnote,
because
you
know
if
it's
going
to
be
processed
by
some
guys,
that's
hot
by
hop,
and
so
what
I'm
basically
saying
is
you've
got
isd
that
is
end
to
end.
You've
got
potentially
rsv
that
is
hot
by
hop,
you've
got
psd,
that
is,
end-to-end.
You've
got
psc.
D
That
is
hub
by
hub.
That
first
case
I
see
that
is
as
end-to-end.
Don't
even
worry
about
it,
so
your
ic
is
hot
by
hop.
Pst
is
hub
by
hop
or
end
to
end.
That's
what
the
current
forwarding
actions
talks
about
adriana.
F
Yeah,
so
very
quickly.
Clarity
just
reminded
me
of
something
that
came
up
long
ago
in
this
discussion,
which
is
whether
it
should
be
necessary
to
distinguish
between
actions
that
or
or
yeah
functions
that
a
router
must
operate
on,
and
if
it
doesn't
understand
them,
then
it
it
cannot
forward
the
packet
and
functions
where
the
router
is
allowed
to
say
I
don't
understand
it
or
I
don't
want
to
operate
on
it
and
can
continue
to
forward
the
packet.
F
N
F
It
doesn't
work
in
the
definition,
I
think,
because
if
you,
if
you
receive
it,
and
you
don't
understand
it,
you
need
to
know
whether
or
not
you
can
forward
it
without
understanding
it
and
you
can't.
If
you
haven't
implemented
the
rfc,
you
can't
know
whether
you
can
forward
it
without
some
additional
information.
N
G
A
hat
on
we
didn't
take
questions
and
clarify
beyond
clarifications
for
the
earlier
pieces
of
this
we're
running
out
of
time.
I
think
we
need
to
give
people
the
opportunity
if
they
want
to
discuss
any
of
the
points
that
we
we
worked
on
during
the
session.
G
Yeah,
I'm
not
trying
to
shut
john's
discussion
down.
I
I'm
just
gonna
make
it
clear
that
people
can
discuss
other
things.
A
So
I
I
think
we
we've
reached
the
part
of
the
of
the
meeting
where
I'm
closing
the
queue
for
further
comments
and
we're
going
to
move
on
to
stuart.
So
stuart
can
give
us
a
summary
of
of
what
he's
heard
and
where
we
stand
and
what's
next
going
forward.
G
When
we
started
it's
my
opinion
that
we
need
to
work
a
bit
harder
to,
and
certainly
for
longer
to
bottom
out,
this
piece
of
work,
rather
than
just
take
the
first
things
that
come
to
mind
because
the
more
we
explore
this,
the
more
difficult
it
seems
to
be.
G
Hopefully,
we
will
have
some
insights
soon
that
will
allow
us
to
to
get
to
the
end
relatively
quickly,
so
the
requirements
they
need
to
be
studied.
We
really
do
need
some,
because
they
are
the
foundation
of
what
we
do
and
the
decisions
we
make
and
I
think
there
needs
to
be
more
input
in
the
odt
process
on
on
requirements
we
need
to.
G
We
need
to
find
a
way
of
giving
them
more
quality
time
and,
of
course,
time
on
the
list,
the
matters
of
how
we
encode
the
information
in
the
stack
covered
by
both
kiriti
and
by
my
john,
I
think,
he's
going
to
need
some
again
focused
time,
maybe
more
time
than
we
can
get
from
the
weekly
meeting.
Maybe
a
breakout
group
or
something.
But
there
are
several
areas
actually
where
I
thought
it
would.
G
We
could
do
with
some
focused
discussion
more
than
the
sort
of
10
minutes,
15
minutes
we
get
in
this
session
and
perhaps
more
than
we
can
get
in
when
we
mix
it
with
all
the
status
reports
and
everything
on
the
thursday
meeting.
So
I
think
there
are
a
number
of
cases
here
where
and
I
would
recommend
that
the
the
the
we
as
chairs
may
be
set
up
some
specialist
discussion
in
the
old
days.
G
G
I
think
there's
something
else
that
we
need
to
to
discuss,
which
is
the
processing
model
which
we
was
brought
mentioned
briefly
by
how
you,
but
again,
is
fundamental
to
some
of
the
decisions
we
need
to
make,
which
is
that
we
need
to
understand
what
an
mpls
router
looks
like
for
the
purposes
of
doing
these
and
what
constraints
we're
going
to
introduce.
Now.
G
Hopefully,
we
can
do
both
that
discussion
and
the
detailed
design
discussion
and
the
requirements,
in
particular
the
requirements
without
this
becoming
a
proxy
fight
for
these
solutions,
because
that
is
what
always
bogs
down
these
sorts
of
discussions.
So
I
think
that's
my
summary
of
where
we
are
and
what
we
need
to
do.
I'm
more
than
happy
to
hear
contra
views
from
my
co-chairs
or
from
the
working
group.
G
What's
the
audio
or
no
one
had
any
comment.
A
Yeah
there
there
was
a
comment
from
lou
in
the
in
the
chat
about
possible
virtual
interim,
and
we
also
have
a
comment
from
turek.
E
Stewart
do
you
think
the
weekly
meeting
that
we're
having
for
the
open
design
team
can
fit
into
the
the
the
breakout
the
discussions
that
you
know
well.
G
I
I
am
just
worried
that
one
and
a
half
hours
a
week
is
not
going
to
be
enough
to
get
our
heads
around
all
of
this,
particularly
some
of
these
things
where
your
thought
model
process
may
be
different,
but
some
of
these
things
you
really
need
to
think
about
for
a
bit
before
you
decide
whether
you
agree
or
not,
but
I
think
there's
no
reason
why
we
can't
why
we
can't
have
groups
reporting
on
the
weekly
meetings
just
to
give
a
status
update,
rather
than
necessarily
have
to
wait
until
the
next
free
weekly
meeting
to
do
the
detailed
discussion.
H
G
Well,
this
is
just
me
sort
of
feeding
to
my
my
colleagues
in
the
in
the
other
chairs
to
say
where
I,
where
I
got
where
my
head
got
to
when
I
looked
at
the
the
depth
of
discussion
that
we
were
having.
D
So
if
I
can
jump
in
yes,
you
know
we've
had
several
of
our
weekly
meetings
postponed
for
various
reasons.
You
know,
I
think
we
could.
We
could
fit
this
into
our
weekly
meetings.
If
we
really
needed
to,
we
could
have
you
know
more
weekly
meetings.
D
There's
10
minutes
for
you
know,
10
different
topics,
so
I
think
we
can
make
progress
in
the
weekly
meetings
but
to
steward's
point
it
might
be
effective
for
some
things
to
take
them
offline,
but
the
problem
is,
then,
you
have
it
offline,
then
you
have
to
bring
it
back
to
the
main
meeting,
but
you
know
making
forward
progress
on
this.
I
think
would
be
a
good
thing,
but
I
think
we
also
have
to
ask
ourselves
if
we're
using
our
weekly
meetings
in
the
most
difficult
way.