►
From YouTube: IETF101-BFD-20180321-1330
Description
BFD meeting session at IETF101
2018/03/21 1330
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
C
So,
as
of
this
meeting,
we
have
a
new
area.
Director
will
stand
up
and
say
hello,
everybody
I
think
alvaro
for
no
putting
up
with
us
for
so
long
and
is
now
Martin's
turn
to
have
some
fun.
This,
hopefully
be
a
relatively
piece
of
working
group
for
him,
so
document
status,
the
multi
point,
an
active
tale
document
has
been
sent
along
to
isg
and
as
of
like
a
few
minutes
ago,
I
just
did
the
exact
same
thing
for
the
BFD
yang
document.
C
So
congratulations
to
all
the
people
who
put
work
into
that
and
the
working
group
for
moving
those
along.
No,
you
know
the
yang
document
particular
was
a
long
journey
because
of
you
know
the
ITF
as
a
whole
head
to
get
along
with
learning
yang
and
what
it
means
and
ready
manageability
stuff
is
not
easy.
C
Since
last
meeting
we
did
adopt
the
VFD
4vx
LAN
document,
and
we
will
be
giving
a
brief
update
on
that.
This
meeting
we've
had
requests
for
last
call
from
authors
for
the
authentication
related
stuff,
specifically
the
secure
sequence,
number
document,
the
PFD
stability
document
and
the
optimizing
VFD
authentication.
So
those
last
calls
will
begin
after
IETF.
C
We
also
had
substantial
commentary
on
the
mailing
list
relating
to
some
comments
about
RFC
58
84
edge
conditions,
specifically
about
getting
the
sequence
numbers
know
up
and
whether
or
not
LS
ping
responses
were
actually
mandatory.
I
think
we
came
to
some
level
of
consensus
as
to
the
expected
behavior,
no,
especially
with
comments
from
the
original
authors.
However,
there
has
been
enough
commentary
that,
even
with
an
errata,
we
may
be
in
need
of
some
additional
texts,
so
a
biz
document
may
happen.
C
The
original
authors
for
a
biz
document
are
usually
given
right
of
first
refusal
to
actually
you
know
update
the
document
will
be
contacting
people
about
that,
but
obviously
we
can
add
on
additional
authors.
If
they're
not
technically
interested
Gregg
Mirsky
will
actually
be
going
through
at
least
a
piece
of
this
problem
space
as
part
of
one
of
his
presentations,
so
documents
watched
elsewhere
draft
gen,
PFD
unsolicited.
C
D
C
B
B
So
this
is
a
quick
update
on
the
young
young
model.
There's
been
a
few
a
few
changes
since
we
last
met,
which
I
believe
was
in
Chicago,
as
Jeff
mentioned,
it's
been
hit.
Click
on
the
submit,
ok
button,
so
we
hope
there
won't
be
too
many
drastic
changes
from
now
on
the
changes
since
Rev
5
of
the
document,
we
had
comments
from
workgroup
last
call
and
we
got
you
know
quite
a
few
comments
from
the
yang
doctor.
B
We
had
comments
from
Jeff,
also
which
we
discussed
last
year
in
Prague,
so
in
no
particular
order.
We
had
you
know
we
added
a
grouping
for
the
VFD
clients
key
to
use.
That
was
especially
for
the
eye
GPS,
which
autodiscover
their
peer,
so
that
was
to
make
the
yang
model
more
usable.
The
security
considerations
section
was
was
lacking,
something
really
trivial,
but
we
had.
We
had
a
container.
We
didn't.
Have
we
continued
around
this,
which
is
the
what's
done?
B
This
slide
is
actually
a
little
bit
out
of
date.
All
the
comments
from
the
yang
doctor
on
Rev,
11
and
reft
well
have
been
addressed
and
I
guess
we're
going
to
get
his
Shepherd
writer
tuned
and
done
okay,
and
so
then
that
next
step
will
be
to
look
at
that
and
to
address
any
issues
and,
as
Jeff
said,
thank
you
to
everyone
who
participated.
It's
been
a
long
ride.
It's
not
done
yet.
G
D
D
So
the
recommendation
of
encapsulation
and
encoding
is
that
for
the
inner
Ethernet
header
destination
MAC
address
is
either
dedicated
MAC
address
and
for
that
we'll
need
a
Jana
assignment
or
it's
a
drag.
Mac
address
of
destination,
V
tab
and
the
way
of
learning
this
address
is
outside
the
scope
of
the
document
source
MAC
address.
Obviously,
it's
originating
V
tab
for
their
IP
header.
The
source
IP
address.
Obviously
their
IP
address
associated
with
the
VM
and
destination
is
a
destination.
Our
vita
IP,
one
of
their
IP
addresses.
D
We
still
have
an
open
question
that
we
appreciate
the
working
group
consideration,
how
we
use
IP
addresses
of
internal
encapsulation,
because
that's
one
of
the
areas.
Where
could
be
done
some
interesting
things.
There
is
no
any
input
from
the
implementations
and
if
there
is
no
special
consideration,
we'll
just
remove
this
editor
node
and
leave
this
description
as
it
is.
So
the
TTL
of
the
inner
IP
packet
must
be
set
to
1
and
UDP
port
used.
D
B
E
All
right,
I'm,
going
to
talk
about
PFD
performance
measurement,
actually
shoe
really
wrote
most
of
the
draft
I
could
not
make
it
to
this
meeting
before
I
get
started.
I
want
to
make
a
couple
of
comments.
The
draft
Myton
makes
suggestions
or
forward-looking
statements
that
might
imply
a
newer
version
of
PFT
and
I'm
not
going
to
deny
it,
but
the
purpose
of
this
particular
document
is
still
to
see.
If
there's
some
kind
of
performance
measurement,
we
could
do
that
might
either
justify
the
need
or
not
the
need
to
do
the
next
version
of
PFT.
E
If
there's
such
a
requirement
yeah,
but
that
said
PFT
in
general
assumes
a
link
with
if
a
fixed
characteristic,
if
a
certain
timeout
interval
is
set
on
that
it
does
not
change,
usually
you'll
either
stay
up
or
go
down
so
Andy.
Of
course.
The
other
assumption
is
that
it's
low,
latency
and
low
jitter,
the
idea
is
that
not
all
links
behave
that
way.
E
Specifically,
there
are
these
satellite
links
and
new
geostationary
or
otherwise,
whose
characteristics
change
all
the
time.
So
the
problem
is
trying
to
figure
out
what
interval
to
set
on
these
lengths.
So
this
study
is
to
try
to
figure
out
a
how
to
a
measure
and
B
how
to
optimize
that
interval
that
we
actually
want
to
set
on
that
link
next
slide.
Please.
E
Suggestion
is
that
in
we
use
something,
that's
already
been
defined
in
our
c63
74
for
delay,
measurement
and
override
it
with
the
BFD
aught
type.
Now
we
next
slide,
we
will
recognize,
as
we
say
later,
on,
that
the
Olerud
be
FTO
type,
is
not
extendable
today.
So
with
that
as
an
issue
that
been
believe,
we
still
need
to
resolve,
but
to
go
back
to
why
we
believe
this
study
is
needed
is.
E
The
idea
of
how
to
tune
the
PFD
interval
based
on
link
characteristics
is
not
well
documented,
even
if
people
have
knowledge
of
it.
It's
not
very
well
documented.
The
other
is
that
it's
of
course,
self-contained
mechanism,
since
the
measurement
happens
within
BFD,
and
there
are
no
extra
frames
that
have
to
be
sent
as
a
result.
Yes,
the
payload
is
slightly
bigger
because
you're
carrying
the
timestamps,
but
at
least
it's
happening
in
the
context
of
BFD
itself
and,
of
course,
the
third
argument
kind
of
contradicts
the
second
one.
E
But
yes,
some
land
links
are
sensitive
to
sending
extra
data.
That
is
just
meant
for
measurement,
so
we're
trying
to
see
if
we
can
minimize
that.
But
yes,
the
payload
is
slightly
bigger
with
this.
So,
as
I
said
before,
we
do
realize
that
the
earth
type
is
not
extendable
and
how
that
measurement
performance
is
translated
to
the
actual
calculation
of
the
BFG
interval
is
very,
very
implementation-specific,
but
again
the
point
being
that
58,
80
or
anything
related
to
it
does
not
quite
still
define
the
mechanism
for
determining
what
that
interval
ISM.
Most
of
the
time.
D
E
D
D
Then
then,
you
have
a
huge
complexity
of
how
you
collect
all
the
time
stamps,
because
if
you
use
a
synchronous
mode
that
each
node
sends
its
packet
separately,
so
how
you
transport
the
time
stamps
from
there
ingress
to
the
egress
I,
see
it's
unnecessary
complexity
and
you
can
use
two-way
active
measurement
protocols
and
then
you
can
extrapolate
your
measurement
results
because
it
does
it's
over
UDP.
So
it's
pretty
close
to
what
BFD
will
experience.
E
Of
all
I
think
if
you
could
go
back
a
couple
of
slides,
so
sorry
yeah,
the
next
one,
please
yeah,
so
we
pretty
much
saying
that
we're
trying
to
follow
what's
defined
in
63
74,
for
how
to
collect
a
what
time
stamp
selected
now
as
far
as
the
actual
time
stamp,
it
is
you
that
that
is
collected
at
initially
when
it's
transmitted
its
you,
what
the
sender
will
put
in
T
1,
which
is
the
first
time
stamp
1
field
and
time.
Sam
tous
is
similarly
the
receivers
a
and
then
you
sending
the
same
you're
copying.
C
You
know
so
please
we
do
have
comment
from
jabber,
which
think
like
somebody's
pasting
into
the
ether
patch
as
I'm
looking
at,
because
I
could
get
onto
jabber.
Ashesh
says
that
are
we
in
agreement
that
the
issue
proposed
in
the
document
is
real?
If
so
yeah
they
are
flexible
on
the
actual
mechanism.
Okay,.
D
E
D
E
Okay,
so
number
two,
and
if
I
can
just
finish.
The
second
I
is
that,
if
you're,
if
you're,
trying
to
figure
out
the
detection
interval
of
PFT,
why
would
I
go
measure
it
with
something
else
rather
than
BFD
itself,
which
has
the
capability
or
can
be
made
to
have
the
capability
to
carry
timestamps?
Because.
D
Even
in
the
transit
nodes,
if
you
even
if
you
have
multiple
VIP
hopes
on
your
path,
it
doesn't
matter
whether
it's
beef,
D
or
not,
because
they
just
for
this
traffic
so
and
in
the
measurement.
You
should
ignore
the
processing
by
the
host
to
do
the
measurement,
because
you're
only
measuring
effectively
what
you're
measuring
their
transit
delay
on
this
path.
So,
regardless
of
what
packet
it
is,
it's
your
host
processing
by
the
ingress
and
egress
of
your
test
points
should
be
excluded.
I,.
C
So
the
whole
point
is
you
bring
up
DFT
because
you
want
to
have
the
up-down
behaviors
that
DFT
give
you
that's
good
you're,
trying
to
tune
it
to
now
actually
have
no
a
reasonable,
lower
threshold
mm-hmm
the
problem
becomes,
you
have
to
be
careful
about
tuning
it
down,
and
then
it's
drops
before
you
would
actually
get
no
additional
performance
information
from
it
back
so
well.
I
I
understand
your
use
case
and
think
that
it
would
be
good
to
figure
out
a
way
to
allow
for
some
level
of
tuning.
H
C
Dropped
packets
to
do
this
sort
of
thing
is
an
example,
but
that
was
using
echo
to
actually
carry
that
test
out
as
a
side
thing
so
for
single
hop,
PFD
I
think
you
can
actually
get
away
with
no
using
echo
as
part
of
your
probe
mechanism
or
as
Greg
is
suggesting
an
alternate
Channel,
but
I
think
that
trying
to
actually
carry
out
self
tuning
within
a
sink
itself
may
be
tricky
at
best.
So.
E
If
the
interval
is
said,
of
course,
high
enough
to
begin
with
yeah
and
the
idea
being
that
you're
not
dropping
packets,
because
the
detection
interval
is
too
low,
it
would
be
that
you
thought
you're
collecting
enough
samples
to
figure
out
what
the
interval
should
be
there
by.
You
would
drop
the
minimum
number
of
packets.
So
you
wouldn't
start
off
with
a
very
aggressive
detection
time
on
I.
C
Understand
you
start
with
something
no
higher
than
expected.
You
expected
the
tune
itself
down
and
then
you
need
to
actually
have
it
self
adjust
past
that
point,
but
for
a
lot
of
EFT
applications.
Much
of
what
you're
looking
for
is
that
you
support
at
least
whatever
the
negotiated
minimums
are,
and
if
you
can't
support
that
weis,
whether
for
self
tuning.
E
C
C
C
And
the
reply
is
also
that
this
is
an
issue
that
we
face
a
non
geostationary
orbit
satellites.
So
that
was
somewhat
the
case.
That
I
was
expecting
out
of
this,
that
you
have
some
level
of
variability
and,
while
I
understand
that
in
such
situations,
no
the
detection
interval
might
actually
be
somewhat
periodic.
You
know
they're
times
you
can
be
more
aggressive
than
others.
It
seems
to
me
that
what
you
should
tune
for
is
basically
the
worst
case.
Yeah.
D
Actually,
just
came
to
me
that
that
might
be
interesting
as
well
for
BFD
of
over
microwave
links,
because
as
microwave
links
can
change
their
bandwidth
available
based
on
external
environment,
so
going
to
the
less
aggressive
intervals
to
ease
condition
for
their
service
traffic
might
be
interesting
scenario.
But
again,
that
would
I
am
very,
very,
very
concerned
about
oughta
adjusting
algorithm
and
mechanisms,
because
sometimes
they
produce
unexpected
results.
C
And
final
comment
from
ashesh
we're
out
of
time
for
this
presentation,
the
reason
for
Auto
tuning
is
that
we
have
tens
of
thousands
of
terminals
and
with
each
each
of
them
with
different
characteristics.
They
can't
all
be
manually
tuned
to
provide
reasonable
performance
and
so
again,
well
I.
By
the
use
case
of
you
know,
you
do
want
to
figure
out
what
the
timing
is
using
BFD
the
self
tune
may
not
be
know
thoroughly
appropriate.
So
that's
the
discussion,
I
think,
is
that's
worth
having
okay.
Our
next
presentation
is
the
one
from
anchor
Chen.
F
C
Okay,
so
I
am
presenting
this
on
behalf
of
Anka
Chen
naming
Shen
and
Robert
Rock.
This
is
BFD
Ansel,
the
EFT
for
unsolicited
applications,
the
motivation
for
this-
and
this
is
me
reading
between
the
lines
this
originally
came
up
in
the
context
of
the
route
server
VFD
document,
which
I'm
under
the
co-authors
on
covering
exchange
point
environments
where
the
next
hops
themselves
aren't
something
that
need
to
be
tested
because
of
the
deployment
scenario
moving
on
to
their
slides.
C
Their
problem
statement
is
that
explicit
configuration
or
registration
is
required
by
both
sides
know
for
current
BFD
protocol,
in
this
case
they're
talking
about
58
ad
1582.
So
this
works
well
for
sessions
that
have
application
applications
I
have
sessions.
Now,
for
example,
you
know
BGP,
you
know,
is
configured
OSPF
has
discovered
through
adjacencies
through
the
hello
protocol,
but
this
is
too
restrictive
and
difficult
for
applications
without
sessions.
Next
slide,
so
examples
of
these
types
of
applications.
C
You
know
static
routes
as
an
example.
Next
top
can
be
set
up
to
be
monitor
using
VFD,
but
this
typically
requires
configuration
on
both
sides
and
only
one
side.
They
need
the
actual
tracking
going
on
the
curb.
No
workaround
is
configuration
is
done
in
both
sides
in
the
case
of
BGP
third
party
BGP
next
hops.
This
is
a
next
top
received
from
a
BGP
speaker.
Now
that
happens
to
be
peering
on
one
address
where
the
next
hop
is
not
the
same
address.
C
C
So
the
procedures
that
they're
suggesting
for
unsolicited
BFD
is
that
one
side
plays
an
active
role.
The
other
one
plays
a
passive
role.
Only
one
side
actually
initiates
a
session.
The
passive
side
accepts
connections
from
the
active
side-
it's
not
written
here
but
effectively
in
a
wild
card
mode
and
that
the
feature
should
be
run
only
on
a
per
interface
basis,
that
the
PFD
parameters
could
be
interface
or
router
base
and
that
passive
roles
may
change
active
roles
depending
on
you
know,
situation
next
slide.
C
So
there's
security
considerations
is
that
the
features
should
be
limited
to
specific
interfaces
and
to
use
GTS
M,
where
the
TTL
is
at
the
255
that
the
environment
is
generally,
as
are
the
features
only
deployed
in
trustworthy
environments,
for
example,
internet
exchange
points
or
between
provider
and
customers,
that
access
lists
be
provided,
so
that
subnets
and
hosts
are
used
to
say
what
we
willing
to
do
this
and,
of
course,
BFD
authentication
could
be
used.
Although
an
exchange
point
environment,
this
is
probably
something
that
doesn't
make
a
lot
of
sense
next
slide.
C
So
the
next
step,
they're
asking
for
working
group
adoption,
the
the
point
I
had
made
to
them-
is
that
this
is
partially
covered
by
some
of
the
solutions
space
that
SPF
D
was
originally
defined.
For
that
said,
one
of
the
reasons
why
this
is
being
suggested
is
that
58,
ad
style,
DF
D,
is
very
common
and
well
deployed,
and
this
is
basically
a
very
minor
change
to
you
know
an
implementation.
As
an
example,
I
asked
our
own
BFD
developers
what
it
would
take
to
do
this
and
sure
enough
know,
at
least
in
the
unix-like
code.
C
We
already
use
a
wild
card,
listen
to
actually
catch
things
and
dedication
is
done
before
we
know
call
the
except
on
the
socket.
They
suspect
this
is
common
for
a
lot
of
people,
so
for
some
PFD
implementations
this
may
be
a
trivial
change
versus
moving
to
the
SP
FD
initiator
and
a
replicator
reflector.
Thank
you.
So,
at
this
point
now
they're
asking
for
adoption
and
discussion.
That's
you.
I
I
C
I
D
C
D
C
Incase
without
the
author's
to
carry
further
discussion
out
on
the
list,
this
is
largely
the
socialize,
the
idea
and
less.
If
you
do
know
for
certain
that
there
is
implementations
that
outright
do
this
as
I
mention
it's
a
trivial
code
change
it
no
I,
don't
think
there's
any
interrupt
issues
and
you
know,
is
informational
document.
This
might
actually
be
fine.
If
not,
we
could
decide
that
there's
nothing
to
be
done.
C
D
But
then
we
decided
that
expertise
in
BFD
a
group
and
we
need
to
decide
it.
What
we
do.
So,
what
is
seen
as
under
specification
in
58
84
is
how
active,
BFD
peer,
bootstraps
VFD
session
over
MPLS
OSP.
The
1584
requires
it
to
use
LSP
pink,
LSP
pink
has
to
carry
be
if
the
discriminator
TLV
along
with
effect,
so
when
everything
verification
that,
with
LSB
pink
packet
being
validated,
then
their
remote
BFD
peer
expected
to
allocate
local
the
discriminator
of
its
own
use.
D
Bfd
discriminator
arrived
in
our
speeding
and
send
the
FD
control
packet
to
their
initiator
and
what
to
do
with
LSP
being
itself.
It's
originally
been
left
unspecified
in
a
discussion.
There
was
clarified
and
now
there
is
more
clarity,
but
it's
still
kept
as
a
rata.
So
because
the
sender
can
choose
a
different
return
mode,
it
can
say
by
default
return
over
IP
or
it
can
send
do
not
return.
D
But
then
the
open
question
is
what
to
do
with
the
BFD
discriminator
and
in
what
manner.
If
reply
is
required,
the
receiver
of
echo
requests
should
reply
because
sending
its
own
BFD
discriminator
does
no
good.
So
it's
not
helpful
because
you
cannot
really
identify
leave
this
session
by
someone's
the
discriminator.
You
can
only
demultiplex
using
your
own
beef,
the
discriminator
so
then
to
BFD
discriminator
till
these
should
be
sent
out
or
we
need
to
come
up
with
a
new,
be
read
new
TLV.
That
includes
both.
D
J
D
No,
but
may
again
may
now
is
already
it's
part
of
80209,
because
there
are
so
many
different
options
of
how
to
set
reply
mode,
so
we
don't
need
to
specify
which
already
part
of
80209,
but
if
we
want
to
make
the
process
more
definite
definitive,
then
we
need
to
say
which
mode
is
preferable
for
bootstrapping
being
the
session
/
LSB.
My
question
is
you.
J
Know
you
you're
saying,
should
not
send
it.
Okay,
that's
fine!
I'm!
Fine
with
that,
so
on
the
way
back,
you
say
you
can
either
say
should
not,
in
which
case
he
might
do
it
and
then
what
are
you
do
on
the
other
end,
so
I
thought
we
should
just
say,
nay,
ignore
it
instead
of
must
ignore
it.
Well.
D
Because
again,
if
they
ignore
it,
so
what
it
doesn't
ignore
and
how
to
interpret
swirl.
It's
an
implementation
specific
because
again,
if
we
have
to
Le
ours
right
so
one
which
will
include
be
if
the
discriminator
teo
V
in
the
reply
and
another
will
do
some
conclusion.
Based
of
that
which
is
are
not
specified.
D
J
J
C
The
two
sort
of
meta
points
that
popped
out
in
the
working
group
this
discussion
first
one
was
know:
should
you
send
the
reply
now?
Some
people
are
expecting
it
because
you're
doing
a
ping
and
if
you
ask
for
a
reply,
should
get
it.
The
second
issue
is
when
you
do
get
a
reply
and
you
get
the
discriminator
and
it's
inconsistent
with
what
BFD
you
know.
Almost
amelia
is
going
to
send
back
to
you.
What
do
you
do
about
that?
C
So
the
first
piece
about
whether
you
send
it
not
back
or
not,
though
the
answer
on
the
list
was
basically
follow
the
procedures
of
the
LSP
ping.
So
if
you,
if
you
were
to
bootstrap
your
session
without
this,
you
know,
should
it
work,
then,
probably
so,
should
you
get
to
reply
only
if
you
ask
for
it,
but
once
you
actually
do
get
to
reply,
what
to
do
about
inconsistent
stuff?
That
is
that's
an
edge
condition
that
was
left
out.
Yeah.
D
Well
there
what
I
am
afraid
of
if
they
will
start
matching
to
be
the
discriminator
of
their
session
and
say:
okay,
there
is
no
match
or
I
cannot
find
this
beef
this
session,
and
thus
it
failed
so
basically
that
they
would
not
properly
correlate
with
the
state
of
beef.
This
session,
that
was
just
bootstrapped,
and
thus
it
will
get
some
confusion
between
what's
being
reported
and
probably
might
try
to
send
another
or
speaking
with
a
bootstrap
or
something
else.
So
basically,
the
authoritative
state
is
give
this
session.
D
The
LSP
thing
is
a
bootstrap
mechanism
and
it's
not
to
be
used.
It's
only
to
be
used
to
validate
that
the
FAQ
is
correct
and
then
it
should
take
the
BFD
discriminator
of
the
egress
of
the
ingress
and
pass
it
to
the
egress
to
use
in
be
the
control
packet
so
and
that's
it,
it
performed
its
role.
That's
why
I
would
recommend
to
suggest
to
use
no
reply,
because
actually,
reply
from
the
egress
serves
no
purpose.
B
B
D
B
I
mean
that's
where
I
agree
with
you,
where
I'm
saying
that
this
creator
is
useless,
but
where
I'm
disagreeing
with
you
is
I,
believe
nothing's
broken.
We
have
useless
information
or
need
to
look
information
or
you
could
say
to
optimize.
We
don't
need
that,
but
the
bootstrapping
process
is
not
something
which
is
frequent.
So
to
me,
I,
don't
view
that
as
being
a
big
issue
again
I'm
talking
as
Rashaad.
K
K
Okay,
no
forget
it,
but
I
don't
think
we
I
don't
I'm
under
the
impression
that
I
don't
think
we
need
such
a
hard
constraint
if
you
receive
it.
It's
up
to
you
to
decide
whether
you
want
to
do
something
wrong
with
it
or
not,
and
you're
responsible
for
the
for
the
wrong
things
you
do
with
in
degree
of
freedom
that
was
defining
left
in
the
original
specification
and.
C
J
C
Is
fair
the
solution
space
but
I'm
afraid
to
say
that
we've
hit
the
end
of
the
time
slat
here
we
can
continue
if
we
have
anything
left,
but
what
I'm
going
to
recommend
is
a
great
the
way
I
read
this
document
is
that
this
could
be
like
the
start
of
the
considerations
for
abyss,
but
this
would
probably
not
be
the
best
document
itself.
Would
you
agree
again?
I.
D
C
And
and
I
guess
my
point
is:
this:
is
a
good
document
to
use
as
a
starting
point
for
formalizing
a
solution.
Okay.
So,
but
let
us
continue
this
on
the
mailing
list
and
as
I
mentioned,
the
original
authors
and
the
document
getwriter
first
refusal
and
it's
up
to
them
whether
they
take
on
additional
editors.
But
they
will
certainly
need
this
discussion
to
be
finalized
in
the
group
before
they
can
start
text
right.
D
D
D
But
the
node
that
is
in
demand
mode
may
send
BFD
control
packets
with
a
P
bit
set
if
something
changes
next.
So
what's.
The
idea
idea
is
that
we
bootstrap
the
this
session
as
defined
in
RFC
58
84,
and
bring
this
session
to
the
Upstate,
and
once
the
session
reaches
up
state,
the
initiator
of
be
if
this
session
puts
its
remote
peer
in
a
demand
mode
by
setting
the
flag
in
a
post
sequence
in
a
VFD
control
packet.
D
Next,
if
we
have
unidirectional
failure
that
will
be
detected
by
the
node
B
as
missing
of
n
consecutive
packets
defined
by
the
detect
multiplier
and
that
were
prompted
to
send
notification,
troll
packet
with
the
P
beat
set
indicating
that
grass
control
so
I
think
this
bit
one
in
a
diet
coat
point
one
in
the
diag
field.
Actually
I
prefer
to
refer
to
as
an
MPI.
D
Goes
into
sending
packets
over
NPOs
LSP
at
one
second
interval,
so
basically
by
figuring
out
that
there
is
a
unidirectional
failure
and
they
need
to
start
operating
as
bringing
up
the
session
next
slide.
So
can
we
go
back
sorry
so,
once
there
defect
condition
being
cleared
again
so
because
node
a
sends
its
packets
with
the
demand
mode
cleared,
node
B
will
come
up
into
a
synchronous
mode.
They
will
form
again
be
if
this
session
and
bring
it
to
the
up
and
then
here
we
go
again
note
a
puts
an
old
beat
in
the
demand
mode.
D
So
that's
the
idea
common
suggestion.
Questions
welcome
greatly
appreciated
I
had
exchanged
with
their
Jeff
about
it.
Jeff
believes
that
this
is
everything
is
very
obvious
and
should
be
known.
So
I
would
like
your
opinion
on
that.
Whether
there
is
any
interest
of
the
working
group
to
have
this
document
as
a
working
group
document
now
or
in
the
near
future,.
D
Next
yeah
I
think
that
this
is
even
simpler,
so
point-to-multipoint
BFD
because
it
does
not
have
a
three-way
handshake
so
that
de-multiplexing
BFD
packets
cannot
be
done
by
your
discriminator
in
a
received
via
the
control
packet.
It
has
to
be
used
source
address
my
discriminator
and
ID
identity
of
the
multi-point
three
in.
D
In
our
opinion,
it's
too
expensive
to
use
ipv6
encapsulation
for
b
FD
over
NPOs
LSP.
So
thus,
if
we
remove
IP
encapsulation
and
use
what
can
be
referred
that
ACH
format,
then
we
need
to
somehow
to
communicate
their
source
address.
So
the
next
slide
right
next
one
nineteen
capsulation
we
need
to
do
extend
defiance
or
snap
I
did
IP
to
address
govt
and
included
in
the
if
dick
after
the
control
pack.
So
that's
pretty
simple.
D
B
D
Hear
less
so,
okay
I
can
explain.
I
agree
that
that
probably
more
in
the
domain
of
anti
OS
working
group
and
I
think
that
originally
and
I
did
present
an
NPOs
working
group.
But
then,
when
we
talk
with
Jeff,
he
suggested
ok,
let's
present
it
to
the
BFD
working
group
and
see
what
the
be
of
the
group
thinks.
So
if
there
it's
agreement
of
the
FD
working
group
that
it
belongs
in
MPLS,
ok.
J
J
D
Guys
catch
and
I
would
just
extend,
because
actually,
the
only
change
that
proposed
here
is
to
the
registry
that
being
defined
by
MPs
working
group.
If
we
keep
it
in
VFD
that
will
require
us
to
communicate
with
the
NPOs
working
group.
Doing
an
impious
working
group
might
be
seems
to
be
making
the
whole
process
much
easier
and
logical.
Yeah.
C
D
D
So
the
details
are
very
simple:
how
it
works
and
how
the
sessions
can
spawned
and
terminate
it
and
what
happens
when
the
master
goes
down
and
the
new
master
being
elected.
So
obviously
it
assigns
locally
it's
a
new,
my
discriminator
and
starts
advertising
and
all
other
authors
who
fail
to
become
master.
They
will
start
listening
to
new.
D
My
discriminator
and
IP
address
actually
IP
address
will
be
the
same
because
it's
a
master
IP
address,
which
is
a
virtual
IP
address.
Ok,
we
can
go
to
the
next
slide.
Yep,
that's
already
covered,
so
this
is
an
extension
so,
and
we
include
just
a
master.
Discriminator
are
after
their
address
list,
next
yeah,
that's
already
covered
so
for
the
PIM
apologize
for
their
very
white
color.
That
makes
it
hard
visible.
So
the
idea
of
PSM
routers
on
a
shared
segment.
D
It
comes
from
current
version
of
pms
m,
which
requires
that
dr
to
be
elected,
dr
elected
in
PMS
m
implicitly,
so
that
each
node
listens
to
hello
messages
and
each
router
can
may
be
assigned
priority,
but
the
tiebreaker
could
be
if
priority
is
either
equal
or
absent
is
not
configured
then
the
tiebreaker
is
IP
address.
So
one
way
another.
The
dr
will
be
elected
by
everybody
on
on
the
same
shared
segment
and
dr
has
a
special
responsibility
for
a
directly
connected
host
because
it
sends
during
messages
to
run
the
group
point.
D
The
proposed
the
use
of
BFD
allows
us
to
do
the
sub
second
detection.
So,
even
though,
in
this
diagram,
only
two
nodes
are
connected
to
the
same
segment.
In
more
general
case,
we
can
imagine
that
there
will
be
a
more
PMS
M
nodes
on
the
same
segment.
So
thus
use
of
point-to-multipoint
BFD
seems
to
be
a
nice
option.
D
At
the
same
time,
use
of
point-to-point
VFD
does
create
unnecessary
state
on
dr
because
effectively
DRS
has
no
interest
in
a
state
of
other
router
on
another
end
of
the
FDA
Jesse.
So
next
slide.
So
the
proposed
solution
is
to
use
point-to-multipoint,
BFD
and
use
P
MSM
hello
message
to
do
the
bootstrapping
so
that
the
router,
which
elected
itself
or
realized
that
its
EDR
will
include
this
optional
TLV
with
its
locally
allocated
discriminator
to
do
the
bootstrapping
next.
D
Dr
and
if
dr
stops,
including
this
govt,
that
should
lead
to
other
non
dr
nodes
on
the
same
segment
to
stop
listening
to
the
FD
a--.
So
next
again
it
was
presented
to
p.m.
working
group
and
they
think
that
it's
interesting,
because
there
were
comments
saying
that,
yes,
there
are
implementations
that
use
pouring
to
point
b
FD
and
in
more
general
case,
when
there
are
more
than
two
notes,
the
point-to-multipoint
seems
to
be
natural
and
logical
vehicle.
To
do
that,
because
again,
there
is
interest
for
expedited
detection
of
the
our
failure
again.
D
Team
working
group
has
dr
enhancement
working
group
document,
which
introduces
notion
of
BTR,
and
this
proposed
mechanism
very
nicely
can
be
used
by
BTR.
So
other
nodes
can
monitor,
BDR
behave
and
do
BDR
election
in
expedited
way
and
actually
BDR
is
learns
the
state
but
doesn't
act
on
it.
So
the
convergence
from
d'art
VTR
is
stateless.
D
C
C
So
this
is
work
that
I'm
doing
with
Albert
foo
from
Bloomberg.
So
the
problem
statement
is,
you
know
there
are
applications
that
run
across
multiple
hops
that
need
a
consistent
MTU
to
behave.
Financial
applications
are
a
good
example
of
this.
They
tend
to
run
over,
know
things
that
are
not
TCP,
because
you
know
they're
real-time.
C
You
know
the
dropping
packets
ends
up
being
very,
very
bad
when
that
packet
contains
a
financial
trade.
There's
an
example
when
something
goes
awry
as
it
no
seems
to
often
do
based
on
know
stuff.
They
hear
from
you
know
my
customers
and
I
suspect
you've
heard
from
your
customers.
They
could
be
very
difficult
to
troubleshoot.
Sometimes
this
is
because
the
path
that's
being
provided
is
provisioned
over
things.
That
are,
you
know.
If
label-switched
and
you
know
the
label
death
may
impact
the
MTU.
C
There
may
be
issues
with
aggregate
Ethernet
pick
your
favorite
headache,
problem
being
that
you
can
actually
see
that
the
MTU
is
actually
no
free
and
clear.
All
the
way
through
LSB
ping
does
have
facilities
that
do
some
level
of
this
stuff,
but
it's
obviously
not
meant
to
be
used
extremely
high
rate.
So
question
is
this:
is
there
something
we
can
do
about
that
with
better
speed?
C
The
FT
has
at
least
some
of
the
right
shape
for
this,
but
the
the
sort
of
general
problems
that
the
FTP
News
just
aren't
all
that
big,
no
a
matter
of
fact
are
BFT
linked
in
the
protocol
is
one
octet.
285
bytes
is
even
close
for
most.
These
applications
next
slide.
Please.
So
the
proposed
solution
has
taking
advantage
of
a
clever
bit
of
hacker.
C
Ii
is
the
Dave's
when
they
were
specifying
58,
80
intentionally,
didn't
talk
about
how
the
encapsulation
an
IP
actually
worked,
and
this
is
to
some
extent
now
something
that's
been
held
up
in
our
back
pockets
for
a
while.
Now
they
have
experienced
in
IGP
land,
where
they
did
sort
of
the
same
trick,
eventually
to
add
an
authentication
onto
OSPF
as
an
example,
since
it's
not
specified
that
the
encapsulating
IP
UDP
or
whatever
no
transport
you
have
on
top
of
IP,
is
for
BFD,
you
can
make
it
bigger
than
the
BFD
contents
know.
C
The
protocol
specification
is
very
clear
about
the
pieces
that
you
must
take
care
of
and
leaves
a
lot
of
open
space
for
the
rest
of
it.
So
the
proposed
solution
is,
you
simply
make
the
packet
fatter
and,
in
this
case
I'm
suggesting
Europe,
add
the
rest.
No.
This
is
where
we
get
into
discussion
next
slide.
C
So
the
draft
is
in
its
initial
State
of
just
saying
this
is
a
problem.
Here's
one
thing
we
can
do
about
it
and
it
has.
You
know
some
interesting
questions
embedded
in
that
space
as
well
know,
one
of
the
good
things
that
was
you
know.
Why
would
you
want
a
zero
padded
wide
not
to
actually
stick
a
bit
test
pattern
in
there?
We've
actually
had
other
people
respond
as
part
of
that
mail
chain.
That
guy
kicked
off
that
they
actually
have
strong
interest
in
this
being
done
to
actually
do
bit
pattern
tests.
C
My
response
back
to
them
is:
do
you
really
want
your
line
card?
Doing
no
jumbo
frame
pattern
test
at
the
FT
line
rates,
the
usual
thing
that
as
chair
I
asked
everybody,
do
you
want
your
implementation,
doing
something
every
three
milliseconds
answer?
Probably
not,
but
in
the
case
of
the
application
question
you
know
something
that
does
this
type
of
probing
slower
might
be
perfectly
fine,
so
there's
at
least
interest
in
that
other
reason
and
do
some
level
of
no
zero
padding.
Okay.
C
D
D
C
C
Size
yeah
minimally,
the
behavior
I,
would
expect
if
something
can't
handle
is
no.
For
example,
I
we
had
our
own
implementation
that
juniper
looked
at
once
upon
a
time
we
actually
were
able
to
take
no
packets
of
arbitrary
size
of
the
lion
guard
and
the
group
in
our
PF
eel
and
actually
decrease
the
maximum
pack
of
that
kid
through
to
about
500
bytes.
Originally
the
deal
with
a
specific
DDoS
bug
that
had
come
in
from
customers
yeah,
but
your
point
being
little.
For
example,
you
know
fraud.
C
D
C
Next
slide,
please,
so
this
is
meant
to
be
a
teaser.
You
know,
there's
a
use
case
here.
I
think
that
this
may
be
an
interesting
thing
to
solve
and
I
think
this
is
yet
another
case
where
we're
starting
to
run
into
the
wall.
Of
what
clever
things
can
we
do
with
existing
BFD
v1
without
sort
of
abusing
the
protocol?
And
perhaps
this
is
yet
another
case
that
v2
something
we
should
look
at.
Don't.
C
So
this
is
not
yet
the
call
for
working
group
adoption.
This
is
mostly
to
act
as
a
teaser
to
starting
people.
Thinking
about
is
this
something
we
should
work
on,
how
continue
the
practice
and
the
mailing
list,
and
as
I
mentioned,
this
is
potentially
another
piece
of
support
of.
Is
it
time
to
start
talking
about
EFT
v2?