►
From YouTube: IETF106-BFD-20191119-1710
Description
BFD meeting session at IETF106
2019/11/19 1710
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
B
C
A
C
C
C
C
Okay,
so
quick
agenda,
we're
going
to
go
through
a
chairs
update,
got
to
go
through
BFD
4vx
LAN
EFT
for
large
packets.
Both
of
these
have
been
through.
We're
can
go
at
group
last
call
and
we
were
supposed
to
have
a
presentation
on
one-armed
BFD.
Is
there
one
of
the
document
authors
in
the
room
to
present
that
okay?
Thank
you.
C
So
document
status,
BFD,
4vx
LAN,
had
a
working
group
last
call.
It
created
a
lot
of
discussion
over
300
messages,
which
is
very
unusual
for
DFT.
Hopefully
we
got
over
the
majority.
The
the
discussion
I
believe
it
is
Greg
that
will
actually
be
giving
the
presentation
on
the
current
status
of
things.
C
Second
item
is
we
also
try
to
work
in
group
last
calling
VFD
for
large
packets.
This
actually
prompted
some
discussion
that
had
been
stalled
out
and
we
need
to
get
some
revisions
for
that
I'll
be
covering
that
without
wearing
my
chairs
had
to
for
this
purpose
as
part
of
working
on
BFD
unsolicited,
a
minor
change
was
discovered
to
be
needed
made
at
the
last
second
in
the
BFD
yang
module.
C
C
We
have
a
little
bit
of
an
interesting
situation
for
the
VFD
authentication
documents.
It's
a
series
of
three
of
them.
One
of
them
has
IPR
on
them
that
has
generated
some
discussion
during
IETF
105.
You
know
we
put
forth
to
the
group
that
we
believe
the
documents
are
at
this
point
in
a
technically
viable
and
the
complete
standpoint.
C
No
further
technical
commentary
was
given
on
them.
We
also
asked
if
they
this
working
group
would
be
willing
to
allow
these
to
proceed.
It
is
perfectly
allowable
for
IETF
to
have
documents
that
have
IPR
in
them.
The
IPR
holder,
in
this
case
Siena
noted
that
their
IPR
is
no
more
restrictive
than
other
IETF
BFD
IPR,
including
my
employer
juniper,
who,
which
is
at
IPR
an
RFC
58
84
BFD
itself.
I,
spend
a
little
bit
time
in
the
working
group
discussion.
There
was
a
small
amount
of
show
for
taking
the
documents
forward.
C
It
was
not
a
huge
list
of
the
group,
so
we
have
some
small
support.
I
believe
Greg's
objections
still
stand,
so
that's
at
least
no
one
public,
no
requests
not
to
I've
been
spending
a
little
bit
of
a
ITF
trying
to
discuss
with
the
people
about
our
consensus
process.
With
regard
to
this,
the
general
outcome
of
that
discussion
is
that
the
main
consideration
ITF
has
for
intellectual
property
restrictions
and
documents.
Is
there
implement
ability?
So
if
the
IPR
would
prevent
somebody
from
actually
being
able
to
implement
it,
that's
the
main
consideration.
C
This
sense
that
has
been
given
from
the
intellectual
property
holders
is
that
they
would
offer
licensing
for
it
and
that
it
could
be
carried
forward.
They
declined
to
state
to
know
whether,
if
he
may
actually
be
judged,
though
so,
implementations
such
as
Linux,
which
need
to
be
open,
source
and
free
may
potentially
be
encumbered.
C
So
this
remains
somewhat
of
an
open
discussion
based
on
what
my
process
discussions
and
then
we
have
no
weak
but
positive
force
to
actually
take
the
documents
and
submit
them
to
RFC
that
we'll
be
spending
the
next
several
days.
Concluding
discussions
with
people
is
G
and
otherwise
to
see
what
the
process
looks
like
and
I
will
take
back
to
the
mailing
list.
What
the
process
looks
like
for
that.
C
The
FT
v2
and
other
extending
DFT
discussions,
the
ITF
105
discussion,
was
actually
very
positive.
We
did
have
a
number
of
people
working
on
various
timing,
things
especially
from
the
IPP
I'm,
a
related
group
group
documents.
They
did
that
personally
find
PFD
a
good
fit
for
encapsulating
their
stuff.
C
there
seems
to
be
some
level
of
positive
discussion
on
that.
I
need
to
find
a
way
to
generate
a
discussion
with
enough
of
the
isg
to
figure
out
how
we
want
to
target
such
a
thing
if
at
all,
because
by
expanding
the
scope
of
what
it
carries
and
who
gets
to
use
it,
we
potentially
have
this
work
leaf,
BFD
as
being
the
working
group,
we're
effectively
giving
IETF
a
gift
of
a
state
machine
and
past
that
point.
How
ITF
chooses
the
use?
It
is
part
of
the
Charter
discussion.
D
Okay,
so,
as
Jeff
explained,
this
captures
the
updates
that
were
applied
from
the
last
meeting
to
before
this
meeting,
resulting
from
addressing
some
of
the
Directorate
comments
and
the
discussion
that
we
had
from
only
with
experts
in
vehicle.
And
so
the
discussion
were
more
related
to
VX
LAN
environment
and
what
is
allowed
and
how
VX
them
is
used.
Rather
than
just
to
base
B
of
the
machinery.
D
D
What
is
management
via
ni
and
how
it
can
be
used
for
BFD
over
the
X
line?
Next,
so
yes,
the
destination
MAC
address.
Question
was
raised
in
routing
directorate
review
and
it
suggested
that
use
of
some
MAC
address
is
intrusion
on
tenants,
MAC
address
space,
and
thus
it's
not
allowed
in
the
X
lab,
but
we
did
receive.
D
D
We
formulated
this
following
text,
and
this
is
a
quote
from
their
current
version
of
the
document.
Mr.
nation
Mac.
This
must
not
be
one
of
the
tenants.
Mac
addresses
the
destination.
Mac
address
may
be
the
address
associated
with
a
destination
V
tab,
the
MAC
address
may
be
configured
or
it
may
be
learned
the
control
plane
protocol
details
of
how
the
MAC
address
is
obtained
outside
the
scope
of
the
document
further,
and
this
discussion
is
not
yet
closed
because
we
Furr
recommend
to
use
loopback.
D
One
of
the
loopback
IP
addresses
whether
for
ipv4
range
or
v6,
and
we
leave
MAC
address
for
this
destination.
Ip
address
basically
pointing
to
this
text,
so
we
had
a.
We
have
unresolved
common
proposal
to
use
to
define
some
default
MAC
address
that
will
be
used
if
the
destination
IP
addresses
it.
Look
back
in
my
opinion
and
I
talked
with
Santosh
about
it.
D
So
like
an
active
editors
of
the
draft
that
it
still
goes
back
to
the
dedicated
MAC
address,
even
to
the
more
limited
scope
applicability
so
which
probably
we
don't
want
to
do
yes,
problems.
Some
implementations
of
VX
LAN
that
look
only
at
their
destination
MAC
address
of
an
inner
header
and
then
might
not
look
an
IT
payload.
D
So
what
we
are
stating
is-
and
again
this
quote
from
the
current
version
we
thought
must
validate
the
packet
in
the
destination
mac,
a
of
the
inner
internet
frame
matches,
one
of
the
MAC
addresses
associated
with
the
Vita.
The
packet
must
be
processed
further.
If
the
destination
MAC
of
the
inner
Ethernet
frame
does
not
match
of
the
he
taps,
MAC
addresses,
then
the
processing
of
the
receive
a
excellent
packet
must
follow
the
procedures
described
in
a
vehicle
and
RFC.
D
D
The
following
statement:
users
should
not
must,
even
though
elders
of
the
document
were
quite
inclined
to
use,
must
here
so
you
can
see,
it
says,
should
use
one
of
the
loopback
I
knew
that
will
happen
should
will
use
one
of
the
loop
addresses
and
again.
That
is
because
we
were
told
that
there
are
implementations
that
hard-coded
using
different
than
that
and
will
not
told
that
they
can
be
configured
for
something
else.
E
E
E
A
E
And
we've
also
I've
also
come
across
sort
of
interoperability
issues
with
things
like
early
implementations
of
seamless,
BFD
and
LSP
PFD,
where
people
have
sort
of
some
implementations
will
check
for
one
to
7/8.
Some
won't
and
some
will
discard
if
it's
not
one
to
7/8
and
I'm,
just
worried
that,
if
you're,
if
you're
implementing
this
on
a
box,
that's
also
doing
all
sorts
of
other
flavors
of
BFD
they're
going
to
run
into
issues.
If
you
allow
anything
other
than
one
7/8
again,.
C
So
speaking,
personally,
rather
than
as
a
chair,
I
think
we
all
agree
that
if
you're
writing
this
from
scratch-
and
you
had
a
clean
implementation,
the
procedure
here
is
the
right
thing
to
do,
and
the
proper
thing
likely
to
do
is
an
industry
is
just
simply
to
pressure
people
to
conform
with
this.
Certainly,
you
know
you
as
an
implementer.
Have
that
choice
simply
by
making
sure
that
your
stuff
doesn't
interoperate
with
things
you
consider
broken
I.
E
F
D
D
C
Yeah,
so
the
motivation
to
force
the
change-
you
know
just
simply
say
you
know
you
have
to
be
compliant-
is
that
we
want
to
make
them
do
things
as
best
I.
Remember
the
working
group
discussion.
We
have
currently
two
parties
that
actually
implement
this,
so
we
have
enough
that
verify
that
people
can
actually
do
things
in
an
interoperable
fashion.
C
The
problem
with
taking
your
the
implementations
is
people
are
taking
the
risks
to
help
refine
the
technology,
and
you
know
there's
some
expectation
that
they
eventually
become
conformer
at
the
documents,
but
there's
all
so
a
desire
in
their
part
that
by
our
taking
of
the
process,
we
don't
force
them
in
the
position
that
they
regret
actually
doing
things
early.
So
the
question
becomes:
what
level
of
disincentive
are
we
providing
might
know,
making
them
an
informant?
And
then
you
know
documenting
that
we're
gonna
break
their
inter
up
by
Fiat
I.
Think.
C
Widely
deployed,
though,
that's
my
question,
so
let
me
stick
an
arbitrary
name
in
there.
That
I
do
not
believe
is
the
party,
but
no
FEX
LAN
is
VMware
is
actually
one
that
did
this
and
you
tell
them
well,
you
can't
do
that
and
they're
not
conformant.
How
many
people,
you
think
are
good
right,
implementations
that
actually
no
take
care,
then
yeah.
D
C
Typically,
the
way
we
see
most
of
these
implementations
behaving
is
people
will
throw
in
a
knob
to
turn
on
non
compliant
mode
for
Reuters
and
as
long
as
the
default
discovered
by
the
should.
You
know
it
takes
care
both
the
security
considerations
and
now
you
basically
have
an
implementation
knob
of
last
resort.
D
D
D
A
C
D
C
D
These
sessions
in
management
via
night,
so
the
current
version
stress,
is
that
in
most
use
cases
single
this
session
between
two
V
taps
is
sufficient
to
monitor
continuity
of
their
V
excellent.
No,
but
we
do
recognize
that
there
might
be
cases
when
operator
would
like
to
do
monitoring
via
nine
and
then
there
are
free
to
choose
that.
D
D
We
had
some
discussion,
some
people
suggested
to
use
VMI
number
zero,
but
we
were
informed
that
there
are
some
cargo
and
some
other
considerations
that
might
limit
the
use
of
va0.
So
we
decided
to
not
recommend
semillas
remain
as
a
default
value
for
management,
which
actually
elders
discussion
led
me
to
think,
and
something
that
probably
we
should
can
discuss
with
the
NGO
3
group
is:
do
we
want
to
have
for
the
sake
of
Geneva
document
as
well?
The
document
which
discusses
use
of
management
via
NIU
extent,
I.
D
D
D
C
My
impression
from
the
text
is
that
we
go
back
to
an
IETF
allocated
number
here,
and
this
almost
is
a
request
to
mvo
3
to
designate
this
number
in
that
new
management.
Dock
management
instance
document
that
this
is
the
MAC
address
that
it
should
get
by
default
if
it
doesn't
otherwise
choose
one.
Is
that
a
valid
interpretation?
C
My
personal
impression
for
this
is
that
we
likely
should
not
ask
IANA
for
a
specific
address,
that
it
is
reasonable
for
this
current
version
of
the
document
that
we're
trying
to
RFC
to
say
that
a
number
should
be
used
supplied
by
the
user.
If
we
do
actually
end
up
with
a
management
instance
document
for
mvo
3,
it
is
not
unreasonable
to
ask
that
document
to
potentially
update
this
RFC
does
imply
this
as
a
default,
so
this
is
sort
of
a
backdoor
way.
To
maybe
add
it
at
a
later
point.
E
If
you
don't
have
a
well
known
MAC
address,
aren't
you
asking
every
implemented
a
configurable
knob
for
the
foreign
MAC
address
absolutely
mm-hmm
and
if
it
does
make
it
very
clumsy,
because
I
I
can't
I
think
we
had
discussions
similar
to
this
with
some
other
forms
of
REM
in
MPLS,
TP
and
and
people
just
push
back
and
push
back
and
said.
We
do
really
don't
have
that
sort
of
configuration
well.
G
D
Actually,
I
do
favor
proposal
that
Jeff
made
because
the
document
which
is
more
generic
and
will
address
the
management
vni
for
all
overlay
protocols
and
will
set
for
all
other
protocols
rather
than
BFD.
So
if
we
define
it
here,
that
will
be
the
wrong
place
because
it
will
be
a
limited
or
might
be
viewed
only
as
applicable
to
BFD
I
think
it
should
be
applicable
to
all
communication
between
V
taps,
because
management,
Vee
and
I
is
a
control
and
signaling
channel
between
V
taps.
So
any
communication
between
them
over
this
channel
should
be
using.
D
C
Think
that
is
the
reasonable
thing
to
do.
That's
the
consensus
we
currently
have
from
the
mail
discussion.
We
provided
a
possible
path
that
allows
us
to
add
it
after
the
fact.
Updating
other
RFC's
is
a
reasonable
thing
to
do,
and
this
means
that
we
can
unblock
this
document
through
the
RFC
Q
and
depending
on
exactly
how
much
work
there
is
to
do
in
nvo
3
for
such
a
management
document.
Maybe
that
comes
out
much
faster
than
this.
D
D
C
Eco
mode,
so
for
PFD
eco
mode,
the
consideration
is
traffic
that
needs
to
be
encapsulated
outside
the
protocol.
So
that's
the
reason
why
it
has
to
be
explicitly
set
outside
because
we
have
to
have
the
discussion,
but
the
fording
for
such
echo.
Packets
would
look
like
for
demand
mode
being
on
top
of
a
sink.
It's
a
bass
note
that
band
is
part
of
58
80.
This
core
feature
it.
C
D
D
C
D
C
D
C
So
a
very,
very
brief
update.
Your
requested
working
group
last
call
for
version
1
because
we
thought
it
was
done,
didn't
no
see
any
additional.
Things
need
to
be
added
and,
as
is
often
the
case
than
IETF,
this
scared
people
into
looking
at
the
draft.
We've
got
a
lot
of
feedback,
I
think
less
ginsberg.
The
points
that
we
addressed
from
that
feedback
in
draft,
oh,
which
is
currently
published,
is
there's
more
operational
discussion
about
detecting
MTU
mismatches.
There's
more
discussion
about
ecmp
impacts
that,
when
I
think
particular
came
from
Robert
rush
book.
C
One
of
the
open
items
have
text.
Written
is
still
discussion
about
how
this
operates
with
regards
to
SPF
t
procedures
where
the
reflector
basically
is
a
passive
entity.
In
most
cases,
do
we
want
to
make
sure
that
it
reflects
a
specific
MTU
or
no
could
be
choose
to
screeners
that
each
so
we're
going
to
address
that
as
part
of
oh
three,
we
did
not
specifically
make
any
protocol
changes
as
part
of
the
o2
considerations
notice,
mostly
operational
ones.
C
The
o3
ones
will
be
minor
protocol
discussions
for
SPF
D,
but
again
the
main
procedures
themselves
shall
not
be
altered.
So
since
we
believe
that
we
may
have
addressed
all
the
operational
considerations
that
were
brought
up
will
request
that
the
working
group
last
call,
you
know,
be
reviewed
for
the
o3
version
and
then
we'll
see
about
advancing
that.
Based
on
that,
as
mentioned
in
Prior
presentations,
we
do
have
Interop
between
doe
juniper
equipment
and
some
software
beta
stacks
and
seems
to
work
perfectly
fine.
C
H
Please
I
know
who
you
are
yeah,
that's
thinking.
Maybe
five
minutes
is
enough
and
then
this
is
a
very
sorry.
Would
you
please
stay
for
the
microphone,
your
name?
How
about
this?
You
know
your
valium,
who
are
you?
Okay,
okay,
so
good
afternoon,
my
name
is
a.
We
charge
him
from
China
Mobile,
and
this
use
case.
We
just.
C
H
Okay,
so
the
application
scenario
is
very
simple,
because
when
we
deploy
is
a
data
center,
maybe
we
did
not
open
PFD,
but
in
some
applicants
now,
such
as,
if
we
want
to
use
data
center
for
our
telecom,
we
life.
That
means
something
like
that.
We
call
the
telecom
craft
at
that
appears
general.
We
need
improve.
H
H
We
run
the
PFD
protocol
and
give
the
destination
MAC
address
to
the
NIC,
but
as
the
IP
address
to
itself,
you
know
that
is
overly
network
and
the
the
axle
I'm
will
for
the
PFD
packet
to
the
NIC
directly
and
when
the
NIC
received
the
packet,
eight
got
the
IP
address
and
rotated
back
to
the
Gateway,
so
that
in
the
the
this
application
scenario,
no
PFD
Reister
unique
and
the
we
still
can
use
PFD
to
monitor
the
link
is
quality.
So
next
page.
H
So
we
compile,
in
this
opinion
scenario
and
the
function
to
the
current,
a
PFD
I've
seen
we
found
the
a
ttle.
The
IQ
function
is
used
on
two
systems
that
deployed
of
PFD,
but
our
applicant
scenario,
as
I
just
mentioned.
In
the
other
side,
there's
no
PFD
riced
and
the
next
page.
We
also
see
the
PPF
a
TR.
H
146-
and
it
gives
some
description
I-
think
it's
a
similar
to
the
current
FC.
So
it's
also
not
gives
a
clear
description
if
the
post
cited
the
system
need
a
recipe
FD
together
can
next
page.
So
the
the
the
the
question
for
us
is
that
has
does
echo
function,
require
remote
peer
note
to
support
PFD
protocol.
It
seems
like
it's
not
a
clear
in
current
I've,
seen
as
well
as
the
current
PB
document.
H
So
the
other
question
is
that,
whether
that's
something
else
needed
to
be
considered
with
ICO
dinero's
such
as
a
PFD
armado,
so
our
next
step,
our
proposed,
is
that
it
might
be
modify
the
current
I've
seen
to
clarify
the
PFD
I
call
functions.
Oh
maybe
we
can
give
an
informational
drafter
to
describe
the
PFD
functions
at
the
scenario
I
just
mentioned.
So
that's
how
thank
you,
okay,
so.
C
About
four
years
ago,
I
think
maybe
a
little
bit
longer
I
started
receiving
strange
emails
at
work,
asking
about
running
PFD
with
echo
without
actually
having
the
EFD
protocol
adduce
know.
This
seemed
like
a
very
strange
sinner
to
me
and
I
couldn't
figure
out
what
the
request
actually
was
when
you
look
at
what
was
actually
requested
for
support
from
the
routers
and
from
the
hosts.
C
Really
they
asked
for
packet
loopback,
for
if
the
echo
port
to
actually
be
enabled-
and
it's
like
okay
I
understand.
This
is
not
a
bad
way
to
test,
whether
not
you
have
remote
connectivity,
but
when
there
is
no
BFT
protocol
involved.
There
is
nothing
for
me,
FTE,
necessarily
to
standardize
so
I
didn't
understand
the
nature
of
the
question
and
then
a
little
over
a
year
ago.
C
Somebody
may
be
aware
of
the
broadband
forum
PR
146
document,
and
this
gave
me
why
people
are
asking
about
it.
It
was
because
another
standards
organization
had
decided
that
they
were
going
to
try
to
make
use
of
a
small
piece
of
our
functionality,
but
in
a
way
that
was
not
well
specified
there,
their
document
has
errors
in
it.
This
is
an
understood
thing
and
it
is,
as
you
say,
one-sided
or
one-armed.
C
You
know
that
the
protocol
literally
is
from.
If
these
perspective
shut
off.
You
know
what
we
have
is
effectively
some
switch
that
we
turn
on.
You
know
the
echo
functioning,
regardless
of
whether
or
not
BFD
has
been
negotiated,
so
we're
sort
of
using
a
piece
of
the
VFD
machinery,
and
we
certainly
could
use
the
piece
of
a
VFD
echo
implementation
that
understands
no
interruptions
to
loop.
That
things
are
up
or
things
are
down
and
report
it
to
a
client
protocol,
so
certainly
somebody's
BFD
implementation
could
be.
C
Bbf
has
not
come
to
a
TF
I
found
out
about
this
completely
by
accident
and
as
I
mentioned,
their
document
is
not
quite
right
and
one
of
junipers
members
of
BBF
has
said
that
they
may
write
a
updated
version
of
the
document
at
a
later
point
in
time
where
this
lis
us
is
an
interesting
position
of
ITF.
Does
not
describe
this
behavior
ebf
has
some
description
of
the
behavior,
but
it's
not
correctly
described.
C
The
functionality
is
useful,
but
EFT
as
a
protocol
itself
is
not
actually
active
on
this
session,
so
to
some
extent
we're
describing
how
a
broken
BFD
could
be
used.
So
our
problem
is
IETF
is.
Do
we
wish
to
put
a
document
together
that
effectively
republishes
the
scenario
from
BB
F,
maybe
with
Corrections
and
at
the
IETF
context,.
C
Part
of
that
is
having
a
discussion
with
Martin
or
ad
to
figure
out.
If
this
fits
into
the
Charter
part
of
the
discussion
is
discussion
with
you
know
any
of
the
Hazen's
we
may
have
with
broadband
form
to
figure
out.
You
know.
Why
did
you
use
our
protocol
in
the
first
place
without
talking
to
us,
but
but
I
think
that
the
point
you're
bringing
to
the
working
group
and
thank
you
for
the
presentation
is
that
this
is
a
helpful
piece
of
functionality,
and
you
also
gave
an
example
of.
C
H
Problem
I
think
it's
a
will
be
very
useful,
because
the
currently
a
lot
of
overly
networking
is
a
deployment
that
deployed
that
not
only
within
data
centers
such
as
the
vxy
as
well.
As
you
know,
one
system
in
sd1,
especially
for
some
industry
in
tonight,
so
maybe
the
scanner
function
can
be
used
in
more
application
scenario.
So
that's.
C
C
G
C
The
sort
of
weird
observation
I've
made
as
this
has
come
up
yeah
my
job
over
the
prior
years-
is
that
they're
using
the
FDA
echo
packets
through
the
job
and
if
I,
have
to
take
a
guess
as
an
engineer,
there's
probably
some
sort
of
no
commodities
silicon
vendor
that
happens
to
have
the
FDA
code
loopback
programmed
into
their
hardware.
That
makes
this
cheap
and
easy,
and
people
are
just
using
that.
But
this
could
be
ping.
C
D
Actually,
thanks
to
bringing
this
Terra
146
attention,
I
was
not
aware
of
it
and
when
I
read
it
I
believe
they
do
use
not
only
beef.
The
echo
the
use,
a
combination
of
pole,
sequence
to
communicate,
diagonals
and,
and
actually
that's
where
I
found
mo
more
mistakes
and
error,
misconceptions
and
no
reference
to
the
final.
For
example,
they
just
say
we.
D
Is
not
accurate
terminal,
it
is
terminology,
I
can
understand
what
they
mean,
but
the
technology
as
well
so
I
think
that
again
we
have
this
week,
David
Sinha
crop.
So
if
we
want
to
communicate
something
to
be
there
that
he
can
put
on
the
liaison
head
and
we
can
use
that
and
actually
the
good
thing
is
that
PDF
member
meeting
is
one
week
from
this
week.
I
believe.
D
C
J
So
Martin
from
hobby,
so
I
think
this
idea
is
very
interesting
as
in
it's
very
useful
offer
some
scenario
in
my
personal
opinion,
I
think
there
may
be
some
protocol
work
need
to
be
defined
in
this
little
girl
because
for
the
traditional
BFD
session
we
need
to
set
to
set
it.
I
only
need
to
set
our
my
discriminators
right,
which
we
use
particle
tuner.
This
come
in
turn
off
the
remote
side,
but
for
this
one
called
one
arm
VFP.
We
need
to
suppose
so.
C
Based
on
my
understanding,
talking
to
people
who
seem
to
have
some
flavor
that's
implemented,
the
whole
issue
here
is
that
they
don't
want
to
put
any
BFD
machinery
into
the
effectively
it's
a
host
device
at
the
other
site,
like
a
media
gateway
for
cable
networks,
that
sort
of
thing
very
dumb
boxes
and
they're,
relying
on
the
packet
loop
to
simply
fulfill
the
need.
So
this
is
very
bad
from
the
working
groups
perspective,
because
we
don't
have
any
negotiation
that
can
help
the
BFD
sender
figure
out.
C
What's
no
packet
speed,
the
receiver
actually
wants
to
get
so
this.
This
is
probably
okay
for
the
people.
Who
did
this
work
because
for
their
environment
they
knew
what
speed
they're
willing
to
support
it's
either
very
slow
or
they
they
know
how
fast
they
can
safely
know.
Do
things
you're
absolutely
correct
that
if
you're
trying
to
do
this
in
a
safe
fashion,
you
would
be
using
a
full
BFD
implementation
that
it's
only
purpose
is
to
say
I'm
not
willing
to
do
fast.
They
sink
I'm
gonna,
go
into
demand
mode
immediately,
feel
free
to
use
echo.
C
J
I
think
yeah
yeah
for
that
attacked,
I
think
a
great
weights,
you
know,
need
some
particle
extinction,
because
the
local
site
and
remote
side,
but
for
the
local
process
and
based
on
current
precision
I
think
her
name
is
some
modification
to
the
current
process
into
you
know
how
to
handle
this.
You
know
have
the
same
discriminate.
No,
maybe
no.
C
E
D
H
C
I
Lewis
Chan
one
direction,
maybe
from
the
echo
sigh,
is
Marie
now
actually
do
not
be
quite
a
coup
start
to
do
anything
right.
So
therefore,
actually
for
troubleshooting
I
also
thought
some
other
statistic
collections
right.
We
may
specify
the
format
so
that
the
echo
size
can
optionally,
okay
turn
on
to
get
the
statistics
so
that
the
troubleshoot
to
look
at
what
happened
in
the
networks
and
look
how
many
sections
we
adapt
ish.
D
Actually,
I
think
that
this
exchange
brings
for
a
good
question
that
was
somewhere
in
the
back
of
my
mind.
Is
would
be
good
in
this
document,
even
when
we
write
it
that
explain
what
exactly
can
be
verified
and
monitored
using
this
technique
so
that
to
have
right
expectations
and
I
want
to
point
out
that
echo
works
on
the
over
single
hop.
You
know,
okay,
so
it
could
be
at
no
so
but
you're
still
crossing
single,
hawk
right,
yeah.
C
And
relaying
a
question
from
Robert,
Russia
and
Jabbar
was
a
spoofy
projection,
spoofing
protection
considered
in
this
Eco
mode,
and
you
know
Greg.
You
just
answered
a
portion
of
the
question,
which
is
that
it's
single
hop
only
you
know
whether
it's
a
tunnel
or
not.
But
beyond
that
this
is
just
a
echo
functionality,
and
you
know
the
remote
side
exercises
no
protocol
behaviors
at
all,
so
it
is
up
to
the
sender
to
put
something
into
the
packet
that
they
would
recognize.
C
You
know
the
BFD
58
80
spec
does
not
talk
about
that
at
all.
It's
my
impression
from
having
talked
to
other
implementers
that
sometimes
they'll
put
their
proprietary
stuff
in
there.
That
does
attempt
to
look
for
it,
they're
not
going
to
publicly
say
what
they
do.
That's
that
you
can
fire
up,
tcp
dump
and
no
look
at
it
and
you'll
probably
give
a
guess
on
it.
You
know.
Okay,
thank
you.
Thank
you.
So
I
think
the
actions
for
the
working
group
is
no
rules
continued
discussion.