►
From YouTube: IETF112-LSVR-20211109-1430
Description
LSVR meeting session at IETF112
2021/11/09 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
Okay,
we
are
on
top
of
the
hour.
I
see
we
have
at
least
the
first
speaker
here.
We
have
our
error
director
here,
so
I
think
we
can
start.
We
only
have
60
minutes,
so
we
better
get
started.
You
know
and
not
lose
too
much
of
everybody's
valuable
time
here,
so
welcome
to
link
state
vector
routing
working
group,
so
we
didn't
meet
at
the
previous
itf
meeting,
but
we
decided
to
to
meet
right
now.
A
As
everybody
has
noticed,
the
working
group
itself,
the
email
list
has
not
been.
You
know
the
most
active
one,
so
I
think
you
can
count
most
of
the
emails
of
you
know
of
each
month
on
a
single
hand,
which
is
a
little
bit.
You
know
unfortunate
anyway,
so
here
we
are
so
we
don't
really
need
the
javascript,
because
we
have
our
texting
tool
within
the
mig
tool
so
which
is
directly
attached,
which
is
very
nice
for
minutes.
A
As
I
mentioned,
it
would
be
very
appreciated
if
people
you
know
who
actually
are
attending
here
to
t
you
know
to
help
taking
minutes
here.
If
we
make
this
a
collaborative
effort,
it
will
make
it
easier.
For
you
know,
for
for
everybody
and
for
the
chairs
to
collect
the
minions
at
the
end,
and
you
know
we'll
reduce
the
burden
for
a
single
person
to
take
notes
before
we
go
on.
Let's
also
have
be
aware
of
the
note.
Well
by
now
you
should
have
seen
it
already
a
few
times.
A
A
A
I
know
at
this
point
in
time,
as
I
understood
it's
actually
almost
ready
for
for
for
release,
which
is
a
good
thing
and
then,
at
the
last
topic
here
we're
going
to
discuss
a
little
bit
on
what
are
going
to
be
the
next
steps.
You
know
for
the
working
group
itself
once
we
have
delivered
the
bgp
link
state
short
spot
routing
document
towards
the
iesg.
A
Okay,
perfect,
so,
if
you
look
into
where
we
are
with
our
documents
here,
so
we
had
two
documents
which
went
to
working
group
lost,
call
the
ad
reviewed
them
and
they
sent
them
back
to
the
working
group
for
updates
the
bhp
spf
one
has
been
updated
based
upon
the
feedbacks
here.
We
are
now
at
release.
15.
A
B
A
D
B
B
E
A
Seeing
slide
5
here
at
this
point
in
time,
so
the
bgp
spf
draft
13,
which
was
released
in
the
beginning
of
the
year,
has
been
further
updated
to
release
15,
where
we
are
right
now.
Also
the
routing
area
directorate
reviewed,
the
earlier
versions
and
the
feedback
of
that
review
got
into
version
14,
which
was
you
know,
now
updated
to
release
15,
also,
which
is
going
to
be
discussed
by
cure
the
applicability
draft.
A
So
the
version
7
was
reviewed
by
our
area
director.
He
had
like
a
long
list
of
updates
on
that
one.
Those
updates,
were,
I
think,
processed
by
the
authors
of
this
draft
and
release.
Eight
actually
came
out
of
that.
As
a
result,
now
I
did
a
diff
between
seven
and
eight
and
it
seems
to
be.
You
know,
inconsistent
with
the
big
number
of
comments
from
our
era
director
and
the
updates
to
the
draft.
So
I'm
not
really
sure
you
know
what
actually
you
know
what
exactly
happened
there.
A
Now,
then,
we
also
have
our
l3dl
drafts,
which
has
been
progressed.
They
have
been
all
been
refreshed
on
the
14th
of
october,
which
is
very
good.
These
drafts
are
now
a
little
bit
in
a
pending
state
because
it
would
be
very
good.
You
know
to
you,
know,
to
keep
working
on
them,
but
we
can
only
progress
them
further
after
we
have,
you
know
fully
confirmed
with
our
recharge
ring
to
actually
keep
them
into
the
you
know
to
bring
them
into
the
charter
of
our
working
group
here,
mainly
because
there
is
a
similar-ish.
A
A
A
C
C
C
We've
also
provided
a
clarification
on
spf
backing
update
message
for
the
nlris
chances
are
very
high
that,
because
bgp
attributes
are
going
to
be
very
prefix
specific
that
the
update
may
only
carry
in
lot
of
cases.
A
single
prefix
should
not
affect
anything
considering
and
knowing
that
number
of
prefixes
in
underlay
are
always
going
to
be
smaller,
but
we've
nonetheless
made
the
clarification.
It
doesn't
guarantee
that
the
packing
will
not
carry
more
than
one
update,
so
the
text
is
added.
C
We've
also
ensured,
with
an
appropriate
text
clarifying
that
only
one
status
tlb
is
to
be
advertised
in
a
given
update
message.
Knowing
that
the
status
tlv
is
common
for
link
attribute
node
attribute
and
the
prefix
attribute
also
beefed
up
error
handling
section
with
regards
to
the
status
dlv
to
ensure
only
one
of
the
status
tlb
is
carried
in
the
uptick
message
next
slide.
Please.
C
Also,
in
the
best
part,
algorithm
selection,
which
is
an
spf
algorithm
here,
we
have
provided
clarification
of
handling
of
ecmp
next
talks,
although
this
is
very
implementation
dependent,
but
it
always
makes
sense
to
get
to
a
deterministic,
ecmp
selection.
So
the
way
to
get
there
is
first
of
all.
The
next
stops
should
be
bounded
to
number
of
ecmps
that
are
configured
on
the
router
once
you've.
Bounded
number
of
next
stops
to
the
number
of
ecmps,
always
a
numbered
link.
C
Next,
stop
is
preferred
over
an
unnumbered
next
stop
and
when
you
are
looking
at
number
link
highest
address
on
the
number
link
as
well
as
highest
remote
identifier
on
the
unnumbered
link
is
always
preferred.
This
will
always
ensure
deterministic
next,
stop
selection.
That
will
be
done
for
the
ecmps
yeah
next
slide.
Please.
C
C
So,
on
the
numbered
link,
we've
said
that
the
link
descriptors
must
have
to
share
v4
or
a
v6
subnet
for
a
link
to
be
considered
as
a
matching
link
on
an
unnumbered
link.
The
current
links,
local
identifier,
must
match
remote
nodes
link,
remote
identifier
and
vice
versa.
The
current
links,
remote
identifier,
must
match
the
remote
node
links
local
identifier.
C
Also
added
error
handling
text
for
particularly
ipv4
prefix
length,
dlv,
where
you
say
that
any
length
error
in
prefix
land
tlv,
particularly
for
ipv4,
must
result
in
first
the
dropping
of
the
tlb.
Then
you
ensure
that
the
corresponding
node
nlri
is
also
considered
as
an
error,
and
you
do
not
advertise
it
further.
You
drop
it,
furthermore,
is
ensuring
also
that
in
corresponding
link,
nlri
is
considered
as
malformed
and
must
handle
as
a
treat
as
withdrawal.
C
So
the
link
error
handling
text.
I'm
sorry
the
prefix
length,
tlv
error
handling
text
has
been
also
beefed
up
to
make
sure
that
the
appropriate
error
handling
is
done
for
its
associated
node
nlri,
as
well
as
the
link
in
our
array,
and
there
were
some
minor
needs
that
we
had
fixed
in
the
draft
as
well.
C
Thank
you.
Here's
the
diff
on
the
version
13.,
both
version
13
and
version
15
came
out
after
the
implementation
were
pretty
much
done
and
they
have
been
incorporated
in
implementation
as
well
in
version
13.
Of
course,
we
had
received
80
comments
that
we
had
in
incorporated.
We
had
beefed
up
error
handling
to
great
extent
security
section
was
added.
We
clarified
the
interaction
and
relationship
to
bgpls
again
and
htlv's,
compared
to
bgps
pf
safety.
C
Overall
clarification
text
provided
and,
of
course,
the
spf
section,
which
is
pretty
much
an
implementation.
Specific
section
was
augmented
to
provide
a
very
detailed
description
of
of
how
the
best
part
selection
should
go
for
yeah
next
slide,
please
so
after
and
after
version
13
and
after
version
15,
the
overall
status
summary
of
the
draft
is
as
follows.
C
C
C
C
We
request
the
chairs
at
this
point
that
we
feel
draft
is
in
a
very
stable
state,
with
an
implementation
such
so
that
the
chairs
we
do
request
the
chairs
to
complete
the
last
call
and
progress
the
draft.
Last
but
not
least,
we
have
multiple
implementations
on
this
there's
one
open
source
implementation
also
been
made
available
on
there
for
our
on
in
fr
itself.
C
A
A
C
A
C
A
E
E
In
existing
egpsf
lighting
procedure
for
rr
model,
pgp
speaker
will
send
its
link
states
to
every
rooted
reflectors
after
receiving
these
link
states,
every
router
reflector
will
send
the
link
states
to
the
other
bgp
speakers,
for
example,
in
this.
In
this,
in
this
figure,
node
a
will
send
its
link
space
to
both
r1
and
r2
r2
off.
Are
these
two
router
reflectors
after
receiving
the
link
states
from
node
a
they
will
send
the
same
link
states
to
node,
b
and
c.
E
E
E
Al
through
four
sessions
so
first
session
from
a
to
b
and
then
second
session,
also
from
a
to
b
and
then
the
third
session
is
from
a
to
c
and
then
the
fourth
session
is
from
a
to
d
and
then,
after
receiving
these
things,
states
the
answer.
Those
were
to
the
similar
scenes
where
fl
will
send
those
links
space
also
along
the
surgeons.
E
E
So
revise
revised,
plotting
procedure
in
ir
model,
so
in
this
revise
the
procedure,
bgp
speaker
will
only
send
its
link
states
to
sum
of
root,
reflectors
and
then
after
receiving
listening
states.
So
these
root
reflectors
will
send
the
link
states
to
the
other
pgp
speakers.
For
example,
node
a
will
only
send
its
unique
space
to
only
one
rooted,
reflected
ir1,
for
example,
and
then
r1
after
receiving
the
link
states
from
node
a
it
will
send
that
that
links
it
to
b
and
c.
E
E
E
E
So,
with
this
flooding
topology,
every
node
will
send
the
link
states
to
the
peers,
which
is
connected
by
link
on
the
flooding
topology
or
say
we
just
do
the
flooding
along
the
flooding.
Topologies
is
not
where
we
are
mounted
to
the
flooding
along
the
real
flag,
topologies.
For
example,
on
the
left
side,
we
have
a
flooding
topology
for
the
real
electrical
topology
on
the
right
side.
E
So
when
node
a
consider,
one
of
these
is
link
is
know.
The
way
will
only
send
is
the
link
states
for
this
link
along
the
flooding
topologies,
so
node
a
will
only
see
the
two
copies
of
its
link.
Space.
One
is
along
the
link
on
the
flood
property
from
a
to
b
and
then
the
other
one
is
from
a
to
d.
This
is
along
the
larger
homology
from
a
to
d.
E
So
so
this
we
can
see.
So
the
blue
blue
arrow
illustrates
the
flooding
along
the
flooding
topologies.
We
can
see
that
the
amount
of
flood
link
state
flooding
using
this
a
revised
procedure
is
reduced
a
lot
compared
to
the
normal
vlogging
procedures.
We
we
talked
about
in
the
previous
slides
next
page.
E
So
this
page
just
describes
our
procedures
or
algorithms
for
computer
flooding
topology
for
sp
for
ptp
spf,
so
this
algorithm
is
similar
to
the
one
in
itp
flooding
topological
computation.
So
the
only
difference
is
that
we
consider
some
special
attributes
in
bgp
spf.
So
this
difference
is
highlighted,
highlighted
here.
So
in
bgp
spf
we
have
some
node
which
do
not
support
transit.
So
we
so
in
this
algorithm
we'll
consider
this
a
special
case
so
for
for
the
nodes
which
do
not
support
transit.
E
So
we
will
consider
that
one
in
the
leader
election
so
we'll
we
will.
We
shouldn't
elect
the
leaders
that
doesn't
support
transit.
So,
in
addition,
so
when
we
compute
the
flooding
technologies,
we
will
minimize
the
connections
to
the
node
that
do
not
support
transit.
So
that's
the
only
difference
compared
to
the
one
in
the
idp,
flooding,
topology,
computation,
algorithm
next
page.
E
So
proper
extensions,
so
this
product
extension
just
is
quite
similar
to
the
one
in
in
igp
flooding
reduction,
so
as
maybe
some
kind
of
a
difference,
for
example,
because
we
have
different
mode
in
bgp
spf.
So
we
have
a
special
one
for
bp
spf
flight
reaction.
So
why
is
a
node
flat
plv?
So
this
tlv
contains
a
flood
behavior
field,
so
this
field
will
indicate
the
behavior
network
node
will
take
for
flopping.
E
So,
for
example,
number
one
indicate
that
network
node
will
send
the
link
states
to
the
root
reflector
with
the
minimum
node
ids,
so
number
two
will
indicate
the
load
will
send
link
states
to
the
rr,
with
maximum
node,
ids
and
so
on.
So
the
leader
root
reflector
will
use
this
trv
to
tell
every
node
how
to
flood
its
link
states.
So
next
page.
E
E
This
tlv
also
contains
a
field
for
algorithm,
so
this
algorithm
is
a
number,
so
it's
mean
zero
means
centralized
computation
of
for
following
topology
if
it's
non-zero,
which
means
that
its
algorithm
will
be
used
by
every
node
to
compute
flooding
topology.
So
leader
load
will
use
this
field
to
tell
every
node,
with
either
centralize
the
flight
interpreter
computation
or
indicate
the
algorithm
evernote
will
be
used
to
compute
its
own
flight
topology
next
page.
E
E
So
node
id
prv,
so
this
node.idtlv
is
used
in
the
centralized
mode,
so
this
trv
contains
a
number
of
node,
ids,
first
load,
id
segment,
id
and
so
on
and
also
contains
a
starting
index.
So
this
information
provides
a
map
node
id
first
one
id
has
index
starting
index.
The
second
node
id
has
a
starting
index,
plus
one
and
so
on.
So
this
is
a
node
id
to
know
the
indexing.
E
E
E
E
C
Yeah,
this
is
kev
patel
arkis,
a
quick
question:
how
does
this
work
with
partial
implementations?
So
if
you
have
a
network
with
two
route,
reflectors
in
your
previous
slide
that
you
had
with
three
nodes,
if
only
one
route
reflector
implements
this
extension
or
one
of
the
three
nodes
implement
this
extension,
how
does
this
still
work.
E
Yeah,
that's
a
good
question,
so
we
can
consider
the
the
normal
case
right.
The
load
connection
model.
So
if
some
of
some
of
the
nodes
in
the
network
have
these
features,
multiple
action
and
the
rest
of
or
some
of
the
only
support
flight
direction,
so
that
will
is
okay
because
on
the
node
with
flooding
reduction
and
then
they
just
flatter
on
the
subset
of
lighting
topology.
So
when
those
linguists
reach
to
the
node,
the
donor,
support
and
then
those
of
the
world
or
send
the
needs
to
every
node
connect
to
itself.
G
G
You
know,
sparser
sessions,
you
know,
depending
on
how
much
redundancy
you
want
now
what
you're
doing
with
the
two,
with
with
selecting
only
one
rr
for
groups
and
making
sure
all
those
cases
that
may
be
enough,
rather
than
going
the
whole
ball
of
wax
and
supporting
many
different
algorithms
like
we're
doing
in
the
igp
centralized
and
distributed
I'm
thinking
that
might
be
be
going.
I
can't
even
think
to
what
that
does
to
bgp.
But
that's
just
my
comment.
I'm
thinking
just
focus
it
you
know
have
maybe
have
have
have
those
case.
G
G
It's
very
similar,
but
I
think
it
could
be
it's
pretty
complex.
I
mean
just
I
think,
just
getting
you
know
getting
it
getting
it
implemented.
We
have
two
implementations
now
getting
that
implemented.
Then,
if,
on
top
of
that,
if
somebody
did
the
extensions
to
support,
you
know
selection
of
one
route
reflector.
That
would
take
you
a
long
ways.
I
mean
you
already
got
a
pretty
sparse
and
you
and
you
handle,
and
you
also
handle
the
cases
where
connections
are
lost.
I
mean
you
probably
have
the
the
two
route
reflectors.
G
Of
course
they
they
need
to
peer
with
one
another,
and
that
needs
to
be
reliable,
but
other
than
that,
I
think
I
mean
I.
I
don't
know
that
you
need
this
whole
framework
and
you
you
know
you
wanna,
you
wanna
be
able
to
run
around
the
block
before
you
attempt
the
boston
marathon
and
set
this
whole
thing
up
with
the
dynamic.
You
know.
Look
at
how
long
we've
been
doing
things
in
in
igps
right.
A
Yeah
and
and
then-
and
me,
you
know
speaking
of
the
participant
here,
so
I'm
not
sure
also
that
the
floating
dynamics
of
this
php
spf
is
similar.
You
know
it's
similar
enough
to
what
we
are
seeing
in
the
igp
app
because
in
the
igp
world,
we're
not
really
relying
upon
reliable
sessions
here
to
send
the
updates
over.
H
E
E
H
H
I
I
Okay,
all
right
thanks
I'll,
go
ahead
and
jump
in
and
try
to
get
quick
move
quickly
for
discussion.
So
this
is
a
an
update.
Again.
I've
done
a
few
in
the
past
which
I'll
talk
about
this
as
a
start
out
as
disclaimer.
Here
since
I'm
talking
about
an
ieee
standards
activity.
I
need
to
point
out
that
the
this
is
my
own
personal
view
of
that.
I
I've
been
obviously
participating
in
that,
but-
and
I
think
my
view
is
accurate,
but
it
is
my
view
not
position
of
the
standards
board
here,
so
obligatory
slide.
So,
first
of
all,
we
were
motivated
by
the
requirements
of
l3dl
and
other
use
cases
I
think,
like
idr
and
some
others,
that
there
was
a
need
to
update
lldp
to
allow
the
sharing
of
more
than
one
frames
worth
of
information.
I
So
I'm
referencing
some
previous
presentations
where
we
went
through
that
requirements.
Discussion
and
frankly,
it
was
time
to
do
an
update
to
lldp,
and
we
know
that
lsvr
had
had
evaluated
lodp
as
a
potential
transport
for
sharing
bootstrapping
information
and
it
wasn't
sufficient-
and
this
was
one
of
the
key
issues.
I
So
anyway,
we
proposed
to
fix
that
if
you
will-
and
we
started
a
project
in
802.1
called
802.1
abdh
that
was
intended
to
allow
support
multi-frame
protocol
data
units
in
lldp.
So
I
have
a
link
here
to
the
project
page.
If
you,
you
know,
you
can
track
all
the
the
history
and
things
that
have
happened
so
from
a
timeline
perspective.
The
way
it
works
in
in
802.1
versus
you
know.
Ietf
we
go
through
a
number
of
different
balloting
phases.
I
We
did
two
two
rounds
of
task
group
balloting
before
we
went
to
what
we
call
working
group
balloting-
and
this
is
where
it's
mandatory
for
working
group
members
to
pay
attention
and
vote.
We
did
three
rounds
of
of
that
and
and
then
we
went
to
what
we
call
standards,
association
ballot,
which
is
kind
of
the
final
phase,
where
it's
open
to
pretty
much
anybody
in
the
ieee.
I
That's
the
standards,
association
member
and
we
did
two
rounds
of
standard
association
balloting.
So
any
technical
changes
are
typically
completed
during
the
working
group
task
group
and
working
group
phases
we're
now
at
this
revcom
approval,
which
is
where
we're.
Basically,
the
document
is
done,
we're
just
it's.
You
know,
proving
it
through
the
process
and
and
going
for
publication,
I'm
not
exactly
sure
the
date
of
publication
expectation,
but
I
do
believe
it's
before
the
end
of
the
year.
So
anyway,
the
draft
could
be
could
be
used
today.
I
There
won't
be
any
substantive
changes
so
couple
why?
Why
were
we
doing
this
again?
The
main
objective
was
to
support
sending
more
information
that
can
fit
in
a
single
frame.
So
lldp
was
very
simple
protocol
that
only
shared
one
frame
at
a
time,
but
now
we've
sort
of
optimized
for
sharing
something
along
the
order
of
let's
say
100k
bytes.
When
we
first
did
this,
it
was
believed
in
here
in
lsvr
that
something
along
the
order
of
60k
bytes
was
needed.
I
I'm
not
sure
what
the
upper
limit
is
now,
but
it
it's
it's
probably
bigger
than
100k
as
well,
but
we
could
actually
do
the
math
and
we
wanted
to
also
allow
to
the
ability
to
shrink
lldp
frame
sizes
too
for
certain
deployments.
There's
a
lot
of
effort
in
time-sensitive.
Networking
where
timing
is
is
very
important
and
so
sending
smaller
frames
was
a
useful
outcome
of
this
as
well.
I
I
You
know
we
want
to
make
sure
what
we're
sending
is
valid.
We
allow
the
mechanism
allows
what
we
call
pacing
of
receiving
of
those
frames
by
the
receiver.
So
in
other
words,
if
you
have
a
very
lightweight
implementation,
we're
not
going
to
overload
you
you,
you
receive
the
extra
data
at
your
own
speed,
so
to
speak,
and
that's
important
there's
a
lot
of
very
constrained
implementations
of
lldp
and
then
we
didn't
want
to
add
any
additional.
You
know
network
traffic,
so
it's
a
periodic
protocol.
I
Lldp
is
in
general,
but
when
we
add
a
bunch
of
extra
frames,
we
don't
want
to
be
uselessly
broadcasting
those
around.
So
the
the
protocol
doesn't
add
any
really
additional
network
traffic
in
its
design.
So
just
as
a
quick
reminder,
this
is
how
original
lldp
works.
You
you
think
of
it,
as
each
agent
adds.
A
has.
I
A
database
is
what
we
call
his
local
database
of
information
that
he
wants
to
share
to
his
neighbor
and
the
neighbor
maintains
what's
a
remote
database,
which
is
just
a
copy
of
that,
and
so
then,
basically
it's
a
simple,
simple
protocol
right
periodically
a
timer
goes
off
and
you
just
send
your
database
to
your
neighbor
and
again
remember
it
was
one
frame
and
then
that
neighbor
would
receive
it
and
effectively
replace
everything
that
was
there
before
with
what
you
just
received.
So
things
get
wiped
out.
I
It's
you
know,
then
the
the
sender
would
do
the
same.
Whenever
anything,
he
changes
or
if
our
timer
goes
off,
that
he
hasn't
updated
his
information
lately,
then
he
just
sends
a
frame
and
of
course,
if
you
change
something
locally
in
your
database,
then
we
try
to
send
that
frame
immediately
with
some
kind
of
rate
limiting
kind
of
thing
so
that
we
don't
overload
implementations,
but
you
can
get
your
information
propagated
relatively
quickly.
I
So
that's
lldp
version
one.
The
simple
one
very
widely
deployed
lots
and
lots
of
use
cases,
and
so
what
we
did
to
allow
additional
frames
to
be
added
was
created.
You
know
an
extension
protocol
if
you
will,
that
has
what
we
call
receiver
facing.
So
in
this
scenario,
let's
assume
you
know
something
changes
on
this
left
agent's
local
mib.
He
sends
out
a
single
lldp
frame,
a
new.
I
Then
now
sends
back
a
extension
request
frame,
saying
I
want
the
rest
of
your
data
specifying
specifically
what
data
he
wants
and
then
the
sender
will
send
an
extension
pdu,
which
is
a
a
looks
like
an
lldp
frame,
but
it's
got
a
special
format,
and
so
then
the
receiver
will
collect
that
information
until
he
gets
it
all
as
soon
as
he
gets
it
all,
then
he
updates
the
local
mib
so
from
above
api
level,
if
you
will
it,
it
looks
exactly
the
same.
Applications
that
run
on
llbp
look
exactly
the
same.
I
They
just
have
more
data
they
can
send
and
receive
than
they
used
to,
but
below.
We
have
this
extra
protocol
and
then
there's
still
a
periodic
thing
that
happens.
You
know
every
every
so
often
that
you'll
still
send
your
one
lldp
frame
and
if
nothing's
changed
in
your
extension
database,
then
nothing
happens
it
just
on
the
other
side.
He
just
up
refreshes
that
basic
information.
I
I
I
have
you
know,
10
more
lldp
frames
and
here's
what
they
look
like:
here's
their
numbering
system
whatever,
and
then
then,
when
you
send
a
request
for
one
of
those
pdus
you
you
include
this
extension
request,
tlb
and
then,
when
you're
sending
your
extension
pdu,
you
add
the
extension
pdu
tlb
to
the
frame,
so
there's
three
new
tlbs
and
then
there's
these
are
the
pdus
there's
already
the
quote
normal
pdu,
so
that
one
remains
the
same.
It
looks
the
same.
I
However,
if
you
add
this
manifest
tlb,
then
you're
now
saying
I
have
more
data,
because
this
manifest
tlb
is
is
wasn't
defined
in
the
first
version.
Implementations
backward
compatible
implementations
would
simply
ignore
it.
That's
their
that's
how
the
protocol
was
specified.
They
would
store
it
perhaps
as
an
opaque
data,
but
they
would
ignore
it,
and
then
this
new,
these
new
pdus,
are
extension
request
and
the
actual
extension
pdu
itself.
I
We
use
unicast
addressing
here
or
we
specify
the
actual
address,
so
you
flip
from
a
multicast
protocol
to
a
unicast
when
you're
doing
the
extensions
that
avoids
a
lot
of
confusion
and
flooding
in
the
network,
and
then
you,
you
have
specifications
in
here
which
exactly
how
to
identify
the
pdus.
So,
as
I
mentioned,
there's
details
in
the
back.
I
won't.
I
won't
go
through
that.
So
what
are
the
next
steps?
We're
just
waiting
on
that
publication
effectively?
Like
I
said
it's
a
logistic
thing,
no
technical
details.
I
I
Well,
we
format
them
in
the
lldp
format
that
didn't
get
a
lot
of
other
joiner
interests
so
to
speak
at
the
time,
but
you
know,
maybe
maybe
it
would
be
worth
considering,
dusting,
that
off
and
looking
at
how
to
share
the
information,
that's
currently
being
exchanged
or
needs
to
be
exchanged,
and
then,
of
course,
we're
looking
for
you
know
someone
to
update
the
lldp
agent
in
open
source
world
to
to
support
this
new
activity.
We
we
I'm
not
aware
of
anybody
yet
doing
that,
but
that'd
be
a
great
project.
A
Yeah,
yes,
here
gunther
as
a
chair,
so
also
before
you,
you
mentioned
like
security
and
so
onwards,
because,
like
in
data
centers,
you
know
the
application
realm
of
lsvr
security
is
a
high
important
thing.
So
security
was
mentioned.
You
know
in
some
of
the
previous.
You
know
updates,
but
it
was
not
in
this
particular
update
either
like
so.
So
what
is
the
status?
You
know
from
that
perspective,
for
a
lot
of
people.
I
I
A
A
You
know
the
maintain
the
technology
and
also
on
how
to
further
enhance
another
realm
of
of
what
we
are
doing
and
the
accompanying
technologies,
because
you
know
the
pgp
spf
by
itself.
You
know,
even
though
it's
a
very
good
and
fine
technology,
it
seems
to
need
the
some
some
supplement
technologies
like
l3dl
or
lltpv2,
to
discover
the
neighbors
and
itself,
because
you
know,
unlike
a
traditional
igp,
the
technology
has
been,
you
know,
has
been
separated
between
each
other.
A
E
B
Yeah
now
gunter,
I
guess
what
the
plan
will
have
is
we'll
put
that
on
the
list
and
did
we
have
an
idea
of
what
timelines
like
I
mean
we
probably
don't
want
this
to
take
forever.
How
much
time
do
you
think
we
should
put
towards
getting
comments
in
and
allowing
for
a
reasonable
amount
of
input
and
discussion.
A
B
E
E
A
A
A
E
G
B
Okay,
so
let's
do
this-
let's
put
let's
put
this
to
the
list.
Obviously
we
can
we
can.
We
can
finish
off
this
conversation
there.
I
think
there
needs
to
be
some
clarity
in
terms
of
what
what
we're
focusing
on,
I
think
here
was
reasonably
correct
and
that
you
know
original
charter
was.
We
were
focusing
on
data
center
protocol
operation
and
this
discovery
would
have
been
in
context
with
that,
irrespective
of
maybe
wider
potential
clickability
is
that.