►
From YouTube: IETF110-BFD-20210311-1430
Description
BFD meeting session at IETF110
2021/03/11 1430
https://datatracker.ietf.org/meeting/110/proceedings/
B
C
That's
your
problem,
for
whatever
reason,
at
least
as
of
the
last
ietf,
you
couldn't
share
anything
other
than
your
full
screen
with
safari.
A
Okay,
let
me
okay.
C
And
if
you're
using
so,
I
think
that
both
chrome
and
firefox
are
known
to
work.
Well,
you
do
end
up
having
to
enable
the
allow
screen,
recording
or
something
like
that
in
the
security
part
of
the
settings,
which
then
requires
you
to
restart
the
browser.
Also.
A
B
D
B
I
will
look
for
the
chair,
slides
just
in
case.
I
have
to
do
the
projection.
B
A
Okay
thanks.
Thank
you
everyone.
This
is
bfd
at
itf,
110,
rashad,
co-chair
and
whoop
jeff
next
slide.
Please.
A
You're
basically
agreeing
to
everything
the
itf
policies,
the
agenda,
so
that's
the
chairs,
update
from
jeff
and
myself,
then
we'll
go
to
bfd
and
sold
sister.
That
will
be
me
bfd.
Secure
numbers,
I
believe,
is
from
mahesh
and
not
so
now.
Right
now,
mahesh
will
continue
vfd
stability
and
then
we'll
have
bfd
on
our
feet.
An
affiliated
echo
next
slide.
Please.
A
C
Returning
from
childhood,
I
believe
I
was
there
at
the
very
first
meeting
between
it
was.
I
think
the
people
in
the
room
were
dave,
katz,
dave,
ward
and
me,
but
it's
you
guys
baby
now
appropriately
so
and
I'm
looking
forward
to
working
with
you.
A
A
A
Okay:
here's
an
update
on
the
documents
we
have
in
urfc
rfc
8971,
which
is
bfd
for
vxlan,
would
like
to
thank
everybody
who
contributed
reviewed
the
authors
and
a
special
thanks
to
greg
for
pushing
it
over
the
finish
line,
which
is
always
a
tough
job.
A
Bfd
for
large
packets
there's
been
discussions,
there's
been
a
relate
that
was
in
working
group.
Last
call
there's
been
a
a
more
recent
draft
regarding
how
to
other,
if
you
guys
remember,
but
bfd
large
packets
allows
you
to
have
large
packets
to
detect
mtu
issues,
but
it
doesn't
address
procedures
to
alter
the
bfd
padding
size
and
that
draft
bf
debating
alteration
describes
procedures
to
do
so.
The
authors
have
decided
to
merge
documents
together.
A
Thank
you,
bfd
yang
document.
It's
been
a
while
we've
had
to
send
diffs
to
the
rfc
editor
do
a
change
in
one
of
the
modules
it
depends
on
the
t's
yankee.
That
document
has
been
in
miss
ref
for
close
to
three
years
now
I
haven't
checked.
What
are
the
state
of
the
other
documents?
I
mean
the
ones
it
depends
on,
so
I
don't
have
a
good
idea.
What
a
potential
eta
would
be.
B
So
a
quick
point
on
this
one.
It
was
mentioned
in
one
of
the
other
meetings
this
week.
I
have
to
pull
my
notes
to
exactly
which
one
I
think
was
in
the
chat
that
one
of
the
options
we
could
consider
doing
to
maybe
move
things
forward
is
to
take
the
document
back
from
the
rfc
editor
and
split
out
the
mpls
component
and
ship
it
without
the
mpls
component
in
the
main
document
and
do
a
second
document
with
mpls.
B
E
Hello
jeff.
That
was
me
who
suggested
that
this
ac
and
lsi
suggest
that
in
lsr,
because
I
had
done-
I
had
done
some
homework
and
I
saw
that.
Not
only
are
you
work
waiting
on
yang
te
you're,
waiting
on
yang
t-e-r-s-v-p,
which
t
e
references,
so
you
got
to
get
both
of
those
done
just
to
get
that
one
reference
to
the
tunnels
or
those
I
mean
those
those
references
to
the
tunnels
in
the
mpls
document.
B
Thank
you,
ac,
I'd
forgotten
that
it
was
you
yeah
so,
and
I
think
part
of
the
relevant
point
here
since
was
mentioned
lsr-
is
that
we're
also
holding
up
other
people
that
are
importing
the
module
that
we
asked
them
to
use
as
the
grouping
to
make?
You
know
life
consistent
for
the
rest
of
the
bfd
users,
so,
unfortunately,
what
we're
trying
to
do
the
right
thing
for
everybody.
Mpls
is
sort
of
messing
that
up.
A
F
Okay,
so
richard
and
jeff,
actually,
I
did
have
an
opportunity
when
I
was
writing
the
yang
module
for
one
of
our
drafts
to
actually
test
out.
And
yes,
richard,
there's
a
minor
change
in
the
tease
document
which
I
was
able
to
address
by
changing
the
pft
module
to
get
it
to
compile.
F
E
That
yeah
I'll
just
add
I
I
would
I
would
hold
you
know:
you're,
holding
it's
holding
up,
ospf
isis
and
pm
at
least.
G
A
Okay,
we'll
sync
up
on
that
and
my
is
the
fix
you
have
to
do.
Is
it
do
you
remember
if
it's
the
same
fix,
I
had
sent
to
the
rfc
editor,
or
should
we
sync
up
on
that.
F
Yeah,
I
don't
remember
exactly
what
you
changed.
I
think
it's
one
of
the
plurals
and
one
yes.
A
There
was
yeah,
there
was
one
thing
for
lsps
versus
lsp
from
what
I
remember
right:
okay,
bfd
unsolicited.
It's
expired
recently.
We
need
eurovision
there's
going
to
be
a
quick
update
immediately
after
the
bfd
authentication,
docs
there's
been
updates
recently,
based
on
the
comments
from
the
shepherd.
We
should
be
done.
Working
group
last
call
soon,
there's
going
to
be
an
update
on
two
of
the
documents.
After
I
think
it's
fairly
minor,
minor
stuff
left
well,
the
document
has
come
a
long
way.
I
think
we're
close
to
being
there.
Yes,
greg.
A
Okay,
okay,
and
that
was
for
this
document
of
interest.
You
know
I
want
to
take
a
look
that
I
did
not
have
time.
I
don't
think
there
was
any
feedback
and
I
believe,
that's
an
rfc.
Now.
E
D
Got
needed
votes
from
isg
and
it's
in
rfc
editor
q.
But
if
I
may,
I
wanted
to
mention
other
documents
in
mpls
working
group.
B
B
So
that's
one
of
the
hold
up
points
it
didn't
get.
You
know
the
wider
review,
even
an
idr,
and
I
think
the
it
hasn't
hit
my
iq
as
a
new
idr
chair
yet
but
john
may
have
a
better
sense
of
what
it
was
last
status
wise,
but
the
need,
for
you
know
this
being
a
more
generic
mechanism
is,
I
think,
one
of
the
sticking
points
we
have
to
figure
out
what
that
goes
on
with
there.
H
So
speaking
of
specific
best
coaches,
it's
currently
in
the
rlc
editor's
queue,
I
believe
it
went
through,
invest
mostly
because
it's
fairly
specific
to
or
is
considered
fairly
specific
to
to
to
vpns,
but
that
may
be
you
know.
Some
people
have
different
different
opinions
on
that,
but
I'm
not
sure
stefan,
my
co-chair
was
actually
shepherding
it.
So
I
don't
know
if
he's
tracked,
the
he's
not
in
this
call
attract
any
of
those
issues
that
you
mentioned
more
closely.
B
Yeah,
I
don't
know
that
there's
serious
issues,
I
did
leave
some
specific
comments.
You
know
as
part
of
my
own
review
of
the
thing,
and
that
was
before
I
took
on
the
chair
job,
so
I
think
a
conversation
will,
you
know,
probably
need
we
need
to
close
off
on
those
points
minimally.
The
point
libraries
need
to
be
addressed
and
past
that
point
more
eyes.
D
As
editor
of
this
document,
I
hope
that
I
addressed
your
comments,
so
yes,
I
appreciate,
if
you
can
check
the
current
version,
I
will
do
so.
Thank
you.
B
So
my
interruption
being
done
greg,
you
said
you
had
further
documents
to
bring
to
attention.
D
Yes,
so
there
is
a
one
mpls
working
group
document:
it's
bfd
directed
for
traffic
engineering,
environment
or
path,
engineered
environments.
What
it
does
it
extends
mpls,
lsp
ping.
D
D
Dvd
community
to
look
at
it
and
share
comments
on
vfd
and
ls
working
group
documents
mailing
lists.
D
A
And
greg
so
that
last
one
you
said
the
mps
encasion's
point
to
my
point
in
what
working
group
is
it.
A
Mpls
working
group-
okay-
and
you
mentioned
the
previous
one-
the
the
bfd
okay
directed-
is
stuck
in
in
what
it's
stuck
in.
What
state
now
and
for
what
reason.
D
D
Ambivalent
to
that,
so
I
hope
that
I
know
I
recall
that
jeff
looked
at
this
draft
and
shared
his
expert
opinion
on
working
group
chair,
but
I
don't
think
that
it
really
was
accepted
because
it
was
not
on
the
mailing
list.
It
was
a
small
group
discussing
so
if
somebody
or
some
experts
from
the
group
can
share
their
opinion
on
mpl's
mailing
list,
whether
it's
useful,
whether
it's
a
reasonable
solution,
I
would
greatly
appreciate
that.
A
A
It's
coming
up
yep!
Thank
you!
Okay,
richard
again,
I'm
going
to
be
just
giving
a
quick
update
on
this
document
on
behalf
of
all
the
authors
next
slide,
please.
A
A
For
this
feature,
you
know
when,
when
the
document
was
adopted,
we
had
a
young
doctor
review,
which
required
a
small
change
in
the
main
bfd
young
model
that
was
sent
to
the
rfc
edit
that
was
sent
to
the
rfc
editor
and
because
of
the
yang
model.
We
change
the
document
from
informational
to
standards,
we'll
talk
about
that
on
the
next
slide
and
then
working
group
last
call
was
was
requested
last
august
next
slide.
Please.
A
A
We,
the
authors,
need
to
address
this.
The
comments
were,
I
think,
yeah
specific
to
the
subnet
check
and
the
source
address
for
lookup.
So
that's
something
which
we
did
not
give
reply
to
and
we
have
to.
We
have
to
look
into
and
update
the
document.
Accordingly.
A
The
other
discussion
which
happened,
I
believe
from
that
got
started
by
less,
I
believe,
was
all
the
well.
The
two
were
related
was
first,
whether
the
yang
should
be
in
the
same
document
as
the
future.
A
A
There
was
no
consensus
here
and
there
seems
to
be.
I
had
sent
an
email
to
the
ops
ads,
rob
wilton
replied.
I
think
I
got
reply
from
somebody
else.
I
forget
who
there
seems
to
be
no
itf
rules
as
to
whether
having
a
yang
requires
the
dock
to
be
standard
struck.
A
Personally,
I
don't
really
mind
either
way
whether
it's
informational
or
standards
tracked.
I
know
there
was
a
push
to
keep
it
informational
because
there's
no
protocol
changers
there,
but
there
is
a
yang
okay
model.
So
john,
we
may
need
your
well
not
me.
We
will
need
your
help
just
to
close
on
this.
A
And
also
got
comments
from
greg.
There
were
some
clarifications,
so
one
of
the
reasons
just
I
mean
for
informational
purposes.
One
of
the
reasons
this
document
stalled
was
three
of
the
full
authors
changed
jobs
in
the
past
year
or
so
so
we
need
to
get
back
to
it
next
slide.
Please.
A
Move
ahead
with
it,
but
the
main
thing
you
know
from
a
non-technical
viewpoint
is:
we
need
to
address
the
standards
track
versus
informational.
B
C
Enough
for
me
to
be
educated
about
the
standards
correct
versus
informational.
I
have
a
question
which
is
what's
the
downside
of
moving
it
forward
as
standards
correct
from
your
perspective,
because
that
would
appear
to
address
the
ambiguity
by
making
it
move.
B
Fine,
I
I
think
the
general
consensus
from
the
working
group
is
their
ambivalent
about
what
the
actual
status
of
this
is
originally
without
the
ang
module.
There
is
absolutely
no
protocol
change.
B
This
is
more
about
here's,
how
you
use
existing
mechanisms,
mostly
via
configuration
and
that
sort
of
thing,
so
that
was
the
real
reason
to
have
it
informational
and
the
ambiguity
is
strictly
what
does
having
a
yang
module
inside
of
your
document
do
to
things
the
the
question
effectively
devolves
down
to
we're
polluting
the
ietf
namespace
for
modules,
by
putting
our
stuff
in
there
and
ietf
effectively
has
to
manage
that.
So,
while
we're
not
changing
bfd
we're
changing
the
yang
tree
that
ietf
as
a
whole
manages.
B
C
Right
yeah,
I
get
the
reason
why
the
the
you
know
bfd
may
pull
standards
crack
in
with
it.
I'm
just
trying
to
understand
why
the
working
group
wouldn't
just
say
okay,
find
standards
track,
but,
as
I
said,
we
can
take
it.
C
F
F
All
right,
so
I
will
be
presenting
secure
sequence
numbers
on
behalf
of
sonal
who
could
not
attend
this
particular
meeting
next
slide.
Please.
F
So,
as
rashad
mentioned
in
the
chest,
status
we've
been
going
through
trying
to
address
the
itches
addressed
now.
I
think
there's
still
a
couple
of
minor
comments
still
left,
which
I
think
we
will
address
in
the
next
revision.
F
So
one
of
the
questions
that
was
raised
as
a
result
of
the
shepherd's
comments
was
has
to
do
with
the
fact
that
we
do
talk
about
symmetric
algorithm
that
is
used
to
compute
the
ciphertext.
For
this
sequence
number
itself,
the
suggestion
from
richard
was
whether
we
should
mandate
or
even
propose
actually
a
minimum
algorithm.
I
don't
remember
richard,
which
is
the
one
you
maybe
said
as
the
minimum
that
we
might
want
to
propose
in
the
draft
for
the
purpose
of
interoperability.
F
That,
of
course,
leaves
the
question
of
what
happens
if
that
minimum
algorithm
ever
gets
obsoleted
or
deprecated
at
that
point
would
become,
have
to
come
back
and
drop.
The
draft,
so
typically
iitf,
has
not
been
very
good
at
being
able
to
specify
a
minimum
set
of
algorithms.
F
So
this
is
a
question
for
the
work
group
to
answer
and
then,
if
not,
then,
should
the
trunk
leave
it
to
the
implementers
to
decide
what
algorithm
they're
going
to
set
up
as
a
minimum
or
whatever
they
propose
in
their
implementation.
F
So
that's
pretty
much
all
I
had
and
I
would
pause
and
see
if
anybody
in
the
work
repair
has
any
comments
or
suggestions
on
how
to
resolve
this
question
of.
A
Personal
opinion
you
mentioned
that
and
you're
correct
that
this
is
usually
not
done
to
suggesting
algorithms
for
the
reason,
so
I
think
I'll.
If
this
is
something
which
is
not
done
for
the
reasons
you
mentioned,
we
should
probably
go
along
the
same
lines.
C
It
was
a
little
thrown
off
when
maheshu
said
that
you
might
put
an
algorithm
into
the
document
for
interoperability
reasons.
Isn't
the
sequence
number
a
local.
F
Matter
the
when
you
say
local
matter,
meaning
in
terms
of
how
you
secure
the
sequence
number.
F
Yeah,
that
is
local.
The
question
is,
if,
as
part
of
this
draft
a
proposal,
if
you're
trying
to
secure
it
by
using
a
symmetric
algorithm,
then
both
ends
have
to
agree
on
that
algorithm.
B
B
Okay,
let's,
let's
take
that
back
so
the
somewhat
to
john's
point.
B
The
purpose
here
is
to
provide
the
ability
to
do
bfd
security
when
you're
not
actually
doing
signatures
across
the
entire
bfd
packet
you're,
just
trying
to
do
something
that
effectively
from
the
outside
world
looks
like
a
random
set
of
sequence
numbers
and
we're
using
a
crypto
mechanism
to
basically
allow
us
to
generate
what
the
next
sequence
number
looks
like
without
actually
doing
something
as
strong
as
sha2
and
we'd
received
some
feedback
during
the
initial
discussion
phases
about
this
that
there
exist
some
low-level
hashes
that
are
extremely
cheap
to
run.
B
The
challenge
is
once
we
get
to
anything,
that's
too
complex.
We
actually
get
rid
of
the
bone.
The
benefit
of
this
feature,
which
was
intended
to
not
have
to
do
quite
as
much
crypto
and
bfd.
B
Okay,
so
I'll
take
that
back
to
the
mailing
list
and
see
if
we
can
contact
alan
john,
did
you
want
to
respond
to
that
as.
E
F
So,
are
you
saying
after
you
have
generated
the
ciphertext
version
of
the
sequence
number?
No,
it's
that
you
you're
taking
a
monotonically
increasing
sequence,
number
to
begin
with,
and.
E
E
F
All
right,
so
if
there
are
no
other
comments,
then
I
guess
jeff
we're
going
to
take
it
to
the
to
john
and
then
our
mailing
list,
yep.
B
F
So
next
slide.
F
So,
just
like
secure
sequence
number,
this
one
is
also
gone
through
the
shepherd's
review.
F
F
So
the
suggestion
was.
Maybe
it
needs
a
young
model
which
is
next
slide,
which
is
exactly
what
we
added.
F
So
it
essentially
extends
the
idf
yang
model
to
add
iftf
bft
stability
documents
for
each
one
of
the
potential
uses
of
pft.
In
this
case,
what
you're
seeing
is
an
example
for
a
single
up
ip
bft,
where
it's
adding
a
lost
packet
count
a
very
fairly
small
yang
module,
but
it
does
require,
I
guess
now,
a
young
doctor's
review,
which
I
think
richard
has
already
initiated
and
it
also
mis
necessitated
an
update
to
the
ayana
consideration
section
and
the
security
consideration
section.
So
those
were
the
changes
for
this
particular
draft.
F
Well,
good
point:
it's
the
only
thing
that
is
there
in
the
yang
modules.
So
either
you
implement
the
yang
module
and
you
have
the
capability.
I
guess
you
don't.
A
Well,
sorry,
I
didn't
mean
to
keep
in
trouble.
Just
saying
I
mean
if
the
I
mean,
if
you
don't
support,
I
think
what
you
were
implying.
My
ish
was:
if
you
don't
support
this,
then
you
don't
there's
one
counter.
So
if
you
don't
implement
this,
you
don't
that
module
would
not
be
in
the
yang
library
and
all
that
right
and
whereas,
if
you
do
it's
the
only
counter,
that's
what
you
were
implying.
B
I
J
Yeah,
this
is
the
intention
of
this
draft,
because
there
are
some
people
asking
some
questions,
so
we
would
like
to
clarify
those
questions
here,
and
this
is
a
new
use
that
is
not
yet
been
documented
in
the
current
offices
and
the
second
one
is
a
ppi
for
tr
114
6
documented
the
similar
use,
but
in
that
tr
the
detailed
procedural
text
is
not
clear,
and
the
third
point
is
this
draft
adopted
by
pfd
looking
group
last
year
due
to
the
fact
that
this
draft
updates
ifc
58
80
in
many
aspects,
so
the
intended
status
exchange
to
the
standard
track.
J
J
Page
so
the
main
change
from
last
revision.
The
first
point
is
that
add
a
new
session
two
to
list
all
updates
to
rfc
5880.
J
The
second
add
more
details
on
procedures
into
section
3.,
the
third
one
improve
the
section
four
on
the
application
applicability
of
a
uniquely
data.
Bfd
ico
functions
the
last
one
added
a
new
section
8
to
list
contributors,
and
we
move
one
course
to
contribute,
because
the
number
limitation
for
the
courses
next
page.
J
Yeah,
this
page
gives
the
details
updates
to
fc
5880.
So
the
first
point
is
the
bfd
ico.
Functions
is
a
drink
to
bfd,
asynchronous
model
or
bfd
demand
model,
but
it
in
this
chapter
on
a
fleet
kitted
bfd
ico,
removes
this
restriction.
J
J
The
on
afflicted
vfdi
code
removes
this
signaling
procedure
and
the
third
one,
the
bfd
ico
packets,
must
not
be
transmitted
when
bfd
session
status
is
not
up
in
this
draft.
J
J
The
the
maximum
number
the
destination
udp
port
is
cited
to
37
85
and
the
the
the
next
action
the
device
b
will
look
back.
The
received
bfd
ico
packets
by
the
normal
forwarding
wii
without
any
special
processing
and
the
last
step
the
device
a
will
receive
the
the
bfd
ico
packet
and
lead
to
bfd
change.
So
this
is
a
very
simple
procedure.
Next
page.
D
Another
question:
it's
something
I
I
wanted
to
note
and
we
discussed
it
before,
so
the
updates
that
you
are
listed
for
that
this
document
updates
58.80.
D
My
concern
is
that
it
affects
the
security
considerations,
because
the
reason
for
this
restrictions
put
in
5880
to
use
echo
function
was
for
the
remote
ad
and
to
be
able
to
either
regulate
their
rate
of
echo
packets,
transmitted
to
it
or
even
not
to
accept
them
at
all.
So,
for
example,
by
setting
this
value
to
zero,
it
indicates
that
the
remote
pier
doesn't
want
to
receive
any
echo
packet.
D
So
removing
this
and
allowing
to
start
transmitting
echo
packets
without
reaching
the
up
state
during
the
normal
pole
sequence
creates
an
opportunity
for
anybody
to
start
sending,
at
any
rate
packets
to
their
system
bfd
system
that
cannot
handle
it.
D
Yeah
and
to
the
procedure,
so
you
probably
didn't
include
in
the
slide
that,
in
order
to
use
returned
packet,
packets.
D
Your
discriminator
and
progress
the
status
to
up
these
fields
has
to
be
initialized
by
the
sender.
It's
itself.
Oh,
yes,
so,
basically,
the
sender
has
to
set
the
status
to
up
and
send
the
your
discriminator
to
the
locally
assigned
associated
with
this
bfd
session
discriminator
value.
J
Yeah,
so
thank
you
upon
the
outtake.
I
think
it
we
did
not
release
it
in
the
slides,
but
the
content
you
mentioned
now.
We
documented
in
the
draft.
E
Just
a
quick
one:
I've
somewhat
given
up
at
my
own
company
trying
to
get
people
not
to
write
yang
with
a
capital
y
and
the
rest
lower
case,
but
it's
yang
is
is,
is
originally
an
acronym.
So
could
you
please
not
use
that
that
version
of
it?
E
H
I
Up
comments:
we
got
into
greg's
comments.
I
think,
for
this
affinity
pfd
echo
process
this
is,
it
is
totally
transparent
today
to
the
remote
system.
So
it's
just
like
just
like
a
data
packet,
you
don't
know
you
don't
know
any
thing
about
the,
whether
it's
a
bfd
packet
or
a
data
packet
so
same
size.
For
me
as
there's
no
security
issue.
B
So
I'm
going
to
insert
myself
into
the
queue
ahead
of
greg,
potentially
make
the
point
that
greg
would.
It
would
be
normally
a
security
consideration
in
the
sense
that
one
of
the
reasons
we
have
signaling
for
echo
support
is
so
that
the
systems
can
do
regulation
and
also
indicate
their
willingness
to
do
so.
B
J
J
B
Yeah
in
security
terminology,
this
would
be
considered
a
reflection
attack
so
that
that
is
the
thing
that
the
security
considerations
will
need
to
discuss.
Yeah
I
was
dead
greg.
I
have
a
further
point,
but
greg
did
you
want
to
finish
one?
No.
D
Thank
you
jeff.
It
was
very
one
small
note
I
I
wanted
to
mention
in
regards
to
the
reference
to
bdf
document.
D
I
discussed
it
with
their
dbf
and
they're,
not
really
proud
of
this
document
and
what
is
written
there
in
regard
to
the
bfd,
so
they're
not
going
to
revisit
it,
but
they
are
not
advertised
and
not
really
supportive
of.
What's
in
the
document
in
regard
to
bfd
echo
function,.
G
D
Yes,
if
we
can
provide
some
foundation,
I
don't
think
that
there
will
be
any
effort
to
revisit
their
tr
146..
But,
yes,
they
would
appreciate
if
we
provide
more
strict
technical
ground
for
this
mode.
D
No,
no,
I
I'm
referring
to
tr
146
in
the
part
that
discusses
bfd
echo
function,
use
okay,.
B
E
B
Make
one
last
point
and
then
return
the
presentation
back
using
your
own
slide.
One
of
the
discussion
points
that
will
need
to
be
in
the
document
is
that
by
entering
you
know
one
of
the
down
or
in
it
states
that
normally
implies
that
the
bfd
async
mechanism
is
running
and
will
be
generating
packets,
so
part
of
our
procedure.
Changes
that
need
to
be
in
here
is
that
we're
allowed
to
be
in
the
down
state
without
transmitting
packets,.
J
List
yeah,
thank
you
very
much.
So
could
I
go
a
hide
for
the
open
issues.
J
Please
yeah
so
yeah.
We,
there
are
still
two
issues
open
if
possible.
We
hope
to
have
some
discussion
here.
The
first
issue
is
that
printed
version.
J
To
reviews
the
both
statistical
machine
and
the
multiplexing
key,
which
will
simply
simplify
the
implementation.
So
in
this
draft
the
pfdi
code
packet
reuse,
the
bfd
control
packet
format,
so
we
would
like
to
know.
Is
there
some
other
proposal?
J
And
the
second
open
issue
is
that
I
think
at
the
beginning
we
talked
about
the
bfd
model
and,
if
possible,
we
hope
this.
The
mechanism
in
this
draft
can
be
pfdr
model
also,
so,
if
we
decided
to
handle
the
bfdr
model
draft
further,
I
think
we
can
consider
this
point
in
also
thank.
D
D
D
A
B
B
J
Yeah,
I
think
we
can
do
it.
We
can
provide
the
proposal
to
working
group
after
the
meeting
and
let's
see
the.
J
Thank
you
so
next
type,
I
think
we
need
more
reviews
and
comments
and
we've
got
quite
a
lot
of
feedback
and
comments
just
now.
I
think
we
will
revise
this
draft
to
resolve
those
comments
as
well
as
some
further
action
will
be
taken
after
the
meeting,
and
then
we
would
like
to
ask
for
a
working
group
last
fall.
Thank
you.