►
From YouTube: IETF104-BFD-20190327-0900
Description
BFD meeting session at IETF104
2019/03/27 0900
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
B
D
A
A
B
E
E
F
E
B
A
D
E
E
A
D
B
Good
morning,
let's
get
started,
this
is
BFD
for
ITF
104.
As
usual.
Here's
the
note!
Well,
you
are
expected
to
have
read
this
at
some
point.
You
are
bound
by
it
anyway,
so
we
have
a
relatively
a
short
number
of
items
on
the
agenda.
Some
of
these
things
may
go
slightly
faster
than
the
schedule,
so
working
group
status.
B
B
H
B
The
t's
yang
battle,
if
you
happen
to
work
in
either
these
working
groups
MPLS
forties,
no,
please
feel
free
to
no
try
to
help
them
get
that
document
set
done
and
they'll
help.
Our
documents
move
along
to
help
the
VFD
4vx
LAN
is
an
AP
evaluation
state,
so
this
means
that
Martin
will
hopefully
be
doing
his
job
and
moving
along
sometime
soon,
so
the
attend
occation
drafts
are
an
interesting
state.
B
B
One
of
the
interesting
pieces
from
that
is
part
of
last
call.
We
received
very
minimal
comments
on
them.
The
I
would
really
need
a
little
bit
extra
review
from
the
reporting
group
for
the
working
group
to
render
move
it
forward.
One
of
the
comments
that
did
come
up
at
the
last
minute
was
that
you
know
there
is
IPR
to
disclose,
but
has
she
actually
pointed
it
out
very
early
into
the
last
call
process
and
the
Siena
lawyers
have
moved
a
little
late
on
that,
so
the
IPR
didn't
come
out
ahead
of
time.
B
At
this
point,
the
IPR
that
is
listed
on
the
drafts
basically
shows
that
it's
using
these
IETF
required
reasonable
and
non-discriminatory
license
and,
however,
it
does
not
have
any
language
on
there
that
covers
the
licensing
fees.
This
is
occasionally
been
a
concern
for
the
working
group,
especially
since
the
FD
technologies
are
sort
of
plumbing
and
tend
to
get
implemented
in
things
like
open
source
software,
so
we're
sort
of
stuck
in
a.
How
do
we
proceed
out
of
this
minimally,
though
the
group
can
move
the
documents,
for
it
is
one
possible
option.
J
What
I
wanted
to.
Oh,
the
other
thing.
I
just
wanted
to
point
out
is
I'm,
of
course,
no
longer
with
the
company
CNS,
so
my
ability
to
influence
state
lawyers
is
limited
to
my
access
to
the
sienna,
as
as
the
people
that
I
worked
with
and
I
just
wanted
to
kind
of
find
out
that
I
did
approach
them
to
see
if
they
would
be
willing
to
kind
of
relax.
The
terms
on
the
idea,
the
the
general
tone
of
the
response
that
I
got
was
that
a
according
to
them.
J
The
IPR
terms
are
pretty
much
in
the
range
of
other
IPS
that
have
been
declared
against
BFT,
and
in
that
sense
it's
not
too
out
of
the
ballpark
in
terms
of
it.
Now,
specifically
in
terms
of
the
license
in
a
it
I'll
read
it
out.
The
email
said
that
first
of
our
IPR
statements
do
not
require
or
imply
that
a
licensed
Buick
fee
is
due.
It
specifically
states
that
any
license
should
be
sought,
maybe
with
or
without
a
fee.
I
So
if
you
we
can
talk
about,
I
can
really
go
into
which
whirling,
what
type
of
wording
is
more
acceptable
at
ITF
and
it's
called
as
covenant
and
if
they
agree
to
that,
I
think
that
would
resolve
this
issue
completely.
So
what
they
are
saying:
oh
yeah.
Well,
it's
only
possibility
it's
understood,
but
it's
still
possibility.
I
So
the
other
version
is
very
clear
and
that
is
what
being
practiced
by
most
companies
and
I
have
to
say
that
some
companies
do
listen
to
input
from
ITF
people
who
work
at
ITF
and
they
understand
and
they
follow
on
the
advice.
So
some
people,
don't
some
companies,
don't
and
that's
unfortunate
fact.
So
beyond
our
control.
B
So
possible
steps
word
so
Greg.
If
you
have
specific
language
that
you
can
share
to
the
mailing
list,
I
think
one
more
step
we'll
try
before
we
look
for
ways
to
work
around
the
IPR
or
just
lead
to
the
call
that
the
working
group
actually
wants
to
proceed
with
the
Icaria
stands
is
to
have
the
chairs
contact,
Siena
lawyers
and
share
our
concerns
with
them
and
see
based
on
those
concerns,
whether
they're
really
good
just
things.
B
New
working
group
documents
since
ITF
o3
metal,
3,
we've
had
50
large
packets,
get
adopted.
New
versions
of
that
has
been
posted
and
will
be
covered
today.
The
DFT
unsolicited
draft
also
got
adopted,
and
it's
gotten
some
changes
as
well
and
we'll
be
covering
the
changes
for
today
as
well,
so
50,
84
biz.
The
consensus
of
the
working
group
is
that
we
do
need
to
actually
do
this.
The
amount
of
work
on
it
is
relatively
small.
B
You
know
there's
just
enough
things
that
are
there
necessary
to
no
closed
off
some
technical
issues
and
it's
like
the
existing
implementers
understand
how
to
appropriately
do
stuff
just
matter
of
actually
writing
it
down.
This
work
had
originally
been
deferred.
Just
simply
because
we
were
trying
to
finish
a
bunch
of
documents
up
and
whether
to
keep
the
working
group
focused.
You
may
be
looking
at
picking
this
up
this
part
of
the
next
cycle.
I
B
Another
piece
of
stuff
from
the
mailing
list
was
a
gregster
after
a
Smurfs
KPFT
mpls
demand.
There
is
a
lot
of
discussion
on
the
mailing
list.
We
had
done
a
working
group.
Adoption
poll,
someone
in
fairness,
Rashad
and
I
as
chairs-
did
not
do
our
job
and
do
our
initial
review
before
we
actually
did
the
adoption
call.
B
The
discussion
that
we
largely
converged
on
in
the
mailing
list
is
roughly
two
things.
The
first
one
is
that
the
demand
mode
procedures
largely
are
clear
in
the
base.
Vfd
RFC,
the
thing
that
is
potentially
a
little
Nicholas
is
whether
the
diag
code
would
be
considered
parameter,
change,
know
for
purposes
of
poll
sequence.
In
terms
of
logically,
how
BFD
has
to
behave.
That's
exactly
what
we're
looking
at.
We've
actually
asked:
Dave
Katz
and
Dave
Ward.
B
B
Have
you
ever
do
it
as
a
58
80
that
will
get
picked
up
the
remaining
item
in
there
from
your
draft
is
best
to
be
understood.
Reading
through
it,
and
the
list
discussion
is
the
upstream
in
this
case
is
permitted
aside
of
diagonal
a
diet
code
that
causes
the
downstream
to
take
an
action
we
do
have
already
in
the
base.
58
80
the
cat,
David
Circuit
case.
That
is
a
place
where
the
return
code
from
upstream
can
cause
the
downstream
to
take
action.
So
at
least
procedure.
B
Why
is
we
have
a
direct
analogy
to
what's
going
on?
What
I
think
is?
Perhaps
you
know
the
single
lingering
detail
out
of
the
draft
is
who
originally
published
is
a
very
clear
procedure
for
the
specific
case
of
now.
If
you
detect
something
upstream
set
it
to
this
exact
diet
code,
the
downstream
should
then
take
a
specific
action
on
it.
So
the
interesting
headache
we
have
here
is
that,
in
terms
of
clarifications,
we
have
exactly
one
very
small
piece
of
procedure.
That
probably
is
about
a
paragraphs
worth
of
note.
B
That
is
something
that
we
could
continue
to
do.
A
draft
for
it's
also
small
enough
and
close
enough
to
the
analogous
case
that
potentially
another
errata
could
also
be
no
coverage
of
that
this
side.
Now.
This
is
certainly
open
for
discussion
and
I
think
that
not
only
in
terms
of
VFD
working
group
and
know
Gregg's
input.
This
may
be
something
that
takes
specifically
as
a
sub
work
item.
Just
for
clarification
and
opinion
specifically
to
the
mpls
group
doesn't
apply
to
yeah.
I
I
Yes,
but
in
my
personal
opinion,
some
errata
that
I
submitted
I
was
told.
Oh
well,
this
this
clarifies
behavior.
So
this
is
not
errata
material.
If
you
want
to
write
another
draft
again,
probably
we
all
have
different
experiences
with
how
errata
being
applied,
accepted
and
treated.
So
it's
not
immediate,
but
yeah.
So
I
still
think
that
the
process
described
in
this
document
is
C
sufficiently
different
from
what
can
be
drawn
from
pieces
are
58
80,
so
there
is
value
in
working
with
it
and
I
asked
working
group
to
consider
adopting
it.
K
It's
been
the
Greg,
Jeff
and
Rashad
show
and
we'd
like
to
hear,
and
sometimes
you
know,
Greg
also
has
asked
if
our
opinion,
whereas
chairs
or
as
contributors
and
you
know
it's-
it's
I've
tried
to
stay
in
this
as
a
contributor
and
not
as
a
chair.
But
it's
be
it'd,
be
good.
If
we
hear
from
other
people,
one
difficulty
also
I
realize
is
as
far
as
I
know,
and
please
correct
me
if
I'm
wrong,
there's
none
or
very
few
implementations
of
demand
mode
out
there
or
when
I
was
actively
developing
in
DFT.
There
was
none.
I
B
Where
I
think
we're
at
and
and
and
these
points
try
to
drum
up
a
little
bit
more
readership
on
the
mailing
list,
you
know
it's
get
some
additional
viewpoints
as
to
whether
people
came
to
the
same
conclusion
as
we
did
makes
you
happy.
We
can
ask,
is
G
no
in
terms
of
clarification
of
whether
they
think
errata
is
appropriate
and
I.
Think
it's
the
chairs
opinions
for
the
parameter
change
piece.
B
B
A
B
So,
as
I
mentioned,
Albert
could
not
be
here
at
the
last
second,
so
he
asked
me
to
present
his
slides
for
him,
so
the
draft
got
adopted
and
did
get
a
couple
of
minor
changes
as
part
of
the
adoption.
Just
to
reiterate
the
problem
statement,
especially
for
when
circuits
often
due
to
issues
that
you
know
the
provisioning
side
of
things,
large
packets
of
some
form
are
not
able
to
make
it
across
some
subset
of
links.
B
They
actually
tell
you
that
this
condition
is
happening
in
some
cases,
especially
for
network
services
that
provided
over
routed
infrastructure.
Now
you
may
go
from
having
a
path:
that's
completely
clean
for
a
specific
m2u
to
one
that
stops
being
clean,
and
so
this
leads
to
a
huge
amount
of
troubleshooting,
and
you
know
sometimes,
applications
just
are
failing
in
very
random.
Fashions
next
slide,
please.
B
So.
The
the
proposal
here
is
really
leveraging
a
what
the
authors
of
BFD
left
is
an
intentional
ambiguity,
respect
you
know
the
VFD
packet
headers
cover
the
size
of
the
DFT
packet.
It
doesn't
pay
any
attention
to
the
encapsulating
protocol
at
all.
So
one
option
that
we
have,
especially
with
no
example
UDP
encapsulation
for
58
82,
is
that
we
just
simply
stick
some
know
a
padding
at
the
end
of
the
packet
and.
B
The
example
here
is,
if
you
look
at
the
bottom,
though,
the
internet
core
may
have
the
standard,
1500,
no
style,
Ethernet
max
payload,
the
padding
size
gets
adjusted
to
basically
cover
the
contents,
the
DFT
packet.
Obviously,
if
you're
doing
things
like
the
FBI
event,
ocation
you'll
need
to
change
that
value
as
well.
B
B
More
importantly,
this
is
one
of
the
things
that
we
have
to
talk
about
from
concerns
on
the
mailing
list.
There's
no
need
for
the
Pettitte
size
to
be
exactly
the
link
m
to
you.
So
example:
jumbo
frame
9k
packets
are
very
common
and
make
people's
cores
know
this.
This
is
not
something
that
you'd
necessarily
care
about.
If
all
you
care
about
is
end-to-end
for
a
given
protocol
that
you're,
you
know
MTU
like
1512
clean
for
the
most
part,
this
type
of
problem
tends
to
be
observed,
mostly
on
commercial
LAN
links.
B
This
occasionally
is
observed
in
other
places,
data
centers,
it's
somewhat
unusual.
Usually
in
data
centers,
you
tend
to
have
l2
connectivity
issues
rather
than
MTU
issues,
but
necessarily
this
can
be
used
in
other
environments
as
necessary.
Exciti
somewhat.
By
analogy
you
know
so
ISAs
actually
has
a
TLV
that
allows
for
padding
somewhat
for
this
exact
scenario,
so
questions
sort
of
became
as
part
of
this
discussion.
Now.
Why
don't
we
solve
this
potentially
in
other
layers?
Other
protocols
know
as
an
example,
OSPF
and
BGP.
B
Don't
support
this
BGP
being
a
little
bit
tricky
though,
since
the
TCP
co-speaker,
you
would
have
to
actually
extend
TCP.
They
do
this
sort
of
thing.
Rather,
the
PGP
protocol
OSPF
could
have
a
mechanism
very
similar,
Dyess
I
as
whether
that
makes
sense
or
not
is
prodigiously
discussion
for
the
LSR
working
group.
B
B
You
know
minimally,
you
know
very
large
megabit
no
circuits,
if
not
gigabit
circuits
and
no
a
couple
seconds
worth
of
downtime
for
an
unacceptable
application
is
actually
a
big
deal,
and
once
we
look
at
the
analogies
for
existing
protocols
like
OSPF
each
a
key,
you
end
up
in
your
large
number,
so
seconds,
no
downtime.
You
know
for
those
protocols
to
decide
that
things
are
not
working
correctly.
B
Bfd
and
modern
implementations
generally
our
control
plane
in
bed,
so
they
they
run
on
the
line
cards
and
all
these
things
tend
to
scale
up
very
nicely.
So
PFD
does
have
a
lot
of
nice
properties
where
you
know
this
seems
like
an
appropriate
place.
But
this
sort
of
thing
and
we've
received
a
commentary
that
perhaps
some
other
l2
or
other
OEM
environments
might
be
more
appropriate
for
this.
The
problem
is
I,
ITF
really
doesn't
have
a
generic
om
working
group
or
nor
do
we
cover
specific
layers.
B
Certainly
I
Triple
E
can
pick
up
such
work,
but
now,
as
we
sort
of
discovered
for
three
things
like
the
FDM
lag,
operators
are
looking
to
try
to
solve
these
problems.
So,
ideally
more
in
the
IP
house,
sometimes
than
the
acrimony
house,
excite
Lisa
so
where
I
think
the
draft
is
right
now
is
that
we
had
know
some
busy
discussion
as
part
of
the
early
adoption.
The
contents
are
mostly
not
controversial.
B
You
know,
don't
think
that
there's
going
to
be
necessarily
a
lot
of
technical
changes
over
the
course
of
development,
for
this
try
to
convince
that
my
employer
to
actually
pick
up
a
prototype
for
this
and
Albert
I
think
is
actually
looking
at
hacking,
some
eft
implementations
and
Lenox
this
if
we
can
actually
get
some
liver
behavior.
So
at
this
point,
we're
looking
for
technical
discussion
and
comment
and
hopefully
we'll
be
able
to
proceed
no
to
implementation
in
the
last
call
relatively
soon
questions
comments.
B
K
Yeah
I'm
going
to
be
presenting
the
changes
in
BFD
unsolicited
next
slide,
please.
So
this
was
presented
in
Montreal
by
Anka
naming,
so
the
there's
been
two
sets
of
changes.
The
first
set
of
changes
has
been
mostly
formatting
related
to
going
to
the
XML
format,
and
the
most
significant
change
is
that
we've
added
the
yang
model
for
configuration
and
operational
data
for
the
PFD
unsolicited
next
slide,
please.
K
So
this
yang
model
for
insulted
it
augments
the
modules
which
are
in
the
PFD
yang,
which
Jeff
was
referring
to
initially,
which
is
in
ms
ref
right
now,
there's
there's
a
new
unsolicited
container
for
configuration
which
allows
to
configure
parameters
for
unsolicited
okay
sessions.
So
just
as
a
as
a
reminder,
the
the
reasoning,
the
motivation
for
the
unsolicited
feature
is
for
cases
like
static
routes
who
are
currently
most
implementations,
have
to
configure
PFD
on
both
sides.
K
Even
though
you
have
the
static
route
really
from
just
one
peer,
so
that
unsolicited
container
has
the
parameters
for
the
unsolicited
BFG
okie
sessions.
There's
a
leaf
right
now,
which
we've
named,
allow
I
believe
we
should
rename
that
to
enable
now,
the
config
container
can
be
at
the
top
level
or
per
interface
and
does
feature
based,
as
to
yang
features,
have
been
defined
on
his
parameters,
global
and
parameters
per
interface,
and
on
the
operational
side
there
is
a
new
unsolicited
container
per
single
hop
session,
which
gives
you
the
unselected
unsolicited
state
per
BFD
session.
K
It's
basically
the
role,
whether
it's
active
or
passive.
Next,
please-
and
this
is
the
boring
yang
tree
as
you
can
see
it
augments.
The
this
one
is
the
top-level
container
I
was
referring
to.
It's
got
the
BFD
parameters
and
the
allow
leaf,
which
will
probably
rename
to
enable-
and
it
depends
on
the
global
feature
next
slide,
and
this
is
exactly
the
same
thing
but
per
interface
next
slide,
and
here
is
the
operational
model
change.
K
M
Ac
Linda
I,
just
think
this
is
that
last
is
a
is
a
good
function
for
simplification,
simplifying
use
of
BFD
and
places
where
you
use
it
automatically
I
mean
you
could
come
up
with
some
kind
of
API
or
something,
but
it's
a
lot
of
complexity,
and
if
you
just
have
this,
it
makes
makes
things
a
lot
easier
and
and
obviates
some
of
the
people
that
suggest
seamless
be
FDR
is
the
answer
to
those
situations
which
it
is
not.
This
is
for
many
of
them
effort.
B
N
O
O
This
chapter
is
similar
to
jump
to
ITF
PFD
vex
LAN,
which
is
a
is
you
process,
is
possessing
now.
The
major
difference
between
Geneva
and
the
wasteland
is
that
Geneva
supports
multiple
Coco
payload
and
the
Rebellion's
option.
That's
that's
option.
Sorry!
Okay,
this
is
the
genie
encapsulation
you
can
say.
Geneva
header
is
at
the
same
position
as
fixed.
A
header.
O
Jim
header
includes
to
Pete's
version.
1
p2,
six
bits
option
lands
a
one
peep
indicator
of
contraband
search,
one
bit
indicator
of
critical
option,
16
bits,
protocol
type
that
follows
the
ill
type
and
24
bits
what
you
network
identifier
and
then
bribe
you
lens
options
until
we
format
so
that
that's
the
Geneva
header
format
as
I
know.
3
working
group
Geneva
is
the
only
one
overlay,
encapsulation
working
group
jobs
in
standards
track
team
can
be
used
to
handle,
not
owning
is
net
frames,
but
also
IP.
O
O
Ok,
this
is
the
second
scenario
in
this
area.
Geneva
pilote
is
neither
incident
friends
and
no
I
P
packets
or
amperes
packets.
So
in
this
scenario
a
new
gene
protocol
type
need
to
be
requested
to
indicate
the
PFD
control
message.
So
here
we
have
a
question:
do
we
really
need
this
encapsulation
because
I'm
not
sure
on
the
requirement
to
for
BFD
to
monitor
the
genie
Matano
of
non
IP
service?
So
I'm
not
sure
we
need
this
encapsulation.
O
So
it's
for
discussion
next
time.
This
is
a
unified
scenario,
as
I
know
in
chemistry,
working
group.
It's
still
in
discussion,
whether
when
you
knew
Nev
o
a
machine.
So
if
we
have
a
Geneva
a
machine,
we
can
use
this
shim
to
indicate
BFD
control
message.
So
this
is
a
unified
scenario
cover
the
previous
two
scenarios.
O
P
Whether
you
had
a
question
in
your
slides
about
whether
you
need
a
non
IP,
UDP
exhalation
is
like
a
roaring
capsulation
engine
Eve
and
given
that
the
Geneva's
being
standardized
in
the
MV
o3
working
group
and
the
users
of
Geneva,
mostly
in
the
MV
o3
working
group,
it
might
be
useful
to
also
discuss
that
on
the
end
and
vo3
list.
And
maybe
we
can
bring
it
up
in
the
mp3
meeting
tomorrow.
Just
to
make
the
working
group
of
where
of
this
draft
in
DFT.
O
P
K
B
K
Q
The
problem
statement
I
have
c5
a
to
enables
routers
to
monitor
data,
plane,
connectivity
and
detector
forwarding
path.
Failure.
An
interview
protocol
level
leverages
this
specification
to
enhance
the
emergency
today
EDP
protocol
neighbor
sessions
Desmond
is
independent
from
the
EFT
state
because
of
that
they
are
possible
failure
scenarios
when
p2p
interaction
with
beauty.
Q
Q
Oh
poor
quality
link
may
relax
in
the
corresponding
PFD
session
going
up
and
down
frequently
while
PGP
session
is
established
for
eb
TP
case
typically
ebgp
peel
is
a
multi
hop
away
and
those
kind
of
scenario
are
likely
to
be
observed.
The
consequence
of
the
impact
would
be
traffic
being
black
hole,
routing,
Jo
and
knocking
interruptions.
So
next
time
please
the
proposed
solution:
eg
ppfd,
Street
mode.
This
proposed
draft
defines
BGP
Street
mode
operation
as
preventing
BGP
session.
Establishment
of
T
opposed
the
local
and
its.
Q
The
speakers
have
a
stable
PFD
session
and
we
also
defined
basically
BFD
capability
for
the
BGP
protocol.
Signaling
peel
on
the
information
next
slide,
please
this
is
the
definition
of
the
new
BGP
PFD
capability
and
the
type
is
TBD.
The
lens
is
a
one
octave
and
the
capability
value
content
of
one
octave
PFD
Flags,
the
PFD
flags,
contains
beautiful
acts
related
to
the
PFD.
The
most
significant
debate
MBS
is
defined
as
a
state
of
Street
mode.
We
also
call
the
piece
as
bit
next
slide.
Please
operations
after
Street
mode
are
a
BGP
speaker
was
PFD.
Q
Street
mode
enabled
must
advertise
the
BGP
PFD
capability
with
a
speed
value
set
to
1
a
BGP
speaker
which
supports
BGP
PFD
capability
ever
times.
Man
must
exam
the
BGP
capability,
PTP
PFD
capability
received
from
its
appear,
if
only
only
if
both
the
local
PGP
speaker
and
its
remote,
a
BGP
here
have
a
BGP,
PFD
sorry
has
BFD
Street
mode
enabled
then
BGP
session
establishment
will
be
prevented
until
its
PFD
sessions
up
always
said
only
both
peer,
our
strict
mode,
enabled
then
the
EF
history,
the
motor
constraint,
can
be
applied.
Q
Okay,
if
is
appear,
has
not
advertised
BGP
PFD
capability
with
Street
mod
enabled.
Then
a
BGP
session
should
not
be
required.
The
prayer
to
the
BGP
session
step
next
slide,
please
so
the
calculation
we
have
identified
a
problem
with
BGP
and
PFD
interaction
which
could
result
in
the
routing
Chung
at
networking
interruptions
we
propose
a
solution
to
the
problem
refers
us
PTP,
PFD
street
amount
that
prevents
bgp
sessions,
judgment
on
top-3
sessions
and
stabilized
it
enables
speedy
p.
Speakers
to
signal
is
appear
additional
bit
of
extensions
using
optional
parameter,
BGP
PFD
capability.
Q
Q
C
Bilhah
Liguori
infinera,
so
the
idea
is
good
and
that's
why
I
have
been
doing
on
maui
implementation,
strict
by
default
and
lenient
only
if
configurate,
but
I
don't
see
why
you
need
capability
at
all.
Peachy
possessions
are
configured
at
that
both
end.
So
you
could
just
have
a
configuration
option,
whether
you
want
strict
or
not,
and
that's
what
I
have
implemented
and
has
been
deployed
on
fields
and
that's
quite
nicely,
and
that's
also
avoid
unnecessary.
B
We
have
seen
between
juniper
and
sis
routers
as
an
example
for
the
hold-down
mode,
and
once
you
drop
the
session,
what
do
you
do
before
you
bring
the
session
back
up
that
we
end
up
in
deadlock
scenarios,
because
the
idea
of
who
brings
up
things
at
what
time?
No
do
you
actually
insist?
Bfd
come
up
before
even
bring
up
your
TCP
session,
or
do
you
do
it
only
after
you
have
transitioned
your
session
to
some
portion
of
up.
You
know
clarifying.
C
R
M
Ac
Wyndham,
the
reason
we
want
a
capability
is
there
are
some
circumstances
under
which
you
might
not
want
to
run
strict
mode,
and
there
are
some
that
you
may
so
that
that's
that's
the
reason.
Now
what
we
were
thinking
I
mean
this
is
gonna,
be
more
when
into
the
implementation.
We
just
hold
the
state
in
open,
confirmed
mode
until
the
PFT
session
was
established.
Well,
think
about
that
some
more.
But
that's
where
we're
leaning
as
far
as
putting
in
the
draft.
R
B
Is
very
much
an
HP
state
machine
issue
because
you
know
drill,
press
implementation
actually
holds
off
even
opening
up
the
TCP
session.
So
that's
why
you
have
the
deadlock.
This
is
definitely
worth
clarifying
because
we
do
have
actual
operational
issues.
I
don't
recall.
Was
this
presented
an
idea?
I,
don't.
M
B
Any
further
questions,
okay,
so
in
terms
of
comments
and
next
steps,
these
issues
about
when
DFT
is
used
to
bootstrap
an
application,
or
vice
versa,
has
proven
itself
to
be
an
interrupt
you.
This
is
absolutely
a
problem
that
needs
to
be
solved.
I
am
definitely
supportive
of
you
know
the
draft
moving
forward,
since
this
is
really
a
change
to
BGP
procedures.
B
My
suspicion
is
that
the
proper
working
group
that
needs
to
own
this-
this
is
just
know,
half
an
opinion
of
the
chairs.
This
may
belong
in
IDR
to
progress.
It
is
PFDs
charter
to
help
review
these
things
in
other
working
groups
as
well.
So
you
know
the
the
chairs
of
IDR
and
BFD
will
discuss,
know
where
this
might
be
long.
S
B
A
question
we
continually
get
bounced
back
to
us.
Mpls
is
a
big
example
of.
Sometimes
the
MPLS
chairs
are
happy
to
punt
things
over
to
no
bfd2
own
and
they
own
the
review
step,
and
it
just
really
becomes
a
conversation
among
the
chairs
so
but
I
agree.
Idr
is
the
natural
place
for
those
I
trust
you
but
I
just
thought.
I'd
make
that
comment.
T
So
the
problem
statement
is
exactly
similar
and
even
in
the
OSP
of
protocol,
there
is
no
way
of
knowing
whether
the
peer
supports,
PFD
or
not,
and
whether
it
has
this
capability
to
operate
in
the
strict
mode,
and
this
is
what
we
are
trying
to
achieve,
which
is
not
bring
up
the
OSP
of
adjacency.
Until
we
have
a
successful,
you
know
PFD
session
established
between
them.
The
problems
to
be
solved
is
exactly
the
same,
skip
to
the
next
one.
T
So
the
proposal
this
is
for
both
OSP
of
v2
and
v3,
is
exactly
the
same
mechanism,
so
we
want
to
enable
introduces
ability
to
indicate
that
the
desire
to
monitor
and
that
the
wastepaper
Jason
C
is
not
going
to
be.
You
know,
brought
up
until
the
PFD
session
is
up,
and
this
enables
the
wispy
of
neighbors
on
link
to
you
know,
learn
that
my
neighbor
is
going
to
operate
in
this
mode.
So
that's
that's.
T
So
how
is
it
does?
This?
Is
the
protocol
machinery
or
the
proposal
in
or
SPF?
We
have
hello
messages
and
they
carry
a
link-local
signaling
block.
So
there
are
this:
we
are
called
extended.
We
have
a
TLB
there,
which
is
extended
option
and
flags
field.
We
are
just
looking
at
introducing
B
bit
there
and
this
is
to
indicate
actually
the
BS
be
AB
district
mode.
We
did
not
want
to
have
a
BS
bit,
so
it's
just
a
bit,
and
this
is
because
the
desire
is
to
bring
up
in
strict
mode.
T
So
as
soon
as
the
neighbor
detects
the
hello
message
with
this
D
flag
set
it's
an
indication.
A
new
neighbor
is
no
it's
indication
that
you
need
to
bring
it
up
and
the
change
is
really
in
the
OSP
of
labor
FSM
and
there's
text
in
the
draft
which
clarifies
that
that
FSM
be
held
in
the
init
state
and
that
the
router
does
not
include
the
neighbor
address
in
its
hello
message
until
the
BMP
session
is
up.
I
Yes,
mercy
City,
so
I
understand
their
idea
in
its
it's
a
practical
you
want
to
bootstrap.
If
this
session
from
OSPF,
then
you
still
defend
how
fast
you
be.
If
this
session
will
come
up,
it
still
depends
how
your
timers
are
configured
so
I,
don't
know
if
you
already
advertised
this
be
in
OSPF
so
desire
to
have
PD
session.
S
K
T
T
Q
T
S
T
T
B
I
M
T
A
I
S
M
Cylinder
main
response
to
Greg
at
least
four:
oh
s,
PF.
We
have
two
mechanisms
for
indicating
appear
as
going
away
yeah.
We
have
the
goodbye
hello,
which
is
well
which
it
which
you
just
take
the
guy
out
of
two-way,
and
now
we
have
a
more
graceful
mechanism
where
you
make
the
adjacent
see
the
less
desirable
using
I
mean
literally
a
link
attribute.
Yes,
yes,
and
they
got
to
be
so
I,
don't
think
we
want
to
rely
on
a
third
mechanism
to
say
we're
going
down.
K
K
Well,
I
actually
remember
the
first
time
I
got
to
know
less
was
because
of
the
ia
that's
was
working
on,
I
is
I
was
working
BFD
that
was
about
15
years
ago
now,
what's
changed
for
SPF
and
okay,
when
we've
had
lots
of
issues
sometimes
seemed
when
there
are
different
implementations,
different
vendors?
Why
suddenly
I
mean
I'm
really
happy?
This
work
is
being
done,
but
why
suddenly
the
OSPF
and
BGP
or
now
after.
T
T
So
so
we
have,
we
have
seen
lot
more
deployments
and
especially
in
some
parts
of
the
world,
we
are
seeing
a
lot
more
lossy,
degraded
links
now
which-
and
you
know
other
stuff
going
on-
which
is
making
this
mode
more
and
more
popular,
and
we
have
had
this
config
option
and
we
were
able
to
work
with
it,
but
we
are
also
getting
into
more
of
Interop
amongst
multi
vendor.
So
it's
been
there
for
a
long
long
time,
but
I
would
say
some
recent
experiences.
S
We're
having
a
lot
of
fun
here,
but
the
comment
I
would
make
is
I
think
this
is
actually
long
overdue.
It
was
always
and
I
know
there
are
multiple
vendors
who
have
implemented
this
functionality.
You
know
based
purely
on
configuration,
but
given
that
it
actually
changes
the
operation
of
the
protocol
and
affects
interoperability.
It
has
always
been
very
strange
to
me
that
we
would
decide
to
do
that
and
not
update
the
protocol
itself.
So
to
me
this
is
just
something
we,
you
know
long
overdue.
Q
Moisture
from
Cisco
I
actually
want
to
say
the
same
thing,
and
when
I
read
that
there
I
see
5a,
it
has
the
section
for
that
one
specifically
talking
about
control
protocol
establishment.
It
also
describes
a
scenario
similar
to
this
one
and
so
on.
Here
today
we
provide
the
solution
for
the
client
side
and
we
actually
also
have
a
customer
encountered
the
problem
exactly
amid
a
request
to
to
have
this
fix
thanks.
I
Okay,
so
again,
this
is
called
extended,
BFD
well,
some
might
think
about
it
as
BFD
2.0,
we'll
see
where
it
goes
next
slide,
please.
So
what
the
motivation
well
we're
all
discussed.
Many
interesting
scenarios
how
to
use
BFD
beyond
their
fat
monitoring,
and
it
was
a
quality
of
beef
this
session,
because
no
in
the
link
that
is
unstable,
lossy
and
with
their
default,
detect
multiplier
of
three.
I
It
might
be
situation
that
will
lose
every
other
be
of
the
packet,
so
we're
getting
very
close
and
an
edge
of
failing,
but
definitely
it's
not
good
enough,
so
it
might
be
not
performance
monitoring,
but
it's
something
really.
There
may
be
a
serve
as
a
very
good
indication
that
things
are
dangerously
close
to
falling
off
the
cliff
or
it
can
be
might
be.
I
There
was
a
proposal
to
use
BFD
for
the
performance,
monitoring
and
path,
MTU,
either,
monitor
consistency
of
path,
MTU
or
do
path,
MTU
discovery
of
sorts
and
when
we
thought
about
it,
so
what
it
should
do
is
that
clearly
was
that
backward
compatibility
is
the
first
requirement
and
ability
to
extend
beyond
what
we
thought
off.
So
everybody
who,
as
a
interesting
ideas
area,
would
be
able
to
extend
this
mechanism
so
which
means
like
TV,
it's
very
simple
right
used
to
be,
and
it
will
be
extensible
next
slide.
I
Please,
and
what
we
are
proposing
is
just
take
PFD
control
message
as
defined
58,
80
god
WordGirl
work.
We
think
that
might
serve.
As
you
know,
if
you
come
up
with
a
weird
combination
of
bits
and
for
off
that
word,
that
is
unusually
to
pop
up
in
the
random
space
that
will
be
indication
whether
it's
a
really
extended
B
of
D
or
something
else
because
again
face
it.
I
We
are
still
using
the
same,
our
UDP
port
number
and
then
followed
by
theories
that
can
use
in
close
to
Yogi's
as
a
sub
theories,
and
those
may
use
again
in
close
TVs
as
a
sub
sub.
Tvs
next
slide,
please
so
it
all
starts
with
a
capability
negotiation,
and
that's
where
the
backward
compatibility
kicks
in
the
proposal
is
that
length
field
in
the
BFD
control
message,
as
defined
by
58.
Eighty
is
reflective
of
BFD
control
message
length
and
for
IP
encapsulation.
I
So
when
the
initiator
that
initiates
the
capability
negotiation
in
extended
BD
sends
it
first
extended
via
the
packet
with
announced
capabilities.
Well,
it
expects
something
back.
What
can
be
coming
back
to
it?
If
nothing
comes
back,
is
the
timer
expired?
Well,
then,
it
should
realize
that
extended
BFD
is
not
supported
and
go
along
with
the
58
eighty.
If
it
receives
back
anything
different
from
the
final
with
their
some
capabilities
acknowledged
of
the
pier
well,
then
everything
is
fine.
I
They
can
proceed
with
extended
VFDs
session,
but
if
it
receives
something
different
from
the
final
like
a
poll
packet,
then
it
has
still
to
conclude
that
extended
BFD
is
not
supported
and
go
with
their
58.
Eighty
version
of
50
next
right.
So
after
that,
what
can
be
done?
Performance
measurement,
I
apologize?
There
is
a
diaper,
it
was
mentioned,
but
it
should
be
63.
I
I
If
we
want
to
have
very
eight
length
of
extended
bilder
packet,
there
is
an
extra
padding
TLV,
it
can
do
a
delay
measurement
and
it
time
stem
can
be
collected
either
in
truncated,
PTP
to
1588
format
or
in
ntp
format
and
each
side
center
in
reflector.
They
can
support
their
own
format
and
they
explicitly
indicate
in
a
packet
and
again
it's
not
something
that
we
introduce
is
already
in
63
74,
and
then
there
is
a
combined
loss,
delay
measurement
mode
that
is
again
supported
by
message
defined
in
63.
74
measurements
can
be
done
either.
I
One
way
performance
measurement,
for
example,
as
using
extended
BFD
a
message
as
a
control
messages
sent
in
asynchronous
mode
theoretically
and
not
necessarily
will
be
every
message
again.
It
could
be
a
some
length
message
in
the
flow
or
it
could
be
the
measurement
using
the
post
sequence
so
that
performance
measurement
is
done
only
with
the
using
pole
of
black
and
then
message.
It's
an
echo
request,
reply
mode.
I
Okay
nicely
so
this
just
recapture
of
what's
defined
in
63
74
and
how
it
looks
for
their
extended
VFD
Ross
measurement.
We
can
go
really
fast,
so
this
is
delay
measurement
and
again
it
has
indication
of
the
timestamp
format
of
the
queer
and
responder
qtf
in
RTF
next
slide,
and
that's
where
the
combination
of
laws,
delay,
measurement
format.
I
For
violating
the
length,
if
we
are
doing
synthetic
measurement
or
delay
measurement,
there
is
extra
padding,
TV
and
the
same
can
be
used
for
MTU
and
again.
Mtu
can
be
either
monitored
using
full
sequence
or
it
can
be
used
along
with
their
periodic
messages,
send
in
s
in
coarse
mode
and
then
what
you
can
end
up
with
that.
If
MTU
suddenly
changes,
then
the
session
will
go
down
because
messages
may
not
get
through.
I
So
again,
it's
very
for
the
detection
to
monitoring
okay,
so
we
will
continue
working,
there's
some
outstanding
things
that
to
be
worked
on.
One
of
them,
for
example,
is
fetching
results
from
their
one-way
measurement.
At
the
same
time,
I
believe
that
it
will
have
to
have
yang
model,
so
this
metrics
can
be
exported,
not
necessarily
fetched.
Then,
of
course,
discuss
discuss,
discuss
and
we
welcome
common
suggestion
and
cooperation.
K
K
I
Understanding
again,
as
I
pointed
out,
it
not
necessarily
always
has
to
work
with
there,
a
synchronous
mode
and
again
it
doesn't
have
to
always
be
for
each
message
being
theoretically
sent
in
a
secure
in
this
mode.
So
it
can
be
used
in
pole,
sequence
so
and
pole
sequence
can
be
any
frequency.
Okay.
So
again,
there
is
a
flexibility,
for
example.
If
we
talk
about
MTU
right,
so
you
can
use
MTU
detection,
yeah.
I
You
came
back
it
right
or
you
can
use
it
as
MTU
monitoring,
because
for
their
poor
sequence,
you
can
only
monitor
you
send
it
there.
Yes,
packet
might
not
get,
but
you
will
get
a
clue
that
pecking
didn't
get
there
right
because
it's
it
turns
out,
and
then
your
sender
can
interpret
the
result
whatever
it
wants.
Okay,
so
it's
more
like
a
monitoring
mode.
I
So
again,
I
I
think
that
what
this
introduces
this
introduces
this
flexibility
of
doing
it
in
message
and
they're
doing
in
a
polling
mode,
not
necessarily
doing
it
only
in
periodic
fashion
and
that's
a
flexibility
that
I
believe
that
we
can
appreciate
and
use,
because
sometimes
in
a
different
scenario,
we
want
the
session
to
go
down,
but
in
some
just
notification.
The
realization
that
something
changed
is
good
enough.
I
K
So,
okay,
so
I
mean
the
question
I
was
getting
at,
which
was
the
same
question.
We
asked
for
DFT
large
pockets
is
why
do
that
in
DFT?
We
have
that
discussion
is,
is
hazard,
others
don't
have
it.
Dft
is
the
placeholder
so
from
what
you're
saying?
Okay,
okay,
so
my
thing
was:
why
do
that
in
gear?
So
from
what
my
understanding
I.
I
Okay,
I,
okay,
I
can
explain
what
was
there.
What
has
triggered
this
work
as
a
last
drop,
because
definitely
it
was
something
that
was
in
the
back
of
mind
and
we
discussed
it
and
you
know
somewhere
deep
was
you
know
growing,
but
the
rest
was
a
discussion
on
mechanism.
Rift
has
four
zero
touch
provisioning
and
exchanging
linked
IDs
that
can
be
interpreted
as
beef
discriminator.
I
I
There
is
a
provision,
and
actually
there
are
a
lot
of
interest
in
zero
cash
provisioning
right
and
they
realize
that
they
need
to
bring
up
BFD
as
they
bring
up
boxes.
So
if
they
bring
up
BFD
already,
why
not
to
extend
BFD
that,
along
with
bringing
BFD,
they
will
get
more
powerful
or
a.m.
to
set
rather
than
just
staff
monitoring.
So,
basically,
the
motivation
for
this
to
extending
BFD
is
to
give
to
zero
touch
provisioning
model
powerful
in
comprehensive
om
to
set.
B
Pause
for
a
second
there,
like
said,
we
prepared
a
couple
of
quick,
slides
and
part
of
this
is
prior
discussion,
and
this
is
summarizing
some
prior
points.
So
the
question
really
comes
at
month.
Know:
we've
we've
had
discussions
over
literally
about
three
years,
and
certainly
the
motivations
for,
like
the
DFT
performance
work,
was
an
excellent
example
of
at
what
point
do
we
decide
that
we
need
to
change
the
core
of
BFD
and
part
of
that
is
no?
B
Can
we
do
it
an
existing
protocol
and
really
the
criteria
the
chairs
have
had
over
the
entire
life
of
the
protocol?
Is
that
me
if
he
was
always
intend
to
be
a
very
thin
protocol,
very
fast,
very
easy
to
implement
for
use
with
its
speed
and
to
some
extent
that
means
that
the
one
of
the
criteria
we
were
always
used
is
what
do
you
want
to
do
as
a
new
extension
every
three
milliseconds,
because
that's
the
no
aggressive
typers
that
people
try
to
go
for?
B
So
when
we
look
at
some
of
these
applications,
part
of
the
interesting
question
becomes
now
you're,
giving
examples
of
doing
this
work
as
whole
sequence
type
of
information.
As
a
way
to
sort
of
not
do
the
work
all
the
time,
that's
certainly
a
mechanism
to
try
to
do
less
work
and
that's
an
interesting
discussion
point.
B
The
other
criteria
that
we
have
tended
to
use
is
the
extensions
can't
break
our
core
use
case.
The
pole
is
an
example
of
how
we
might
be
able
to
use
it.
That
is
extension
and
not
break
things,
and
basically,
where
we
have
been
driven
in
a
lot
of
cases,
is
when
the
extensions
don't
look
like
they
fit
into
the
core
use
case
very
well,
we've
had
to
say
no
so
in
terms
of
methods.
B
No,
certainly,
no
as
the
example
when
the
FDA
large
packet
sort
of
let
out
the
door,
you
know
something
that
we've
known
that
we
could
use
for
years
as
a
possible
extension
mechanism.
Your
mechanism
makes
sense.
You
know
that
you
know
have
a
place
that
we're
willing
to
advertise.
We
could
do
this
sort
of
thing.
The
offer
at
least
a
level
contrast.
B
The
large
packets
really
isn't
doing
much
with
the
contents
beyond
the
end
of
the
packet,
whereas
some
of
the
stuff
you're
discussing
would
potentially
impact
like
the
FT
state
machinery,
so
there
there
may
be
some
yeah,
maybe
some
motivations
to
not
do
it
with
simply
v1
the
gotcha.
Is
that
I
wouldn't
sorry
the
other
problem
is
that
anything
we
put
past
the
end
of
the
package
won't
work
with
the
existing
authentication
mechanisms.
So
that's
that's
going
to
be
a
red
flag
for
our
security,
guys
actually.
I
We
specifically
refer
to
B
of
D
control
message
defined
by
58,
a
B
as
defined
by
58
80,
whether
it's
with
authentication
extension
or
not.
Okay.
So,
basically,
yes,
we
don't
change.
If
d-58
area
of
beef,
D,
regular
classic,
okay,
I,
don't
know,
let's
agree
to
cult
classic
session.
Is
configuring
with
authentication
everything
stays
the
same
as
authentication
in.
B
The
comment
really
is
that
the
authentication
really
covers
only
contents
of
the
BFD
packet
rather
than
stuff
that
come
after
the
end.
You
know
sort
of
by
contrast
and
again
PFDs
large
packet
stuff
was
partially
motivated
by
same
trick
that
OSPF
used
years
ago,
pacific
extension
and
it's
no
surprise,
no
Dave
Katz
was
an
old
IGP
guy.
He
knew
exactly
that
trick
was
there
in
their
case
they
added
a
fent.
Ocation
is
the
thing
after
the
fact,
so
that
didn't
have
to
change
the
existing
PDU
behaviour.
B
In
this
case
the
authentications
are
any
part
of
it.
So
one
of
the
things
we
have
to
discuss
as
part
of
this
process
is
what
dasta's
to
authentication
second
thing
is.
It
was
example:
whole
sequence,
work
based
on
the
contents
as
an
example,
we're
sort
of
a
state
machine
type
change
now
pay
attention
to
some
things
are
not
against
larger
discussion.
B
At
some
point
we
have
to
decide
when
the
procedural
changes
are
finally
a
motivator
to
do
a
PFD
v2,
and
you
know
this
is
an
excellent
starting
point
for
the
conversations
problem,
of
course,
is
this
larger
work?
The
extensions-
and
you
know
the
sort
of
premise
of
large
packets
is
that
you
can
stick
things
at
the
end
and
have
existing
EFT
p1
just
work
fairly,
seamlessly
with
it.
So
that's
a
nice
thing,
yeah.
B
Then
we
do
have
bits
for
your
PFD
v2,
so
the
motivation
has
to
become
know
whether
the
backward
compatibility
considerations
for
existing
deployments
really
justify
know
having
the
behavior
in
v1
versus
a
v2
so
again
longer
conversation.
This
is
not
the
draw
conclusions.
This
is
just
the
Highline
thinks
we
knew
about
the
last
one
for
my
list
again,
the
question
usually
becomes:
what
do
you
want
to
do
every
three
milliseconds
of
BFD?
B
No,
so
we
give
the
example
in
your
poll
sequence
of
version
of
being
able
to
do
work,
that's
covered
by
om
as
an
example
whether
or
not
the
guys
om
would
actually
want
the
stuff
that
happened
to
BF
he's
an
interesting
long,
question
mm-hmm.
But
the
sort
of
meta
point
that
comes
from
this
is
less
about
what
the
applications
actually
are,
and
it's
partially
what
the
comments
that
we've
had
from
the
ASIC
implementers
over
the
years
for
PFD.
B
They
like
the
FT,
similar
to
the
guys
who,
like
no
IP,
fix
and
NetFlow,
because
it's
fixed
size
very
easy
to
parse
very
low
work
to
actually
do
the
minute
we
start
introducing
tlvs
we
introduce
into
you,
know.
Basically,
the
core
Fastpass
of
the
seat
views
the
need
to
actually
look
at
verbal,
like
data
guys
that
work
on
IP,
six
ipv6
Asics
will
tell
us
that
they're
not
very
happy
with
how
that
stuff
works.
So
again,
this
is
another
piece
of
our
discussion.
Yeah.
I
One
of
the
motivation
for
us
to
use
63
74
is
that
it's
already
very
much
like
fixed
size,
and
you
know
where
your
timestamp
encounters
is
because
we
can
define
how
it's
used
and
then
given
their
fixed
size
of
predictable
size
of
the
classical
control
message.
It's
in
a
well-known
place,
yes,
I
know,
I
absolutely
agree
for
the
performance
measurement,
your
fields
that
you
fill
in
time,
step
encounters.
I
B
Mode
and
just
they
reject
the
point
before
AC
that
follows
on
that.
Tl
fees
themselves
are
not
necessarily
bad
when
and
used
in
such
a
way
that
you
can
actually
understand
they're
there
again
ticking
on
NetFlow
nike
fixes
examples.
Those
are
template
driven
systems
where,
by
describing
the
template
ahead
of
time,
fast
lookup
mechanisms
can
be
implemented,
you're
not
doing
completely
arbitrary
TL
fees.
What
you're
actually
doing
is.
M
They
suggest
okay,
I
said
I
haven't
thought
about
it
as
much.
The
chairs
I
just
really
looked
at
it
earlier
before
the
meeting,
so
the
one
thing
I
was
I
was
going
to
say
about
OSPF.
We
do
have
separate
authentication
for
the
L
LS.
It
did
come
after
and
we
did
have
to
put
a
separate
event
in
it
and
it
is
a
much
more
control.
Blindage
protocol.
If
you
go
with
this
completely
generalized
capability
based
8
d
lb
base,
I
think
they
should
be
separate
protocols
leave
VFD
run
alone.
M
If,
if
that's
the
way
you
choose
to,
if
you
just
do
some
little
like
ok,
this
is
how
you
do
this.
You
know
or
some
simple
extensions.
Then
maybe
you
could
do
extend
BFP
one,
but
there's
a
lot
of
I'm
thinking
back
to
those
easy
chip,
easy
chip,
baseline
cards
I
mean
you
they'd,
never
do
anything
yeah!
No,
it
was
not
easy.
Yeah
again.
M
M
B
I
Okay,
okay
I
will
turn
me
down
most
of
the
time
and
then
actually
impact
on
asynchronous
mode
will
be
lesser,
but
at
the
same
time
it
can
still
be
useful
for
the
same
performance
monitoring
because
you
don't
really
you
know.
If
we
look
at
the
protocols
like
t1
or
now
we
have
stamp
so
the
reflector
it
doesn't
matter.
If
your
quarks
are
synchronized
and
you
everything
do
it
doesn't
matter
how
you
reflector
processes
the
received
packet
and
sends
it
back
whether
it's
all
hardware
is
a
bump
in
the
wire
or
its
control
plane.
I
R
Capital
R
cos
I
just
have
a
quick
comment.
Aside
from
you,
know,
working
with
hardware
implementations
and
having
an
unfortunate
experience
of
implementing
this
protocol
in
software.
One
of
the
things
I
really
appreciate
about
it
is
the
fixed
packet
formats
and
actually
fixed
filled
lens
within
it
to
really
read
the
packets
pretty
fast
having
static
buffers
define.
So
if
you
come
up
with
a
variable
and
TLB
format
and
variable
length
packets
size,
my
only
suggestion
is:
have
a
cap
such
that
a
priori
and
implementers
would
know
if
you
have
to
implement
this
somewhat.
I
In
software
yeah,
if
we
can
go
back
so
again,
the
users
TV
at
least
for
this
scenarios,
is
only
necessary
for
extra
padding,
because
everything
else
and
again,
that's
why
we
reuse,
what's
defined
in
63,
74
fix
it
again
to
my
liking
as
much
as
I
am
exposed
to
performance
monitoring,
63
74
structured.
It
perfectly
again.
We
can
say
it's
very
similar
to
CFM
okay.
So
it's
not
a
bad
example.
I
B
One
way
to
read
at
least
between
part
of
those
lines
is
ITF
has
been
somewhat
in
need
of
a
more
generalized
OAM
mechanism
for
a
while.
A
question
for
the
working
group
over
the
long
term
is:
is
the
PFD
be
to
work
potentially
motivation
to
try
to
actually
leverage
no
doing
new
work
on
the
protocol
for
some
more
generic
OAM
purposes?
I,
don't
have
a
strong
opinion
on
this
and.
I
Again,
I've
been
exposed
to
63
74
and
I
protocols
like
Oh,
wham,
womp,
and
now
we
are
clear.
The
working
group
Roscoe
on
the
stamp
I
appreciate
their
discipline
of
63
74
and
it's
more
hardware
friendly
than
t1
or
1p
okay.
So
it's
just
again
I
as
a
supported
out.
Yes,
III
know
the
problems
of
chips
and
not
to
overextend
it
so
and
make
it
position
well
known
and
predictable.
I
think
that
63
74
is
very
good
too,
for
the
performance
monitoring.
B
B
K
Yeah,
just
on
this
last
topic
on
Greg's
presentation,
please
everybody!
You
know
whether
you
deploy
or
implement
software
hardware
BFD,
that's
a
pretty
big
topic.
If
we
take
this
on
whether
it's
in
the
way
Greg
presented
it
or
whether
we
do
v2,
which
has
a
big
impact
as
Greg
mentioned,
so
please
be
vocal,
but
nice.
Thank.
A
B
So
the
stuff,
the
stuff
that
we
have
in
the
queue
right
now,
the
first
half
of
the
presentations-
are
things
that
I
think
is
impressively
progressing.
The
aliens
on
their
own,
the
em-50
strictmode
stuff
I-
think
will
progress
in
the
individual
working
groups,
so
the
main
reason
they
have
a
discussion
I
think
is
primarily.
N
B
Potentially,
but
where
it
sort
of
comes
down
to
is
ideally
we'll
get
some
good
discussion
of
the
df/de,
whether
it's
be
one
extended
or
v2.
If
we
have
nice,
no
aggressive
stuff
on
the
mailing
list
and
you're,
not
necessarily
converging,
that's
excellent
use
of
microphone
time
session
basically
becomes
a
let's
discuss
this.