►
From YouTube: IETF102-LSVR-20180718-0930
Description
LSVR meeting session at IETF102
2018/07/18 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
B
Okay,
thank
you,
everyone
for
coming
to
LSB
our
Montreal
IAT
f-102,
so
we
Gunther
is
going
to
walk
us
through
in
a
moment
some
introductory
slides.
Could
everyone
hear
me
by
the
way,
yeah?
Okay,
great
some
introduction,
slides
we're
gonna
review
the
agenda
just
before
we
do
that
blue
sheets
have
gone
out
and
should
be
circling
the
bases
now
and
we
we're
going
to
go
over
the
agenda.
B
If
anyone
has
any
challenges
or
one
of
those
move
things
around,
let
us
know:
we've
broken
the
sessions
up
to
try
to
structure
the
conversation
as
best
we
can
and
we're
also
going
to
have
a
review
of
the
inter
meeting
we
had
in
June
just
so.
Everyone
here
has
an
opportunity
to
at
least
get
the
highlights
of
that
as
well.
So
Condor.
B
C
C
C
C
B
B
So,
as
mentioned
earlier,
we're
just
doing
a
quick
intro.
We
will
have
a
gentleman
over
me.
Echo
do
help
us
with
a
review
of
the
inter
meeting.
We
had
back
in
June
made
some
good
progress,
as
well
as
a
couple
of
key
actions
coming
out
of
that
particular
interim
meeting.
We're
going
to
maintain
interim
meetings
throughout
the
next
year
or
so,
given
the
current
momentum
we
need
to
maintain
for
lsv
are
and
then
we're
going
to
talk
about
the
actual
bgp
SPF
draft,
which
is
now
adopted,
adopted
Osment
within
the
within
the
working
group.
B
B
Now
that
the
cutoff
period
is
over,
then
we
will
have
a
focused
discussion
around
some
of
the
requirements
of
neighbored
neighbor
discovery
and
liveness
and
willed
as
we
review
the
inter
meeting
outcomes
and
actions
we'll
kind
of
dive
into
why
that
was
in
action
and
how
we
structure
that
within
the
meeting
and
then
we'll
have
a
closing
with
making
sure
we
capture
any
actions
out
of
this
meeting
and
what
we
would
likely
take
into
our
next
in
term,
meaning
so
before
I
proceed.
Or
is
there
any
questions
or
comments
on
the
agenda?
Hi.
D
B
B
F
I
apologize
for
that
so,
while
in
the
virtual
queue
I
can't
see
the
presentation
screen
so
I
think
we'll,
maybe
I
can
go
back
over
here.
Can
you
still
hear
me.
F
F
As
far
as
actual
content
goes,
QR
gave
a
an
update
on
the
BGP
based
SPF
draft.
The
updates
that
had
been
made
due
to
the
comments
on
the
working
group
and
then
I'll
talk
a
little
bit.
You
know
there's
a
little
bit
more
detail
in
the
next
slide
and
then
AC
went
through
the
applicability
draft
and
then
we
kind
of
established
our
next
step
so
so
AC
excuse
me:
yours,
update
on
bgp
SPF,
a
draft
it
was
submitted.
Most
of
the
comments
were
included
in
the
draft.
F
So
there
was
some
minor
changes
made
there,
and
then
we
talked
about
an
issue
that
Gunter
brought
up
was
what,
if
there's
different,
link
state
databases
on
the
nodes,
and
we
had
some
some
discussion
about
that
as
well.
Next
slide,
please,
after
that,
AC
went
through
the
applicability
document
he
went
through
each
of
these.
F
Go
ahead
next
slide,
so
so
the
next
steps
were
one.
Were
we
in
a
position
where
we
can?
We
can
actually
go
through
the
adoption
process,
Olivia
document
in
since
that
time,
since
the
interim
meeting,
obviously
the
working
group
list,
without
the
adoption
call
from
the
22nd
of
June
to
July
6th
that
was
adopted
and
and
then
throughout
the
discussion
in
the
interim,
meaning
there,
the
liveliness
and
neighbor
discovery
poked
its
head,
something
that
we're
going
to
talk
quite
a
bit
about
today.
F
Obviously,
that's
that's
part
of
what
we're
gonna
guess
in
this
good
a
few
minutes.
Another
question
at
the
end
of
the
meeting
was:
if
there
are
any
prototypes,
develop
health
or
LSP
on
our
period
to
the
working
group
this,
and
so
that
continues
to
be
something
that
ought
to
be
born
as
well
yeah.
That
was
your
meeting
one.
B
B
So
just
two
quick
comments,
so
we
took
some
through
those
three
key
action
items.
As
you
can
see
here.
The
adoption
of
the
document
has
now
completely
been
completed.
That
was
done
on
the
list.
As
noted
earlier,
we
were
just
waiting
for
the
cutoff
period
and
to
get
that
updated
and
accepted
in
the
system
and
obviously
action
item.
Two
is
a
part
of
today's
agenda
and
action
item
three
was
deferred.
Currently,
while
we
work
on
the
first
two
actions.
G
G
G
G
B
H
So
the
peering
could
be
sparse
or
dense,
sparse,
meaning
beliefs
in
this
topology
could
only
appeared
with
subsets
of
spines,
dense,
meaning
the
Leafs
could
be
here.
With
all
this
points,
the
peering
would
typically
dictate
the
path
redundancy
that
that
an
operator
would
want
in
the
network,
and
it's
a
directly
proportional
to
that
again
in
such
sparse
bgp
peering
or
a
dense,
bgp
peering.
The
liveness
detection
would
be
done
outside
bgp
slowly
through
BFD,
which
is
defined
for
that
purpose.
H
Right,
the
spines
could
act
as
her
out
reflectors
or
it
could
simply
do
a
bgp
peering
right
and,
as
I
said,
the
controllers
could
coexist
on
the
spines
if
needed,
or
it
could
be
off
out-of-band
if
needed.
Also
well,
here
is
the
topology
that
talks
about
exactly
what
we
I
just
said.
You
could
have
controllers
either
in
band
or
out
of
band
in
sparse
topology
notice.
How
the
leaves
are
not
in
this
example,
connected
to
all
the
spines
but
subset
of
spines.
H
So,
typically
in
such
networks,
it's
quite
possible
that
every
layer
would
have
a
southbound
connection
which
it
passively
listens
on
and
establishes
connections
by
default
and
on
the
northbound
it
has
an
ability
to
choose
what
the
fan-out
looks
like
again,
like
I
said
that
fan-out
is
directly
proportional
to
the
path
diversity
that
an
operator
would
The.
Voice
want
out
of
the
cloth
cloth.
Cloth
networks.
H
H
H
H
From
a
security
standpoint,
the
extensions
defined
are
built
on
top
of
BGP,
so
the
applicability
draft
makes
it
clear
that
all
the
security,
almost
all
of
the
security
extensions
defined
in
BGP,
would
be
applicable
here,
which
means
more
specifically
the
TTL
base
security.
That's
defined
would
be
directly
applicable
here
or
any
session
level
security
that's
been
defined,
whether
it's
AO
or
md5
would
be
applicable.
Here
there
is
an
RFC
now
that
supports
key
rollovers
using
yang
base
model,
which
is
81
77
that
would
be
applicable
here.
H
H
So
those
were
the
version
1
changes
in
version
2.
We
added
a
section
that
talks
about
peer
discovery
requirements.
Specifically,
we
laid
out
high-level
discovery
parameters
that
would
be
needed
for
any
kind
of
peer
discovery
that
you
would
do,
and
we
made
sure
that,
while
the
discovery
specifically
targets
the
data
center
networks,
it
doesn't
limit
the
solution
to
such
networks,
because
there
is
a
there
could
be
a
potential
applicability
at
PC
boundaries
on
l3
VPNs,
also
an
deviance
if
they
use
BGP
from
the
discovery
mechanisms.
There
are
few
solutions
that
are
out
there.
H
There
is
a
solution
based
on
lldp,
which
tries
to
make
the
discovery
more
generic
in
a
manner
that
BGP
would
be
one
of
the
discovery,
protocol
or
or
the
discovery.
Information
that
is
passed
in
lldp
would
be
specific
to
BGP,
as
well
as
it
is
made
in
a
way
that
it
could
be
extensible
for
other
protocols.
There
is
also
a
BGP
peer
discovery
draft
which
aims
to
augment
BGP
to
do
discovery
itself.
H
And
finally,
there
is
a
new
proposal
that
Rand
is
going
to
talk
about
today,
which
is
link
state
over
ethernet
again,
a
generic
discovery
based
mechanism
kind
of
like
how
we
did
bfb
for
all
the
routing
protocols.
So
you
want
to
think
of
LS
OE
very
similar
to
what
BFD
does
for
the
heartbeat.
The
applicability
draft
talks
about
at
least
speaking
one
of
the
solutions,
because
we
would
need
this
for
the
data
center
networks,
whether
the
works
done
over
here
or
an
idea,
is
up
for
the
debate,
but
at
least
the
applicability
shock
covers
it.
H
So
at
this
point
the
draft
is
in
a
pretty
well
shape.
What
we
need,
as
a
working
group
is
to
discuss.
Do
we
need
to
include
any
kind
of
routing
policies,
aggregation
policies?
If
any
of
this
needs
to
be
included,
then
what
sort
of
policies
and
what
kind
of
station
should
be?
Should
we
be
having
do
we
need
to
partition
and
talk
about
any
SPF
domains
in
such
so
that
we
could
scale
the
solution
as
the
DC
networks
grow?
H
I
H
J
J
J
J
My
comment
was
my
comment:
was
on
the
other
one,
so,
while
he's
coming,
let
me
just
tell
us
that,
yes,
be
really
good.
Being
is
I've
got
all
this
policy
stuff
floating
in
from
into
the
IDR
working
group
floating
in
from
spring
to
see
what
it's
coming
in
from
LSR?
If
you
want
to
do
policy,
if
you
don't
that
actually
gives
some
real
viewpoint,
it
just
would
help
us
balance.
You
know
the
segment
routing
people
have
have
these
wild
and
crazy
ideas
about
policy
that
they
think
is
really
important.
H
So
you
know
this
working
group
is
all
about
being
very
seen.
As
you
know,
and
one
one
way
we
could
take
cover
this
is
we
could
say
that
you
know,
in
specifically
in
the
applicability
draft
is
that
any
policies
that
are
defined
inside
bgp
as
an
idea
or
sr
as
a
spring
working
group
would
be
applicable
here
and
we
could
cover
them
and
wider
umbrella.
J
Okay,
that's
one
way
to
do
it
more.
Meat
on
the
bones
is
always
good
yeah
in
in
trying
to
look
at
the
requirements
and
then
look
at
the
resulting
spec
I
find
that
Goss
or
Amano
of
you
coming
out
of
spring.
That's
good.
They
have
a
projected
goal
and
desire,
and
by
weld
and
crazy,
I
just
meant
lots
of
functionality.
Sure
if
you
have
a
different
desire,
it
helps
that
helps
us
as
we
review
these
things.
J
B
K
So
I
am
a
seal.
Indem,
not
capital,
accept
no
substitutes,
so
I'm
going
to
talk
about
the
we
switched
it
up.
I,
don't
know
if
you've
noticed
where
I'ma
talk
about
the
base
protocol,
modifications
which
Kerry
talked
about
before
and
he
talked
about
the
applicability
to
try
and
get
fresh
perspective
on
this
Thanks.
K
So
the
draft
was
updated
and
may
we
haven't
had
any
updates
since
then
we
have
some,
probably
there
are
pending
and
what
I
the
perspective
I
looked
at.
It
is
what
more
is
needed
in
the
draft
to
make
it
complete
for
the
original
base.
Spec
I
don't
want
to.
We
don't
want
to
go
forward
with
things
like
trying
to
add
segment
routing
and
talk
how
you
do
that
in
bgp
SPF,
because
really
it's
gonna
mirror
a
lot
of
the
work.
That's
been
done
in
IDPs,
but
this
is
the
main
focus
now.
K
So
one
thing
I
noticed
when
I
talk
to
some
people
that
are
bgp
people
about
SPF.
They
have
a
idea
about
it,
but
they
don't
really
know
exactly
when
an
SPF
is
and
so
I
thought
I'm
wondering
if
I
shouldn't
put
a
non
normative
section
like
in
appendix
that
shows
the
talks
about
how
you
might
want
to
do
this.
I'm
just
gonna
go
this
quickly
and
it's
good
it's
good
to
go
through
this.
K
In
the
context
of
thinking
about
how
you
do
this,
so
the
first
thing
you
do
is
you
have
you
have
a
local
rib,
not
the
beer,
a
local
rip
and
you
mark
routes
corresponding
to
the
SPF
status
scale.
Then
you
start
with
your
own
router
node
a
lie.
I
hope
everybody
in
here
is
familiar
with
BGP
ALS,
RFC,
77
52.
You
start
with
that
at
the
route
and
you'd
add
your
local
resources.
K
The
local
Reb,
which
is
mainly
just
marking,
will
be,
will
be
C,
marking
the
scale
as
active
routes
of
the
metric,
and
you
optionally,
I,
say
optionally,
because
the
most
clone
networks
you
don't
really
want.
The
prefixes
are
all
the
links
install
those
as
well
now,
but
you
do
for
the
links,
though,
as
you
add
it
so
me
this
is
a
real,
simple,
SPF
right
now
compared
to
all
the
variations
we
have
in
the
iGPS,
because
it's
only
point-to-point
connections
between
peers.
K
K
Have
you
could
use
those
as
well
now
like
the
eye
GPS,
and
this
helps
this
helps,
make
sure
you
don't
stall
routes
that
are
invalid
or
even
in
you
know,
II
that
you
you
require
the
bi-directional
check,
in
other
words,
you'd
only
put
a
note
on
the
candidate
list
if
and
only
if
that
node
also
advertises
a
link
back
to
back
to
the
know
you're
looking
at
so
this
is
don't
worry.
This
isn't
gonna.
Last
too
long,
I'm
just
gonna
go
through
at
high
level.
Then
you
move
you
remove
from
the
candidate
list.
K
The
lowest-cost
node
you
process,
local
prefixes
on
that
node
install
those
into
the
local
river
mark.
The
routes
that
were
previously
scale
is
active
and
you're,
maintaining
ecmp
as
you
go,
and
again
optionally,
install
routes
relating
to
rate
links
for
the
node,
N
or
Ally.
You
just
took
off
the
candidate
list
and
you.
K
Uuuugh
update
those
routes
as
well
in
the
spec
I
think
I
have
some
redundancy
there
probably
take
that
out.
Then
you
then,
for
that
node
you
do
what
you
just
did
for
the
root
node
for
that
node.
You
take
look
at
the
links
and
you
add
those
nodes
to
the
candidate
list
again
using
in
the
order
of
the
lowest
cost
metric.
Now
a
lot
of
people
use
a
tree
for
this
sorted
by
the
metric.
K
A
lot
of
people
use
a
heap
or
the
heap
has
a
property
of
being
a
little
bit
less
overhead,
but
you
still
have
the
lowest
cost.
You
can
have
the
lowest
or
highest
for
it,
and
now
you
do
the
heap
on
top,
and
then
you
go
again
with
that.
You
process
the
links
and
you
honor
the
bi-directional
connectivity
check
for
the
nodes
that
are
more
one
hop.
K
It
hop
away
just
the
same
as
you
did
for
yourself
for
the
root
node
and
you
add
the
nodes
from
that
node
that
are
connected
links
and
that
note
to
the
candidate
list
again
in
the
order
of
the
lowest
cost
metric,
and
then
you
repeat,
cernan
at
the
top.
Now,
when
you're
all
done,
this
is
like
a
signal.
This
is
like
a
very
single
single
area,
very
simple
single
area
SPF
and
is
isro
SPF.
K
Then
you
look
at
your
local
rib
and
you
determine
the
changes
because,
of
course
you
don't
want
to
hit
the
ribs
and
fills
with
anything,
that's
unnecessary,
so
you
delete,
add
or
update
routes
based
on
that
computation
I
was
thinking,
maybe
just
as
a
reference.
I
could
put
something
like
this
in
the
in
an
appendix
you
had
a
mistake,
a
bug,
no.
D
K
L
D
So,
yes,
putting
it
putting
something
in
there
is
important.
I
was
just
looking
at
the
IRC
at
the
draft.
Really
quick,
and
it
says
something
like
this
draft
defines
the
SPF
algorithm
similar
to
all
SPF,
so
yeah
I
mean
it
doesn't.
Actually
you
find
that
in
the
first
place
and
second
similar
can
be
interpreted
in
many
different
ways
exactly
and
it
is
different
because
you
have
a
different.
K
D
K
I
K
Okay,
oh
here,
one
one
thing
that
caused
a
lot
of
confusion
was
the
base
SPF
versus
the
strict
SPF.
Now
we're
reusing
an
eye
GP
registry
for
I
Anna
and
in
this
context,
at
least
for
the
initial
version
of
this
the
strict,
even
though
we're
reusing
that
that
registry,
the
strict
that
SPF
isn't
really
applicable
because
right
now,
strictest
SPF
is
only
applied
to
SR
routing
computation
in
documents
that
are
close
to
standardization.
So
we
want,
since
we're
defining
these
t
LEDs.
K
K
Okay,
kay
I
talked
about
this
a
little
bit
in
the
applicability
document,
I
thought
about
how
what
you
would
do
with
policies
now
right
now,
a
lot
we
thought
do
we
need
area
areas,
of
course,
the
since
it's
bgp
LS
for
link
state.
Of
course
the
77
52
in
codings
already
have
area
IDs,
and
you
could
just
reuse
that
but
I'm
we're
thinking
right
now.
Our
current
thinking
is,
we
don't
need
areas,
we're
not
going
to
put
in
the
areas
in
the
first
step,
we're
just
gonna
leave
it.
K
It
could
easily
be
added
later
if
you
needed,
and
you
just
take
what
you
have
and
say.
That's
a
you
know:
that's
area
zero
or
you
have
to
redefine
it,
but
one
thing
we're
not
precluding
is
that
if
some
one
of
the
nice
things
about
EGP
as
opposed
to
is,
is
and
OSPF
is
that
if
somebody
is
so
inclined-
and
they
know
what
they're
doing
you
know
it's
Ropin
and
chair,
you
can
define
policy
at
any
level
and
we
think
people
should
I
thought.
K
If,
if
somebody
was
willing
to
go
through
the
thinking
about
it,
you
know
thinking
about
it
and
the
configuration
they
could
define
in
area
boundary
any
place
they
wanted
and
or
a
quasi
area
boundary
any
place
they
wanted
and
do
the
policy
themselves
and
again
I
just
have
a
warning.
You
know,
since
it's
not
automatic,
it
could
break
things.
Of
course
you
can
break
things
with
OSPF
by
misconfigure
ain't
areas
as
well,
SPF
domains
think
this
is
something
I'm
saying
we
do
have.
K
This
is
a
big
question,
because
what
a
domain
would
be
is,
if
you
have
two
separates
complete
like
I
would
say,
this
would
be
more
analogous
to
some
people
that
have
been
so
compelled
that
they
needed
to
use
multiple
instances
of
OSPF
or
is
is
in
the
same
birth
and
they're
in
the
same,
and
what
you
would
do
here
is
you
could
have
an
instance
identity
and
somebody
on
the
boundary
could
such
as
an
ASPR,
could
use
these
new
and
and
and
provide
policies
to
redistribute
between
them.
Now.
Do
we
need
this.
H
So
speaking
as
a
quarter,
I
I
think
it's
it's
really
cool
to
cover
this,
because
then
you
could
break
a
given
DC
into
a
bunch
of
pods
and
you
can
assign
domains
per
pods
and
do
a
much
more
restrictive
route
distribution
across
the
pods
if
needed.
So
it
gives
you
a
right.
You
know
good
control,
aside
from
aside
from
the
scale,
if
you
will,
this
is.
M
Jeff
has
a
significant
motivator
for
HP
Ellis
period
was
the
fact
that
doing
things
that
span
IGP
domains
was
painful
and
they
provided
the
way
they
actually
gather
thing.
It's
one
spot.
There
is
a
little
bit
more
speculative
work
about
actually
taking
multiple,
separate
domains.
No,
that
are
completely
I,
think
just
areas
or
levels
just
simply
cooling,
together
more
than
one
with
taking
the
different
views
and
applying
blue
in
the
middle
through
you
know,
MPLS,
or
something
like
that.
So,
rather
than
take
this
as
a
should,
we
think
about
doing
this.
K
Think
that's
good,
because
once
you
specify
something
precisely
and
have
people
disagree
with
it,
you're
going
to
shake
out
a
lot
of
things
too.
Rather
than
leaving
this
to
say.
Well,
we
have
policy
and
BGP.
You
can
do
this
any
way,
but
yeah
I
think
I.
Think
we'll
have
something
explicit
for
domains
in
the
next
revision.
It.
C
May
be
one
thing
to
add
about
domains
itself.
Is
that
you
know,
if
you
look
in
the
shorter
you
know
we
don't
really
short
to
actually,
you
know,
I
have
the
word
document
for
multiple
domains,
which
doesn't
mean
you
know
that
we
should
know.
I,
think
the
solution
we
develop
should
not
exclude
the
potential
for
domains,
but
the
actual
you
know
the
embodiment
of
that
is
maybe
a
little
bit
too
far.
You
know
from
what
we
actually
you
know
are
shorted
to
do
at
this
point
in
time.
Okay,.
D
Cell
rule
yeah,
the
turner
actually
says
a
single
distribution
domain
and
I
think
what
we
meant
by
that
was
more
the
concept
of
a
flooding
domain
or
an
area,
and
it
the
Turner
also
says
that
I
can't
see
the
term
here,
but
it
says
that
a
single
the
solution
domain
is
defined.
As
this
and
an
initial
to
me
now
we
can
bend
this
any
way.
We
want
right
claiming
that
you
can
divide
your
data
center
into
multiple
initials
of
the
mains,
and
so
you
end
up
with
this
right.
D
One
thing
that
I've
told
the
chairs
several
times
and
and
other
people
is
I,
really
want
the
working
group
to
focus
and
not
to
add
stuff
in
that
stuff
and
that
stuff,
just
because
it's
cool
to
do
it.
But
you
know,
as
Jeff
said
you
know,
there
are
some
things
that
maybe
we
want
to
consider
from
the
beginning.
So
don't
let
the
Charter
your
stand.
The
way
of
putting
in
identifier
for
domain,
for
example,
okay,
maybe
not
go
crazy
with
areas
and
everything
else.
D
K
The
decision
process
I
the
the
one
of
the
one
of
the
you
know,
they're
really
two
things
that
we
changed
significantly
and
BGP.
One
was
the
computation
of
routes,
how
it's
done
where
as
distance
vector
versus
SPF
and
the
other
one
was
the
determining
the
best
path
and
I
have
this
in
there.
So
a
BGP
OSPF,
because
the
node
ID
is
part
of
the
NRI
key.
K
It's
inherently
originated
by
a
single
router
in
BGP,
ALS,
SPF
domain
and
the
rules
are
you
always
prefer,
enter
Ally
from
your
from
the
originator
of
it,
even
irrespective
of
anything
else?
So
if
the
BGP
ID
and
is
one
of
the
node
identifiers
for
then
RI
you're,
getting
it
from
that
guy
you're
gonna
prefer
that
this
is
to
handle
the
case
where
you
have
a
cold
start
and
there's
still
stay
out
now.
K
Otherwise,
we're
using
I
don't
know
how
many
of
you
are
familiar
with
a
VPN
in
the
Mac
mobility.
There's
a
sequence
number
we're
using
a
similar
concept
where
the
originator
will
put
a
sequence
number
on
it
and
you're
always
going
to
prefer
the
most
recent
or
the
one
of
the
highest
sequence
number
we're
using
a
64-bit
sequence.
Number
that
way
that
was
similar
to
we
did
for
the
it's
not
called
a
sequence
number.
K
What
do
we
call
that
an
authentication
when
you
have
a
counter
to
make
sure
that
for
replay
attacks,
okay,
yeah,
yeah
yeah,
so
we're
we're
using
we're
using
64
rather
than
32-bit,
and
we're
using
a
similar
wrapping
strategy
for
if
a
router
restarts
the
high
or
32-bit
updates
and
four
billion
for
a
you
know.
It'll
handle
both
cases
anyway,
and
we
don't
think
we
need
any
further
or
criteria.
Now.
Here's
where
we
get
into
something
the
normal.
K
The
difference
between
BGP
and
I
GPS
is
a
GPS
for
things
that
are
withdrawn.
The
IGP
has
an
advantage
because
it's
withdrawn
there's
only
a
GPIO
me
keeps
one
copy
of
it,
whereas
we'll
keep
a
copy
from
everybody.
So
one,
unless
you
do
something
one
consequence
of
this,
is
you
won't
converge
on
the
deletions
as
fast?
Unless
we
do
something
else,
so
do
we
wanna
modify
it
or
just
do
the
normal
bgp
and
wait
till
all
instances?
M
Doing
this
type
of
procedure,
where
we
have
basically
identical
and
Ori
we're
just
keeping
track
of
where
they're
at
can
be
done
internally,
it's
a
special
optimization
for
things
that
you
might
actually
know
have
this
property.
This
is
not
normal
for
bgp,
normal,
normally
bgp
once
to
keep
any
copies
of
things,
and
there
are
relatively
few
circumstances
and
normal
bgp
routing,
where
you
would
actually
do
this
sort
of
thing.
So
whether
you
choose
to
say
that
no,
this
might
be
a
possible
optimization
or
not.
M
I
would
not
recommend
changing
the
PGP
procedures,
but
making
note
that
this
property
should
exist
is
worth
doing
where
I
think
you
may
run
into
trouble
is
thus
far
you
haven't
gotten
into
decoration.
Yet
you
know
at
what
point
may
nodes
start
doing
things
like
adding
communities,
adding
an
additional
path,
attributes
right.
K
H
Protocol
I
agree
with
Jeff
that
we
probably
should
keep
it
out,
but
have
implementations
specific
extensions
that
they
could
do
to
figure
out
where
the
failure
is
and
how
do
you
add
up
to
it
and
how
do
you
sort
of
take
one
update
that
you
receive
and
extrapolate
information
and
sort
of
correlated
to
the
other
updates
and
do
whatever
is
needed?
Those
are
implementation,
specific
details.
We
could
leave
it
out.
K
C
So
something
what
we're
you
know
planning
to
do
is
to
create,
like
another
interim
Ian,
you
know
in
about
a
month
and
a
half
two
months
from
now
mainly
to
drag
the
documents
further.
Now
what
I
will
also
know
request
on
the
working
group?
Email
alias
actually
is
for
the
volunteers
to
actually
review
the
documents.
Because
now,
even
though
we
believe
you
know
that
the
current
stake
is,
you
know
reasonable,
it
can
always,
you
know,
be
improved
in
such
a
way
that
you
know
we
can
actually
add
things.
You
move
things.
C
I
C
So,
let's
have
a
quick
look
at
the
correct
agenda
now
now
that
I've
uploaded
this
thing,
so
we
have
like
a
couple
of
topics
you
know
remaining
here,
and
so
we
are
at
this
point
in
time.
We
are
at
the
you
know,
we're
gonna
start
discussion
or
like
a
not
sharing
of
some
ideas
about
like
neighbor
life
in
these
requirements,
because
you
know
distributing
gives
links
date
vectors.
You
know
we
need
to
create
them
in
some
sort
of
a
way
and
automatically
so
so.
C
So,
while
we
actually,
we
have,
like
you,
know
majority
of
our
milestone
documents,
you
know
covered
one
of
them.
You
know
has
seen
at
this
point
in
time.
Like
you
know,
it's
very
dormant,
it
was
mentioned.
You
know
a
little.
You
know
couple
of
minutes
ago.
So
we
actually
have
like,
in
our
shorter,
also
some
young
model
specifications.
Maybe
it
is
still
too
early
I'm
trying
to
understand.
You
know
how
you
know
how
to
deal
with
that.
You
know
going
forward.
Do
we
actually
know
think
they
should
be
in
the
applicability
document?
C
B
And
just
from
the
jabber
list,
there's
a
yes
agree
so
on
that
last
comment,
all
right.
So
unless
there's
any
more
questions
on
that
part
of
the
agenda,
we're
moving
into
another
part
of
the
agenda,
that
was
one
of
the
outcomes
of
some
discovery
in
work.
We
did
during
the
last
inter
meeting,
which
was
so
at
least
understand
what
we
would
require
from
our
from
the
specs
perspective
as
to
what
we
would
need
for
liveness
and
neighbor
discovery,
and/or
detection.
So
the
the
thought
pattern
there
was
to
work
on.
What
do
we
require?
B
E
E
If
somebody
has
other
ideas,
okay,
so
I'm
going
to
be
a
little
religious
for
a
moment,
if
you'll
excuse
me
and
I
greatly
would
appreciate
any
attribution,
I,
don't
remember:
I
can't
find
the
quote,
but
it's
either
Tony
Hoare
in
his
eternal
speech
or
Klaus
ferret,
but
there
are
two
kinds
of
standards:
Union
standards,
which
is
all
the
features
everybody
ever
wanted,
which
I
think
we
need
to
be
very
careful
of
in
this
group
and
the
intersection
standards.
Only
those
things
everybody
absolutely
had
to
have:
okay,
I'm,
a
fan
of
the
latter.
E
The
good
example
was
in
dealing
with
the
ITU
ruffhouse
Lee
said.
So
let
me
get
this
right.
You
just
keep
adding
features
until
the
nose
stop
and
they
blushed
and
said.
Well,
we
don't
like
to
think
of
it
that
way
right.
So
what
must
we
have?
Okay,
we
need
to
discover
the
nodes
and
the
links
so
that
s,
BGP
SPF,
can
figure
the
topology
all
the
brains
and
the
routing
and
the
topology
are
upstairs.
E
E
I
I
E
I
E
H
Capital
R
cos
they
think.
From
my
perspective,
what
would
be
nice
is
if
we
see
requirements
out
here
that
actually
can
address
else.
We
are
require
needs,
but
more
specifically
be
done
in
a
manner
that
is
very
generic,
so
can
be
extended
in
feature
again
a
good
example
when
I
say
this,
we
should
think
about
is
PFD.
How
BFD
has
an
applicability
to
bgp
and
is
is
something
similar
out
here?
If
we
could
do
that,
that
would
be
fantastic,
yeah
yeah.
E
J
E
J
M
J
It
but
the
context
in
which
you're
talking
about
this
is
for
the
is
for
BGP
LSR
and
you're
asking
for
must-haves,
and
if
it's
in
that
context-
and
you
require
TCP
for
this
protocol
to
work
for
this
protocol,
the
must-haves
must
include
I,
believe
Transport.
Well,
yes,
and
no
that
that's
the
discussion.
I
wanted
to
get
hey.
E
J
Bfd,
on
top
once
you've
got
that
may
ask
how
this
makes
sense.
Just
just
so.
If
you
have
these
two
liveness
protocols,
when
you're
working
for
fast
convergence
and
I
assume
the
reason
you're
going
for
an
SPF
inside
of
all
this
is
you
do
have
some
concern
for
best
convergence,
that
if
you
put
two
protocols
together,
you're
likely
to
be
less
fast
than
if
you
have
one
as
far
as
saying
hellos,.
H
H
Anything
that
calls
aliveness
in
here
is
specifically
in
context
of
bgp
or
or
routing
protocols
is
bft
where
we
won't
define
any,
or
at
least
I,
don't
see
a
need
to
define
any
other
protocol
extension
to
cover
the
liveness
aspect.
What
is
needed
here
is
a
discovery
which
is
what
I
I
believe.
What
I
heard
Randy
was
alluding
to
and
the
specific
requirements
for
discovery
should
the
protocol
we
designed
over
UDP
or
TCP.
Then
you
need
some
kind
of
a
reliability
in
here.
Otherwise
you
don't.
P
Bruno
Reisman
I
have
two
comments:
I'll
just
give
them
both
and
let
you
respond
to
them.
One
big
decision
point
is
whether
we
should
support
multi-point
lands
or
only
point-to-point
interfaces
that
will
make
a
big
difference
and
we
could
get
away
with
just
point-to-point
in
a
data
center
if
we
want
to
minimize
requirements-
and
the
second
comment
is
that
you
mentioned
the
must-haves
of
discovering
addresses
on
the
remote
side.
P
K
Ac
Linda
I,
just
like
to
I,
think
the
maintain
liveness.
You
know
a
lot
of
people
saw
that
a
different
way
and
I
want
to
say
that
I
agree
with
what
randy
said
that
we
shouldn't
try
and
maintain
the
session
once
we
bootstrap
the
encapsulation
being
there.
We
should
just
use
BFD
I
mean
there's
so
much
interaction
and
machinery
for
BFT
implementation.
So
you
you
don't
want
to
do
that
again
with
any
other
protocol.
My.
E
Inclination
I
think
it's
based
kind
of
on
what
Kerr
said
is
that
my
responsibility
at
this
level
is
to
tell
SPF
your
topology
has
changed.
An
encapsulation
may
have
gone
missing
or
come
up
or
may
other
topology
affecting
things
have
happened,
not
how
reliable
it
is.
It's
alive.
Not
it
doesn't
have
a
fever
and
isn't
peeking
sorry.
Q
E
Q
J
Is
your
requirement
to
have
two
stat
protocols
so
that
you
can
find
out
what
the
encapsulation
and
then
put
tcp
on
top,
or
are
you
trying
to
bring
up
the
liveness
in
the
quickest
way
possible?
I
would
have
thought
you
would
have
tried
to
bring
up
the
liveness
and
the
quickest
way
possible.
That's
why
I'm
confused
how
two
protocols
can
interact
as
quick
as
one.
R
E
I
will
pretend
to
think
about
that
for
a
while,
but
I
won't
bore
you
all.
I'm
thinking
is
securing
requirements
to
my
great
horror.
Data
center
operators
seem
not
to
think
of
security
at
this
lair.
They
have
wells
around
this
thing
everything
safe.
Nobody
comes
in
with
laptops
and
USB
sticks.
Just
ask
the
Iranian
bomb
workers.
Do
we
want
to
add
authentication,
and
maybe
integrity
are
those
uncle
requirements?
E
Okay
watch
out.
This
is
one
of
those
things
which
is
likely
to
drive
the
size
over
fifteen
hundred
and
fifteen
hundreds
of
magic
thing.
Ldp
hits
IPR
at
1500,
okay,
so
one
of
my
hats,
I'm
a
security
person,
but
I
don't
want
to
shove
that
down
this
group's
throats.
So
far,
security
has
not
been
an
issue
here.
E
E
K
He's
healing
there's
an
interesting
point
here
that
I
had
in
the
lldp
draft,
but
I
took
it
out
and
I
noticed
now
we
have
a
fourth
option:
Robert
invented
one
over
the
weekend
and
the
one
of
the
things
that
allowed
for
was.
You
could
learn
a
loop
back
and
have
that
layer
install
a
connected
route
to
the
loopback,
so
you
could
pair
on
loop
backs
directly
with
all
coins
or
anything
else
now
is
this.
Would
we
want
this
a
not
when
we
want
to
disqualify
this
right
here
and
now.
K
E
K
H
Patel
arcus,
I
I
think
that's
an
implementation.
If
you
ask
me
I
think
that's
an
implementation,
specific
detail,
if
I,
if,
if
on
an
interface
that
you
you
run
if
on
an
interface
say
you
get
a
packet
where
you
have
a
BGP
peering
address,
which
is
different
from
the
interface
address,
but
a
discovery
is
telling
you
to
peer
over
that
address.
I
think
you
could
add
a
text
that
says
that
this
address
that
you've
received
over
this
interface
while
it
doesn't
belong
to
that
subnet
will
recur
over
this
interface.
H
R
R
You
know
you're
trying
for
minimal
here,
but
it
would
be
awfully
good
to
have
a
way
to
bootstrap
those
loop
backs
because
we're
building
an
I
GP
out
of
bgp
here
and
otherwise
you
get
this
horrible
stack
of
layering
violations,
so
I
kind
of
like
adding
that
into
the
requirements.
Leaving
aside
the
question
of
what
the
solution
is,
I
will
put
that
explicitly.
E
E
So
let
me
just
jump
up
and
down
on
simple
one
more
time:
I
presume
everybody
can
read,
so
I
won't
read
it
to
you,
but
you
know
we
are
not
telcos.
We
don't
demonstrate
macho
by
seeing
how
complex
things
we
can
make
things
to
provide
barriers.
We're
trying
to
make
it
simple.
So
it
works,
is
understandable
and
is
securable.
E
Okay
and
Rob.
Pike
said
this
just
two
weeks
ago,
I
so
I
had
to
stick
it
on
there.
Okay,
and
for
those
who
don't
know
who
Rob
bike
is
you
can
skip
it?
Okay,
who
are
the
candidates
that
we
have
so
far
I'm
sorry
Robert
came
out
too
late
for
this
one.
So
lldp
is,
is
link.
Discovery,
Alvaro,
loves
to
find
brick,
says,
he's
walking
down
the
road
and
throw
them
over
the
fence,
so
he
threw
edge
control
protocol
at
me.
I
am
still
digesting
it.
E
Alvaro
BGP,
neighbor,
Auto
discovery,
which
will
I
believe,
is
the
next
song,
so
you'll
get
that
one
and
the
song
after
that
is
link,
stayed
over
ether,
okay
and
some
comments
on
each
one.
Ll
DPS
and
I
Triple
E
protocol
watch
out
it
has
IP.
Are
over
1500
bytes,
okay,
and
we
don't
care
about
that
for
the
simple
stuff.
But
if
we
start
trying
to
put
security
associations
and
other
things,
this
could
become
an
issue.
It
won't
go
through
a
switch.
Is
that
a
feature
or
a
bug?
E
T
E
E
E
E
E
D
The
boy
blame
I
really
gonna
have
that
paul
is
here
because
when
we
talked
about
or
when
you
when
we
started
talking
about
the
IPR
in
LDP,
what
I
did
is
I
reached
out
for
the
actually
had
asked
and
one
of
the
answers
that
came
back
was
we
don't
know,
but
in
case
we
probably
don't
want
to
extend
it'll
DP
beyond
15
everybody
even
knew
we
could
and
so
paul
actually
threw
the
brick
at
me.
I
just
laid
the
brick
to
you
and
said
how
about
easy
p.
E
K
T
Yeah
I
think
your
assertions
here
are
relatively
correct.
It.
It
is
transport
it
was
intended
to
carry
more
than
one
in
MPU
or
PDUs
worth
of
data.
You
know
in
a
reliable
fashion
and
primarily
invented
for
the
EVP
for
the
Edge
virtual
bridging
protocol.
There's
been
there's
some
recent
proposal
to
use
this
for
some
new
802
discovery
are
not
discovery,
but
state
exchange
protocols
that
that
require
large
data
transfers.
T
E
Okay,
there's
the
BGP
neighbor
on
a
discovery
draft.
It
is
an
ITF
protocol.
It's
very
new.
It
kind
of
confuses
me
as
to
whether
it
actually
does
discovery
or
not.
It
seems
more
its
configuration
okay,
it's
a
s
base
does
not
use
other
identifiers
and
it's
not
really
it's
more
configuration
than
discovery
and
it
doesn't
do
liveness,
okay,
Roberts
new
thing,
I'm.
Sorry,
it's
not
here!
My
quick
take
on
it
is
that
it's
discovery
at
a
top
level,
not
liveness,
and
a
s
based
link
state
over
ether
was
custom
designed
for
this
particular
job.
E
But
conflict
notice
I'm
a
co-author
in
this,
and
it's
very
bare-bones,
brutally
simple.
This
discovery
and
aliveness
it's
new.
It's
so
is
EGP
SBF.
The
bottom
statement
is
true
of
too
many
of
the
items
on
this
laundry
list
that
I
presented,
which
is
measurement
and
monitoring,
is
very
among
these
and
as
an
operator.
J
J
E
B
C
Okay,
yeah,
so
so
from
what
I
understand
is
that
you
know
most
of
the
the
aspects.
I'm,
sorry
I,
think
from
what
I
understand
is
you
know
there
is
like
no,
you
know
violent
disagreement
on
what
were
any
actually
no
mentioned
here.
I
think
one
of
the
key
topics
we
probably
know
which
needs
to
be
you
know
further.
Consider
is
the
timeliness
aspect
which
one's
mentioned
I.
Think
for
the
rest,
you
know
from
a
place
from
my
perspective,
you
know
majority
was
we
were
like
an
agreement
on
on
this
set
of
requirements.
R
I
said
you
know,
there's
there's
no
proposal
on
the
table
right
now.
Regarding
security,
you
just
said
here:
it
is
it's
not
addressed
pretty
much
and
I,
or
is
there
a
sort
of
I
guess
you
actually
had
a
straw
man
on
the
table,
which
said
security
is
not
a
requirement
beyond
you
know
these.
You
know
four
strong
walls
built
out
of
cinder
blocks,
which,
which
is
the
correct
summary
I
guess
of
I.
E
M
M
The
mode
that
BFD
gets
run
in
can
impact
whether
it's
really
suitable
or
not.
The
specific
example
is
standard
point-to-point
BFD.
You
know,
stock
58
80
expects
to
have
a
single
session
between
two
IP
endpoints
and
typically,
an
implementation
will
try
to
get
the
most
aggressive
timers
it
can
and
if
you're,
having
two
applications
wanting
to
use
BFD
for
the
same
set
of
addresses
and
normally
that's
what
you
want
to
do,
because
you
want
the
faster
thing
to
fail
and
take
everything
else
with
it
somewhat.
M
In
contrast,
you'll
think
about
bgp
bgp,
probably
could
live
with
like
say
no
300
millisecond
not
keep
Alive's
happening
is
a
liveness
mechanism.
Maybe
you
know
a
little
bit
shorter
if
you're
looking
at
doing
this,
for
you
know
bgp
SPF
purposes,
but
if
you
end
up
tying
no
single
session,
that's
doing
liveness
and
also
link
liveness.
Oh
sorry,
your
protocol
and
link
nihilist
together
you'll
have
the
faster
session
negotiated,
it'll,
go
down
and
potentially
take
the
protocol
fate
with
it,
and
you
may
not
intend
that.
U
Rob
Austin
arcus,
in
spite
of
being
known
around
here
more
as
a
security
person
I'm,
actually
not
here,
to
talk
about
that,
although
I
agree
with
Randy
that
it's
nuts,
not
as
something
but
to
Sue's
comment
about
one
protocol
versus
two
for
faster
convergence
and
all
that
I,
don't
think
of
it.
Quite
that
way,
it's
been
a
long
time
since
anybody
was
dumb
enough
to
let
me
actually
write
routing
code,
but
my
recollection
is
that
the
hello
phase
in
OSPF
is
basically
a
whole
separate.
U
Sub
protocol
is
just
tightly
integrated
with
the
rest
of
OSPF
and,
as
you
think,
what
we're
talking
about
here
is
essentially
equivalent
to
the
hello
phase.
It's
basically
just
a
link
discovery.
So
well,
that's
what
actually
is
a
separate
protocol
or
just
an
add-on
to
the
side
of
bgp
for
this
purpose,
it's
mostly
a
matter
of
semantics,
I.
Think.
J
I'm
sorry,
Randy
I,
didn't
I
will
disagree
with
your
analysis
and
if
you
would
like
to
see
charts
afterwards,
we
can
diagram
how
some
of
this
stuff
works,
but
I
really
think
that
and
it's
personal
opinion
that
you
should.
J
You
know,
see
people
you
should
timeliness.
You
know
how
the
code
works,
how
everything
works,
I,
think
the
timeliness
is
important,
or
at
least
it's
a
question
to
make
a
decision
on
it's
off
the
list.
Just
you
know
you're
asking
if
I
thought
the
list
was
complete,
I'm
asking
that
you
do
a
reasoned
discussion
on
timeliness.
If
you
decide
out
I'm
still
gonna
support
and
work
with
stuff
I
just
think
you
have
to
think
about
it.
D
D
At
some
point,
we
will
want
to
think
very
well
about
how
we
justify
that,
if
authentication
integrity
etc
does
not
baked
into
it
from
the
beginning,
but
it's
an
extensible
option
that
may
be
okay,
but
we
just
want
to
be
able
to
justify
that
so
that
others,
in
the
ASG,
for
example,
will
understand
where
it's
going
to
be
used.
Why
we're
doing
that
this
way?
One
of
the
normal
modes
of
operation
we've
done
other
protocols.
D
For
example,
in
my
name
we
did
a
protocol
called
D
lab,
which
runs
inside
a
tank
inside
a
copper
cable
in
a
point-to-point
wired
network,
and
we
had
a
discussion
with
security
people
about.
Why?
Don't
we
have
interior
encryption
and
everything
else,
and
the
answer
was
well.
You
can
actually
see
this
stuff
in
this
Burke
Hall.
You
all
right
broke
into
the
tank
right.
You
have
bigger
problems
of
that.
So
we've
got
away
with
explaining
what
the
normally
use
is
well
at
the
same
time
saying.
D
But
if
you
don't
use
it
here,
then
here's
the
extensions
to
go.
Do
all
this
other
stuff,
so
I'm
happy
with
I'm,
okay
with
not
putting
too
much
overhead
and
to
a
protocol
like
this.
We
just
need
to
be
able
to
justify
that
so
that
it's
clear
to
everyone
what
the
motivation
is
and
what
the
operational
circumstances
are:
corrupters
yeah.
E
E
S
Before
I
answer
your
question
and
the
previous
speaker,
just
before
you
has
an
interesting
question
in
his
update
status,
which
was
network
operator,
interest,
I
think
we
should
pull
a
little
bit
more.
The
operator
when
you
propose
something
like
you
were
proposing,
so
we
could
be
aligned
a
little
bit
more
from
a
security
perspective.
It's
a
must
for
a
bunch
of
different
reason,
but
I
felt
that
your
your
presentation
was
a
little
bit
like.
S
I
I
D
D
D
No
no
I
agree.
I
agree.
What
I
was
gonna
say
is
that
the
only
we
have
people
here?
There's
I
was
just
looking
at
the
list.
My
email
is
open
right.
There
I
do
see
very
little
traffic
on
the
list,
for
example,
but
you
know
to
your
question:
yeah
we
had
the
boss,
people
said
they
were
interested
in
working
on
things
now.
I
keep
insisting
and
I
said
this
earlier-
that
we
won't
focus
in
the
working
group
to
finish
the
work.
D
One
of
the
conditions
that
I
told
the
chairs
and
I
told
you
and
and
Jeffrey,
was
that
you
know
we're
gonna
charter
this
for
a
year
and
see
what
we
got
out
of
that
year,
based
not
just
new
people
who
show
up
the
people.
You
know
all
this
stuff
so
that
we
can
actually
do
the
work.
In
other
words,
I.
Don't
want
to
be
sitting
here
ten
years
from
now
still
talking
about
whether
we
do
Beach
BSP
or
not.
If
we
arts-
and
here
tea
from.
D
To
be
doing,
I
don't
know
multi-level
whatever
the
heck
it
is.
But
that's
that's
yes
right
we're
here,
because
you
know
the
community
said
we
wanted
to
do
this.
If
we
don't
want
to
do
this
will
soon
lose
interest
and
that's
it.
You
know
this
will
die
or
either
both
efforts
whenever
it.
You
know
whatever
this
so
we'll
see
what
where
that
goes,.
B
So
Victor
coursing,
chair
hat
off
operator
question
was
that
asked
earlier
so
from
a
security
perspective,
my
my
operator,
hat
on
is
is
a
wide
variety
of
how
operators
handle
security,
new
data
centers.
As
far
as
I've
seen
ones,
I've
worked
on
in
different
places.
People
I
know
built
their
things.
I
think
we
should
probably
have
at
least
extensible
and
be
able
to
include
it.
B
How
it's
going
to
be
used
will
likely
differ
between
a
lot
of
operators,
so
a
lot
of
them
have
built
up
walls
because
they
had
to
from
earlier
days
of
how
things
worked
so
I
think
polling.
The
operators
is
probably
a
good
idea
so
that
you
can
at
least
get
a
gauge
of
where
the
various
respondents
would
likely
be,
and
that
might
help
of
ro
when
we
talked
they
fake
things
go
up
to
is
G
and
it
maybe
not
be
included
day
one,
but
it's
something.
B
That's
expensable
so
that
such
that
this
is
the
reasoning
why
you
know
50%
of
operators
who,
hopefully
there's
a
you,
know
a
good
number
of
operators
that
comment:
50
percent,
my
I
dunno,
that's
the
number,
but
you
know
said
we
want
this
or
we
want
that.
So
that's
a
comment
in
that
one
and
then
the
second
comment,
which
was
the
last
again
chair,
had
off
still
off
on
the
on
the
last
point:
I
mean
I,
think
a
lot
of
operators
have
gone
to
a
model
and
they
all
make
different
decisions.
B
So
there's
the
I
can't
even
think
of
two
networks.
I've
worked
on
where
they've
looked
the
same
from
how
I've
constructed
them
and
or
the
folks
I've
worked,
and
how
I
construct
them.
I've
we've
had
network
and
in
some
of
them
like
more
mobile
network,
wireline
networks,
cable,
Co
networks-
you
know.
Sometimes
it
was.
You
know,
I
eyesight
ISS
with
some.
You
know,
VPNs
running
above
it
others
where
we
chose
OSPF.
B
There
were
so
many
reasons
why
we
made
decisions
as
to
what
protocols
be
read:
I
think
the
thing
that
drove
a
lot
of
operators
to
the
world
of
LS,
VR
and
or
rift
or
looking.
This
was
we're
already
looking
for
strong
simplifications
of
what
we're
trying
to
do.
We're
trying
you
know
some
of
them.
Not
everyone's
big
decision
is
how
do
I'm
in
how
do
I
create
a
simplistic
way
of
trying
to
deal
with
large
fabrics.
So
you
know
personal
opinion
is
some
might
choose.
B
You
know
that
you
know
method
like
this
in
so
much
that
allows
them
to
create
a
minimalist
type
of
deployment
right
where
you
don't
want
to
run
multiple,
multiple
protocols,
you
wonder
what
you
want
to
want.
You
want
to
run
one
you
need
to
and
the
other
things
that
come
with
that
are
you
need
to
tool
this
thing
you
need
to
troubleshoot
these
things.
B
You
need
to
hire
people
who
can
can
configure
it
who
couldn't
like
said,
build
telemetry
around
understand,
what's
going
on
and
so
I
think
a
lot
of
those
things
rive
that
desire
for
some
simplicity
and
so
I
think
that's
what
drives
us.
So
some
might
very
well
probably
say
you
know
what
a
lot
of
the
changes
in
OSPF
ifs
are
probably
just
fine
for
what
we
do.
B
You
might
have
a
lot
of
others
who
make
different
decisions
just
like
I
think
we
discussed
this
at
the
boss,
which
was
why
do
we
have
ISS
knows
PFF
extensively?
They
almost
do
the
same
thing.
The
answer
is,
there
are
some
subtle
differences,
there's
some
advantage
and
disadvantages
some
of
its
religion
and
all
those
things
go
into
what
people
choose.
V
V
To
clarify
this,
this
work
or
the
this
problem
statement,
came
from
data
centers
that
are
today
already
using
BGP
as
a
hop
by
hop
protocol.
That's
RFC,
79
38,
so
this
is
in
that
sense.
This
is
not
exactly
LS
where,
but
there
is
a
lot
of
applicability
and
you
know
it
can
be
leveraged
and
I'm
here
to
share
this.
This
also
going
to
be
presented
at
idea,
but
sharing
this
further
review.
You
know,
amongst
the
different
options
that
we
have
so
BGP.
V
Can
the
protocol
be
extended
to
make
it
easier
to
do
the
neighbor
discovery
and
the
bootstrapping
or
the
bring
up
of
the
sessions
just
to
make
that
part,
you
know
easier
and
automatic
these
are
this?
Is
the
there
are
already
data
centers
where
this
is
all
set
up
and
it's
you
know
scripted
or
it
is,
you
know,
done
with
different
playbooks,
but
this
is
about
looking
at
solving
this
in
the
protocol
in
a
bit
of
automatic,
dynamic
manner
and.
V
There
are
designs
where
there
are
multiple
ECM
peelings
or
there
are
only
you
know,
unnumbered
or
ipv6
specifically
only
link
local
addresses
that
are
used
on
the
links
and
desire
to
actually
do
the
BGP
pairings.
Even
though
hop-by-hop
using
the
loop
backs
is
very
attractive,
but
we
still
do
want
to
use
the
you
know
underlying
links
for
ecmp.
V
So
this
is
the
goal
it's
specific
to
BGP.
It
is
not
a
general,
you
know,
general
protocol
or
extension
in
that
sense.
I
would
also
like
to
say
that
this
is
not
a
link,
discovery
protocol
or
a
link
discovery
mechanism.
It
is
really
bringing
element
of
neighbor
discovery
in
BGP
on
very
close
lines
of
how
it's
been
done
in
OSPF
is,
is
or
LDP
for
that
matter.
V
V
We
want
to
do
the
signaling
or
exchange
of
peering
address,
and
yes,
number.
It's
really.
We
want
to
take
this
to
a
point
where
this
automated
discovery
takes
us
to
state
where,
as
if
a
neighbor
is
provision
in
bgp,
so
you
just
say
the
pairing
address.
Yes,
and
you
know,
other
policies
are
perhaps
part
of
a
template,
or
something
like
that,
so
it
just
takes
just.
Does
that
part
in
the
BGP
protocol?
V
V
Apart
from
this
part,
there
is
really
no
change
proposed
in
the
BGP
protocol
itself.
It
still,
you
know,
works
the
way
it
does
today.
There
is
really
minimal
changes
in
the
BGP
FSM
and
based
on
feedback
and
comments.
We
have
added
more
text
and
clarity
in
that
document
may
not
be
I
mean,
may
not
really
go
into
all
those
details,
but
just
to
clarify
the
relationship.
V
V
In
that
sense,
this
Hello
discovery
can
be
used
or
either
ipv4
or
ipv6
addresses,
but
in
a
environment
where
we
have
dual
stack
expect
only
one
of
them
to
be
used,
it
is
not
necessary
to
do
it
at
you
know
in
both
the
address
families,
it's
really
the
number
and
identifier
which
identifies
the
bgp
router.
There
is
a
capability
to
Boone
likeness
here,
so
there
is
an
adjacency
hole
and
then
to
make
it
extensible,
and
we
will
see
some
of
them.
We
have
scope
40
alvey's
in
there.
V
So
what
are
the
important
or
critical
tlvs
here?
So
one
is
the
peering
address
TLV
it
can
be
used
to
indicate
one
or
more
ipv4
or
v6.
Peering
addresses
that
you
know
a
local
router
has
or
would
accept.
Bgp
sessions
on
optionally
can
also
indicate
which
efi
surface
are
enabled
for
which
addresses
this
is
to.
You
know,
take
care
of
like,
for
example,
dual
stack
scenarios
or
other.
V
V
At
this
point
it
defines
the
end
point,
and
this
is
important,
because
the
link,
so
we
are
doing
hop
by
hop
it's
a
topology.
There
is
a
desire
and
requirement
to
be
able
to
export
the
actual
link
topology
in
a
BGP
data
center
via
bgp
LS,
and
these
identifiers
allow
us
to
do
that
or
describe
links.
You
know
and
also
describe
the
links
in
a
very
accurate
manner.
V
It
can
be
used
for
doing
some
things
like
subnet
checking
or
other
policy
checking
before
the
actual
setup
is
a
session
setup
is
done
so
before
the
adjacent
is
accepted.
This
can
be
used,
for
you
know,
checking
for
any
miss
configurations
or
miss
wrong
connections.
Things
like
that
at
this
point
that
what
it
is
it
could
be
more
things
could
be
added
based
on
real
operational
feedback
on
what's
really
required.
V
The
idea
is
only
really
to
ensure
that
we
kick
or
start
the
BGP
pure
FSM,
when
we
know
that
both
guys
are
going
to
connect.
When
we
look
at
scale
and
other
things
it
may
not
be.
You
know
a
good
thing
just
to
have
sessions
scale
sessions
just
saying
there.
If
one
side
is
not
going
to
connect,
you
know,
for
any
reason.
V
So
where
are
there
is
will
go
or
more
of
this?
Then
there
are
certain
optional
tlvs
and
further
peering
route
set
up.
You
know
we
discussed
a
lot
amongst
author
and
we
put
right
now
put
a
specific
local,
prefix
TLV,
and
this
is
really
explicit
plv,
which
indicates
to
the
peer
that
you
know
to
reach
me.
My
peering
address
he
programmed
this
router.
So
it's
it's
explicit.
V
V
There
is
an
accepted,
a
s
numbers
list,
and
this
is
again
optional,
but
it
is
a
kind
of
a
like
a
policy
check
or
conflict
profile
check
to
ensure
that
you
know
wrong.
Connections
may
not
be
done
or
something
like
that.
Just
to
it's
more
of
a
policy
thing
there
and
then
based
on
the
feedback,
there
is
a
the
cryptographic
authentication.
Clearly
that's
been
added,
it's
very
similar
to
the
proposal
in
LDP
world
for
doing
security
for
the
UDP
neighbor
discovery
message
system.
V
V
In
that
sense,
there
is
a
one-way
state
when
the
router
has
accepted,
and
you
know
it
would
then
include
the
neighbor
in
its
own
hello,
using
the
neighbor
TLV
or
for
some
reason
we
could
who
we
are
not
accepting
that
neighbor,
it's
you
know
rejected,
and
then
the
neighbor
would
still
be
there,
but
it
would
in
the
hello,
but
it
would
be
stated
that
it
is
rejected.
So
the
point
here
is
that
when
the
neighbor
is
rejected,
then
we
do
not
need
to
set
up
a
TCP
session,
for
it
I
mean
nobody.
V
Then
there
is
a
two-way
state
which
basically
means
that
both
ends
have
actually
you
know,
accepted
or
agreed
each
other,
and
this
is
the
point
where
the
TCP
session
can
be
initiated
on
both
sides.
This
is
also
the
steps
where
the
planning
route
would
get
installed
in
the
forwarding
by
both
the
routers.
J
I
want
to
make
sure
you're
finished,
with
the
description
yeah
trying
to
be
very
okay,
so
I
understand
your
sequence
that
you're
going
through
I've
actually,
but
this
really
doesn't
interact
in
the
way
you
think
it
does
with
the
BGP
fizzle
and
I'll
just
stop
with
that,
and
we
can
take
it
offline.
It's
it's!
The
BG
beef
is
emitted
than
you
think.
I
realize
I've
been
pinged
on,
because
I
added
that
stuff
to
the
BGP
40.
You
know
the
latest
draft
of
BGP.
Perhaps
we
should
just
take
this
part
off
line
yeah.
V
J
J
V
So
on
the
session
management
itself-
and
this
is
the
BGP
session
management
once
the
discovery
is
done
and
adjacencies
that
I've
done
and
the
session
is
done,
then
the
session
management
is
performed
as
per
the
BGP
FSM.
The
liveness
detection
is
why
the
keeper
lives
and
the
whole
timer
that
you
already
have
so
BFD
can
be
used
fast.
V
There
is
a
subtle
difference,
but
those
mechanisms
are
still
there.
A
bgp
session
which
is
established
is
not
brought
down
due
to
the
hello
adjacency
hold
timer
by
default.
So
this
is
a
mode
where
which
is
a
default
mode,
where
the
liveness
is
left
to
the
Buju,
PF
SM
keeper
lives,
and
all
of
that
now
optionally,
you
got
some
feedback.
Certain
operators
may
want
to
really
use
the
hellos
as
a
faster
liveness
mechanism
and
they
may
not
want
toward
able
to
use
BFD
or
other
mechanisms.
V
V
One
key
thing
is
that
when
the
BGP
poor,
FSM
or
when
the
budget
with
your
FSM
is,
is
down-
or
you
know
it's-
it's
not
established
basically,
and
they
lose
a
adjacency
in
that
case,
Bodo
want
the
pure
state
to
be
cleaned
up
in
BGP.
So
that's
really
one
key
interaction
there,
and
this
is
because
these
are
Auto,
discovered,
bgp
sessions
and
no
matter
what
mechanism
how
we
set
them
up.
We
don't
want
them
to
be
cleaned
up
when
that
adjacency
goes
away,
and
that
this
is
just
that
part.
V
The
peering
route
itself
is
really
for
when
the
pouring
is
done
using
glue
pack
interfaces
now
this
route
does
need
to
program
with
the
higher
augment
distance
than
the
normal
blue
GP
routes,
and
this
is
because
this
is
the
reach
ability
over
which
the
bgp
session
has
been
established
in
the
first
place.
So
it
is
possible,
maybe
not
by
design
or
you
know,
it
is
possible
that
the
same
network
or
same
prefix
is
also
learnt
or
DGP
itself.
V
V
So
the
purpose
of
this
boring
plv
is
to
really
do
away
with
the
need
for
some
static
route
or
running
some
other
protocol
when
doing
play
in
between
loopback
addresses
and
obviously
it
allows
the
fabric
to
you
know
being
unnumbered
or
using
ipv6
link
local.
Only
so
there
is
a
working
group
or
option
called
go
on
going
for
this
in
the
idea.
H
Capital
artists,
I,
suggest
you
ask
for
implementers
feedbacks,
also
aside
from
an
operational
feedback,
because
some
of
these
mechanisms,
even
before
they
hit
the
network,
has
a
severe
scale
concerns
that
are
imposed.
For
instance,
inside
BGP
keepalive
machinery
itself
has
its
own
scale
limitations,
and
there
are
that
has
been
worked
on
over
period
of
over
numerous
years
across
multiple
implementations
to
handle
this
so
bringing
something
inside
BGP
like
this
has
scale
limitations,
which
you
probably
should
lay
out
what
they
are.
H
H
Write
the
second
thing:
I
think
it
is.
If
you
answer
to
this
to
say:
hey
look.
There
are
scale
concerns,
but
we
want
to
take
it
out
of
BGP
and
do
it
in
a
manner
that
it
doesn't
impact
the
core
bgp
machinery.
Then
you
got
to
vary,
then
you
got
to
specify
how
the
FSM
state
would
work
out
for
this,
and
if
you're
gonna
do
it
outside
bgp,
then
the
right
question
to
ask
is
why
not
try
and
do
it?
H
V
Sure,
thanks
so
and
start
in
a
different
order.
Why
do
it?
Why
not
make
it
generic?
Why
do
it?
Yes,
it's
UDP
and
be
picked
put
179.
Why
do
it
generic
the
reason
why
it
was
not
made
generic
is
because
it
was
intended
to
be
purpose
for
what
was
built
for
UDP
there
was,
there
was
no
desire
or
requirements.
I
would
say
to
for
it
to
carry
any
other
protocol
or
any
other
thing.
That
was
not
the
intention.
I
mean
at
least
that's
not
within
the
authors.
So
that's
where
you
know
it's.
V
N
However,
the
difference
I
can
say
is
that
LDP?
The
way
you
can
order
discover
the
session,
because
there's
nothing
specifically
for
the
session,
but
in
the
BTB
case,
like
every
session,
you
could
have
different
address
families
a
lot
of
different
since
humans
need
provisioning.
So
the
way
you
assumed
that
they
can
order,
discover
that
the
mean
that
in
this
data
center
environment
and
the
adjust
families
or
those
parameters
are
usually
same
for
all
of
those
sessions.
Otherwise
you
still
there.
V
Is
no
such
assumption
actually,
so
there
is
some
text
in
the
draft
which
clarifies
it
would
have
to
be
based
on
in
Auto
disk
or
is
not
just
by
itself.
There
would
have
to
be
templates
or
like
we
have,
for
example,
neighbor
group
or
neighbor
set.
We
would
have
that
template
and
have
an
association
of
that
template
with
a
set
of
interfaces
over
which
you
know
this
discovery
is
to
be
learned.
So
it's
not
like
everybody
is
the
same
and
the
policies
they
can.
V
V
Depending
on
the
position
in
the
network
in
the
in
the
clause,
the
templates
are
really
generic,
for,
if
I
am
connecting
to-
let's
say,
let's
say
it's
a
leaf:
it's
connecting
to
spine
one,
two,
three:
four,
it's
really
the
same
thing.
If
it's
connecting
down.
Let's
say
you
enable
it
with
a
editor,
then
it's
it's
similar.
There
is
no
again.
We
we
had
that
discussion
earlier.
There
is
no
that
much
policies
that
we
are
talking
about
here
in
the
data
center
right.
We
talked
we
discussed
that
earlier
in
the
working
group.
V
J
Okay,
I'm
gonna,
put,
although
fine
point
on
my
earlier
one,
because
I
think
it
may
be
helpful
in
German.
Look
the
reason
why
the
BGP
state
machine
in
42,
71
is
so
interesting
to
read
is
because
we
actually
worked
with
the
implementers
and
actually
took
in
all
these
various
options
and
tried
to
make
it
so
it
was
bulletproof
what
you're
moving
with
doesn't
really
encompass
that
information.
J
I
I
realize
it's
not
easy
to
pull
out
of
the
state
machine
and
what
you
so,
if
you're,
building
on
something
that's
not
quite
solid,
because
you
don't
have
a
solid
piece-
and
this
is
where
I'm
going
to
encourage
you
like
Kara,
did,
is
to
actually
work
with
the
implementers.
Why
that
that
42
71
was
so
carefully
worded
as
we
worked
with
all
the
implementers
and
people
who
added
new
implementations
have
had
to
interact
with
those
and
that
state
machine
is
extremely
important.
J
What's
happening
in
this
draft
does
not
align
with
those
existing
state
machine,
so
it
would
be
very
difficult
to
put
inside
of
BGP
as
it
stands
now.
I
believe
the
authors
can
refine
and
and
work
through
that,
but
it's
not
there
so
I
I
would
urge
you
to
pick
up
put
a
pin
in
it
pause,
make
sure
you've
got
that
talk
like
care
and
other
implementers
make
sure
you
actually
see
what
is
in
there
and
has
been
working
in
others.
I'm
sure
several
of
your
Cisco
buds
well
will
will
work
with
you
on
that.
J
So
I
have
faith
in
that
you
can
do
this,
but
you
really
sort
of
have
to
take
a
pause,
get
that
right
and
then
come
back
now.
Just
this
is
this.
Is
me
and
my
42
71
editors
hat,
you
gotta
go
back
and
rework
this
it.
Now
that
I've
listened
to
your
presentation,
you
got
too
many
misses
to
really
be
a
forward
path.
The
way
you
have
it.
Thank
you.
Okay,.
V
V
You
are
you're
correct
in
that
and
when
it's
it's
really,
we
thought
it's
really
an
implementation.
Specific
aspect
of
how
to
you
know:
do
it
whether
to
it's
obvious
that
it
should
be
done
in
a
way
that
it
does
not
affect
as
a
separate
thread
or
maybe
even
outside
the
process.
I
mean
all
of
those
options
are
implementation,
options
for
sure
yeah.
So.
H
First,
as
you
look
at
the
solution
and
you
try
to
come
up
with
something,
take
a
look
at
it
and
say
how
do
you
scale
this
out
and
when
you
scale
it
out
at
that
point,
you
probably
want
to
consider
whether
you
want
to
do
this
within
bgp
or
outside,
and
once
you
have
that
right,
then
that
would
be
a
good
point
to
cover
all
the
semantic
information
needed
to
get
the
solution
right,
because
there
are
multiple
holes
in
sure
yeah.
Thanks.
E
Okay,
okay,
now's,
your
time
to
run,
you
have
to
listen
to
me
again.
This
is
yet
another
proposal
in
the
space.
I,
don't
intend
to
go
through
the
internet
draft
you're
supposed
to
have
read
it
and
remember
it
from
the
last
time.
This
is
mostly
what
the
differences
are,
but
just
to
give
you
a
light
refresher.
The
idea
is
down
below.
E
Let
me
find
the
right
buttons
here
at
as
close
to
the
link
layer
as
we
can
get
exchange
of
PDUs
for
link
state,
then
a
fee
Saffy's,
our
encapsulations
and
john
has
beaten
me
up
and
everywhere
you
see
a
face.
A
fee
think
encapsulation
are
discovered
in
the
exchange
and
then
pushed
up
to
bgp
SPF
that
does
the
topology
and
routing
okay.
E
Essentially,
the
protocol
looks
like
find
each
other's
max
and
ID's
and
start
mac
level
keeper
lives.
Okay,
then
you
tune
the
timers
for
those
keeper
lives
and
any
higher-level
acts
then
negotiate
capability
exchange.
What
encapsulations
does
this
link
support
and
then
you
can
announce
exchange
the
particular
encapsulations
addresses
so,
for
instance,
here's
the
hello
keep
alive
right
and
its
local
ID
and
one
of
the
things
that's
changed.
Unfortunately,
I
don't
think
it's
the
next
slide.
Here's
an
idea
is
not.
E
E
So
I'm
gonna
take
you
through
one
example
of
an
encapsulation
exchange,
because
it
has
this
one
little
vibe,
which
is
interesting
to
the
previous
discussion,
add
drop
and
is
this
the
primary
exchange
and
what
I
meant
there
isn't
very
good,
but
there's
room
for
flags
here
to
say:
hey.
This
is
a
primary
interface
or
this
is
something
like
an
indirect
interface
like
a
loopback.
E
Okay,
so
you've
got
the
prefix
in
length
and
that
for
each
one,
very
boring
boring
is
good.
So
the
summary
of
the
changes
between
the
last
draft
is
the
node
identifier.
As
I
said
anything
you
need.
The
MPLS
label
became
a
list.
There
is
no
more
northbound
protocol,
it's
just
replaced
by
using
the
BGP
LS
and
its
extensions
API
and
then
there's
some
administrivia
stuff.
Like
the
ionic
considerations
and
references
got
filled
out,
the
node
identifier
can
be
an
ASN,
a
router
ID
woo.
E
E
Ok,
northbound,
instead
of
oops,
instead
of
a
protocol,
just
escape
steal
it
from
bgp
SPF
and
just
take
the
BGP
LST
LVS
and
say
here
they
are
and
the
rest
is
an
implementation
detail.
Ok,
multiple!
If
there
are
multiple
addresses
on
the
length,
multiple
TTL
visa
pushed
northbound
having
the
same
ID
pair.
E
J
Could
we
not
do
that
just
just
working
group
hat
chair,
please
either
put
it
in
a
separate
spec
where
you
both
go
to
it.
The
I'll
talk
about
why,
after
climb,
but
maybe
I
just
say
that
that
that,
as
a
review
of
that
particular
draft
Kitana-
and
I
have
been
working
through
that
one
could
we
just
take
the
node
specifications
may
mean
it
make
another
third
short
draft
that
that
draft
is
a
little
difficult
in
that
area.
Could
that's
just
a
that?
Don't.
E
E
W
H
Can
take
it
out?
I
know
Bruno
asked
earlier
also,
but
this
was
put
in
specifically
with
server
based
applications
in
mind
if
we
were
to
do
label
based
forwarding
all
the
way
up
to
the
servers
that
this
would
be
a
good
thing,
I
think
when
we
looked
at
the
draft
that
curity
had
proposed
earlier,
it
looked
like
a
fine
extension
where
he
wanted
to
handle
it
at
an
ARP
level.
H
V
E
E
Security,
as
I
said,
we
have
lots
of
time.
E
If
you'll
notice,
you're
on
the
global
internet,
they
dropped
two
polygons
with
those
passwords
on
them
on
the
network
within
15
minutes
they
were
owned
and
now
the
credentials
are
widely
known
everywhere.
The
NOC
is
scrambling
to
clean
up
the
mess,
because
I
mean
you
don't
want
to
know
how
far
those
passwords
had
permeated.
Let's
not
do
that
again.
Q
E
E
Unfortunately,
it's
super
linear
and
such
so
much
so
that
a
very
respected
member
of
this
community,
Tony
Lee,
is
madly
working
on
trying
to
partition
the
I
GP
noise
space
to
see
if
our
GPS
can
scale
to
this
and
by
our
GPS
would
mean
is,
is
and
OSPF
of
course
here.
The
idea
is
this:
just
has
the
noise
scaling
of
a
single
language
in
a
data
center?
Okay
and
the
changes
are
infrequent
and
BGP,
which
is
a
very
quiet
protocol.
Only
propagates
changes
now.
Q
Q
Follow
what
you're
saying
but
I
don't
think
that
is
applicable
because
I
think
the
nape
only
the
neighbor
discovery
part
was
detached
from
the
IGP
protocol
to
discover
the
neighbor
for
bgp,
because
the
BGP
doesn't
have
an
order.
Discovery
for
the
neighbour
user
has
to
configure
the
IP
address
and
we
want
to
get
over
that
hump.
So,
ok,
there
is
various
schemes
that
neighbor
discovery.
Q
Part
of
the
scheme
is
what
we
are
talking
about,
not
the
whole
IGP
I
mean
yes,
there
is
a
whole
IGP
related
activity
that
is
happening
for
reducing
the
flooding
and
all
that.
So
that's
all
parallel
activity
for
data
center
energy
piece
at
high
GP
level,
and
then
there
is
this
group
here
there
is
overlapping
and
all
that,
but
I'm,
not
talking
about
all
that
I'm
just
talking
about
there
is
that
how
does
BGP
autodiscover
a
neighbor
and
you
have
a
proposal.
Q
E
Is
it
through
BGP?
That's
because
that
it's
outside
of.
Q
It's
a
it's
a
it's
a
neighbor!
Ok,
if
you
look
at
it
from
an
isolated
way
or
you
know,
step
back
and
say:
ok
I
need
to
discover
the
neighbor.
We
discover
the
neighbor
for
BGP
in
this
specific
issue.
It
is
outside
of
BGP
state
machine
and
all
that
stuff.
But
then,
once
the
neighbor
is
discovered,
you
hand
it
off
to
BGP
and
let
me
GP
do
whatever
is
doing
right.
So
there
is
no
interference
between
the
two.
Once
you
have
done
your
part,
the
discovery
part
and
then
handed
off
to
BGP.
H
So
look
as
I
understand
and
I'm,
not
kale,
Patel
arcus,
without
trying
to
get
into
a
protocol
war.
The
hello
machinery
inside
IG
peace
not
just
do
a
neighbor
discovery,
but
it
does
a
lot
more.
We
have
part
of
that
machinery
already
taken
care
of
inside
bgp.
Using
keep
allies,
keep
allies.
If
you
look
at
BGP
scaling
issues,
there
are
many
the
to
make
big
scaling.
Issues
are
route
scale
at
scale
and
peering
scale.
The
pairing
scale
has
a
direct
correlations
with
keepalive.
H
Specifically
when
you
go
to
8,000
16,000
neighbors,
where
the
applicability
could
be
there
right,
not
in
data
centers.
Now,
then
the
normal
option
is,
do
I,
take
it
within
bgp
or
do
I,
take
it
outside
BGP
and
create
the
database
and-
and
that
is
where
I
think.
Hopefully
the
answer
to
your
question
comes
around
I
I.
Q
Still
want
to
say
that
it's
a
phase
one
unit,
you
do
the
neighbor
discovery,
you
find
the
neighbor
and
just
hand
it
off
to
BGP
not
to
affect
any
of
the
BGP
keepalive,
or
anything
like
that.
It
is
just
to
overcome
the
requirement
that
user
has
to
configure
the
BGP
Napier
we
want
to
autodiscover.
The
peer
here
is
the
scheme
you
found.
A
neighbor
you
now
carry
on
is
how
you
would
do
it
exactly
what.