►
From YouTube: IETF110-RIFT-20210308-1430
Description
RIFT meeting session at IETF110
2021/03/08 1430
https://datatracker.ietf.org/meeting/110/proceedings/
B
C
A
D
C
C
C
Good
mute,
so,
let's
start,
then
we
are
on
time
so
welcome
to
itf,
110
thrift,
working
group,
meeting
chairs,
jeffrey
justin
sure
we've
got
busy
agenda
for
today.
Tony
is
going
to
update
us
on
three
base:
specification
updates
on
yank
update
applicability,
draft
update
jordan
is
going
to
present
kv
registry
for
the
same
time,
there's
great
progress
in
segment,
routing
and.
E
C
Work
on
how
to
vpn
by
tony
again
working
group
status,
we've
sent
12
revision
to
ilg
reasonably
long
time.
There's
a
lot
of
work
going
on
to
address
alvarez
commands.
Hopefully
we
are
keeping
our
id
happy.
There
are
also
weekly
meetings
to
work
on
the
comments.
C
Applicabilities
making
draft
has
been
in
working
with
platform
for
quite
some
time,
still
working
on
comments.
Young
there's,
ongoing
work
and,
as
our
work
is
progressing
new
cultures
and
you'll,
see
presentations
there
by
jeffrey,
not
well,
sorry,
stephen's,
first
site
you're,
contributing
to
atf
and
subject
to
adf
policies.
If
you
haven't
read
not
well,
please
do
so.
C
D
D
So
we'll
talk
to
one
book
again
and
what's
going
on
with
alvaro's
review
next
one,
please,
okay,
the
day,
one
book
shameless
plugin
game,
it's
for
free!
You
can
download
it.
It's
a
fat
little
thing
that
talks
about
jupiter
implementation,
open
source
and
deals
with
a
lot
of
you
know
the
magic
of
the
real
implementations
coming
up
and
what
the
stuff
looks
like
and
further
considerations
when
you
build
the
fabric
and
so
on,
and
so
on.
E
D
All
right
so
alvaro
is
giving
us
a
very
nice
review.
He's
slogging
through
the
whole
thing
thanks
so
much
most
appreciated,
he's
learning
you
know,
crash
learning,
thrift
on
the
on
as
well
on
the
go,
and
we
started
weekly
meetings
to
basically
work
through
the
comments
and
polish
the
document
until
we
hopefully
get
him
happy
and
move
to
the
next
step.
So
first,
big
thing
is
that
the
document
will
go
svg,
so
that
seems
to
work.
D
So
we
are
in
a
sense
a
little
bit
of
a
guinea
pig
because
we're
probably
one
of
the
first.
But
given
how
complex
a
lot
of
the
figures
are
in
the
respect,
it
makes
sense.
So
jordan
volunteered
to
add
a
lot
of
these
complex
figures
in
svg
and
we
already
have
fsn
as
we
do
pictures
and
so
on.
D
Jeff
can
you
kill
the
mic
sideways
noise
and
the
bigger
things
that
came
out
from
the
first
meeting
that
we
had
there,
and
some
discussion
was
that
we
need
to
refactor
the
intro
section.
This
really
suffered
from
a
lot
of
previous
comments
where
we
remove
things
like
requirement
section
and
so
on.
D
So
we
refactor
that
stuff
into
an
intro
and
it
will
need
the
reader's
guide
to
understand
for
reader,
depending
on
his
interest,
what
kind
of
fabric
he's
building
and
how
and
how
much
he
wants
to
implement
over
if
which
parts
need
to
be
read
and
how
they
build
up
on
each
other.
Some
mild
moving
of
sections
will
be
necessary
and
lots
of
forward
referencing
to
model.
C
B
Jeff
could
could
you
do
full
screen
in
presentation.
C
B
B
B
F
Okay,
sorry,
sorry
for,
for
the
unstable
connection,
hello
chairs
and
colleagues,
I
have
a
very
short
introduction
of
the
latest
status
of
rift
applicability.
Draft
version,
zero,
four
on
behalf
of
all
the
co-authors.
Okay,
next
page.
D
B
B
F
About
the
connection,
I
would
be
very
quickly
so
next
next
page.
F
F
F
B
You
are
sharing,
but
but
the
slides
are
not
moving.
C
F
Okay,
the
update
since
itf109
the
chair
here
is
announced
or
working
group
last
call
for
the
draft
on
december
10th
2020.
F
from
the
comparison
of
version
0,
3
and
version
0
4.
You
may
find
math
editorial
optimizations
and
2
chapters
were
added.
F
Yes,
so
I
would
like
to
hear
guidance
from
chairs
of
the
next
step
of
the
working
group.
Last
call
and
comments
are
always
welcome.
That's
all
for
my
presentation.
Thank
you.
C
Thank
you
sandy.
So
with
regards
to
addressing
comments
from
reviews
in
general
people
who
provided
commands
don't
track,
they
don't
participate
necessarily
in
routing
area.
C
So
next
step
for
you
would
be
reach
out
and
ask
for
final
comments
where
they're
happy
with
how
you
address
them.
Usually
there
are
some
iterations,
it's
an
iterative
process
to
you
know
to
update
document
and
obviously
we
would
like
to
finalize
last
call
as
soon
as
possible.
So
please
do
so
and
we
would
love
to
finalize
it
within
a
couple
of
weeks.
C
G
Yeah,
okay,
hello,
everyone,
I'm
sam
dijon
from
zte.
This
presentation
is
for
the
update
of
rift
yang.
We
have
closer
bruno
yohan
and
shifu
next,
please.
G
And
this
is
the
overview
of
the
model.
The
model
is
defined
according
to
drift
protocol
draft.
The
model
includes
protocol
configuration,
static,
information
and
notification,
and
some
features
are
edited
to
enhance
the
protocol
and,
except
for
the
co-author,
we
also
thank
to
tony
and
ben
chung
for
their
detailed
review
and
available
comments.
And
next,
please.
G
G
This
is
the
neighbor
state.
The
information
received
by
the
neighbor
includes
the
neighbor
node
information,
interface,
information
and
some
other
information,
such
as.
If
the
bfd
session
is
up
between
the
local
node
and
the
neighbor
next,
please-
and
this
is
a
database
state.
The
database
information
includes
the
base
tie
information
such
as
the
direction
type
originator
and
something
else,
and
the
detailed
information
of
the
noda
thai
prefix
tie
and
the
key
value
store.
G
C
D
No,
I
don't
think
alvaro's
comments
were,
will
be
changing
the
model
or
have
any
you
know,
fundamental
mechanism
or
anything
like
that.
No,
I
don't
think
so.
I
still
have
to
review
this
last
version
of
the
anchor
for
it.
C
G
B
D
D
C
C
D
A
All
right
thanks
everyone,
so
my
name
is
jordan
head,
I'm
just
here
to
present
the
rift
key
value
registry,
the
actual
kb
details
are
defined
in
the
main
spec,
but
this
further
details
a
lot
of
the
details
pertaining
to
like
structure
and
key
types
and
how
those
are
maintained
next
slide.
Please.
A
So,
just
a
bit
of
a
primer
for
those
underwear
haven't
looked
at
in
a
while.
Basically,
kv's
ties
are
used
to
disseminate
information
to
other
riff
nodes.
You
know
pulling
this
little
quote
straight
from
the
draft
rate.
The
data
contained
within
these
kv
ties
can
be
used
for
any
imaginable
purpose.
So
it's
we
give
you
just
enough
rope.
A
A
Please
so
I'll
leave
it
for
the
respective
presenters
today
to
kind
of
elaborate
on
their
specifics.
But
as
far
as
you
know,
current
use
cases
so
auto
evpn
is
you
know.
One
thing
we're
looking
at
is
basically
leveraging
kvs
for
necessary
operational
information.
A
You
know,
relationship
between
the
overlay
and
the
underlay
for
state
srift
is
actually
using
it,
for
you
know,
disseminating
the
like
srgb
system,
id
sort
of
details
to
facilitate
forwarding
for
sr,
and
then
finally,
you
know,
while
there's
no
mention
of
it
currently
and
in
the
multicaster
of
implementation.
You
know
it's
that
there.
A
I
think
there
are
some
considerations
for
doing
so,
but
that's
something
for
a
little
bit
more
discussion
and,
lastly,
it's
not
listed
on
here,
but
the
draft
itself
does
make
some
considerations
for
like
ipmaq,
binding
and
security
rollover
considerations
for
like
the
security
model.
A
A
A
It
can
also
signify
oui,
which
is
basically
just
vendor
specific
or
company
specific,
and
they
use
their
previously
signed,
ui
space
and
finally,
there's
an
experimental
identifier
as
well
for
any
other.
You
know
use
cases
the
three
bytes
for
key
identifier
itself
describe
the
you
know
the
structure
and
you
know
the
specific
elements
within
the
values
field.
So
it's
and
then
kind
of.
A
Finally,
it's
just
it's
the
data
itself
and
if
you
jump
to
the
next
slide,
there's
a
you
know:
30
000
foot
view
example
of
what
we
can
do.
So
if
we
were
just
for
the
sake
of
example,
looking
at
a
well-known
you
know,
tie
or
kv
it
can
contain
any
data
or
data
structure.
You
know
it's
not
limited
to
strings
or
integers.
We
could
even
put
another
first
encoded
data
model
in
there.
If
we
wanted
to,
but
but
again
it's
you
know
your
miles
may
vary.
A
You
can
do
whatever
you
need
to
with
it.
I
guess
next
steps
would
be
you
know.
Co-Authorship
and
comments
are
welcome,
feel
free
and
then
you
know
we
can
pursue
last
call
after
after
some
feedback
and
last
slide.
If
there
are
any
questions,
I
can
try
and
address
them
now
or
we
can
follow
up
offline.
B
B
I
assume
the
well-known
is
it's:
it's
not
exactly
a
key
type.
It's
mainly
it's
a
property
of
a
type
or.
D
D
No,
it's
not
no,
it's
not.
It
defines
what
you
talk
about,
but
then
the
thing
itself
is
in
the
data
right
and
look.
If
you,
for
example,
go
I'm
unhappy
with
that,
then
you
have.
You
know
one
byte
in
front.
So
beside
the
well-known
we
can
have
something
like
segment
routing
purposes
and
you
just
take
a
value
and
then
you
run
and
you
do
behind
whatever
you
want,
but
you
still
have
to
keep
to
the
structure
key
and
value
because
we
need
tie
breaking
right
if
the
same
key
id
comes
from
multiple
places.
E
C
B
Okay,
all
right,
so
this
is
a
segment
routing
with
ripped.
We
have
co-authored
myself,
jeff
jordan
had
who
joined
recently
and
don
paddak
from
time
some
time
ago.
Next
slide,
please
the
segment
writing
draft
was
actually
published
some
time
ago.
We
never
really
talked
about
it
much.
It
was
not
presented
before
so.
This
is
the
first
time
we
probably
presented
here.
So
let
me
first
start
with
the
comparison
with
ospf
or
bgp
based
segment
routing.
B
B
Even
in
the
old
days
before
sros
ling
came
to
life,
the
all
the
provisioning
is
on
centrally,
maybe
in
the
head
of
an
operator
and
then
and
the
planning
result
is
then
carried
to
maybe
on
pen,
paper,
pen
and
paper
and
then
entered
into
the
individual
routers
and
from
there
the
provisioning
information
is
flooded
out
nowadays,
of
course,
yeah
you
can
use
netconf,
young
or
other
means
to
to
send
the
centralized
centrally
planned
information
to
to
the
routers
and
the
routers.
Then
flood
the
advertise.
The
information
next
slide.
B
Please
now
about
traffic
forwarding.
There
are
two
ways
of
doing
sr
forwarding
the
first
simple
one
is
you
afford
traffic
based
on
the
igp
or
bgp
routing
just
use
a
prefix
set
that
is
basically
replacing
ldp
with
igp
or
bgp
based
label
distribution,
nothing
special
there.
B
Now
that,
when
the
ingress
router,
it
needs
to
needs
to
put
the
cities
into
the
package,
it
can
be
that
to
determine
what
to
be
put
into
the
package,
it
can
be
either
done
by
base
by
a
local
calculation
or
based
on
the
sr
policy
programs
from
the
sr
controllers.
B
Now,
compared
to
rips
how
this
is
done,
the
srgb
and
seed
distribution,
how
it
is
done.
We
now
do
not
provision
those
srgb
or
acid
information
on
the
non-tough
notes
and
there
will
be
no
flooding
from
those
either.
B
Instead,
the
result
of
central
planning
is
flooded
south
using
the
kiwi
mechanism
by
the
tough
notes.
Of
course,
the
top
notes
need
to
learn
all
those
provision
information
from
the
oxidation
oxidator,
so
this
actually
combines
a
two-step
process
in
the
igp
or
bgp
case
into
a
single
step,
and
that
perfectly
matching
the
gtp
principle
of
the
the
rift
next
slide.
Please.
B
So
about
traffic
forwarding
we
here
we
only
care
about
the
traffic
steering
based
on
the
city
list.
In
other
words,
a
labor
stack
in
particular
srv6
is
not
in
scope
for
now
and
then,
when
it
comes
to
the
how
to
determine
the
seed
list,
we
will
only
rely
on
sr
policies
programmed
by
the
controllers.
B
And
then,
when
we
do
not
have
parallel
links
or
multiple
planar
tech
topologies
that
the
leaves
only
have
northbound
default
routes,
so
they
cannot
determine
the
seedless.
That's
that's
why
we
rely
on
the
sr
policy
from
the
controllers
and
we
only
need
to
care
about
note
6,
because
when
you
have
no
parallel
links,
then
no
set
is
all
you
need.
B
Besides
that,
we
don't
see
benefits
for
prefixes
that
are
not
for
nodes.
Now,
if
you
do
have
parallel
links
or
if
you
do
have
multiplanar
topologies,
then
we
need
to
have
adjacency
to
choose
the
right
link
or
right
plan,
and
for
that
we
can.
We
can
use
sr
or
lb
local
base
for
for
the
sr,
for
the
saves.
B
We
have
some
outstanding
discussion
on
how
that
can
be
done.
This
will
be
addressed
in
in
a
future
revision.
B
There
is
one
issue
we
would
like
to
call
out
here:
reef
protocol
itself
does
not
require
loopback
addresses
in
principle
now
notice
that
sr
traffic
steering
is
based
on
routing
to
node
segments
in
the
seedlist.
So
we
must
have
individual
routes
to
those
nodes
in
the
seedless.
B
You
could
do
system
id
it's
just
that
now
you
have
a
different
table
for
those
routes
based
on
system
ids,
and
also
consider
that
operator
may
want
to
do
managements
using
those
using
loopback
addresses
anyway.
So
if
you
put
all
those
considerations
together,
one
question
is:
should
we
simply
require
loopback
addresses.
B
B
So
we
use
qb
to
distribute
sr
information
here.
So
we
have
two
boxes
here.
The
first
one
is
that
we
need
a
key
type
to
describe
that
this
is
for
sr
purpose
and
then
and-
and
then
we
have.
The
next
box
is
for
the
specific
ssr
information.
B
We
here
we
need
to
identify
the
system
id
slash,
loopback
address,
basically
specify
which
node
this
is
for
and
and
there
we
have,
the
label
base
label
range
and
no
note
say
and
potentially
other
information
in
the
future,
especially
for
how
we
advertise
adjacency
information
here.
B
Here
you
can
see
that
there
is
a
system
id
slash
new
pack
address
to
identify
which
notice
is
for
so
that
is
sort
of
like
a
key
identifier
to
me
and
what's
the
relationship
with
of
that
information
and
the
s-rift
note
here
and
what
is
gb
tbd2
versus
tbd.
B
So
obviously
we
see
comments
and
we
we
will
address
the
outstanding
issues
and
after
er
or
we
will
settle
those
outstanding
issues
and
revise
the
drafts
that
time
we
will
see,
seek
working
group
adoption.
D
Yeah
so
I
stand
accused
of
not
having
tony
juniper.
D
Of
not
having
read
the
newest
version,
but
my
observation
is
that
you
start
to
define
those
things
and
what
you
suggest
will
work.
Fine
in
principle,
make
sure
that
you
keep
very
precise
account
what
is
northbound
and
what
is
south
about
in
terms
of
key
values
that
you
want
to
redistribute,
because
first
mechanisms
are
different
right
time.
Breaking
and
second,
it
has
all
implications
on
scalability
of
the
solution.
B
I
got
a
your
comment
about
making
clear
is
north
or
southbound.
What's
the
second.
D
D
So
why
not?
But
then
you
impose
addressing
on
the
whole
scheme.
So
beware
what
you
wish
for,
because
if
you
work
of
system
idea
that
full
gtp,
if
you
start
to
talk
about
loopbacks,
then
you
better
describe
how
to
automatically
derive
lupex
from
system
ids,
which
theoretically
can
be
done
or
you
are
bound
along.
The
thought
end
to
force
people
to
address
loopbacks
on.
D
B
Yeah,
so
one
really
question
is
that's
in
a
rift
network
when
you
do
not
use
new
back
address,
how
do
you
normally
manage
the
nodes
or
you.
D
C
Yeah,
I
think,
there's
larger
picture.
If
you
are
planning
on
traffic
engineering-
and
you
know
to
do
explicit
stuff,
probably
you
would
want
to
be
able
to
address
the
nut
specifically.
So
it's
not
the
cattle
anymore
for
pets,
but
practically
tony
to
your
comment
about
scalability.
If
you
look
at
non-rift
network,
the
process
of
provisioning
is
orthogonal
to
process
of
discovery.
So
you
would
go
to
your
orchestration
system
and
provisions,
rgbs,
seeds,
ikea
or
something
else,
and
then
you
would
use
a
dynamic
part
of
network
to
actually
do
out
the
discovery.
C
D
Tommy's
tommy
is
raising
his
enzo,
but
yeah
bigger
discussion,
maybe
list,
but
arguably
you
could
build
the
full
sr
thing
fully
gtp.
If
you
have
system
id,
you
could
derive
all
these
blocks
and
everything
and
just
distribute
them,
and
you
don't
need
to
configure
everything.
But
I
think
this
is
to
lock
for
the
mic
now.
C
Okay,
yeah,
thank
you
yeah
I
mean
non-planar
topologies
and
with
single
links,
absolutely
there's
nothing.
You
just
need
to
to
reach
next
node
in
more
complex
topologies.
Probably
something
more
would
be
needed,
but
this
is
something
that
should
definitely
be
addressed
in
the
draft
for
implementers.
B
E
I
wanted
to
make
some
observations
more
than
anything
like
this.
D
A
G
D
For
something
completely
different,
which
is
probably
unsurprising
when
I'm
showing
stuff,
so
this
is
actually
someone's
else
idea,
which
I
hope
to
flesh
out
and
there's
a
bunch
of
other
people
who
contributed
a
lot
because
it's
pulling
a
couple
of
technologies
together.
D
So
it's
lots
of
jordan's
work,
wentz,
of
course,
and
I
kind
of
fleshed
out
the
rift
part
based
on
somebody's
house
idea,
and
we
call
it
autoevpn
and
I
show
in
the
next
slide
the
motivation
and
what
the
hell
are
we
up
to
next
one,
please
right
so
first
I
say
I
mean
what
are
we
doing
right?
What
are
the
drivers
and
what
is
the
vision?
What
you're
trying
to
achieve?
Then
I
show
you
the
architecture
of
the
whole
thing
and.
E
D
D
D
D
So
when
you
now
start
to
deploy
edp
and
sl2,
you
start
to
deal
with
the
fact
that
it
needs
quite
significant
amount
of
configuration.
So
you
either
take
a
magic
controller.
I
mean
nothing
wrong
with
that.
It
does
it's
it's.
You
know
its
own
beauty
and
in
larger
deployments.
That
may
be
absolutely.
You
know
a
better
solution
right,
because
evpn
skills
way
bigger
than
l2
could
right
and
it
was
one
of
the
undoings
of
l2,
and
then
you
face
your
own
set
of
problems
right.
D
D
We're
talking
always
evpn
on
the
fabrics,
which
is
you
know
where
it's
being,
I
would
say,
prominently
used
if
not
actually
used
in
most
of
the
cases.
So
you
configure
l3
ip
on
delay,
which
means
you
go
and
address
a
lot
of
stuff
all
the
links
and
with
the
v6
link,
local
and
forwarding
of
a
v6
and
v4.
D
You
have
a
little
bit
less
work,
because
v6
does
no
pretty
good
work
of
the
whole
thing
and
then
you
go
and
provision
your
underlay
protocol
unless
you
run
rift
right,
so
you
have
to
give
ivs
and
you
have
to
configure
the
peers
and
igps
are
a
little
bit
better
about
that
and
bgp
has
some
special
hacks
where
it
tries
to
lessen
the
load,
and
you
start
to
configure
vfd
and
try
to
bring
you
on
the
layout
and
then
you
go
and
debunk
it.
D
And
then
you
start
to
configure
the
l3ip
overlay
to
give
to
get
you
evpn.
So
you
bring
up
your
rrs
where
you
need
them
which
needs
cluster,
ids
and
loopbacks,
and
then
you
start
to
bring
up
the
leaves
right
which
actually
have
the
c
interfaces.
Only
then
you
need
again
cluster
ids
and
loopbacks
and
loopbacks
for
vxlan
we're
talking
ep
and
dx
land,
because
this
is
the
most
prevalent
case
today.
D
By
far
and
then
you
need
some
loop
expo
rb's
and
raw
distinguishes
four
type,
two
type
fives
and
routers
vlans
vnis,
and
you
know
I
probably
forgot
a
bunch
of
more
things
and
then
you
go
and
debug
the
whole
thing.
So
can
we
have
the
l2
simplicity
back
for
edpn
and
that's
the
driver?
That's
the
question
we
ask
and
we
think
that
with
rift
we
can
the
next
one.
So
what
is
the
architecture
of
such
a
beast?
D
Next
one?
Please?
Okay,
so
it
changes
a
couple
of
key
observations
which
are
unique
to
rift
so
far
and
first
you
ip
underlay
the
salt
right.
Unless
you
really
want
to
ssh
into
the
nodes-
and
you
know
you
will
possibly
want
sr
and
other
frills
and
things,
but
if
you
just
want
basic
ip
in
any
flavor
v4
v6
v4
over
v6,
both
stuff
just
magically-
comes
up
zero
config.
Well,
you
have
to
fix
the
top
of
the
fabric
right
because
the
protocol
doesn't
have
gps.
D
So
it
doesn't
know
what
is
up
and
what
is
down,
and
that
arguably
has
nothing
to
do
with
geographic
location
either
right.
So
only
humans
understand
what
is
the
top
of
the
fabric.
So
you
fix
this.
You
know
whatever
you
have
this
couple
of
top
of
fabric
and
you're
pretty
much
done.
You
have
the
ip
underlay
and
then
you
start
to
observe.
D
Distributed
fashion,
so
you
don't
need
a
controller,
you
don't
need
additional
synchronization.
You
have
enough
information
everywhere
to
derive
what
you
need
to
configure
a
full
evp
and
overlay.
D
So
when
we
started
to
work
on
the
stuff
you
know,
a
couple
of
things
came
up
where
we
extended
the
architecture.
Such
you
know,
simple.
First
set
of
observations
and
solution
with
a
couple
of
things
that
came
up
so
one
observation
is
that
that
works,
fine
on
fabrics
with
different.
You
know
number
of
parts,
different
heights
of
parts
different
fan
out
in
every
part.
That
is
not
a
problem
at
all.
D
Then
we
started
to
observe
that
if
you
watch
evpn
how
it's
deployed
in
80
or
80,
plus
of
of
the
cases
that
we
see
is
that
people
have
two
types
of
vlans,
they
have
vlans
that
they
want
to
stay
purely
on
the
same
fabric
and
they
want
vlans
that
may
be
stretched
between
fabrics
and
all
of
a
sudden.
You
start
to
realize
that
the
fabric
id
is
a
concept.
D
So
if
you
want
this
thing
to
work
over
multiple
fabrics,
arguably,
then
you
really
want
something
like
a
fabric
id
which
is
still
ztp,
because
if
you
don't
provide
it,
you
just
take
a
default
value,
take
one
and
that's
it
and
you
run
with
it.
But
if
somebody
wants
something
more
sophisticated
around
multiple
fabrics
and
stretch
vlans,
then
they
will
need
the
fabric
id
which
they
basically
every
switch,
needs
a
fabric
id,
and
then
we
can
derive
literally
vlans.
That
stretch
and
do
not
stretch-
and
this
little
picture
shows
you
the
reference
architecture.
D
The
rrs
are
at
the
very
top
after
long
discussions,
that's
where
we
ended
up
with
and
there's
a
bunch
of
them
of
course,
and
then
on
the
leaves
we
run
running
integrating
irb,
also
type
five.
So
when
you
read
the
draft
today,
it
is
sketchy
because
we
didn't
have
much
time
to
publish
it.
So
we
omit
right
now
all
the
computation
of
the
values
there
is
no
type
5,
and
so
all
the
architecture
is
fixed.
There
is
all
the
placeholders,
but
we
didn't
feel
the
stuff
in
so
next
one.
D
So
I
show
you
a
bunch
of
details
to
to
show
that
this
is
not
just
a
powerpoint,
that's
actually
pretty
real.
So
if
you
a
little
bit,
you
know
ahead
of
the
curve.
You
will
know
what
programming
language
that
is,
but
basically
will
provide
all
the
derivation
as
algorithms,
because
it's
so
complex
that
you
know
verbal
description
is
iffy.
We
have
some
very
simple
verbal
description
in
terms
of
what
kind
of
things
influence
very
very
derivation
of
the
value,
but
then
we
provide
precise
algorithm.
D
So
here
is
an
example
of
all
the
stuff
that
you
have
to
pull
out
on
all
the
leaves
and
all
the
route
reflectors
to
configure.
So
you
need
a
cluster
id.
You
need
a
v6
look
back.
You
need
a
type
5
v6
loopback,
which
is
different,
a
type
5v4
loopback
and
a
bgp
router
id
and
the
autonomous
system,
and
I'm
showing
you
how
this
thing
can
be
computed
right.
So
in
the
decoding
folder
you
see
how,
for
example,
a
cluster
id
is
derived.
D
They
write
the
same
way
as
the
private
as
and
it's
basically
the
fabric
id,
which
we
shift
a
little
bit
and
add
it
to
the
smallest
private
as
and
then
we
mold
it
to
it.
You
know
so
it
doesn't
run
out
of
the
private
data
space
and
that's
good
enough.
So
you
have
a
private
aes
which
is
fabric
dependent.
D
So
what
you
do
is
you
shift
things
a
little
bit
around
and
you
store
a
bunch
of
things
and
what
I'm
not
showing
we
will
be
seeding
with.
You
know,
probably
a
small
array
of
pretty
good
random
numbers.
So
the
whole
thing
has,
you
know:
lots
of
entropy
going
for
it,
and
the
architecture
hinges
on
the
fact
that
you
will
be
running
on
the
v6
fabric,
because
otherwise,
simply
all
the
interface
addressing
the
v4
interface
addressing
becomes
unresolvable
right.
D
You,
you
somehow
need
to
centralize
instance
that
takes
a
10
star,
slash,
8
and
assigns
everywhere
unique
addresses
and
that's
a
major
pain,
whereas
v6
will
derive
link
local
for
you
and
they
don't
even
have
to
be
unique,
but
they
will
be
working
fine
and
the
v6
loopbacks
we
derive
are
good
enough
to
provision
dni's
and
run
bgp
sessions
and
so
on.
So
all
this
stuff
will
be
flashed
in
next
one.
D
D
All
right,
so
what
do
we
have
to
add
to
rift
nothing,
but
we
choose
to
do
a
couple
of
optional
things.
D
So
there
is
a
suggestion
to
add
optional
version
on
the
lines
and
the
ties
and
note
ties
only
with
the
only
purpose
to
prevent
us
from
forming
adjacencies
between
you
know,
evp
and
version
one
and
okp
and
version
2
for
the
future.
D
I
think
that
is
a
nice
thing
right,
because
we
don't
want
to
mix
that
we
also
want
to
figure
out
if
we
have
nodes
within
the
fabric
that
do
not
support
auto
edpn
and
maybe
shoot
right,
there
will
form
adjacencies
to
them,
but
maybe
the
top
of
the
fabric.
You
can
see
the
certain
leaks
do
not
run
auto
evpn
and
they
will
give
you
some.
D
You
know
useful
information
and
in
case
we
want
to
really
go
multiplying
support
and
we
want
a
better
route,
reflector
architecture
in
the
sense
that
we
don't
want
too
many
route
reflectors,
and
we
want
to
spread
them
across
planes
when
we
thought,
through
the
issues,
we'll
need
a
new
tie.
D
That
only
goes
northbound
on
the
tops
which
describes
the
plane.
Basically,
all
the
system,
id
of
all
that
of
of
the
whole
plane
that
has
to
do
with
the
election
algorithm.
If
you
look
at
the
election
algorithm
in
detail,
you
understand
that
otherwise
you'll
not
be
able
to
spread
across
planes,
and
then
you
know
there
is
a
different
problem
that
if
a
single
plane
goes
down,
you
could
take
down
all
your
rock
reflectors
and
then
flip
over.
So
the
election
algorithm
is
also
built
very
carefully,
so
a
single
guy
joining
kendall
start.
D
What
also
comes
now
is
that
there
is
a
strong
desire,
of
course,
once
you
run
something
like
that
to
have
some
information,
whether
it
came
up
whether
all
the
bgp
sessions
are
up,
you
know
and
how
many
prefixes
did
did
evpn
put
on
a
leaf
and
so
on
so
on
the
type
2
mac
addresses,
for
example,
and
that
we
can
do
by
basically
sticking
a
bunch
of
things
into
the
key
value
store
and
just
flooding
it
up.
So
that
seems
like
a
small
investment.
D
It's
strictly
not
protocol
right,
but
it's
pretty
handy
because
you
don't
ask
people
to
deploy
anything
except
rift
and
they
get
some
minimal
insight
into
their
evpn
being
you
know,
auto
configuring
and
coming
up
and
working
and
whether
anything
is
wrong
and
what
is
roughly
the
scale
on
each
leaf
and
so
on.
I
think
that's
it
next
one.
I
think
it's
the
last
one
of
the
lot.
D
Oh
no
yeah,
so
we
will
fill
in
the
algorithm.
We
will
add
the
type
5
irb
variables
and
algorithms
as
well,
which
right
now
or
are
commented
out.
So
the
the
key
value
thing.
I
don't
know
what
it
should
be
part
of
this
specification.
I
think
it
should,
but
maybe
we
pull
out
actually
a
different
draft
for
that
we
welcome
co-authorship.
Whoever
is
interested
in
working
on
that
as
from
to
the
implementation,
if
you
want
to
run
the
whole
thing
well,
you
need
the
whole
rift.
D
But
if
you
just
interested
implementing
the
leaf
side
of
things,
a
rift
lift
implementation
is
enough
and
as
the
basic
spec
describes,
it
is
actually
much
much
simpler
to
implement
the
whole
protocol
right.
You,
basically,
you
need
a
very,
very
minimum,
flooding,
northbound
and
you're
pretty
much
in
the
game,
and
you
can
literally
know
you
can
also
meet
flood
reduction
economy
between
balance.
D
D
B
G
D
D
So
the
fabric
starts
to
look
like
a
one.
Big
ethernet
switch
to
them
in
a
sense
with
vlans
and
that's
what
we're
addressing
that's
something
that
is
being
deployed
a
lot
and
you
know,
preconditions
have
a
significantly
complex
configuration
and
there
are
controller
solutions,
but
that's
something
where
you
could
buy
just
three
four
switches
and
literally
stick
them
together,
like
ethernet
switches
and
you
get
evpn
with
the
same
simplicity
as
deploying
l2.
D
I
mean
it
will
scale
to
much
bigger
scale
at
a
certain
point
in
time.
I
think
the
manageability
of
such
a
thing
will
become
iffy
right,
but
I
don't
know.
Maybe
people
will
I
mean
the
rift
will
support
it
at
any
scale
and
so
will
evpn.
So
you
know
sky's
the
limit
really,
but
it
addresses
you
know
a
specific
deployment
use
case
which,
however,
which
we
see
a
lot
of
really
a
lot.
D
G
D
H
Yeah
there
we
go
yeah
double
mute.
I
said
I'll
go
to
return
around
80..
So
just
a
quick
comment
as
this
progresses.
It
would
be
good
to
keep
best
informed.
I'm
sure
that
if
this
is
a
very
common
scenario,
they
would
be
interested,
it
might
be.
You
know,
people
there
who
want
to
maybe
collaborate
or
have
some
other
comments.
H
So
just
that
thanks.
I.
D
Already
addressed
up
in
best,
actually
I'm
I
got
the
tail
end.
Slot
invest
this
time,
so
they'll
be
aware
of
what's
going
on
absolutely
yeah
and
the
discussion
where
it
should
be
adopted,
should
it
be
adopted
and
so
on.
It's
all
upcoming.
I
just
wanted
to
evoke
some
interest
and
see
who
is
you
know,
willing
to
jump
and
help.
C
Okay,
personally,
I'm
very
happy
to
see
evp
and
draft
coming
into
rift.
I
mean
it
leverages
unique
capabilities
of
rift
and
it's
great
stuff
and
auto
discovery
capabilities,
absolutely
unique,
and
that's
really
great
next
step
development,
for
if
we
are
on
time,
we
are
actually
two
minutes
over
thanks.
Everyone
for
being
here
with
us
protocol
is
progressing
really
well.