►
From YouTube: IETF105-LSVR-20190725-1000
Description
LSVR meeting session at IETF105
2019/07/25 1000
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
Oh
all
right,
we'll
figure
it
out,
I'm
gonna.
Do
it
all
right
I'll,
do
it?
You
guys
have
to
talk
a
lot
okay.
So
let's
get
going!
Thank
you
very
much
for
coming
to
ITF.
In
five,
the
LSP
our
working
group
co-chairs
will,
under
the
weather,
so
I'm
gonna
try
to
do
most
of
the
talking
yep
and
put
up
with
me.
A
Please
note
the
note
well
applies
to
the
meeting
you
haven't
read
it.
These
read
it's
here.
Is
our
agenda
we'll
take
a
moment
to
have
a
quick
look
at
that?
If
anyone
feels
it's
out
of
order
or
you
want
to
make
a
comment
now,
it's
time
to
do
so.
I
have
a
mic,
but
if
not,
we
will
do
a
some
administrator
to
get
things
going.
The
chair
side
there'll
be
a
call
to
action,
quick
presentation
from
Ignis
Rab.
A
Then
there
will
be
a
few
presentations
on
some
in-flight
working
group
documents
or
yet
to
be
working
group
documents
and
then
we'll
have
some
closing
comments
and
next
steps
all
right.
No
one
at
the
mic
will
keep
going.
So
we
had
a
number
of
key
milestones
that
we
had
to
work
through
over
the
last
little
while,
as
of
March
2019
earlier
this
year,
with
the
applicability
statement
of
LSB
our
DC's
adopted,
it
was
the
LSP
distribution
using
B
to
transport
that
was
adopted.
We
had
the
LSP
our
with
standard
Dykstra
path.
A
Selection
adopted
those
key
milestones
were
were
met.
Who
were
making
good
progress
on
that?
We
had
wanted
to
get
the
gang
specification
for
LSB
are
going,
there's
still
some
work
to
be
done
there,
and
that
will
be
addressed
from
some
of
the
comments
from
Agnes
on
to
sort
out
well
how
we
move
on
from
there
and
then
we'll
have
a
discussion
around
the
l3
BL,
which
was
previously
known
as
Ellis
OE,
adopted
as
a
work
group
ID.
A
Now
a
bit
of
a
late
adoption
from
from
a
working
group
status
perspective
like
I
mentioned
a
moment
ago.
We
seem
to
be
doing
doing
reasonably
well
from
a
progress
perspective.
We
had
some
aggressive
timelines
from
the
outset.
We
had
want
to
make
rapid
progress.
Given
the
state
of
things.
There
is
an
LS
we
Python
3
demo
available
so
effectively
an
application
people
can
play
with
and
utilize
the
link.
It's
there
over
in
a
github
free
to
use
and
to
play.
A
They
said
an
LS
BR
has
made
good
progress
as
a
main
spec
as
well,
and
we'll
get
an
update
on
that
within
this
working
with
some
documents
that
appear
to
be
ready
for
work.
Last
call
was
the
applicability
statement
document
and
the
BGP
SDF
document.
We
had
talked
about
this
back
in
March.
What
we'll
do
is
we'll
be
a
little
more
aggressive
after
this
meeting
to
make
sure
we
get
the
reviews
in
and
get
the
number
of
reviewers
identified
and
follow
up
with
those
reviewers.
So
we
can
get.
A
B
B
B
C
Given
that
this
BG
pls
we're
using
a
very
small
subset
of
it
for
SPF,
you
know
given
the
whole
universe
of
it.
So
how
much
we
put
into
the
initial?
That's
a
question
you
know
doing
it
all
doing
doing
both
bgp
LS,
SPF,
family
and
the
regular
standard
bgp
LS
would
address.
Family
would
be
good,
but
you
know:
they're
gonna
just
definitely
share
some
TVs
and
things,
but
the
amount
of
amount
of
work
is
a
lot
different
I'm
just
making
that
point.
So
that's
gonna
have
to
be
a
decision.
D
D
E
So
Kate
Patel
arcus
I
was
simply
going
to
ask
you
to
clarify
a
little
more,
but
before
I
do
that.
Let
me
give
you
a
status.
I,
I'm
gonna
present
the
status
on
LS
fear.
We
have
device
based
model
very
well,
hashed
out,
mind
you
that,
as
a
she
said,
the
encoding
in
LS
we
are
follows.
The
formats
of
LS
address
family.
However,
there
isn't
a
model
defined
for
Ellis
address
family
in
idea
itself.
E
The
base
bgp
model
doesn't
cover
it,
and
it's
not
intended
to
and
as
part
of
doing
this
work,
we
are
also
going
to
come
out
with
a
yang
model
or
idea
for
LS
ettus
family
as
well,
because
it
applies
here-
and
we
have
done
the
work
here
right.
So
I'm
going
to
talk
a
little
bit
more
in
my
presentation,
but
I
thought
I.
Just
let
you
know
the
device
model
is
ready.
Okay,.
F
D
D
D
E
G
G
Okay,
so
remember
the
basic
point
of
the
entire
l3,
dr
and
I'm
probably
gonna,
say:
LSO,
we
half
a
dozen
times
gun
still
getting
used
to
the
name,
change
but
remember
the
goal.
This
is
we're
trying
to
discover
the
topology
and
liveness.
You
know
a
lot
of
this
is
about
just
detecting
when
cables
are
miss
plugged
and
the
topology
isn't
what
we
expected.
That
kind
of
thing-
and
this
is
from
bgp
SPF
right-
that's
the
point
of
all
this
mechanism
and
we're
trying
to
keep
it
as
simple
as
we
possibly
can.
G
There's
some
entertaining
discussions
within
the
author's
team
about
how
simple
that
is.
Randy
and
I
tend
to
be.
If
it's
more
complicated
than
a
spoon,
it's
too
complicated
Kira
likes
a
little
bit
more
than
that,
but
we're
having
fun
so
again
reminder
of
how
the
stack
looks.
Okay,
you've
got
Ethernet
frames
which
the
PD
use
for
this
protocol
and
we're
doing
that
link
checks
with
the
a
fuse
and
Saffy's
and
then
we're
feeding
stuff
up
to
bgp
SPF.
G
G
G
We
have
this
little
transport
protocol,
that's
built
in
here,
it's
very,
very
small
and
it
can
handle
to
the
32
octet
PDUs.
We
tried
to
make
it
clear
which
bit
is
which
so
there's
the
transport
layer
and
there's
the
PDUs
layered
on
top
of
that,
and
we
try
to
have
a
clear
delineation
between
that.
The
exact
number
here
to
224th
datagrams
that
was
last
week,
I
think
it's
2
to
the
15th
datagrams.
G
Now
we
keep
fiddling
without
trying
to
get
the
numbers
right,
but
the
problem
is,
you
want
to
have
enough
to
be
able
to
carry
the
largest
PDU.
That
makes
sense
in
this
protocol,
but
you
also
don't
want
really
ridiculously
large
numbers
of
frames
flying
around
with
a
relatively
lightweight
transport
protocol.
G
So
it's
a
trade-off
thing
not
so
the
upper
frame
here
is
showing
you
what
the
transport
headers
look
like
and
it's
pretty
straightforward
is
just
version
number,
there's
a
sequence
number
so
that
we
can
tell
whether
or
not
we're
doing
the
same
print
the
same
PD
we're
doing
last
time
or
not.
Let's
actually
change.
The
Elbit
is
still
the
same.
There's
the
Datagram
number
the
Datagram
length.
There's
a
checksum
because
you
don't
send
stuff
around
raw
Ethernet
frames
without
a
checksum.
G
If
you
want
to
survive
and
there's
the
payload
and
that's
all
there
is
to
it,
so
you
put
together
a
bunch
of
these
data
grams.
You
do
a
PD
you
and
at
that
point
you've
got
a
PD,
you
type
and
a
payload
lengths
and
signature
stuff
which
we'll
talk
about
in
a
bit
and
you've
got
some
payload
not
much
to
it.
G
We're
not
running
TCP.
Ok,
there's
no
IP
at
one
we're
doing
this
so
that
that's
not
going
to
work.
In
any
case,
we
want
something
lightweight
Randy
likes
to
think
of
this
as
TCP
like
I.
Don't
think
it's
that
complicated
I
used
to
maintain
a
TCP
implementation.
This
is
orders
of
magnitude
less
complicated.
This
is
more
like
TFTP,
but
it
works
okay.
It's
simple!
G
It
gets
the
data
through
and
we
have
a
little
bit
of
mechanism
for
being
able
to
deal
with
retransmissions
and
out
of
order,
delivery
and
that
sort
of
thing
and
back
off,
because
we're
trying
to
learn
from
the
mistakes
of
the
1990s
and
not
just
flood
everything
all
the
time.
It's
pretty
simple
and
I
think
it's
stable
at
this
point.
G
We
might
end
between
a
little
bit
more
depending
on
discussions
about
you
know
large
numbers
of
frames
flying
around
and
having
to
retransmit
all
of
them
if
you
lose
something,
but
it's
been
pretty
stable
for
months
now.
The
stuff
above
that
is
a
stateful
session
per
peer.
Okay,
so
you've
got
a
relationship
between
two
peers
as
a
session,
pretty
straightforward,
we
do
have
a
way
of
great
of
gracefully
restarting
now.
This
is
one
of
the
carrier
enhancements.
It's
mostly
a
good
thing.
G
It
adds
complexity
still
under
discussion,
but
Kara
likes
to
think
of
this
as
being
very,
very
much
like
BGP
I'm,
an
old
DNS
guy.
To
me,
the
mechanism
looks
a
lot
like
DNS,
but
it's
basically
the
same
kind
of
mechanism
in
either
case,
you've
got
a
serial
number
okay,
so
you
send
stuff
around
and
what
serial
number
was
that
all
right?
And
then,
if
you
have
to
restart
the
open
message,
now
has
a
serial
number.
G
G
Okay,
we
do
have
mechanisms,
we
had
to
add
an
explicit
act
mechanism
because
we
discovered
there
a
couple
of
places.
We're
detecting
duplicates
was
a
little
tricky,
so
there's
actually
an
explicit
back
mechanism
for
everything
now
and
we
do
didn't
retransmit
if
stuff
doesn't
assume
it's
evolving
into
a
small
transport
protocol.
As
we
said,
hello
frames
and
keepalive
frames,
sorry
PDUs
are
still
different
because
they
have
somewhat
different
requirements.
There's
some
discussion
about
whether
or
not
we
really
need
the
hello
and
keep
alive
but
to
be
different
things.
G
If
we
were
just
beaconing
the
hellos
all
the
time.
That
would
be
an
indication
that
the
end
point
is
still
alive.
So
why
do
you
need
to
keep
alive?
But
the
heath
lives
are
intended
to
be
Malta
unicast
between
two
piers
and
yes,
I'm
still
here,
yes,
I'm
still
here,
yes,
I'm
still
here,
as
opposed
to
hello,
which
is
the
hi
I
just
came
up.
Anybody
want
to
talk
to
me
in
the
case
of
a
point-to-point
link,
which
is
the
usual
case.
G
You
only
need
to
do
the
hellos
when
you're
starting
up
once
you've
got
the
pier
you
know
who
the
address
is.
At
the
other
end,
the
the
the
link
layer
dress
is
at
the
other
end,
you
don't
really
need
to
keep
beaconing
the
lows
in
a
multi
drop
thing:
we've
got
multi
access,
your
conventional
Ethernet,
and
it's
not
just
point-to-point.
You
might
need
to
keep
beaconing
them
so
that
new
people
joining
get
the
message
so
they're.
Just
these
two
PT
is
that
they
look
a
lot
alike,
but
they
have
somewhat
different
behavior.
G
So
at
least
for
the
moment,
they're
still
separate,
we'll
revisit
whether
or
not
they
need
to
be
merged.
At
some
point.
Oh
sorry,
that
got
to
this
a
little
early
so
yeah,
we
don't
need
to
repeat
the
hello
as
if
it's
just
a
point-to-point
link,
because
once
you
know
the
other
endpoint
you're,
not
learning
anything
new.
G
Okay,
some
new
stuff
encapsulation
flags
we
had,
but
we
didn't
have
I,
don't
think
the
announced
withdrawal
and
I
don't
think
we
had
the
over-under
bit
either
care.
The
over-under
bit
is
new
since
last.
So
this
is
an
overlay
underly
thing
if
you've
got
a
complex,
topology
and
you've
got
it
as
a
backbone.
Within
your
rack
and
you've
got.
You
know
land
that
you're
using
just
for
communication
between
the
Tor
and
the
servers
within
the
rack.
G
But
you
also
want
to
be
able
to
take
things
that
are
in
side.
The
rack
and
have
them
have
public
addresses
outside
the
rack.
So
you've
got
this
overlay
underlay
mechanism,
the
underlay
is
the
conversation
within
the
rack,
the
overlays,
the
stuff
you're
transporting
out.
So
we
just
have
a
bit
to
indicate
which
kind
of
address
you're
talking
about
for
any
particular
encapsulation,
because
it
makes
it
easier
to
sort
out
which
things
need
to
propagate
where
we
had
an
explicit
ACK
and
error
message.
G
G
Okay,
we
have
this
vendor
extension
mixin.
That
was
actually
in
I
think
by
the
time
we're
in
Prague.
It
uses
enterprise
numbers
all
on
nibs,
because
it
was
an
existing
mechanism
is
used
for
extensions
other
things.
We've
actually
got
a
use
case
for
that
already
with
somebody
doing
something
in
another
working
group,
it's
pretty
trivial,
ok,
logical,
link,
endpoint
identifiers,
I,
looked
at
this
and
said
what
the
hell
is.
That
Randy
just
says:
I
just
made
it
up.
G
The
problem
is
that
I
go
back
far
enough
that
when
I
was
doing
device,
drivers
Ethernet
was
called.
You
know,
Dix
Ethernet.
You
know
there
wasn't
a
lot
to
it.
These
days,
layer
2
was
a
complicated
ecosystem
with
multiple
layers
of
stuff,
and
sometimes
your
MAC
address
isn't
really
your
MAC
address
or
your
MAC
address
isn't
really
an
endpoint
identifier
or
there's.
G
You
know
a
bunch
of
bonding
stuff
going
on,
or
god
only
knows
what
so
in
a
simple
Dix
Ethernet
world
your
endpoint
would
identify,
would
just
be
your
MAC
address,
but
sometimes
the
topology
is
more
complicated
than
that
at
layer
2
and
you
need
something.
That's
your
system,
identifier.
So
it's
a
something
abstract
concept
system,
identifier
and
which
interface
did
you
receive
this
on?
That's
generally
the
endpoint
identifier
in
terms
of
what
you're
writing
in
your
code,
ok
and
there's
a
question:
do
we
need
a
mandatory
to
implement,
link
layer
and
point
identifiers?
G
G
We're
plan
I,
putting
this
stuff
into
our
operating
system
and
we're
hoping
maybe
we'll
be
able
able
to
do
some
kind
of
an
interrupt
thing
in
Singapore
and
send
this
stuff
to
last
call
still
up
in
the
air,
but
that's
the
hope
and
as
I
mentioned,
we've
already
got
somebody
using
the
extension
mechanism.
So
Niraj
has
this
thing
over
in
deaths
the
evpn
mechanism.
G
Ok,
we
really
want
people
to
review
the
draft.
Randy
says
this
every
time.
It's
still
true,
please
review
the
draft.
It
would
be
nice
if
we
could
get
review
before
having
to
send
it
to
working
group
last
colleges
to
wake
people
up,
I
want
to
specifically
acknowledge
Paul
Condon.
Thank
you
for
having
repeatedly
reviewed
the
thing
for
is
very
much
appreciated,
but
it
would
be
nice
of
other
people
to
please
okay
and
that's
it
for
the
main
protocol.
The
other
one
is.
G
This
is
like
sixty
seconds
okay,
so
we
added
another
PD
you
type
for
transporting
around
sort
of
the
minimal
upper
layer
protocol
configuration
information.
That's
really
it
right
there,
this
one
slide:
okay,
we're
really
hoping
to
keep
that
to
the
minimum
amount
of
necessary
configuration
stuff.
For
you
know,
we
don't
want
to
turn
this
into
all
of
BGP
again,
just
what's
the
minimum
you
need.
Care
can
speak
more
to
what
actually
needs
to
go
in
here
than
I
can,
but
that's
pretty
much
it
for
the
other
one.
We
don't
want
to
be
replacing
BGP.
G
G
Pretty
much
okay,
okay!
So
here's
the
here's,
the
explanation
of
what
we
have
currently
expect
to
go
in
for
BGP.
Okay,
you've
got
your
ass
and
your
before
peering
address
prefix
length,
BGP,
authentication
data;
okay,
that's
it
for
make
breeze!
Oh
I
did
not
do
any
slides
for
the
signing
mechanism.
We've
been
working
on
because
that's
really
we,
the
draft,
isn't
published
yet.
So,
there's
no
point
asking
you
to
read
the
draft,
but
we've
managed
to
keep
it
very,
very
simple.
G
So
far,
just
going
to
talk
about
it
for
one
minute,
it's
basically
just
signatures.
Okay,
and
there
are
three
levels
you
can
do
with
this.
You
can
have
screw
it
I,
don't
care
about
signatures
at
all,
in
which
case
you
leave
the
signature
field
empty.
You
can
have
what
the
security
world
is
called.
Tofu
trust
on
first
use
where
it's
like
I.
Send
you
a
key-
and
you
say:
okay,
I
never
seen
you
before,
but
fine
whatever
the
rest
of
this
session
will
be
signed
with
this
key
okay,
fine
whatever.
G
So,
all
that
that
proves
to
you
is
that
somebody
hasn't
jumped
in
and
hijack
the
session.
Sometimes
that's
all
you
need
depends
on
your
on
your
operation
model.
The
third
level
is
very,
very
lightweight
PKI,
yes,
the
word
BKI
is
scary,
but
we
had
help
from
a
friend
who
said
no,
you
do
not.
Damn
well
need
x.509
here,
so
the
PKI
is
basically
just
a
signature.
The
certificate
literally
consists
of
a
signature
by
a
certification
Authority.
That's
it
all.
It's
telling
you
is
this.
G
Il3
dll
speaker
is
an
authorized
member
of
the
group,
as
opposed
to
say
the
janitors
laptop.
That's
all
it's
telling
you
if
you
care
about
that
level
of
assurance,
the
mechanism
is
there.
If
you
don't
care
about
it,
you
don't
have
to
use
it.
We've
got
the
draft
mostly
written.
It
should
be
ready
within
a
month
or
so
at
the
most,
and
certainly
ready
for
people
to
review
by
the
next
meeting.
That's
it
questions.
H
G
H
I
had
a
great
update
on
this
draft.
There
was
a
lot
of
changes
and
clarifications
that
then,
that
the
additions
of
the
overlay
underlay
things
brought
a
lot
of
questions
up
for
me
anyway.
So
that's
primarily
for
the
I
would
say
you
know
the
Geneva
clan
style
over.
They
underlaid,
you
don't
consider
a
VLAN
layer
to
as
a
overlay,
underlay
right,
I,
think
I
think
the
VLANs
are
actually
why
you
also
modified
the
lle
I.
E
Yeah,
that's
correct
here
for
Dolores,
and
this
is
also
assuming
say.
For
example,
a
server
has
an
overlay
addresses
in
a
manner
that
can
be
made
accessible
at
the
LIA,
where
l3
DL
can
announce
it
out.
If
that
happens,
we
did
just
a
bit
here
that
can
differentiate,
saying
this
is
an
overlay
versus
an
underlay
address
yeah,
so
so.
H
Effectively
that
allows
you
to
sort
of
aggregate
rather
than
having
to
run
instances
of
stuff
at
that
layer.
I'm
wondering
if
you
can
do
a
similar
thing
at
the
VLAN
layer,
because
what
I'm
seeing
you're
gonna
be
right
now,
I
think
you're
running
an
instance
of
l3
dl,
/
VLAN,
you
know,
and
the
hellos
and
potential
keeper
lives
might
generate
a
lot
of
chatter
I'm
wondering
if
there's
a
way
to
do
a
similar
approach
of
that
as
well.
Anyway.
H
H
E
E
A
Enik
wander
back
there
bleats
back
there,
they
went
had
a
chance
to
sign
the
blue
sheets.
H
Okay,
thanks:
okay,
I'm
Paul,
Congdon
and
I'm.
Also
acknowledging
Paul
Batra
he's
not
here
he,
but
he
is
working
on
with
me
on
the
I
Triple
E
to
kind
of
help
do
this
definition,
so
we
have
a
project
in
return.
I
won
a
B
D
H
I
can
give
you
the
whole
I
Triple
E
decoder
ring
for
all
the
letters
if
you're
interested.
But
fundamentally
this
is
a
what
we
call
lldp
version
two,
so
first
major
disclaimer
I'm
on
an
individual
here,
I'm,
not
speaking
on
behalf
of
I
Triple
E.
H
So
you
know
I'm
just
telling
you
my
perspective
of
what
we're
doing
here.
So
just
as
background
you
can
look
at
these
at
your
leisure.
We
originally
proposed
a
update
to
lldp
back
in
January,
and
then
we
did
sort
of
a
initial
first
cut
of
evaluation
against
the
lsv
our
requirements,
because
the
objective
was.
Could
we
support
try
to
support
what
lsv
our
needs
by
making
modifications
to
lldp?
H
There's
been
some
liaison
exchanges
back
and
forth
between
a
Triple,
E
and
ITF
on
the
topic,
and
you
know
we
we
now
have
a
project
approved,
there's
some
final
logistics
within
the
I
Triple
E
to
actually
get
it.
You
know
slowly
staff,
but
we're
at
a
point
where
we
can
kind
of
move
forward.
So
what
was
kind
of
driving
all
this?
You
know
from
our
perspective,
you
know
it's
kind
of
like
discovery
protocols
going
wild
everywhere.
H
We
even
worked
with
the
ITF
on
a
virtual
station
that
interface
discovery
protocol
for
nvo
3
and
that
takes
advantage
of
lldp,
but
sometimes
the
amount
of
information
that
needs
to
be
exchanged.
There
is
large,
so
well
if
he
doesn't
always
fit
perfectly,
there's
also
another
project
and
the
I
Triple
E
called
Auto
attach,
which
does
assignment
of
V
vids,
and
I
Syd's,
if
you're
familiar
with
provider
backbone,
bridging
that
also
runs
into
size
limitations
with
lldp.
But
it's
it's
a
effectively
an
application
running
on
top
of
LOD
P.
H
So
there's
a
lot
of
a
lot
of
use,
a
lot
of
need
and
we
were
really
stretching
the
needs
for
for
LOD
P.
So
it
was
clearly
time
to
do
something
and
revise
that
protocol.
As
we
all
know,
it's
pretty
widely
deployed
people
have,
you
know,
kind
of
quote,
used
it
and
in
many
different
ways,
many
different
environments.
H
Not
you
know,
data
centers
to
wireless
networks,
to
you,
know,
campus
lands
and
there's
a
facility
to
define
your
own
information
either
as
a
standards
organization
or
as
an
individual
vendor,
and
people
have
come
up
with
all
kinds
of
use
cases.
So
the
amount
of
data
that
people
are
wanting
to
send
just
keeps
growing.
So
so
we
needed
to
start
this
project,
and
so
the
fundamental
thing
was
to
scale
it
to
allow
what
we
call
we're,
calling
this
informally
lldp
applications
or
people
that
use
lldp
data.
H
We
want
to
be
able
to
scale
the
amount
of
data
that
they
they
can
share
and
so
and
clearly
lsv.
Our
requirements
were
one
of
those
things
we
also
had
requirements
in
and
we're
doing,
time-sensitive
networking
you
know
debt
net
style
stuff
in
theatrically
as
well
and
and
there
was
a
need
to
actually
go
the
opposite
direction
and
shrink
lldp
PDUs
so
that
you
can
schedule
them
in
mix
them
in
with
other
traffic.
So
so
that's
a
facility
that
we're
also
doing
so.
H
This
project
is
as
an
amendment
to
the
the
current
standard
and
it's
going
to
allow
what
we
call
TLB
databases
to
consists
of
multiple
frames.
So
so
think
of
what
you
have
is
a
database,
it's
just
a
bunch
of
TLV,
so
in
in
LS
VR,
you
have
the
IP
address
encapsulation
list
of
various
things
that
it's
that
that
node
has
that's
part
of
an
overall
database
that
it
wants
to
share
with
its
peer.
H
So
just
think
of
it,
as
you
know,
a
generic
database
and
now
that
database
needs
to
be
bigger
than
what
can
fit
in
a
single
layer
to
frame,
and
so
anyway,
let's
see
what
else
that
one
of
the
key
advantages
to
was
to
allow
this
new
version
of
lldp
nose
to
still
talk
to
the
old
version
as
though
they
were
an
old
version.
So
if
you
have
LDP
running
all
around
anywhere
else
and
your
new
updated
version,
you
can
still
exchange
that
first
frames
worth
of
data
and
everything
is
fine.
It's
just.
H
You
can't
do
more
than
one
frame
to
an
old
version
that
guy
has
to
get
upgraded
so
anyway,
we
think
it's
we
think
just
this
facility
and
the
way
in
which
we're
doing
the
extension
you
know
should
satisfy
a
lot
of
discovery
needs
for
other
many
of
these
new
use
cases
that
are
out
there.
So
what
were
some
of
these
objectives?
First,
one
is
to
be
completely
transparent
to
the
users
of
lldp.
So
again,
like
an
application,
that's
expecting
data.
We
don't
want
that
application
to
have
to
change
at
all.
H
It's
just
now
allowed
to
send
and
receive
more
data
than
it
used
to
that's
the
from
the
user
level.
It
should
look
the
same,
and
so
we
again
we
want
to
support.
You
know
more
than
one
frame
worth
of
data,
I
think
initially
lsv
our
requirements
were
around
64
K,
they
may
be
bigger.
Now
it
looked
like-
or
at
least
you
have
the
facility
to
send
lots
of
data
so
and
then,
of
course,
we
want
to
as
I
mentioned,
for
time-sensitive
networking.
H
We
also
want
to
shrink
things
if
possible
or
have
the
ability
to
configure
it
in
a
way
to
shrink
the
data
so
that
you
can,
you
can
schedule
it
again,
communicate
with
version
ones.
It
should
work
over
shared
media,
although
we're
gonna
really
more
or
less
optimize
it
for
point-to-point.
So
that
will
be
the
the
better
use
case
and
one
of
the
key
things
is:
we
want
to
make
sure
we're
ensuring
that
the
integrity
of
that
data,
so
we
know
that
we've
received
everything
that
that
pier
is
trying
to
to
advertise.
H
H
Another
key
thing
about
this
new
proposal,
so
changes
in
the
the
most
recent
proposal
is
that
we
support
what
we're
calling
pacing
of
refrain
of
frames
at
the
receiver,
so
in
other
words,
instead
of
just
blasting
out
a
ton
of
frames
to
a
node
that
only
has
one
buffer
for
we're.
Gonna
allow
that
receiver
to
consume
the
data,
at
whatever
rate
it
needs
to.
So
if
it's
a
rich
implementation
with
a
lot
of
memory,
it
may
request
a
whole
batch
of
frames.
H
But
if
it's
a
very
lightweight
IOT
type
implementation,
it
may
just
get
that
data
one
frame
at
a
time
it
really
it's.
So
it's
receiver
paste,
and
that
was
a
key
change
in
the
latest
proposal
and
again
we
wanted.
We
don't
want
to
really
try
to
increase
network
traffic.
We're
gonna,
send
more
frames.
As
you
know,
lldp
is
a
periodic
protocol.
Every
so
often
just
sends
out
the
one
frame.
So
the
version
two
will
look
exactly
like
that.
They'll
still
just
be
one
frame
that
gets
sent
out.
H
However,
if
you
need
the
extension
data,
a
receiver
will
ask
for
it
and
then
you'll
you'll
transmit
it,
so
we
won't
just
be
multi
casting
stuff
all
over
the
place
and
then,
since
we
have
the
the
book
open,
if
you
will
and
and
and
the
pin
to
modify
it-
and
let's
look
at
maybe
some
other
things
that
might
be
of
interest,
so
maybe
supporting
a
larger
TLV
itself.
Today,
the
the
sizes
is
restricted
by
the
format
we
could
consider
larger
formats.
For
extensions
and
I
know.
The
authentication
idea
is
a
high
high
want
here.
H
You
guys
have
a
draft
in
play
for
that,
so
that
could
be
an
example
of
something
is
well
to
consider.
Okay,
so
just
as
a
quick
reminder,
this
is
how
the
current
operation
works.
Very
simple
protocol
widely
deployed.
Think
of
these
as
again,
we
think
of
them
as
databases.
It's
just
you
have
as
a
local
agent
I.
Have
my
local
information
I
want
to
tell
people
about
so
just
periodically,
I
send
it
out,
and
the
receiver
gets
that
and
he
compares
with
what
he
got.
H
Last
time,
if
it's
different,
he
signals
the
application
that
something's
changed
and
he
updates
everything,
so
the
entire
database
got
got
updated
and
then,
if
you
change
something
locally,
that'll
trigger
the
the
transmission
quicker.
So
it's
it's
very
simple.
You
know
protocol
not
too
complicated,
so
the
proposal
for
the
new
thing
is
to
define,
use
the
current
frame
format
for
the
the
level
one,
but
to
find
a
new
PDU
or
a
new
TLV
in
that
PDU.
H
So
again
we
still
have
the
same
version.
One
frame
that
an
lldp
one
implementation
would
be
able
to
receive
it,
but
will
they
define
a
new
lldp
extension
PDO,
so
a
new
frame
and
what
we'll
do
is
we're
gonna
describe
those
new
frames
in
a
manifest,
so
the
first
frame
that
we
send
that
looks
like
lldp
v1
it'll
have
an
additional
TLV
that
has
effectively
a
manifest
defining
all
the
other
tlvs
that
are
out
there.
H
So
then,
when
you
receive
that
you'll
be
able
to
know,
if
you
have
all
the
extension
data
or
not,
and
if
you
don't,
then
you
request
it
frame
at
a
time
or
batch
at
a
time
whatever.
Whatever
you
want,
so
that's
the
high
level,
that's
kind
of
how
it
works
so
yeah
the
manifest
defines
a
way
to
to
identify
each
of
the
extension
frames
and
again,
the
transmission
of
those
extension
frames
is
going
to
be
controlled
by
the
receiver
he's
going
to
pace
it
at
what
rate
he
wants.
H
I
think
that's
pretty
clear
and
I'm
going
to
the
details
and
the
another
important
attribute
is
we
want
a
version,
one
implementation
that
receives
an
extension
PD
you
to
basically
ignore
it,
because
if
you
recall
a
version,
one
implementation,
when
it
receives
an
lldp
frame,
it
throws
away
everything
it
knew
before
and
replaces
it
with
this
one
frame,
new
frames
worth
of
data.
So
we
have
all
these
extra
frames
that
are
extension
frames.
H
They'll
still
have
the
the
chassis
ID
port
ID,
so
you
know
who
came
from
the
pier
and
then
they'll
have
some
way
that
identifies
them
like
I'm
frame,
number
5
of
10,
you
know
and
that'll
be
a
new
part
and
then
the
rest
of
it
will
just
be
tea
obese.
They
could
be
new
formatted
team
Ovie's
or
they
could
just
be
the
existing
ones,
we'll
have
to
decide
and
then
there's
this
new.
It
can
request
for
extension
mess.
So
this
is
again
how
the
receiver
says:
okay,
I'm,
missing
frame.
H
Five,
please
give
me
frame
five
or
I'm
missing
frames,
one
through
seven,
give
me
one
through
seven
and
and
then
once
the
the
receiver
has
everything
he
he
knows
by
the
manifest
that
that
he's
up-to-date
and
he
can
signal
the
application
that
the
date
is
available.
So
this
will
support
you
know
again:
shared
media
as
well.
H
Multiple
peers
on
shared
media
won't
be
as
optimized
for
shared
media,
but
it'll
it'll
it'll
work
there
and
again
we
talk
about
receiver
pacing,
and
you
will
only
ask
for
things
that
are
out
of
date
and
then
there's
no
change
to
the
periodic
transmissions.
You'll
still
periodically
transmit
the
first
frame
would
the
manifest
and
the
TTL
would
would
rely
on
that.
So
in
this
situation
same
same
agents,
remember
they
just
have
more
data.
They
have
this
manifest.
That's
required
in
the
base
TLV.
H
So
when
something
changes
locally,
you'll
send
out
that
first
frame
and
the
receiver
will
get
that
and
he'll
look
at
that
manifest
and
compare
and
say
I'm
missing
some
some
frames
so
he'll
send
a
request
for
extension
and
that'll
be
a
unicast
packet.
It
won't
be
multicast,
it'll,
be
unicast
back
to
the
to
the
sender
and
then
he'll
send
those
extension
PDUs
as
he
needs,
and
once
the
receiver
has
collected
all
of
that
data
it'll
signal
the
application
that
something's
changed.
We've
got
a
new,
a
new
database
and
so
again
from
the
applications
perspective.
H
H
So,
as
I
mentioned,
we
had
done
an
evaluation
sort
of
what
lsv
our
requirements
were
in
if
I
were
to
say
at
50,000
foot
that
you
know
your
LCR
is
doing
a
couple
things
like
you
said
it's,
it's
exchanging
a
database
of
information,
encapsulation
types
and
and
things
and
it's,
but
it's
also
doing
you,
know
this
layer
to
lie
this
and
it
may
have
an
authentication
scheme
and
some
vendor
extensions,
and
things
like
that.
So,
if
I
look
at
with
our
new
proposal,
could
can
we
support
these
things?
These
is
sort
of
the
the
guesstimate.
H
Yes,
I
think
you
know.
Obviously
the
lle
I
is
just
a
chunk
of
data.
Relatively
small
attribute
list
is
the
same.
We
would
just
despite
define
a
TLB,
the
authentication
data.
We
need
to
see.
That's
why
I
was
asking
the
question
about
the
size,
because
it
would
it
fit
in
the
current
TLV
or
do
we
need
to
grow
the
size
of
a
TLB
I.
Think
the
encapsulation
and
addresses
are
fine.
One
thing
to
keep
in
mind:
this
came
up
in
a
hall
conversation
there's
multiple
types
of
tlvs
in
lldp.
H
Usually
you
just
receive
one
of
them,
but
it's
possible
to
see
receive
multiple
of
the
same
TLB
type.
So
in
other
words,
if
I
have
let's
say
a
a
layer,
three
encapsulation
TLV
that
I
define
for
LS,
vr,
I,
K
and
I
need
to
send
more
encapsulations
than
will
fit
in
one
TLB.
Well,
I
just
send
multiple
of
those
tlvs
that
works.
You
don't
have
to
you
know
you
only
have
one
TLB
of
one
type,
so
you
can
replicate
stuff
so
keep
the
lives
the
way
they're
defined
in
l3
DL
right
now,
I'd
be
one.
H
H
The
acts
are
sort
of
you
know
an
implicit
part
here
with
the
manifests
and
knowing
that
you
you've
got
things
and
then
we
do
have
vendor
extensions.
That's
already
exist
today
and
it's
been
been
widely
used,
so
I
think
in
general,
for
the
information
exchange
that
we
need
I
think
we
should
be
able
to
do
it.
So
if
we
wanted
to
start
to
say,
hey
could
when
we
were
gonna
use
lldp
for
for
LSB
our
requirements.
What
we
really
need
to
be
done
well,
I
think
the
first
thing
thing
would
be.
H
We
need
a
draft
to
write
to
describe
these
new
tlvs
that
are
specific
to
the
IETF.
So
so
we
would
create
a
internet
draft
that
describe
the
format
of
those
TL
B's.
We
already
have
a
pretty
much
that
format
Danelle
3dl-
maybe
maybe
it's
maybe
that
format
work
says
is.
Maybe
it
means
a
slight
modification,
but
we
would
just
use
lldp
as
a
transport
rather
than
it
L
three
DL
or
in
addition
to
L
3
DL.
So
we
would
need
a
draft
for
that.
We
would
say,
consider
some
alternatives
for
liveness
there's
a
standard.
H
We
have
connectivity,
fault
management,
it's
pretty
widely
deployed
as
well
check
your
local
Broadcom
chip,
it's
probably
already
in
there.
So
that
already
does
layer
2,
you
know.
Liveness
requires
some
configuration,
but
but
that's
there
and
then
of
course
make
sure
as
we
progress
this
LTP
v2
standard
that
you
know
it's
staying
within
it's
meeting
the
needs
of
LS
VR.
So
providing
technical
input,
review
I'm
sure
we
could
set
up
some
liaison
style
way
of
sharing
documents,
that's
open
and
everybody
can
play
so
that
would
be
another
suggestion
so
anyway,
that's
it
there's
a
so.
H
J
Hi
John
Scudder
says
this
was
a
you
know,
sort
of
compelling
ad
good
elevator
pitch
that
and
I
was
glad
to
see
your
your
bullet
that
you
just
spoke
to
on
the
last
or
second
last
slide.
You
don't
have
to
go
back
where
you
said
you
know,
let's
we
can
come
up
with
a
way
to
provide,
provide
the
spec
so
that
people
can
read
it
because
that
was
you
know
like
by
the
time
you
had
gotten
through
your
first
few
slides
and
you
know
sitting
in
the
back
thinking.
J
H
Yeah,
so
that
when
we
do
draft
developments
of
the
specs,
it
is
a
working
group
only
document,
so
they're
password-protected,
it's
kind
of
a
widely
known
password,
but
I
didn't
I,
didn't
say
that,
but
also
we
have
means,
for
you
know
formal
liaison
between
standards.
Organizations
to
make
those
drafts
available.
So
be
honest.
I
H
It's
there's:
no,
it's
not
difficult
to
join
and
become
a
working
group.
Member
I'd
also
like
to
add
that,
during
the
what
we
call
the
task
group
ballot
phase,
which
is
you
know,
the
early
phases
of
the
first
rap,
we
pretty
much
will
accept
comments
from
from
anybody.
You
know
I
mean
you
I,
it's
the
there
is
a
process,
but
we
typically
are
gonna.
Take
input
from
anybody.
So
you
know
you,
can
you
don't
have
to
be
voting
membership
and
all
that
kind
of
stuff
to
make
a
comment
exactly.
I
H
I
A
E
E
Full
implementation
is
now
done
on
the
spec.
There
is
another
implementation.
There
is
also
on
the
way,
probably
from
an
open
source
community,
and
at
least
three
operators
have
signed
up
to
test
and
evaluate
the
protocol
itself
to
see
how
it
operates
from
a
cost
standpoint.
It's
fairly
stable
as
part
of
implementing
the
draft.
The
yang
model
is
already
in
place,
like
I
had
mentioned
earlier,
the
formats
of
SPF
reuses
LS
Safi
of
bgp
itself.
E
We
do
want
to
start
working
on
while
we
work
on
the
mod
models
draft.
We
do
want
to
start
working
on
protocol
implementation
draft
and
probably
an
experienced
draft
if
possible,
and
people
keep
on
telling
me
that
this
is
a
new
protocol,
while
I
tend
to
think
of
this
as
just
a
BGP
Safi
extension.
But
if
it's
a
new
protocol
we
probably
should
have
an
implementation
and
experience
draft
from
an
implementation
perspective.
All
sections
of
draft
have
been
implemented
pretty
much
all
of
them.
E
There
was
challenge
in
generating
in
some
cases
what
the
remote
router
ID
can
be
when
the
servers
don't
run
BGP
SPF
or
when
you
start
to
have
appearing
model
that
is
reflection
base,
which
is
not
an
inbound
peering
model.
We
basically
gather
this
information
either
from
lldp
or
l3
DL
or
the
protocol
of
choice.
We
figure
out
who's
the
remote
endpoint
on
the
link,
use
that
information
to
source
and
compute
SPF
as
we
need
then
again.
Pfd
is
always
used
to
leverage
for
abide
by
directional
link
verification.
E
So
we
do
that
using
DFT
we
make
sure
PFD
is
turned
on
and
as
long
as
the
link
is
up,
the
neighbors
ship
is
up.
Finally,
from
intro
of
also
standpoint,
we
ran
this
against
different
IGP
protocols.
As
draft
has
mentioned,
it
does
give
higher
preference
to
LS
VR
and
from
that
perspective,
when
you
start
to
do
tiebreaking,
it's
pretty
straightforward,
where
you
take
LS
via
routes
as
a
preference,
give
them
a
higher
preference
and
implement
them,
install
them
in
fibbin
forwarding
so
from
an
implementation,
strength.
Standpoint,
it's
fairly
simple
and
straightforward.
E
As
soon
as
we
get
second
implementation
from
the
open
source,
we
like
to
start
doing,
Interop
the
draft.
That's
all
I,
have
the
drafts
like
I,
said
again
in
fairly
stable
State.
We
would
really
welcome
reviews
at
this
time.
Any
feedback
comments
would
be
appreciated
because
the
implementations
are
under
way.
We
can
change
it
if
needed
or
else
consider
pushing
it
towards
Ellis
call,
probably
seen
from
at
Singapore
ITF
and
maybe
later
yeah.
A
J
A
So
that's
the
end
of
the
draft
reviews
for
this
agenda.
We
didn't
want
to
cover
a
couple
of
closing
comments
in
the
next
steps
at
this
point,
so
we
just
spoke
of
it
now
and
there
there's
a
number
of
drafts
that
we
have
that
have
matured
over
the
last
while
and
we
do
need
to
get
some
kind
of
Rio
Dental
I
of
reviewers
and
why
we
want
to
get
those
reviews
done
for
two
basic
purposes.
A
We
address
meeting
curvature,
but
it's
really
important
to
get
a
bit
of
a
better
cross-section
review,
so
we
can
actually
validate
that
make
sure
that
we
have
something
we
can
actually
take
a
working
last
call.
What
I'd
like
to
do
is
identify
those
on
the
mailing
list
and
we're
gonna
look
for
volunteers
now,
just
as
a
show
of
hands
that
I
want
to
figure
out
what
I'm
gonna
face
in
the
mailing
list
here.
Who
would
be
willing
to
do
reviews
for
some
of
these
documents
that
we
really
require?
A
These
for
I
mean
I'm,
not
suggesting
you're,
committing
right
now
for
the
review,
but
I
need
to
try
to
get
an
assessment
or
we're
trying
to
get
us.
It's
gonna,
whom
will
I,
will
actually
be
able
to
dig
into
these
documents
and
help
us
make
sure
we
flush
out
some
of
the
data
there.
So
just
trying
to
pick
up
tests
here
show
up
and
of
you
would
be
willing
to
do
review,
not
just
in
general,
like
there's
some
document
that
we've
reviewed,
that
you
would
be
willing
to
review.
A
A
A
You
know
it's
important
to
operationalize
this
so
expect
over
the
next
week,
or
so
we're
gonna
have
to
work
with
Gunther
to
figure
out
how
we're
gonna
drag
people
in
to
get
these
reduce
time
is
that's
to
me,
that's
the
biggest
bar.
We
have
this
point
to
make
sure
that
we're
ready
for
actual
work,
culottes
calls
so
I
really
don't
want
to
go
up
the
chain
with
with
documents
that
then
receive
review
post
us,
you
know
sending
them
up
there.
Any
other
comments
you
have
at
this
point.
A
Okay,
so
I
do
appreciate
everyone
coming
out.
You
did
have
a
bit
of
a
short
agenda,
but
that's
okay.
We
had
lots
of
real,
pretty
Q&A
now
before
we
break
there's
any
last
comments.
Anyone
want
to
say
anything
the
mic:
okay,
blue
sheets,
who
loves
blue
sheets.
If
there's
one
up
here,
one
back
there
I'll
come
Thanks.
So
thank
you
very
much.
That
concludes
the
work.