►
From YouTube: IETF112-RIFT-20211108-1430
Description
RIFT meeting session at IETF112
2021/11/08 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
A
B
Yeah
yeah,
it's
about
time
good
morning
to
everybody,
hey
jeffrey,
it's
an
early
morning,
california,
so
welcome
to
atf
112
vegan
virtual
and
please
not
well
by
participating
in
a
tf.
You
agree
to
follow
idea,
process
and
policies
specifically,
would
also
like
you
to
ask
to
be
polite
and
treat
your
fellow
idea
first
with
respect
and
be
number
of
events
where
it
wasn't
so,
luckily,
not
in
our
working
group.
But
we
would
like
to
emphasize
the
point
that
it's
a
no
harassment
environment.
It
would
like
you
to
to
act
accordingly.
B
B
B
Okay,
young
model
has
addressed
comments
received
from
young
doctors
and
from
shares
perspective
is
ready
for
working
with
lascal,
which
will
start
soon
kv
registry.
You
would
like
to
ask
the
authors
what
they
think
with
regards
to
upcoming
changes.
If
anything
needs
to
be
changed
and
when
do
they
think
to
be
ready
for
working
with
plus
call
out,
evp
and
draft
is
in
progress,
there's
really
good
progress.
I
think
the
results
are
planning
implementation,
multicultural
segment
shrouding.
C
C
So
main
changes
from
last
time,
first
and
foremost
working
group
adopted.
Thank
you
everyone
for
that.
Beyond
that,
we've
started
working
in
some
foundational
components
for
data
center
interconnect
variable
derivation
with
that
came
a
few
considerations
to
how
we
elect
the
top
of
fabric
route
reflectors.
C
You
know
we
also
worked
in
some
multi-plane
fabric
components
there
as
well.
We
increased
collision-free
scale.
Tony
was
able
to
squeeze
some
more
out
of
the
hashing
algorithms
and
we've
also
added
a
operational
section.
Some
of
the
feedback
you
know
indicated
that
it
would
be
helpful
and
get
a
little
bit
more
detail
and
then
just
minor
restructuring,
nothing
terribly
exciting
there
next
slide.
Please.
C
C
C
C
So
now
we
would
say
you
know
highest
hit
with
the
dci
bit
lowest
with
the
dci
bits
second
highest,
and
then,
if
at
that
point
you
know,
depending
upon
your
deployment
like
if
we
were
to
have
a
tough
node
that
wasn't
doing
dci
gateway
stuff,
we
could
just
kind
of
fall
back
to
the
typical
election
procedures
there.
So
basically
we
just
to
re-emphasize
we'd,
prefer
the
the
dci
component
to
it
next
slide.
C
And
so
for
multi-plane
we
basically
take
among
all
of
the
top
nodes
in
a
plane.
We
declare
a
plane
id
and
that
is
the
highest
sid
from
each
of
those
planes.
Everything's
carried
in
the
no
tie
already,
so
the
election
is
distributed
across
planes,
as
you
know,
highest
plane
id
with
dci
bit
lowest
second
highest
and
same
as
before.
If
we
have
any
that
aren't
doing
dci,
we
just
fall
back
to
it
that
way,
so
this
basically
will
distribute
route
reflectors
and
the
dci
gateways
across
planes
for
some
redundancy.
C
This
one's
pretty
straight
forward
previous
scale
was,
you
know
three
fabrics,
each
with
three
evis
and
each
of
those
with
15
v
lines
a
piece.
Now
we
can
do
six
fabrics,
seven
edis
and
30
vlans
and
same
as
before.
We
can
go
higher,
but
we,
you
know
we
have
to
define
those.
You
know
how
those
are
derived,
so
they
remain
collision.
Free
next
slide.
C
And
last
but
not
least,
we
added
an
operational
section.
There
was
some,
you
know
basically
feedback
saying
this
would
be
helpful
and
you
know
that
not
only
for
single
plane
versus
multiplane
sort
of
things,
but
also
for
you
know
those
who
are
not
incredibly
familiar
with
rift
or
auto
evpn.
You
know
to
kind
of
help
them
bridge
that
gap
a
little
more
quickly.
So
there's
some
example:
topologies
in
there
that
sort
of
take
existing
terminology.
You
know
from
like
the
physical
underlay
is
a
super
spine.
How
that
translates
to
rift?
C
C
Basically,
we
folded
the
analytics
section
into
the
operational
section
and
then
finally,
a
little
bit
of
a
you
know:
quote-unquote
pics
performa,
for
this
scale
mentioned
on
the
previous
slide.
Basically,
there
is
a
table
at
the
end
of
the
document
in
the
appendix
that
you
can
basically
use
to
confirm
compliance
with
the
current
version
of
autoevpn.
C
So,
as
always,
co-authorship
comments
are
welcome,
but
for
for
next
go
around
it'll,
you
know
more
dci
examples
more
multi-plane,
stuff,
more
operational
considerations.
That's
it
from
my
end.
If
there
are
questions
next
slide
and
if
not
maybe
I
can
steal
a
couple
of
extra
minutes
to
go
through
something
that
you
guys
might
find
interesting
too.
D
Tony
here
a
quick
observation
so
as
input
from
people
playing
with
it
and
there
was
a
desire
that
the
hash
function
actually
is
delivering
some
kind
of
a
continuous.
You
know
simple
vlans
for
the
fabric
id
one
and
edi
one
is
kind
of
the
default
case,
so
I'll
be
probably
still
fiddling
with
the
hash
function
to
get.
You
know
in
fabric
id1,
ebi1
default
case.
Something,
like
you
know,
vlan
one,
two,
three,
four:
five.
Instead
of
what
do
we
have
now?
C
Yeah,
let's
jump
forward
two
slides,
so
I'm
gonna
kind
of
shift
gears
for
a
second
just
breeze
through
something
so
just
kind
of
a
quick
teaser
or
something
we're
working
on.
That's
you
know
not
directly
related
auto
vpn,
but
you
know
if
you're
interested
in
kind
of
the
true
ztp
sort
of
you
know
underlay
fabric
sort
of
provision.
This
might
be
pretty
interesting
for
you
just
next
slide.
For
me,.
C
I'm
gonna
kind
of
breeze
over
these
pretty
quickly
just
just
to
provide
some
high
level
context
as
to
what
we
were
working
on.
So
I
think
zooming
out
a
bit.
We
all
kind
of
know
that
you
know
flat
single
area
igps
come
with
pitfalls.
You
know
lots
of
flooding,
lots
of
state
lots
of
convergence,
and
this
just
gets
worse
as
the
network
scale,
but
there
are,
there
are
desirable
reasons
to
deploy.
These
sorts
of
things
like
like
sr,
makes
things
simple.
Next
slide.
C
So
one
way
we
address
that
problem
is
with
flood
reflection,
so
it's
based
on
some
existing
lsr
work.
There's
a
new
version
posted
for
the
don't
know
off-hand
when
the
meeting
is
but
there'll
be
a
new
new
one
presented
this
time,
but
the
at
a
high
level
work
a
little
bit
like
bgp
route
reflectors
and
that
we.
C
A
flood
reflector
and
we
have
you,
know
one
or
more
clients,
but
the
end
result
is
we
we
get.
We
can
squeeze
a
lot
more
scale
out
of
those
sorts
of
networks,
so
a
lot
less
state,
less
flooding.
You
know
less
spf
computation
next
step
next
slide,
so
just
for
the
visually
inclined
just
if
we
had
a
really
basic
example,
kind
of
comparing
the
two.
You
know
if
we
needed
you
know
full
mesh
of
level.
Two
adjacencies
between
you
know
tier
one
and
tier
three
right.
C
That's
the
only
real
reachability
information
we
needed
flat
single
area.
We
need,
you
know,
15
adjacencies.
But
if
you
look
on
the
right
we
have
you
you'd
only
need
eight.
So
basically
we
have
tier
ones,
establish
those
flood
reflector
adjacencies
with
those
nodes
at
the
top
are
the
flood
reflectors
and
those
nodes
at
the
bottom
are
the
or
the
clients.
C
C
So,
basically
you
know:
what's
this
got
to
do
with
auto
vpn?
Well,
we're
taking
the
same
kind
of
technology.
The
automatic
variable
derivation
and
applying
it
to
that,
so
we
figure
out
the
cluster
id,
which
is
you
know
how
we
keep
things
unique
within
the
fabric
and
then
you
know
the
the
role,
whether
it's
a
client
or
a
reflector.
So
it's
you
know
not
an
incredibly
complex
addition
to
it,
but
super
beneficial,
so
so
stay
tuned
for
that
check
out
the
check
out
the
drafts.
D
C
D
C
D
Of
you
know
in
the
same
fabric
right
so
it
it.
It
touches
the
the
base
that
extends
the
base
back
in
in
a
backwards
compatible
way.
So
you
know
the
stuff
will
run
with
base
basic
rift
as
well,
but
the
extension
will
allow
you
to
run
this
auto
dp
and
autoflood
reflection,
but
those
things
are
completely
orthogonal
to
each
other.
So
the
auto
ep
and
auto
flood
reflection
are,
you
know
independent?
You
can
run
both.
D
You
can
run
either
and
if
you
think
about
flood
reflection
depending
how
you
know
you
build
it,
you
can
actually
see
rift
just
a
day.
Zero
protocol,
because
auto
flood
reflection
will
be
able
to
even
you
know,
configure
isis
l1
and
l2,
or
you
can
just
configure
l2
and
use
rift
underneath
as
a
forwarding
protocol
will
provide
both
options.