►
From YouTube: IETF108-BFD-20200730-1300
Description
BFD meeting session at IETF108
2020/07/30 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
Yeah,
so
since
we're
waiting
and
people
seem
to
be
a
little
bit
confused
about
the
controls
at
the
top
left
of
your
screen,
you're
going
to
see
four
icons
left
starting
left-hand
side,
a
tv
screen,
a
camera
and
two
microphones,
the
tv
screen
is
for
sharing
the
screen.
We
will
be
presenting
the
slides
for
the
entire
time,
so
you
should
need
that
you're
allowed
to
send
video
if
you
so
choose
the
microphone
on
the
left
hand,
side
with
the
hand
icon
is
to
request
to
join
the
audio
queue.
A
A
A
A
A
So
our
agenda
is
relatively
light,
we'll
be
going
over.
You
know
some
quick
chair
updates.
The
three
items
that
are
up
for
discussion
is
an
update
on
bft
for
vxlan,
as
is
going
through
last
call
stuff,
and
we
have
two
new
presentations.
A
Well
one
and
a
half
presentations,
one
sort
of
a
partial
repeat
from
a
prior
ietf
session.
One
is
for
bfd
padding
alteration
that
xiaomi
would
be
presenting
and
bfd
unaffiliated
echo
wei
chang
again
pardon
5
is
pronouncing
your
name
in
terms
of
chair
updates.
A
We
have
several
things
that
we're
trying
to
clear
through
general
apologies.
You
know
for
me
specifically
for
being
non-responsive.
Over
the
last
several
months,
I've
had
the
fun
of
the
pandemic,
and
I
also
have
had
surgery
that
was
recovering
from
for
my
knee.
A
So
they
took
me
out
of
the
queue
for
a
little
bit
in
terms
of
actual
work.
Bfd
for
vxlan
still
has
an
open
discussion,
isg
and
I
think
that's
actually
been
resolved.
So
I
believe
the
dash
14
that
greg's
going
to
talk
about
will
likely
address
the
last
set
of
issues
we
can
move
it
forward.
So
we'll
let
greg
update
us
on
that
vfd
for
large
packets
has
gone
through
working
group
last
call
and
is
in
need
of
a
new
revision.
My
intent
is
to
push
the
changes
that
were
requested
last
round.
A
A
A
At
this
point,
we're
still
waiting
for
the
last
sets
of
the
shepard
comments
to
go
through
and
those
can
be
submitted
to
the
isg
as
well.
C
C
On
the
authentication
side
I
see,
santosh
is
here
but
mahesh
isn't
here,
there's
been
no
update
to
the
sequence
numbers
document.
I
believe
we
want
all
three
to
go
together.
Thank
you,
mahesh
and
santosh
for
accommodating
my
my
my
request,
but
we
will
need
the.
We
will
need
the
sequence
numbers
document
to
be
updated.
Also,
before
all
three
can
progress.
A
Okay-
and
I
believe
that
concludes
our
document
status
update.
We
have
a
couple
of
minor
things
that
will
be
taken
care
of
on
the
list
afterwards,
we'll
pause
here
to
see
if
there's
any
further
comments
or
agenda
bashing
before
we
continue
with
the
scheduled
presentations.
D
Thank
you
for
the
update.
I
have
a
question.
We
had
a
discussion
at
our
last
meeting
on
extended
bfd
work,
so
we
sometimes
referred
as
bfd
to
zero.
So
any
update
on
on
that.
A
Yeah,
that
was
one
of
the
ones
I
was
hoping
to
push
off
to
the
mailing
list,
but
no
certainly
we
can
have
a
brief
discussion
here.
A
We
approached
the
isg
specifically
about
what
do
we
want
to
do
about
bfd
2,
or
do
we
want
to
do
bfd2
and
there's
sort
of
two
broad
topics
that
came
up
as
part
of
that
discussion?
For
the
most
part,
question
number
one
to
the
isg?
Was
you
know,
do
they
care
about?
You
know
bfd
as
a
v2
specifically-
and
you
know
much
like
the
rest
of
the
isg
involvement
for
bfd.
Most
of
them
don't
understand
what
we
do
so
they're
relatively
neutral.
A
On
that
specific
point,
the
related
point
of
dfd
v2
is
starting
to
become
a
attraction
point
for
a
lot
of
different
proposals
and,
as
I
sort
of
discussed
during
our
last
session,
where
we
talked
about
bfd2
and
had
our
friends
from
ippm
come
in.
The
point
that
we
actually
had
gotten
discussed
was.
B
A
You
know
they're
not
looking
to
have
their
technologies
embedded
in
the
bfd
and
where
this
really
left
us
was.
The
interesting
question
of
bfd
is
an
interesting
thing.
Much
like
bgp
and
dns
end
up
being
interesting
in
their
own
areas.
It's
a
useful
technology,
that's
well
standardized
for
carrying
stuff
between
two
systems,
and
we
did
actually
offer
to
the
isg
is
one
of
the
options.
No
bfd
has
a
very
nice
constrained.
A
Continuity
check,
type
activity
that
we
want
to
continue
to
optimize,
for
this
is
where
we've
had
our
success.
There's
obviously
interest
in
moving
things
forward
to
using
the
protocol
machinery
for
other
purposes,
and
rather
than
overload
the
well-defined
use.
Perhaps
we
could
consider
spinning
off.
Basically
a
flavor
of
the
bfd
state
machinery
for
more
general
purposes
and
isg
was
again
mostly
silent
on
the
issue,
but
they
seem
to
think
that
that
is
a
perfectly
acceptable
conversation
as
well.
A
My
inclination,
based
on
what
we've
seen
over
the
years
is
we
do
want
to
keep
the
fd
a
nice
tight
protocol
mechanism,
stick
to
the
primary
continuity
check
case,
and
let
us
tighten
our
charter
specifically
for
that
and
if
there's
some
other
group
or
some
other
buff
that
wants
to
spin
off
for
bfd
like
behaviors
as
a
transport
mechanism.
For
other,
you
know
state
information
between
systems.
You
know
we're
certainly
happy
to
help
people
spin.
That
off.
A
E
A
Okay,
being
no
further
comments,
greg,
please
take
it
away.
Okay,
thank
you.
D
So,
as
you
probably
know,
if
you
follow
the
discussion
with
isg,
we
had
a
lot
of
comments.
A
lot
of
discussions
and
several
versions
were
published
to
address
these
comments
next
slide.
Please.
D
D
D
The
next
topic
of
discussion
was
that
we
had
the
text
in
the
document
that
talk
about
the
interaction
between
bfd
and
the
firewall.
If
it's
collocated
with
a
vtec-
and
we
received
a
lot
of
comments
about
it
that
effectively,
we
are
opening
their
door
too
wide
for
it
to
be
exploited
and
agreed
that.
Well,
if
you
have
this
case,
you
can
make
it
work.
D
So
thus
we
remove
this
text.
The
text
was
a
little
bit
too
controversial
and
open
to
interpretations.
We
couldn't
find
agreement,
how
to
keep
it
and
remove
it
related
to
preventing
bfd
control.
Packets
being
leaked
is
a
question
of
destination
mac
address
on
inner
ethernet.
D
Frame,
we
had
gone
to
different
directions,
and
now
we
decided
that
I
will
ask
ayana
for
allocation
of
unicast
mac
address.
D
So
that's
the
only
ayanna.
D
The
choice
of
ip
destination
address
in
an
inner
ip
header.
D
It
was
very
educational
to
me
because
from
ipv4
we
all
used
to
127
8
range
being
used,
especially
in
a
tunnel
case
rfc
5884
or
80
29
and
its
predecessor
mpls
lspt.
So
it's
used
to
prevent
attacking
being
leaked
out
of
mpl
over
tunnel
and
we
usually
map
it
to
ipv6
range,
and
so
I
learned
what
their
correct
characterization
of
this
would
be.
D
But,
interestingly
enough,
ipv6
doesn't
have
a
range
of
loopback
addresses
directly
correlating
to
127
slash,
and
it
has
only
one
loopback
address
officially
defined,
but
what
we
agreed
that
we
can
use
their
correct
characterization
of
ipv6
address
as
ipd4
mapped,
ipv6
addresses
and
still
recommend
to
choose
a
destination
id
address
from
this
range,
and
another
topic
that
we
had
is
the
question
about
their
coverage
of
echo
bfd
mode
in
bfd
over
vxlan.
D
What
I
want
to
point
out
and
stress
is
that
the
use
of
managing
pni
the
document
disc,
describes
operation
and
encapsulation
of
the
bfd
control
packet
over
management
vni.
It
does
not
preclude
any
other
case.
It's
just.
They
are
outside
the
scope
of
this
document.
C
So
greg
one
question
on
the
destination
ip
address:
it
says:
inner
id
header,
that's
outer
id
header
right,
not
inner.
D
No,
it's
inner.
The
loopback
is
used
in
the
inner
id
header,
the
outer
ip
header,
it's
a
tunnel,
so
it
has
to
be
vtep
address.
Oh
yeah,
okay,
yes,
yes,
okay,
okay,
thanks.
D
Okay,
so
a
little
bit
more
in
details
about
management,
vni
and
again,
the
important
part
of
management
vni
that
it's
characteristic,
that
it
has
no
tenants.
D
And
thus
it's
ensures
that
there
is
nowhere
to
send
to
next.
So
at
least.
D
Yeah
destination
ip
address
on
the
inner
ip
header
and
it's
recommended
to
be
chosen
from
127,
slash,
eight
range
or
ipv4
map.
Ipv6
range.
D
So
I
understand
that
bfd
echo
mode
over
vxlan.
We
already
have
like
indication
of
no
interest
in
it
and
the
destination
mac
address.
The
current
text
is
that
it's
ayana
action
and
we
are
asking
to
allocate
a
unicast,
eui,
48
mac
address.
D
So,
as
jeff
said,
there
is
a
understanding
that
at
least
all
the
comments
that
were
open
and
questions
after
the
first
iig
being
addressed,
and
I
hope
that
we
are
ready
for
the
second
round.
Thank
you.
G
G
You
have
the
microphone.
Thank
you,
matthew,
botch,
you're,
not
here,
just
a
quick
question
greg.
If,
whether
or
not
you
we
had
this
discussion
in
mvo3
with
the
bfd
over
geneva,
about
sharing
fate
between
the
bfd
packets
and
and
the
the
packets
on
the
other
vni's,
I'm
just
wondering
if
that
issue
had
come
up
at
all
in
this
discussion
about
use
for
management
vni
in
the
vxlan
case.
D
Right
so
again,
what
this
specification
describes
is
the
vxlan
tunnel
continuity
check.
So
it's
not
a
specific
vni
case.
Their
current
vni
is
outside
the
scope
of
this
document
so
effectively.
D
If
using
management
vni,
we
are
monitoring
that
there
is
a
way
of
getting
from
vtep
a
to
v
b,
whether
we
explore
all
possible
paths
that
exist
in
overlay
network.
No,
this
specification
does
not
define
that.
It
just
defines
that
again.
That's
what
continuity
check
is,
so
it
verifies
that
there
exists
a
path
between
two
systems.
G
Yeah,
I'm
in
principle,
I'm
okay
with
that.
It's
just
that
you
may
have
situations
where
bfd
goes
down
because
of
the
way
that
the
bfd
that
vni
is
hashed,
but
there
is
still
continuity
for
effectively
if
you,
if
you
happen
to
be
on
a
different
vni.
So
I
mean
this
problem
comes
up
all
over
the
place
to
be
honest
when
using
bfd
over
ldp
and
all
sorts
of
other
cases
where
you've
got
ecmp.
And
it's
I'm
just
wondering
if
it's
worth
saying
something
in
the
draft
about
about
that.
D
Yeah,
we
probably
again,
I
agree
it's
it's
it's
interesting
problem
and
we
probably
will
be
addressing
it
more
in
geneve
document,
yeah,
okay,.
D
Well
again,
because
we
define
the
management
vienna
as
vni
that
doesn't
have
tenants
by
itself
it
it's
a
restraint,
ensures
that
there
is
no
one
to
send
to
so
it's
by
by
the
way
it's
configured
and
provisioned
on
vtab.
D
We
recommend
to
use
vni
one,
but
it's
an
operator
that
can
choose
any
particular
dni
number.
Just
then
to
maintain
its
tenant.
Three.
A
Right
and
as
the
shepherd
for
the
document,
a
big
portion,
what
greg
is
discussing
matthew
is
the
fact
that
we
did
have
the
document
in
a
much
more
general
shape
for
a
very
long
time.
Where
you
know
one
or
more
bfd
sessions
could
be
testing.
You.
H
A
Individual
vnis,
rather
than
you
know,
reachability
between
vteps
and
a
significant
portion
of
the
isg
feedback
and
pushback
ended
up
being
security
considerations
over
how
that
impacted,
individual.
You
know
tenant
systems.
What
do
you
set?
The
mac
addresses
to
make
sure
that
you
don't
you
know,
collide
with
the
tenant,
no
space
tenant
ip
addresses
and
as
anybody
who's
used
to
operating
those
sort
of
systems
is
where
that's
very
much
a
question
of
provisioning
and
cooperation
with
the
tenants
to
make
sure
that
those
things
are
set
up
appropriately.
A
So
there
there's
some
extent
obvious
to
the
people
operating
the
systems.
What
you
should
do,
but
trying
to
put
it
into
a
generic
enough
fashion
that
the
isg
management
was
willing
to
say
that
the
security
considerations
were
sufficiently
discussed
was
simply
not
happening
and
therefore
yeah.
We
took
the
spec
back
to
test
to
the
management
vni
which,
to
some
extent,
were
effectively
defining
in
this
document,
since
there
seems
to
be
no
rfc.
A
And
it's
worth
noticing
that
the
bfd
for
geneve
document
probably
should
get
a
serious
update
once
we
finish
with
vxlan,
because
every
single
one
of
those
considerations
will
pop
up
again.
D
Actually,
since
I'm
like
cross
on
both
and
xiaomi
ii,
so
we've
been
so
he's
the
lead
offer
on
on
bfd
fujinir.
But
we've
been
communicating
and
I
was
updating
him
on
a
discussion
of
bfd
over
vxlan
and
the
changes
that
have
been
applied.
A
H
Okay,
hello,
everyone,
it's
xiaomi
here,
this
presentation
is
a
bfd
pairing
alteration
and
this
is
a
zero
zero
version.
Draft
next
slide.
Please.
H
H
H
H
H
H
H
H
The
padding
post
sequence
in
one
direction
is
independent
of
the
pad
input
sequence
in
a
reverse
direction,
and
note
that
the
packet
size
of
padding
response
would
follow
the
size
of
the
scheduled.
We
have
the
periodic
packets,
if
padding,
pull
sequence
fails
at
one
side
or
both
the
bfd
session
remains
running
and
that's
the
main
purpose.
H
H
I
Okay
from
vmware,
so
when
we
say
that
we
want
to
use
poll
and
final
sequence,
how
long
do
you
think
it
will?
You
know,
use
the
poland
final
sequence,
the
reason
being
that
you
know
once
we
have
this
poll
and
final
dfd
packets
are
not
absorbed
in
hardware
anymore.
It
has
to
go
to
the
state
machine
in
the
software
right.
So
what
is
the
thought
process
on
that.
H
Tell
me
the
timing
for
the
power
sequence.
H
I
C
I
follow
up
to
that
question
is
so
what
you're
basically
saying
is
when
you
would
basically
send
the
schedule
packet,
and
on
top
of
that
you
would
send
a
larger
packet
with
a
pulse
sequence.
So
if
your
interval
is
10
milliseconds,
so
you
would
send
that
extra
packet
until
that
whole
sequence
was
resolved
until
you
got
the
f
bit
back
yeah.
C
So
I
guess
the
question
concern
is,
I
think
some
implementations
may
have
policers,
so
some
implementations
may,
because
you
have
a
contract
where
you're
saying
you're
going
to
be
sending
one
packet,
every
10
milliseconds
with
you
know,
85
jitter
or
whatever
it
is,
and
now
you're
going
to
be
sending
more.
So
you
you
may
see,
drops
of
the
fd
packets.
C
H
I
I
think
extra
extra
padding
pole
can
be
sent
more
than
once,
just
like
a
normal
pole
packet.
A
Okay
to
interject
a
comment
before
greg
takes
the
microphone
vfd
polling
sequences.
The
protocol
procedure
is
that
as
long
as
you're
receiving
the
pull
bit,
you
will
continue
sending
the
final
bit
until
you
stop
seeing
the
pull
bit.
So
this
does
mean
that
we
don't
have
to
see
a
small
number
of
packets
with
this.
D
You
have
the
microphone.
Thank
you.
Well,
I
understand.
The
idea
of
using
the
pro
is
that
frequency
of
the
pole
will
be
very
relaxed
and
as
a
one
packet
per
second,
so
it
should
not
add
significant
number
of
packets
to
their
fast
session,
like
which
might
have
a
10
millisecond
interval
for
their
asynchronous
mode.
A
A
A
So
if
there's
a
consideration
about
changing
the
packet
for
the
bits
per
second
range
and
interactions
with
other
systems,
there's
some
concern
there.
That
said,
one
of
the
things
the
bfd
large
document
does
mention
is
that
you
may
be
able
to
support
fewer
sessions
because
you've
changed
the
scaling.
Because
of
this,
what
that
would
mean
for
the
proposal
that
xiao
is
giving
is
that
it
may
be
necessary
to
change
the
negotiated
session
speed
in
such
circumstances
before
you
actually
start
probing
for
the
large
size.
C
H
H
So
I
think,
if,
if
I
change
the
vfd
package
size
with
the
periodic
bft
package,
then
maybe
that
will
cause
the
pfd
session
go
down.
C
A
And
I
have
a
final
comment:
this
is
speaking.
It
was
the
one
of
the
authors
of
the
large
document,
so
I
think
what
you're
partially
showing
is
that
you're
providing
a
mechanism
by
which
we
could
negotiate
large
packets?
This
was
one
of
the
open
discussion
points
that
had
come
up
from
the
working
group
last
call.
A
Excellent-
and
I
I
think
the
final
comment
along
those
lines
is
use
case
driven.
This
is
where
I'm
providing
the
outlook
that
albert
liu,
you
know
my
co-author
has
on
what
the
need
for
this
feature
is.
There
will
be
some
customers
that
will
be
happy
to
allow
this
to
be
a
negotiated
feature,
and
then
there
will
be
users
of
the
feature
that
require
this
to
be
on,
and
the
session
must
immediately
fail
if
large
packets
does
not
work.
So
part
of
our
discussion
point
for
the
working
group
is:
what
does
this
look
like?
B
Okay,
so
thank
you.
Could
you
hear
me.
E
E
The
intention
of
this
draft
we
would
like
to
propose
a
use
case
for
bfd
ico
function.
It's
a
new
use
case.
That's
not
yet
been
documented
in
some
other
current
rfcs
and
the
pbf
tr
1v4
have
some
similar
use
case.
Vfd
ico
function,
proposal
to
in
this
draft,
but
in
that
tr
the
procedural
tax
is
a
little
bit
unclear.
E
E
So
this
is
the
text
in
pbf,
tr
146
use
cases,
and
it's
just
given.
It
should
be
noted
that
the
vfd
icon
mechanism
is
only
suitable
to
detect
and
recover
from
the
loss
of
ipv4
the
connectivity
between
the
rg
and
the
iph
as
a
observered
and
detected
by
the
rg
next
page
we
will
show
detail
in
the
tr
146
next
page,
so
here
we
list
some
text
from.
E
E
So
the
proposal
described
in
this
page
the
device
a
supports,
bfd
still
machine,
which
is
a
down
to
issued
to
app
the
device.
A
sending
the
bfd
iq
packets
to
device
b
with
ip
address,
testing
needed
for
itself.
E
E
So
here
we
give
deploy
the
use
case
in
channel
mobile's
network,
that
is
in
our
data
center.
E
You
know
now
a
lot
of
operators
have
begun
to
deploy
5g
network
and
the
5g
core
network,
which
will
be
deployed
in
the
telecom
infrastructure
crowd,
and
we
have
to
guarantee
the
high
reliability
in
the
data
center
that
requirement
even
higher
than
the
normal
data
center.
So
in
this
case
we
use
the
solution.
E
E
We
can
monitor
the
link
between
data
center
gateway
and
the
virtue
machine
that
may
be
ovis,
something
like
that
word
to
switch.
You
know
the
virtual
switch
located
in
the.
E
So
that
is
the
first
purpose
and
the
second
one
is
that
we
often
use
different
vendors
component
in
one
data
center,
such
as
the
dc
gateway,
maybe
from
a
vendor
and
the
server
or
the
ovs
system
from
another
vendor.
If
we
wanted
to
set
up
the
whole
solution
and
the
support
such
as
bfd,
we
need
have
a
inter-operation
test
between
the
data
center
githui
and
the
ovis,
and
it's
often
very
hard
because
there
are
many
different
vendors
support,
the
provider
to
different
systems.
E
E
Yeah
next
step,
we
ask
for
more
reviews
and
comments
and
then
we
ask
for
working
group
adoption.
That's
all
you
permission
draft.
A
Okay,
quick
comment:
we
are
your
top
of
our
session.
We
get
kicked
out
very
quickly,
so
we
need
to
keep
these
somewhat
brief.
Rakesh.
You
have
the
microphone
please
state
name
and
affiliation.
J
J
So
it's
it's
interesting
to
see.
Bfd
has
a
similar
proposal.
One
question
I
had
is:
does
it
mean
we
would
update
the
procedure
for
bfd
and
defined
in
58
80?
Is
it
like?
There
is
no
point
there?
No
inject
then,
but
bfd,
responder
or
reflector
is
designed
certain
way.
So
does
it
mean
we
defy
the
base
rfc.
E
Yeah,
so
thank
you
for
your
comments.
I
I
I
think.
As
I
know,
there
are
some
solution
based
on
to
app
also,
but
here
I
think
we
don't
need
to
change
any
bfd
solution
in
the
local
server
and
we
also
don't
need
to
change
any
functions
in
remote
peer.
E
So
I
think
we
we
just
have
some
configuration
for
the
vfd,
the
the
bfd
control
packet
with
itself.
E
E
A
And
if
I
might
interject
since
we're
a
little
low
on
time
prior
discussion
when
we
had
this
proposed
the
first
time
a
couple
ideas
ago,
this
is
a
very
odd
document
at
the
pdf
level,
just
because
we
are
not
really
using
bfd
in
here,
there's
no
state
machine.
This
is
strictly
the
echo
function
that
may
or
may
not
actually
have
a
bfd
implementation
at
the
back
end
doing
the
work
of
generating
this
echo
traffic
so
request
your
questions
valid.
Does
this
really
update
efd?
A
I
think
the
proposal
we
have
here
versus
the
one
from
bbf
is
that
we
are
intentionally
talking
about
there's
a
a
bfd
state
machine
on
the
local
side
that
can
actually
handle
han
the
echo
stuff.
If
that's
the
way
this
document
proceeds,
this
would
be
an
update
to
5880.
J
A
D
Okay,
thank
you.
I
I
would
suggest
to
clarify
one
thing
related
to
the
multiplexing
bfd
sessions
on
a
sender
receiver.
D
I
think
that
since
it
uses
a
well-known
udp
port,
so
it
my
understanding
is
it's
expect
to
receive
the
bfd
packet.
So
I
think
it
what's
logical
is
that
the
system
assigns
discriminator
to
this
session
and
then
puts
this
value
in
your
discriminator
packet
that
it
transmits.
D
So
I
I
look
at
the
document.
I
didn't
find
it
in
a
document.
I
think
that
it
will
be
helpful
to
clarify
that
part
of
the
process.
F
The
next
one,
I
think,
is
jigen
hi.
This
is
jacon
from
cisco.
I
have
a
small
clarification
here
is
this:
is
this
looks
like
same
as
sbfd
functionality
like
which
can
loop
on
the
receiver
side?
Is
that
what
we're
trying
to
do
here
or.
D
If
I
can
greg
nursky
zt
again,
in
my
opinion,
it's
not
because
sbfd
sends
the
packet
to
their
remote
site
which
advertised
its
discriminator,
and
it
could
be,
for
example,
learned
through
the
igp
extension
and
effectively
the
remote
side
receives
this
packet
and
sends
it
back.
So
my
understanding
of
this
proposal
is
that.
D
The
loopback
works
on
the
transport
layer,
so
there
is
no
reception
of
the
packet
at
the
remote
side.
F
Yes,
actually
even
spfd,
there
is
a
similar
thing.
What
I've
said
right?
It
need
not
to
go
to
the
control
plane.
It
could
be
a
look
back
in
the
data
path,
so
we
have
another
kind
of.
H
It's
xiaomi
here,
I'm
co-author
of
this
job.
I
want
to
clarify
that
answer.
Brexit
question.
I
I
think
you're
right
this
bfd
echo.
It
is
actually
a
vfd
control
package.
H
So
if
you
use
discriminator
to
multiplex
the
received
the
echo
packets
and
to
a
pfp
session,
so
I
think
yeah,
it's
a
it's
a
bit
different
with
the
current
to
appear
vehicle,
defining
fc
5880,
but
the
state
machine
and
the
vfd
control
package
are
all
the
same
to
that.
Fc.
D
I
would
still
consider
that,
if
you're
running
multiple
sessions
like
this,
you
want
to
de-multiplex
them
and
if
you
receive
them
as
bfd
packets,
because
your
transmitting
nodes
is
a
receiving
node
at
the
same
time.
So
I
would
expect
it
will
be
listening
on
this
udp
port
and
wants
to
demultiplex
the
bfd
packets
and
if
you,
if
we
follow
the
pfd
process,
so
the
multiplexing
happens
on
your
discriminator
value.
So
I
think
that
this
your
discriminator
can
be
locally
assigned
to
this.
D
B
A
Yeah
we're
going
to
have
to
cut
the
microphones
because
we
are
just
about
out
of
our
time
or
five
minutes
over
and
the
tool
will
kick
us
out
in
three.
What
I
would
suggest
at
this
point
in
time
is
there's
obviously
a
lot
of
interesting
discussion
in
this.
Just
thank
you.
So
the
feature
from
the
tool
starter
hum.
If
you
have
interest
in
issuing
the
working
group
adoption
call,
you
know
immediately,
please
respond
positively
to
the
hum,
and
we
will
take
this
to
the
mailing
list
as
well.
A
Okay,
so
the
response
of
the
hum,
assuming
that
people
understood
what
was
happening,
is
come
out
as
pianissimo,
which
is
very,
very
quiet.
A
So
what
we'll
do
is
we
will
take
this
to
the
mailing
list
and
continue
discussion
there.
Okay,
okay,
thank
you.
A
Thank
you,
everyone
and
we'll
send
out
minutes,
hopefully
fairly
soon,
please
contribute
to
them
and
we
will
talk
to
everyone
soon
in
the
mailing
list.
Thank
you.
Bye,
bye,
bye,.