►
From YouTube: IETF103-LSVR-20181108-1350
Description
LSVR meeting session at IETF103
2018/11/08 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
It's
interesting
to
see
you
know
the
dynamics
of
the
new
scheduling
mechanism
here
so
now
suddenly,
instead
of
like
you
know
the
one
before
the
last
day
in
the
afternoon,
we
are
now
on
the
last
day
on
in
the
afternoon,
and
you
know
the
dynamics
about
people
attending
seems
to
be.
You
know,
interesting
to
say
the
least
anyway,
so
we
have
a
two
hour
slot
here
allocated
for
us
I,
don't
you
know
looking
into
the
schedule
itself?
I,
don't
think
we
have,
like
a
you,
know,
a
very
full
agenda.
A
So
with
a
bit
of
luck,
you
know
we'll
be
able
to
fill
it
up,
but
my
anticipation
is
that
a
lot
of
work
actually
is
being
you
know
reasonably,
you
know
modeled
over
already,
and
you
know.
Probably
can
you
know
steam
ahead?
You
know
pretty
well
so
my
culture
right
now
is,
you
know,
distributing
the
blue
shade.
So
please
fill
it
in
so
that
the
next
time
we
actually
have
a
similar
kind
of
like
very
comfortable
large
room.
You
know
it
actually
fits
us
all
very
well,
so
that's
fantastic!
A
Okay,
otherwise
you
know
we
will
monitor
it
from
from
our
end
here.
So
that's
okay.
Anybody
willing
to
do
like
minutes,
so
you
don't
have
to
do
it
alone.
It
can
be
done
over
the
ether
pad.
You
know
application.
It
is
allowed
to
look
at
me
right
now.
You
don't
have
to
look
at
your
screen
or
at
like
something
else.
Any
volunteers,
okay,
Adam
I,
don't
thank
you
so
much
so.
Okay
before
we
go
on,
you've
probably
have
seen
this
thing
already.
So
anything
you
say
you
know
it's
actually
going
to
be
record.
A
It's
going
to
be
part
of
a
contribution
to
what's
the
ITF,
so
you
have
to
be
aware
of
it.
You
know
this
is
the
yes
okay,
so
AC
cool!
Thank
you
so
much
so
we
have.
No
duality
is
the
first
time
you
see
it
right
now.
Then
you
probably
haven't
really
attended
a
lot
of
sessions,
so
I
do
recommend
you
in
that
case,
to
actually
read
it
very
deep
and
detailed,
and
you
know
so
that
you
are
aware
of
it.
A
A
Think
right
now
you
know
if
you
look
into
where
we
are
in
the
quality
of
documents
and
and
how
the
document
actually
are
set
up
and
the
details
which
are
includes
I,
think
we
have
progressed
well,
particularly
seeing
where
we
came
from
you
know
in
the
beginning
of
the
year,
so
it
actually
is
going
pretty
well.
The
road
forward
for
us
is
to
actually
have
like
one
more
IETF
meeting
have
like
one
more
intimate
meeting
to
discuss
some
of
the
open
topics
which
actually
may
come
out.
A
So
this
is
agenda
we
have
so
I
took
particular.
You
know
very
good
care
that
the
agenda
where
I
shown
on
the
screen
here
is
actually
the
same
agenda
as
what
is
posted
on
the
website
this
time.
The
last
time
it
tricked
me
a
little
bit
so,
as
I
mentioned,
we
have
about
like
120
minutes
and
we've
tried
to
carve
it
up
in
this
kind
of
time
slots
a
little
bit
of
time
left.
A
So
we
have
about
like
10
minutes
spare
looking
into
so
you
know,
I
see
some
people
actually
who
have
been
allocated
like
50
minute
slot
and
actually
gave
me
a
40
slide
presentation.
So
maybe
that
could
be
able
to
initially
you
know
used
by
those
people
to
actually
you
know,
do
it
that
way.
So
for
the
rest,
so
this
is
the
agenda.
Any
anybody
wants
to
say
something
about
it.
Shuffle
with
it
or
you
know,
just
you
know
say
victory
and
you
know
be
super
happy
and
make
a
dance
of
joy.
A
The
first
thing:
what
I
would
like
to
say
is,
like
you
know,
if
you
look
into
the
the
milestones
of
what
we
have
so
we
have
like
a
set
of
you
know,
deliverable
deliverables,
not
talking
about
a
technology
itself.
We
also
have
something
you
know
which
is
not
really
started
upon.
You
know
I've
been
told
it
is
not.
A
You
know
something
that
is
an
element
that
requires
a
lot
of
time
to
progress
which
is
like
you
know,
the
manageability
and
the
yang
specification,
for
you
know,
links
data
vector,
routing
I'm,
just
you
know
pointing
it
out
here.
So
you
know
it
isn't.
It
is
on
track,
but
we
do
have
you
know
a
milestone,
you
know
in
July,
so
we
need
to
be
aware
of
it.
We
should
not
really
lose.
You
know,
visibility
of
it
either
and
it
needs
a
big
progress.
B
A
So,
looking
at
your
agenda
that
actually
we
can
start
with
our
you
know
first
presentation
here
and
that
is
to
give
like,
like
a
15
minute,
you
know
high-level
overview
of
some
of
the
conclusions
and
discussions.
We
actually
had.
You
know
during
the
entry
meeting
in
October
itself.
So
Jacob
will
be
you
know
presenting
this.
You
know
out
of
whatever
he
is
based
in
the
US.
It's
like
very
late
that
this
is
side
of
the
planets.
C
C
So
I'll
tell
you
next
slide:
I
guess:
I
can't
see
the
slides,
as
you
show
them
on
my
screen.
I
think
there
might
be
some
browser
issue
or
something,
but
we'll
try
to
keep
in
sync
and
I
won't
need
15
minutes.
So
we
so,
as
you
know,
if
you
go
to
pass
the
title
slide
to
slide
number
two.
So
the
meting
meta
meeting
info
slide.
C
Yes,
all
right,
so
we
met
on
October
1st
in
California
in
the
morning
met
for
about
two
two
and
a
half
hours
or
something
there
was
10
of
us
and
that
the
two
chairs,
and
as
as
you
already
provided
the,
where
are
you
obviously
an
IETF
103?
And
these
are
the
updates
from
what
happened
in
interim
meeting
number
two.
So
you
can
go
to
the
next
slide.
There
Gunther
so
I'll
slide
number
three.
C
Yes,
the
the
the
intent,
of
course,
with
all
the
interim
meetings,
is
to
continue
to
drive
the
deliverable
forward
and
to
that
end
we
met
and
discussed
the
link
state
discovery
protocol.
We
did
a
deep
dive
in
that
Randy
provided
a
lot
of
updates,
starting
with
the
requirements
that
we're
building
after
we
build.
The
draft
of
course,
as
he
says
in
typical
IETF
fashion,
went
through
that
and
had
a
number
of
updates
we'll
talk
about
our
discussions
that
will
talk
about
her
in
a
minute
and
then
went
through
the
draft.
C
That
was
the
majority
of
the
discussion
and
Kure
provided
some
updates
that
were
made
to
the
BGP
SPF
draft
in
response
to
comments
that
have
been
made
from
various
reviewers
and
when
we
finished
with
some
security
requirements
and
discussions.
I
will
talk
about
her
in
a
minute,
so
you
can
move
onto
to
slide
more
for.
C
So
the
the
link
state
or
Ethernet
requirements,
we
did
a
basic
review
of
the
requirements
essentially
coming
to
the
conclusion
that
one
it
needs
to
be
simple.
When
you
need
layer,
two
liveness
and
simplicity,
we
need
to
be
able
to
discover
nodes
and
links
and,
of
course,
that
should
be
simple
and
we
need
to
then
discover
encapsulations
and
provide
some
northbound
API
to
BP
SPF
throughout
the
discussion
of
the
requirements,
as
well
as
the
actual
draft
review.
C
We
kind
of
kept
coming
back
to
this
need,
for
you
think
we
need
something
security
related,
but
we
don't
really
know
what
it
means,
and
we
came
to
some
conclusions
that
we'll
talk
about
about
providing
some
hooks
and
then
and
then
Randi
did
a
review
of
the
other
options
that
could
be
used
for
this
kind
of
thing
and
none
of
them
quite
seemed
to
fit
what
we
need
for
LSP.
Our
next
slide,
please
slide
number
five.
C
C
We
talked
some
about
the
changes
that
were
made
around
the
interlink
ether
protocol,
particularly
around.
We
need
to
assume
that
we
should
always
expect
a
new
node
and
how
that
should
change,
hellos
and
so
forth.
Again
spend
some
time
talking
about
security
and
authentication,
which
was
the
introduction
to
what
we've
called
the
security
blog
and
that's
an
effort
to
be
able
to
provide
some
hooks
into
being
able
to
provide
security.
C
And
now
we
talked
about
the
draft
review
of
bgp
SPF.
This
is
on
slide
six,
so
the
status
update
is
at
that
time
it's
mostly
in
a
stable
State
updates
were
made
from
some
of
the
comments
and
the
reviews
that
were
made
from
the
reviewers
and
we
believe
at
least
at
that
time.
It's
ready
for
some
implementation
work.
There
was
some
added
manageability
considerations
and
some
I
was
one
of
the
comments
that
was
made
and
what
do
we
do
about
explicit
withdrawals
that
was
kind
of
left
as
as
part
of
the
discussion?
C
And
finally,
the
last
thing
we
kind
of
wrapped
up
about
was
how
do
we?
What
do
we
do
about
security?
Obviously
it's
important,
but
we
don't
really
know
what
the
threat
model
is,
and
so
that's
kind
of
led
us
to
well
what
if
we
we
create
this
blog
that
we
can
use
to
add
security
somebody
could
hook
into
and
then
perhaps
maybe
we
create
an
informational
draft.
That
says
this
is
one
way
that
we
could
use
this
as
kind
of
a
path
for
somebody
to
be
able
to
take,
and
we
sort
of
left
it
there.
C
A
A
A
D
Okay,
thanks
Randy
Bush,
arcus
and
you'll
notice,
a
new
victim
has
been
added
to
the
draft
Rafal
stock
and
that's
because
he's
implementing-
and
so
we've
been
sitting
side
by
side
for
10
days
now
and
the
knock
with
me,
making
a
mess
of
the
draft
and
I'm
trying
to
implement
it.
Beating
me
up
so
Oh
God.
A
E
D
Welcome
so
you'll
remember
this,
which
is
mainly
I,
believe
I
can
go
slowly
right
because
we
have
30
minutes.
Oh
that's
called
slowly.
So
what
we're
talking
about
is
Ethernet
protocol
to
pass
link
state
and
the
address
families
and
encapsulations
that
are
available
on
each
device
and
will
be
pushed
up
to
bgp
SPF
or
some
upper
layer
protocol
to
actually
communicate
between
devices
so
to
form
the
topology
of
the
network,
etc.
D
So,
what's
new
and
different
new
data
framing,
we
now
call
the
message
of
the
entire
application
message.
The
traditional
name
is
a
program
protocol
data
unit
and
it
may
occupy
multiple
data
grams
because
of
the
MTU
or
other
limitations
of
an
Ethernet
frame
and
they
get
reassembled
and
they
can
be
reassembled
into
the
datagrams
can
be
reassembled
into
a
pgu
because
each
one
has
a
number
and
went
and
they
checksum.
So
it's
kind
of
like
UDP,
okay
and
there's
a
flag
that
says
this
is
the
last
one
of
a
PDU.
D
D
There
are
eight
ones
that
we
know
now
and
the
thing
that's
interesting
is
this
used
to
be
called
an
encapsulation
act,
and
now
it's
called
an
act
because
it
will
be
used
for
more
than
encapsulations
and
the
sessions
are
made
here
because
open
is
act
so
it
now
becomes.
You
send
me
an
open
I,
send
you
an
open
each
of
us
act
to
each
other.
We
now
have
established
a
session
instead
of
this
kind
of
Spacey
thing
where
I
got
it
open,
so
I
have
a
think.
D
D
Why
is
that
one
behind
that's
exciting:
okay,
I
click
again
again,
whatever
okay,
so
the
hello
has
changed
in
that.
D
It
is
now
acknowledging
that
we
have
to
send
it
by
a
multicast,
because,
if
I
wake
up-
and
there
are
lots
of
devices
out
there-
I-
don't
know
who
I'm
going
to
so
I
send
the
hello
multicast.
All
responses
will
be
unicast,
but
there's
an
issue
that
there
are
multiple
kinds
of
multicast,
the
two
most
interesting
to
us
and
we're
getting
Paul's
condoms
help
on
deciding
them
are.
Does
this
multicast
Ethernet
frame
Pierce
a
switch
or
not?
D
D
You
get
a
hello,
responding
with
an
open
the
establish
a
session,
etc.
Et-Cetera
open
has
my
name,
your
name
account
of
attributes
in
case
anyone
forgets
the
list
of
attributes
goes
here
and
we
don't
know
what
those
attributes
mean
only
the
operator
does
and
they
could
be
what
flavor
coffee
they
like
or
anything
they
wish.
As
mentioned,
there's
an
authentication
blob
get
into
this
a
little
more
later.
D
One
thing
that
could
happen
is
I.
Could
wake
up,
find
myself
that
I've
got
a
TPM,
go
over
my
management
interface
and
ask
the
TPM
God
in
the
sky
to
sign
a
certificate
with
that
and
I
put
the
signed
certificate
chain
down
here.
Otherwise,
I
could
take
my
public
key
and
just
stick
it
in
there
and
we
do
what's
known
in
security.
Community
is
tofu,
which
is
trust
on
first
use,
I
call
it
marriage
on
first
date,
but
that's
another
matter.
It's
not
something
I'm
very
fond
of.
D
We
have
the
local
and
remote
IDs,
which
can
be
an
ASN,
a
concatenation
of
36
identifiers,
Zoar.
Anything
you
want
I
suggest
they
be
uniform
and
unique
in
the
data
center.
Okay,
the
attributes
can
be
anything
as
I
said.
The
authentication
data
might
be
a
certificate
chain.
Failure
to
authenticate
if
there
is
a
nonzero
authentication
field
is
a
failure
of
the
session,
and
you
start
again
as
I
said:
open
gets
an
act.
Other
things
are
going
to
get
ax.
D
What
act
is
the
type
of
PDU
that
is
being
act,
so
it
will
be
an
open
PD.
You
type
here
for
an
open
that
will
be
an
encapsulation,
PDU,
etc.
Okay,
if
I
don't
receive
an
act,
there's
a
time
out.
Retransmit
failure,
count
I'm
sure
the
transport
people
will
give
us
good
and
put
on
this,
in
other
words,
exponential
back-off
and
put
your
finger
in
your
idea:
etcetera,
etcetera,
okay,
so
once
we
have
each
other's
Max
and
we've
acknowledged
them,
we
have
open.
D
We
can
start
to
keep
lives
between
the
two
okay
there's
no
protein
in
this
keep
alive.
Okay,
so
I
think
they
should
probably
be
infrequent
on
the
order
of
seconds
or
a
minute,
but
the
operator
knows,
of
course
it
will
be
configurable
and
so
on
and
so
forth.
This
is
to
be
differentiated
from
BFD,
which
is
probably
running
quite
quickly.
D
Okay,
one
of
the
reasons
I
think
this
one
will
be
slow
is,
if
you
choose
to
do
security
you'll
see
later
on,
that
this
should
be
signed
and
signing
and
verification
are
expensive
operations,
especially
in
devices
that
have
high
out
degree.
Okay,
so
now
we've
met
each
other
and
we
have
our
max.
We
have
our
noted
your
IDs,
we
can
extend
encapsulations
and
they
all
have
the
same
header,
which
is
what's
their
length.
D
What's
the
count
of
encapsulations
and
the
list
of
encapsulations
and
all
the
encapsulations
kind
of
look
like
this,
there's
the
count,
there's
a
flag
that
says
is
this
a
primary
address
on
this
interface?
Is
this
a
loopback
address,
reachable
via
this
interface
and
then
in
this
case,
we're
doing
an
ipv4
address
and
there
can
be
lots
of
them?
Okay,
a
big
change
from
the
previous
draft
is
an
encapsulation
message
of
type
T
replaces
all
previous
encapsulations
of
type
T,
so
you
don't
have
to
remember,
and
you
don't
have
to
worry
about.
D
D
D
Okay,
use
multiple
encapsulations
to
allow
one
label
to
be
associated
with
multiple
there's
a
v6
encapsulation,
that's
about
the
protocol.
I
will
not
go
and
bother
you
with
the
section
that
goes
in
how
this
is
pushed
up
to
be
GPL
s
through
BH
appear
through
the
BGP
LS
API
to
be
GP
as
SPF,
because
you've
gotten
to
hear
that
three
times
already.
That
must
be
boring.
It
is
unchanged,
but
we're
looking
thank
you
Eric
to
said
security
and
what
we
think
at
the
moment
when
we
talked
about
the
threat
model,
was.
F
D
D
F
F
F
No,
not
all
of
them,
I
switch
one,
it's
okay,
but
but
you
are
using
the
same
space.
The
same
IANA
register:
okay,
okay,.
A
H
H
I'm
talking
Randi
instead
of
the
instead
of
the
BFD
hello,
the
upward
pushed
to
the
BGP
API
to
let
you
know
that
you
do
have
a
neighbor
in
your
original
presentation
in
ITF
102,
you
were
considering
how
long
it
took
to
go
upwards
and
you
had
that
question
whether
this
process
would
be
fast
enough
in
this
current
implementation.
Have
you
seen
that
same
concern,
or
has
that
concern
been
resolved
based
on
implementation
experience?
We.
D
I
I
I
Then
my
last
comment:
I
mean
question.
I
may
be
more
of
a
comment.
You
have
a
version
number
in
there
and
in
the
draft
you
say:
if
it's
not
this
version,
then
it's
a
failure
and
I'm
wondering
if
you
want
to
reconsider
that
for
something
that
might
allow
for
some
sort
of
forward
compatibility
or
some.
You
know,
we've
done.
I
D
G
I
G
Cuz
I'll,
forgetting
I've,
already
forgotten
sorry
Rob
austin.
I
just
want
to
gently,
speak
against
that
last
point.
Generally,
it's
fairly
straightforward
to
say
you
know
I
I'm
version.
0
I
understand
version.
0
version
1
can
understand
both
it's
not
impossible,
but
it's
challenging
to
be
forward
compatible
with
something
that
hasn't
been
specified
yet
and
we're
trying
to
keep
this
stupid.
So
that's
kind
of
why
we
ended
up
with
the
way.
What
way
it
is.
There's
really
strong
reason
to
do
forward
compatibility
but
stuff
I,
don't
understand
yeah.
We.
I
I
D
I
Then
this
one
said,
then:
if
you
have
an
incompatibility
where
you
change
the
PDU
such
that
these
two
guys
cannot
talk
to
one
another,
then
you
either
have
different
protocol
or
you
know
you
go
with
week
what
you're
talking
about
now.
The
reason
why
I'm
suggesting
this
is
because
you
have
the
requirement
that
your
hello
protocol
will
continue
on,
because
you
need
to
find
guys
that
might
be
on
a
multi
drop
link,
good.
G
D
I
I
needed
to
talk
to
a
version,
one
Guyana
version:
zero
guy.
That
happened
to
be
in
this
thing,
I'm
going
to
be
sending
multiple
hellos
of
different
versions.
All
you
know,
so
you
kind
of
it
just
kind
of
creates
some
overhead.
So
it's
just
thought
but
I
understand
the
challenge,
but
it's
worth
considering
so
I'll.
Send
you
a
note
on
that
worth.
D
Considering
as
I
think
the
operative
phrase
and
we'll
consider
serious
level,
that's
an
ugly,
it's
an
ugly
back
to
security.
Okay,
I
posted
a
threat
novel
to
the
list
back
at
ITF
-1
and
nobody
responded.
I
said:
don't
up
how
many
operators
are
there
here?
Don't
you
care?
Oh
they
all
cared
well
then
respond.
D
What
I
suggested
was
that
the
one
threat
is
spurious
devices
appearing
on
your
network,
somebody
plugging
a
hostile,
laptop
in,
etc,
etc.
In
which
case
the
concern
is,
is
this
the
Droid
I
was
talking
to
earlier?
In
other
words,
I
had
a
Hello
exchange,
whether
that
came
from
a
joint
certificate
or
made
up
naked
public
key
is
I
thought
I
knew
who
I
was
talking
to
am
I
still
talking
to
you?
D
Okay,
so
there
was
not
a
clear
need
for
confidentiality,
just
integrity
and
continued
Authority.
So
what
we're
thinking
is
the
open
can
have
a
public
key
plus
whatever
it
could
be,
wrapped
with
certificate
stuff
obtained
from
the
provisioning
server
in
the
sky.
Whatever
the
public
key
is
signed
with
the
private
key
on
open,
that's
proof
of
possession
right
there.
In
other
words,
you
know
that
the
person
issuing
the
open
that
that
has
the
private
key
matching
the
public
key.
D
D
I'm
an
operator
I
charge
by
the
traffic
255
bits
is
great
right
and
our
PD
is
are
easily
extended,
so
no
harm
the
keepalive
would
get
a
sequence
number
which
cranks
each
keep
alive
and
probably
other
things
would
get
to
keep
a
lot
a
get
a
sequence
number
too.
So
that
would
narrow
the
window
for
a
replay
attack.
D
D
Okay,
maybe
add
a
proof
of
possession
challenge-response
PDU
pair,
so
we
drift
on
even
though
I'm
fairly
assured
no
replays
happening.
Do
you
really
have
the
private
key
for
that
public
key?
It's
a
cheap
PD.
You
pair
desperately
would
like
some
feedback
on
this
one
before
we
dig
it
in
also,
do
we
want
to
put
this
in
the
LSB,
our
pro
any
lsle
protocol?
Do
we
want
to
different
protocol
drafts.
J
Another
thing
as
you
consider
this
and
I
know
that,
as
you
said,
no
one
has
necessarily
giving
you
a
lot
of
feedback,
but
also
think
of
not
just
when
this
is
used,
because
this
is
the
base
protocol
spec,
not
when
this
is
used
and
only
in
the
data
center,
but
if
whatever
use
be
used
somewhere
else
right
so,
for
example,
from
fidelity
right,
you
mentioned
that.
Maybe
there's
not
a
need
for
confidentiality
in
the
data
center.
That
is.
J
Just
I'm
just
saying
so
yeah
what
I
need
you
to
do?
Is
you
don't
think,
there's
anything
combinational
about
this
data
like
tend
to
agree,
then
please
justify
that
in
the
traffic
right,
so
that
you
know
it's
easy
to
not
just
ask:
why
isn't
there
you
know
this
and
the
security,
but
to
understand
why
you
have
the
justification
behind
that
that
way
we
should
avoid.
You
know
this
question
is:
are
we
willing
to
repeat
too
many
times.
D
D
Okay,
this
is
now
we
get
into
the
boring
stuff
that
we
had
from
last
time.
Nothing
has
changed
so
I'm
kind
of
at
the
end
of
it,
I'd
really
like
people's
feedback
on
whether
we
do
this
at
all.
What's
the
threat
model
behind
it,
do
you
want
confidentiality?
Do
we
separate
this
into
two
versions
of
the
protocol,
or
is
this
okay
and
remember?
This
means
every
PD
you
as
a
signature,
calculation
and
verification,
we're
specifically
thinking
of
an
algorithm
which
is
fairly
cheap
to
do
well
fairly
to
5519.
D
G
G
It
boiled
down
to
a
choice
between
doing
the
stupidest
simplest
possible
signature
over
the
messages
or
how
to
do
some
kind
of
complicated
setup
to
negotiate
a
session
key,
and
if
we
were
willing
to
negotiate
a
session
key,
we
could
do
something
like
H
Mac
instead
of
signatures.
The
problem
is
when
you
start
looking
at
it,
and
you
start
asking
people
who
know
what
they're
doing
the
advice
oils
down
to
either
use
TLS,
which
is
kind
of
heavy
weight
for
this
or
by
the
time
you're
done
doing
all
the
things
you
need
to
do.
G
You
will
have
reused
TLS.
You
just
aren't
admitting
that,
so
we
chose
to
skip
all
of
that.
The
price
tag
for
that
is.
We
actually
have
to
compute
signatures
on
every
message.
Instead
of
doing
you
know
just
one
setup
for
a
session
at
the
beginning,
so
it's
a
deliberate
design
trade-off
to
keep
this
now
as
simple
and
stupid
as
we
could.
F
D
I
I
F
D
K
F
K
F
F
You're,
giving
your
your
you're
giving
them
the
public
key
and
they're
using
that
you're,
giving
them
the
public
key
out
of
a
public/private
key
pair
and
then
you're
using
that
to
verify
the
signing
of
the
message
so
I
don't
see
why
why
you
couldn't
change
it
at
any
time.
It
would
be
up
to
the
sender
to
do
that.
D
D
A
D
Unless
we
do
security,
oh
I
think
it's
fairly
close.
We
have
the
protocol
in
the
condition
that
I
believe
we
can
do
a
reasonable
state
diagram.
Oh,
we
have
a
prototype
implementation
coming
out
that
we
plan
to
beg
management
to
allow
us
to
release,
but
if
they
don't
they
don't
that's
their
choice.
That's
why
they're
called
management
and.
A
A
A
So
we've
been
discussing-
actually
you
know
on
how
to
you
know
how
to
progress
some
of
these
elements
going
forward,
so
the
chairs
from
you
know,
LSB,
are
denied
all
have
been
sitting
together
together
with
the
area
director
and
also
during
the
the
idea
into
the
meeting
here.
This
topic
actually
has
been,
you
know,
discussed
about
like
auto-discovery
and
the
clearly
actually
is
like
an
like
an
evident
interest.
A
You
know
this
particular
topic
from
many
working
groups,
so
the
next
couple
of
slides
are
sort
of,
like
you
know,
I've
stolen
from
the
good
work
from
from
Jon
Secada.
You
know
what
he
actually
use
during
is
IDR
interim
meeting
and
and
at
the
end
of
you
know
the
four
or
five
sites.
What
I
have
here,
I'm
gonna
go
over
it
very
quickly.
I
would
like
the
plan.
You
know
our
our
wave
forward
with
this
technology
itself.
A
So
so
in
idea-
or
actually
you
know,
it
was
discussed
that
indeed
you
know,
there's
clearly,
like
you
know,
interest
you
know
from
Alana
working
groups
actually
work
on
this
and
also
within
Alice
VR
itself.
You
know
technology
like
it's
not
really
shorter.
Now,
a
little
bit,
oh,
you
know
you
know
shorter
for
this,
so
we
can
potentially
not
plot
something
in
and
also
from
analyst
view
on
perspective.
A
So
now,
looking
into
all
the
different
options
we
have
and
they're
like
many
different
ways
of
you
know,
skinning
the
cat
hair.
Our
area
director
has
been
very
smart
and
I
realized.
You
know
why
do
we
need
that?
You
know
if
we
can
have
like
you
know
the
only
one
that
would
be
better
from
a
technology.
You
know
progress
perspective
and
it
would
make
things
you
know
easier
for
you
know
for
everybody
else.
So
that's
a
very
good.
You
know
vision
in
a
very
good
view
now.
A
So
now,
at
the
same
time
like
an
idea,
it's
like
a
whole
set
of
different
kind
of
proposals.
Being
you
know,
talked
about
you
know
in
this
space
of
auto-discovery,
so
you're
still
comparing
you
know
and
only
what
would
be
best
for
them.
Now,
all
of
these
different
kind
of
are
all
these
different
proposals.
You
know
they
can
be
like
mixed
and
matched
in
different
ways,
so
they
haven't
really
converged
into
like
what
is
the
best
for
IDR,
so
they
still
need
to
compare
like
okay.
You
know
what
are
the
similarities?
A
You
know
in
their
direction
now,
at
the
same
time,
if
you
look
into
the
requirement
itself
from
all
of
these
different
themes,
you
see
like
one
particular
requirement
and
the
one
which
actually
every
you
know
all
of
these
actually
have
is
that
you
know
it's
mainly
to
actually
trigger
you
know
the
bootstrap
on
almost
single
hop
ebgp.
That
is
the
main
common
thing
now,
of
course,
if
you
look
into
all
of
them-
and
you
put
you
know
all
of
the
requirements
into
a
union-
it's
a
much
bigger
pool
of
things.
A
A
A
They
are
going
to
be
planning
like
an
interim
meeting
to
talk
about
this
now
you
know
I'm
not
really
sure
it
makes
a
lot
of
sense
from
an
LS
VR
perspective
to
actually
wait
upon
them
until
idea
or
actually
converge
to
something,
because
also
the
requirements
are
going
to
be
vastly
different
from
our
requirements.
So
Randy
has,
like
you
know
in
the
last
couple
of
you
know:
LS.
We,
our
meetings
been
talking
about
requirements,
and
you
know
what
we
actually
need
so.
F
Cylinder
Cisco
Systems
the
one
place
where
there's
an
intersection
here
is
your
point
because
it
reuses
the
beep,
the
BG
pls
TLV
space.
You
need
to
have
an
agreement
to
be
able
to
I,
don't
think
I
think
there's
there
may
be,
like
you
said,
there's
different
requirements,
more
requirements,
you're
going
to
be
able
to
have
to
be
able
to
add
at
least
attributes
and
just
an
agreement
that
we'd
be
able
to
buy.
We
I
mean
this
working
group
use
the
same
eye
in
our
space
and
registries.
F
D
D
Sees
a
problem
coming
not
a
big
one,
but
something
that
would
be
nice
to
sell.
They
say
this
happening
over
here.
It's
still
IDR
is
big
and
slow
and
has
a
large
burden
on
their
back
that
they
have
to
carry
and
so
I
think
they're
watching
and
we'll
figure
it
out
or
there
will
use
something
else
and
if
they
have
input,
of
course,
they
should
be
taken
very
seriously
right
now
they
haven't
given
us
much
input
and
that's
their
prerogative,
so
we're
plotting
along
in
our
kind
of
stupid.
A
So
so
so,
actually
so
so
going,
you
know
further
into
this,
so
what
actually
was
discussed
in
IDR
also-
and
is
that
you
know
so
Eleazar
we
right
now
and
it's
a
proposal
in
in
this
particular
working
group
and
what
we
agreed.
Actually
you
know
with
you
know
with
the
chest
from
idea.
Is
that
you
know
if
we,
you
know,
plan
to
progress
work
further
on
in
this
working
group
here
that
it
should
not
exclude.
A
You
know
the
future
requirements
from
from
an
idea
of
perspective,
so
idea
will
also
look
into
what
LLC
actually
is
doing,
and
you
know
they'll
actually
know
really
assess
you
know,
together
with
the
other.
You
know
proposals
if
these
actually
will
satisfy
their
needs.
Now
they
don't
want
it
now
that
does
not
mean
that
IDR,
you
know
in
the
future
will
actually
choose
LLC
B
itself
from
you
know,
from
a
neighbor
ship
discovery
perspective.
Just
also
keep
in
mind.
A
You
know,
Ella
Zoe
is
not
really,
you
know
creating
a
navy
ship
or
establishing
in
the
neighbor
ships
at
all.
It's
just
providing
you
the
hoops
with
sufficient
information
to
actually
you
know
to
regulate
that
particular
that
event
itself.
Now
all
of
this
being
said
so
the
thing
what
I
would
like
to
you
know
this
you
know
proposed
going
forward,
is
you
know
to
understand
you
know
just
to?
Maybe
actually
you
know
adopt
this
work.
You
know
in
our
working
group.
So
that
is
something
what
I
would
like
to.
You
know
propose
going
forward.
A
I
know
the
shorter.
You
know
it's
a
little
bit.
You
know
on
the
adjacency
of
the
shorter
itself.
You
know
it
probably
has
to
what,
if
you
know
to
be
modified
a
little
bit
so
so
my
plan
is
to
you
know
it's
going
forward
to
actually
you
know
do
like
a
working
group
and
an
adoption
call
for
Ella
Zoe.
Unless
there
is
like
anybody
in
the
room
was
like
you
know
it's
violently
in
disagreement.
M
M
They
don't
allow
liquor
Cisco.
So
from
the
last
update
to
this
update,
we
seen
that
there
is
a
transport
layer
being
introduced
in
Ella.
Sorry,
there's
fragmentation
and
reassembly
coming
in
checksum
was
there,
but
it's
changed.
There
are.
There
is
an
open
session
and
there
is
some
kind
of
a
session
management
aspect
coming
in
randy
also
talked
about
protocol
state
machine.
M
A
M
B
Capital
arcus,
clearly
I,
don't
disagree.
I
disagree
with
that
comment.
The
reason
why
we
started
off
with
Ellis
OE
was
fundamentally
because
we
say
lldp
cannot
scale
beyond
certain
package
size
and
it
can't
scale
because
the
ad
information
could
extend
beyond
1500
bytes.
So
some
of
the
things
that
you
mentioned
we're
already
as
part
of
the
design
document
that
we
wanted
to
started
off
with.
N
N
Data
centers
are
planned
and
every
piece
that's
put
into
the
data
center
is
put
in
there
according
to
the
plan,
and
nothing
needs
to
be
discovered,
and
this
came
from
two
people
who
actually
build
data
centers
to
build
massive
scale.
Data
centers
and
I
respect
their
opinion.
So
is
there
any
need
at
all
for
order
discovery.
P
Eat
or
Yahoo,
one
of
the
guys
that
Jake
was
talking
about
there's,
definitely
a
need
for
verification
of
something
is
wired
correctly.
There
is
not
much
need
for
it's,
not
so
much
order,
discoveries,
verification,
so
we're
not
looking
for
something
that
order
discovers
an
automatic
will
start
up.
Every
protocol
Under
the
Sun
magically.
We
just
need
to
know
if
something's
wired
correctly
and
if
we
get
to
know
something,
is
configured
correctly.
Ok,
cool
extra
verification,
but
we
don't
need.
P
We
actually
don't
want
four
protocols
to
start
automatically
because
we
test
the
network
as
we
bring
it
up
and
unless
the
protocol
will
perform
all
of
this
testing,
like
fire,
20,000
pings
down
the
link
and
make
sure
that
it's
all
clean,
there's
no
errors,
etc.
Then
we
wouldn't
actually
want
the
protocol
to
come
up.
First.
Thank.
A
D
There
is
a
wide
range
of
how
people
build
things
out
going
at
the
example
I
used
like
to
use
for
the
extreme
centralized
in
is
Jupiter,
rising,
of
course,
where
everything
is
blown
down
to
the
device
it
wakes
up
on
the
management
Network-
and
it's
told
here-
is
your
world
Igor
in
the
middle?
Who
has
some
of
that,
but
also
wants
to
verify
it
by?
You
told
me
that
Mary
was
over
there?
D
M
M
To
answer
K
your
point,
this
could
use
IP
UDP,
which
is
what
one
of
the
other
proposal
is
doing
and
I
have
not
seen,
and
it
could
really
do
all
the
functionality
without
having
the
comm
occasions,
leverage
existing
stuff,
our
nd
IP
fragmentation,
reassembly
out
of
that,
so
I
haven't
really
seen
actual
strong
reason
for
doing
it
at
link
level
and
not
IEP.
Lldp
was
from
I
Triple
E,
so
they
could
only
do
at
that
level,
but
here
at
ITF
we
could
do
it
on
top
of
IP.
B
L
Remembering
okay,
I
think
I.
First
of
all,
I
think
there
is
environments
which
don't
need
auto
discovery,
but
there
are
environments
where
we
do
need
auto
discovery.
I
think
so.
From
that
point
of
view,
I
think
we
need
something
to
be
enhanced
from
what
we
are,
whether
it
has
to
be
done
here
or
not.
L
I
don't
have
a
real
strong
opinion,
but
I
think
it
would
be
good
to
this
guy
to
go
through
the
list
of
all
the
auto
denied
the
bootstrapping
and
auto
discovery
mechanism,
which
were
identified
in
your
slides
to
see
whether
there
is
some
additional
requirements
which
we
haven't
captured
it,
but
I
think
the
set
which
is
defined
here
is
pretty
well
defined.
In
my
view,
and
as
such
it
would
make
sense
to
continue
this
because
I
think
it
has
a
good
base
or
a
good
foundation.
F
I,
a
synonym,
subscribe,
agreed,
I
agree
with
women
care
I,
think
there's
a
lot
of
different
requirements.
I
think
this.
The
fact
that
protocols
like
lldp
exist
is
enough
and
CDP
proprietary,
cisco
discovery
protocol
is
enough
of
a
justification
also
even
if
you're
just
using
it.
For
verification
that
doesn't
mean
that
you
want
your
config
templates.
You
don't
want
something
like
this.
You
don't
have
to
have
your
you
know.
F
A
P
Guess
two
things:
one
I
do
on
my
config
templates
to
be
cluttered
because
I
don't
want
anything
to
be
magically
defaulted,
because
magic
defaults,
changed
between
code
versions,
between
vendors,
etc
and
breaks
bad.
Unfortunately,
but
I
do
want
to
say
something.
So
we
absolutely
would
you
need
order
discovery
from
a
verification
perspective.
The
question
now
is:
where
do
we
want
to
order
discover
and
what
are
the
limitations
of
the
current
protocols?
J
When
one
says
that
in
one
of
the
other
slides
that
this
are
slicing
the
yard
that
John
made,
he
said
that
I
suggested
that
we
had
one
protocol.
I
still
would
prefer
that,
because
you
know
it's
easier
for
everyone
to
do.
One
thing,
however,
as
he
finished
saying
in
this
slide,
the
recognition
from
the
chairs
is
that
we
don't
delay
the
work
right.
J
That
we
go
ahead
now
with
means
is
that
if
this
working
group
decides
to
move
ahead
with
LS,
we
there
is
a
probability
or
a
possibility,
at
least
that
we
might
end
up
with
more
than
one
discovery
board,
all
right,
there's
a
possibility
that
IDR
will
say:
okay,
let's
so
e,
to
discover
you
know
b2b
sessions
in
general,
but
there's
also
possibility
that
IDR
will
say.
I
will
use
something
else.
J
So
we
need
to
keep
that
in
mind.
Yeah,
that's
the
decision.
We
go
that's
the
way
we
go,
one
of
the
things
that
we
did
discuss
somewhere.
I,
think
maybe
it
wasn't.
The
IDR
interim
is
that,
of
course,
what
that
happens.
It
would
be
nice
for
BGP
to
be
able
to
get
discovery.
Information
from
any
of
the
protocols
right
and
still
be
able
to
come
up,
so
one
thing
that
we
need
to
keep
clear
and
I.
Think
if
I
remember
it
correctly,
but
if
not,
you
can
check
the
minutes
from
the
idea
meeting.
J
It
was
just
there
that
maybe
in
a
separate
document
somewhere,
you
know
that
type
of
information
was
documented
so
that
we
know
that
we
need
X
information
to
boot,
up
a
or
to
start
a
BGP
session,
and
so
that
the
protocols
are
discovering
to
provide
that
information
right.
Otherwise
we
end
up
with
not
just
multiple
protocols
with
protocols
that
don't
do
the
same
thing
or
even
have
similar
functionality.
J
We
had
also
discussed
just
to
give
everyone
the
whole
picture.
The
fact
that,
because
the
initial
interest
was
in
this
working
group
that
and
assuming
that
LS
OE
is
the
one
thing
that
we
would
have
chosen-
that,
of
course
we
could
start
to
work
here.
You
have
the
the
first,
you
know
the
base
protocol
and
the
initial
requirements,
and
then
other
people
like
IDR
or
whoever
else
wants
to
go
use
it.
This
covered
protocol
could
add
that.
J
So
what
that
means-
and
of
course,
Randi
and
the
other
authors
know
this-
is
that
the
protocol
obviously
has
to
not
just
has
to
satisfy
initially
the
requirement
from
this
working
group,
but
has
to,
of
course
be
accessible
to
satisfy
whatever
else
right.
This
is
Ben,
obviously
I'm
just
saying
it
just
to
make
sure
that
it
wouldn't
knows
that
so
I
think
that's
it
I
just
wanted
to.
You
know
provide
that
that
had
other
background
and
two
other
things
that
that
we
considered
so
that
you
think
about
it.
P
Have
a
question:
has
anybody
actually
done
the
analysis
of
what's
missing
between
lgp
and
what
LS
OE
provides
and
if
it's
possible
to
retrofitted
and/or
Rev
to
LTP
version,
2
or
whatever,
because
I
think
all
of
us
would
rather
have
fewer
things
on
box
that
start
up
and
try
to
do
the
same
thing?
At
the
same
time,.
D
P
P
B
So
caleb
patel
arcus
when
we
started
off
at
this
work,
it's
it's
it's
a
classic
rathole.
If
you
start
with
that
question
in
sense,
that's
a
valid
question,
but
the
kind
of
information
we
wanted
to
exchange
was
a
configuration
information
and
maybe
some
network
related
information.
So
we
weren't
looking
per
se
to
replace
everything
that
is
there
in
lldp
and
all
an
argument
it
in
Ellis
way.
But
we
wanted
to
carry
this
information
which
is
specifically
auto-discovery
related
now
protocol
is
designed
and
it's
quite
flexible.
A
D
J
J
Else,
either
now
again
with
the
intent
of
not
delayed
anymore
or
anything
else,
and
because
there
has
been
a
lot
of
efficient
this
working
group
yeah
we're
gonna,
go
fine
because
it's
a
layer,
2
protocol.
The
other
thing
that
we
have
to
do
is
we
need
to
liaised
with
the
Arab
League.
You
know.
Paul
has
obviously
been
helping
us.
He
doesn't
completely.
A
J
N
J
J
J
J
What
that
protocol
that
we
already
did
we're
not
gonna
change
the
scope
and
do
something
else
right
so
either
the
scope
is
this
sort
of
the
scope?
Is
that
or
the
scope
is
something
else,
but
this
is
something
that
has
to
be
clear
with
them.
So,
as
conser
said
I
we
should
probably
take
this
to
the
list.
D
O
O
A
Listening
to
everything
here,
you
know
what
has
been
said
so
I'll
be
taking
to
the
list
of
action.
You
know
do
like
a
working
group.
You
know
adoption
call
for
this
work
now.
That
being
said,
the
working
group
adoption
call
will
be.
You
know
around
requirements.
We
have
four
LS
V
R.
So
some
of
the
comments
of
what
I
heard
like
very
valid,
but
they
actually,
you
know,
are
coming
off
from
from
the
perspective
from
an
ID
our
perspective,
and
that
is
discussed.
You
know
which
needs
to
be
held.
A
Like
you
know
the
working
group,
because,
as
you
know,
what
we'll
discuss
during
the
interim,
an
idea
is
like
they
may
or
may
not
know,
qu
the
same
solution
as
us.
Hopefully
you
know
what
we're
going
to
be.
Choosing
will
be,
you
know
simple
enough
and
will
allow
extensibility.
It
would
be
helpful
for
demo
I'll
for
idea
also,
and
that
is
definitely
something
we
need
to
targets
for
and
that's
what
Reni
was
mentioning.
Also,
you
know
having
a
bit
more
eyeballs
around
you
know,
Eliza.
We
would
be
very
helpful.
A
F
Promise
to
take
less
than
a
fifth
to
the
time
it
took
for
that
LS,
o
II
working
group.
Adoption
call
so
I
just
did
an
update
on
this
before
the
IETF
and
the
one
thing
I
added
is
on
the
we
got
a
head
of
directorate
call
on
on
the
base
document.
They
cares
me
talking
about
the
bgp
SPF
and
ask
for
discussion
of
purity
models,
and
we
heard
that
to
the
applicability
draft,
so
I
put
a
section
in
there
discuss
seen
the
three
sparse
peering.
F
Actually,
the
three
sparse
peering
advantages
and
the
models
for
those
I
put
those
in
there
and
those
are,
for
you
know
the
bandages
and
parallel
links,
densely
mesh
data
centers
and
talking
about
the
controller
based
deployments
and
the
next
revision.
There's
going
to
be
a
discussion
of
BGP
policy
and
submit
I
got
some
editorial
changes
and
anything
else.
So.
F
A
B
Kate
but
LM
gonna
give
an
update
on
LS.
Beer
draft
was
last
updated
in
September
right
before
they
entered
in
we've
incorporated
comments
from
Oscar
and
Artie
Jeter
in
a
fairly
stable,
say,
I'm,
starting
to
look
at
implementations
listed
out
the
feedback.
Here's
a
feedback
from
Fred
Baker
thinks
it's
ready.
There
was
a
minor
net
in
section
five
point:
four,
which
was
taken
care
of
another
review
from
Dan
frost.
B
One
of
the
concerns
he
listed
was
he
thinks
BGP
is
not
designed
for
the
general
purpose
database
distribution.
This
was
more
suggestion
to
80s
to
look
for
a
strategic,
long-term
solution.
Peirong
models
were
thought
to
be
a
little
more
brief.
We've
had
a
text
for
that.
We've
had
a
text
again
on
the
usage
of
sequence
numbers.
He
thought
he
you.
It
would
travel
the
help
with
some
examples
that
has
been
already
taken.
Care
of.
B
There
are
tons
of
timers
that
have
been
used
in
BGP
you,
you
know
clearly
as
part
of
this
extension.
Some
of
this
timers
may
need
to
be
augmented
or
may
not
need
to
be
used
at
all,
and
his
suggestion
was
to
clearly
list
them
out
in
manageability
section
and
talk
about
what
are
those
timelines
that
are
impacted
and
explained
possible
implications.
If
you
would
sort
of
change
them,
we
have
already
done
that
as
part
of
a
separate
manageability
section.
B
Here
are
the
version
two
changes
I'm
not
going
to
go
through
them
since
I
have
already
discussed
this
in
past
presentations,
but
drafts
pretty
much
in
a
stable
State.
There
is,
though,
one
outstanding
point
that
is
worth
discussing,
which
is
about
explicit
withdrawals
very
similar
to
max
age.
Lsa
in
OSPF
should
be
in
corporate.
D
D
Snarky
version
of
this
is
not
a
problem
we're
going
to
solve
this
wait,
it's
a
problem,
which
is
why
we
pay
the
IAB
and
they
don't
deliver.
Okay,
and
indeed,
we
have
a
distributed
database
problem
in
the
IETF
and
elsewhere,
but
I
don't
think
we're
gonna
solve
it
in
time
to
get
this
protocol
out
the
door
a.
F
Coelom
Cisco
Systems
and
a
co-author
on
this
this
this
is
this
is
because
the
reason
for
this
is
and
a
lot
of
people
have
brought
up.
We
knew
this
from
the
start
that
if
a
link
goes
down-
and
you
just
use
the
withdrawal
mechanism
in
BGP,
you
won't
quit
using
that
link
until
every
copy
of
that
is
removed
from
your
BGP
local
rib,
so
or
local
beer.
F
If
the
BG
period
now,
we
don't
really
want
to
change
more
of
the
BGP,
the
BGP
machinery,
to
try
and
maintain
one
copy,
there's
all
sorts
of
things
you
could
do
with
some
invention,
but
we
really
want
to
move
other
than
just
doing
bgp
SPF.
We
want
to
leave
BGP
alone
and
not
raise
the
implementation
bar
for
this
by
adding
all
this
new
invention,
and
also
we
want
to
not
only
implementation,
the
possibility
of
introducing
things
that
don't
work.
We
just
want
to
do
bgp
SPF
now.
F
This
is
this
would
be
a
very
simple
thing
to
do
where,
rather
than
if
a
link
goes
down,
you
would
advertise
that
it's
down,
but
and
for
some
period
of
time,
and
then
you
would
withdraw
the
link
just
so
that
you'd
start
recognize
the
failure
with
the
first
advertisement
that
reaches
you,
which
would
have
a
higher
sequence
number.
You
know
we
have
the
sequence
number
rather
than
the
last.
Q
Hello
Victor
coursing
had
off
on
this
one.
It's
not
actually
on
this
slide.
I
do
it
was
a
slide
couple
slides
ago.
I'm.
Just
a
comment
on
the
comment
about
you
know
is
BGP
the
best
protocol
to
use,
etc.
I
just
want
to
from
an
operator
at
perspective,
I
think
a
lot
of
people
forget
why
operators
chose
B
to
be
in
the
first
place.
It
wasn't
necessarily
because
it
was
the
best
protocol
for
something
operational,
simplicity
and
commonality
was
in
fact
one
of
the
drivers
and
I.
Q
A
Q
Wasn't
before
and
it
wasn't
because
scientifically
they
decided
he
was
necessarily
the
best
thing
to
use
it
was
it
was
there,
it
was
common,
it
simplified
operations
and
a
lot
of
the
things
that
drive
cost
and
organizations,
and
that's
that's
actually.
The
main
reason
why
us
and
a
lot
of
other
folks
used
it.
Q
B
O
E
A
But
but
going
forward
actually
know
with
respect
to
this
work,
so
one
of
the
elements
that
worries
me
a
little
bit
with
respect
to
this
particular
draft
has
been
you
know
the
silence
Ness
on
the
working
group
Amy,
you
know
email
lists,
you
know
with
respect
to
commands
and
feedback
and
additions,
and
this
kind
of
you
know
little
things.
That's
a
bit
unfortunate
now.
A
A
A
So
for
actually
no
further
review.
You
know
this
work.
What
I
was
thinking
about
is
to
actually
know
launch
like,
like
a
working
group.
You
know
last
call
on
this
document
itself
now,
while
doing
that,
so
that
is
something
we
will
start
doing
on
the
working
group.
You
know
email
list,
you
know
as
a
first
step
now,
something
which
ones
you
know
distributed.
Also
between
you
know,
the
different
routing
checks
is
actually
you
know
to
look
into
the
requirement
of
actually
having
like
an
old
working
implementation.
So
that
is
something
you
know.
A
We
still
need
to
look
into
if
you
actually
need
that
for
LS
VR,
yes
or
no-
and
that
is
discussion,
you
know
which
we,
you
know
need
to
be
having
at
some
point
in
time.
You
know
before
pushing
this.
This
work
further.
You
know
off
the
working
group.
Last
call
you
know
to
our
size
genes,
one
right,
so
there
is
definitely
something
now
LS.
A
While
the
major
use
case
scenario
for
this
is
to
running
data
centers,
and
that
will
problem
probably
often
result
like
you
know,
one
vendor
doing
most
of
the
work
of
their,
so
that
problem
is
not
that
we
don't
need
to
have
like
you
know,
one
implementation,
you
know
which
you
know,
which
you
know
as
like
something
running
like
this,
so
that
is
something
that
we
will
be
discussing.
You
know
further
running,
you
know
in
the
background
also,
but
I
will
be
launching
of
working
group.
Last
call
for
this
I
will
expect
and
only
desire.
A
D
A
It
also
means
it's
it's
quite
you
know
it's
it's
it's
a
it's
a
gating
requirement.
D
D
D
A
P
Yes,
right
now,
we
have
three,
tomorrow
might
have
five,
and
it
would
be
nice
to
know
that
the
stuff
I
did
if
I'm.
If
there's
only
one
implementation,
then
de-facto
that
implementations
bugs
become
the
standard,
and
we
really
would
like
for
there
to
be
two,
so
they
could
discover
their
bugs
pretty
fast.