►
From YouTube: IETF105-BFD-20190723-1710
Description
BFD meeting session at IETF105
2019/07/23 1710
https://datatracker.ietf.org/meeting/105/proceedings/
A
C
B
And
eight
f-105
in
Montreal
it's
gender
today
is
mostly
dedicated
towards
discussion
about
futures
of
EFT.
So
try
to
get
to
that
use
the
presentation
fairly
quickly.
So
the
agenda
today,
relatively
short
in
the
grand
scheme
of
things
I,
will
be
having
presentation
on
service
redundancy
sandy
Gregg
will
give
a
update
from
his
last
version
of
presentation
and
VFD
basically
extended
features
and
we're
good
using
that
as
a
seat
to
a
discussion
specifically
for
the
FTP
to
success.
B
B
B
Pfd
for
large
packets
is
also
stable
and,
more
importantly,
Albert
has
actually
done
some
experimental
work
and
the
frf
routing
stack
to
make
use
of
the
feature,
and
we
see
that
it
actually
does
interact
with
itself
in
standard
mode
and
also
journalist,
vmx
and
potentially
other
stuff.
I
have
like
two
slides
I'll
be
flipping
through
that
I'll
give
you
some
data
there.
It's
potentially
ready
for
working
group
last
call.
We
did
a
little
bit
more
testing
with
actual
forwarding
card
Berg,
considering
that
we
know
that
no
real.
B
One
point
that
we
did
actually
want
to
take
a
little
bit
time,
mature
stuff,
and
this
will
be
Mahesh.
The
entity
authentication
documents
that
we
had
specifically
for
optimizing
EFT
and
the
procedures
around
that
had
gone
through
last
call
had
not
received
a
lot
of
no
feedback.
No
getting
glass,
coffee
back
and
BFD
sometimes
tricky
as
it
stands.
The
thing
that
was
the
main
sticking
point
was
that
his
former
employer
had
done
IPR
declaration
on
the
stuff
and
the
text
of
the
Declaration
does
no.
You
follow
the
standard,
IETF,
reasonable
and
non-discriminatory.
B
You
know
status
in
terms
of
what
they
are
applying
to
be
a
key
around.
What
is
not
on.
There
is
text
that
we
tend
to
see
that
is
somewhat
comparable
for
Cisco
and
juniper
as
examples
where
there's
also
a
core
stating
that
this
license
tree
or
no
its
license
free
and
the
text
in
there
does
suggest
that
license
read
it's
potentially
an
option,
but
they
also
exclude
cases
where
licensing
fees
may
be
required.
I
finish:
did
you
want
to
comment
on
what
the
iclear
person
actually
had
said
directly.
C
Right
so
what
the
legal
department
at
Siena,
which
is
the
company
that
filed
the
IPR
said,
is
that
they
looked
at
the
template
of
the
IPS
that
had
been
submitted
against
the
BFD
working
group
and,
in
their
mind,
they
kind
of
followed
middle
of
the
line
text,
as
it
was
concerned
concerning
this
particular
patent
and
felt
that
their
language
was
no
stronger,
no
weaker
than
the
other
part,
and
the
IPS
that
particular
in
the
BFD
working
group,
and
so
their
summary
was
essentially
that
they
are
no
better.
No
worse
off.
Then.
D
D
There
is
clearly
there
is
a
clearly
different
disclosure
language
that
Jeff
characterized,
and
one
of
them
is
characterized
as
covenant,
which
is
different
from
friend,
and
covenant
can
be
interpreted
as
a
stick
behind
your
back.
So
that
says
that
I
would
not
impose
royalties
on
unless
you
go
after
me.
D
B
B
And
I
think
it's
a
mutually,
not
assertive
is
know,
one
of
the
other
terms
that
I
think
popped
up
in
that
conversation.
So
it
was
clear
in
looking
at
the
back
and
forth
that
was
forwarded
to
us
that
the
lawyer
question
did
understand
what
we
were
asking
and
it
was
their
opinion
that
you
know
the
disclosure
as
currently
filed
was
sufficient
for
that
purpose.
B
The
problem
is,
of
course,
new
promoters
were
talking
about
and
know
exactly
what
interpretation
you're
going
to
get
is
good
and
they're
the
mood
for
the
day
to
be
miserly
so
and
unfortunately
not
to
try
to
belabor
this
one
way
or
the
other,
because
we're
not
going
to
necessarily
change
their
mind.
Based
on
what
we've
seen.
E
B
But,
more
importantly,
in
terms
of
what
do
we
do
as
a
working
group
know,
if
the
the
lawyer
in
question
did
actually
point
out
at
least
two
eyecare
disclosures
against
fifty
eight
eighty
itself
know
that
word
no
not
covered
in
similar
ways,
no
lacuna
francisco
as
we
weren't
the
only
ones
that
file
disclosures
on
the
technology
and
at
least
a
couple
of
those
also
we're
missing
the
nuclear
options
and
there
as
well.
So
there
is
precedent
within
VFD
of
technologies
you
know
being
covered
in
such
a
way.
We
do
have
the
option.
B
That's
a
working
group
to
proceed.
You
know
that's
calling
the
documents
and
just
buying
those
their
procedures,
and
the
best
thing
we
can
actually
say
is
that
no
compared
to
some
of
the
5818
that
I
can
afford
the
IPR
declarations
that
were
referenced
to
us
know
as
comparisons,
but
we
do
have
other
eyecare
against
fifty
eight
eighty
that
NIF
all
similar
paths.
So
we
do
have
it
with
a
route.
B
D
Yes
and
and
I
know
that
everyone
has
to
decide
and
draw
the
conclusion
and
we're
not
discussing
like
they
are
here.
So
that's
what
I
want
to
say
is
that
even
there
might
be
a
disclosure
which
uses
front
language
at
the
time
of
progressing
these
documents.
People
might
have
decided
that
this
IPR
is
not
applicable.
That's
one.
B
B
Care
is
decided
to
be
unacceptable
for
the
working
group
that
alternative
methods
can
be
so.
This
is
will
be
one
of
our
discussion
points
when
we
get
around
to
your
presentation,
yeah,
so
I
think
where
we
are
probably
add
at
this
point,
is
you
know
a
bail
will
go
out
to
the
mailing
list
to
see
if
people
are
willing
to
take
down
this
through
the
last
call
procedure
and
if
so
well
do
I
know
editorial
passed
on
things
since
it
has
gone
through
last
call
before
and
decide
how
to
dispatch
from
there.
B
D
Again,
that's
what
I
try
to
stress
is
that
the
fact
that
there
is
a
filed
IPR
against
the
ITF
document,
we
all
encourage
to
look
at
IPR
and
see
whether
we
believe
it's
applicable.
Yes,
I
myself,
I,
look
at
some
IPR
with
their
front
covenant
and
looks
like
I
said
well.
I
would
probably
would
not
advise
to
file
it
because
it's
not
applicable
okay,
but
there
are
different
cases.
The
IPR
might
be
not
applicable
and
then
yeah
I
would
support
it,
because
you
know
I.
G
D
G
D
D
I
You're
American
our
point,
but
we
must
keep
in
mind
that
whatever
we
may
agree
on
with
respect
to
the
applicability
of
IPR
we're
not
accrued
that
will
decide,
and
so
the
ITF
consensus
or
working
with
businesses
on
that
won't
prove
anything
on
what
may
happen
in
front
of
a
curve.
So
you
must
be
careful
with
that.
D
Yes,
I
agree,
so
if
somebody
has
access
to
IPR
War
expertise,
you
can
ask
them
to
give
you
more
professional
judgment,
but
again
by
reading
their
document,
I
think
that
we
can
come
to
the
reasonable
conclusion
sufficient
to
basically
saying
well.
There
is
no
risk
because
it's
kind
of
stretched
too
far
or
saying.
Well,
it's
a
pretty
much
close
call.
J
David
black
TSP
WG
working
group
chair
got
up
basically
a
plus-one
Gregg's
comments
that
I
think
the
the
big
take
where
how
people
take
from
this
is
that
nothing
substitutes
for
your
own
technical
judgment
about
what
is
going
on.
Please
don't
get
carried
away,
focusing
solely
on
what
the
lawyers
did.
B
J
B
And
also
the
dmx
stack
from
juniper,
which
is
a
virtual
machine
based
forwarding
stack,
and
you
know
the
feature
does
seem
to
work
as
expected,
and
now
in
case
you
want
to
actually
dig
into
the
back
of
contents.
You
needed
to
does
apply
that
as
well,
so
I
think
partially
with
this
is
just
a
vacation.
Once
we
get
a
little
bit
bored
in
Iraq,
we
may
actually
move
forward
with
the
last
call
on
this
feature
ended
up
being
probably.
L
M
M
So
the
idea
here
is
that
you
know
in
in
a
network
where
we
want
to
offer
service
redundancy
across
multiple
nodes
like
shown
here,
so
those
services
could
be
layered
or
layer,
3
or
even
layer,
four
services,
or
even
there
seven.
So
we
have
multiple
nodes
offering
the
services
and
in
general,
especially
layer
for
services
and
above,
are
offered
in
active
standby
mode,
not
really
in
active
active
because
they
tend
to
create
state
related
to
the
flows
passing
by
the
nodes.
M
M
M
So
don't
take
back,
don't
take
over
the
service
that
you
were
active
or
so
so
so
for
that
we
we
are
talking
about
a
small
extension
to
be
a
D
and
you
diet
code,
by
which
a
node
that
service
that
detected
the
failure
of
another
node
I
can
tell
that
other
node.
When
comes
back
up,
that
I
was
up
while
you
were
down,
and
that
would
help
as
I
mentioned
in
the
non
revert
of
keys,
meaning
he
is
an
inverter
case.
M
All
the
active
as
I
was
explaining,
wouldn't
take
over
the
service,
because
the
standby
was
survived
as
a
failure
or
was
active
during
the
video.
Of
course,
if
both
the
active
and
standby
went
down,
then
the
standby
wouldn't
activate
any
saying
because
both
failed
and
that
that
code
was
not
used.
What
we
are
proposing
further
here
and
I
guess
it
will
be
part
of
another
discussions
that
will
be
done.
The
working
group
later
today
is
using
the
payload
to
to
communicate
some
optional
bitmap
about
the
services
that
are
offered
by
Z
notes
here.
M
So
so
so,
especially
in
sauna.
Relative
mode
is
an
example.
I
just
mentioned.
If
the
standby
is
activated
for
the
service,
it
can
send
the
back
code
and
optionally
can
send
a
bitmap
of
the
service
that
it
took
over
right.
So
it
tells
active
yes
I
we
are
honoring,
the
deliberative
mode
and
I
am
going
to
take
over
those
I
already
took
oversee
those
set
of
services
described
in
a
bitmap
that
can
be
configured
by
a
controller
that
you
saw
in
the
picture
on
the
first
slide.
M
N
N
But
but
it's
usually
it's
all
or
not
right
all
services
or
no
services
right,
that's
the
way
it
is.
Today
we
have
preamp
mode.
We
already
have
this
revert
of
non
revert.
Oh
that's
been
a
BFT
since
the
the
beginning
right,
you
know.
No,
oh,
wait.
I'm
thinking
a
br,
oh
yeah,
okay,
oh
it's
VR!
Okay!
That's!
So
it's
really
simple!
Then
yeah!
Okay,.
O
M
Okay,
I
think
I
think
what
you
are
talking
about
cases,
whether
you
have
a
split
brain
for
example,
right
and
so
on
right.
So
so
this
is.
You
have
a
point
in
split
brain
kind
of
scenario
in
which
maybe
both
of
them
will
sink
the
other
guys
down.
They
didn't
survive
the
failure,
but
at
least
when
they
come
back
up,
especially
for
non-relative
service.
If
one
of
them
is
saying,
okay,
hey
I
was
up,
then
the
other
guy
can
figure
out.
Okay
yeah.
He
was
up.
He
took
over
services.
M
D
Growing
risk
is
et
regarding
so
one
question
is
that
you
think
that
only
scenarios
that
you
need
to
cover
are
when
you
have
active
and
standby,
that
you
cannot
have
more
nodes
that
can
be
provide
the
service,
the
same
service
so
saying
that
you
might
have
three
nodes.
One
is
active
standby
and
other
is
dr
other.
M
D
What
I'm
driving
to
is,
that
is
the
point
to
point
B.
If
d
is
the
best
mechanism
might
be
look
at
B
of
D
for
multi-point
networks,
because
what
we
found
is
at
four
scenarios
and
AC
mentioned
vrrp
for
VRP
point-to-multipoint
works
very
nicely
and
point-to-multipoint,
I'm
for
sure
for
multiple
networks.
So
now
it's
at
the
RFC,
85/60
I
believe
works
nicely
for
case
or,
for
example,
T
MSM
when
you
have
multiple
PSM
routers
on
a
shared
segment.
D
So
basically,
your
active
just
has
is
a
head
end
of
the
session
and
all
others.
They
are
or
vdr
back
up
or
others
are
listening,
and
in
that
we
might
think
about
how
to
insert
the
notion
of
whether
active
is
non
revert.
If
saying
that
I'm
non
reverted
and
regardless
of
your
priority,
you
should
wait.
Till
I
go
down
okay,
so,
let's
might
be
I,
say
to
the
list
and
talk
about
and
think
whether
point-to-multipoint
BFD
is
provide
more
generic
solution,
because
otherwise
you
have
to
have
multiplicity
of
point
opponent
session
for
the
same
service.
M
M
P
G
P
List
base,
okay
on
Sunday
show
me:
may
I
just
have
a
comment
on
this
particular
pick
Matt,
but
we
are
sending
it's
a
it's
a
come.
It's
a
comment
for
the
working
group
itself.
Like
time
and
again
we
are
introducing
you
know
new
new
payloads
for
BFD
and
increasing
the
IP
être,
so
I
guess
this
should
be
considered
for
be
of
devotion
to
or
the
external
pfb,
where
we
just
introduced
this
as
a
capability
and
you
know
negotiate.
B
B
B
D
So
in
another
motivation,
is
that
to
provide
somewhat
intermediate
authentication
for
beef
this
session,
because
there
what
we
discussed
first,
the
proposal
was
addressing
it
to
more
white
weight.
Authentication,
because
otherwise
authentication
is
the
very
computational
heavy,
especially
if
there
are
a
synchronous
mode
at
three
point
three
millisecond
next
slide,
please.
D
D
Let's
discuss
it
and
then
followed
by
tod
as
very
generic
and
commonly
accepted
method
of
doing
extensibility
till
these
can
be
enclosed.
So
the
obituaries
and
sub
t
Okies
and
let's
see
what
it
gives
us
next
slide,
please
so
for
the
extended
capability
it
starts
with
a
capability
negotiation
which
is
done
for
their
paw
sequence.
D
D
When
we
talk
about
this
in
Prague,
it
was
a
very
good
question
about
okay.
What
do
we
want
to
do
in
three
point?
Three
milliseconds?
Well,
if
somebody
proposes
you
that
they
want
to
do
periodic,
for
example,
last
measurement,
the
other
side
might
say
well,
I'm
not
doing
it
three
point
three
milliseconds
I
can
do
at
100
milliseconds,
so
the
paw
sequence
allows
an
already
existing
mechanism
of
saying
well
how
about
this?
Oh,
no
I'm
not
doing
this,
and
they
they
can
negotiate
what
they
do.
D
Again,
there
could
be
that
ravenous
would
be
monitored
by
one
give
this
session
and
another
be
of
this
session
may
be
brought
up
for
extended,
but
at
the
same
time,
what
I
would
like
to
point
is
that
there
Paul
Moe,
so
everything
can
be
done
in
poem,
ode
and
Paul.
Molt
is
a
query:
it's
a
waked
ping-pong
mod
in
post
sequence
and
BFD
works
as
a
query.
So
one
sense
the
poor
another
looks
at
it
and
responds
either
with
its
Paul
or
with
the
final.
D
Q
D
P
D
Well
again,
as
I
mentioned,
I
think
that
this
capability
negotiation
can
be
done
at
any
stage,
so,
for
example,
so
the
regular
B
of
this
session
is
already
up.
Then
we
want
to
negotiate
saying
that
okay
I
want
to
have
was--and
delay
measurement
done
in
a
poor
mode,
using
poor
sequence
and,
as
Jeff
suggested,
that,
yes,
we
need
to
specify
what
would
be
the
frequency
of
this
measurements
and
the
others
say
size
says
now:
I
don't
want
to
do
it
at
all.
Now.
P
D
D
I
know
right:
if
again,
that's
basically
what
I'm
suggesting
that,
if
no
external,
BD
and
I
think
that
there
is
some
wording
in
a
document
we
discussed
that
I'm.
Sorry
we
discussed
in
Prague
is
that
if
extended
Paul
doesn't
go
so
their
sender
has
conclude
the
other
side
doesn't
support
the
extended
BFD
and
can
revert
back
to
classical
bfd2.
Basically,
he
will
need
to
send
normal
paul
without
extension
and
just
negotiate
the
timer's,
not
the
capabilities.
Okay,.
D
Okay,
so
authentication
capability,
their
authentication
field
in
the
capability
of
e
is
a
variable
length
field
which
characterizes
what
the
length
of
authentication
and
what
the
authentication
type
are
supported
by
the
sender.
And
the
idea
is
that
if
they
both
support,
extended,
BFD
ml
or
support,
light
wave
authentication,
they
advertise
their
capability
and
then
they
select
the
their
largest
authentication
and
the
highest
authentication
mode.
B
D
Authentication
header
quite
well,
because
the
thing
is
that
existing
authentication
header
is
that
it
tied
to
the
configuration
so
they're
in
an
existing
58
80
definition
of
how
we
do
authentication
and
BFD
is
once
it's
configured.
It
has
to
be
an
issue
in
every
packet.
What
we're
proposing
is
that
authentication
capability
is
only
used
in
the
poll
sequence.
This.
D
It's
it's
actually
authentication
is
explicitly
not
to
be
well.
At
least.
We
are
not
proposing
to
be
done
in
periodic
messages
because
it-
and
we
have
this
discussion
with
the
other
proposal-
that
if
we
do
this
in
theoretic
messages,
it
creates
a
lot
of
complexity
of
when
do
you
declare
your
session
down
with
authentication
capability?
D
If
it's
done
in
the
poll,
then
you
even
if
your
litigation
fails,
you
can
receive
whether
you're
not
receiving
final
bid
or
you
receive
the
final
with
the
error
code,
we're
introducing
the
error
code
here
and
then
you
can
draw
the
conclusion
what
you
do
with
the
session.
You
can
take
the
session
down,
or
you
will
say:
okay.
B
D
B
E
So
so
for
tuam
we
had
control
channel,
signaling
and
I
think
you
introduced
them
to
eliminate
some
of
this
control,
channel,
signaling
and
complexity
in
the
network
to
simplify
you
know
using
to
operate
using
the
provisioning
model
so
by
adding
a
lot
more
complexity
in
this
capability
and
and
signaling
in
BFD,
I.
Think
we're
going
in
the
other
direction
for
BFD.
D
Actually,
I
want
to
say
that
in
the
stamp
we
put
up
the
requirement
that
there
is
a
backward
compatibility
with
the
tier
employed
in
uncirculated
mode,
and
there
are
special
mechanism
in
stamp
that
ensures
this.
So
here
what
we
are
putting
is
that
ensuring
the
backward
compatibility
with
the
classical
B
of
D.
B
We
move
into
the
next
bit
of
the
conversation,
so
I'm
just
going
to
kick
this
off
harshly
with
some
slides
we
had
at
Prague.
You
know:
what's
our
motivations
for
extending
things?
No,
we
we
had
VF
e
is
a
very
thin
protocol.
You
know
the
question
I
always
ask
is
what
you
want
to
do
every
three
milliseconds,
our
extensions,
can't
break
our
core
use
cases
and
we've
said
no
a
lot
over
the
years
to
try
to
keep
these
things
true,
and
you
still
managed
to
do
extensions
when
they
made
sense.
We've
talked
about.
B
You
know
the.
How
can
we
extend
no
I
sort
of
opened
up
the
Genie
model
by
showing
that
we
can
stick
stuff
at
the
end
of
the
package?
The
visitor
has
been
holding
my
back
pocket
for
a
number
of
years.
I,
however,
does
it
interact
with
authentication,
as
it's
specified
in
the
core
draft
right
now,
a
BF
d
v2
could
obviously
solve
a
lot
of
these
things
without
going
through
a
bunch
of
tricks
and
I
suspect
that
Square
will
get
drift
driven
very
quickly
and
will
figure
out
that
for
compatibilities
work.
B
We
know
that
fast
things
in
tlvs
don't
usually
get
along
one
of
the
things
we
do
tend
to
see.
That
does
work
around
for
that
IP
fix.
As
an
example,
has
the
idea
of
templates
that
allow
you
to
send
information
very
quickly.
It's
still
structured,
so
there's
ways
around
what
the
new,
but
really
the
motivation
to.
Thank
you
all
they're
coming
here.
You
know
from
outside
the
usual
DFG
stuff.
The
bigger
question
is
you
know
it's
time
you
open
up
the
conversation.
You
know
why.
B
Why
are
we
trying
to
do
some
of
the
stuff
in
DFT
and
know
we
have
as
examples
of
stuff
that
we've
done
before
you
know.
We
have
some
of
the
timing,
loss,
delay,
measurement
type
stuff
that
has
been
previously
covered
by
ITT
M
type
stuff.
They
obviously
have
their
iom
work
and
how
that
might
Interlake
here
is
one
of
the
interesting
pieces,
the
conversation
when
we
start
adding
a
new
stuff.
Maybe
it
was
the
example
for
your
presentation.
If
we're
in
ldm
mode,
we
might
actually
want
to
either
spin
up
a
new
session.
B
We
might
want
to
downshift
our
speed.
Well,
there's
obviously
changes
to
the
coracle
PFD
is
going
to
behave
in
such
circumstances,
so
already
at
the
point
of
this,
isn't
really
no
standard
PFD
anymore,
and
you
know
the
bigger
problem
for
us
no
perspective,
our
ad
is
at
least
things
are
sort
of
weekly
and
charter
to
start
with,
and
you
keep
on
getting
pressure
to
open
things
up
and
the
the
reason
why
I
may
need
to
really
look
at
this
stuff
comes
down
to
I.
Think
a
very
simple
thing.
I
mentioned
this
on
the
mailing
list.
B
Now
BST
is
a
popular
protocol
for
the
same
reason
that
things
like
BGP
and
VMs
are
popular.
It
has
a
particular
structure
that
is
appealing
to
certain
types
work
of
HP's
popular
for
inter
domain.
That's
what's
used
for
DNS
is
a
effectively
distributed
database,
which
design
the
thing
that's
sort
of
popular
about
PFD.
Is
that
it's
a
continuous
channel
between
two
systems
and
provides
a
place
where
you
can
potentially
put
all
sorts
of
interesting
things?
B
So
you
know
using
this
as
a
motivation
for
discussion,
and
this
is
where
I'd
like
to
see
by
more
participation
from
people
from
outside
of
the
birkin
group.
If
T
might
be
an
interesting
channel,
we
don't
necessarily
have
to
put
things
into
the
core
BFP.
You
know
50
80
80
case
itself.
You
know
it's
a
great
mechanism
for
doing
our
continuity
checks.
It's
very
popular.
It's
very
successful.
B
Nothing
stops
us
from
taking
exactly
the
same
mechanism
set.
That's
made
DFT
popular
and
potentially
just
cloning
it
off
into
different
UDP
port,
different
capsulation
type,
something
that
runs
at
a
different
speed.
You
know
that
can
carry
along
expiry
formation
when
it
makes
sense
for
this
conversation,
perpetual
conversation
between
two
systems,
so
the
question
I
like
the
sea
to
the
room
is
knows
like
we
don't
have
to
change
vfe
itself
from
the
core
use
case.
As
we
start
expanding
things
out,
this
is
a
nice
property.
B
So
does
this
make
sense
to
hand
this
off
to
a
different
working
group
as
an
example,
it
would,
for
example,
I
TPM
benefit
from
having
a
EFT
like
no
exchange
where
they
can
profound
things
like
IOM
oriented,
a
situation
where
there's
other
ITF
om
mechanisms,
because
ITF
really
doesn't
do.
Am
your
your
big,
your
big
advocate
of
it?
Is
there
other
groups
that
we
should?
Let
me
start
having
this
conversation
with,
and
it
was
the
room.
D
B
D
R
So
Matthew
Bakshi
not
here
so
this
discussion
reminds
me
of
the
same
deliberations.
You
went
through
with
MPLS
TP
and
we
discussed
using
back
in
the
day
using
BFD
to
do
l,
MDM
and
all
these
other
functions
that
were
required
for
STP
and
we
decided
not
to
it
because
we
all
wrote
either
already
had
tools
to
do
that
or
we
didn't.
R
Control
channel
for
doing
that,
so
we
then
went
ahead
and
created
all
these
other,
like
MDM,
for
MPLS
performance
monitoring
and
created
a
kind
of
a
framework
where
you
could.
You
could
slaughter
in
all
these
different
tools
nicely
in
the
MPLS
context
to
run
together,
so
so
I
guess.
The
question
is:
why
specifically,
do
you
want
to
use
or
replicate
these
mechanisms
or
replicate
similar
functionality
and
BFD
when
we
already
have
these
tools
they're
already
working
well,.
R
D
63
74
is
it's
a
nice
mechanism
and
I
like
it,
because
it
uses
fixed
messages
that
are
symmetrical
in
size
if
it's
done
one-sided,
two-way
measurement,
but
I
think
that
it
works
some
of
their
mechanics
and,
as
Jeff
said,
BFD
provides
a
mechanism
and,
for
example,
this
measurements
doesn't
have
to
be
done
on
three
point:
three
millisecond
the
measurements
can
be
done
using
the
pole
sequence
in
a
way.
How,
for
example,
stamp
works,
send
a
reflector
and
provide
very
nice
performance
monitoring.
R
D
S
Front
proper,
Cisco,
well,
I,
think
negotiation
and
maybe
also
kind
of
more
flexible
authentication.
I
gather
for
doing
things
that
embark
into
performance
measurements
I'm
not
entirely
sure
right,
because
I
think
one
of
the
assets
I
think
you
price
it
very
well
earlier
on,
is
B
of
leagues.
Accept
it
because
it's
simple
and
you
can't
put
loads
of
into
it,
which
is
why
people
run
it
if
we
are
opening
up
that
to
be
really
flexible.
S
Just
that
hamper
acceptance,
I
don't
know
because
we
could
also-
and
maybe
we
should
go
before,
jumping
into
the
extensibility
debate.
We
should
go
and
figure
out
what
we
want
to
go
and
do,
and
we
can
go
do
what
exactly
execs.
It
is
exact,
sorry,
existing
tools
if
you
have
a
set
parallel
session
that
runs
tym
stamp
whatever.
What
can
you
get
from
that
if
you
put
stuff
like
IOM
into
the
messages
that
you're
exchanging?
What
can
you
get
from
that
and
based
on
that,
maybe
can
come
to
a
conclusion
where
we
say
well.
S
This
is
a
specific
app
that
is
small
enough,
so
that
we're
not
overloading
the
if
they,
but
at
the
same
time,
we're
not
replicating
all
that
other
stuff.
Because
once
you're
opening
up
the
thing
to
be
doing
anything,
then
you
might
actually
hamper
B.
If
these
acceptance-
and
that
might
be
bad
right
because
we
don't
want
to
go
and
lose
this
asset
that
we
indeed
ran.
D
I
would
note
that
IOM
is
one
way
measurement
and
basically
it
has
a
problem
that
was
found
in
63
74,
one
way:
measurements
that
what
you
do
with
this
metrics.
You
need
to
export
it.
What
nice
about
using
po
sequence
for
performance
measurement,
it's
yes,
it's
similar
to
tea,
womp
and
stamp-
is
that
this
is
a
one-sided,
two-way
measurement.
So,
basically
the
sender
receives
the
measurement
results
and
can
calculate
the
metrics
and
that's
usually
the
more
operationally
friendly
mode
right.
But
again.
P
If
the
BFD
packets
were
getting
draw
right,
I
mean
it
was
happening
because
in
you
know,
in
one
of
the
hardware,
the
BFG
packets
were
getting
robbed
in
the
host
path
when
the
packet
was
received,
while
the
link
was
up,
everything
was
working
fine.
So
this
was
one
of
the
features
that
we
really
wanted
to
enable
and
disable
on
the
fly
for
a
given
B
of
decision
so
b,
FD
itself.
We
wanted
to
see
whether
it
is
stable
or
not.
P
D
O
O
D
O
So
maybe
I
think
it's
alluding
to
what
Matthew
asked
like
we
need
to
do
the
due
diligence
of
what
the
existing
tools
out
there
cannot
do.
The
the
third
aspect
is
related
to
this,
because
how
exactly
it's
gonna
play
out
with
the
existing
mechanisms
in
various
working
groups,
which
already
does
some
or
all
or
even
part
of
the
the
problems
we
are
trying
to
solve
it
right.
D
D
D
No,
it's
again.
This
function
characterizes
their
stability
of
BFD
session,
okay,
so
B.
If
D
has
this
detector
multiple
parameter,
which
tells
how
many
packets
in
a
row
will
constitute
their
failure?
So
if
you
lose
one
less
packet,
comparing
out
of
detect
multiplier,
your
session
will
stay,
but
is
it
considered
stable
session?
Is
it
a
good
session
so
so
till
now
there
is
no
mechanism
to
know
that
there
is
no
BFD
variable
that
characterizes
how
many
BFD
packets
you
have
lost.
D
Know
but
again,
what
I'm
saying
is
that
there
are
very
specific
mechanism
that
we
discussed
and
Eve
D
group
over
a
period
of
time
that
are
needed
for
B
of
D,
and
the
proposal
is
to
use
the
extension
mechanism
to
do
this.
So
basically,
it's
not
only
for
performance
monitoring
on
the
link
that,
where
B
of
D
runs
on
a
path
that
buildi
runs,
is
just
a
characterized
Beauty
itself
at
the
same
time.
So
as
we
discussed
earlier,
so
the
authentication
mode
is.
B
E
A
kiss
from
Cisco
Systems,
so
I
think
the
current
market
direction
is
to
simplify
the
control
plane.
You
even
eliminate
it
using
the
automation
and
also
the
emergency
recon
right,
so
the
simplified
way
of
forwarding
packets,
so
the
two
things
so
one
is
that
in
IP,
PM
working
group,
if
you
see
the
direction
they
have
been
taking,
is
to
simplify
or
even
eliminate
the
control
channel
signaling.
At
the
same
time,
if
you
look
at
the
team
are
messages
or
even
the
staff
messages,
there
are
messages.
Well,
there
isn't
fixed
offset.
E
So
you
know
exactly
the
merton.
Silicon
will
know
exactly
where
to
put
a
timestamp
where
to
put
a
counter
right
and
also
the
message
size
is
very
small,
because
the
memory
is
very
small
to
load
the
payload.
The
merton
silicon
would
also
know
that
I
only
need
to
load
that
much
of
it
cannot
write
like
byte
number
2048
and
look
for
a
TLB
and
whatnot
right.
So
this
is
the
market
Direction
right
now
and
I
ppm
group
has
the
expertise
to
go
in
the
right
direction
so
doing
the
VAP
way.
E
B
H
H
B
So
I
believe
clarify
my
work,
I'm
talking
about
PFD
as
a
protocol,
not
necessarily
the
FDA
in
terms
of
it
a
given
instance
of
it
so
remember
that
BFD
was
largely
stolen
from
the
hello
mechanisms
of
other
routing
protocols.
No,
it
did
this
is
this
was
a
very
simple
mechanism
that
we
lifted
from
somewhere
else.
We
just
happened
to
put
an
instance
of
it
that
could
run
really
really
fast,
really
really
simple
and
for
the
continuity
check
cases
we've
been
using
it,
for
it's
been
great.
What
I'm
sort
of
suggesting
is
I?
B
Don't
really
think
that
we
want
to
overload
core
continuity
cases
for
BFP,
no
with
all
this
other
stuff.
In
many
cases
you
know
we
have
things
like
authentication
that
we've
had
questions
about.
We've
had
features
that
we've
actually
built
on
top
of
things
that
made
good
sense
over
the
years,
and
you
know
so
if
these
succeeded
in
scaling
up
new
things
that
you
have
to
ask
for,
but
for
other
mechanisms
that
want
these.
B
It's
that
and
that's
the
thing,
and
that's
one
of
the
reasons
why
I
think
this
is
a
broader
conversation
and
thank
you.
Everyone,
who's,
not
a
normal
PFT
attendee
he's
subscribed
the
mailing
list
for
this
conversation,
okay,
yeah
and
it
really
the
conversation
I
think,
is
if
we
think
that
BFD
as
a
protocol
is
useful
for
cadence
other
stuff,
does
some
extent
that
BFD
charter
is
know
about
continuity.
B
That
work,
doesn't,
you
know,
have
a
lot
of
things
happening
from
year
to
year,
if
this
is
BFD,
protocol
format
being
used
for
other
things,
that's
easier,
potentially
new
working
group
or
a
completely
different
charter
stuff
for
us,
but
it
is
not
necessarily
the
core
case
of
what
we've
been
doing
for
continuity.
You
know
the
last
year's
Geetha.
T
Kitten
does
not
occur
Cisco
so
I'm
completely
in
favor
of
we
have
deepen
the
continuity
check
mechanism
and
the
way
it's
been
focused
laser
sharp
on
solving
this
problem.
So
whatever
other
extensions
like
I
think
Santosh
mentioned,
which
can
improve
the
continuity
check
mechanism,
I
think
we
should,
you
know,
continue
doing
that.
But
you
know
this
thing
about
running
another
session.
Another
protocol,
another
thing
just
to
use
the
pole
sequence
I
mean
before
we
get
down
that
path.
T
We
should
look
at
what
other
problems
in,
let's
say,
the
existing
mechanisms
that
are
being
discussed
in
AI
ppm
and
Rakesh
mentioned
some
of
the
directions
that
have
been
taken
there.
So
we
should
look
at
what
those
are
and
if
there
is
a
gap
and
see
what
how
to
fix
that.
So
we
should
approach
it
that
way,
rather
than
the
other
way
Thanks.
U
Yoga
through
here
from
Bloomberg
I
just
want
the
other
quick
comment
with
what
quick
was
saying
about
the
there
are
no
counters
we'd
be
80
today,
so
we
found
with
one
of
the
major
vendors
because
the
PFD
is
implemented
in
hardware.
We
visibility
to
when
packets
and
rum.
So
that's
actually
one
of
the
things
I'm
requesting
the
vendors
to
do.
Is
they
exposed
some
of
those
counters
so
that
we
can
at
least
see
sending
received
counters
and
get
some
statistics
about
how
we?
What
the
quality
of
the
link
is
so.
B
Part
of
the
conversation
about
the
extensions,
no
I
think
there's
no
carry
a
lot
of
weight
to
it.
Things
that
we
are
looking
for
I
keep
on
running
the
cases
where
we
need
to
carry
some
extra
data
with
us.
No
we've
had
the
performance
measurement
nearly
that
presentation
today.
We
know
that
these
things
need
to
be
fast
and
simple.
And
again
whether
or
not
we
carry
the
mechanism
through
for
use
for
other
working
groups
is
a
longer-term
question,
but
there's
also
the
remaining
question
of.
B
Do
we
carry
a
little
bit
of
extra
stuff
specifically
for
our
core
use
case
so
and
that
that
might
be
where
we
draw
our
line
in
the
sand
for
work
within
BFD,
as
a
working
group
for
the
continuity
case
doesn't
serve
that
purpose
and
if
so,
how
do
we
keep
that?
You
know
within
the
fast
requirements
that
we've
got
over
the
years
now,
for
the
other
use
cases
where
again
we're
just
looking
for
a
nice
mechanism
between
two
systems.
You
know
that's
something
to
look
at.
B
Is
you
know
a
expand,
the
Charter
or
a
move
to
other
working
groups?
No
mechanism?
That's
one
way.
This
could
potentially
progress
as
an
example
and
I'm
recommending
this
a
priori.
You
know
if
I
ppm
would
like
they
actually
have
a
mechanism
to
have
this
note
in
her
system
carrier
PFD
is
a
protocols
already
specified.
You
know
what
its
properties
are.
We
know
how
it
behaves
and
if
we're
already
looking
at
what
the
format
would
look
like,
they
carry
such
things.
Certainly
we're
happy
to.
E
B
Okay,
so
this
is
going
to
continue
to
be
I,
think
a
longer
conversation
again.
Thank
you
for
participating.
What
we'd
like
to
do
is
our
next
steps
here
is
taking.
You
know
several
of
these
observations
that
we've
had.
You
know,
trying
to
distill
them
down
a
little
bit
and
start
a
couple
of
threads
on
the
mailing
list,
probably
one
about
extending
VFD,
specifically
for
the
continuity
cases
and
then
VFD
as
a
more
general
mechanism
for
other
working
groups
to
potentially
use
and
will
carry
it
on
from
there.