►
From YouTube: IETF94-BFD-20151103-1030.webm
Description
BFD meeting session at IETF94
2015/11/03 1030
A
A
A
B
B
And
also,
please
think,
we're
shot
for
no
stepping
up
to
do
the
new
chair
work.
No,
no,
no
bows
done
a
now
great
amount
of
work
for
us
and
I.
Think
I've
Ishod
he'll
do
just
as
wonderful
of
a
job
so
document
status
as
usual.
The
wiki
is
current.
No,
so
this
is
what
the
chairs
believe
the
status
of
things
are.
One
of
the
items
of
interest
to
the
Birkin.
The
Briton
group
in
general
is
the
fact
that
we
do
have
the
FT
stuff
that
is
done
outside
of
VFD.
B
So
if
you
notice
something
that
is
not
on
that
list,
please
let
us
know
now.
Part
of
our
Charter
is
to
sort
of
help.
Other
groups
review
the
use
of
DFT
in
their
mechanisms.
Other
status
is
that
the
50
80-84
considerations
document
is
in
the
FC,
editor
queue
and
should
pop
out
sometime
soon.
Thank
you.
Everyone
for
working
on
that
one.
The
spfd
documents
are
waiting
for
editorial
work
from
the
area
direct
that
we've
received
from
the
area
director
nobo,
unfortunately,
was
unable
to
know,
take
care
of
the
outstanding
items.
B
So
one
of
the
bits
of
feedback
that
Alvaro
had
given
us
as
part
of
the
review
of
the
document
set
is
you
know
we
have
a
use
case
document
know
and
as
I
HAF
process
to
that
point,
head
largely
suggested
we
did
the
use
case
document
as
a
internet-draft,
sometimes
use
case
documents
etc
get
published.
Sometimes
they
don't.
B
B
B
So
basically,
two
people
have
an
opinion
one
way
or
the
other
I
think.
My
in
my
personal
inclination
would
be
that
you
know
extend
the
author's
one
last
opportunity
to
see.
Do
you
actually
want
to
publish
this,
but
the
sense
of
the
working
group,
I
think
is,
is
that
this
is
not
critical
work
that
actually
should
be
enshrined
in
an
RFC,
so
we'll
offer
them
one
more
opportunity
for
that
and
if
they
decide
not
to
take
us
up
on
that
opportunity,
we
will
allow
the
document
elapsed.
B
B
B
It
might
mean
that
you
don't
think
we
should
actually
progress
them
or
it
means
that
you
simply
don't
care.
We
do
actually
require
consensus
from
the
working
group
to
move
these
things
forward.
You
know
for
a
mid.
I
can
actually
believe
that
the
majority
of
this
room
does
not
care.
Now.
Libs
are
sort
of
on
the
way
out
with
an
ietf.
You
know
we
make
do
this
one
to
completion.
B
Justin
Thea
is
a
way
of
closing
off
some
remaining
work,
but
I
find
it
a
little
bit
difficult
to
believe
that
there
is
no
interest
in
the
point
in
the
room
here
so
again
to
get
a
sense
of
the
room.
Have
you
read
at
some
point
the
BFD
multi-point
document
yeah
and
we
actually
have
to
know
for
the
people
that
are
active
in
the
group
done
it
so
of
you
who
have
read
this
document.
Do
you
think
it's
ready
to
progress
and,
let's
all
that
about
roughly
about
two-thirds
in
the
same
people?
B
So
my
request
to
you
is:
if
you've
read
it
and
think
it's
ready
to
move
forward,
please
just
say
so
on
the
mailing
list.
You
know,
let
us
get
a
sense
of
that,
so
that
we
can
say
that
you
know
we
have
consensus
here.
We
have
also
started
last
call
along
with
trill
since
trills
one
of
the
first
users
that
are
publicly
including
that
as
a
normative
reference,
the.
C
D
B
Really,
no
sort
of
the
same
question:
no
they're
really
tightly
bound
items
together,
but
we
can
progress
the
first
one
independent
of
the
second
one,
just
simply
cuz
would
have
nor
no
down
refs
to
worry
about.
In
that
case,
what
we
didn't
see
anybody
showing
hand
so
again,
I
think
the
sense
is
that
we
probably
do
when
to
continue
to
progress.
These
things
together
and
similar
for
the
VFD
mpls
nib
I'm,
going
to
ask
and
not
have
huge
hopes.
Has
anybody
here
in
the
room
read
this
document.
B
B
So
in
terms
of
interesting
work
happening
elsewhere,
an
ITF
for
BFD
in
the
routing
working
group.
We
do
actually
have
some
efforts
to
use
the
fda
for
VAR
ki,
know
the
sort
of
motivating
new
data.
At
no
case
these
days
is
some
extent.
Data
centers,
you
know,
BRP
is
becoming
very
popular,
is
a
host
level
failover
mechanism,
but
people's
vrp
implementations
don't
have
timers
that
keep
up,
whereas
there
BFD
implementations
can
you're
encouraged
to
take
a
look
at
this
work
inside
the
party
gwg
and
supply
no
feedback
to
the
authors.
E
So
I'm
presenting
on
may
have
offers-
and
this
is
update
to
the
document
we
present
in
Prague-
what
dresses
in
it's
a
use
cases
that
OEM
between
virtual
machines
a
photo
alkalization
and
serviceability.
Currently
we
are
considering
a
use
case
for
point-to-point,
BFD
and
point-to-multipoint.
Bfd
is
further
study.
We
had
a
pretty
extensive
discussion
among
offers
because
currently
in
the
excellent
does
not
have
explicit
case
for
multicast,
but
at
the
same
time,
so
it
does
mention
that
the
excellent
will
have
bomb
traffic
and
bump
traffic
implicitly
assumes
the
multicast.
E
So
this
is
a
just
genetics
of
the
deployment
scenario
when
you
have
their
three
underlay
and
hypervisors
and
their
leave.
This
session
is
between
the
hyper
viruses,
thanks
and
as
in
the
excellent
you
have
inner
mac,
header
and
inner
IP
header.
So
our
outer
IP
header
will
be
terminated,
will
be
D
capsulated
at
V
tab
and.
E
Here's
a
listing
of
what
information
is
needed.
We
are
not
yet
discussed
whether
there
will
be
a
well-known
mac
and
how
it
will
be
allocated
could
be
probably
allocated
from
a
anna
managed
range
of
multicast
MAC
addresses.
But
on
unrelated
discussion
we
had
a
concern
expressed
of
use
of
multicast
MAC
addresses
in
the
explain
environment
in
data
center,
and
that
is
not
only
the
case
here,
but
a
case
for
vr
p
and
I'm
pointing
to
multiple
in
VFD.
E
The
multiplexing
will
be
done
using
a
source
IP
address
for
the
bootstrap
and
from
then
on.
It
will
be
done
based
on
your
discriminator
in
case
of
a
point-to-multipoint
VD,
then
their
update
to
the
demultiplexing
on
a
point-to-multipoint
give
the
session,
as
per
current
proposal,
will
be
applicable
and
the
TTL
will
be
set
to
one
next
slide.
E
E
C
E
E
B
E
I
mentioned
it
briefly,
I
think
it's
a
generic
problem
for
you,
the
multicast
addresses
in
a
DC
environment,
and
so
yes,
we
discussed
that
applicability
of
point-to-point
BFD
to
vr
p,
+
vr
p
itself
uses
a
multicast
well-known
mac
address,
so
it
has
this
problem
inherently.
So
I
think
that
it's
a
generic
problem
I
agree,
and
we
just
need
to
find
the
right
group
to
discuss
it
and.
B
Certainly
one
of
the
problems
that
the
multicast
will
cause
in
this
context,
no,
like
VRP,
is
mostly
a
slow
protocol.
You
don't
tend
to
run
it
with
very,
very
fast
timers,
even
though
you
can,
whereas
with
VFD
you
tend
to,
and
we
sort
of
have
the
other
impact
that
I
understand.
The
main
use
case
of
this
is
no
sort
of
coming
from
the
outside
in
the
world.
From
you
know
the
devices
basically
many
sessions
potentially
crossing
the
same
pipe.
Yes,
actually.
G
E
E
E
C
E
C
C
E
E
E
You
can
do
to
have
multiple
be
of
these
sessions,
be
the
same
target
faq
and
then
you
can
probably
use
different
source
IP
port
numbers
to
try
to
address
different
ecmp
pass,
but
there
is
no
guarantee
what
your
monitoring
in
which
session
monitor
squat
so
easy
in
peace.
Yes,
it's
very
tricky
thinking,
but
as
innocents
a
general
case
home.
This
is
so
somehow,
but
if
you
have
any
suggestions
or
just
want
to
discuss
it
with
us,
you're
welcome
I
appreciate
it.
Thank
you.
I'm.
F
E
That
is
I
think
that
if
we
have
OEM
our
protocol
type
and
then
we
can
use
ACH
encapsulation,
so
there
will
be
not
subject
to
hashing
based
on
BF
d,
IP,
UDP
header.
So
then
we'll
follow
it
and
at
least
we'll
follow
the
particular
the
same
tunnel
but
I
agree
that
be,
if
deed
is
more
of
continuity
check,
rather
than
connectivity,
verification.
A
B
Collect
a
separate
so
my
sense
you're
looking
for
adoption
in
NV,
0
3,
and
you
know
you
obviously
have
a
good
set
of
probably
the
same
interested
parties
all
show
up
the
same
there.
No,
my
recommendation
is:
go
ahead,
work
with
these
people
and
don't
see
what
we
can
do.
It
actually
refine
it,
especially
in
terms
of
the
in-band
versus
know
the
encapsulated
versus
the
raw
format
since
I
suspect.
That's
prolly
gonna
be
your
biggest
issue,
a
siphon,
multicast
yeah,
we're.
C
G
Right
by
everyone,
I'm
Ashish,
Mishra
I'm,
presenting
on
behalf
of
Mahesh
for
optimization
of
BFD
authentication.
We
had
our
first
presentation
a
couple
of
meetings
ago.
There
was
some
feedback
that
came
through
it.
I'll
go
over
a
quick
overview
of
what
the
idea
was
first
and
then
the
couple
of
changes
we've
made
to
the
draft
the
problem
would
be
a
bit
authentication
for
most
implementations
is
that
it's
very
computationally
intensive
having
to
check
the
authentication
on
each
and
every
pft
frame
it
limits
the
scale.
Also,
the
crypto
is
available
in
58.
G
C
G
G
Now
for
the
changes
from
the
first
version.
There
was
a
comment
that
we
had
not
properly
mapped
out
exactly
what
state
changes
and
what
transitions
are
going
to
be
authenticated.
So
here's
a
cool
little
map
that
shows
all
transitions
that
are
going
to
use,
authentication
the
ones
that
not
going
to
use
authentication
will
use
a
null
authentication
tlv
and
that's
what
we
are
proposing.
We
can
change
it
a
little
bit
if
necessary.
G
The
novel
authentication
tlv
for
people
who
are
familiar
with
the
stability
draft
that
we
had
proposed
has
no
authentication,
but
has
a
sequence
number
and
a
timestamp.
The
timestamp
here
is
irrelevant,
but
the
sequence
number
is
something
that
we
are
going
to
need
to
maintain
proper
authentication
across
the
báb
state
transitions
that
we
are
authenticating.
Also,
if
you
notice
the
up
to
up
transition
is
going
to
use
analog
communication
generally,
but
we
must
allow
configuration
to
periodically
authenticate
the
CC
apps
to
completely
prevent
man-in-the-middle
attacks
over
a
long
period
of
time.
G
G
B
B
I
suspect
that
up
Dale
up
they
have
a
sub
state
hiding
in
there
in
terms
of
the
periodic
replay
you
have
it
in
there
anyway,
but
just
matter
of
actually
documenting
it
is
sometimes,
if
you
know
sometimes
it
should
be
not
null
vm
that
have
you
sought
out
any
review
from
the
security
group.
Yet
this
point
not.
B
F
F
G
C
B
So,
yes,
so
we'll
take
the
adoption
call
to
the
mailing
list.
One
final
question
to
the
groom:
how
many
operators
are
actually
present
in
the
room
right
now
you
operate
an
actual
Network,
see
least
three
of
you
three,
how
many
of
you
actually
deploy
some
sort
of
BFE
authentication
at
this
point
in
time,
I
see
two,
that's
actually
two
more
of
those
expecting
reason.
The
motivation
for
that
question
is
we
were
doing
the
original
security
work
moving
towards
RFC
a
few
years
ago.
B
It
was
sort
of
shown
that
authentication
was
not
a
feature
that
people
had
been
interested
in.
So
this
is
this
is
actual
change.
Now
we
have
people
that
are
now
using
authentication.
Second
thing
of
interest
in
this,
maybe
I
should
find
the
link
and
set
it
off
to
the
mailing
list.
There
was
a
nice
article
from
the
crypto
research
group
within
the
IETF,
showing
some
sort
of
disturbing
statistics
about.
How
shall
one
is
you
know?
B
Obviously,
the
biggest
problem
had
then
that
we
can't
do
crypto
at
line
rate
for
barely
with
no
shell.
One
no
shot
to
was
probably
not
reasonable
in
the
current
form,
and
this
proposal
is
really
our
only
step
forward
to
be
able
to
allow
this
the
deployable
feature.
So
my
request
to
the
working
group
is,
you
know:
please
lend
your
eyes
to
reviewing
this
and,
as
I
mentioned,
both
will
take
the
poll
to
the
working
list.
Alright,.
H
C
H
Hi
good
morning
my
name
is
Rashad
I'm
going
to
be
presenting
the
BFD
yang
model
okay.
So
this
is
a
bit
of
history
of
recent
history.
On
the
BFD
yang
model,
it
was
adopted
as
the
work
group
dark
after
Prague,
so
the
rav4
of
the
individual
contribution
document
became
workgroup
doc.
The
current
document
is
the
RF
centric.
After
Dallas
we
work
on
the
wave
of
augmenting
routing
protocol.
Rounding
instances
can
all
that
and
the
current
the
current
doc
has
a
single
hub
support,
multihop
support,
key
ldpe
and
lag
currently
in
that
doc.
H
H
H
So
if
you
have
any
suggestions
on
this
and
seamless
BFD
I
think
initially,
we
had
left
seamless,
BFD
out
because
it's
not
an
RFC
yet,
but
it's
getting
closer,
so
we
might
decide
to
tackle
that
next
slide.
Okay,
so
here
are
some
of
the
issues
we
think
exists
in
in
the
current
draft.
So
the
first
point
is
that
Bing
vrf
centric
is
great.
If
all
your
services
are
routing
base,
but
in
the
case
of
mpls-tp
you
you
could
have
a
layer
to
lag.
There's
absolutely
I
mean
there's
no
vrf.
H
The
second
issue,
which
is
probably
one
of
the
biggest
issues,
is
we've
been
going
back
and
forth
between
the
we
configure
BFD
intervals
in
the
four
single
hub
in
the
routing
application.
Do
we
configure
it
centralized
in
VFD
there's
various
implementations
out
there,
which
do
one
the
other
or
kind
of
a
hybrid
model
where
some
stuff
is
in
the
routing
application,
and
some
stuff
is
actually
in
VFD
the
problem
with
what
we
have
right
now.
H
Is
you
have
the
basic
parameters
being
the
intervals
and
the
multiplier
which
are
exported
via
a
grouping
to
the
to
the
routing
applications
which,
for
example,
west
PF
okay
uses,
but
the
authentication
parameters
which
you
know
are
really
BFD
specific?
They
end
up
in
the
bfg
model,
so
the
config
is
split
between
two
different
places
and
the
last
point
here
is
well
what
we
have
for
operational
model
for
mpls
te
is
/
tunnel
and
it
should
really
be
pearl
SP.
When
you
have
multiple
at
ESPYs
in
a
tunnel
you
could
have.
H
You
know
different
states
so
are
having
we've
had
some
discussions
with
the
MPLS
group
and
we're
supposed
to
have
some
more
this
week
next
slide.
So
here
are
some
solutions.
The
design
team
has
been
has
been
looking
into
so
the
first
one
regarding
the
for
the
technologies
which
are
not
ip-based
is
instead
of
augmenting
the
routing
protocol.
H
The
one
question
there
is
one
discussion
we've
been
having
is
certain
implementations.
Today
they
have
BFD
configuration
under
the
routing
protocol.
Let's
say
Wesley
f
kin
is
is
and
as
opposed
to
sharing
the
same
wfd
session.
They
have
the
ability
to
have
different
BFD
session
for
those
different
routing
applications.
So
to
support
that
we
were
looking
at
ways
to
support
that
in
the
base
model,
but
we
haven't
found
a
way
to
do
that
which
would
work
for
implementations,
which
don't
support
that.
H
So
our
current
proposal
is
with
the
centralized
BFD
configuration
is
for
implementations
which
have
that
special
behavior.
They
would
need
to
augment
the
base
model,
but
I
mean
this
is
something
which
is
not
closed.
Yet
it's
discussions
which
are
going
and
regarding
the
last
last
problem,
so
you
know
we
discuss
importing
some
LSP
stuff
from
the
T
model.
The
T
team
has
asked
us
to
look
into
augmenting
the
MPLS
LSP
operational
model,
so
discussions
ongoing
on
this
also,
but
those
are
the
three
main
points
which
we
have
to
solve
in
the
in
the
immediate
future.
H
Next
slide,
please!
So
assuming
we
do
the
changes
I
just
mentioned
so
here
it's
the
full
BFD
configuration.
This
is
for
single
hop
where
you
have
you
know,
interface,
destination,
address,
etc,
etc.
You
see
the
list
is
keyed
by
interface
and
destination
address
and
everything
is
inside
BFD,
nothing
in
the
application,
as
we
have,
as
we
have
in
the
currently
published
draft.
H
Next
slide,
please.
This
is
for
multi-hop
so
previously,
when
we
rode
menteng
the
routing
protocol,
so
we
didn't
need
to
put
a
vrf
in
there
because
it
was
part
of
the
context.
So
if
you
can
see
the
cut
the
line
with
vrf
there,
that's
something
which
we've
added,
which
would
be
added
if
we
stopped
up
mending
the
routing
protocol.
H
H
Looks
like
I've
got
my
answer:
okay,
so
last
thing
regarding
lime,
so
we've
been
having
lots
of
ongoing
discussions.
Also
with
the
lime
team.
Yesterday,
I
did
presentation
in
the
lime
workgroup
and
what
lime
is
kind
of
mine
dating
us
right
now
is
to
use
their
generic
yang
model
for
all
technologies,
all
over
em
tools
and
we're
finding
it
hard
to
make
a
CFM
like
model
fit
into
what
we
need
for
PFD.
D
C
D
E
H
E
Us
it
is,
it
is,
presumably
goes
of
a
different
path
of
within
the
same
LSP.
So
if
you
have
I
p.m.
pls
and
you
have
ecmp,
then
you
can
have
multiple
paths
for
the
same
LSP
so
that
you
can
play
the
trick
with
your
source
port
number,
which
you
control
at
their
ingress,
so
trying
to
hit
there
in
a
CMP.
If
you
know
it,
you
have
five
available
paths.
You
can
allocate
five
different
source
port
numbers,
hopefully
that
your
IP
UDP
encapsulation
of
VFD
will
force
it
over
the
different
paths.
D
So
I
think
my
my
question
is:
is
simply
in
the
context,
if
you,
if
you
look
at
bft
as
a
service
and
you
have
multiple
clients
and
it
turns
out,
multiple
clients
are
asking
for
the
same
service.
Why
would
you
run?
Why
would
you
certainly
you
you
know
you
might
have
to
look
at
the
parameters
that
have
been
requested
and
you
know
you
know,
work
out
the
lowest
common
denominator
so
to
speak,
but
I
don't
see
why
running
two
sessions,
so
thanks
innocence,
the.
H
Only
thing
I
can
think
of
is
if
one
application,
let's
see
if
you
say
you
know,
T,
for
example,
you're
doing
fast,
we're
out
and
you're
saying:
I
need
15
milliseconds
and
you
know
I
GP
say
well,
you
know
if
you
got
a
really
small
failure
like
you
know,
which
lasts
less
than
500
milliseconds,
maybe
I
don't
care,
maybe
I
don't
want
to
go
and
do
my
fast
convergence
and,
oh
that's
the
only
thing
I
can
think
of
but
I'm
speculating
here.
So.
B
Jeff
has
I
can
jump
into
the
mic
line.
One
application,
you
know
which
you
sort
of
hinted
at
is
that
if
you
have
a
application
that
needs
a
really
tight
granularity,
fast
timers
and
another
application
that
is
lazier,
it
needs
less
granular
timers.
You
have
an
interesting
design
question
in
front
of
you,
whether
you
choose
the
more
aggressive
or
the
less
aggressive
timers
as
the
no
comment
session.
If
you
reduce
it
to
a
single
session,
if
you
do
the
less
aggressive
one,
you
are
doing
a
disservice
to
the
one
that
needs
the
tighter
timers.
B
So,
typically,
what
most
implementations
do
is
they
choose
the
most
aggressive
timer
set
and
the
less
aggressive
is
along
for
the
ride.
There's
a
problem
with
this,
though,
when
the
more
aggressive
session
goes
down
because
of
no
transient
loss
of
connectivity,
you
want
the
application
that
needs
that
to
be
able
to
take
down
the
session
because
it's
receiving
the
edge
trigger
of
know
the
down
event
is
happening,
but
the
less
aggressive
application
is
also
getting
it
down.
Despite
the
fact
that,
had
it
been
on
a
less
aggressive
timer
set,
it
could
have
lived
with
it.
B
Theoretically,
we
could
do
some
level
of
poll
timer
to
do
this,
but
the
pole
itself
is
so
long
that
it
might
actually
cause
issues.
So
your
choice
really
is
live
with
a
single
one,
knowing
that
you'll
take
the
less
aggressive
one
with
it
or
potentially
run
more
than
one,
where
possible,
which
has
interesting
bootstrapping
issues
for
single
single
hop
single
session,
because
you're
using
the
same
end,
points
to
do
your
your
session
demultiplexing.
D
H
Sorry,
let
me
just
answer
it
less.
First,
so
I
mean
if
you
have
it's
not
a
so.
The
question
back
is
in
this
case:
it's
not
a.
What
we
discuss
in
the
design
team
is
not
a
common
implementation.
It's
not
a
common
behavior.
We
know
about
me
one
implementation.
So
that's
why
I
wondering
if
you
know
that's
out
there,
these
the
BFD
rfcs
does
not
prevent
you
from
doing
that.
E
B
So
trying
to
take
notes
at
the
same
time,
so
the
I
agree
with
you
know
we
can
basically
choose
to
do
one
behavior
or
the
other,
but
we
do
have
the
modeling
issue
in
terms
up
for
going
to
say
this
is
a
supportable
type
thing.
What
do
we
do?
I'm
going
to
offer
an
example
out
of
EGP
data
modeling
from
SMP.
B
There
were
cases
of
you
know
multiple
beach
be
sessions
between
two
endpoints
as
being
in
like
one
or
two
implementations
across
the
entirety
of
the
internet,
but
it
massively
made
a
mess
out
of
the
session
table
for
bgp.
The
design
choice
was
not
to
support
it.
Now,
you're
still
able
to
cover
portions
of
things,
but
you
didn't
get
a
hundred
percent
coverage,
so
you
do
have
a
choice
in
front
of
you.
B
If
you
can
figure
out
how
to
model
it,
it's
certainly
a
nice
to
have,
but
if
it
completely
makes
a
mess
of
your
key
structure,
it's
probably
not
worth
supporting
as
a
primary
use
case
and
unlike
SNMP,
as
long
as
we're
doing
a
good
job
about
our
groupings.
In
terms
of
the
contents
of
things,
it's
perfectly
acceptable
to
have
more
than
one
container
set.
Modeling
things
the
one
for
the
common
case,
one
for
the
extended
case
with
additional
a
disease.
B
One
of
the
interesting
implications
about
lime,
aside
from
the
keying
stuff,
know
how
to
fit
this
into
the
CFM
style
model
is
that
lime
does
imply
common
RPC
type
elements,
so
it
is
example,
ping
and
traceroute
ER
effectively
common
elements
in
line
with
a
sink
PFD.
We
don't
really
have
either
of
those
things,
but
when
we
start
considering
things
in
the
context
of
spfd,
we
have
basically
introduced
ping.
B
So
it
comment
to
the
design
team
is
no
take
a
look
at
you
know,
maybe
the
pink
case
for
spfd
and
see
if
it
makes
sense
to
include
a
RPC
that
is
specific
to
support
that
I.
Think
that
actually
supports
the
line
use
case.
The
rest
of
it
is
obviously
a
lot
of
negotiation
about
what
sort
of
keying
stuff
that
line
needs
out
of
the
the
design
team.
I.
Think
that's
going
to
be
an
ongoing
thing.
B
C
Ice
lol
is
an
mpls
working
group
share.
The
question
is
a
little
bit
tricky
to
answer
and
we
are
not
doing
anything.
A
coordinated
work
group
chat
at
the
moment,
but
I
know
that
at
least
the
ocean
I
are
looking
at
the
Edit
individually.
So
if
this
is
a
request
that
we
should
do
something
as
working
group
shares
there,
we
certainly
willing
to
do
sir.
B
B
Okay,
that's
why
I
thought
it?
No
to
the
best
of
my
knowledge
having
pulled
people
before
nobody
currently
supports
it's
sort
of
one
of
the
last
orphan
features
in
the
base
RFC,
and
this
actually
brings
me
to
know
what
was
going
to
be
an
optional
topic.
No,
we
have
five
minutes
left
I'm,
just
going
to
mention
it.
Bfd
has
been
pretty
darn
stable
for
the
last
know.
Several
years,
no
demand
mode
really
is
the
only
feature
that
is
not
pervasively
supported.
B
We
now
have
support
for
the
multi-point,
which
was
referenced
in
the
original
document,
and
it's
know
at
this
point
in
the
publication
stream.
This
means
that
we
are
capable
of
looking
at
taking
BFD
to
full
internet
standard.
If
we
actually
desire
to
do
this.
The
work
that
is
involved
with
taking
something
to
full
standard
is
basically
an
audit
of
all
of
the
specifications
in
these
set
that
we
want
to
submit,
which
would
probably
be
the
core
set
of
58
now
80
and
up
to
58
85.
B
The
50
80
before
bisque
document
basically
helps
take
care
of
some
of
the
things
we
would
have
done
there
anyway,
and
it's
basically
about
taking
care
of
any
errata,
and
these
features
that
we
don't
support
doing
some
implementation
reports,
making
sure
that
we
have
stuff.
I
think
PFD
is
mature
enough,
that
we
could
probably
do
this,
but
there
is
work
involved
here.
No,
it's
going
to
require
people
that
are
willing
to
do
some
document,
auditing,
no
type
activities.
B
B
And
I
suspect
that
no
there's
baby
this
would
be
interesting,
but
no,
don't
necessarily
want
to
work
at
it.
So
I'll
take
the
question
to
the
mailing
list,
but
no,
please
be
thinking
about
this
yeah.
We
were
right,
a
point
where
we
can
go
across
the
little
boundary
in
the
standards
process.
It
does
absolutely
nothing
for
us
besides
I'll,
create
a
little
to
work,
but
it
is
no.
There
are
not
a
huge
amount
of
protocols
that
have
hit
full
standards
and
I
think
it
would
be
nice
to
actually
go
there.