►
From YouTube: IETF106-LSVR-20191119-1330
Description
LSVR meeting session at IETF106
2019/11/19 1330
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
Can
somebody
please
close
the
door
at
the
back,
so,
let's
start
welcome.
You
have
all
reached
the
lsv,
our
working
group
session,
so
for
the
next
90
minutes.
We're
going
to
be
discussing
that
topic.
So
let's
first
start
off
with
the
at
the
beginnings
here.
So
a
few
things
actually
happened
now
before
going
into
the
content.
Let's
first
do
some
administrator,
so
we
do
have
a
jabber
scrap.
We
also
have
immunitech
it
parish.
Thank
you
for
that.
So
the
minutes
we'll
be
taking
in
either
part
it'll
note
or
whatever
the
thing
is
called.
B
If
you
would
like
to
contribute,
which
would
be
very
appreciate-
and
please
you
know,
add
your
comments,
particularly
with
names
and
so
on
words
just
to
make
sure
everything
is
done
correctly.
So
you
have
seen
a
note
well
already
a
few
times
if
going
from
the
assumption
that
you
attended
at
least
one
session
already,
if
not
retesting,
be
aware
of
that
anything
you
say
and
do
actually
is
part
of
the
ITF.
You
know
community
here
so
before
we
step
into
the
today's
agenda.
So
this
is
what
we
have
set
up
here.
B
So
first
we're
gonna
have
like
of
you
know
like
a
few
short
notes
on
what
happened
in
the
last
three
months.
That's
going
to
be
followed
up
with
an
update
of
you
know
with
the
latest
document
of
the
bgp
SPF.
You
know
in
Alice
we
are
then
we're
gonna
have
like
three
different
updates
to
do
with
late
release.
You
know
discovery
protocol
followed
with
the
updates
from
I
Triple
E
on
the
tlvs
for
LS
VR,
and
also
with
LTP
v2
in
the
progress
onward.
B
So
if
you
look
into
where
we
are,
you
know
at
this
point
in
time,
and
you
know
from
where
we
start
I
think
we,
our
deliverables
based
upon
the
shorter,
are
like
in
a
reasonably
good
progress.
We
have
a
demo
already
available
for
the
a
lot
of
e.
We
also
have
done
a
working
group
last
call
on
the
bgp
SPF
document
that
went
to
cast
foley.
This
document
has
very
recently
been
updated,
so
I
was
waiting
for
that
for
creating
the
shepherd
right
up
and
pushing
it
onwards.
B
The
document
already
actually
also
had
some
directorate
reviews.
There
was
a
routing
directorate
reviewed,
which
came
back
with
some
issues
and
those
have
been
addressed
in
the
latest
version,
so
maybe
you
can
actually
say
a
few
more
words
later
on
in
his
update
on
where
we
are
with.
You
know,
with
the
comments
from
the
routing
Directorate.
B
So
from
the
ldbl
perspective,
it
actually
had
some
properties
which
went
beyond
the
lldp
v2
v1
technology,
which
required
us
to
work
on
something
like
that
which
you
know
included.
For
example,
things,
like
you
know,
a
big
ramp,
you
size,
a
better
handling
of
fragmentation,
re
assemblies.
It
implemented
like
a
push
model
instead
of
like
a
political
kind
of
update,
and
it
also
had
some
improved
rapid
recovery
technology
involved
there.
B
C
Good
afternoon
guys,
I'm
gonna
give
a
quick
update
on
bgp
SPF.
The
draft
version
six
was
submitted
right
around
the
end
of
September.
First
week
of
October
working
group
last
call
has
been
successfully
done.
We
did
get
reviews,
we
have
incorporated
that
in
the
draft,
implementations
are
now
available.
C
There
are,
we
did
also
receive
lots
of
needs
and
I
think
will
take
care
of
that
in
version
7
that
is
going
to
be
post
posted
post
IETF
from
an
implementation
update
standpoint.
We
now
have
at
least
one
BGP
implementation
that
is
fully
conformant.
We
do
have
another
open
source
implementation.
That's
in
works
specifically
on
FRR,
and
we
have
at
least
three
operators
who
are
looking
to
sort
of
start
playing
around
with
the
code
base
in
the
lab
from
the
update
standpoint,
the
yang
model
for
this
Safi
is
also
defined
fairly
straightforward
mechanism.
C
From
the
modeling
standpoint,
we
want
to
start
working
on
this
models
draft.
We
think
we
should
have
a
common
model
for
LS
and
SPF
and
we'll
take
that
work
pretty
soon
we'll
publish
the
draft
out.
Do
we
wanna
as
part
of
this
new
effort?
We
also
want
to
write
in
protocol
implementation
draft
and
an
experience
strap
that
comes
along
with
the
implementation.
C
C
There
was
from
an
implementation,
standpoint
and
I
think
we
discussed
this
at
the
last
IETF
to
a
challenge
in
generating
a
remote
router
ID,
because
we
do
not
have
a
hello
mechanism
that
it's
establishes
the
edges
in
seas
and
as
part
of
that,
as
part
of
this
draft,
we
have
sort
of
punted
that
either
using
lldp
or
l3
DL
and
or
else
you
can
statically
configure
that
and
sort
of
build
up
the
efficiencies.
So
that
took
care
of
it
again
from
an
intro
up
standpoint.
C
C
Testing
point
of
view
we
have
made
sure
we
have
enabled
it
with
both
ipv4
ipv6,
as
well
as
SPF
Safi
and
seems
to
be
working
just
fine,
a
little
bit
of
a
test
details
on
the
test
setup
that
we
have
tried.
This
Safi
we've
used
standard
Claus
each
point:
apology,
10k,
a
v4
and
v6
routes
with
32
a
ecmp,
so
you're,
looking
at
320
K
paths
for
v4
and
v6,
he
will
start
tested.
C
Peering
was
done
in
band
between
leaf
and
spine.
The
early
convergence
numbers
we
have
gotten
suggest
no.
Particular
convergence
deviation
from
iGPS.
In
fact,
this
is
turning
out
to
be
a
little
bit
on
a
better
side
that
pretty,
which
means
that,
from
a
convergence
standpoint,
the
southeast
holding
up
pretty
well
by
next
ITF
and
in
the
implementation
update
Raph
will
be
posting
some
numbers.
C
As
of
with
respect
to
how
many
updates
were
generated,
and
do
we
see
any
optimized
behavior
here
a
little
bit
of
details
on
implementation
to
that's
done
on
FRR
again,
it's
implemented
by
Santosh
from
VMware
office.
A
fee
support
for
the
BGP
is
pretty
much
done.
A
packet
and
code
decode
support
is
also
done.
He
is
actively
trying
out
ten
code
D
codes
to
make
sure
it's
conformant
with
darkus
implementation.
C
The
SPF
computation
is
work
in
progress
and
post
SPF
computations
that
are
out
downloads
would
be
the
other
part
of
the
work
that
remains
on
this
implementation,
but
we
are
actively
working
towards
interoperability.
Two
implementations
are
going
to
be
out
there,
so
that's
all
I
have
from
the
traffic
update
any
questions.
D
C
C
Two
different
documents-
probably
one-
would
talk
about
specifically
an
implementation,
specific
details
on
an
interim
Interop
side,
and
the
second
would
probably
talk
about
how
you
would
what
are
the
implications,
as
you
start
to
deploy
this
as
a
new
technology
within
the
cross
networks
and
that
one
is
different
from
the
applicability?
Yes,
unless
you
want
us
to
write
one
draft
and
cover
them,
I.
D
E
Ac
Linda
I
just
want
to
say
that
we
tried
for
this
base
specification.
We
tried
to
keep
the
amount
of
function
low.
We
didn't
want
to
put
all
the
bells
and
whistles
that
are
in
a
GPS
in
this,
especially
since
you
already
have
the
richness
of
BGP
policy
that
you
could
apply
anyplace,
but
if
people
see
things
that
they
think
should
be
in
this
base,
spec,
it
isn't
yeah
III,
as
we
were
going
through.
The
implementation.
I
had
one
thing
in
my
mind
and
I'll
discuss
with
the
implementers.
You
know.
E
Let
us
know
if
there's
something
something
we'd
like,
for
instance,
we
decided
we
purposely
didn't
put
areas
in
because
we
didn't
think
we
needed
them
and
we
didn't
think
the
use
case.
The
initial
use
case
needed
them.
So
that
would
be
saying
that
we
are
in
our
borrows
comment
about
the
protocol
experience
we
had.
That
was
a
requirement
for
new
protocols.
Now
we
haven't
done
a
new
protocol
for
a
long
time.
We
got
a
couple
of
them
coming,
so
you
know
back
in
the
old
days.
I
remember
there
was
these.
E
F
A
Hi
I'm
Randy
I'm
from
Marcus
also
that
just
email
address
is
older
than
Cisco
and
so
and
Rob
also
works
for
artists.
So
this
is
conspiracy.
This
is
actually
a
sympathy.
Play
I
have
to
work
with
care
every
day,
okeydoke
l3
DL,
it's
this.
This
is
the
fourth
version
and
it
hasn't
changed
much.
So
just
a
quick
review.
Remember
the
primary
goal
is
topology
discovery
for
layer,
three.
A
Okay,
then
the
principle
customer
is
RK
or
an
AC,
etc,
etc.
Spf,
but
I
will
reveal
some
other
uses.
Okay,
just
a
review
is
and
you're
not
gonna.
Let
me
move
it's
layer,
2
protocol
to
get
layer,
3
data
across.
So
here's.
What
we're
talking
about
down
here
and
I
will
not
get
into
this
time,
how
it
pushes
it
up
to
SPF
because
it's
boring.
So
it's
just
a
layer,
2
protocol
single
links
at
a
time.
It's
not
a
routing
protocol.
A
A
The
question
is:
should
apd
you
be
retransmitted?
If
so,
it
must
be
sent
as
the
identical
set
of
data
grams.
As
the
original
transmission
and
the
transmission
sequence
number
informs
the
receiver
that
it
is
the
same
one.
The
sequence
numbers
are
knots,
okay,
so
every
PDU,
which
is
composed
of
lots
of
frames
as
this
magic
number,
it's
sequential
it's
obvious.
Okay,
and
if
a
Datagram,
a
Datagram,
not
the
PDU,
but
a
from
one
of
the
data
grams
in
a
PD,
you
fails
checksum
verification
drop
it
on
the
floor.
A
The
sender
will
retransmit
the
PDU
and
the
receiver
can
reassemble
it
right.
Reassembly
is,
if
you
remember,
TCP,
it's
pretty
dissimilar.
Okay,
there
was
an
Oracle.
There
were
two
cases
of
authorization:
failure,
authorization
in
open
and
authorization
in
a
non
open,
PDU
that
formed
an
Oracle
that
you
could
tell
what
the
PD
you
type
was
by
the
error.
So
therefore,
now
they're
both
one
just
failure,
just
security
nut
stuff.
Okay,
the
transport
layer
can
handle
rather
large
PD
use,
and
it's
really
pretty
clearly
delineate
delineated.
A
A
Ok,
with
that
transmission
sequence,
number,
Datagram,
length,
etc,
checksum
reassemble
them
and
into
PD.
You
just
like
we
do
with
the
TCP.
Ok,
and
why
not
use
TCP
I
mean
why
reinvent
TCP?
It's
because
we
don't
know
the
IP
addresses
of
anybody.
We're
discovering
the
IP
addresses
we'd
love
to
use
TCP
we'd
even
put
it
over
TLS.
So
it's
a
cheap
TCP
like
protocol
with
state
and
all
that
stuff
over
layer,
two
okay,
reassembly
transmission
with
back
off
BTUs
or
acknowledged
long-lived
sessions.
A
A
A
One
of
the
things
that's
been
enhanced
in
this
version
is
they
need
a
peak
in
the
PD.
You
that's
announcing
and
withdrawing
addressing
at
endpoints
the
actual
protein
of
this
protocol.
The
encapsulation
flags
are
now
you
can
announce
and
withdraw
single
encapsulations.
At
a
time
you
can
say
whether
this
is
a
primary
address
on
an
interface
you
can
say
whether
it's
an
underlay,
an
overlay
address,
and
this
will
get
exciting
in
another
15
minutes.
You
can
say
whether
it's
a
loopback
okay
for
each
encapsulation
for
each
address.
A
Okay,
there's
explicit
acts
with
errors,
error,
type
code.
Zero
is
just
an
act.
Everything
else
is
in
error.
Vendor
extension
hasn't
changed.
Okay,
we
now
have
as
I
think
it
was
Gunther
said
one
Python
three
open
source.
One
is
in
golang
that
we're
hoping
to
open
up
it's
going
into
our
product,
a
false
within
drop,
maybe
in
Vancouver
we'd
like
to
start
thinking
about
moving
to
weg
last
call.
A
A
H
H
In
its
ITF
RSC
GCC
peak
that
has
been
done,
it's
basically
TCP
or
UDP,
fully
published
with
all
the
corner
cases.
So
I
wonder
why
you
you
were
not
looking
at
that
stuff.
Maybe
you
missed
them.
Maybe
there
was
something
missing,
just
a
question
in
the
room,
because
I
see
the
same
work
pretty
much
yeah.
If.
B
A
F
A
Thank
you,
yep
yep
yep.
He
was
rather
picky
by
the
way
his
name's
Harsha
he's
not
here,
but
he
beat
me
up
every
couple
of
days.
Okay.
So
if
you
remember
from
this
last
time,
you
can
go
to
Bess
and
neeraja
extended
it
to
do
evpn
without
ARP
snooping
without
all
the
crazy
stuff.
That
makes
you
throw
that
equipment
away.
Okay,
so
go
to
Bess
and
senior
ahsha's
presentation
on
using
this
with
two
new
PD
use
for
e
VPNs.
A
So
I'm
way
back
when
I
raise
the
issue
of
security
and
operator
said
yeah,
we
want
security,
I
said:
what's
your
threat
model
and
the
room
was
silent,
so
I
hypothesized,
a
threat
model
and
I
said
I'm,
worried
about
people,
plugging
lot,
poisoned
laptops
in
worried
about
people,
plugging
strange
devices
in
etc,
etc.
So,
if
you'll
notice,
the
PDUs
have
signal,
PDUs
are
signed
or
can
be
signed
or
may
be
signed
to
be
more
proper.
A
The
open
PD
you
may
have
a
type
of
the
authorization
that'll
be
used,
the
key
that
will
be
used
to
sign
with
the
appropriate
length.
Of
course,
okay.
The
PDU
is
signed
by
the
sender,
the
open
pd.
You
had
the
public
key,
the
sender
signs,
with
the
private
key,
of
course,
and
the
device
sending
the
open
can
use
one
key
for
all
links,
different
keys
for
the
blue
links,
different
keys
for
the
pink
links,
whatever
we
don't
care.
Okay,
that's
a
matter
of
configuration.
A
Okay,
click!
There
we
go,
the
open
is
generated
on
the
sending
device.
The
private
key
never
leaves
the
sending
device.
This
is
reasonable,
normal
key
practice
with
trust
on
first
use.
It's
believed
without
question
by
the
receiver.
So
here's
my
public
key,
you
believe
it.
It's
used
to
verify
all
subsequent
videos
from
the
same
sender.
So
the
sender
is
the
same.
Attacker
you
had
yesterday,
that's
tofu,
sorry,
you
don't
have
to
use
tofu.
A
A
Okay,
it
just
is
that
the
key
the
public
key
is
signed
by
a
private
key,
and
that's
it
none
of
the
rest
of
the
x509
glorp.
You
don't
need
it.
If
you
are
an
organization
that
has
an
x.509
infrastructure.
Of
course
you
can
use
x.509
enjoy
okay,
every
device,
though
to
do
this-
must
have
burned
in
or
distributed
to
it
somehow
the
public
key
of
the
trust
anchor
of
the
PKI.
So
it
can
verify
it,
but
this
gives
you
fairly
reasonable
sign,
PDUs,
okay,
verify
the
two
methods
are
indistinguishable.
A
The
key
in
the
open
pin
used
to
verify
the
signatures.
If
it's
PKI
based
it's
just
when
you
got
the
open
pd
you,
you
could
check
that
the
key
was
authentic
from
then
on
you're
cruising
okay,
the
choice
of
which
type
of
Kings
left
to
the
operator
and
in
fact
they
could
mix
and
match
the
pink
peers,
get
tofu.
The
blue
peers,
get
it
PKI.
A
A
You
don't
have
to
do
it
by
the
way
you
can
have
the
key
authorization,
type,
B,
zero
and
no
security
at
all.
Right.
Sorry,
I
didn't
mention
that,
so
the
purpose
here
is
4k
or
NAC
to
be
able
to
talk
to
BGP
to
each
other.
A
A
So
so
we
have
a
PD
you
for
building
upper
layer
protocols
and
in
this
instance,
so
it's
it's
a
simple
TLV
with
a
protocol
type
an
attribute
count,
an
attribute
list
and
the
attributes
are
the
protocols
want
to
provide
the
minimal
set
of
parameters
for
bgp,
because
open
is
going
to
exchange
all
the
rest,
and
you
don't
want
to
be
in
conflict
with
the
parameters
exchange
in
open.
Because
then
you
have
two
sources
of
truth
and
my
mother
always
told
me
that's
bad
news,
because
then
you
have
to
resolve
okay.
A
A
I
A
Okay,
you
know
so
we'll
do
the
we'd,
like
an
adoption,
call
on
that
too,
and
then
for
dessert.
There
is
no
internet
draft
on
this,
but
I
want
to
show
you
an
OP
stack:
okay,
no
protocol,
just
an
ops
hack
at
layer,
3
using
l3
deal
so
the
folks
doing,
kubernetes,
etc,
etc.
Have
you
know
tours
connected
a
rat
full
of
servers
and
servers?
Have
you
know
they
might
have
an
ad
or
whatever
and
tons
of
micro
services?
A
Maybe
a
hundred
of
them
on
a
server
okay,
and
we
can
use
l3
DL
to
automatically
build
and
discover
this.
The
simple
thing
would
just
be
running
a
l3
DL
on
the
server's
external
interfaces
and
on
the
tours
and
you'd
have
an
L,
3
DL
configuration
to
say
inject
those.
Well,
that's
fine!
Now
the
tour
knows
to
add
us
find
those
interfaces
big.
What
we
do,
that's
not
very
exciting,
so
remember,
active
and
passive
interfaces
in
is-
is
nos
PF,
okay,
where
you
can
say
that
an
interface
is
active,
excuse.
A
The
juniper
I
believe
that
this
is
an
active
interface.
It
sends
and
receives
the
protocol.
That's
what's
meant
by
active
and
it
injects
its
l3
addressing
into
the
protocol
a
passive
interface.
It
does
not
send
and
receive
the
protocol,
it's
silent,
but
it
injects
the
l3
information
into
the
protocol
database.
A
A
Okay,
so
you
can
have
a
rack
where
her
services
are
moving
around,
etc
and
remember.
L3
DL
is
going
to
be
very
quiet.
It's
only
going
to
tell
you
when
things
change
now
you
can
turn
up
lair
to
live
in
this
checking
or
not
use
it
at
all.
But
if
you
want
detection
of
failures
in
motion,
if
you
want
to
detect
the
server
down
within
one
second
ten
seconds
or
five
minutes,
you
can
turn
that
on
okay,
so
you
can
have
hundreds
of
micro
services
on
a
server
30
or
40
servers.
A
G
Hi
Paul
I,
so
I
think
what
you're
saying
is
you
really
only
need
to
one
run,
one
instance
of
vel
3dl,
then
not
for
all
of
those
ll
or
whatever.
That
are
the
virtual
ones
in
the
overlay.
Is
that
what
you're
saying
yes,
and
so
if
there's
collisions
with
IP
addresses
or
things?
How
does
that
result
or.
G
G
A
The
two
aspects
to
quiet:
first
of
all,
you
tuned
liveness
for
what
you
just
like
you
tuned
BFD,
but
the
protocol
only
announces
changes
right
and
that's
the
big
thing
about
quiet.
It's
not
going
like
is,
is
and
OSPF
every
30
seconds
hitting
you
on
a
hit
with
hammer
right.
Okay,
it's
like
bgp.
It's
the
only
announcing
changes.
B
G
Okay,
so
at
the
last
ITF
we
promise
to
produce
a
draft
that
showed
how
to
write
the
lldp
tlvs
for
the
information
that
is
needed
to
be
exchanged
for
LS
VR.
So
that's
what
this
draft
is
about
again,
so
you
know
why
I
was
motivated
as
Randy
just
mentioned.
L
SVR
needs
to
get
this
information
to
bootstrap
itself,
l
through
Yale
does
that
uses
TLB
formats
to
do
that?
G
This
is
the
format
of
that
organizations
can
be
vendors
or
they
can
be
other
standards
organizations
and
you
simply
you
stick
in
your
o
UI
into
the
TLV
itself,
and
you
have
a
subtype
field
that
must
be
there
and
that
subtype
you
need
to
manage.
So
that's
what
the
ITF
would
need
to
make
sure
if
they're
gonna
create
their
own,
that
they
manage
that
space.
G
G
F
G
Okay.
So
let
me
talk
a
little
bit
about
the
design
of
these
Tobs.
So
till
the
TLV
themselves
have
a
bunch
of
fields
in
them.
I
didn't
define
those
fields
just
made
a
normative
reference
to
l3
DL.
So
things
like
the
lle
eye,
the
attributes,
those
in
caps
flags
that
we
just
looked
at
all
those
come
from
l3
DL
as
a
normative
and
the
I
did
not
include
the
per
TLV
signatures
that
are
in
Elfie
DL,
but
that's
kind
of
the
the
way
elf
and
yell
can
define
very
large
TLV.
G
So
maybe
a
signature,
Portillo
v
makes
sense
here,
I
think
in
lldp.
If
we're
gonna
do
signatures,
we
need
to
do
it
across
the
entire
set
as
opposed
to
inside
each
one.
We
we
have
a
limited
space
for
TL
v.
That's
one
of
the
that's
one
of
the
things
we
need
to
work
with,
and
so
just
some
minor
things
I.
G
That
was
then,
to
just
add
the
lle
I
into
each
of
the
tlvs,
so
we
don't
need
to
again
run
multiple
instances
of
the
protocol,
and
so
in
order
to
get
the
full
set
of
information
that
you
need,
you
probably
have
to
send
multiple
of
some
of
these
tlbs
and
that's
perfectly
valid
in
in
lldp.
You
don't
just
have
to
have
one
of
them.
You
can
send
ten
of
the
same
type
of
l
TLV,
just
as
long
as
they
have
different
data
and
log
it
put
together
and
so
I
guess.
G
G
So
again,
most
of
these
are
just
strictly
TLV
formats.
Now
there
was
the
attribute
account
and
I
noticed
that
got
changed
in
Randy's
latest
draft,
so
obviously
I
didn't
track
some
of
these
changes,
but
this
would
just
be
simply
that
attribute
list.
The
assumption
would
be.
We
could
fit
that
into
a
single
TLV,
so
we
should
really
only
have
one
of
those
not
multiple
of
those.
G
My
PV
for
or
announcements
would
have
the
in
caps
flags
and
the
address,
and
then,
of
course
you
could
replicate
that
as
many
times
as
you
can
to
fit
in
the
size
of
an
LLB
pto
V.
So
you
might
send
multiple,
so
we
have
a
v6
as
well.
We
have
the
MPLS
v4,
the
MPLS
v6
I.
Don't
think
we
need
to
look
at
them
in
details,
but
the
way
the
the
fields
in
there
are
structured
again
are
either
normatively
referenced
to
l3
DL,
or
they
were
slightly
modified
to
remove
the
count
field
or
something
okay.
G
So
that's
sort
of
the
main
thing
in
the
draft.
It
doesn't
really
tell
you
how
to
process
them
or
pack
them
or
anything
like
that.
It's
just
trying
to
define
them,
and
if
we
need
to
sign
these
things,
we
need
to
probably
figure
out.
Maybe
we
should
create
a
whole
new,
l2
or
TLB
just
for
the
signature.
We
talked
a
little
bit
about
that
and
clearly,
if
we
want
to
pursue
this
there's
interest
in
this,
we
need
to
fix
the
clarifications
and
get
it
up
to
date
with
l3
DL.
So
so
any
questions.
G
A
G
Be
covered
in
this
presentation
where
we
talk
about
lldp
v2,
so
all
that
other
with
the
drought
is
just
defining
the
payloads
that
that
you
need.
So
this
presentation
is
going
to
tell
you
about
the
latest
status
of
project
802
2.1,
a
b
d
h.
If
anybody
needs
a
secret
decoder
ring
on
the
letters
meet
me
in
the
hallway,
I
can
explain
a
Capitol
upper
and
lowercase.
They
are
significant.
So
that's
what
we're
calling
lldp
v2
so,
first
of
all
I'm
giving
an
update
on
a
standards
project
and
the
other
SDO.
G
This
is
just
my
personal
view
kind
of
need
to
slow
this
slide.
It's
not
an
official
liaison.
Okay.
If
you
want
to
do
those
the
past
letters
back
and
forth,
this
is
much
more
efficient
way
to
do
it.
If
you
trust
me,
so
that's
my
discrepancy.
Okay,
so
I've
already,
given
an
update
in
the
previous
one,
so
I
there's
some
background
material
lots
of
links
of
things
that
you
can
get
history
on.
I
didn't
repeat
him
here,
and
so
that's
the
first
link.
The
second
thing
is:
the
project
has
been
approved
this
official
project.
G
G
We
proved
that
last
week,
so
I
don't
know
when
that'll
go
out,
probably
in
the
next
couple
of
weeks
or
so
or
who
knows
so
one
of
the
big
changes
since
last
IETF,
just
we
added
terminology
and
definitions,
you
know
trying
to
get
it
ready
for
actually
starting
the
documentation.
There's
a
thing
called
a
manifest,
which
is
a
new
TLV
which
effectively
describes
all
the
other
TL
B's.
G
We
tweaked
it
a
little
bit
so
that
we
could
get
the
the
set
of
data
that
you're
going
to
exchange
to
be
bigger,
basically
and,
and
that
needs
to
be
tuned.
That's
there's
nothing!
That's
up
in
the
air
on
how
it's
a
trade-off
between
you
know,
kind
of
collisions,
reliability
and
how
much
data
you
want
to
send,
and
then
there
was
sort
of
a
worst
case
scenario
shared
me
can't
brain-dead
thing
where
you
might
have
multiple
people
in
the
same
MAC
address.
G
G
Okay,
so
a
lot
of
words
on
here
and
the
next
couple
slides
that
there's
some
good
pictures
that
maybe
make
it
a
little
more
obvious.
So
the
goal
here.
Of
course,
the
main
goal
is
to
send
more
data
than
can
sit
and
fit
in
a
single
Ethernet
frame.
So
the
biggest
restriction
with
lldp
is
that
everything
that
you
had
to
send
was
in
one
frame.
You
couldn't
actually
send
multiple
frames
of
different
stuff
that
that
wasn't
the
way
the
protocol.
It
was
designed
to
be
ultra
simple
and
so
obviously,
there's
big
restrictions
in
that.
G
So
we
want
to
support
the
the
ability
to
limit.
You
know
that
also
we
do
the
opposite
so
in
in
802,
there's
a
thing
called
time-sensitive
networking,
which
is
debt
net
in
here
at
layer,
3
and
there's
a
lot
of
like
super
time
scheduled
stuff,
and
we
don't
want
to.
We
want
to
be
able
to
actually
shrink
an
lldp
packet
if
we
wanted
to
in
order
to
get
them
to
fit
in
the
timing.
So
this
this
LOD
pv2
actually
works
for
that
as
well.
So
it's
a
separate
sort
of
a
separate.
G
G
But
so
you
have
basic
connectivity,
you
have
the
same
level
of
functionality
and
an
existing
lldp
implementation,
but
you
have
the
ability
to
send
more
data
now,
if
you
support
an
enhancement
and
so
that's
important,
because
we
don't
have
to
just
upgrade
the
world
or
deploy
something
shared
media
is
supported
and
you
know,
obviously
we
want
to
make
sure
everything
we
send.
We
can
account
for
so
the
other
important
thing.
Another
objective
was
we
want
to
support
what
we
call
receiver
pacing.
G
So
a
lot
of
you
know
really
really
small
IOT
type
devices
do
things
like
lldp
right,
so
we
don't
want
to
have
them
have
to
swallow
a
big
giant
database.
Every
time
you
send
it
I
know
OSPF
and
is
may
have
had
some
problems
like
that
in
the
past.
So
what
we
do
is
we
allow
the
receiver
of
this
chunk
of
a
series
of
data
to
be
able
to
request
them
at
the
pace
that
they
can.
G
So
that
means
I
can
stop
very
cheap
implementation
of
lldp
without
a
ton
of
buffering
and
things
like
that,
need
it
and
we
don't
want
to
increase
the
chatter
any
more
than
lldp
v1.
So
there
is
no
increase
its
you
simply
periodically
transmit
exactly
like
you
do
in
llv
p1.
If
there's
more
changes
in
the
extension
data,
then
the
receiver
will
request
that
there
are
some
other
optimizations.
You
know
that
we
we
looked
at
as
well
or
looking
at
that
could
be
considered.
G
The
project
scope
was
written
in
a
way
that
we
could
do
I
think
some
extra
things
if
we
really
needed
to
here
without
too
much
feature
creep
and
then
the
whole
authentication
security
like
I,
said
I
had
punted
it
in
the
previous
presentation
on
tlvs,
but
we
can
certainly
address
that
year
by
defining
some
secure,
TL
ease
that
that
would,
you
know,
provide
some
kind
of
integrity
across
the
whole
set.
Okay,
just
a
quick
reminder,
so
so
I'll
repeat
again:
super
simple
protocol.
Think
of
it
we
like
to
think
of
it
as
you're.
G
Exchanging
a
database
I
have
a
database
which
is
just
a
set,
or
maybe
a
data
set
is
a
better
word
of
tlvs.
I
have
a
set
of
TVs
and
I
just
want
to
tell
my
neighbor
about
them
and
if
I
change,
something
I
want
to
tell
them,
there's
a
change,
and
so
what
happens
is
periodically
you
just
go
out
like
an
in
period.
G
You
can
be
like
thirty
seconds,
you
would
go
out
and
you
would
just
and
here's
my
latest
database
now
the
receiver
again
very
simple
when
he
receives
the
packet
from
you
and
it
checks,
sums
out
and
everything's
good.
He
throws
away
the
old
database
and
replaces
it
with
what
he
just
got
well.
He
actually
compares
first
to
make
sure
something
changed.
If
something
changed
he
replaces
it
and
he
tells
us
higher
layer
protocol
something
changed.
That's
it
and
then,
when
you
change
something,
you
immediately
go
ahead
and
transmit
your
PDU.
G
You
don't
wait
for
the
periodic.
You
know
transmission,
so
you
can
get
a
rapid
update
if
you
will,
but
you
know
things
settle
down
and
just
basically
you're
just
exchanging
a
database.
So
the
version
two
is
doing
the
same
thing.
It's
just
that
the
database
now
will
consist
of
more
than
one
packet,
and
so
now
we
have
to
deal
with.
G
How
do
we
know
we
got
all
the
packets
and
blah
blah
blah
so
there's
this
is
where
you
get
a
lot
of
words
and
they're,
basically
think
of
the
the
original
lldp
packet
as
a
foundation
PDU,
we
call
it
so
the
original
version
one
is,
is
the
same
as
the
version
one
today.
It
just
has
one
additional
PT
LV
and
the
additional
TLB
is
what
we
call
a
manifest
TLV,
and
so
what
that
is
is
effectively
a
description.
G
Cryptographic,
hash
check
sums
whatever
of
all
of
the
other
extension
PDUs
okay,
and
so,
when
a
version
one
guy
receives
this
he's
not
gonna
know
what
that
TOB
is,
so
he
just
ignores
it.
He
actually
stores
it,
but
he
doesn't
process.
He
doesn't
know
what
it
is,
so
it
doesn't
do
any.
He
doesn't
act
on
it
when
a
version
2
guy
gets
it
he's.
Gonna.
Look
at
that
that
manifest
he's
gonna
go.
Okay,
I've
got
let's
say
seven
more
PDUs
out
there.
G
And
yet,
if
you
don't
have
a
manifest
at
the
act,
just
like
a
regular
PU
now,
the
number
of
additional
extensions
PDUs
that
I
can
add
to
LLB,
pd
d
b2
is
is
limited
by
the
size
of
a
TLB.
So
a
TLB
he
currently
is
limited
to
512
bytes.
So
that
puts
a
restriction
on
how
big
we
can
make
the
whole
thing
and
that's
we're
playing
with
the
size
of
the
manifest
gives
us
a
bigger
set
or
smaller,
set,
and
so
anytime,
a
data
changes
in
one
of
these
extension
PDUs.
G
The
manifest
would
get
updated
that
would
get
sent
over
the
receiver
would
notice
that
it's
changed
and
then
he
would
ask
for
the
changes.
Basically.
So
now
we
have
extension
PDUs.
These
would
be
ignored
by
a
version
one,
so
they
wouldn't
even
see
them
via
different
ethertype
or
we've
talked
about
various
ways
to
do
that,
and
then
it
would
look
somewhat
like
a
version,
one
PDU,
but
it
would
have
some
identifier
on
which
extension
it
is
and
it's
sent
as
a
unicast.
G
So
lldp
is
multicast,
but
if
you,
if
you're
you
know
real
familiar
with
802
standards,
it
uses
one
of
the
special
multicasts
which
is
used
to
just
talk
to
other
bridges.
So
it
doesn't
flood
through
the
network.
It
is
stopped
by
every
bridge,
so
it
acts
a
little
bit
like
a
unicast.
But
if
you
had
a
true
shared
media
like
a
old
repeater
or
something
in
there,
it
would
go
to
every
every
person,
the
extension
P
to
use
the
new
ones
that
we're
sending
our
unicast.
G
So
those
would
not
flood
anywhere
or
not
get
propagated
any
further
than
they
need
to,
and
then
we
have
a
time
to
live.
So
when
you,
when
you
in
lldp,
when
you
tell
your
neighbor
about
your
your
your
latest
state,
there's
a
TTL,
that's
associated
with
that.
That
means
that
data
is
good
for
a
certain
amount
of
time.
After
that
time
you
throw
everything
away
but
or
it
gets
updated
refreshed.
So
it's
again
really
pretty
straightforward.
G
That
TTL
will
apply
to
all
the
data
across
all
the
extensions,
ok,
and
so
now
we
have
another
another
packet,
which
is
the
request
for
PU.
So
this
is
one
two
person
asks
for
all
the
extensions
he
asks
for
the
updates.
You
know
a
lot
of
text
here.
I,
don't
know
that
it's
overly
important
to
go
through
the
minutiae
here.
But
if
you
have
questions
about
it,
we
can
I
think
what's
probably
best
is
to
look
at
the
the
actual
protocol
here.
G
So
here
we
have
two
lldp
agents
on
a
wire,
the
one
on
the
left.
Let's
say
he
makes
a
change.
He
reconfigures
for
some
reason,
LS
PR
adds
adds
an
interface.
That's
gonna
change,
one
of
the
tlvs
in
the
in
the
overall
database,
which
is
gonna
cause
the
manifest
to
change,
and
so
we're
gonna
have
what
we
call
something
to
change
local,
which
triggers
me
to
send
a
PD.
You
out
and
I'll
tell
my
neighbor.
G
Now
all
I'm
gonna
send
is
the
the
old-fashioned
foundation
PD
you,
but
it's
gonna
have
a
different
manifest
so
that
receivers
going
to
get
the
packet
he's
gonna
look
at
it's
different
than
what
he
currently
had
and
so
he's
gonna
go
okay,
something
changed
and
he's.
Oh,
it's
in
the
manifest
something's
different
in
the
manifest.
Now
he's
gonna
go
about
the
process,
deciding
exactly
what
is
he
what's
missing?
Which
extension
is
missing
and
then
he'll
send
a
request
for
that
extension
and
then
you
know
as
he
can
consume
them.
G
The
sender
will
unicast
the
the
the
information
back
and
then
eventually
you
go
back
to
everything,
settles
down
the
change.
The
configuration
change
has
been
propagated
and
you
go
back
to
normal
lldp
operation.
So
that's
that's
effectively
the
version
two
pretty
pretty
straightforward,
so
I
guess
Randy.
To
answer
your
question.
We
have
the
same
lldp
transmission.
We
in
the
tio
V's
I
proposed
in
the
previous
draft.
G
So
any
other
questions
on
how
the
protocol
works
or
what
what
we're
trying
to
do
pretty
simple.
Next
steps
is
to
continue
to
the
technical
contributions.
I
mean
love
to
have
an
open-source
implementation.
There's
somebody
to
work
with
on
you
know,
taking
the
open-source,
lldp
and
and
prototyping
this.
These
particular
changes
to
it.
So
we
can
better
evaluate
that
yeah,
I
I!
Don't
personally
have
the
time
but
I'd
love
to
love
to
do
it.
If
I
had
the
time
yeah.
E
G
Is
being
done,
yeah
good,
good
point,
yeah
I
mean
Alice,
VR,
sort
of
stimulated
it
because
you
had
the
immediate
need,
but
there
have
been
other
people
that
have
come
up
and
and
and
already
asked
for
it.
So
there's
there's
another
standard
going
on
a
tour
2.1
qcj,
which
it
does
a
provider
backbone
bridging
you
know,
I,
said
to
VLAN
mapping
thing
and
it's
a
little
protocol
that
sits
on
top
of
lldp
as
well,
and
they
have
a
need
to
send
more
data
than
you
can
fit.
I
didn't
talk
about
some
of
the
other
things.
G
I
mean
general,
there's
a
lot
of
vendors
that
have
made
a
lot
of
their
own
tlvs
and
every
protocol
that
we
keep
inventing
in
dot
one.
We
keep
adding
another
TLV
to
negotiate
it,
so
so
the
it's.
It's
definitely
a
need
so
yeah,
and
this
is
done
in
the
general
sense
right.
It
wasn't
just
done
for
lol
SBR,
but
we
think
that
was
one
of
the
key
people
that
could
use
it.
G
G
The
next
step
is
to
actually
create
what
we
call
an
editors
draft
or
an
individual
contribution,
individual
draft,
because
there
hasn't
been
an
editor
assigned
yet,
but
usually
that's
the
person
who
puts
that
together
and
and
I
welcome
a
etf
participation
I.
What
I
should
have
put
on
here
was
a
list
of
when
our
next
meeting
is
and
how
you
can
how
you
can
participate
care,
hey.
C
C
G
I
certainly
wasn't
proposing
that
this
is
in
all
a
exclusive
alternative.
What's
going
on
with
l3
DL
now,
there's
gonna
be
other
use
cases
for
this
as
well.
What
we
understand
from
talking
to
various
operators
is
they're
already
running
lldp
anyway.
So
why
not?
You
know,
let's
try
to
try
to
add
to
it,
but
there
certainly
was
an
intention
to
be
an
exclusive
method
and
then
I
guess
yeah.
As
I
mentioned,
IETF
people
can
participate,
we're
in
entering
the
early
stages
of
what
we
call
a
task
group
ballot
and
it's
up
to
the
editor.
G
G
D
So
you
just
said
that
there's
some
extra
this
some
extra
working
so
Metro
features
an
LP
DL
that
are
not
covered
here.
So
the
the
inverse
question
is:
does
LD
PV
to
satisfy
the
requirements
that
we
need
for
LS
we
are,
are
the
things
missing
that
we
get
rid
of
through
the
other?
We
don't
get
with
LD
P
b2
or
not.
What,
since
you
quote
in
mean
cute,
pretend
like
I'm.
C
D
C
Look
since
he
quoted
Mikael,
written
arcus,
I
was
simply
saying
they're,
two
different
transports
and
therefore
two
different
semantics.
As
long
as
we
have
common
TLB
definitions
and
set
of
TL
ways
that
go
onto
different
transports,
depending
on
which
fabric
wants
what
transport
and,
like
all
said,
some
fabrics
to
deploy
lldp
today,
some
fabrics
very
deploy
already
L,
so
I
think
working
do
taking
both
work
in
parallels.
A
I
think
you
missed
darkus
and
IJ.
They
are
not
the
same
TVs
but
right
that
can
be
okay
if
they're
the
same
semantics.
It's
not
clear
that
they're,
saying
semantics,
because
we
haven't
really
dug
into
this.
A
Okay
and
the
semantics
include
not
just
the
content
of
the
TL
V's,
but
what
happens
in
is
their
state
and
how
the
two
states
are
maintained
at
both
end
and
what's
the
story
about
failures,
etc.
So
I
think
and
I'm
not
saying
good
or
bad
I'm
saying
we
haven't
looked
so
to
answer
your
question.
I
think
we
don't
know.
Is
it
the
only
answer?
I
could
give
certainly
I
okay.
D
D
Right
so
we
creative
at
some
point.
We
knew
something
more
right
since
there's
already
collaboration
corporation.
You
know
it
would
be
nice,
I
didn't
notice
that
you
changed
the
tlvs
I
think
you
said
at
some
point
that
in
the
other
presentation
that
it
was
basically
the
same
thing,
you're
actually
normally
normatively
referencing
the
3d
I'll
graph
for
the
definition
of
all
the
all
the
fields,
but
you
took
things
out
like
counts,
or
something
like
that.
G
I
think
you
could
define
the
T
Ovie's
once
and
use
them
in
both
places.
I
just
and
I
could
provide
this
calm
feedback
to
the
l3
Li
there
I
don't
think
there
was
a
need
for
some
of
the
feeling
that
the
Ovie's,
but
I
certainly
could
have
mapped
it
better
or
more
identical,
and
that
there's
definitely
a
different
packing
problem.
G
It
might
be
one
TLV
in
l3
DL,
but
they
might
be
three
or
four
tlvs
in
lldp
that
have
the
same
format,
so
no
I
mean
I
think
it's
possible
to
define
potentially
defined
identical
tlvs
the
security
one
I
was
like
again
I'm,
not
entirely
sure.
We
want
to
sign
every
TLV
that
that's
a
discussion
to
have
that's
probably
an
aspect
of
the
way:
lldp
packs
its
tlvs,
because
it
has
a
restricted
side.
So
I
don't
want
to
waste.
However,
many
bytes
signing
every
single
one
of
them,
I'd
rather
sign
the
block
of
them.
G
G
A
G
G
Okay,
so
all
you
know,
I'll
do
my
best
to
make
sure
I
announced
to
lsv
are
when
we're.
You
know
making
drafts
available
of
our
protocol
and
again
Oh
inviting
people
to
participate
in
the
process
and,
of
course,
coming
to
our
meetings
is
fine
too.
That's
great
and
I
can
announce
that
as
well
whatever
you
guys
want
me
to
do
there,
just
let
me
know,
okay,
any
other
questions.
H
B
Also,
you
know
between
you
know
the
common
dlv
kind
of
structure,
I
think
it's
an
important
thing,
because
so
what
we
have
seen,
for
example,
you
know
one
of
the
complexities
I
want
to
avoid
is
between
some
of
the
you
know,
IGP
tlvs
being
constructed,
and
then
the
encoding
with
BG
pls
involve
to
it
it's
image,
sometimes
to
have
like
a
magical
decoder
ring,
as
was
mentioned
before
it
would
be
very
nice
if
we
can
actually
avoid
that,
and
for
that
you
know,
I
would
really.
You
know
appreciate
collaboration
between
the
two
different
transport
mechanisms.
B
C
Okay,
I
one
last
comment:
I
I,
I.
Don't
think
we
got
a
chance
to
address
it
while
Randy
was
presenting
l3
DL,
but
we
have
an
implementation
for
l3
DL.
That
is
fully
compliant
and
I
just
wanted
the
working
group
to
know
so
happy
to
work
with.
If
there's
any
other
implementation
out,
there
would
be
happy
to
do
summit
drop
testing.