►
From YouTube: IETF101-MPLS-20180322-0930
Description
MPLS meeting session at IETF101
2018/03/22 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
Next
slide,
please,
so
this
is
a
new
note.
Well,
if
my
understanding
of
the
English
language
is
correct,
this
actually
says
more
or
less
the
same
thing,
but
in
the
listen
little
different
way
that
the
previous
note
Wells
did
so,
basically
everything
you
say
in
a
meeting
to
one
of
the
two
co-author
of
its
draft
to
one
group
shares
to
a
DS
and
anyone
else
is
considered
a
contribution
to
the
ITF
and.
A
A
Here's
the
agenda,
it
looks
extremely
packed,
though
turret
has
been
smart
this
time
he
is
concerned
of
what
actually
takes
time
and
that
slightly
swapping
over
between
presenters.
So
we
have
a
a
space
of
three
minutes
to
do
that.
We
hope
to
do
that
quicker,
but
because
you
normally
do
so,
the
times
might
not
be
exact
going
down
the
agenda
and
we
should
be
able
to
stop
at
at
welcome.
A
A
A
A
A
A
A
B
As
you
all
know,
I
think
by
now,
especially
if
you
were
at
the
plenary
last
night,
it's
a
sad
day
sad
week
for
us,
but
it's
also
a
happy
time
right
that
we
will
say
goodbye
to
George
as
chair,
though
I
understand
he
will
not
leave
us
too
desolate.
He
will
be
that
he's
going
to
be
the
technical
adviser.
So
that
means
he
will
be
following
the
mailing
list
and
helping
us
out.
So
George
has
some,
as
you
all
know,
he's
been
the
chair
of
the
NPS
working
group.
B
Now,
the
first
one
more
than
20
plus
years
more
than
40
RFC's
first
RFC
was
the
tag,
switching
and
kicking
off
and
quests
and,
as
many
have
reminded
me,
and
even
more
important,
one
was
LSP
ping.
He
did
the
first
RFC
on
traffic
engineering
and
he
has
mentioned
many
of
us,
many
of
us,
including
me
and
everybody
both
how
to
participate
authoring
chairing,
and
we
owe
him
a
lot
really
a
lot
so
anyway,
just
to
make
not
drag
this
out
too
long.
B
C
So
I
took
this
job.
I.
Never
really
thought
I
would
stick
around
this
long,
but
MPLS
has
been
a
very
successful
technology
and
it's
successful
because
of
the
contributions
everybody
in
this
room
and
and
those
who
came
before
us
who
retired
before
me.
But
it's
gets
to
be
time
to
move
on
and
and
I
think
we're
all
in
good
hands
here
and
you
guys
will
carry
on.
So
thanks
for
being
a
great
group.
A
Your
choise
IRA
know
that
he
was
the
share
or
the
buff
before
we
had
to
become
a
working
group
in
San,
Jose
I,
don't
know
if
you
will
share
all
the
buff
in
Boston.
Okay.
So,
let's
see
this
Sun
is
here
that
it's
a
starting
point
for
ambulance
and
sharing
for
four
notes.
I
was
a
little
bit
I
don't
know.
English
were
desolate,
I
was
kind
of
not
feeling
good
about
George
leaving.
So
I
asked
him
to
become
the
technical
adviser
and
Yosh
accepted
to
do
that.
D
Okay,
so
actually
I'm
going
to
choose
like
how
much
I've
enjoyed
working
with
Georgians
of
these
years
and
how
much
of
an
inspiration
you're
both
inside
the
company
we
work
together
and
in
the
idea
minutes
please
so
they
probably
were
looking
at
a
problem-
is
that
the
control
blames
for
mini
routing
protocols
or
carried
over
simple
transport.
A
about
UDP
and
TCP.
D
D
D
Have
we
come
to
an
arrangement
that,
in
the
app
in
the
mode
in
which
we
use
md5,
it
is
satisfactory,
so
lower
did
a
small
survey
amongst
operators
and
vendors?
It
was
an
unscientific
survey,
as
is
Perez
admission,
I
think
slower.
They
did
this,
and
maybe
we
could
have
asked
the
questions
better
and
maybe
we
need
to
ask
it
properly.
D
The
operators
were
asked
if
TCP
Oh,
a
TCP
IO,
was
available
in
their
products
and,
if
so,
would
they
use
it
and
would
they
be
planning
to
deploy
it?
Vendors
were
asked
if
they
actually
had
implemented
TCP
I,
oh
well.
The
operators
said
that
they
had
no
plans
that
it's
due
to
deployed
TCP
IO
tcpo
is
the
obvious
candidate
for
a
more
secure
authentication
scheme
in
in
MPLA
in
LA,
in
LDP.
D
Is
good
enough?
It's
in
the
operators,
products
and
all
those
that
answered
said
that
very
few
of
there
are
very
few
authenticated.
Lvp
sessions
run
anyway,
and
they
considered
there
was
a
cost
to
deploy
TCP
AO
the
vendors
position.
You
know
saying
this
very
small
and
unscientific
survey
was
actually
most
of
us.
Don't
have
TCP
I/o
in
our
products
will
be
available
by
one
vendor
later
this
year
and
they
were
not
able
to
vent
to
it
that
once
they
have,
you
got
it
until
the
operators
say
that
they
need
it.
D
What
I
think
we
need
as
a
as
a
group
is
something
there's
more
secure
than
md5
when
used
over
the
long
live
sessions
that
support
writing,
something
that
can
be
run
on
all
or
at
least
most
of
existing
root
processes,
something
that
starts
up
and
runs
fast,
so
that
it
won't
impact
Rican
versions
from
a
cold
start
yeah.
We
can't
forward
to
wait
a
long
time
for
authentications
to
happen
when
we
have
a
completely
clean
start
in
a
route.
D
Now
what
we're
doing
we're
looking
at
T
CPO,
because
that's
the
current
obvious
candidate
for
securing
TCP,
we
think
we
probably
also
need
to
look
at
other
methods
to
see
if
any
of
them.
These
needs
better
we're
having
discussions
with
the
main
protocol
groups
that
are
in
the
same
position,
bgp
OSD,
P&P
set
and
we're
talking
to
a
large
number
of
the
working
groups
that
are
impacted
and
we're
going
to
go
along
where
I'm
going
to
go
along
to
the
site.
D
Meeting
the
security
area
meeting
later
today,
I
think
true
to
tell
the
security
folks
that
we
really
need
long-term
guidance
from
them
as
we
work
through
this
property.
So
this
needs
to
be
a
partnership
with
security
so
that
whatever
we
do
we'd
ever
where
we
go,
they
won't
keep
raising
this
as
an
issue
on
why
we
should,
on
and
holding
back
minor
improvements
through
LD
P
minor
feature
requests.
D
So
our
request
to
the
security
area
is
going
to
be.
We
need
help.
You
can't
do
this
on
our
own.
We
need
security,
designers
involved.
Rolls-Royce
solutions
are
unlikely
to
find
their
way
into
RFPs
that
set
the
implementation
specifications.
We
need
a
pragmatic,
simple
approach
that
operators
find
compelling
can
easily
deploy,
which
will
cause
the
security
technology
to
be
pulled
into
product.
D
Jeff
has
wrote
a
much
longer
and
more
comprehensive
presentation
and
presented
it
to
the
IPG
meeting
on
Sunday
I've
attached
his
presentation
to
the
end
of
these
slide.
In
case
people
want
to
look
at
it.
I
don't
intend
to
go
through
today,
though,
and
so
that's
where
I've
got
to
with
where
we
got
to
with
this.
So
we
need
help
we're
trying
to
work
with
security
to
have
a
solution
to
this
long-standing
standoff
questions.
G
But
then
just
ever
comment
you
know,
I
am
aware
of
quite
a
lot
of
vendors.
Supporting
you.
The
last
thing
be
it
at
least
I
had
heard
was
that
while
we
have
shipping
implementations
the
folks
weren't
too
keen
on
deploying
it
if
you're
going
to
talk
to
the
routing
force,
maybe
it
would
be
interesting
for
you
to
come
and
talk
exciter
ops
as
well,
where
the
security
for
bgp
is
being
talked
about
and
maybe
have
a
conversation
with
operators
and
and
see
if
there
is
have
they
taken
on
deployments.
For
you.
H
G
I
Jared
montz
from
alkaline,
so
there's
a
lot
in
here.
That's
kind
of
hidden
and
embedded
Jeff
highlighted
many
of
these
things.
I
have
TCP
sessions
that
have
been
up
for
close
to
a
decade
with
some
of
my
you
know,
you
know
BGP
peers
and
so
with
the
security
area.
Expressing
these
concerns
many
of
the
things
many
of
the
enhancements
that
they've
done
in
transport,
layer,
security
and
that's
happened
in
the
transport
area.
I
Don't
really
address
the
type
of
long-lived
state
that
exists
in
routers
that
may
have
very
high
uptime,
especially
when,
where
do
we
failover
and
other
activities
to
keep
things
up-
and
this
also
applies
to
things
like
LDP,
where
we
need
to
go
and
have
a
stable
way
to
do
this
also
many
in
many
cases
this
the
security
keys.
If
configured
stay
static
for
the
lifetime
of
forever.
I
There
is
no
good
way
to
do
with
TCP
md5
rollover.
Juniper
did
it
did
a
keychain
method
where
you
could
do
time,
exchange
of
the
md5
exchange,
but
I
I
don't
know
anybody.
Who's
used
it
outside
of
the
laboratory
when
I
talk
to
other
operators
and
it's
much
easier
for
up
for
the
people
who
operate
networks
to
just
configure
it
once
and
then
move
on
having
some
sort
of
transition
path
for
many
of
these
technologies.
I
If
you
have
an
ibgp
mashin
or
if
you
have
an
LD
p
mesh
protected,
and
you
need
to
do
key
rollover,
you're
going
to
have
to
cause
a
global
outage
for
your
network
as
a
result.
So
as
much
as
the
security
folks
would
really
like
us
to
change
we're
kind
of
stuck
in
many
ways,
and
it's
going
to
be
a
great
deal
of
difficulty
to
even
implement
that
operational
guidance.
I
J
J
F
One
of
them
is
the
sort
of
process
issue
of
moving
documents
forward
through
a
security
Directorate
that
has
certain
desires,
requirements
of
us
whatever,
as
far
as
I
can
tell
those
could
basically
be
satisfied
by
offering
them
a
transport
security
that
has
the
mathematical
properties
that
make
them
happy.
That
would
not
satisfy
the
operational
issues
that
Jared
was
talking
about
at
all,
but
this
is
probably
a
good
place
where
you
know
to
divide
and
conquer
and
I
will
point
out
the
AO
already,
you
know
has
pluggable,
you
know
hash
algorithm.
F
So
it's
it's
possible
to
say:
okay,
look
we're
going
to
provide
a
transport
mechanism.
That's
you
know,
sort
of
satisfies
the
right,
mathematical
security
properties
and
oh
by
the
way.
We
know
that
that
doesn't
really
satisfy
operational
security,
but
that's
an
orthogonal
issue
that
can
also
be
worked
on
either.
You
know
at
the
same
time-
or
you
know
in
due
course,
but
by
the
way,
I'm
not
trying
to
say
that
the
operational
issues
aren't
important,
I
think
they're
more
important
date.
D
K
Wilson
from
orange
ITF
can't
appreciate
CPOE
Cyrus,
that's
fine,
but
now
talking
from
an
operational
point
of
view,
if
the
vendors
are
keeping
supporting
TCP
md5
implementation,
why
should
we
move?
Because
there
is
an
operational
cost
for
the
migration
and
it
does
not
really
bring
you
strong
benefit,
at
least
for
us.
So
while
the
vendors
are
still
supporting
it,
we
will
not
make
it
I'm.
Sorry,
at
least
for
the
migration
point
of
view
for
new
implementation.
Why
not?
It.
L
M
I
was
around
BGP
before
the
reset
attacks
and
couldn't
understand
why
nobody
cared
about
security
and
the
learning
from
that
time
onwards
has
been
for
me
that
people
are
very
reluctant
to
do
anything
till
the
disaster
happens.
So
my
take,
is
you
have
very
little
success
with
this
unless
until
there
is
a
disaster
and
whether
that
disaster
is
going
to
be
one
year
out
to
five
year
at
I,
don't
know
but
I
think
our
responsibility
is
to
make
sure
we
have
specified
something
that
would
have
prevented
the
disaster.
M
N
Solanum
Cisco
Systems
I
just
wanted
to
point
out
that
at
least
from
a
standards
prospective
I
don't
know.
If
people
I
know
some
people
have
implemented
the
key
agility,
at
least
for
OSPF,
but
I,
don't
know
about
algorithm
agility,
I
believe
it's
at
least
for
always
PF
algorithm
agility.
But
it's
easier.
It's
easier,
secure
protocol
like
OSPF,
then
it
is
TCP
I
agree,
but
81
77
allows
for
both
algorithm
and
key
agility.
So
the
whole.
N
You
know
if,
if
it's
implemented
the
whole
issue
of
not
being
able
to
update
your
keys,
you
should
be
able
to
do
this
on
an
existing
session.
It's
just
a
matter
of
the
implementations.
Getting
it
right.
81
77
is
the
yang
model
for
key
chains
and
it
describes
what
Jerry
was
alluding
to
how
you
do
overlapping
keys
and
use
important.
You
know
you
send
you're,
you
support
both
both
keys
on
accept
and
you
send
the
most
recent
one
and
then
we're
not
everybody's
world.
You
know
it
I
mean
you.
N
D
A
Also,
if
you
really
think
you
have
relevant
information,
please
send
that
to
the
authors.
I
have
a
feeling
that
asking
so
it
was
a
very
unscientific
survey
we
did,
but
the
feedback
was
that
there
are
very
few
authenticated
LDP
sessions
out
there.
The
Iran
md5
vs.
shed
some
good
ships
and
checksum
tool,
but
it's
not
really
any
authentication.
So
we.
A
A
D
Okay,
so
I'm
doing
a
poor
impression
of
Adrienne
for
this
next
slot,
so
we're
gonna,
we're
talking
about
the
MPLS
based
forwarding
plane
for
service
function,
chaining
that
about
the
list
over
the
last
a
few
a
few
weeks.
So
next
I
don't
I
so
here's
the
agenda.
We
won't
talk
about
the
objectives
and
the
non
objectives
of
the
designer
I
give
a
very
short
overview.
D
Sfp
on
a
specific
service
function
instance,
the
SFC
proxy
may,
an
SMC
proxy
may
be
interspaced
between
an
s
FF
and
an
SFI
in
order
to
allow
a
legacy
front
service
function
instance
to
a
deal
with
the
service
function
chain.
So
what
are
our
objectives?
We're
not
trying
to
replace
our
obsolete.
The
nsh
that's
been
designed
in
the
SFC
working
group,
and
it's
not
out
most
to
touch
it.
We're
looking
at
a
specific
environment
where
deployed
MPLS
rooters
can
serve
as
service
bunch
of
orders.
We
want
to
make
no
change
to
the
forwarding
plane.
D
We
want
to
work,
we
using
existing
MPLS
forwarding
operations,
it's
push
pop
and
swap,
and
we
want
to
be
able
to
forward
SFC
packets
at
nights,
so
we're
looking
for
a
high-speed
implementation
using
existing
hardware
where
their
hardware
is
already
deployed
in
the
network.
Our
aim
is
to
get
high
level
of
SMC
functionality.
Possibly
has
some
features.
Some
features
will
be
sacrificing
to
do
this.
They
will
be
sacrificed
to
do
this.
We
must
support
the
SMC
architecture.
D
D
The
SFF
uses
the
top
label
first
label
it
pops
to
identify
the
path
providing
local
context
and
to
select
the
path
of
the
to
the
next
s
FF
and
uses
an
SF
s
as
the
second
label
to
identify
the
service
function.
That's
rien,
SF,
l,
I.
Think
in
that
and
I
said
yeah
the
second
label
the
SFF
uses
the
SFL
identifies
the
SM
so
nits
and
editorials.
D
These
are
the
things
that
we
change
from
0
1
to
0
for
RFC
80,
381
74
have
been
published,
we've
changed
the
use
of
the
S
flag
and
the
S
appeal
to
be
the
s
bit.
What
it
should
be
bunch
of
abbreviations
have
been
expanded.
We've
added
a
section
on
proxies
which
I'll
talk
about
later.
We've
clarified
metadata
usage
and
we
fixed
some
of
the
typos
so
below
the
discussion
about
sick
of
routing.
An
Adrian
sent
a
note
from
the
from
the
author
team
to
the
list.
D
D
We
don't
think
really.
This
is
segment
routing
that
we're
talking
about.
We've
removed
all
discussion
from
about
about
second
routine,
specifically
MPLS
SR.
We
only
talk
about
normal
MPLS,
forwarding,
plane,
operations,
pusher
pop
and
swap
as
absolutely
you
know,
the
the
keynote
of
the
work
we
do
here.
We've
not
discussed
the
control
plane
mechanism
is
in
any
detail.
D
We
need
to
continue
to
discuss
the
use
of
labels
doing
flow
code,
information
included
in
an
SH
how
to
handle
metadata
data
with
labels.
Some
people
like
the
idea
of
doing
this,
some
people-
don't
we
need
to
have
the
discussion
we
nee.
It
seems
that
that
the
draft
is
now
in
a
state
or
it
will
be
in
a
state
where
it's
really
an
MPLS
draft,
and
but
we
will
need
to
review
it
in
the
service
function.
Training
working
group.
D
There's
a
debate
on
whether
such
a
service
function
forwarder
should
exist.
Should
we
need
to
know
whether
the
author
should
describe
how
the
SFF
functionality
works
or
whether
and
that
should
be
left
for
the
implementers
and
the
vendors
as
part
of
their
their
some
private
work?
Who
is
not
our
objective
to
obsolete
or
modify
the
nsh?
We
assume
that
that
work
will
continue
and
will
continue
to
deployment.
So
0-5
will
add
clarity,
red
text,
clarity
on
the
objectives
and
the
non
objectives.
I.
D
Thought
John
was
going
to
say
something:
service
function,
training,
so
transport
independence,
the
NS
H
is
transport
independent.
This
draft
shows
how
MPLS
can
be
used
as
that
transport.
We
think
that
this
is
the
most
likely
use
of
this
particular
block
of
work
between
SF
deaths
and
the
service
functions,
n
SH,
and
this
document
or
transport
independent
there's,
a
discussion
on
the
next
slide
about
proxies
and
SF's
are
usually
Ethernet,
vh,
r
and
p
w
attached.
So
you
know,
then
there
needs
to
be
some
sort
of
mapping
between
the
two.
D
D
Service
functions
are
usually
legacy
in
a
VN
s
and
p
NS
and
are
not
SFC
aware
by
definition.
So
in
order
to
get
between
one
and
one
world
and
the
other
we
have
to
use
a
proxy
proxy
has
to
strip
the
encapsulation
past.
The
payload
to
the
service
function,
receive
the
service
function,
output
back
using
the
ontological
port
and
then
impose
the
encapsulation
needed
to
get
to
the
next
service
function.
D
D
Metadata
the
document
acknowledges
that
we
can't
really
think
that
nsh
can
do.
We
can't
carry
metadata
in
the
same
way,
this
discussion
about
how
we
might
put
some
types
of
metadata
into
the
packet
through
a
label,
but
also
have
this.
You
know
the
possibility
exists
that
the
metadata
could
be
carried
out
of
bound
drunk,
already
provides
explanation
about
this,
and
we
don't
plan
to
change
anything
for
0-5
control
main
this
document
doesn't
discuss
the
control
plane,
but
a
control
plane
almost
certainly
will
be
needed.
The
number
of
options
here
probably
need
a
yang
model.
D
D
Again,
you
know
BGP
seems
to
be
the
right
way
to
do
it
in
in
the
legacy
world.
So
the
next
steps-
this
is
the
last
night
I
think
they're
almost
these
to
polish,
but
we
think
this
is
now
relatively
stable.
Support
for
swapping
and
stacking
is
a
common
way
took
some
effort,
but
we
think
it's
got
good
benefits
fits
with
the
best
control
plane
work,
so
the
authors,
the
approach
seems
obvious,
and
the
authors
think
that
this
is
in
charter
for
this
working
group.
D
Use
of
special-purpose
labels
definitely
belongs
in
MPLS,
but
obviously
needs
to
be
reviewed
with
the
service
function
chain
working
group
so
I
think
the
the
action
for
the
chairs
is
to
decide
whether
this
belongs
and
to
resolve.
Yet
any
of
dr.
adoption
issues
and
the
action
proper
for
participants
is
to
objectively
have
an
objective
discussion
of
the
design.
So
that's
the
end.
O
D
It
really
it's
up
to
the
chairs
right,
the
chairs
of
both
working
groups
and
the
rads
own,
where
work
is
pursued
right.
Our
view
is
that
it
fits
well
in
here
it's
well
within
scope,
and
that's
where
it
should
should
take
place.
You're
welcome
to
work
with
us
on
this,
but
help
you
is
that
this
is
an
MPLS
issue,
but
it's
not
my
position
as
in
order
to
oppose
this.
It's
up
to
the
chairs
and
the
ADEs.
A
P
A
D
O
O
O
In
this
use
case,
you
can
say,
as
our
domains
are
interconnected
over
IP
network
we
can
use
either
we
can
use
any
MPs
who
IP
encapsulation
magnets,
such
as
MPs
or
UDP,
MPs
or
gie,
and
whatever
second
case
is
unable
as
our
MPs
wielding
IP
network.
In
the
case,
we
can
realize
IP
on
the
way,
while
we
can
leverage
them
empty,
SSR
network
program
technology.
O
O
O
And
you
can
say
from
this
details
since
the
source
part
the
UDP
handle
is
filled
with
HIV
label.
If
this,
the
table
label
could
be
contained
when
the
the
packet
that
the
capsulated
UDP
hender,
that
the
job
label
could
be
reviewed.
Well,
really
encapsulate.
The
MPS
packet
with
a
new
UDP
header
in
this
way
is
same
no
need
or
lemonade
to
need
to
insert
one
or
more
inch
oval
labels
into
the
MPs
label
stack.
This
is
very
useful
in
scenario.
Where
still
has
Hardware
limit
on
the
label,
stack
readability
and
misses
such
an.
O
O
For
whole
solution
controllable,
a
control
plan,
work
is
needed,
such
as
say
about
heisman
tunnel
calculated
a
lot
of
development,
but
we
believe
it
should
be
described
in
suffering
document.
So
we'll
move
some
detail
discussion
from
this
draft
next
up
since
the
80s
have
rich
agreement
that
the
work
should
be
done
here
and
the
technology
self
is
stable.
Now,
we'd
like
to
request
so.
A
You
want
to
change
that
question
mark
to
an
exclamation,
I'm.
Sorry
right
now,
I'm,
actually
are
you
asking
for
working
group
adoption?
Okay,
but
you
have
a
question
mark
up
there.
That's
why
I'm
asking
you
said
that
you
also
were
given
to
remove
some
material
from
this
draft.
So
do
you
consider
it
stable
enough
anyway,.
Q
A
H
H
That
we
didn't
submitted
yet.
So
that's
why
we
decided
our
friends
for
this
elated
thanks
your
table
in
order
to
help
with
ever
loopy
drops
with
the
last
year's
actually.
So
this
was
a
draft
that
we
submitted,
but
we
sort
of
lost
energy
on
it
because
for
most
apology,
routing
that
never
really
got
the
points.
H
Now
lost
months,
because
there's
new
work
being
done
on
HP
algorithms,
but
actually
gets
you.
So
it
is
same
solutions
so
reading
the
green
in
the
draft
and
resubmitted
now
to
support
Milt
apology
routing
in
LDP,
a
new
address
assembly
has
been
created
for
LDP,
so
that
others
from
the
encodes
an
IP
address
and
an
empty
ID
right
for
both
the
foreign
key
six.
H
R
H
Okay,
is
this
better?
Okay,
sorry
buck?
You
owe
me
to
restart
okay,
so
we
also
introduced
a
new
capability
right
to
know
whether
your
neighbor
supports
a
particular
address
family
right.
Otherwise
you
don't
you
don't
send
it
now.
So
the
reason
this
God
you
know
we've
got
new
energy
to
which
pushes
forward
is,
is
what
we
call
the
Flex
algorithm,
which
is
both
defined
out
for
is
yes
and
OSPF,
and
flex
algorithm
is
really
a
mechanism
to
sort
of
create
a
more
lightweight
sub
topology.
H
H
H
So
basically,
the
combination
of
the
empty
ID
and
the
IPA
creates
a
unique
effect,
so
each
node
that
receives
that
combination
can
now
take
the
empty
ID
the
IPA
and
identify
exactly
which
unicast
routing
instance.
You
want
to
look
at
in
order
to
resolve
the
route
address,
to
determine
what
your
upstream
LDP
neighbors.
H
A
M
S
What
we
have
mainly
is,
we
addresses
all
the
just
all
the
comments
from
the
yang
doctor
review
from
Jan.
We
are
thankful
for
his
detailed
review
of
the
yang
motto
for
LDP.
We
were
also
missing
a
specification
for
the
default
values
for
the
configuration
parameters,
which
was
also
one
of
the
comment
from
the
yang
doctor,
so
we
have
also
updated
those.
We
have
added
a
couple
of
minor
configuration
items
which
were
missing
in
the
original
model,
especially
specifically,
to
handle
dual
stack
in
case
of
LTP
v4
and
v6
interworking
and
coexistence.
S
Some
of
the
some
of
the
features
that
we
had,
they
were
already
an
extended
model.
If
you
just
recall,
LDP
had
two
models
based
model
and
extended
model,
so
so
they
were
already
part
of
extended
model,
but
they
were
not
higher
feature,
so
they
have
been
made
feature,
and
so
this
revision
for
was
updated
and
we
have
few
open
items
in
the
previous
revision.
So
right
now,
this
revision
has
no
open
items
left
so.
S
Right,
so
just
just
to
highlight
what
young
doctors
comments
were
main
comments,
so
one
of
the
main
comment
was
that
we
have
some
funding
to
do
work
in
the
draft
to
close
on
open,
config,
IDF
and
nmda
compliance.
So
we
have
taken
care
of
this
item,
and
now
we
are
aligned
with
nmda
model.
They
were
lack
of
default
and
mandatory.
You
know
attributes
for
some
of
the
leaves
they
have
been
taken
care
of
some
other
stuff
about
better
description
of
the
Leafs
and
some
automated
mention
regarding
the
password
handling.
S
We
have
a
d5
so
right
now,
our
password
handling
in
this
draft
is
based
on
what
most
of
the
different
deployments
are,
so
over
base
model
uses
mp5
and
our
extended
model
allows
you
to
configure
and
based
authentication
for
LEP
but
I.
But
if
there's
a
need
and
discussion
based
on
you
know
earlier
presentation
by
stay
board
on
md5,
we
may
react,
but
right
notice
how
the
model
is
written.
S
We
also
took
care,
as
I
mentioned,
about
some
of
the
default
values
so
about
a
whole
time.
You
know
gee
our
goal
time
session,
people
our
whole
time.
So
what
we
have
the
approach
you
have
taken,
we
have
not
specified
for
everything.
You
know
default
values,
so
the
values
which
are
already
defined
in
some
of
these
RFC's
for
LTP.
We
have
used
those
values,
the
other
other
leaves
which
are
not
defined
in
RFC,
aware
where
the
default
values
are
not
defined
in
their
respective
Alexei's.
S
We
have,
you
know,
discussed
within
a
team
and
come
up
with
a
good
compromise,
so
you
know
you're
encouraged
to
look
at
the
model
and
comment
on
default
values.
You
know,
and
you
can
provide
us
a
comment
offline
if,
if
you,
you
feel
otherwise
so
next
step
for
this
drop,
so
we
are
I.
Think
authors
believe
that
the
drop,
as
goes
all
the
open
items
we
are
at
a
stage
where
we
can
because
I
work
in
coop
last
call.
A
C
S
S
A
S
Okay,
if
there's
no
comment
on
MVP,
so
what
you
can
go
to
just
quickly,
Emily
P.
This
is
really
a
real
quick,
a
bit
for
ml
DP
and
data
model,
which
we
are
producing
in
parallel
as
a
separate
graph
so
status
for
this
job.
So
we
were
focusing
on
LDP
and
to
make
it
ready
for
working
coab
last
call,
so
no
revision
has
been
updated
since
last
idea.
The
pending
item
of
the
same
well,
VP
drops
are
again.
We
are,
we
are
still
appending
some
default
values
for
some
of
the
complication
options.
S
Minor
cleanup
is
needed
for
this
document
and
I.
Think
the
one
of
the
main
thing
that
we
are
we
have
requested
yang,
doctor
review.
We
haven't
received
younger
career
for
this
document.
Yet
so,
once
we
receive
this,
you
know
yog,
doctor,
zero
or
next
step
is
to
address
those
comments
from
the
under
actor
and
address
any
remaining
open
items,
and
we
are
hopeful
that
mostly
we
are
does
those.
This
document
should
also
be
ready
for
working
blast
cough
and.
A
A
O
N
T
N
U
N
Q
Q
Their
fault
management,
our
spitting
for
anti
OSTP,
is
supposed
to
come
from
the
separate
model.
Do
you
need
to
be
using
the
UDN
model
performance
monitoring?
Yes,
there
is
a
question
of
whether
anybody
will
start
doing.
63
74
was
delay
measurement
model
because
then
entellus
TP
will
be
just
the
profile.
Q
So
we
do
have
to
RFC's
that
demonstrate
how
to
do
proactive
or
OAM
function
management
through
our
suite
ET
extensions
and
extensions
to
LSB
ping,
so
that
definitely
helps
in
developing
the
yang
model
and
itu
they're
doing
information
model
for
MPLS
TP.
It's
a
g8
152,
so
out
of
information
model
as
I
understand,
receiving
or
pulling
on
data
model
is
the
technical
issues,
nothing.
Q
So
the
there
are
series
of
open
issues,
and
recently
we
had
a
discussion
with
Sasha
lunch
team
and
who
participated
and
such
a
broad
series
of
questions
very
good,
detailed
and
pointed
questions
that
I
would
like
to
set
forth
to
the
working
group
because
we
need
to
decide
whether
we
want
to
continue
this
work
and
complete
mpls.
Tp,
om
and
I
would
say
that,
given
the
scope
of
ITU
work,
it
will
be
ITF
defined
or
him
to
set,
because
I
tu
covers
their
own
om,
what
they
did
extending
internet,
om
or
extending
1731.
V
It'll
moosa
from
away
just
at
point
for
information.
Jt
152
is
developing
information
model
for
MPLS
tpoem
and
covers
both
ITF
and
I
QT
tools
and
is
more
based
on
the
functions.
And
then
you
can
have
additional
attributes
depending
on
the
tool
so
and
the
question
is,
will
be
about
how
do
we
want
it?
Are
they
did
this
DM
order
to
be
structured
based
on
the
functions
or
based
on
the
tool
and
or
based
on
a
common
architecture
like
Meg
and
all
the
stuff?
We
to
figure
it
out
that
it's
not
easy?
V
Yes,
because
they
call
it
based
on
the
function,
they
call
is
a
continuity
check
and
collectivity
verification,
proactive
and
on-demand,
and
then
that's
the
tool
that
the
canoes
can
be
EFT
or
can
be
731
tool.
That's
why
it's
not
that
straightforward
to
understand.
So
basically,
it's
more
like
a
mountain
point.
It's
I
want
to
configure
activities
checker
between
a
and
B
at
this
rate,
and
then
Daniel's
you
have
another
attribute,
assess
the
tool
to
be
used
as
PFD
or
sorry
to
achieve
our
CCM.
V
So
basically
them
still,
you
need
a
specific
model
that
does
this
method.
Yeah
you
need
a
tool.
That'll
be
the
configure
attribute
is
the
same.
The
rate
is
the
same,
no
matter
whether
we
use
PFD
or
CCM.
So
the
attributes
the
same
and
then
when
attributed
says
is
the
tool
that
is
the
CMO
PFD
and
then,
if
PFD
requires
additional
attributes,
then
you
have
additional
attributes
that
are
only
for
PFT.
A
E
Q
Y
Z
Thank
you.
My
name
is
Carsten
was
enough
of
me:
NTC
we've
been
testing
MPLS
related
multi,
vendor
interoperability
for
the
last
15
years.
I
just
looked
up
our
first
report
from
2003
we
tested
IRC
25:47
biz
was
a
couple
of
implementations
and
I
always
thought
back
at
that
time.
I
would
really
love
to
get
to
know
other
guys
who
wrote
this
stuff,
really
ingenious
and
new
stuff.
So
here
I
am
so.
Z
F
Z
Able
to
gather
all
of
the
results
from
21
random
so
far,
yet
so
I
just
like
to
focus
one
topic
here,
which
is
LSP
ping,
so
in
effect
we
we
tested
a
whole
lot
of
areas.
We
have
like
some
6070
devices
in
the
test
from
21
vendors,
focusing
on
a
wide
area,
networking
data
center,
peering
stuff
like
that,
and,
of
course,
all
of
the
Sdn
control,
yang
models,
etc.
The
results
will
be
published
in
3
weeks
from
now
at
conference
in
Paris,
and
so
what
we
tested
here.
Z
What
which
focuses
on
this
working
group
is
our
C
to
80
to
87,
LSP
ping
and
traceroute
for
segment
routing
with
MPLS
data
plane,
so
in
all
configurations
is,
is
with
as
SR
extensions
was
configured,
so
everything
seemed
well
from
the
get-go
we
started
preparing
this
in
October.
Last
year
we
had
numerous
conference
calls
with
all
of
the
vendors
interested
8
vendors
planned
to
participate.
Z
In
the
end,
only
3
of
them
succeeded,
so
5
venice,
couldn't
interoperate
at
all,
and
the
reason
for
that
is,
I
will
explain
in
a
moment,
but
basically
we
had
two
scenarios.
We
had
one
scenario
for
a
ping
and
traceroute
with
an
emulated
link,
failure
allowing
us
to
see
the
effects
of
change
in
the
topology
and
subsequent
change
in
the
traceroute
results
and
the
second
one
set
up
in
the
bottom
right.
Z
The
diagram
here
for
ping,
which
allowed
us
to
ping
from
north
one
to
all
of
the
other
nodes
in
this
topology,
so
clearly
simple,
fairly
straightforward,
and
then
we
mixed
and
mention
all
the
different
vendors
as
we
went
ahead.
So
what
happened
was
that
it
seems
like
the
RC
e
287
is
pretty
complex
to
interpret
so
it's
a
very
elaborate
document
with
many
details.
Many
options
for
different
effects,
for
you
know,
routing
options
and
so
on
and
so
on.
As
you
know,
and
so
one
vendor
immediately
so
like.
Z
Actually,
you
know
this,
we
can't
do
all
of
this
multi
hop
FEC
stuff,
so
we
only
support
single
bob
ping
and
traceroute.
Then
we
select
single
hop
trace
right,
that's
not
really
how
its
intended
to
be,
but
anyway,
so
those
guys
have
to
go
back
and
do
some
homework,
but
the
other
seven
vendors
struggled
a
lot
on
the
interpretation
of
the
sub
TLB.
Z
Actually,
the
type
and
links
in
an
effective
stack,
Giove,
so
I
looked
through
the
RFC
and
I
saw
like
this
is
not
the
main
point
and
there
it
turns
out.
The
links
is
actually
never
defined
anywhere.
We
have
to
go
back
to
our
CA
t29
to
really
look
at
the
links,
and
there
is
an
example,
somewhere
page
15,
I
think
which
says
a
length
equals
13.
So
it's
easy.
Oh,
the
links
does
not
include
reserved
elements
that
are
bytes
that
exist
there
in
the
TLB,
but
are
supposed
to
be
reserved
at
0.
Z
Z
So
there
is
a
certain
major
confusion
in
the
industry
which
might
I,
don't
know,
might
be
reasonable
to
result
in
errata
or
some
sort
of
clarification
to
a
t29
or
or
the
LSP
bring
traceroute
RFC,
and
the
other
question
was
also
like
what
how
do
we
encode
the
type
I'm,
not
sure
if
this
is
a
problem
here,
I
just
got
this
from
our
engineers.
If
the
type
of
30
1744
actually
makes
sense,
I,
don't
think
so,
and
so
it
seems
also.
Z
The
type
encoding
is
maybe
sometimes
questionable
and
of
course,
in
general,
what
makes
our
life
as
an
interoperability
lab,
always
a
little
more
complex,
is
if
there
are
many
many
options
in
the
standard,
and
especially
the
protocols
which
were
encoded.
Somehow
correctly,
you
know
is
having
OSPF
and
is
is
and
the
different
protocol
options.
That
makes
it
more
difficult
for
the
vendors
to
come
up
with
exists
and
implementations
for
all
of
the
different
aspects.
Z
So
one
of
the
vendors
actually
had
something
hard-coded
like
oh,
let
me
always
use
one
equals
OSPF
and
if
we
use
ISS
for
the
transport
well,
I,
don't
even
look
at
this.
It's
you
know
a
whole
lot
of
encoding
and
dependencies
in
the
code,
and
so
in
the
end,
that's
why
entire
reality
didn't
work
in
this
small
case
or
I'd
like
to
bring
it
to
your
attention,
maybe
to
review
some
aspects
of
the
LSB
ping
standard
and
also
with
regards
to
the
yang
models
that
were
discussed
just
before
me.
We
love
young
models.
Z
We
love
standardized
yang
models
even
more
because
most
people
just
have
their
own
proprietary
runs
today.
But
when
you
standardize
yang
models,
please
you
know
don't
just
make
them
a
a
collection
of
proprietary
yang
models
just
put
into
a
big
pot
and
stirred
around,
because
this
is
really
making
life
very
difficult,
and
please
use
the
complexity
to
a
level
that
the
majority
of
vendors
out
there
can
understand,
and
even
today
there
are
still
new
vendors
coming
into
this
joining
this
game
and
implementing
things
for
the
first
time.
Z
So
I
don't
want
to
name
anybody,
but
we
had
a
vendor
from
Taiwan
white
box
vendor
this
time.
Also
another
Asian
vendor
who
we
just
came
into
this
game
from
China
and
they're
very
enthusiastic.
They
are
implementing
SR,
b6
and
they're,
sometimes
ahead
of
even
the
largest
Western
vendors,
but
they
struggle
a
lot
understanding
the
contents
of
our
C's,
because
some
of
them
require
a
lot
of
you
know
reference
reading
across
reading
and
options
selection.
Z
So
that's
just
a
very
quick
report.
We'll
have
much
more
details
published
on
April
10th,
so
I
mentioned
the
URL
here
where
we
have
published
a
full
report
is
free
of
charge
is
open
and
we
covered
a
number
of
other
working
groups,
groups
specifically
spring
and
PCE,
but
I'm
not
reporting
reporting
to
any
of
those
here
this
week.
We'll
just
subsequently
make
comments
through
the
main
areas.
Any
question.
AA
An
additional
question
like
how
much
of
the
label
stack
that
we
actually
tested
for
and
how
we
also
test
it
for
edgy
censuses
and
have
you
tested
for
the
label
stack
depth?
How
far
you
can
actually
test
it
for
in
sense,
like
how
much
of
the
label
stack
depth,
the
vendor
devices
are
actually
supporting,
and
the
second
thing
is
for
the
hsn.c
suits
and
those
kind
of
scenarios
have
you
tested
those
as
well?
Well,.
Z
A
second
sorry
I,
just
since
he
said,
oh
I,
see
so
we
haven't
tested
for
the
label
depths,
because
that
would
have
been
like
a
more
advanced
in
our
anyway.
As
you
see,
we
struggled
with
the
basics
with
SRV
six.
We
only
had
very
few
implementations,
actually
supporting
it
successfully.
So
a
lot
of
our
testing
was
actually
in
in
the
basic
areas
of
signal
routing,
SR
v6,
and
we
didn't
get
to
the
more
advanced
topics
such
as
LS
peeping
over
a
SR
v6.
They.
AA
Telecom
I,
of
course,
didn't
read
your
paper.
I
must
admit
that
what
was
your
starting
point?
We
also
had
a
look
into
LS
beeping
and
we
are
applying
it
in
our
network.
Our
take
was
to
start
with
looking
at
what
the
robbers
through
when
you
started
paying
from
them
and
then
simply
copy
that
our
experience.
Z
Is
quite
good,
so
we
always
have
a
zoo
of
implementations
on
one
hand,
so
that's
different
from
hopefully
most
operator
networks
and
secondly,
we
try
to
focus
on
the
latest
drafts
and
developments.
So
of
course,
a
ton
of
stuff
in
LS.
Peeping
is
working
very
fine
and
very
nicely,
but
we
have
basically
completed
those
tests
some
years
ago.
So
I
think
we've
tested
a
sleeping
since
how
long
six
five
six
years-
I'm
not
exactly
sure
but
we've
tested
it
for
some
considerable
time,
and
now
we
focused
most
of
our
efforts
on
unciekin
rotting.
Q
Q
We
confirm
that
the
current
model
confirms
two
new,
our
management
database
architecture
and
we
updated
security
considerations
based
on
according
to
yang
security
guidelines.
Examples
again
are
what's
being
interesting.
That
found
we
found
that
now
it's
recommended
that
configuration
examples
will
use
ipv6
addresses
rather
ipv4.
Okay,
no
problem
and
discussion
continues.
Q
These
are
options
then
do
we
need
a
traceroute
moon,
separate
or
the
traceroute
mode
is
just
instantiation
of
incrementing
TTL
and
TTL
control
is
exposed
in
the
model,
and
the
question
is
that
we
have
new
facts
being
defined
since
the
last
time.
I
will
work
on
this
part
of
the
model
and
the
question
whether
we
need
to
include
all
the
current
currently
defined
facts,
or
it
could
be
extensions
that
will
be
mounted
to
the
model
as
new
types
being
added
and,
of
course,
comments,
discussion,
questions
and
consider
working
group
adoption.
Q
F
AC
AC
AC
So
the
the
peon
capitulation
include
peer
label
and
yehuda.
The
ple
boy
is
also
a
patron
P
label.
It
will
change
your
hope,
I
hope,
like
normal
PN
P,
when
folding
rockets
and
the
Peters
dream
inside
of
the
package,
we
are
not
changing.
Hope,
I,
hope
this.
It's
a
little
difference
from
the
normal
fear
of
builder,
an
AGP.
AC
So
this
video,
the
MLP
extension
to
trade
with
well
yeah
where's,
some
beer,
PA
information,
the
main
part
it's
the
is
in
the
labor
mapping
message.
Forwarding
it
mask,
is
included
in
the
lab.
Imagine,
for
example,
tea
center
to
see
the
lip
imagine.
It
will
include
four
Olympic
mask
0,
0,
0,
1
and
seasoned
to
be
with
a
bit
Massacre
0,
0,
1,
1
and
Pearson
to
a
bit
mask
of
0
1
1
1.
AC
AC
AC
That's
the
introduction
of
the
true
protocol
extension
and
next
up
I
will
add
some
capability
and
era
handle
to
the
ass
VP
are
weaved.
He
loved
the
emotive
he
trapped.
Ordinate
of
such
a
handy
description.
Also
I'd
like
to
get
some
feedbacks,
also
discuss
army
enlisted.
It
is
preferred,
that's
what
thank
you.
X
X
Is
it
in
your
craft,
honestly
I'm,
sorry
I
patent,
yo
speakers,
Lonnie?
Okay,
let
me
repeat
again:
did
you
consider
the
case
of
Nick
before
break
for
our
cpt
point-to-multipoint
LSPs,
the
optimization
case
or
the
global
reauthorization,
and
the
second
part
is
the
pruning
and
grafting
of
sub
LS
B's?
Was
that
audible.
Y
P
Y
AC
A
A
AD
A
So
I
take
what
you
say
is
that
there
is
a
need
for
a
coordination
between
the
tree
shares
for
every
working
group,
so
I
would
take
as
an
action
item
to
send
that
mail
to
both
teas
and
beer
and
MPLS
share,
and
we
can
take
it
from
there.
My
feeling
yes
now
is
that
currently
I
would
like
to
progress
it
here
and
they
actually
read
it.
Is
you
little
bit
later
sure
yeah,
okay,.
T
T
Typically,
at
that
point,
it's
some
other
or
add
some
other
process
that
is
used
to
inform
the
fault
upstream.
If,
assuming
that
there
is
no
other
protocol
running
what
we
are
proposing
is
to
ride
on
that
a
is
message
that
has
reached
earlier.
B-
and
let
me
finish
and
with
an
additional
bit,
indicate
the
fault
and
send
that
a
iced
message
upstream
towards
la
RA,
where
earlier
aid,
if
it
chooses
to
them,
can
coordinate
failover
to
a
backup
LSP.
T
To
do
that,
we
are
posing
a
change
to
our
FC
64:27
feel
one
of
the
fields
to
add
what
is
currently
a
reserve
bit
and-
and
we
call
it
the
RDI
but
which
essentially
says
that
this
is
an
RDF,
remote
detection,
indication
flag
that
it's
coming
from
a
downstream
L
earlier
and
that
the
downstream
earlier
has
received
a
fault
indication.
Okay,.
Q
Can
we
go
back,
I
think
that
your
assumption
or
the
scenario
that
you're
considering
is
not
using
correctly
functionality
of
our
medication
signal
walk.
So
if
you
want
to
inform
their
upper
layer
of
your
mag,
then
you
need
to
have
a
lesser
one
reporting
to
lar.
What
a
the
same.
So
then,
you
don't
need
to
do
anything
from
earlier,
be
to
LR
a
so.
You
have
to
have
a
symmetrical
use
of
alarm
indication
signal
lock.
Q
Q
It's
not
for
carotid
OSP,
it's
just!
Basically
your
need
to
use
it
symmetrically.
You
cannot
say
I
use
it
on
one
end
and
I'm
not
using
on
another
end,
because
then
you
have
a
fractured
system.
Your
state
yes
I
agree.
Then,
basically
you
have
one
leg
or
am
you're
standing
on
one
leg
on
ARB.
You
need
to
stand
on
both
legs.
You
need
to
inform
earlier
a
as
well
through
the
same,
exactly
already
available
means.
T
Q
That's
your
statement
is
in
China,
okay,
first
of
all,
between
LSR
one
in
osr2,
if
you're
using
Proactiv
failure,
detection
more.
Actually
it's
BFD
right,
so
it's
bi-directional
by
itself
already,
so
both
ends
will
know
that
the
failure
being
detected
so
you're
have
all
information
on
LS
are
one
in
the
same
way
you
have
on
the
ORS
are
two
and
LS
are
one
ought
to
report
it.
Q
If
you
want
to
report
to
inform
your
upper
level
that
there
is
a
failure
in
a
server
layer,
so
you
want
to
tell
to
the
client
that
server
failed
don't
be
alarmed
when
you
detect,
because
why
are
you
using
s
because
you
may
be
running
some
failure,
detection
in
a
client
layer,
and
you
know
that
your
server
failed.
You
just
want
to
say:
okay,
don't
be
alarmed.
I
know
there
is
a
problem
when
you
detect
it
don't
bother
okay,
so
you
need
to
do
it
on
both
ends.
Q
P
Okay,
let
me
answer
that,
so
this
is
an
in
band
fault
notification
scheme,
so
you
have
unidirectional
LSP
hang
on
a
second,
you
have
a
unidirectional
LSP
going
from
earlier,
a
to
a
layer,
B
and
you
could
have
been
associated
bi-directional
going
other
direction
right.
So
in
the
failure
of
a
forward
direction.
Lsp
you
are
now
in
band
sending
a
signal
to
the
tail
and
le
RB,
which
is
then
sending
the
RDI
to
the
head
end
that
that
this
is
the
this
is
the
scheme.
T
T
P
Is
nothing
new?
This
is
all
the
time
this
a
is.
Our
di
is
in
1731
and
all
that
stuff,
okay,
that
this
is
just
bringing
that
to
MPLS
LSP,
so
it
works.
This
is
not
for
co
routed
bi-directional,
as
it
said
there
are
these
four
associated
bi-directional
and
you
are
you.
You
have
a
unidirectional
failure
right,
but
you
can
do
it.
Our
medication
signal
out
of
band.
Q
P
T
The
other
key
is
that
this
simply,
we
have
actually
implemented
this
and
it
works
at
scale
and
performance
for
platforms
that
do
support
it.
You
know
for
the
platforms
that
do
not
recognize.
Of
course
they
can.
They
will
probably
not
see
the
idea
of
it,
but
they
will
still
see
the
Albert
and
will
know
that
the
fault
has
occurred.
Yeah.
Q
But
the
problem
is
that
remote
defect,
indication
you're
changing
their
content
because
effectively
for
la
RAL
are
be.
There
is
nothing
wrong
with
this
LSP,
okay
and
remove
the
fact
in
the
indication
is
for
the
particular.
So
basically
you
are
doing
alarm
indication
signal.
You
need
to
change
something
in
terminology
that
no.
P
V
Yes,
you
sent
a
couple
of
comments
to
the
Middle
East.
It's
not
very
clear
to
me
exactly
the
scenario
because
you
may
mention
about
PFD
and
limited
CPU
power,
but
in
that
main
least,
you
were
speaking
about
100
LSP
and
you
can
run
PFD
at
one
packet
per
second
or
so
will
be
your
solution:
generator
receiver,
100
PFD
packets.
Every
second
is
this:
going.
T
T
That
in
context,
right
yeah,
let
me
provide
the
context.
This
is
a
system,
something
like
a
500
megahertz
CPU
and
at
best
it
can
support
32
PFD
sessions
at
10
milliseconds
on
that
system
and
LSP
is
that
number
into
at
least
a
few
hundred
of
thousands
there's
no
way
for
us
to
run
a
beardy
session
for
every
a
list.
Okay,.
V
That's
fine.
It's
right!
I
was
speaking
about
PFD
8:1
per
microsecond,
one
packet
per
second
yeah.
That's
about
a
senior
Lindy
idea,
if
you
to
do
failover
a
coordination
and
as
measured
by
also
by
hope,
the
we
have
the
PSC
protocol,
which
has
exactly
the
same
logic
as
the
one
you
are
proposing.
So
as
soon
as
you're
back
you
get
the
failure.
Your
sensory
packets
and,
in
addition
supports
it's
a
little
bit
more
complex
as
they
machine,
because
it's
not
all
if
reporting
failures
or
is
also
reporting
operators
command,
so
which
that's
right.
V
That's
the
point
is:
do
we
really
don't
have
requirements
to
have
not
support
operators
commands
because
the
user
single
protocol
means
that
that,
in
the
long
term
you
are
going,
we
are
going
to
reinvent
a
PSC
into
FM.
If
you
have
an
operator's
requirement,
operators
common
requirement
type
so
only.