►
From YouTube: IETF101-LSVR-20180319-1330
Description
LSVR meeting session at IETF101
2018/03/19 1330
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
A
So
so
before
we
can
actually
kick
this
thing
off.
We
need
to
have
like
two
sets
of
you
know.
Direct
contributors,
one
is
a
jabber
scribe.
Is
somebody
willing
to
you
know?
What's
the
Java
channel
make
some
notes
from
you
know
from
time
to
time,
and
actually
you
know
provide
us
some
feedback
if
there
would
be
like
any
questions
for
people
who
cannot
be
attending
this
particular
meeting
here,
please
it
is
a
perfect
opportunity
now
to
actually
look
at
the
chairs
and
look
at
how
you
know
great
you're.
A
A
Okay,
nabil!
Thank
you
so
much
so
the
first
you
know
so
now
everybody
can
start
looking
up
from
that
screen
again.
You
know,
and
you
know
and
smile
instead
of
looking
so
mega
busy.
Now
before
we
kick
this
thing
off,
let
us
go
through
first,
you
know
some
set
of
administrivia,
so
the
first
thing
we
have
is
we
have
a
note.
Well,
it
is
a
new
note.
A
Well,
as
you
can
see
so,
give
this
thing
a
look,
and
it
basically
says,
like
you
know
big,
you
know
whatever
you
say
it
is
going
to
be
in
the
public
domain
and
you
know
be
aware
of
that.
Also
we
are
distributing
a
set
of
blue
sheets.
Please
fill
this
document
in
again.
This
will
guarantee
that
the
next
time
you
know
that
our
era,
directors
and
the
rest
of
the
team
will
make
sure
we
have
such
a
comfortable
room
again
for
our
LMS.
We
are
working
group
here
and
also
it
avoids.
A
You
know
people
making
from
a
secretary
making
grumpy
faces
of
us.
That
is
always
you
know.
Very
nice.
People
are
smile
and
are
happy.
So
this
is
agenda.
What
we
have
in
intended
here
so
before
we
kick
this
off,
so
we
gonna,
you
know
bootstrap
it
first
we'd
like
a
small,
welcome
towards
Alice
VR,
and
then
we
gonna,
you
know
we
have
like
three
different
topics
we
would
like
to
discuss.
First
is
the
shortest
path,
routing
extensions
for
PGP
so,
which
is
you
know,
targeting
to
be
Alice
VR
specification?
A
That's
gonna
be
followed
up
with
some
applicability
of
that
particular
you
know
technology
itself
and
then
at
the
end,
this
is
something
which
was
introduced
a
little
bit
late
as
a
draft,
but
we
managed
to
you
know,
push
it
through
to
arts.
You
know
the
data
tracker
anyway
and
as
a
result,
we
can
actually
also
discuss
it
here,
which
would
be
some
extensions
for
link
state
over
Ethernet
and
it
would
actually
find
its
applicability
area.
A
A
So,
just
a
quick
update
on
what
the
lsv
our
Charter
is,
you
know
actually
about,
and
so
in
essence
you
know
lsv
are
you
know
the
intent
is
for
it
to
be
a
standalone
protocol.
So
it's
going
to
be
like
a
hybrid
routing
protocol
and
a
question
we
get
often
is
like
you
know
what
does
hybrid
actually
means,
so
it
actually
means
that
you
know
we
will
be
using
a
combination
of
pub
vector
and
link
state
technology,
no
in
those
applications,
I
guess
where
it
is
like
most
powerful.
A
Now,
when
each
note
in
the
data
center
is
actually
creating
this
link
state
vector
it
needs
to
be
distributed,
you
know
in
an
effective
way,
and
that
is
where
you
know
how
protective
mechanisms
actually
are
going
to
be
utilized.
So,
in
the
first
phase
of
LSD
art,
the
plan
is
to
actually
use.
You
know,
as
this
document
the
initiative
to
use
like
BGP
based
distribution
mechanisms,
how
it
actually
will
work
from
a
pragmatic
perspective.
That
is
what
is
going
to
be
discussed.
A
You
know
in
the
next
few
sections
here
and
then
what
you
see
at
the
bottom
here
is.
The
initial
focus
is
to
actually
really
reuse
what
we
actually
already
have
with
eg
P.
So
bgp
is
a
very
nice
way
to
transport
in
a
loop
free
fashion
in
a
way
which
is,
you
know
well
known
by
the
operational
community
in
a
way
which
is
like
technologically,
you
know
very
good
in
scaling
and
securing
so
on
routes.
So-
and
it
also,
you
know,
it's
very
fine
in
managing
different
error
handling,
so
we
plan
to
actually
reuse.
A
So
what
is
our
focus
of
the
working
group?
Here?
Is
it's
it's
3/4
and
on
one
end,
it
is
actually
to
work
upon
the
standardization
of
the
political
functionality.
It
is
to
document
how
a
link
state
vector
is,
you
know
to
what
it
is
and
how
it
looks
like
and
again
in
the
first
space,
we're
going
to
be
reusing.
A
Obviously,
because
at
this
point
in
time
it
is
very
closely
related
with
the
idea
of
working
group,
so
you
know
any
of
the
changes
you
know.
So
any
modifications
or
extensions,
the
PGP
that
are
not
really
constrained
towards
you
know
being
used
in
lsv
are,
you
know,
should
be
still
carried
on.
You
know
in
the
idea
of
working
group,
and
it
might
actually
no
come
to
here
if
there
is
like
you
know,
general
consensus.
That
actually
is
the
right
thing
to
do
so
only
time
will
tell
and
a
particular
use
case.
A
A
So,
from
the
initial
shorter,
we
have
like
a
few
milestones
and
a
few
documents
to
deliver.
So
so
we
actually
are
shorter
to
deliver
the
following
documents.
So
the
first
one
is
a
specification
describing
you
know
what
is
in
LS
v
together
with
Dijkstra
SPF,
fruit,
pop
calculation
and
utilize.
You
know
the
existing
bgp
protocol,
baseline
functionality
and
the
pitch
pls
packet
encoding.
In
addition
to
that,
we
also
will
document
some
of
the
protocol
extensions.
You
cry
too,
you
know
efficiently,
you
know,
reuse
bhp,
to
facilitate
that
to
distribute
GLS
fees
within
an
ipv4
ipv6.
A
You
know
datacenter,
and
we
will
also
look
into
a
lot
of
the
privacy
and
any
security
considerations.
So
what
you
can
see
is
that
put
like
you
know
a
square
around.
This
is
because
you
know
it's
all,
because
this
can
be
different
documents.
This
can
be
actually
in
a
single
document.
I
think
it
makes
sense
to
actually
you
know,
have
them
into
a
single
document,
but
I
leave
it
up
to
the
working
group
and
what
we
actually
find.
You
know
what
is
best
you're,
not
going
forward
in
addition
to
that.
A
Another
piece
of
information
document
we
need
to
create,
as
a
working
group
is
the
applicability
statement.
So
you
know
we
know
what
L
is
VR
is,
but
it
is
actually
important
to
document
how
to
use
it
correctly
and
which
are
you
know,
different
ways
of
how
to
deploy
LS
vrs
technology.
You
know
in
the
best
possible
way
and
how
will
it
you
know,
for
example,
in
to
react
with
other
routing
protocols
is
maybe
LS.
We
are
running,
on
top
of
you
know
the
same
session
as
BGP
and
so
on
right.
A
So
these
are
things
which
will
be
covered.
You
know
in
that
particular
document
and
then,
of
course
you
know
this
technology
needs
to
be.
You
know
managed
also,
so
we
need
to
document.
We
need
to
look
also
into
the
yang
models.
You
know
specifications
for
Alice
via
so
from
a
milestones
perspective,
so
we
have
been
given
a
very
ambitious
goal,
so
the
plan
is
to
actually
have
something
ready
by
you
know
March
next
year.
That
is
very
ambitious.
We
have
a
lot
of
work
ahead
of
us
going
to
the
direction
now.
A
That
being
said,
there
is
already
like
you
know
quite
some
good
documentation
actually
out
there,
which
seems
to
be
putting
like
a
very
good
hello,
stick
into
the
ground
to
actually
start
working
from
so
in
july,
2019,
so
the
middle
of
next
year.
The
plan
is
to
actually
have
a
young
specification
ready
also
for
the
LSB
inspector,
so
actuation.
So
we
have
a
very
ambitious
goal
and,
as
we
all
know,
people
tend
to
do
a
lot
of
work
just
before
the
IETF
meetings
itself.
So
the
actually
means
you
know.
A
We
only
gonna
get
like
six
weeks
of
fine
good
work.
People
and
normally
you
know.
If
you
don't
do
anything
special.
You
know
if
you
just
go
to
work
the
ITF
meetings,
so
it
was
actually
our
plan
to
do
like
an
interim
meeting
in
between
each
of
the
ITF
meetings
to
keep.
You
know
the
process,
you
know
and
the
development
of
Technology.
You
know
hello
going
forward.
Basically,
so
the
interims
will
actually
happen
somewhere
in
the
middle
between
each
of
the
IDF
meetings.
How
we
will
actually
you
know
do
that.
A
That
is
something
we
still
need
to
so
we're
looking
input
into
both
like
either
like
a
face-to-face
meeting
or
into
WebEx.
You
know,
you
know
online
meetings.
It
will
probably
be
an
online
gatherings,
but
really
to
see
that
together
with
the
area
directors
and
how
they
actually,
you
know,
think
is
the
best
way
for
driving
this
forward.
A
D
So
good
afternoon,
folks,
my
name
is
Kate
Patel
and
I'm.
Gonna
talk
about
the
BGP
based
SPF
extensions.
This
is
the
draft
I've
caught
heard
with
a
CRI
and
when
you
from
Cisco
whim
from
Nokia
sean
from
linkedin
and
derek
from
marcus.
So
we
know
massively
scaled
data.
Centers
have
implemented
some
form
of
simplified
layer,
3
routing
for
the
clause
for
a
centralized
route
control.
They
use
a
controller
based
solution
and
from
an
operational
simplicity.
Lot
of
this
MSD
sees
have
actually
converged
on
pgps
their
routing
protocol
for
their
layer,
3
routing.
D
However,
traditional
route
reflectors
that
are
or
not
in
forwarding
paths
assumes
a
presence
of
an
underlay,
some
form
of
an
IDP
that
help
resolve
next
stops
and
it's
HSN
says
for
BGP
based
MST
sees
they
have
solved
these
problems,
typically
by
using
hop-by-hop
in
band
peering
sessions.
So
the
proposed
solution
here
is
one
where
we
want
to
facilitate
deployments
of
route.
Reflectors
or
out
controllers
that
may
be
in
band
or
may
not
be
in
band
and
yet
achieve
the
operational
simplicity
that
is
given
to
us
by
BGP.
D
D
Only
network
failures
need
to
be
advertised
as
opposed
to
all
routes,
and
this
would
result
into
a
faster
convergence
or
and
or
better
scaling,
and
lastly,
SPF
in
general
lends
itself
to
an
optimal
path.
Selection
in
any
peering
models
beat
her
out
reflector
or
a
controller
based.
Apologies
here
are
the
advantages
of
using
BGP.
It's
already
been
deployed
in
lot
of
MSD
C's
fairly
robust
and
scalable.
Implementations
from
different
vendors
do
exist.
It
has
a
wide
acceptance
and
I
mean
therefore
has
a
minimal
learning
curve
when
you
start
to
play
around
with
PGP.
D
It
runs
on.
Tcp
therefore,
has
a
reliable
transport
and
guaranteed
in
order
delivery
of
data,
supports
incremental
updates
in
any
and
every
mode
avoids
flooding
and
you
could
do
policy-based
routing
and,
lastly,
it
really
lends
itself
fairly
easily
to
multiple
peering
models,
including
reflectors
and/or
controllers.
D
So
then,
here
are
the
changes
that
we
would
probably
need
to
make
to
BGP.
To
achieve
this
functionality,
we've
defined
a
new
Safi
and
therefore
a
new
NLRA
to
support
this
Safi.
The
format
of
the
NLRA
is
exactly
same
as
the
format
of
BGP
LS
that
is
used
to
carry
link
state
information,
define
a
new
capability
and
a
node
attribute
that
will
assure
compatibility
between
two
BGP
speakers
that
are
deploying
this
extensions
supports
multiple
peering
models
and,
lastly,
replace
BGP
best
path,
decision
process
with
Dijkstra.
D
So
in
a
typical
BGP,
efficacy
announcements,
you
have
routes
and
you
have
next
stops.
The
next
stops
in
itself
are
resolved
by
a
presence
of
an
underlay
protocol
in
case
of
BGP
SPF,
since
the
best
path
is
replaced
by
Dykstra,
the
Dijkstra
will
end
up
computing.
The
next
stops,
therefore,
any
next
stops
that
are
received
along
with
the
NL
arise,
are
usually
ignored
upon.
D
E
D
Greatly
simplified
SPF
is
used
again
for
point-to-point
links
in,
and
the
scope
is
constrained
to
a
single
area
will
sub
can
support
the
computations
of
LF,
a
segment
routing,
Sates
and
any
other
IGP
features,
as
LS
has
mechanisms
to
announce
this
within
itself,
so
it
could
be
naturally
extended.
The
current
version
of
the
draft
only
focuses
on
the
simplified
SPF.
The
link
state
AF
that
we
support
in
the
draft
is
a
dual
stack
AF,
which
means
it
supports
both
v6
and
v4
addresses
together.
D
Support
for
VPN
Saffy's
are
kept
out
of
the
scope
for
now,
and
there
is
some
work
needed
to
define
the
interaction
with
existing
unicast
AF
s--
that
are
present
in
bgp.
We
think
this
is
a
matter
of
local
implementation
policy
and
I.
Have
a
the
drafters
make
a
recommendation
as
to
what
should
be
done
and
we'll
be
talking
be
talking
about
it
in
the
latest
slide
from
convergence
standpoint,
no
new
changes
are
needed
to
be
standardized,
however,
the
traffic
does
make
recommendations
for
implementations
to
follow
if
they
would
like
to
achieve
a
better
convergence.
D
One
of
the
recommendations
is
that
any
local
changes
to
the
node
or
a
speaker
should
be
announced
ahead
of
the
changes
that
are
otherwise
pending.
So,
for
example,
in
case
of
session
outages,
you
typically
withdraw
all
the
routes
that
you
have
received
from
your
fellow
bgp
neighbors,
but
be
great
to
announce
the
link
state
information
ahead
of
all
the
remaining
routes
so
as
to
facilitate
so
as
to
facilitate
the
faster
convergence,
there's
also
investigation
and
so
forth.
D
Some
work
that
has
been
done
particularly
to
see
if
we
can
find
ways
to
dampen
the
announcement
of
all
the
routes
that
are
present
in
your
add-in.
For
the
speaker,
where
the
connection
has
gone
down
using
the
variation
of
graceful
restart.
This
would
make
BGP
a
lot
more
closer
to
any
IG
piece,
and
this
is
an
initial
investigation.
That's
been
done.
We
are
not
sure.
D
If
we
need
this
changes,
it
may
not
be
required
simply
reprioritizing
of
how
you
announce
your
updates
may
be
good
enough,
but
then
again,
this
is
the
work
that
the
spin
looked
upon
and
investigated
from
an
officer
fee,
interaction.
Standpoint,
bgp
SPF
today
has
a
support
for
v4
and
v6
unicast
Saffy's.
The
legacy
legacy
legacy.
Bgp
also
has
the
support
for
the
same
surface.
There
is
no
implicit
route
leaking
that
needs
to
be
done
between
this
surface.
Whether
you
leak
or
not
is
an
is
a
matter
of
local
implementation
from
a
policy
standpoint.
D
D
The
draft
will
also
make
the
similar
recommendations
in
next
revision
for
AGP
protocols
also
and
lastly,
the
peering
models,
as
stated
bgp
sessions,
will
support
all
kinds
of
peering
models,
be
it
with
route,
reflector
or
controller
in
band
or
out
of
band
or
a
direct
bearing
connections.
Any
link,
level
discovery
or
liveness
detection
has
to
be
done
outside
the
scope
of
the
work
that
has
been
presented
here.
D
If
the
route
reflectors
and
controllers
are
present
in
a
way
that
they
are
not
directly
connected
to
its
clients,
then
they
would
need
to
resolve
over
some
routing
so
that
the
connections
can
get
established,
and
this
connectivity
dependence
should
not
be
there
on
the
SPS
Safi
in
general.
Furthermore,
the
controllers
could
learn
expected
topology
information,
also
through
some
other
means
other
than
the
protocols
classically.
This
would
be
through
some
configuration
and
the
bgp
SPF
Safi
should
be
able
to
consume
this
seamlessly.
A
A
A
Are
you
know
it
only
pops
up
at
the
head
of
somewhere
so
is
like
any
any
plans
to
actually
know
carve
it
up
into
the
you
know,
into
the
documentation
sector
sections,
as
you
know,
mentioned,
in
the
sharp
itself,
meaning
like
in
documentation.
You
know,
like
you,
know,
specification
of
the
LS
vs
and
then
you
know
cover
up
another
section.
You
know
like
the
distribution
of
the
other
service,
you
know
through
the
network,
then
the
third
one
you
know
calculating
the
you
know
the
SPF,
based
on
the
information
available
in
the
others
reasons
for
it.
A
F
A
E
Synonym
Cisco
Systems:
this
is
where
we
are
using
the
same
ion
or
registry
that
the
IGP
czar
for
algorithms.
Now
the
difference
between
the
normal
SPF
and
the
strict
SPF
is
that
the
normal
SPF
can
be
written
can
be
overwritten
by
local
policy,
whereas
the
strict
SPF
must
take
the
shortest
path,
and
this
I
mean
I
mean
this
was
discussed
ad
nauseam
in
the
is
is
working
group,
but
we're
kind
of
inheriting
this
level
of
complexity.
I
mean
this
distinction
between
normal
and
strict
SPF.
A
D
Be
looking
for
input
to
say
whether
you
know
the
solution
that's
presented
can
is
that
a
refinements
needed
any
good
deployment
use
cases?
If
there
are
operatives
in
the
room,
they
would
look
at
it
and
say
this
is
something
that
is
worth
deploying
or
could
be
deployed.
And,
finally,
you
know
folks
from
implementation
side
of
the
world
to
implement
prototype
and
do
some
interoperability
testing
a.
E
Cylinder,
you
know,
obviously
the
the
most
valuable
would
be
any
prototype
in
an
implementation.
That's
what
I
would
say
we're
hoping
right-
and
you
know
it's
all
of
us-
have
lots
of
jobs
and
right
now,
I'm
not
involved
with
implementing
this,
but
I
really
think
it's
it
I'm,
not
sure.
If
this
is
you
know
the
answer
for
data
centers,
but
I
think
it's
it's
a
very
promising
one.
Otherwise
I
wouldn't
be
spending
the
time
on
the
standardization
and
all
the
investigation
of
it,
but
implementation
would
be
key.
D
Sure
we
can
do
that
and
maybe
from
our
perspective
I
can
make.
One
quick
comment
is
that
if,
if
we
can
issue
a
call
at
least
for
an
adoption
on
a
mailing
list,
maybe
that
will
get
some
discussions
going
and
in
parallel,
we'll
get
the
we'll
get
the
list
of
comments
prepared
up
ahead
of
time.
So
we
could
have
some
discussion
on
it.
G
A
Okay,
no
actually
I
do
have
one
other
question
also
to
the
working
group.
It
is
from
the
people,
you
know
who
have
read
it
and
also
the
people
who
will
actually
read
it.
You
know
coming
out
of
this
working
group
and
thinking
is
the
most
dazzling
idea.
You
ever
see.
You
know
late
your
eyes
upon
in
the
last.
You
know
three
four
years
so
is
you
know
other,
like
any
people
willing
to
you
know
to
actually
give
feedback
about
this
draft
in
the
next
two
weeks.
So.
H
I
I
So
I
hope
that
you
read
this
because
even
if
it's
George
says
this
is
gonna
happen,
we
want
it
to
happen
right
and
you
want
it
to
be
well
specified
and
something
that
people
can
implement
and
something
that
people
actually
read
and
had
some
comments
on.
So
this
experiment
of
or
this
exercise
we're
doing
this
working
group
is
not
so
we
can
rubber
stamp.
What
K
are
already
did-
and
you
know
maybe
I'm
wrong.
I
Maybe
the
document
is
perfect,
but
please,
if
you
think
it's
perfect
already
at
least
come
up
and
say
that
you
have
no
concerns
and
no
comments
and
that
it's
absolutely
perfect
and
we
can
go
from
there.
So
this
is
a
working
group
right.
It's
it's
not
it's
something
that
we
expect
people
to
participate
in
work.
I
Yes,
the
same
not
just
for
this
document
for
the
other
documents
and
and
I
hope
that
the
plan
that
Gunter
and
Victor's
put
out
there
of
having
not
just
meetings
at
the
ATF
but
interim
meetings
to
accelerate
this
work,
that
you
works
and
there's
not
a
one-way
communication
that
we
have.
You
know
discussions
and
comments
and
other
things,
that's
it.
Thank
you.
Yeah.
A
So
what
I'll
do
is
I'll,
actually,
you
know
submit
a
working
group.
Adoption
call
and
I
will
be
looking
for
feedback,
positive
and
negative.
So
if
you
have
only
negative
things
to
say,
please
speak
up.
If
you
only
have
positive
things,
please
pick
up,
but
please
do
not
be
silent,
because
silence
doesn't
help
us
at
all.
We
need
to
have
feedback.
We
want
to
move
this
thing.
C
E
Oh
I
can
see
it
right
here.
That's
good,
so
I'm
not
going
to
make
any
pretenses
here
that
this
document
is
perfect
because
we
put
this
applicability
together
rather
hastily
after
the
working
group
formed
and
there's
there
and
most
of
the
thinking
that's
been
done,
has
been
done
in
the
last
couple
weeks
and
in
the
applicable
'ti,
and
the
slides
actually
include
a
lot
more
than
in
the
base
document.
So
I
would
ask
you
not
to
read
the
document
right
now
and
review
it.
A
E
E
E
E
E
I
believe
care
talked
to
some
of
these
things,
but
as
as
we
as
a
lot,
you
know
we're
already
using
BGP
as
an
underlay
and
a
lot
of
data
centers
and
a
lot
of
these
are
massively
scaled
data
data
centers
and
as
Peters
draft
in
routing
working
group.
Seventy
nine
thirty
eight,
it
just
uses
base
hop-by-hop
BGP,
and
this
would
be
a
direct
replacement
to
that.
E
Additionally,
this
kind
of
fits
and
we'll
go
more
into
this
into
the
central
controller
model,
because
we're
also
already
using
central
controllers
and
the
main
mechanism
for
providing
topology
information
to
these
controllers
is
BGP
LS.
Today,
again,
we
can.
We
can
look
at
this
from
a
route
as
opposed
to
a
route,
reflector,
topology
and
I'm,
going
to
talk
more
about
this
as
well,
but
the
the
period
model
in
79
38
doesn't
really
lend
itself
to
route
reflectors.
Just
a
very
simple
hop-by-hop
exchange
of
a
BGP
enter
Ally
I.
E
Really
want
to
get
to
the
beef
of
this
okay.
I
just
want
to
point
out
and
I:
don't
want
it
a
lot
of
times
we
put
up
these
slides
people
are
well
that
are
really.
Experts
in
the
topologies
will
point
out
that
this
isn't
true.
I
it'll
support
either
fat
tree
or
claws.
I
know
in
the
Charter.
The
working
group
is
data
center,
LS
VR
for
data
center,
but
I'd
also
like
to
point
out
that
bgp
SPF
could
be
used
in
other
areas.
E
Here's
the
79
38
now
the
interesting
thing
from
this
is
this
is
a
three
tiered
clause.
That's
taken
directly
from
79
38
as
the
other
two
pictures
you
saw
were
stolen
as
well,
but
you
would.
You
would
have
a
BGP
session
on
the
local
address
of
all
of
these
links
between
all
the
switches.
You
know
whether
be
in
in
the
leaf
or
the
aggregation
or
the
spine
or
layer,
so
they
called
it
in
the
topology
in
this
would
be
a
five
stage.
E
Five
stage
topology,
as
per
the
terminology
in
79,
38
and
I,
think
I
talked
to
this
as
far
as
applicability,
we're
not
looking
at
you
know,
VPNs
or
anything
like
that.
You
would
use
normal
BGP
for
the
overlays,
all
the
address
families
other
than
the
base,
unicast
ipv6
and
ipv4,
especially
for
this
first.
You
know
the
these
documents
that
we're
trying
to
do
very
quickly
in
a
year
you
wouldn't
we
wouldn't
even
consider
using
it
for,
say,
VPN.
E
Now
I'm
going
to
talk
more
about
this,
but
one
of
the
drawbacks
that
people
have
pointed
out,
I
believe
I
believe
Jeff
Hass
was
the
first
one
to
point
this
out
was
that
if
you
have
a
node
failure
and
that
your
best
path,
you
need
to
withdraw,
discard
all
the
NRI
from
a
peer,
so
Clause
topologies.
You
know
a
lot
of
these
we've
seen
in
data
centers
up
to
64
way,
ecmp
from
the
Leafs
to
spying
layer.
E
E
It's
it's
bad
in
this
because
you
really
only
you
just
want
to
make
sure
that
everybody
has
a
copy
of
the
NRI
and
since
enter
lies
are
unique
and
if
you,
if
you're
familiar
very
familiar,
RFC
77
52,
you
know
that
the
NR
a
lie
is
defined
by
the
Noda
script.
I
mean
by
the
descriptors.
You
know
no
descriptors,
link,
descriptors
and
prefect
descriptors,
depending
on
what
type
of
BGP
LSN
or
I
you're.
Having
so
really
the
only
version,
an
NRI
you're
interested
is
the
one
that's
originated,
and
you
only
need
one
copy
of
that.
E
Now,
I'm
also
thinking
what
you
do
is
you
could
also
do
sparse
peering.
In
other
words,
in
some
of
these
more
dense
topologies,
these
dense
cost
apologies.
You
wouldn't
run
a
BGP
session
on
every
link.
Rather,
you
would
use
BFD
or
something
else,
Randy's
going
to
talk
about
a
different
proposal,
but
you'd
use
you
do
the
library
wirelessly
the
liveliness
detection
outside
of
BGP
and
then,
depending
on
that
you
would
advertise
enter
alike
and
corresponding
to
those
links.
E
E
E
Now
there
was
one
other
thing:
I
wanted
to
point
out
here.
Oh
I
wanted
to
point
out
that
the
controllers
reflectively
only
you-
could
also
cut
down
on
the
amount
of
topology
information
disseminated
by
using
a
policy
to
determine
say
that
left
spy
normally
reflects
the
routes
from
the
left
side
and
the
right
spine.
Only
the
controller
on
the
right
only
reflects
the
NRI
from
the
right
side,
further
reducing
mitigating
the
effects
of
having
a
copy
of
the
be
ribbed
for
each
best
path.
Upstream.
E
E
But
you'd
really,
you
need
some
other
way
to
make
sure
you
had
routes
for
those
bgp
sessions
and
determine
the
right
paths
and
I'll
just
give
you
a
picture,
and
you
can
see
this
so
in
this
case
the
only
bgp
sessions
for
this
bgp
f
SPF
are
with
the
two
controllers
and
there
is
a
session.
You
know
you
know
that
both
controllers
or
you
could
have
three
controllers
now.
The
only
the
only
complexity
is
is
that
you
and
you
see
the
red
and
green
for
the
two
controllers
different
at
different
sessions.
E
I
had
to
point
that
out
because
I
had
upgraded
to
high
sierra.
I
had
to
pay
a
hundred
dollars
to
get
my
OmniGraffle
to
work
again
once
I
did
that
anyway,
this
this
this
one
in
this
situation,
you
notice
that
the
leaves
don't
have
a
direct
route
to
pierce
the
controllers.
So
you
would
have
to
do
that
out.
A
band
and
I
think
the
proposal
rant
Randi
with
the
discovery
mechanism
around
going
to
talk
about
after
this
is
one
way
to
do
this.
E
E
And
you're
also
also
the
controller
is
all
is,
is
already
getting
is
getting
bgp,
LS
and
one
side
benefit
of
this
is
the
distribution
of
the
BGP.
Ls
could
be
used
for
other
applications
for
in,
for
you
know,
for
example,
P
GPRS
RTE
uses
the
same
Beach,
BGP
LS,
or
the
same
or
more
of
the
BGP
LS
for
computing.
The
traffic
engineered
paths
through
the
data
center
fabric.
E
So
this
wouldn't
be
a
Bible
internet
draft
if
we
didn't
this
isn't
in
there
yet.
But
this
is
just
some
thinking
that
I
did
in
the
last
week
for
this.
This
really
isn't
much
different
than
RFC
79
38.
You
know
the
hop
by
hop
BG,
BGP
pureeing.
The
only
thing
that
it's
different
is,
you
know
we
have
we
probably
since
it
is
a
new
proposal
and
79
38.
This
is
standard
tracks
in
79,
38
was
just
in
ferment
informational.
E
We
really
want
to
suggest
some
good
security
and
what
I
do
is
I
mandate,
the
use
of
TD
TTL
security
for
a
BGP
session
bgp
sessions
within
the
fabric.
That's
the
first
thing,
and
with
that
you
really
get
a
lot
of
protection.
You
really
you
know,
because
you
get
a
protection
on
all
your
inter
switch
links
in
the
data
center
and
really
it's
only.
E
So
if
you,
if
you,
if
you
think
you
have
problems
with
vulnerability
from
outs
from
like,
say
the
servers
to
the
leaves,
you
could
also
use
RFC
61
92,
which
are
recommendations
and
by
the
way
most
data
center
switch
vendors-
do
have
something
you
know
do
have
some
firewall
rules
to
protect
the
control
plane
anyway,
I
mean
some
that
come
pre-configured,
at
least
some
of
the
ones
that
I'm
familiar
with
these
are
recommendations
for
firewall.
You
know
for
what
you
do
on
interfaces
to
protect
the
control
plane,
I,
don't
know
it's
it.
E
It's
a
good
RFC.
If
you
haven't
read
that
one
yet
I'd
also
say
that
I'd
recommend
that
no
I,
don't
think
I,
don't
know
why.
But
if
you
had
a
datacenter
where
somebody
could
get
in
and
get
around
the
TTL
security
and
subvert
the
fabric,
which
I
don't
think
a
lot
of
people
worry
about,
but
there
could
be
some
data
centers
where
I
don't
know,
maybe
if
they're
physically
geographically
disconnected
and
go
over
the
public
internet
or
something
I,
don't
know,
I,
don't
know
how
this,
but
in
that
case,
then
you
could
use
TCP.
E
E
E
Just
wanted
to
point
out
one
more
thing
you
see
in
this
clause:
this
is
the
picture
I'm
talking
about
where
you
see
that
the
the
leaf
could
have
four.
All
four
of
those
spines
they'd
have
a
separate
copy
of
the
NRI,
and
we
wanted
to
determine
whether
that
is
a
big
problem
or
not
I.
Think
initially
we're
not
going
to
do
a
lot
to
make
this
more
like
the
iGPS,
because
we
could
go.
E
You
know
off
the
deep
end
and
start
changing
it
to
make
it
more
like
adding
things
like
aging
and
mechanisms
to
make
sure
stale
enteral
I
get
deleted.
Just
like
I
gp's
have
and
go
off,
but
I
think
once
you
do,
that
you're
kind
of
losing
a
lot
of
the
synergies,
your
your
your
you
have,
and
those
would
be
things
that
wouldn't
be.
E
Spf,
that's
already
a
fairly
fundamental
change,
but
it's
fairly
well
understood
where,
as
we
start
going
into
the
into
ideas
of
determining
when
to
send
data,
that's
going
one
step
further
and
we're
going
to
try
and
stay
away
from
those,
at
least
for
the
first.
This
first
version
of
documents
are
trying
to
get
out
by
March
next
year.
E
And
here
again,
so
you
have
BGP
for
for
your
underlay,
yet
BGP
for
all
your
overlay
services
and
you
have
the
synergy
of
the
inner
the
the
same
bgp
LS.
It's
you
know,
even
though
we're
using
a
separate
address
family
that
doesn't
mean
the
controller,
can't
avail
it
for
calculating
the
sr
any
and
not
just
srte,
but
any
TE
paths.
I
can
tell
Tony's
enthused
and.
E
E
H
Has
so
I
was
waiting
for
your
presentation
that
make
this
common
see
posted
rest
here,
one
of
the
things
the
chairs
brought
up
is
you
need
a
yang
module
at
some
point.
One
of
these
two
sets
of
documents
needs
to
talk
about
how
this
is
going
to
interact
with
the
existing
hapen
cudgel,
because
you
are
still
going
to
need
a
provisioning
layer
which
know
partially
lives
in
there.
Your
configuration
and
operational
state
are
significantly
different,
so
there's
gonna
be
a
lot
of
weird
interactions.
All.
J
Bloomberg
LP
so
under
applicability
statement,
I
mean
it's
great
that
you
guys
have
developed
yet
another
product
call
to
help.
You
know
massively
scaled
datacenters
yeah,
that's
amazing.
They
think
we're.
You
know
the
only
place
where
I
see
this
in
any
way
like
applicable,
is
if
I'm
going
to
start
building
my
data
center
or
you
know
special.
You
know,
exchange
topologies
that
are
going
to
be
based
and
you
that
are
not
going
to
be
pure
Claus
or
they're
not
going
to
be
pure
fat,
trees
or
they're
not
going
to
be.
J
E
J
You
know
I'm,
the
the
the
problem
is
I
mean
this
can
be
adapted
absolutely
for
Claus.
For
that
tree.
This
could
be
adapted
for
anything
I'm.
Just
saying
that
the
value
that
I
mean
if
I
mean,
if
you're
going
to
talk
about
it,
the
primary
you
applicability
is,
if
you're
going
to
be
building,
what
I
would
call
irregular
topologies
and
you
need
to
support
being-
is
just
supportive
in
those
topologies
and
you
need
to
do
all
kinds
of
optimizations.
Then
I
think
this
is
what
probably
this
should
be.
You
know
aiming
for.
E
J
B
He
can
ask
quite
a
couple
questions
in
so
just
for
clarification,
so
we
got
a
right.
Basically,
which
would
put
in
the
draft
was
the
apparent
initial
considerations
would
be
cloths
or
factories
that
could
easily
be
used
in
those
environments,
but
you're
refreshing
that
those
are
not
necessarily
limiting
well.
E
One
thing
we've
been
saying
about
this,
which
is
really
really
nice
for
bgp
SPF.
Is
you
get?
You
could
take
all
this
innovation
we've
been
doing
over
decades
in
iGPS,
for
example,
LFA
and
all
the
different
flavors
of
LFA.
However,
in
a
class
environment
I
mean
in
a
class,
topology
LFA
doesn't
really
buy
you
a
lot.
I
mean
you,
you
can
get
if
you
have
have
fast.
E
Rehashing
of
your
next
stops
on
failure,
because
you
have
this
dense
ecmp,
you
don't
need
LFA,
you
don't
need
all
these
flavors
you're,
not
gonna.
Have
it
you
don't
have
looping
topologies
right,
you
don't
need
you
just
just
if
you,
if
you
rehash
your
next
hops,
based
on
failures
really
quickly
and
do
it
well
and
in
our
pure
fat
tree
or
your
ear.
You're
gonna
get
everything
you
need
in
one.
E
Well,
I
was
just
gonna
say,
but
but
you
could
use
bgp
SPF
in
different
topologies
and
I
know.
This
is
only
data
center,
but
you
know
like
say
you
wanna
say
outside
of
this
working
group.
You
wanted
to
use,
have
a
pure
BGP
that
had
a
BGP
overlay
and
you
wanted
to
use
BGP
on
a
ring.
Like
a
metro
ring,
you
could
do
LFA
with
that
ya.
B
E
Or
benefit
if
before,
for
the,
for
the
second
option,
where
you
appear
with
I,
can
a
a
BGP
neighbor,
it's
more
than
one
hop
away.
Of
course
you
need
some
way
to
get
to
him
any
time
you
take
it
beyond
one
hop.
You
need
something
else,
but
for
the
first
sparse
one
where
you
only
have
you
only
appear
with
a
subset
of
your
directly
attached
neighbors.
No,
you
don't
need
anything
for
that.
H
C
A
Just
about
your
ideas
about
how
this
thing,
so
you
can't
go
back
a
few
slides,
actually
the
power.
So
if
you
look
at
this
particular
take
you
see
like
lots
of
stuff
traveling
over,
you
know,
potentially
the
same
bgp
session,
so
I
think
it's
also
touch
upon
what
Jeff
actually
was
kind
of
mentioning
earlier
is:
how
do
we
see
this
thing
going
forward?
Well
everything
in
order
to
travel
on
the
same
session,
including
elders.
If
they
are
or
do
we
want
to
go
as
strict
going
forward
to
say?
A
D
Today,
BGP
provides
means
to
step,
set
up
multiple
sessions.
You
could
set
up
multiple
sessions
and
separate
them
out.
You
can
have
a
single
session
and,
as
this
is
a
different
Safi,
you
could
carry
it
completely
honored
different
Safi
right.
So
there
is
no
interdependency
between
that.
It
seems
like
that
would
be.
A
operator
is
call
as
so
how
he
would
want
to
configure
these
sessions
and
how
you
would
want
to
operate
this
within
his
or
her
net.
Yes,.
A
H
As
sell
care,
if
this
was
a
normal
routing,
I'd
say
I
agree
with
you.
This
stuff
is
latency-sensitive,
you
probably
don't
want
to
have
the
stuff
stovepipe
no
caught
behind
the
cue
of
other
things.
That
may
have
a
lot
more
messages.
This
is
you
know,
in
spite
of
the
fact,
I
believe
in
prioritization.
I
think
this
is
something
I
would
recommend
you
all
strongly
advocate
for
separation
of
sessions,
Gilligan
I'm
perfectly
fine
with.
D
E
Yeah
I
think
that's
something
that's
missing
from
my
slides
and
then
which
will
go
into
that
ability,
but
I
think
you
definitely
want
the
same
way
that
I
we
recommended
that
you
give
the
routing
preference
or
administrative
distance.
You
give
the
bgp
SPF
since
the
underlay
precedence
you'd,
want
to
say
for
processing
and
queue
handling
and
update
generation
everything
yet
which
should
be
given
preference.
I
L
Id,
our
chair,
John
Scudder,
juniper
networks,
Oh
Oh,
Mike
I,
also
in
the
idea,
our
chair,
but
yeah
I
guess
I
just
want
to
sort
of
underline
with
the
last
couple
people
said,
which
is
its
kind
of
ironic,
to
have
a
slide
that
says
operational
simplicity
up
at
the
front
of
the
room.
Well
care!
Is
it
in
the
back
of
the
room,
saying
yeah,
you
know
we
can
do
it
this
way.
L
B
Okay,
comment:
hat
off
so
down
to
Mike
here,
Victor
forcing
still
dying,
I
guess
my
thoughts
are.
This
is
more
of
a
perspective.
I
did
hear
the
comment
recently
that
you
know
kind
of
there's
a
problem
solved
scenario
I
mean
you
know.
From
my
operational
background,
you
know,
building
network
for
about
twenty
years
was
I,
never
thought
any
fun
was
ever
fully
solved.
I
thought
we
were
getting
better
at
solving
problems.
B
The
types
of
networks
we've
built
and
the
reason
why
we're
building
them
and
the
thought
that
goes
into
what
we
need
to
support
has
changed
at
least
from
what
I
can
see
from
you.
Nine
news
till
now,
so
I've
always
thought
that
having
a
few
options
have
been
beneficial.
We've
exercised
a
lot
of
those
options
over
time,
there's
not
a
network
that
we
have
built
from
scratch.
That
really
looked
like
the
previous
network
foundation.
B
It
was
always
been
Delta's
and
those
were
being
driven
because
the
requirements
have
changed
drastically
when
I
think
about
what's
going
into
building
larger
infrastructure
people
call
it
cloud,
but
there's
things
that
write
large
data
centers
they
scale
very
differently,
though
those
didn't
exist.
Ten
years
ago,
or
maybe
they
did
too
here's
ago
twenty
years
ago,
we
weren't
talking
about
that
we're
building
number
two
that
look
very
different,
we're
gluing
together,
very
different.
So
from
the
operational
side,
I've
always
found
it
beneficial
to
have
options,
auctions
where
we
can
actually
choose
to
build
something.
B
The
way
we
need
to
build
it,
and
you
know,
even
if
I
go
back
to
the
LS
meetings
like
look
at
ISS
versus
OSPF
I
mean
use
them
both.
Sometimes
one
was
better
than
the
other
I
would
not
know
what
life
would
have
been
had
I
not
had
that
choice.
So,
from
an
operational
standpoint,
I
feel
that
choice
and
just
to
comment
on
this
last
one
on
simplicity,
I
mean
yeah
I
I,
like
options
as
an
operator
to
do
it.
One
of
the
other
way
recommendation
is
always
good.
I,
like
options.
H
Jeff
has
so
prioritization,
maybe
look
back
in
the
draft
for
a
point
we
had
talked
about
in
the
prior
said,
which
was
TCP
interactions
so
again
for
normal
BGP.
You
can
live
with
no
thing
stretching
out
a
little
bit
based
on
TCP
timer's,
because
you
lost
packets.
That
sort
of
thing
again
with
things
that
are
link
state
dish.
Do
you
care
about
latency
a
lot
for
you
start
running
into
a
TCP
back
off
no
issues,
then
this
potentially
interacts
with
know
the
latency
requirements
to
get
these
this
data
across
the
BGP
session.
H
E
I,
haven't
I,
haven't
seen
this,
but
I've
heard
people
that
talk
about
this
isn't
BGP
processing,
but
I've
heard
people
talk
about
route,
reflector
implementations
and
how
you
know
full
full
BGP
tables
are
sent
in.
You
know
like
one
and
a
half
seconds
or
less
there's
something
you
know,
I
I,
so
I'm
not
sure.
Let
me
let
me
this
is
something
which
I
think
we
need
to
discuss
to
whether
with
TCP.
You
really
have
problems
with
back
off
and
whatnot.
E
H
E
H
F
F
F
C
F
One
a
couple
comments
on
a
C's
thing:
we
have
a
long
history
on
the
internet
of
things
designed
for
the
land
end
up
on
the
web
when
you're
talking
about
BGP
security,
one
hop
TTL,
just
don't
cut
it,
and
this
well
I'm
gonna
present
one
of
the
big
gaps
in
security.
One
of
the
reasons
I'm
pushing
this
instead
of
lldp
is
because
I
believe
we
need
security
for
link
state
and
no.
This
is
ok,
fine
and.
F
Lldp
has
an
artificial
limit
of
1,500
bytes
and
I
like
to
carry
big
fat
security
globs
around
so
anyway.
Motivation
here
is
no
central
controller.
That's
not
really
true.
I
have
a
friend
who
works
for
a
small
ad
company
who
says
they
like
to
run
their
cloths
hot
and
they
want
to
micromanage
flows.
So
this
is
essentially
a
length
discovery
protocol
that
can
push
up
to
bgp
SPF,
which
I'm
going
to
use
as
all
the
examples,
because
that's
my
admission
to
this
show,
but
it
could
be
used
with
central
controllers,
etc.
F
F
You
you've
got
an
east-west
protocol
at
the
ether
level.
Okay,
Mac
link-state
is
exchanged
and
pushed
up
the
stack
northbound,
the
a
visa
fee.
Information
is
gathered
over
the
ether
to
ether
protocol
and
then
SPF
or
whatever
your
controller
is
operates
at
a
higher
level.
Okay,
so
the
east-west
protocol
and
I'm
gonna
skip
the
packet
porn.
This
is
full
of
packet
porn,
but
let's
just
pay
attention
to
the
core
of
it:
the
ether
protocols,
PD,
u
sequences
with
check
sums
all
the
normal
garbage,
a
PD
use
one
or
more
Ethernet
frames.
F
You
can
reassemble
them
if
you
need
to
and
payloads
are
assumed
to
be
IP
over
the
same
Ethernet.
In
other
words,
hey
I'm,
going
to
be
competing
with
payload
traffic,
so
we
have
to
think
about
failure
and
congestion.
Okay,
there's
a
basic
PD
you
as
Flags.
It
has
a
checksum
okay,
because
we
don't
trust
the
hardware
and
there
are
two
basic
types
which
is
hello:
keep
alive
capability
exchange,
ok,
checksum,
blah
blah
blah.
What
essentially
happens
is
it
wakes
up
and
we
both
say
hello
to
each
other.
F
If
I
can
figure
out
how
to
operate
this?
Ok,
so
that
allows
me
to
discover
your
Mac,
because
you
shout
I
shout
and
find
out
each
other's
math
for
this
I.
Consider
the
ASN,
the
identifier,
because
we're
doing
this
for
LS
for
our
SPF.
Ok,
we
negotiate
timers.
If
we
want
to
change
them,
otherwise
keep
a
lives.
I
forget
what
the
standards
are.
I'll
get
to
that
what
the
default
is.
Then
we
can
negotiate
between
us.
F
What
a
fee
Saffy's
are
supported,
using
capability
exchange,
hey
I
support,
v6,
hey
I,
support,
v4
s,
support,
MPLS,
v6,
etc.
I
had
now
my
add
my
layer,
three
layer,
two
and
a
half
or
layer,
3,
NLR
eyes
or
sixes
mps,
MPLS
labels,
etc.
We
now
have
full
reach
ability,
information
which
we
can
push:
northbound.
Okay,
here's
a
keepalive
blah
blah
once
we
know
the
max,
we
can
start
running
hot
keep
lives
very
frequently.
F
Okay,
though
she
eight
capabilities,
negotiate,
timers.
Okay,
now
we
know
the
max
and
das
ends.
Now
we
can
start
talking
about
a
fee
Saffy's
this,
as
its
defined
so
far
supports
before
v6
MPLS.
You
could
do
other
tunnels.
Okay,
so
now
we
can
exchange
our
interface
a
fee.
Safi
stuff,
okay,
for
what
the
ones
we
have
negotiated.
F
So
I
can
say
here's
my
list,
and
this
is
the
prompt.
My
primary
address.
Okay,
it's
over
an
unreliable
transport,
so
again
they're
sequence,
numbers.
The
sequent
numbers
are
act
all
that
kind
of
stuff
you'll
enjoy
reading
the
draft.
You
don't
want
me
to
drag
you
through
this
back
at
bond.
Okay,
there's
an
act
here,
for
instance
in
ipv4
announcement,
which
has,
as
I
said,
sequence
number
and
all
that
stuff.
The
count
of
this
is
the
v4
addresses
we're
gonna
have
here:
are
you
adding
it
dropping
it
and
who's
the
primary?
F
So,
for
instance,
if
an
address
change
or
a
Mac
changes,
that
change
is
immediately
noticed.
You
generate
an
ad
in
the
drop
and
it's
pushed
up
the
stack
okay
same
six
same
MPLS,
etc.
Okay,
if
you
have
one
label
associated
with
multiple
athlete,
Saffy's
use
multiple
label
PB
use
with
the
same
label;
okay.
So
now
you
can
test
IP
now
or
later,
two
and
a
half.
F
If
you
insist
liveness,
if
you
want-
and
now
you
can
start
talking
about,
BFD,
etc,
if
you're
not
satisfied
with
the
ether
level,
liveness
being
pushed
up
okay,
so
now
we
know
our
interfaces,
we
know
our
EFI
Saffy's.
We
made
friends
with
our
neighbors.
We
want
to
push
it
northbound,
okay,
so
we
now
use
what
we
call
a
north/south
protocol
to
take
it.
F
F
F
Okay,
so
there's
packet
porn
about
all
that
stuff:
okay,
nothing
very
exciting,
yeah
he's
happy
types
etc.
The
shim
takes
the
above
and
translates
it
into
LS
PDUs,
okay,
7750,
okay,
the
topology
layer
like
SPF,
can
now
construct
the
full
link
state
and
IP
and
mpls
topology
bgp
SPF
can
run
that's
all.
You
need.
F
F
F
E
E
Will
this
will
this
will
definitely
work
better
than
say
lldp,
because
we're
doing
it
here
we're
doing
it
specifically
for
this
task
right
for
this
or
or
do
we
want
to,
you
know,
try
and
write
on
right
on
those
I'm
I
mean
I'm
I'm
supportive
of
this
work,
but
I,
but
I
know
that.
That's
that's!
That's
the
big
question,
we're
gonna
add
you
know
we're
gonna
ask
have
to
ask
ourselves
because
this
I
mean
for
BGP.
This
is
really
you
know.
This
is
doing
something
that's
customized,
just
like
the
whole
net.
E
F
For
a
reason,
okay,
you
can
push
whatever
you
want
up
there.
Yeah
my
ticket
to
admission
to
this
party
was
that
it
works
with
SPF
right.
F
H
K
Yeah,
that's
just
on
the
where
to
discuss
it,
please,
to
remember
that
our
tgw
G
exists
as
well
for
talking
about
routing
related
stuff
that
doesn't
have
a
better
palom.
If
this
fits
perfectly
in
LS
VR,
that's
great,
but
if
you
think
it
has
the
wider
applicability
which
you
seem
to
be
saying,
our
tgw
G
would
be
a
fine
place
to
have.
It
talked
about
as
well.
A
A
F
A
F
A
New
so
and
that's
sort
of
like
we
need
to
assess
you
know
what
are
the
exact
you
know,
requirements
from
a
protocol-specific.
You
know
kind
of
perspective
and
see
how
you
know
which
solution
maps
the
best
thing
to
that
I
think
it
would
be
a
very
interesting
discussion
topic
for
the
next
interim
to
assess.
You
know
what
would
be
a
knock.
You
know
a
good
path
forward.
I,
don't
think
we
should
wait
too
long
for
this
kind
of
things.
A
It
is
actually
you
know
at
this
point
in
time
and
out
of
chartres
also-
and
I
would
like
to
finish
our
milestone
deliverables
as
a
first.
You
know
topic,
but
I
do
see
this
as
a
very
interesting.
You
know
sight
track.
We
actually
can
work
upon,
but
it
should
not
be
no
influencing
our
outcome
of
deliverables
in
about
a
year.
From
now,
just.
F
B
B
Yes,
not
okay,
so
we
have
a
couple
of
drafts
that
there's
some
initial
review.
We
had
today
it's
going
to
recap
that
and
get
a
sense
of
the
room
on
a
couple
of
points
here.
So
the
first
draft
would
like
to
discuss
was
the
LSB,
our
BGP
SPF
document?
That
was
the
document
discussed
by
Kier
earlier
on
in
the
session
coming
out
of
that
document
review
it
looked
like
we
were
still
looking
for
some
additional
reviewers
possible.
Within
this
group.
B
We
had
a
number
of
folks
close
to
about
20
that
showed
hands
that
they
had
read
the
document.
What
we
were
looking
for
was
list
discussion
and
whether
that
be
supportive
or
Corrections
to
document
other
ideas,
whether
it
looks
like
positive
or
negative,
we
want
that
discussion
on
the
list
and
so
that
we
can
figure
out.
Is
this
document
in
a
form
that
we
can
then
proceed
to
adoption
of
the
working
group
or
does
the
document
require
some
adjustments
before
we
can
do
that
or
take
any
other
particular
suggestions
we
might
get
in
a
list?
B
Would
that
be
fair
to
as
an
encapsulation
inventor?
From
what
we
heard
today,
yeah
I,
don't
think
we
need
to
show
hands
for
that
I
think
we
had
to
show
hands
for
the
never
read
okay,
so
that
was
that's
the
what
we
would
like
to
see
it
in
that
list
and
if
that
can
be
done,
I
know
it's
asking
a
lot.
A
lot
of
folks
are
busy
coming
out
of
this
week.
To
have
that
done
with
the
next
couple
of
weeks.
B
That'd
be
very
helpful
for
us
so
that
we
can
work
towards
what
we
would
do
in
an
interim
meeting
to
help
progress.
The
work
is
of
the
timelines.
We
do
have
the
second
document
that
we
wanted
discuss
and
list,
and
we
have
a
commitment.
Pseudo
commitment,
desi
for
the
14th
of
April
I,
believe
you've
signed
in
blood.
For
that
we
would
once
that's
produced.
I
was
joking
by
the
way
once
that's
produced.
We
would
like
to
get
list
discussion
on
that
particular
document.
There
was
quite
a
bit
of
discussion
here
today.
B
It
would
be
good
to
then
get
that
document
read
and
discussed
at
length
within
the
within
the
mailing
list,
so
that
we
can
look
also
to
get
a
sense
of
whether
we
can
adopt
that
as
a
working
group
document
within
the
within
the
team,
and
then
the
third
document
was
with
the
control
plane
over
Ethernet.
The
one
we
just
concluded
with
sounds
like
the
consensus
was
potentially
some
additional
review
at
the
routing
working
group,
since
this
might
have
wider
applicability
than
just
within
this
particular
working
group,
and
what
I
got
from
my
co-chair
was.
B
H
D
Okay,
then,
one
of
the
reasons
why
we
presented
it
here
is
because,
aside
from
what
we
do
with
LS,
we
are
what
actually
would
be
really
helpful
is
some
form
of
a
neighbor
discovery.
Now
we
have
had
solutions
that
run
over
lldp
and
few
other
ways
to
incorporate
this.
It
would
be
nice
and
I
think
it
would
be
it'd
be
super
cool
if
there
is
a
generic
mechanism
that
has
been
devised
to
do
the
neighbor
discovery
kind
of
like
how
we
have
standardized,
b.a.p
and
I.