►
From YouTube: IETF109-MPLS-20201120-0500
Description
MPLS meeting session at IETF109
2020/11/20 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
Yeah,
it's
okay
with
me:
what
about
mark
yeah?
What
about
10?
Should
we
wait
or
what
do
you?
No,
I'm
sending
him
a.
B
A
All
right
I'll
go
ahead.
Welcome
to
the
mpls
working
group
session
today
is
friday
the
last
day
in
this
iedf109.
This
is
a
two-hour
session.
I
am
tariq
and
we
have
loa
and
nick
as
co-chairs
our
work
working
group
secretary
is
mack.
Chen
he's
lost
in
action
right
now,
but
we'll
find
them.
A
Next,
this
is
yeah.
I
probably
have
seen
this
slide
multiple
times
by
now.
This
is
the
note
well
which
governs
the
policies
of
your
contributions
and
attendance
or
participation
in
itf
as
usual.
If
you've
not
read
it
or
you're
not
acquainted
with
it,
please
do
so.
A
The
blue
sheets,
as
usual,
they're
for
online
meetings-
they
you
don't
have
to
sign
in
they're,
automatically
collected
the
meet
echo.
If
you're
here
then
you've
you've,
you
have
the
right.
Url
jabber
is
integrated
into
meet
echo,
so
we'll
I
think
nick
and
lowa
will
be
taking
care
of
any
questions
that
pop
up
minute.
Taking
we
have
the
kodi
md
link,
please,
if
you,
if
you
can
contribute
to
a
minute
taken.
Please
do
please
do
so.
A
The
agenda
is
published
online
so
and
I'll
be
presenting
that
in
a
minute.
So
take
a
look.
If,
if
you
have
issues,
please
raise
it,
slides
are
also
available
for
offline,
taking
a
look.
A
We
think
that
we
will
be
on
time.
If
you
have
any
issues
with
this
agenda,
please
raise
it
otherwise
I'll
proceed.
We
ask
the
presenters,
as
usual,
to
stick
to
the
time
slot
they're
assigned
they're
assigned.
A
In
terms
of
errata,
this
time
we
have
two
reported
erratas
looks
like
a
pdf
has
corrupted
the
formatting.
There
is
a
for
rfc
6428.
The
reported
issue
is
with
the
remote
vfd
discriminator.
A
The
suggestion
is
to
reset
it
on
timeout
or
on
on
the
transitioning
to
the
down.
I
did
quote
rfc,
which
I
don't
have
the
number
now
because
of
you
know
the
garbling
of
the
text,
but
the
suggestion
is
that
if
a
period
of
detection
time
passes
without
the
receipt
of
a
valid
authenticated,
bfd
packet,
the
the
the
discriminator
must
be
set
to
zero.
So
this
is
kind
of
an
agreement.
We
will
take
it
back
with
the
ad
and
and
see
how
to
progress
on
this
errata.
A
Okay,
I
guess
no
one
has
an
issue.
The
second
errata
reported
on
rfc
6512,
it's
a
typo
since
p1
has
no
root,
should
be
since
p1
has
no
route
again.
This
is
a
simple
table.
Typo.
A
Research
group
and
you
will
see
that
there
is
a
response
from
actually
this
is
a
response.
This
is
from
mpls
to
itu
and
there
is
a
response
back
from
itu
to
npls.
On
the
same
on
the
same
matter,
we
have
another
separate
liaison
from
itu
to
mpls
about
mplstp
documents
for
information.
B
A
A
We
do
have
one
document
in
iesg.
It
was
expired,
but
the
authors
this
week
they
have
refreshed
the
document.
There
are
some
outstanding
isu
review
comments
that
are
being
worked
on.
This
is
the
feedback
I
got
from
the
authors
on
this
one.
A
A
A
Lowa
might
have
some
words
to
say
about
it
or,
and
we
expect
some
update
from
that
shares
on
this.
I
will
stop
here
and
you
know
ask
if
laura
wants
to
add
anything
on
this
document.
B
A
Thank
you,
okay.
Thank
you.
The
next
updated
working
group
document
of
interest.
We
have
the
mpls
bfd
directed.
This
is
also
controversial
there.
It
was
it's
been
lingering
for
a
while,
but
we
have
a
follow-up
with
a
meeting
with
the
authors
and
reviewer
carlos
underway.
So
my
understanding
is
nick
is
arranging
that.
A
Okay,
the
next
one
here,
the
lsp
ping
registries
update
it
is
in
worker
group
last
call
at
the
moment
recently
expired
documents.
They
are
working
group
documents,
so
this
the
first
one
is
rmr.
A
It
has
an
rmr
dependency
on
the
on
the
base
rmr
draft,
and
this
is
the
one
that
we
are
going
to
make
a
decision
on
soon
and
the
decision
will
reflect
on
on
this
expired
document.
A
We
have
emailed
the
authors,
notifying
them
that
this
expired
and
we
have
a
progress
update
towards
the
end
I'll,
also
expand
on
that
before
I
flip
to
the
next
slide
feel
free
to
interrupt
or
add.
A
If
there's
anything
from
the
offers
on
these
drops.
A
A
A
So
I
understand
that
lowell
you
will
be
following
up
with
the
with
the
ayanna
people
on
what
can
be
done
and
I
will
pause
here
if
you
want
to
add
anything
on
that
feel
free
to
jump
on
the
mic.
B
I
I
can
just
say
that
I
sent
the
draft
to
ayanna
at
the
same
time
as
I
first
first
hosted
it,
and
that
was
actually
the
day
before
the
cut-off.
So
there
was
not
much
time.
I
got
the
response
from
amanda
and
amanda's
point
is
that
she
likes
what
you
want
to
do,
but
the
current
tools
are
not
supporting
one
more
hierarchy,
a
hierarchical
level
in
the
end
radiuses,
and
I'm
going
to
talk
to
both
two
people
and
diana
people
and
see
what
we
can
do.
A
Okay,
thank
you.
Moving
on
the
the
drafts
colored
in
blue
are
on
the
agenda
so
I'll
skip
over
those
they
will
be
presented
today.
A
That's
it
updated
individual
documents,
we
have
the
lsp
ping.
Genetics
said
this
was
presented
multiple
times
and
we
received
from
the
author's
request
for
adoption.
So
there
were
these
two
documents:
the
egress
tlv
for
nelfek,
as
well
as
this
one.
They
seem
to
be
related.
A
The
chairs
have
discussed
this
and
we're
going
to
ask
for
the
author's
coordination
or
at
least
discussing
potential
duplication
there
and
get
getting.
You
know
back
reciprocating
back
on
on
what
comes
out
of
it
and
based
on
that,
we
will
proceed
with
a
request
with
adoption.
A
A
Again,
the
alive
individual
documents
without
update,
we
have
one
which
is
on
the
agenda.
The
rest
of
them
are
for
now
they
are
not
actively
being
worked
on.
B
Carrick,
that
is
a
truth
with
a
couple
of
the
things
we
need
to
say
when
we
talked
about
it,
I
forgot
about
it,
but
all
the
sfl
drafts
are
requested
to
be
progressed
by
the
authors
to
the
next
state.
So
that
means
that
you
have
documents
that
should
be
able
to
work
in
group
class.
Call
and
documents
should
do
the
working
group
adoption.
A
Okay,
that's
good!
Thank
you!
Yeah!
We
have
one
document
here
for
sfl.
At
least
I
see
it
yeah,
the
other
one
is
adopted
in
my
understanding,
so.
B
We
will
I,
it
has
been
a
little
bit
well,
my
heat
has
been
too
big.
I
haven't
really
been
able
to
dig
down
to
it,
but
we
are
almost
there
and
I
think
I
will
check
chatbot
all
the
sfl
documents.
F
E
I
only
to
understand
when
the
chairs
are
going
to
get
around
to
doing
any
doing
the
last
two
sfl
documents,
because
they
have
been
in
this
state
pretty
well,
since
the
last
ietf.
G
C
C
A
That's
a
good
question,
so
there
is
a
process
that
mpls
working
group
does
for
adoption.
They
we
do
ask
for
a
review
from
two
of
the
reviewer
teams
and-
and
that
usually
takes
another
two
weeks
so
based
on
now,
based
on
your
request,
I
expect
hiliti
that
we
will
initiate
that
review
and
it
will
get
into
the
process
of
being
adopted.
C
How
big
in
terms
of
pages
pages,
it's
eight
10
pages.
C
C
So
it's
yeah,
I
mean
there's
a
prototype
implementation
beyond
that,
we'd
like
to
make
it
real,
because,
especially
in
the
evpn
use
case,
there
are
issues
when
the
ce
dies
you
get
a
loop.
B
C
I
A
Thank
you
kiriti.
Anyone
else
in
the
queue
without
nick
yeah
next
is
rather
okay.
Should
I
go
ahead.
I
Yeah
hello,
so
I
wanted
to
just
give
an
update
on
draft
in
mpl
domain
a.m.
I
just
did
an
update
at
night,
so
we
the
four
points
that
the
registry
that
we
were
using.
I
It's
better
to
have
a
separate
registry
created
for
subtleties
and
and
I've
done
that
update
and
posted
the
latest
version,
and
I
think
that
you
know
it's:
it's
ready
for
an
adoption
call
chairs
can
look
into
it
and
take
a
decision.
I
J
I
Another
update
on
another
draft,
which
is
a
working
group,
draft
draft
ietf,
mpls
ep
oem,
so
this
was
adopted.
Wait.
A
We
have
a
progress
update
on
on
working
group
documents.
Still
I
haven't
so
hold
your
thought
until
then.
Thank
you.
Thank
you.
Anyone
else
in
the
queue
yeah
last
one
is
greg
great,
go
ahead.
K
I'm
not
confused,
but
what
I
see
in
a
data
tracker
on
mpls
point-to-point
to
point
to
multi-point
pfd,
is
that
it's
marked
as
a
candidate
for
working
group.
Adoption.
K
K
G
B
Greg
and
everyone
else,
there
is
just
one
point,
one
way
of
actually
getting
a
document
into
the
working
group
and
it
is
making
it
a
document
for
candidates
who
work
in
group
adoption.
So
when
we
start
doing
things
like
reviews
and
talking
to
the
authors
and
suggesting
things
we
need
to
put
it
in
in
the
candidate
status.
B
That,
okay,
good
okay,
the
next
thing
is
actually
we
will
start
the
adoption
poll.
That's
when
the
state
has
changed
so
when
when
we
say
if
this
document
is
for
any
working
group
within
itf,
it
is
for
mpls,
then
we
market
this
candidate,
and
that
means
that
he
can
work
with
it.
Otherwise
we
can't
do
anything
great
okay.
Thank
you.
A
Okay,
so
that's
it
from
the
queue
okay.
Thank
you
I'll
move
on
to
the
progress
reports.
So
these
are
working
group
documents
that
are
active.
The
first
one
is
spl
terminology.
The
current
revision
is
four.
The
working
group
last
call
is
issued
for
this.
Eta
is
two
weeks
from
now.
A
The
second
one
is
mpl
static,
king
and
it
has
the
next
steps
of
addressing
any
outstanding
comments
from
the
young
doctors
review
and
adding
a
json
instance
of
the
data
model
and
then
we'll
proceed
to
working
group
class.
A
Call.
The
third
one
is
mldp
yang.
The
current
the
revision
is
seven.
It
is
in
young
doctors
review,
but
I
heard
from
the
authors
that
there
are
no
outstanding
issues,
at
least
from
the
review
of
young
doctors
that
was
done
and
they're
ready
for
progressing
at
the
working
group.
Last
call,
so
this
is
also
in
the
queue
for
being
a
working
group
class
called
I'll
move
on
to
the
next
slide.
Unless
there
are
someone
in
the
queue.
A
The
mpls
vfd
directed
its
current
revision,
is
14.
We
already
mentioned
that
the
chairs
are
coordinating
and
meeting
with
between
offers
and
their
viewers
to
converge
on
on
this
one,
the
rmr.
We
already
talked
about
a
decision
that
the
chairs
have
to
make
about
about
this.
The
status
of
this
document
and
the
last
the
next
one
is,
is
dependent
on
on
the
base
nmr,
and
it's
going
to
be
affected
by
the
decision
that
we
will
make
on
that.
B
I
have
one
small
comment,
so
we
also
have
an
rmr
a
teeth
document
and
it's
also
dependent
on
the
base
base
document.
So
we
need
to
coordinate
with
the
these
working
group
shares.
They
need
to
follow
what
we're
doing.
A
A
B
L
Yes,
yeah,
there's
nagandra,
so
I'm
working
on
updating
this.
I
circulated
the
updated
one
just
to
get
a
confirmation
from
the
co-authors
by
today
or
tomorrow,
we'll
be
updating
the
new
version.
Okay,
thanks.
A
Okay,
I
think
this
is
the
last
slide
I
have
here
the
lsp
ping
registries
update.
It
is
in
working
group
last
call.
There
are
some
outstanding
comments.
We
are
requesting
the
working
group
to
review
this
document
and
provide
feedback,
so
this
is
an
open
invitation
to
give
feedback
on
this
document.
A
The
last
one
is
an
sfl
document.
I
heard
stewart
raise
concerns.
It
is
ready
for
working
group
last
call
and
it
shares
need
to
trigger
the
the
wglc,
the
working
group
class
called
and
yeah.
We
have
to
do
that
right
after
a
meeting
this
session.
Yeah
with
this,
I
conclude
my
progress
report
before
I
start.
B
Okay,
I
have
a
question
for
stewart:
are
there
any
dependents?
B
No,
that
the
courser
is
not
dependent?
I
I
mean,
should
I
take
the
rfc
6374
sfl
first,
or
should
I
try
to
adopt
the
individual
draft
first
or
you
cannot
do
it?
Do.
E
It
in
any
order
there
is
a
reference,
as
I
recall,
from
6374
to
the
control
draft.
B
A
Nope,
okay,
the
next
on
our
agenda
is,
is
rakesh,
I
believe,
and
it's
about
mpls
data
plane,
encapsulation,
4
and
c2am
rakesh.
Are
you
there.
M
M
Please
so
agenda
is
we'll,
take
a
look
at
the
requirements
and
scope
the
history
and
updates
since
the
last
itf
and
the
summary,
as
well
as
next
steps.
Next
slide,
please.
M
So
the
requirement
is
to
transport
the
iom,
data
fields
with
mpls,
encapsulation
and
iom
has
oem
information
like
timestamps
and
and
many
other
fields,
that's
defined
in
the
ippm
working
group.
There
are
three
drafts
that
listed
here
being
worked
on,
so
this
is
the
the
scope
and
edge
to
edge,
as
well
as
a
hub
by
hop
iom
is
in
the
scope
and
next
slide.
Please.
M
So
the
draft
has
been
around
for
a
couple
of
years.
It
was
in
spring
and
was
transferred
to
mpls
working
group
about
a
year
ago.
This
was
presented
at
the
last
itf
and
we'll
focus
on
the
delta
since
the
last
meeting
next
slide.
Please.
M
M
There
is
a
text
that
explains
why
different
labels
used
for
the
hop
by
hop
and
hyh,
basically
to
optimize
the
processing
on
transit
nodes.
There
is
tax
added
for
the
msd
consideration,
the
diagrams
or
the
the
headers
is
updated
to
show
the
extension
label
and
few
editorial
changes.
There
is
no
open
items
at
this
point
next
slide.
Please.
M
M
And
similarly,
there
is
a
variant
of
it
that
includes
the
this
iom
flow
indicator
label,
as
well
as
the
protocol
type
and
the
flow
label
and
block
number
and
next
slide
please.
M
So
we
we
are
requesting
for
hoh
case
two
special
extended
special
purpose
labels
for
it
for
the
indicator,
labels
in
a
variant
it
could
be
allocated
by
controller
or
signal,
but
prefer
the
ii
location
values
as
well.
M
Next
slide,
please
and
the
same
case
for
the
hub
by
hop.
So
there
are
two
labels
requested
for
mine
as
well,
and
next
slide.
M
Please
so
we
welcome
your
comments
and
suggestions.
Many
thanks
to
all
the
review
comments
that
we
have
received.
We
are
requesting
a
working
group
adoption
for
this
draft
since
the
the
base
work
is
done
in
ipv
and
working
group.
We
plan
to
keep
them
in
the
loop
out
progress
for
this
work,
so
that's
all
I
had
there.
M
K
Presentation
can
you.
K
Again,
explain
their
interpretation
of
two
extended
special
purpose
labels.
M
So
these
are
indicator
label
right.
So
the
indic
when
the
the
header
process
is
just
like
you
know,
entropy
label
in
the
label
indicator
label
that
ali
else
kind
of
thing,
so
it
when
you're
processing
it
tells
you
that
there
is
an
iom
data
field
and
then
it
can
be
used
to
trigger
the
iom
processing.
So
you
activate
it.
K
Right
but
for
entropy
label
indication
we're
using
just
one
entropy,
a
special
purpose
label.
M
Yeah,
so
if
you
go
to
the
figure,
if
you
go
back
on.
M
H
M
Yeah
yeah,
so
if
you
don't
have
this
protocol
type
0010.
M
If
a
transit
node
does
ecmp
hashing
using
the
ip
header,
it
could,
if,
if
the
value
happens,
to
be
zero,
zero,
the
the
for
ipv4
or
ipv6
case,
it
might
think
that
there
is
ip
address
there
and
it
could
do
incorrect
hashing.
So
this
is
to
fix
that
hashing
issue.
It's
not
mandatory,
but
if
there
is
a
customer
who
has
ipv
based
hashing
and
need
this,
then
we
recommend
to
use
this
indicator
label
with
zero
zero
one
zero
so
that
the
hashing
is
not
broken.
K
Okay,
but
again
here
on
the
figure,
so
you
have
extension
label
and
then
the
special
purpose
label
or
extended
special
purpose
labels.
So
total
labels
are
a
special,
extended
special
purpose
label.
But
I,
if
I
understand
correctly
so
you
mentioned,
that
you
request
allocation
of
two
extended
special
purpose
labels,
so
yeah.
K
Where
the
second,
the
other.
M
One
would
be
used
so
if
you
go
to
the
slide
number
six
previous
slide.
M
So
this
is
a
indicator
label,
so
this
is
without
the
protocol
type
field
and
the
next
one
was
with
the
protocol
type
field
and
the
label,
so
there
is
a
variant
to
it.
So
there
are
two
different
formats.
That's
why
there
are
two.
I.
M
Make
it
simpler,
yeah,
I'm
fine
with
it,
but
we
added
the
second
use
case
based
on
the
review
comments
and
the
working
group
had
raised
this
issue.
That's
why
it's
there.
K
M
Yeah,
if,
if
working
group
is
okay
with
that
yeah,
I
mean
no
issue
from
that
point
of
view.
It's
just
you
adding
one
more
label
in
the
stack
and
there
is
msd
consideration
and
all
that
stuff
right.
So
it
is
fine.
If
working
group
says
we
are
okay
with
the
slide
number
seven
indicator
label,
that's
fine
as
well.
K
Yeah,
okay,
I
I
think
that's
something
to
discuss
you
know
because
just
make
it
simpler,
less
options,
always
good.
Okay!
Thank
you.
M
Yeah,
thank
you
and
yeah.
We
can
have
email
discussion
and
this
working
group
has
consensus
to
just
go
with
that.
No
issues:
okay,
anyone
else
in
the
queue.
K
I
don't
think
so
yeah.
I
think
that,
since
this
is
individual
draft,
it's
for
offers
to
decide
where
they
want
to
go
all
right.
A
Okay,
thank
you,
rakesh
I'll
move
on
to
the
next
plot.
We
have
lsp
ping
for
sr
path:
sids
xiao,
you're,
presenting.
G
A
Can
you
still
hear
me,
I
do
yes,
okay,
it
went
that
silent.
I
think
xiao
was
having
some
technical
issues
yeah
and
now
he's
gone.
N
Okay,
hello,
everyone,
it's
xiaomi
speaking
here!
This
presentation
is
on
lsp
ping
for
sr
pass
seat.
This
is
a
0-0
version.
Draft
next
slide.
Please.
N
N
N
N
Next
slide,
please
about
past
segment
allocation,
as
described
in
the
working
group,
dropped
spring
mpis
path
segment.
There
are
several
ways
for
allocating
the
path
segment
to
the
ingress
node.
N
The
first
way
path
segment
is
allocated
by
the
egress
node
through
a
communication
channel
between
the
egress
node
and
the
ingress
node.
N
Currently,
the
details
of
this
way
are
for
further
study,
in
other
words
tier
now,
there
is
no
proposed
protocol
for
allocating
pass
segment
to
the
ingress
node
by
the
egress
node.
N
N
N
N
N
N
N
N
So
the
procedures
to
check
and
validate
the
received
as
a
second
list
pass
see
the
sub-tuv
are
similar
with
the
last
one,
and
the
only
difference
is
that
this
tov
includes
one
more
validation
key
than
the
previous
sub-tuv.
N
N
The
second
one.
Currently,
it
seems,
there's
no
psat
details
on
allocating
a
past
seat
to
identify
an
sr
segment
list
which
is
outside
the
scope
of
this
job,
because
this
draft
is
just
for
extending
svp
to
validate
the
control
plane
to
data
plane,
synchronization
or
pass
it
the
third
one.
Currently,
it
seems
there's
no
young
details
on
allocating
policies
which
is
also
outside
the
scope
of
this
chart.
N
The
fourth
one
currently
asp
chase
route
is
mentioned
in
this
draft.
However,
the
use
case
for
passive
trace
route
is
still
unclear
to
the
authors,
and
the
weather
is
really
needed
is
for
further
study
next
slide.
Please.
N
A
Thank
you.
Anyone
in
the
queue
and
nick
laura.
O
P
So
two
questions
first,
like
the
the
past
set,
is
a
list
of
labels
so
like
how
do
we
align
fact
stack
with
the
level
stack
and
to
fix
that
change
procedure?.
P
So
the
second
question
is:
we
might
need
a
type
of
field
in
the
sub
trv
to
define
to
separate
theory
type
for
ipv4
and
ipv6
types.
So
basically
in
tr,
v
format
shall
not
use
error.
Information
for
the
purpose
of
t
so
use
the
substitution
to
derive
the
type
is
not
a
good
practice
and
not
flexible
for
future
modification.
N
Okay,
thank
you.
So
your
ques,
your
first
question
is
about
alignment
between
label
stack
and
effect
right.
Yes,.
N
So
this
fact
subtly
is
taken
within
the
pink
package,
so
I
I
I
I
don't
know
whether
we
need
to
align.
P
Like
in
rfc
829,
so
it
defines
that
basically,
the
label
stack
and
the
fact
the
number
of
london
atoms
in
this
respect
should
match.
P
So
how
do
we
match
these
numbers
because,
like
the
past
segment
will
like
populate
a
list
of
labels?
But
here
we
just
use
one
fact
type
like
do.
We,
like
you,
know,
push
mob
facts
to
extend
the
label.
N
Q
So
far,
yes,
can
you
hear
me?
Yes,
okay,
very
good,
okay,
so
basically,
there
is
a
draft
that
is
on
the
agenda
as
well,
and
I
like
to
point
out,
because
this
is
a
good
example
of
some
complexity
that
comes
in
in
mpls
onn
machine.
The
draft
that
I'm
referring
to
is
one
that
again
are
going
to
present
is
on
the
sr
generic
label
sub
tlv
there.
Q
The
idea
here
the
idea
is
to
simplify
this
and
not
to
make
it
more
complex
and
keep
chasing
as
we
define
new
and
new
set
type,
keep
changing
a
definition
of
fact,
but
really
extend
an
notion
similar
to
the
nilfak
and
add
some
egress
validation
associated
with
it.
Q
So
I
would
like
that
you
take
a
look
at
that
draft
as
well
and
then
see
how
it
actually
works
for
your
use
case,
and
if
we
can,
I
mean
we
can
work
a
little
bit
more
offline
as
well
talk
a
little
bit
more
offline
to
explain
and
discuss,
but
I
think
we
can
do
a
simplification
using
the
sr
general
sub.
N
N
So
I
think
this
job
to
maybe
is
also
needed.
Q
So
and
and
that's
the
that's,
the
main
thing
is
that
the
synchronization
between
control,
plane
and
data
plane
is
a
goal
that
that
ampersand
machinery
started
with,
but
it
has
a
large
cost
for
deployments
as
service
provider
deploy,
new
technologies
on
m
start
to
become
behind
and,
and
there
are
some
challenges,
so
I
so
I
think
just
for
that
and
just
chasing
that
that
role
for
defining
a
new
effect
type.
I'm
I'm
personally,
don't
like
that.
Q
But
but
anyway,
I
think
we
should
talk
a
little
bit
more
and
then
see
at
least
for
the
data
plane
validity.
How
can
you
use
the
sr
generic
label
subtle
for
the
past
segment
use
case.
N
Okay,
we
can
discuss
the
offline.
A
Okay,
thank
you
mike
matt
go
ahead.
H
Let's
show
you
about
so:
what's
the
purpose
of
to
carry
what
it
did.
N
The
purpose
is
to
check
whether
the
power
segment
allocated
to
the
ingress
node
can
can
be
forwarded
before
the
to
the
correct
egress
node.
The
euclid's
node
can
check
whether
it
is
the
right
pass
segment.
Is
the
correct
segment
that's
allocated
to
the
ingress
node
so
that
that
that
that's
the
intention
of
this
job.
N
Because
there
are
there
are,
there
is
a
working
group
draft
in
idr
working
group.
I
think
for
idr
part
segment
in
that
draft
per
segment
can
be.
I
can
be
used
to
identify
the
two
different
things.
One
thing
is
sr
candidate
path.
The
other
thing
is
sr
pass
specified
by
seed
list.
P
P
N
A
J
Okay:
okay,
welcome
to
join
the
pro
second
work,
and
luckily
I
have
the
order
of
the
pgp
policy
jobs
and
I
think
it's
that
it's
valuable
to
do
something
associated
with
to
a
part
segment,
but
I
don't
really
think
the
mechanism
is
valid
right
now,
I'll
take
some
time
to
read
it.
Thank
you.
A
All
right:
okay,
thanks
I'll
switch
over
to
the
next
presentation
and
the
interest
of
time,
okay,
greg!
Thank
you!
Thank
you
and
greg
you're
up
next.
Okay,.
K
Great
next
slide,
please
all
right.
K
Okay,
so
this
is
an
update
to
our
draft
on
point
to
multipoint
bfd
applicability
to
mpos
lsp,
and
so
we
have
two
new
experts
joining
the
work,
welcome,
donald
and
guyan,
and
so
to
recap
the
motivation
that
point
to
multipoint,
mpls
lsps,
are
being
used
and
will
be
used.
So
their
issue
is
that
rfc
5884
that
defined
only
point-to-multipoint
bfd
applicability
to
mpos
lsp.
K
Recently,
two
rfc
has
been
published
by
the
working
group.
It's
rfc
8562
for
bfd
for
multi-point
networks
and
8563
bfd
for
multi-point
networks
with
active
tails.
K
K
Yes,
and
to
mention
that
seamless
bfd
seems
not
to
be
at
least
now
defined
how
it
works
over
multi-point
multi-class
networks
because
point
to
multipoint
bd
uses
demand
mode,
and
there
is
no
three-way
handshake.
K
It
requires
bootstrapping,
the
bootstrapping
that
we'd
propose
could
be
using
the
periodic
lsp
ping.
So
if
we
have,
if
a
new
tail
joins
the
multicast
distribution
tree,
then
the
next
lsp
thing
will
bootstrap
the
session.
K
There
are
some
changes
to
the
process
of
bootstrapping,
as
defined
in
our
rfc
5884,
so
because
their
head
end
does
not
is
not
interested
in
a
discriminator
and
actually
the
tail
does
not
allocate
one
for
the
bfd
session.
So
we
recommend
to
use,
do
not
require
mode
for
the
lsp
thing
that
includes
the
discriminator.
K
Also,
there
are
point
to
multi-point
vd
session.
Over
mpls
osp
can
be
bootstrapped
using
a
bgp
pfd
attribute
that
is
defined
in
best
document
on
nvpn,
fast
failover.
K
So
what
changed
historically
for
ipudp
encapsulated
in
ip
edp
encapsulated
oem
packets
in
under
mpls?
We
used
to
use
ipv4,
loopback
range
or
recommend
to
use
any
address
from
that
range
and
then
for
ipv6
ipv4
mapped
addresses.
So
basically
the
same
address
is
mapped
into
ipv6.
K
What
is
interesting
that
in
ipv6,
this
address
range
doesn't
have
any
special
meaning.
So
it's
not
the
loopback
addresses
and
I
was
demonstrated
that
available
ipv6
stack
will
generate
a
ping
to
the
one
of
any
of
these
addresses,
so
it
was
recommended
that
to
use
the
only
I
look
back
address
that
is
defined
for
ipv6
in
rfc
4291
address
one
slash.
K
128
is
the
only
loopback
for
ipv6
and
since
we're
using
one
address
for
ipv6,
it
would
be
logical
to
use
one
address
for
ipv4
encapsulation
ipedp
encapsulation
of
oem
packets.
So
in
this
specification
we're
proposing
to
use
128,
7,
0,
0,
1,
slash
32
and
one
slash
128
for
ipv6
as
destination
ip
addresses
using
ipudp
encapsulation.
K
Rc
8563
defines
three
types
of
head
notification:
the
multicast
polling,
their
composite
wallet,
which
combines
multicast
falling
using
their
multicast
distribution
three
and
then
unicast,
following
using
paths
that
are
not
using
the
same
links
as
a
multicast
distribution.
Three
another
and
the
third
option,
but
not
defined
but
mentioned
in
the
rfc,
is
head
notification
without
polling.
So
in
this
draft
we
provide
a
more
detailed
explanation
of
the
mechanics
and
how
head
notification
without
polling
operates.
K
So
basically
it's
uns
solicited
event
triggered
option
next
slide.
Please.
A
If
you
can
wrap
it
up,
yep.
K
Three
more
so
this
diagram
just
presents
their
mechanics
as
that
we
have
a
p
and
p
one
that
is
a
head
end
and
p,
four,
five
and
six
as
it
tails,
and
if
we
network
failure
occurs,
then
the
tails
will
generate
unicast
pole
to
the
head
end
and
head
end
will
send
the
unicast
final
and
then
can
take
corrective
actions
next
slide.
Please.
K
So
we
welcome
common
suggestions
and
questions
about
the
proposed
solution
and,
as
I've
mentioned
in
the
discussion
earlier,
I
really
appreciate
that
this
document
being
put
as
a
candidate
for
working
group
adoption.
Thank
you.
A
Thank
you
greg
anyone
in
the
queue.
No,
she
was
empty.
A
K
A
R
Oh,
am
I
audible?
Yes,
you
are
go
ahead.
Hi
I
am
deepti
and,
along
with
the
authors,
we
are
presenting
egress
tlb
for
the
new
effect,
as
extension
to
the
nilfek
next
site.
Please.
R
So
now
in
this
slides,
we
will
be
touching
the
springtea
requirement
for
the
om
and
how
nilfek
fits
in
that
picture
and
egress
tlv
how
it
completes
the
how
how
it
completes
the
whole
om
requirement
with
the
example
next
slides.
Please
sure.
R
So
the
srt
paths
are
built
by
stacking,
the
labels
that
represents
the
nodes
and
links
in
the
using
the
adjacency
set
node
set,
and
all
this
this
give
requirement.
So
the
basic
om
is
not
basically
hop
by
hop
basis
which
give
rise
to
a
ping
and
trace
route
for
this
path.
R
Now
the
idea
to
you
verify
these
labels
stack
by
sending
the
mpls
or
echo
request
packet
with
entire
label
stack
along
with
the
same
data
along
on
the
same
data
plane
as
used
by
the
data
traffic
in
certain
use
cases
where
the
srt
paths
are
built
by
controller.
The
hidden
routers
may
not
have
the
complete
database
of
the
network
or
may
not
be
aware
of
the
fact
associated
with
the
labels
that
are
used
in
the
label
stack
like
static,
lsp
labels
and
others.
R
R
R
R
So
we
can
always
build
an
intelligent
application
which
will
help
to
validate
or
do
the
extra
additional
verification
on
the
ingress
for
the
on
using
the
data
sent
by
the
transit
node
to
verify
the
data
plane.
Data
forwarding
plane
is
same
as
the
label
stack
path
provided.
R
So
since
the
knee
effect
carries
only
label
information
and
no
fake
related
information,
it
may
happen
that
that
there
is
a
high
possibility
that
the
packet
may
be
misforwarded
to
incorrect
destination,
even
though
the
ping
and
trace
route
returns
success.
There
is
another
thing:
when
router
in
the
label
the
stack
path
receives
mpls
eco
request.
R
There
is
no
definite
way
to
decide
on
whether
it's
egress
or
transit,
and
it
solely
depends
on
the
receive
label,
stack,
thus
to
use
nif
in
the
for
the
srt
parts,
where
fake
validation
is
not
possible,
we
should
have
additional
information
regarding
egress
so
that
the
egress
validation
can
be
completed.
R
R
Piece,
so
this
is
where
the
egress
tl
we
come
into
picture.
So
this
is
a
very
simple
tlb
which
has
the
end
point.
The
srt
path
end
point
as
a
prefix
inserted
in
it.
So
even
if
we
have
multiple
knee
effect,
the
last
nail
effect
end
point
will
be
the
prefix
used
in
the
egress
tlv.
R
Now
how
it
helps
in
our
determining
the
egress
validation
is
as
nilfek
as
in
rfc
8029.
If
the
outermost
effect
is
neil
feck,
all
the
transit
node
will
avoid
to
do
the
fact
validation,
so
the
label
stack
will
use
to
forward
the
packet
at
the
last
neighbor.
When
the
label
stack
is
like
reached
to
the
last
label
last
router
there
it
will
check
for
the
egress
dlv
and
the
prefix
is
matching
with
the
any
of
the
interface
ip
addresses
or
the
local
loopback
address,
and
thus
determine
key.
R
That
is
the
egress
for
this
path
or
not
in
case.
If
it
is
failed
to
match
with
the
any
of
the
interface
ip
address,
it
will
send
a
failure
saying
that
it
is
a
non-compliant
or
no
mapping
is
present
next
slide.
Please.
R
So
this
is
the
example
where
I'm
taking
like
a
srt
route
with
the
label
stack,
provided
it
has
four
segments
next
slide.
R
R
R
So
all
in
where
the
the
advantage
of
adding
a
nil
like
a
egress
tlv
is
none
of
the
in
between
routers,
like
transit,
router
need
to
be
upgraded
to
to
accommodate
the
egress
tlv
as
it
is
optional
and
on
the
transit
router.
We
are
not
checking
for
the
egress
tlv,
so
it
helps
to
have
the
backward
compatibility.
R
R
We
can
go
to
the
next
slide
at
the
end
of
the
slide.
Yeah
next
slide,
so
here
once
on
r7,
when
the
label
stack
reached
to
the
last
label,
it
will
go
and
verify
for
the
egress
tlv
if
it
matches
with
the
interface
on
any
of
the
ip
address
on
the
r7
with.
So
it
will
return
with
the
thing
key.
It
is
a
egress
for
this
label
stack
and
does
the
egress
validation
can
be
achieved
using
the
knee
effect
next
slide.
Please.
R
We
request
the
reviews
and
comments
on
this,
along
with
like
working
group
adoption.
R
A
M
You
anyone
in
the
queue
yeah,
we
have
two
people
in
the
queue
xiang.
P
P
R
P
And
how
we
handle
adrian's
is
it
so
if
the
last
segment
is
not
a
prefix
set
and
so
for
buying
like
for
binances,
these
kind
of
things
are
like
upstream
root
assigned
or
popped
labels,
so
how
to
take
a
egress
for
this.
P
So
another
thing
is
like.
I
noticed
that
you
have
two
trvc
in
the
effect,
so
one
equals
trv
and
new
vector
trb,
then
how
we
align
their
fax
stack
and
the
label
stack.
So
according
to
rfc8029,
so
fact
stack
and
the
label
stack
should
match
so
the
number
of
atoms
should
match.
So
then
they
can,
you
know
so
just
break
it.
R
See
yeah
currently
for
in
this
case,
for
the
complete
label
stack.
Only
one
nail
effect
is
sent
because
sending
a
multiple
meal
effect
doesn't
make
any
sense,
and
neil
feck
does
provide
to
give
the
it
can
send
for
the
one
label
and
it
can
send
for
the
multiple
labels
as
per
the
same
rfc8029.
R
So
that
is
one
the
answer.
R
Use
the
nil
tlv
nilfex
up
tlv.
That
requirement
is
not
how
it
need
to
be
followed.
As
per
the
rfc.
You
can.
R
No,
the
thing
is
once
the
outer
label
outermost
fake
stack.
R
You
avoid
the
the
router
doesn't
go
for
the
validation,
it
just
skipped.
The
fake
stack
validation.
So
there.
P
P
R
I
can
point
you
to
the
section
which
tells
that
it
does
not.
So
there
is
a
section
on
the
rfc
80294.4.1.
Like
start
validation
effect
validation,
where
it
tells
clearly
if
the
outermost
effect
of
the
target
fake
stack
is
the
knee
effect,
then
the
note
must
keep
the
target
fake
validation
completely.
A
Okay,
it's
good
at
this
time
to
take
this
discussion
on
the
mailing.
A
Provide
the
reference
deepti
so
that
we
can
follow
up
on
that
zafar
you're
up
next.
Q
So
thanks,
I
have
a
similar
question,
like
jay
has
said
so,
but
I'll
come
to
the
rest
of
the
question
that
I
had,
which
is
not
covered.
Q
So
basically,
there
was
some
discussion
in
the
context
of
the
generic
effect
tlv
and,
and
then
one
of
the
one
of
the
thing
that
came
out
of
that
discussion
was
we
extend
the
nil
fact
with
we're
discussing
with
shredder,
so
we
had
discussed
this
in
past
some
and
and
then
I
I
think,
what
in
the
genetic
fact
draft
what
we
try
to
do
is
we
also
try
to
address
the
agency
state?
The
peer
node
peer
sets
it
and
flex
I'll
go.
Q
So
in
the
context
of
the
sr
generic
labels
of
tlb,
there
is
a
lot
of
synergy
between
the
two
drafts
they
address.
The
goals
are
similar.
We
have
been
talking
as
well
quite
a
bit
on
this
and
we
did
discuss
this
as
well.
The
new
use
of
just
mailbag
and
extender
for
egress
validation
it'd
be
good
to
have
that
discussion.
R
Sure
I'll
I
will
be
like
go
for
it
like
we
can
have
a
discussion,
maybe
on
the
mailing
list,
or
have
a
call
later.
G
S
I
Thanks,
your
friends
thanks
just
to
answer
to
zafar's
question,
so
the
little
fake
the
idea
is
to
you
know,
have
a
generic
way
of
being
able
to
traverse
the
data
path
without
having
to
validate
the
the
actual
synchronization
between
control,
plane
and
data
plane.
I
So
if
you,
if
you
think
of
validation
in
in
a
at
a
scale
of
one
to
five,
the
actual
validation
definition
of
feck
for
each
of
the
sits
and
validation
of
that
stands
at
five,
the
validation
level
and
the
nilfek
based
validation
stands
at
one,
because
it's
not
really
doing
any
kind
of
validation
and
I
think
the
generic
sid
mechanism
that
you're
proposing
stands
somewhere
at
2.5
and
yeah.
You
can
have
discussion
and.
A
Yeah
yeah
that,
except
there
is
some
validation
that
is
done
not
not
much
but
and
given
this,
my
feedback
is,
as
I
mentioned
in
the
beginning,
is
for
the
office
of
the
two
drafts
to
get
together
and
it's
possibly
that
we
end
up
with
an
ill
fec
extension.
A
You
know
going
through
as
well
as
charla
said
it
is
the
data
plane,
validation
at
the
end
point
yeah.
I
think
yes,.
Q
You
need
we
did
discuss
this
option
in
earlier
thanks.
Okay,
thank
you.
A
All
right,
I
don't
see
anyone
in
the
queue
so
I'll
move
on
to
the
next.
The
next
slot
is
there's
nagendra
go
ahead.
L
Yeah,
thank
you.
Hi,
I'm
nagendra
from
cisco
I'll
be
presenting
this
draft
on
behalf
of
my
co-authors.
Next
flight.
L
Yeah,
so
the
basic
motivation
behind
this
draft-
I
think
I
know
we-
we
discussed
this
at
least
a
couple
of
times
in
the
previous
slides
or
presentations.
So
with
segment
routing.
We
are
seeing
different
types
of
you
know:
segment
ids
being
proposed,
but
different,
forwarding,
semantics
associated
to
that
so
based
on
rfc
1829,
we
we
go
with
a
one-on-one
kind
of
mapping
for
for
each
segment,
id
or
effect
will
have
a
new
targeted
target.
L
L
So
you
know
a
lot
of
efforts
involved
in
defining
and
standardizing,
and
it
also
requires
either
domain
void
or
node
wide
upgrade
software
upgraded
so
that
the
ingress
can
include
the
relevant
information
that
is
required
to
be
included
as
part
of
the
the
targeted
fcc
stack
and
the
responder
can,
I
know,
interpret
those
information
and
then
send
a
positive,
negative
response
based
on
the
validation.
So
this
basically
raises
scalability
challenges.
L
So
this
is
a
partial
list
of
some
of
the
you
know.
Srfx
we
took
a
stab
writing.
You
know
different
drafts
addressing
or
defining
a
different
target
deficiency
stack
for
each
of
these
assets
and
we
started
realizing
that
you
know
with
the
plethora
of
segment
id
is
being
proposed.
It
may
not
be
scalable
to
you
know,
introduce
new
target,
fec
stack
and
you
know
have
a
always
on
implementation
of
oem.
L
So
that's
why
you
know
we
took
one
step
back
and
started
looking
into
other
ways
to
see
if
we
can
solve
this
problem
next
time.
L
So
it's
not
only
about
you,
know,
standardization
efforts
required
to
define-
and
you
know,
implement
these
new
target
deficiency,
but
depending
on
the
the
volume
of
information
that
needs
to
be
carried
so
that
the
responder
can
validate.
We
basically
need
a
lot
of
information
that
may
or
may
not
be
available
in
the
initiator,
for
example,
the
initiative
in
it
originate
the
oem
probe.
L
We
need
to
include
different
types
of
information
that
you
know
that
sometimes
even
the
initiator
may
not
be
aware
of,
and
the
same
goes
through
with
the
responder,
where
the
responder
need
to
understand
all
this
information
included
in
the
you
know:
target
deficiency
stacks
of
tlb
so
that
it
can
validate,
perform
the
relevant
validation
and
respond
back
with
the
the
right
response.
L
So
we
took
a
step
of
solving
this
problem
by
you
know:
defining
a
very
basic
segment
id
which
or
a
very
basic
targeted
deficiencies
like
sub
plb.
That
only
carries
the
segment
id
that
needs
to
be
validated
so
from
the
effect
validation
procedures.
Point
of
view.
It
basically
does
two
things.
One
is:
is
this
probe
terminating
on
the
right
end
point?
In
other
words
the
responder
when
it
receives
the
probe
will
check
two
things.
L
One
is
like
you
know
I
might
be
a
lsp
endpoint
for
the
segment
id
and
two
did
I
receive
it.
Did
I
receive
this
probe
on
the
right
incoming
interface,
so
by
simply
using
these
two
validation,
you
are
able
to
validate
quite
a
few
segment.
Ids
next
slide.
A
L
Agenda.
Okay,
so
this
is
the
subtly
lv
that
we
defined.
As
you
can
see,
we
just
you
know,
carry
only
the
20-bit
segment
id
that
needs
to
be
validated
next
slide
sure.
L
So
this
is
an
example
of
how
the
prefix
set
can
be
validated.
So
we
included
an
example
where
we
have
both.
You
know,
default
algorithm
and
also
a
flexible
algorithm
or
plex
algo128.
So
16008
is
the
prefix
set
for
algoz
zero
for
node,
eight
and
16
128.
Eight,
for
you
know
algo128
for
node
eight.
So
when
node
one
wants
to
validate
any
of
these
prefix,
all
it
needs
to
do
is
include
the
relevant
set
in
the
as
the
sub
plb
and
send
the
pro
when
node
8
receive
it.
L
Like,
I
said
you
know
it
will
be
performing
two
validations.
One
is:
am
I
the
lsp
endpoint
for
this?
You
know,
and
did
I
receive
it
on
the
right
incoming
interface,
so
using
these
two
we
were
able
to.
You
know,
identify
not
just
the
the
default,
but
also
any
flex
I'll
go.
You
know,
since
prefix
can
be
validated
next
slide.
L
Parallel
set
from
note
7,
we
have
9378,
which
is
a
parallel
adjacency
set
that
could
be
load,
balance
between
link
one
or
link
two
to
node.
Eight
again,
you
know
if
one
want
to
validate
9378,
which
is
the
adjacency
parallel
adjacency
said
it
simply
include
9378
and
send
the
probe
node
8
when
it
receives
it
checks.
If
it
is
the
lsp
endpoint
and
did
I
receive
it
on
the
right
incoming
interface,
so
the
the
incoming
interface
mapping,
we
we
do
have
a
slide
that
will
be
explaining
about
that.
L
Yeah.
I
think
we
can
skip
this
next
slide.
Okay,
so,
in
order
to
perform
this
interface
validation,
did
I
receive
it
on
the
right
incoming
interface.
We
basically
follow
a
simple
mechanism
where
each
node
will
maintain
all
the
local.
L
You
know
segment
ids
like
the
prefix
segment,
with
all
the
in
incoming
interface
as
any,
and
it
also
includes
the
adjacency
segment
ids
assigned
by
the
directly
connected
next
ops
to
itself,
for
example,
from
node
8
point
of
view.
It
will
include
sixteen
zero,
zero,
zero,
eight
and
sixteen
one
twenty
eight
eight,
which
are
the
prefix
set
for
default,
algorithm
and
flex
algorithm
128,
and
it
also
includes
all
the
adjacency
set
assigned
only
by
node,
seven
for
node
8.,
9178,
93789
9278
or
the
adjacency,
designed
by
seven
for
eight.
L
So
these
are
the
information
that
will
be
included
in
no
dates
table,
but
the
relevant
incoming
interface,
for
example,
9178,
will
be
marked
with
the
incoming
interface
of
link,
1
and
9278,
with
the
incoming
interface
of
link
2..
So
using
this
database,
any
node
can,
when
it
receives
the
probe
will
be
able
to
validate.
If
you
know
it's
the
end
point
for
that
particular
sig,
and
if
it
received
the
probe
on
the
right
incoming
interface
next
slide,.
L
Yeah,
so
in
a
nutshell,
we
are
defining
one
targeted,
fcc
stack
that
is
capable
of
you
know,
validating
multiple
segment
ids,
so
this
drastically
reduce
the
you
know.
I
mean
the
standardization
effort
that
are
required
and
also
drastically
reduce
the
volume
of
information
that
is
required
to
be
you
know
inserted
by
the
initiator
and
the
details
that
needs
to
be
validated
by
the
responder.
So
it
is
also
extendable
to
accommodate
you
know
any
new
or
future
segment
ids.
L
So
from
the
iana
point
of
view
we
are
requesting,
you
know
once
up
tlb
from
tlb
type,
one.
Sixteen
and
twenty
one.
We
are
not
introducing
any
new
written
codes
or
return.
Suppose
we
are
actually
reusing.
The
existing
cell
return
code
and
subcode,
which
are
defined
in
1829
and
e287
next
slide
yeah.
So
like
tarek
was
mentioning.
I
know
we.
We
presented
this
draft
in
the
in
the
past
in
other
idf,
so
we
welcome
any.
A
Thank
you,
nagendra.
Anyone
in
the
queue
nick.
C
K
So
if
I
understood
correctly
so
you
mentioned
that
each
segment,
each
node
supporting
segment
routing,
must
now
add
the
information
about
the
adjacency
sids
and
its
immediate
neighbors
right.
So
that
does
look
like
a
hell
of
a
lot
of
information
additionally
has
to
be
stored
within
the
sr
domain.
L
L
Yeah,
so
you
anyway
have
all
those
information
in
the
database
in
your
igp
database,
so
it's
either
a
matter
of
having
it
in
another
database
or
just
reuse.
The
existing.
K
Yeah,
but
that
probably
needs
to
be
really
clearly
stated
because
it's
a
trade-off.
So
basically
it's
not
clear
benefits
their
price
to
be
paid.
L
Yeah,
so
so
this
is
more
of
an
implementation
matter.
We
are
not
suggesting.
This
is
one
of
the
best
practices
that
you
could
use
to
have
it
as
a
you
know
separate
table,
but
this
is
not
a
mandatory
table
that
you
you're
required
to
have.
So,
if
you
think
you
know
that's
going
to
be
a
overload,
the
solution
still
can
rely
on
igp
database
to
fetch
that
information,
so.
P
L
Good
question:
so,
if
the,
if
it
is
an
adjacency
sid
and
if
the
link
failed
and
if
it
is
steered
over
the
backup
path,
okay,
we
haven't
thought
about
this.
I
don't
think
we
included
anything
around
this.
We
can
think
about
this
and
we
can
add
something
in
the
draft.
A
Okay:
next,
we
have
either
yao
or
greg.
A
S
S
Oh
amperes
can
be
used
to
realize
service
function
paths
so
far.
There
are
two
methods.
One
is
based
on
where
service
programming,
where
each
service
function
is
related
with
an
mps
label,
another
is
defining,
ifc8595
and
and
ps
label
step
is
used
to
carry
the
logical
presentation
or
congrats
edge,
and
the
basic
unit
comprises
two
labels
and
one
provides
a
context
within
the
sfc
scope
and
the
other
carries
a
label
to
show
which
service
function
is
truly
enacted
and
it
is
called
sfc
mps
in
this
draft
for
simple.
S
This
document
defines
extensions
of
the
mpl's
health
speaking
to
support
the
revocation
between
the
control
management
plan
and
the
data
translate
for
sfcsr
and
sfcmps.
Next,
like
this.
S
Next
slide,
please,
the
new
tvs
have
been
been
introduced
last
time,
so
I'll
go
through
it
quickly.
Now,
first
and
sfc
validation,
tier
v
is
defined.
If
an
npo's
echo
request
for
reply
contains
this
tv,
it
is
an
sfc
validation
message.
This
deal
contains
subjects
only
in
reply
message:
two
tovs
are
defined
separately
for
sfc
sr
and
sfc
and
prs,
which
is
used
to
carry
the
sfp
detailed
information
in
the
reply
message
and
next
slide.
Please.
S
And
this
page
sfc
basic
unit
flex
sub
tv
is
defined
only
for
sfc
and
prs,
unlike
standard
mps,
forwarding,
which
is
based
on
a
single
label
in
ifc8595
packet
forwarding
is
based
on
the
basic
unit,
which
is
two
labels,
so
the
new
flat
suburb
can
be
used
to
carry
the
corresponding
fact
info
of
the
base
of
the
unit.
The
node
that
receives
an
lc
pin
with
the
new
flex
sub
tree
will
check
if
it
is
hardy
and
whether
it
advertises
at
service
function
type
and
if
the
validation
is
not
passed.
S
And
this
slide
introduces
using
special
purpose
labels
in
sfc
and
pos.
Generally,
the
processing
functions
supported
by
service
functions
are
limited.
Service
functions
may
not
be
capable
of
processing
the
sfp
om
payload
and
may
drop
the
package
after
receiving
it.
So
and
so,
this
function
for
water
need
to
identify
an
oem
package
with
sfp
scope,
and
we
introduced
the
user
and
in
special
purpose,
labor
unit
in
the
basic
unit
of
mps
label
stack
for
sfc.
S
S
Please
npr's
generic
associated
channel
is
introduced
in
ifc,
5586
and
oem,
and
other
control
message
can
be
exchanged
over
it.
The
genetic
gl
is
the
generic
associated
channel
label,
which
is
used
to
differentiate
specific
packets
like
gh
packets
from
others
in
this
packet,
the
usage
of
the
gl
is
expanded.
S
If
the
gao
immediately
follows
the
sfc
contact
symbol,
the
packet
is
recognized
as
an
srp
om
package
and
below
are
the
processing
rules
and
in
so
first
and
sf
has
must
not
pass
the
on
package
to
local
service
function
instance.
So
as
fc
proxy
and
the
next
two
rules
I'll
introduce
later
so
the
next
one,
please.
S
J
S
S
Okay-
and
this
is
the
last
slide-
and
this
is
a
package
processing
flow
of
the
service
function
for
water
as
introduced
before.
If
the
sfc
contacts
label
is
followed
by
a
special
purpose
label
gl,
it
is
recognized
and
as
a
sfp
oam
package,
then
service
function
for
water
will
enter
the
spo
processing
procedure.
S
It
decreases
the
ttl
in
sf
label
and
if
the
tto
is
not
zero,
the
om
packet
is
processed
as
defining
85.95
sent
to
the
next
service
function.
For
order,
if
the
tdl
is
zero,
the
own
packet
is
sent
to
the
local
control
plan.
If
the
om
packet
contains
service,
sfc
validation,
trv,
the
service
function
for
order
will
generate
and
reply
message
with
the
sfc
info
subtly
included.
S
It
says
if
an
service
function
for
order,
decrements
the
ttl
to
zero,
it
must
discard
the
packet,
and
we
just
expect
this
package
to
be
sent
to
the
local
control
plan.
Conversation
control
to
trace
service
function,
path
and
next
slide,
and
your
feedbacks
and
comments
are
welcome
and
much
it
thanks.
A
Thank
you.
Anyone
in
the
queue.
A
All
right,
okay,
thank
you!
So
much
we
all
right
I'll
move
on
to
the
next.
G
S
M
S
S
S
It
can
be
used
by
the
egress
node
for
performance
measurement,
bi-directional
path,
correlation
and
end-to-end
protection
in
sr
and
npr's
interwoven
scenario.
Pass
segments
can
also
be
used
to
implement
these
functions.
Two
scenarios
are
introduced
in
this
draft
nesting
of
past
segments
and
stitch
focus
segments
next
slide.
Please.
S
These
are
the
updates
from
last
version,
the
usage
of
past
segments
in
si
and
peers
and
amperes
interworking
has
been
clarified,
as
I
mentioned
in
the
previous
slide.
It
can
be
used
for
performance
measurement
protection
and
to
achieve
bi-directional
parts,
and
there
are
some
modifications
about
the
necessary
assignment
and
the
stage
of
assessment
and
using
finding
it
to
stitch
the
tesla
list
and
osp
across
multiple
commands
is
also
added
next
slide.
Please.
S
The
nesting
or
path
segments
represents
end
to
end
encapsulation
in
the
packet
from
an
sr
appears
domain
to
an
amperes
domain,
which
is
encapsulated
in
the
ingress
node
and
in
the
english
nodes
and
encapsulated
at
the
equest
nodes.
The
transition
notes
are
not.
Can
the
border
nodes
of
the
domains
are
not
aware
of
the
nesting
of
class
id
and
the
srsp
and
rpo
and
pslsps
may
be
stitched
across
the
man's
face
binding
state?
Next,
like
this.
S
The
ssids
will
be
popped
out
at
the
border
node
in
each
domain
and
correlate
it
to
the
s-pass
id
of
next
domain.
The
staging
of
past
segments
can
support
the
end-to-end
path,
stitching
and
monitoring,
and
next,
like
this,
many
authors
will
continue
working
on
this
draft
on
solutions
for
the
interworking
with
parking
pass
segments
and
comments
and
discussions
that
will
welcome.
That's
all
thanks.
A
Okay,
thank
you.
I
have
a
question
for
you.
This
is
dark
and
my
question
is:
you
are
creating
state
at
the
border
nodes,
so
this
is
per
path
state
for
creating
these
path
segments
right.
S
A
Okay,
I
thought
the
idea
is
to
not
create
states
on
transit
nodes
in
that
case,
in
segment
routing,
but
now
we're
bringing
path,
state
and
the
world
into
the
transit
notes.
S
In
past
segments,
most
of
the
the
nodes
are
have
no
states,
but
I
think
at
the
bottom
of
those
we
can
have
space
for
the
inter
intel
inter
scenario
for
the
interworking
scenario
and,
for
example,
like
financing
they.
It
also
has
states.
I
think.
A
The
next
one
I
have
is
for
thomas.
D
Perfect.
Thank
you
good
thomas
graf
from
swisscom.
I'm
presenting
the
draft
export
for
offer
ample
ssr
label
type
information
in
ipfix
next
slide.
Please.
D
So
the
problem
statement
is
you
see
on
the
right
side,
this
is
a
packet
ipfix
packet
capture
of
an
mls
sr
implementation,
understood
well,
where
ample
assessor
is
using
the
existing
amples
data
plane
and
therefore
the
the
ipfix
packet
capture
is
more
or
less
identical
to
to
to
mpls,
with
one
notable
difference,
which
is
the
ample
stop
label
type
which
is
referring
to
the
protocol
providing
the
label.
In
this
case
it's
ldp,
even
though
ldp
is
not
covered
in
the
network.
D
Next
slide,
please
so
looking
at
iana
into
the
ipfix
mpls
label
type
registry,
we
see
the
problem
and
palace
sr
is
not
present
there.
So
currently
only
the
the
the
existing
routing
protocol
not
covering
ample
ssr
listed
next
slide.
Please.
D
And
I
received
two
ipfix
doctor
reviews
and
in
this
doctor
reviews
we
we
noticed
that
currently
the
rich
history
is
is
not
being
properly
set
up.
There
is
a
hidden
requestor
section
and
actually
the
column
on
the
reference
and
the
column
on
the
request
is
should
be
vice
versa.
D
D
I
received
so
far
feedback
from
spring
and
palace
lsr
and
ops
awg
at
itf
108.
I
requested
adoption
at
ops
awg
and
received
feedback
in
regards
to
review
as
a
city
type
and
fix
the
existing
I-46
switch
history
which
I
just
presented
before
the
src
type
was
removed
from
the
the
latest
version
of
the
draft
in
favor
of
the
draft
spring
esser
in
section
8
3
there's
a
nice
description,
basically
covering
the
same
aspect,
so
you
can
get
the
same.
D
Src
type
information
through
young
push
versus
implementing
in
ipfix
and
high
prefix
has
some
limitations
in
terms
of
packet
sizes
and
yep.
I'm
aiming
for
do
an
another
call
for
option
at
ops,
awg
at
itf
110
and
in
between
I'm
looking
forward
for
receiving
feedback
from
the
emperor's
working
group
as
well.
A
I
have
a
question
to
you,
thomas
just
clarification,
of
course,
so
you
dropped
src
type.
So,
what's
left
in
that
identifies
it's
a
segment
routing
label.
D
It's
just
basically
about
the
the
label
type
so
for
which
label
protocol
defined
the
label.
D
Exactly
that's
why
the
ia46
registry
is
there:
it
defines
which
label
protocol
provided
the
label.
Okay.
Okay,
that's
fine
right!
This
src
type
was
more,
which
city
type
so
for
each,
for
instance,
adjacency
sit
or
fix
it,
and
so
on.
E
A
Okay.
Thank
you
thomas.
We,
we
have
another
presentation,
but
it
was
supposed
to
be
jeffrey,
I'm
not
sure
if
kiriti
you're
filling
in
for
jeffrey-
and
if
you
are,
we,
we
didn't
receive
the
slides.
So
I
cannot
present
them
right
now.
C
I
think
mark
did.
A
If
he
did,
I
can
check
they
weren't.
Okay,
let
me
see
oh
okay,
cool.
C
Okay
thanks
and
thank
you
mark
for
for
accommodating
us,
the
presentation.
C
So
basically,
what
we're
saying
here
is
we
have
this:
we
have
in
ipv6
this
mechanism
for
fragmentation
and
other
other
functions
on
packets,
for
example,
inserting
an
esp
header
and
such
things.
So
we
have
the
need
in
non-ip
environments
to
do
such
things
so
we'll
give
you
an
example
on
the
next
slide.
C
You
can't
fragment
it.
So
a
workaround
is
to
say:
okay,
let's
do
mpls
over
ip,
so
mkls
over
udp
or
mpls
over
gre
and
then
fragment
the
ip
packet.
But
that's
a
lot
of
overhead.
That's
a
lot
of
you
know
it's
a
much
heavier
function,
plus
you're,
not
using
mpls
in
the
transport
you're
using
ip,
and
maybe
you
had
this
nice
traffic
engineered
path
that
you
wanted
to
use
for
this
evpn.
C
So
there
are
solutions
to
this
in
pw
there
was
an
there
is
an
rfc
many
thanks
to
stuart
for
pointing
it
out
and
what
it
does
is
put
a
control
word
and
have
some
things
to
indicate
the
user
sequence
numbers
to
indicate
the
fragments
use
bits
to
say
this.
C
The
first
fragment
that's
the
last
fragment
and
you
can
do
it
that
way,
but
we're
looking
at
a
more
generic
solution,
not
just
for
pseudo
wires
but
for
evpn,
which
doesn't
use
the
control
word,
but
also
in
you
know
in
principle
for
other
protocols.
So
maybe
peer,
maybe
your
mpls
in
general.
C
So
the
thing
that
we're
looking
at
is
to
use
the
ipv6
functions
like,
for
example,
the
fragmentation
header,
it's
relatively
independent
of
ipv6
itself.
So
the
big,
the
big
difference
is
the
identification
feel
for
the
fragment
itself.
But-
and
so
if
you
already
have
ipv6
fragmentation
in
your
hardware,
maybe
it's
a
relatively
small
tweak
to
use
it
in
other
contexts.
C
So
the
idea
is
to
use
fragmentation,
reassembly
function,
and
so,
in
the
case
of
evpn,
we
would
say,
put
the
service
label
and
then
fragment
the
packet
using
you'll,
see
on
the
next
slide,
the
generic
fragmentation
header
and
then
on
top
of
that
put
another
label
that
says
fragmentation
is
next
and
then
on
top
of
that
put
the
tunnel
label.
So
the
packet
would
look
like
turner
label,
gfh
label,
the
the
fragmentation
header
followed
by
the
service
label.
C
So
the
eager
spe
would
see
the
gfh
label
reassemble
the
packet
and
then
say:
okay,
there's
more
mpls
or
just
a
service
label,
and
then
it
would
know
how
to
you
know,
hand
that
off
to
the
right
customer,
because
essentially
at
that
point
the
service
label
just
tells
you
which
interface
you're
going
out
of
next
slide.
C
So
ipv6
has
this
very
interesting
tlb
structure,
where
the
t
comes
from
the
previous
header
and
then
the
l
and
v
are
typically
in
this
insider,
so
the
previous
header
would
have-
or
the
previous
thingy
would
have
said,
what's
coming
up.
Next
is
the
fragmentation
header,
so
we
don't
have
that.
C
So
we
need
to
do
that
outside
of
this.
So
that's
why
we
have
a
gfh
label
that
says
what
comes
next
is
a
fragmentation
header,
the
gfx
label
could
be
signaled
or
it
could
be
a
special
purpose
label
details
to
be
figured
out,
but
essentially
that's
how
you
know
that
this
is
a
fragmentation
header
in
in
the
payload.
C
The
fragmentation
header
itself
we're
starting
with
this
nibble
of
zeros.
This
was
from
a
suggestion
from
stuart.
The
next
header
will
then
tell
you
that
when
you're
done
with
this,
you
still
have
mpls,
because
the
service
level
is
to
come
up.
C
The
header
length
tells
you
how
to
do
the
identification
again
in
the
context
of
ipv6.
The
identification
is
just
you
know,
for
a
given
packet.
You
just
generate
a
new
identification
number.
All
the
fragments
will
have
that
same
number
and
then
you
put
them
together,
but
in
the
case
of
ip
I
mean,
if
you're
not
doing
ipv6,
you
may
not
have
enough
contacts
just
with
that
four
byte
number,
the
identification,
so
you
might
have
to
add
the
source
pe
loopback
address
you
may,
depending
on,
if
you're
doing
it
for
ethernet.
You
might
want
to.
A
C
Yeah
yeah
yeah,
so
so
basically,
the
idea
is
that
you
embed
a
fragmentation
header
in
different
protocols
in
different
ways.
So
in
mpls
you
have
this
generic
fragment,
fragment
header
label,
gfx
label
and
and
then
you're
able
to
fragment
the
package,
use
the
full
you
know,
use
the
normal
mpls
otherwise
and
then
at
the
egress.
You
can
then
put
it
back
together.
C
So
again,
this
this
is
the
description
of
what's
in
the
header,
so
I'll.
I've
mostly
said
all
that,
so
let's
go
to
the
next
slide.
C
So
the
idea
is
then,
to
solve
the
mpls
evpn
fragmentation
problem
without
incurring
the
ipe
overhead,
or
you
know
avoiding
the
mpls
tunnel,
but
then
we
could
also
do
it
for
other
things,
besides
fragmentation.
So
if
you
want
to
do
esp
or
something
you
can
use
an
esp
header
and
finally,
the
the
solution
works
for
mpls
for
beer,
or
hopefully
it
works
for
mpls
for
brf
ethernet
could
be
used
for
pseudo
wires
and
vpls.
C
The
goal
is
to
the
goal
here
is
just
to
sort
of
give
you
a
heads
up
we're
presenting
this.
So
we've
at
this
point
presented
this
in
tsvwg
pierre
and
I
think
we've
also
presented
in
best.
C
So
the
idea
is
to
essentially
make
everyone
aware
of
this,
and
then
you
know
find
a
place
to
standardize
it.
So
I
think
the
next
slide
has
that
yeah.
So
do
we
find
a
home
in
ts,
dsvwg
or
into
area,
or
you
know,
that's
something
that
we
have
to
figure
out,
but
we're
just
putting
the
idea
in
front
of
you
guys.
We
love
your
comments.
Thank
you,
stuart
for
your
comments
and
yeah.
We
have
work
to
do,
but
we
will
continue
discussions.
A
Thank
you
kiriti.
We
don't
have
time
for
too
many
questions.
Stewart
if
it
was
quick,
go
ahead.
I
see
that
you're
in
the
queue.
E
So
if
we
separate
the
type
from
the
ac
fragmentation
method,
we
should
also
seriously
consider
upgrading
rfc
4623
to
add
the
additional
field
that
you
you
need.
4623
is
a
standard
track
method
of
doing
fragmentation
in
this
context,
so
I
see
two
problems
and
we
should
discuss
them
separately
and
we
should
do
the
right
thing
for
the
mpls
architecture.
E
So
could
you
explain
the
type
field?
Are
you
talking.
E
Is
yeah
next
header
we've
avoided
having
that
in
everything
else,
we've
done
in
mpls
by
making
what
follows
a
function
of
the
bottom
label.
Now
those
are
the
top.
C
Yeah,
the
thing
is
you:
you
need
to
terminate
the
label
stack
so
that
you
know
that
and
so
you're
sort
of
terminating
the
label
stack
in
the
middle
of
the
label
stack.
So
you
need
to
come
back.
So
you
you
have
the
top
label,
which
is
the
tunnel
label.
C
E
The
the
other
guy
needs
to
me.
You
need
to
know
the
other
guy
can
expect
this,
so
your
peer
should
really
issue
a
label
with
the
instructions
yeah
right.
So
given
that
you've
got
the
labels
agreed
and
the
capabilities
agreed,
you
don't
need
to
do
that.
C
C
E
A
A
C
So
we
can
continue
the
discussion
until
I
amid
echo,
kicks
us
out
right.
C
So
if
you
don't
put
the
end
of
stack
bit
on
the
gfh
label,
you
know
somebody's
going
to
process
this
and
do
ecmp
based
on
everything
and
treating
the
zero
zero
nibble
field
as
a
label
and
that's
going
to
screw
up
everything.
So
you
put
the
end
of
stack
bit
there
and
you're
right.
If
you
say
that
the
semantics
of
the
gfx
label
is
that
yeah,
the
end
of
stack
bit
is
on,
but
it's
only
so
to
prevent
ecmp
from
doing
stupid
things
and
once
you've
processed
it.
E
O
E
O
No,
no,
no!
No!
No,
not
like
that
either.
It's
really
that's
so
put
put
mpos
first
on
the
side
for
one
moment,
okay,
consider
forget
about
mpos.
Let's
just
say
we
are
doing
doing
the
fragmentation
for
ethernet
okay
without
ip,
without
mpls
at
all.
It's
just
a
pure
ethernet,
pure
layer,
too
we're
doing
fragmentation.
O
So
we
put
this
with
as
long
as
signs
either
time
for
the
forgive
to
indicate
that
the
gfh
for
follows
and
then
and
then
after
that
that
that
gfh,
the
next
header
value
in
the
gfc
gfh,
will
tell
you
what's
coming
after
the
after
the
gfc
gfh.
So
now
coming
back.
E
Well,
well,
that's
an
802
discussion.
Isn't
it.
E
F
O
O
So
we
assign
either
type
to
to
indicate
that
the
gfh
follows
and
then,
and
and
the
next
header
in
the
gfh
will
tell
what
what
would
be
the
original
either
type.
We
imagine
that
when
you're
not
doing
the
gf
fragmentation,
there
is
either
time
to
tell
you
what
what's
coming
after
ethernet
header
now
with
the
gfh.
O
The
next
header
value
in
the
e
in
the
gfh
will
be
the
the
either
either
type
so
right
now
now
we
put
put
mpos
back,
we
don't
have
a
either
type
for
mpos.
O
C
Well,
what
I
was
going
to
say
is:
if
we
did
this
hack,
that
you
suggested
for
mpls,
then
the
next
header
field
could
be
empty
so
that
we're
not
sneaking
in
a
protocol
type,
although
we're
not
sneaking
in
a
protocol
type
you're,
not
saying
that,
because
what
the
protocol
people
wanted,
the
people
who
wanted
a
protocol
type
in
mpls
wanted
you
to
say
this:
an
evpn
packet,
it's
ethernet
after
the
mpls
stack
or
just
an
I,
you
know,
and
we're
not
doing
that
we're
just
saying
we
broke
the
label
stack
into
two
parts
and
we're
sort
of
stitching
them
back
together,
but
we
could
say
that
you
know
a
gfh
label
has
the
well-known
semantics
that,
yes,
it
has
an
end
of
stack
bit,
but
there's
actually
one
more
label
or
there
are
actually
more
labels
operate.
C
M
M
E
Yeah,
so
I
I
just
think
that
we've
got
20
years
of
really
clean
architecture,
and
I
I
I
it
seems
to
me
to
be
wrong
to
just
change
that
without
huge
amounts
of
thought
about
the
implications
and
the
ramifications
so
so
far,
what
what
we
would
normally
do.
You
you've
got
us
in
the
mpls
world.
You've
got
a
sudower
going
between
the
two,
the
two
points.
E
Yes,
you
you
decide
that
you
want
to
have
a
fragmenting
pseudo-wire.
So
normally
what
you
do
is
you
tunnel,
the
sudo
wire
over
another
sudo
wire?
Wouldn't
you.
C
No,
you
tunnel
it
over
something
that
you
could
actually
fragment
so
you'd.
Normally,
I
mean.
E
Supposing
we
created
a
fragmenting
pseudo
wire,
which
is
what
essentially
a
pseudo
wire
supporting
4623,
is,
but
you
say
you
need
this
extra
identification
field,
so
we're
going
to
add
the
identification
field
in
now
we're
completely
clean
in
terms
of
existing
designs
and
architectures.
You
you,
you
create
a
pseudo
wire
between
these
two
endpoints.
It's
got
this
fragmentation,
property
and
a
property
of
the
pseudo-wire
label
is
that
it
says
what
is
underneath.
E
That's
the
stamp.
That's
that's
the
architecture
that
we've
had
in
place
for
nearly
20
years
and
I'm
fine
with
doing
something
new.
If
something
new
is
the
right
thing
to
do,
but
if
you
can
do
it
with
the
existing,
it's
almost
proved
extremely
valuable
to
to
take
a
more
conservative
approach
so
far.
C
So
here's
the
thing
the
idea
is
to
reuse
the
the
fragmentation
header
and,
while
the
immediate
sort
of
reason
for
doing
this
was
an
evpn
over
mpls
case
mkls
doesn't
have
fragmentation.
So
if
there
was
a
way
that
we
could,
you
know,
do
generic
fragmentation
for
mpls
for
ethernet
for
beer.
I
don't
know
enough
about
beer
to
talk
about
that,
but
jeffy
does.
Then
I
think
if
we
would
then
say
we
have
a
generic
mechanism.
C
What
we
need
in
that
generic
mechanism
is
a
way
to
tell
the
outer
thingy
like
if
it
was
ethernet,
you
use
the
ether
type
to
say,
there's
an
there's,
a
fragmenting
header
there
and
then
and
then
go
back
to
whatever
you're
doing
so.
If
you
were
carrying
an
iss
packet
over
ethernet,
you
would
have
an
ether
type
of
isis,
but
you
would
replace
it
with
the
fragmenting
thingy
and
then
you
put
the
isis
ether
type
in
the
next
header,
so
we're
trying
to
keep
the
architecture
general.
C
C
So
I
I
think
the
idea
is
to
say:
is
this
idea
of
a
fragmenting
header
or
an
esp
header
or
whatever
sufficiently
interesting
to
take
it
out
of
the
ip
context
and
put
it
in
mpls?
Put
it
in
ethernet
put
it
in
beer?
Maybe
you
know
specifically
for
survives,
maybe
generally,
so
that's
basically
what
we're
looking
at.
H
E
Is
sufficiently
important
and
sufficiently
fundamental
that
we
need
a
proper,
you
know,
thought
process
and
to
decide
what
we're
going
to
do,
because
so
far,
we've
not
needed
to
do
this
and.
E
E
Need
to
fragment
mpls
because
normally
ip
sorts
it
out
for
you,
I
mean
when
I
say
it,
sorts
out,
for
you
pmtu
discovery
fails,
a
packet
gets
dropped
or
something
the
pmt
discovery
runs
and
you're
back
not
needing
to
do
the
the
fragmentation
again.
C
I
don't
think
that
works
for
surewise,
but
anyway
we
can.
We
can
have
this
discussion.
E
Ipv6
running
over
pseudowire
will
do
exactly
this,
yes,
the
the
ip
won't
get
through,
and
so
it
will
say.
Oh
I've
got
a
problem.
What
I
would
do
is
to
reduce
my
mtu.
C
An
echo
reply
saying
it
broke,
I
mean.
C
You
know
sticking
it
inside
of
ip
anyway.
I
think
we
should
get
off.
I
I
don't
want
the
medical
guys
to
get
mad
at
us,
but
but
I
I
don't
disagree
with
you
that
we
should
think
through
this.
I.