►
From YouTube: IETF-MPLS-20230601-1400
Description
MPLS meeting session at IETF
2023/06/01 1400
https://datatracker.ietf.org/meeting//proceedings/
A
D
D
D
C
D
C
G
B
D
D
Okay,
I'll
move
on.
Since
this
is
an
interim.
We
have
to
remind
everyone
of
the
note
12..
This
session
is
being
recorded,
it's
recorded
in
and
it
will
be
broadcast
on
YouTube
and
for
anyone
to
see
it
after.
The
note
well
is
the
set
of
practices
that
or
processes
and
that
govern
our
contributions,
as
well
as
the
different
processes
in
IDF,
so
I
will
leave
it
for
you
to
go
through
them.
If
you
haven't
already.
D
D
D
C
D
We
also
had
a
request
to
get
input
for
use
cases
that
are
relevant
to
PSD.
So
if
someone
has
a
strong
use
case
for
PSD
and
they
want
to
present
it
again,
please
come
forward
and-
and
let
us
know-
and
then
you
will
be
on
the
agenda
if
you
want
to
to
present
the
use
case
today,
we
have
one
one
such
use
case
and
Rakesh
will
be
presenting
it.
A
So,
yes,
a
small
kind
of
different
view
on
what
we
actually
asked
for.
We
are
not
primarily
asking
for
new
use
cases,
though
it
might
turn
out
to
be
new
use
cases.
We
are
actually
mostly
asking
for
how
the
existing
use
cases
actually
responds
to
the
questions
we
put
up
last
time
and
that's
the
the
important
discussion
we
need
to
have
we
and
that
actually
is
the
motivation
for.
Do
we
need
PhD
or
do
we
not
need
PST?
That's
where
we
want
to
go.
H
D
Okay,
I
I
also
attended
half
of
the
meeting
okay,
so
the
there
was
a
discussion
last
time
that
about
a
Paul
that
we
we
want
to
send
to
itu
right.
Now,
it's
it's
waiting
to
be
finalized.
There
is
a
a
write-up,
a
rough
write-up
being
prepared
and
actually
in,
in
liaison
that's
being
prepared
to
be
sent
to
the
itu
so
that
we
can
ask
if
a
label
14
can
be
reclaimed.
We
don't
have
I
mean
The
Impressions
we
are
getting.
D
D
C
D
A
A
A
I
J
Public,
just
like
Greg
Defenders
draft
but
I
think
it's
that
there's
good
reasons
for
the
first
nibble
draft.
We
know
that
there
are
things
which
make
use
of
the
first
nibble
and
heuristic
Fashions
and
the
first
nibble
draft
documents.
What
we
know
about
that
first
nibble,
so
that
if
people
insist
on
using
heuristics,
they
can
do
so
making
it
a
well-defined
D-Max
point
would
be
a
very,
very
different
preposition.
That
I
think
is
a
bad
idea.
F
F
B
F
C
C
D
One
from
the
top
of
my
mind
is
beer
and
that
net
I
believe,
if
I'm
not
mistaken,
so
they're
assigning
values
for
the
first
nibble
I'm,
not
clear
why
they
chose
to
do
that
versus
zero.
So
if
someone
has
the,
maybe
we
need
to
investigate
why
they
chose
to
use
the
specific
value
other
than
zero,
but
the
argument
that
you
could
use
zero
only
is
not
holding
today.
A
A
For
M
and
apsd,
and
then
you
receive
a
packet
and
you
only
use
the
first
nibble
as
the
D-Max
point.
You
cannot
be
certain
that
anything
that
has
the
number
we
assigned
it's
a
m,
a
PSD
packet,
so
it
could
be,
for
example,
a
ethernet
sudowire
without
the
control
word,
and
you
can't
differentiate
that
on
the
first
neighbor
alone.
A
On
the
other
hand,
if
you
actually
go
into
the
stack
and
look
at
the
bits
said
tell
this-
that
this
is
an
m,
a
PSD
packet.
That
information
is
very
strict
and
very
easy
to
understand
and
actually
give
you
the
right
answer.
So
you
don't
need
to
look
at
the
first
neighbor
first
neighbor,
that's
where
I
come
from
thanks.
E
So
the
first
nibble
does
actually
have
a
semantic
I
believe
the
semantic
is.
This
is
not
IP.
That
was
the
original
intended
semantic
for
it
for
sure,
and
it
is
distinguished
in
in
the
first
time
we
we
we
use
this
in
mpls,
which
was
on
sudowise,
the
that
was
distinguished
from
one
which
had
another
semantic
within
the
context
of
the
pseudo-wire
label.
E
E
I
do
not
know
why
beer
used
something
else
and
I
think.
Maybe
we
should
ask
beer
why
they
did
it
and
try
and
understand
whether
what
they're
doing
with
it
is
actually
safe
but
I,
don't
think
it's
safe
to
make
any
assumption,
certainly
in
a
p
router,
it's
not
safe
to
make
any
assumption
about
the
post
stack
information
of
whatever
sort
without
having
the
contact
of
the
context
of
the
label
stack
telling
you
explicitly.
F
F
F
C
E
E
F
As
we
pointed
in
well,
I
can't
remember
this
all
latest,
as
we
pointed
out
in
the
latest,
update
of
first
Naval
draft
and
nsh.
So
it's
a
sfc
nsh
plays
interesting
trick
with
the
first
nibble
and
that
might
result
at
some
point
in
the
future.
In
first
nibble
after
Alice,
mpls
label
stack
to
be
some
other
value.
C
J
C
D
J
J
So
we
wanted
to
make
sure
that
it
didn't
get
confused
with
value
four
or
six,
and
since
there
were
spare
nibble
values,
we
used
to
Value
other
than
zero,
but
frankly
in
in
retrospect,
we
probably
could
have
just
used
zero,
but
at
the
time
we
were
also
crying
to
say.
Well,
if
you
care
you're,
not
gonna,
if
you're
doing
some
more
complicated,
heuristic
you're
not
going
to
think
it's
something
else,
but
I
don't
think
anybody
made
use
of
that
aspect.
A
You
you
prescribe
to
put
a
certain
value
in
there,
but
you
don't
need
to
check
it
when
you
receive
a
packet
and
if
someone
else
sees
it,
it
could
draw
some
conclusions,
given
that
you
can't
distinguish
it
on
the
first
nibble
only
from
a
ethernet,
so
do
I
without
a
control
word
that
has
the
same
value
in
the
first
neighbor
and
that's
what
I
mean.
But
that's
what
I
mean
when
I
say
sound,
safe.
B
E
I
am
not
quite
so
confident
that
we
won't
ever
want
to
do
a
D-Max
on
this,
so
I
mean
I'll.
Give
you
an
example-
and
we
probably
should
have
been
wiser
at
the
time
when
we
designed
suited
work.
We
didn't
anticipate
that
we
would
need
an
oem,
because
OEM
wasn't
quite
so
popular
in
those
days
and
we
needed
a
D-Max
we
use,
which
is
why
we
introduced
one.
So
I
would
be
fairly
cautious
about
asserting
that
we
would
only
ever
need
one
value.
L
D
D
D
E
So
I
think
and
I
don't
remember
seeing
any
serious
discussion
about
how
we
would
make
you
work.
Certainly
it's
not
been
one
of
the
ones
that
immediately
sprang
to
mind,
so
we
we
should
add
it
to
the
list
of
sort
of
interactions
that
we
need
to
to
be.
Conscious
of
you
know,
together
with
pseudowires.net
and
beer,
correct.
A
I
kind
of
kind
of
agreeing
with
Stewart
that
okay,
we
could
dmax,
but
this
is
not
the
DMX
between
any
value
of
the
first
label.
That's
an
D
marks
within
the
m
a
protocol,
so
you
need
to
go
to
the
stack,
decide
that
this
is
m
a
PSD
and
then
you
go
look
what
the
value
is
and
if
we
at
that
time
actually
assigned
this
second
value
for
m
a
PSD.
We
can
do
the
d-maxing
within
the
protocol,
but
it's
not
a
general
demux.
C
D
E
E
You
go
down
and
process
the
PSD,
and
it
may
be
that
the
fullness
of
time
we
decide.
We
need
to
add
a
feature
that
needs
to
stand
out
on
on
its
own
at
the
first
nibble,
rather
than
be
be
buried
inside
the
the
actions
in
the
post
stack
data
oam
was
a
good
one.
So
supposedly
we
wanted
to
do
some
instrumentation
of
the
handling
of
Ms
of
of
this
work.
Then
you
might
decide
to
put
a
d-maps
at
that
point.
I
J
Have
I
actually
slightly
disagree
with
Stewart
because
and
well
I
strongly
disagree
with
Tony
I,
don't
think
yeah!
Well,
let
me
let
me
I'll
come
back
to
that
point
given
if
we
assume
that
we
have
an
indicator
in
the
stack
or
in
control
of
the
presence
of
post-tac
data.
If
we
decide
we
need
a
nuanced
post
that
data
Prime.
We
can
put
a
second
indicator
in
that
says.
J
Oh
actually,
what's
there
is
post-doc
data
Prime,
so
we
don't
need
to
rely
even
for
that
on
the
use
of
first
nibble
I
would
prefer
not
to
rely
on
first
nibble,
because
it's
small
and
overloaded
and
error
prone
I
I
will
grant
that
if
you
assume
control
there
is
control
that
tells
all
of
the
relevant
parties
that
there
is
post-doc
data.
And
if
you
need
post-doc
data,
then
you
could
dive
down
and
find
it
that
way,
but
even
if
you're
doing
so,
you
don't
need
the
first
nibble
to
verify
it.
J
Control
has
told
you
what's
present
if
it
doesn't
pass
right,
it
doesn't
parse
right,
but
if
control
tells
you,
you
parse
what
you
find
so
I,
don't
think
even
for
Tony's
use
case
which
I'm
still
not
convinced
of
but
I
it
can
be
made
to
work.
Even
for
that
use
case,
we
don't
need
an
actual
dmux
point
on
the
first
nipple.
B
E
There's
a
huge
Delight
from
mute,
sorry,
so
I
guess
I
I
I'm
a
bit
more
conservative
than
Joel
is
on
on
this
because
it
there
there
may
be
a
case
when
you're,
for
example
instrumenting.
This
is
the
the
stack
side
of
the
system
where
you
would
like
an
indicator.
That's
not
part
of
the
stack,
so
you
try
to
test
whether
your
sort
of
Stack
parameters,
work
and
I
don't
have
a
case.
E
I
am
just
trying
to
make
sure
that
I
could
build
it
if
I
wanted
to,
because
I
got
tripped
up
by
this
once
before
a
question
for
Tony.
What
would
you
do
if
you
in
your
world,
if
that
P
router
had
a
a
pseudo
wire
packet
without
a
control
word
pass
through
it
and
it
had
the
quotes
wrong,
quotes
value
as
the
as
the
address
such
that
the
first
nibble
meant
something
to
your
router.
E
Not
necessarily,
let's
just
say,
scroll,
this
a
bit
so
I
was
interested
in
the
p-router
case
right
because
sometimes
it
would
appear
that
we
that
some
people
would
like
to
do
stuff
in
the
middle
of
the
of
the
path,
so
you're
an
innocent
p-router
and
someone
is
sending
pseudoir
traffic
through
you.
Well,
so
someone
is
sending
M
A
information
through
you
and
you're
handling
that
just
fine
you've
been
taught
about
that,
and
then
someone
sends
you
a
a
pseudo
or
out
wire
packet
without
a
control
word.
E
I
E
Right:
okay:
well,
we
can
make
it.
We
can
Define
it
to
be
irrelevant
by
by
to
be
not
relevant
by
defining
out
of
scope.
A
the
the
case
where
a
p
router
looks
at
the
the
post
stack
data.
We
can
say
that
that
is
not
an
allowed
case
that
that
would
resolve
the
issue
in
that
no
P
router
would
ever
be
looking
for
M
A
information
below
the
bottom
of
Stack,
but
once
you
get
to
the
edge
node,
why
wouldn't
you?
You
have
a
service
label
there?
I
E
A
B
J
Thank
you,
I
think
Stuart
was
getting
at
what
I
was
thinking
of,
because
I've
been
trying
to
understand
what
Tony
is
assuming
and
I
finally
realized
that
he
was
assuming
a
combination
of
things,
namely
that
there
was
control
information
to
tell
you.
You
will
sometimes
receive
post-stack
data
without
a
label
step
without
any
indication
in
the
label
stack
and
the
way
you
will
tell
that
this
particular
packet
falls
into
that
control
is
by
looking
at
that.
J
First
nibble,
given
the
first
nibbles
are
not
reliable
and
just
waving
our
hands
and
pretending
they
are
won't
work
I
can't
make
that
work,
whereas
if
it's
either
a
service
label
or
an
overloaded
pseudo
wire
label
or
an
overloaded
or
a
multi-valued
end
label.
So
you
do
use
different
n
values
to
indicate
different
behaviors.
B
D
All
right,
I'm
I'm,
it's
my
turn
now
so
my
my
comment
is
I
could
signal
with
the
service
label?
Please
look
into
the
nibble
to
find
out
what
to
do
with
it.
So,
basically,
only
when
I,
when
you
get
the
service
label,
X
and
you're
allowed
to
look
at
the
first
nibble,
so
that
could
eliminate
the
the
concern
about
a
an
Ethernet
packet
coming
in
and
we
peaking
at
the
nibble.
B
K
Okay,
so
my
understanding
is,
we
have
clear
specification
about
the
egress
node
to
I,
use
the
service
label
or
some
other
context
label
to
together,
with
the
first,
enable
to
determine
the
context
on
the
content
of
the
following
data.
Well,
we
don't,
but
we
so
far
we
do
have
any
specification
about
how
the
transit
knows
to
use
the
first
Naval
to
determine
the
content
of
the
payload
on
the
other
data.
K
E
E
To
answer
these
question,
the
the
only
way
I
can
think
that
would
work
reliably
for
a
p
router
to
know
that
there
was
a
postdoc
data
would
be
that
there
was
an
m
a
label
and
that
context
was
provided
through
the
m.
A
label
I,
don't
think
anything
else
would
be-
would
be
safe
at
all
in
terms
of
our
previous
effort
of
deprecating
ethernet
pseudo
wires.
E
Without
the
control
word,
the
group
of
vendors
that
found
it
most
difficult
and
objected
were
vendors
who
were
in
the
transport
Network
business,
not
the
transport
layer,
but
the
transport
Network
and
they
were
in.
They
were
in
the
the
the
business
of
using
mpls
to
provide
the
transport
Network
and
their
equipment
was
incredibly
primitive.
Really
really
simple.
E
Tiny
number
of
functions
not
a
full-blown
router
at
all,
and
they
did
not
have
at
the
time.
So
it
was
communicated
to
us
the
capability
of
doing
anything
cleverer
than
what
they
were
already
doing
so
and
I,
and
the
thing
about
transport
networks
is
that
they
can
be
in
place
for
a
very
long
time
as
speeds
go
up.
The
equipment
tends
to
be
moved
to
other
duties.
So
I
honestly,
don't
know
when
we're
going
to
get
get
rid
of
the
ethernet
pseudoirs
without
control
words.
B
D
Let
me
just
join
in
and
say
yeah
okay,
so
we
discussed
two
mechanisms,
one
for
P
router
and
one
for
PE,
router
or
potentially
to
potentially
to
one
for
p
and
one
for
PE
for
finding.
What's
in
PSD
for
m
e,
do
we
need
to
unify?
Maybe
they
don't
need
to
be
unified
mechanisms
for
a
p
router
to
deterministically
know
could
be
different
from
the
PE
thanks
and
stay
with
you
next.
B
D
B
A
D
E
We
we
we
should
discuss
it,
but
whether
with
a
question
is
asked
on
the
list
as
chairs
or
whether
it's
asked
us
an
individual
contributor
he's
also
for
discussion
about
that
meeting.
It's
our
business
to
do
that
or
not,
but
I,
do
think.
The
question
should
be
put
to
the
list
so
that
we
can
get
wider
input.
G
B
B
C
B
K
C
K
A
G
G
G
This
is
where
you,
you
will
see
a
lot
of
this
in
situ
om
coming
into
the
picture,
so
so
just
to
step
back
a
little
bit
and
and
look
at
the
Telemetry
aspects.
I
have
just
a
few
slides
and
then
maybe
we
have
some
discussion
around
this
topic.
So
this
this
is
what
chairs
looking
for
ISD
PSD.
What
are
the
use
cases?
How
can
you
do
it?
Pros
cons
and
whatnot
and
I
thought,
maybe
going
back
to
the
Telemetry
might
give
some
more
context.
G
G
Now
it's
a
local
policy
on
what
data
to
be
sent
to
the
collector.
It
could
be
the
incoming
interface
outgoing
interface,
incoming
timestamp,
the
node
queue
information,
whatever
is
provision,
but
but
the
the
packet
is
lightweight
because
only
carrying
a
flag.
It
doesn't
blow
to
your
stack,
it's
just
a
basic
M
A.
So
this
is
one
one
use
case.
G
G
So,
just
a
flag
base
option.
The
second
one
that's
proposed
in
draft
CX
for
m
a
is
again
in
stack
option.
It's
a
little
bit
more
more
information
than
the
previous
option.
In
this
case
it's
an
alternate
marking.
So
you
have
two
flags.
One
is
flag
for
the
delay,
one
for
latency
and
you
have
flow
identifiers.
It
makes
a
controllers
life
easier
because
you
have
a
flow.
So
if
you
want
to
reconcile
the
data,
it's
coming
from
all
the
P
nodes
or
P
nodes
in
the
network
for
a
flow,
you
have
flow
ID.
G
So
you
make
the
controller
life
easier
again.
What
data
to
be
exported
via
Telemetry?
It
could
be
based
on
local
policy
and
again
it's
a
simple
put
it
in
ISD
things.
Don't
change
it's
quite
static,
and
this
is
this
is
one
proposal,
and
now
we
go
into
the
the
some
of
the
work
that
ippm
or
working
group
has
done.
Defining
there
are
two
rfcs
for
it.
Rfc
9326
contains
the
direct
export,
tlv
kind
of
information
and
it's
carried
in
the
packet.
G
It
has
more
more
things
than
the
previous
two
options,
so
you
you,
obviously
they
have
defined
flow
ID,
but
there
are,
there
are
basic
Fields,
And,
Then
There
are
optional
fields
that
you
can
put
on
top
of
it
again.
This
is
also
you
do
direct
export.
If
you're
doing
Hub
by
hop
I
mean
you
can
do
end-to-end
as
well.
But
let's
say,
if
you're
doing
hop
by
hop,
then
all
nodes
will
will
send
this
Telemetry
information
to
the
collector
one
good
thing
about
this.
G
This
direct
export
is
that
what
information
is
sent
is
maybe
it's
based
on
local
policy,
but
it
also
has
a
set
of
flags.
So
it
says
that
send
this
send
this
and
that
send
that
so
it
kind
of
gives
a
guidance
to
the
node
to
send
this
kind
of
information,
because
that's
the
use
case
and
that's
what
I'm
looking
for
and
I
need
queue
that,
for
example,
from
all
of
you
guys.
G
So
it's
it
makes
it
more
explicit
as
a
request
and
then
obviously
everybody
will
send
it,
but
the
the
the
cons
is
that
you
you're
carrying
information
in
the
packet,
so
the
iom
has
defined.
This
is
an
example.
I
copied
from
the
RFC
9326
as
it
has
IM
has
a
namespace
Flags.
These
are
the
flags
that
I
was
talking
about
and
then
various
flow
ID
sequence
number.
There
is
a
new
drug
to
do
extensions
to
say
also,
let's
carry
the
time
stamp
as
well
and
it
can
grow.
G
G
This
is
not
the
exhaustive
at
least,
but
these
are
some
of
the
drafts
that
we
have
in
m
a
and
there
might
be
more
drops.
But
in
this
particular
option
idea
is
that
the
information
is
collected
in
the
fixed
header
from
on
each
node,
and
it
goes
to
the
egress
PE.
So
there
is
no
need
to
do
Telemetry
from
HP
node
they
just
kind
of
stamp.
The
packet
with
whatever
information
is
needed
could
be
timestamp
as
requested,
or
it
could
be
interface,
ID
or
whatever.
That
might
be.
G
Will
digest
it
or
do
Telemetry
and
and
done
with
it?
So
it's!
This
is
a
different
option.
It's
a
recording
option
where
P
nodes
no
need
to
do.
Telemetry,
The
Collector
doesn't
need
to
reconcile
all
that
information,
because
it's
all
the
PE
node
egress
PE
node
would
have
everything
that
you
need
so
the
way
iom,
RFC
9197.
G
They
have
defined
again
the
the
option
type
just
like
direct
export.
So
you
have
namespace
and
Trace
type
and
whatnot
and
say
this
is
a
pre-allocated,
so
pre-allocated
means
you
have
fixed
buffer
in
the
scratch
pad
in
the
packet
itself.
That
everybody
writes
and
incremental
means
that
everybody
will
add
that
information
happen
to
it.
So
if
it's
a
10
half,
then
you
will
see
that
10
nodes
and
then
in
each
hop
on
the
right
side.
G
You
will
see
a
node
ID
or
interface
ID,
timestamp,
all
kinds
of
stuff,
and
there
are
a
whole
bunch
of
Trace
types
defined
and
depending
on
what
gets
enabled
you
allocate
that
much
of
space
and
you
build
one.
So
again,
you
can
see
that
with
so
many
options
and
stuff.
You
could
end
up
depending
on
how
many
hops
the
packet
takes.
You
can
end
up
with
large
amount
of
data
that
that's
carried
in
the
packet.
G
G
Some
things
to
consider
is
that
the
amount
of
telemetry
data
that
needs
to
be
processed
based
on
how
many
is
it
coming
from
your
entire
network,
all
the
PNP
nodes,
or
only
some
PE
nodes,
and
what
is
the
size
of
lse?
If
you
put
everything
in
the
stack,
can
the
end
cap
node,
put
that
big
into
the
labor
stack
or
or
how
does?
How
do
you
implement?
G
So
this
is
just
the
the
suggestions
and
now
going
back
to
the
questions
that
those
days
any
any
use
case,
motivating
PSD.
So,
for
example,
hubby
hop,
recording,
probably
a
good
option
for
for
PSD.
It's
very
I,
don't
know
if
it's
ISD
you
can
do
it.
Amount
of
data
is
large
and
you're
changing
the
labor
stack
with
timestamp
and
whatnot
along
the
way,
because
amount
of
data
is
large,
I,
don't
know,
it's
really
is
the
use
case.
G
Is
it
urgent
or
I,
say
it's
it's
a
it's
a
one,
a
good
solution
for
it.
If
you're
going
to
work
on
it,
that's
a
one.
A
good
solution,
impact
on
compatibility
issue,
I
think
the
first
nibble
is,
is
really
the
or
the
PSD.
It
would
be.
A
issue
related
to
the
compatibility
and
that's
all
I
had
on
this
topic.
The
rest
is
just
going
into
the
the
protocol,
extensions
and
stuff
about
iom,
but
it's
already
in
the
draft
it
was
presented
before.
So.
G
C
F
C
F
Fact
alternate
marketing
method
can
use
either
one
beat
flag
or
two
bids.
The
two-bit
provides
more
accurate,
latency
measurement,
but
effectively
even
one
bit
can
provide
good
packet
to
us
and
Alternate
marking
method.
Furthermore,
there
have
been
documented
how
to
use
one
bit
for
sufficiently
accurate
delay
measurement.
F
F
There
is
a
proposal
in
ittm
working
group.
It's
called
hybrid
two-step,
which
explains
how
a
packet
that
carries
operational,
State
and
Telemetry
information
can
be
carried
along
the
same
path
as
a
trigger
packet
and
then
arrive
to
the
terminating
node.
So
that's
all
the
information
is
collected
and
that
simplifies
the
correlation
by
The
Collector,
so
that
alternative
option
of
collecting
out
of
band
Telemetry
information.
F
F
Prohibitive
for
that
net,
because
the
debt
net
Paradigm
is
that
resources
allocated
so
that
OEM
does
not
disturb
in
a
normal
condition
the
data
traffic,
because
the
the
purpose
of
that
net
is
minimizing
packet
loss,
providing
bounded
packet,
reordering
and
very
low
latency
and
Jitter
per
package
so
obvious.
It
seems
that
loading
in
a
data
plane,
Telemetry
information,
operational
State
information-
will
definitely
change
the
economics
for
the
debt
net,
because
these
resources
will
have
to
be
guaranteed
in
reserve.
C
C
F
Each
node
sends
it
directly
to
the
collector
or
some
other
method.
As
I
mentioned,
the
hybrid
two-step
is
used
to
collect
along
the
path
out
of
band
and
then
so.
That's
simplifying
correlation
of
telemetry
for
a
given
flow.
That's
orthogonal
issue,
but
I
see
that
direct
expert
IAM
is
suitable
for
instac
m.
A
thank
you.
I
I
That
seems
like
an
egregious
emission
as
you
seem
to
be
trying
to
do
a
literature
survey
here
and
how
you
miss
that
I
don't
understand.
The
key
point.
I
think
that
you're
trying
to
make
here
is
that
there
is
a
use
case
for
PSD,
because
of
hot
by
hop,
recording
and
I
would
have
to
take
issue
with
that.
I
A
G
So
iom
defines
two
options,
so
one
is
pre-allocated
and
another
one
is
incremental
Trace
option
when
pre-allocated
the
encap
node
has
puts
the
scratch
pad
in
the
packet.
So
this
way
the
packet
doesn't
grow
as
it
travels
the
path
in
case
of
incremental
option,
that's
defined,
each
node
will
append
its
data,
so
packet
would
grow.
So
these
are
the
two
options
that's
defined
so.
G
That
right,
so
this
is
a
one
example
of
a
data
list.
There
are
many
different
encodings
and
it's
based
on
the
flags,
so
it
could
only
be,
for
example,
hop
limit,
node,
ID
interface,
ID
and
egress
interface.
Id,
only
two
lse
could
be
three.
It
could
be
four
or
different
combination
of
it.
This
Q
length
and
stops
and
is,
is
based
on.
A
A
A
G
A
D
G
D
D
One
advantage
I
mean
the
the
other.
The
in-band
collection
of
of
OEM
data
does
not
require
at
least
all
P
nodes
and
possibly
the
PE
node,
the
Ingress
node.
It
doesn't
require
the
Ingress
and
all
P
nodes
to
export
or
streamed
Elementary
or
even
contact
the
collector.
In
that
case,
only
the
egress
is
doing
that
correct,
so
the
egress
will
be
exporting
the
the.
G
G
D
I
So
I
disagree
with
what
lawa
had
to
say
about
pre-allocated,
somehow
fixing
the
problem.
It
doesn't
pre-allocating
a
kilobyte
of
data
and
sticking
it
on
the
front
of
the
packet
does
not
change
the
MTU
problem,
one
bit.
It
only
changes
where
the
packet
gets
dropped.
So
you
know,
pre-allocating
tons
of
space
is
not
a
good
solution.
C
D
J
I
D
G
H
Even
for
the
MPS,
you
add
this
new
MPS
label
stand
to
the
package.
It
also
increase
attack,
size,
so
I
think
it's
a
totally
depend
on
the
application.
The
when
the
Ingress
node
decide
to
allocate
some
space
for
data
connection,
it
must
take
16
into
consideration
if,
if
it
can
actually
fade
in
package
without
causing
the
NTU
problem,
then
this
similar
issue
is
faced
by
any
place.
H
This
iom
is
applied,
so
there's
this
not
unique
to
mpis
and
in
in
many
use
cases,
I
think
the
user,
depending
on
the
scale,
the
length
of
the
LSP
and,
depending
on
the
what
kind
of
data
the
user
really
really
want
to
connect
the
size.
Is
that
I
think
it's
under
control?
It's
not
not
a
lot
of
it,
so
in
this
case
mode
can
be
applied.
Thank
you.
E
With
them,
so
I
think
Tony
with
respect
the
either
using
the
internet.
The
diameter
of
the
internet
as
a
as
an
example
here
is
what's
well
known,
is
not
actually
relevant,
because
mpls
is
usually
deployed
in
a
limited
domain,
and
normally
you
would
know
the
size
of
the
LSP
or
the
expected
length
of
the
LSP
I
would
imagine.
E
Any
sensible
protocol
would
have
a
mechanism
for
dealing
with
the
case
of
when
the
predicted
size
was
exceeded,
that
it
took
a
defined
action,
dropped
the
packet,
stop,
recording
it
and
make
a
note
or
something
else,
but
I
don't
think
we
can
use
the
diameter
of
the
internet
as
a
as
an
example.
Here,
like.
F
The
problem
with
their
storing
the
timestamp
in
a
trigger
packet
in
a
trigger
data
packet,
is
that
packet
needs
to
be
processed
after
their
value
is
red.
So
that's
there
is
some
queuing
delay
which
adds
on
Jitter
and
effects
there
accuracy
of
the
measurement.
So
that's
another
argument
for
doing
the
collection
of
information
out
of
band
separate
from
the
packet.
C
F
I
I
I
I
Second
of
all,
the
diameter
of
the
internet
is
very
much
a
function
of
the
diameter
of
our
service
providers
and,
as
the
cut
of
all
the
vendors
on
here
will
gladly
attest.
There
are
many
of
our
tier
one
customers
who
have
a
diameter
of
their
Network,
which
is
a
significant
chunk
of
the
diameter
of
the
Internet.
It's
traversing
entire
large
networks
using
mpls
and
they're.
E
I
acknowledge
Tony's
Tony's
rebuttal
at
my
point.
I
am
yes
you're
right
about
both
and
and
of
course
it
is
the
customer
that
owns
the
MTU
rather
than
the
well.
Obviously,
the
service
provider
owns
it,
but
the
the
the
assembly
provider
needs
to
provide
the
customer
with
the
biggest
MTU
they
can
because
they
want
to
send
real
data
and
fewer
packets.
So
yeah
I
largely
agree
with
you.
Tony.
G
G
Yeah,
so,
basically
idea
is
that
when
we
talk
about
the
overhead,
it
was
a
three
bytes
per
node,
so
I
mean
if
you
have
25
nodes,
then
you
do
25
times,
I
mean
3.
75
plus,
you
add,
you
know
four,
eight
more
bytes
of
the
header
so
that
that's
the
math.
It's
definitely
not
huge.
But
again
you
you
had
to
the
service
provider,
owns
the
network
and
has
an
idea
about
what's
really
happening
and
there
are
other
mechanisms.
G
If
you
are,
you
have
limitations,
you
will
stop
recording
it
or
you
do
recycle
the
packet.
I
mean
the
recycle,
the
scratch
pad
and
you
overwrite
it.
So
there
are
other
means
of
it
as
well,
and
just
to
I
just
wanted
to
step
back
a
little
bit
about
the
first
three
use
cases
about.
They
are
related
to
sending
the
Telemetry
data
about
P
node
to
the
controller.
So
the
first
one
is
is
simple
in
the
sense
that
it
only
has
a
flag
and
it's
up
to
the.
G
There
are
two
things:
that's
missing
in
the
first
one:
it's
missing
the
flow
information,
so
it
makes
the
collector's
job
harder
and
it's
it
doesn't
have
information,
so
you
had
to
provision
on
each
node
what
information
to
be
sent.
So
this
is
that's
solved
by
the
number
two
where
you
put
the
flow
ID
and
now
it
makes
a
collector's
job
easier,
but
still
has
to
process
information
from
all
the
nodes.
Now,
if
we
say
that
I
don't
want
to
provision
all
the
nodes,
then
there
might
be
a
way
to
say
a
differently.
G
So
you
don't
need
to
go
to
this
extent
of
using
the
whole
ioam
direct
export
with
so
many
lses
and
this,
and
that
you
could
just
Define
and
say
that
I'm
I'm
not
going
to
provision
every
single
P
node
in
my
network,
but
my
packet
will
have
a
bit
flag
in
the
m,
a
that
will
say
just
export
this.
This
piece
of
information,
so
just
just
looking
at
the
problem,
see
what
is
it
that
we
need
for
Telemetry?
G
D
Thanks
Rakesh
I
just
want
to
give
a
heads
up
that
we're.
We
still
have
30
minutes
for
the
meeting,
we're
one
hour
and
a
half
through
yeah,
so
I'll
make.
If
we
want
to
discuss
the
last
items
on
the
agenda,
we
can
go
quicker
on
this
discussion,
but
it's
a
very
good
discussion,
we're
having
now
so
I
hate
to
stop
it.
Greg
you're
next.
C
F
F
So
if
somebody
wants
to
do
it,
it's
their
Network.
Yes,
certainly
on
a
point
of
challenge
to
correlate
information.
I
already
mentioned
that
there
is
a
proposal
in
ippm
working
group
on
hybrid
two-step
mechanism,
protocol
that
allows
collection
of
state
and
Telemetry
information
generated
by
the
data
packet
and
then
transporting
it
as
a
train
of
packets
sequence
of
packets
to
the
end
node.
So
that's
lifting
this
problem
from
The
Collector.
F
C
D
Okay,
I
think
I'm
going
to
be
quick.
It's
a
suggestion
to
the
to
recession.
The
office
of
iuem
in
band.
Did
you
for
a
large
number
of
hop
LSPs?
Did
you
consider
breaking
down
the
the
scope
of
testing
or
recording
the
segments
of
the
path?
Basically,
if
you're
traversing,
20
hops,
break
it
down
to
10
and
then
export
the
the
the
metadata
or
the
collected
data
and
then
record
the
next
10.?
You
know
just
an
idea
and
I'm,
not
sure
if
that
was
considered.
F
G
B
C
D
C
A
D
E
E
I
was
just
making
sure
in
my
mind
that
we
could
actually
write
into
the
stack
and
the
the
reason
for,
in
other
words,
overwrite
into
the
stack.
The
reason
for
asking
is
to
make
sure
that
the
stack
is
actually
a
read,
write
cache
rather
than
just
a
read
cache,
because
I
could
see
some
implementations
might
implement
the
mpls
stack
as
a
as
essentially
a
read
cache,
because
most
of
the
time
you
never
need
to
look
at
anything
other
than
the
top
other
than
the
label
after
the
ones
that
you've
popped
so
I'm.
C
I
Stuart
I'm
sorry
we're
always
going
to
follow
a
foul
of
implementations
that
do
unfortunate
things.
This
is
just
the
fact
of
life.
We
don't
control
what
people
are
going
to
do
and
they
don't
know
about
the
future.
So
the
way
that
ISD
draft
is
written,
it's
pretty
careful.
We
try
not
to
make
anything
that
is
basically
in
the
first
label
of
the
lse.
None
of
that
is
writable
because
there
are
going
to
be
implementations
that
are
going
to
Hash
that
for
entropy
purposes,
so
we
want
to
avoid
writing
there.
E
I
was
just
trying
to
understand
what
the
world
looked
like
and
whether
the
majority
could
do
this
or
whether
there
was
a
any
significant
minority,
That
Couldn't
or
indeed
any
minority
that
was
going
to
object.
So
I
was
just
trying
to
understand
what
the
LIE
of
the
land
was
I,
don't
know
what
the
scope
of
what
implementations
can
or
can't
do
in
terms
of
writing.
Overwriting
labels
that
are
in
the
stack,
but
not
at
the
top.
D
E
They
don't
worry,
I,
think
those
are
well
known
and
likely
to
to
be
around,
and
a
lot
of
that
of
that
is
all
done
in
terms
of
pointers
to
to
build
the
packet.
So
basically
you
you
have
a
pointed
to
the
thing:
that's
going
to
remain.
You
have
a
pointer
to
the
stuff,
you
want
to
add
in
ETC,
and
you
say:
hey
dma,
engine's
just
go
and
get
on
with
this
when
the
packet
goes
out.
E
F
C
F
Is
provisioned
to
a
system
and
so
that
thus,
the
transit
notes
will
be
obviously
decrementing
reflecting
their
residence
time
packet
being
in
the
system
so
by
decrementing
this
budget.
So
that's.
If
we
run
out
of
time,
the
packet
might
be
dropped
all
together,
rather
than
being,
you
know,
taking
more
resources
in
the
network.
So
that's
my
big.
E
H
H
Then
in
case
there
is,
there
are
actually
the
labels.
Deck
is
a
very
deep.
Then
the
Ingress
node
has
to
put
multiple
copies
of
as
the
in
a
different
place
of
the
label
stack
in
order,
because
at
some
points
this
will
be
popped
out
and
after
that
the
next
hobby
in
the
in
the
label
stack
can
be
accessed.
So
if
this
is
supported,
then
this
is
writable.
H
E
E
D
E
D
B
E
D
E
E
Okay,
well,
I
think
yeah,
maybe
it
would
it
would.
It
would
be
useful
I
think
if
those
people
who
still
have
attachment
will
have
attachment
to
Hardware
teams
were
to
ask
their
Hardware
teams
whether
these
sorts
of
things
are
feasible
or
whether
they
are
I.E
to
modify
a
field
within
the
label
stack
not
at
the
top
of
the
label
stack,
whether
those
things
are
feasible
or
whether
they
are
a
showstopper
for
their
design.
D
L
L
E
L
E
You
know
cell
phone
Edge
sort
of
things
which
are
built
to
a
budget
and
can't
really
do
very
much
and
yet
might
need
this
instrumentation,
and
it's
all
a
question
of
how
fundamental
this
change
would
be
for
for
such
routers
I
don't
know.
Maybe
I
am
just
worrying
about
nothing
but
better
to
worry
about
it
than
have
a
surprise
later.
B
I
Hello,
can
you
hear
me
now?
Yes,
we
need
to
file
a
bug
with
meat
Echo,
so
the
cheap
routers
are
not
the
problem.
They
are
system
on
chip
they're,
basically
a
CPU
dealing
with
memory.
They
have
full
right
access
to
the
packet,
that's
never
the
issue.
It
is
the
hardware
optimized
routers
that
are
the
question.
Yeah,
okay
and
I
can't
speak
to
current
Hardware,
but
at
least
20
years
ago.
This
was
not
a
significant
issue.
E
E
D
I
can't
do
that
myself,
okay,
no
I,
I
think
we.
We
talked
about
the
call
of
action
kind
of
for
everyone
who
has
access
to
Hardware.
You
know
to
get
some
feedback
now.
How
does
that
materialize
either?
Next
time
we
meet,
we
get
the
feedback
or
I
think
someone.
The
options
are
a
Paul,
or
maybe
someone
will
reply
to
your
email,
I
guess:
Stewart
I
want
to
say
that
we're
running
out
of
time
and
we're
actually
out
of
time
and
Noah
last
chance.
No.