►
From YouTube: IETF111-RIFT-20210728-2130
Description
RIFT meeting session at IETF111
2021/07/28 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
Let
me
do
the
introduction
thanks
everyone
to
participating
and
welcome
to
rift
at
itf,
111
glad
to
see
you
here
and
we'll
spend
few
minutes
providing
you
update
on.
What's
going
on
and
then
move
to
the
presentation.
A
A
A
So
from
overall
progress
and
working
group
stages,
thanks
alvaro
for
great
work
on
reviewing
and
working
with
authors
on
better
tests
version,
13
has
been
posted
and
is
going
to
be
presented
today.
Applicability
statement
is
still
in
working
room
plus
call,
and
progress
is
good.
All
the
comments
are
must
be
progress
and
jeffrey
is
going
to
shepherd
it.
A
Young
model
is
almost
ready
and
thanks
to
mikhail
vashkar
young
review,
so
we
are
going
to
progress.
It
there's
some
other
active
work,
such
as
key
registry
and
work
on
the
vpn,
as
well
as
some
going
to
work
on
segment,
routing
and
multicast,
and
if
there
are
no
questions,
we
are
ready
to
move
to
the
next
presenter.
Jordan.
D
A
A
D
Wonders
of
modern
technology-
maybe
I
start
and
if
he
fix
this
is
my
journey-
can
take
over.
D
E
Okay,
yeah,
sorry
about
that,
no
idea!
What's
going
on
one
second,
get
situated!
E
Okay,
all
right!
So
thanks
guys,
thanks
for
being
patient,
so
here
to
present
version
13..
Historically
speaking,
you
know
the
protocol
works,
it's
been
implemented
to
spec,
but
the
document
itself
still
needed
some
work.
You
know
between
alvaro
and
other
working
group
members.
I
think
we've
made
some
pretty
major
progress,
helping
this
move
forward,
so
I'll
run
I'll
run
through
this.
E
So
first
I've
been
added
as
a
contributor,
so
I've
fought
some
of
these
dragons
in
the
past,
but
I
had
the
benefit
of
essentially
having
unlimited
resources,
but,
as
we
know,
that's
not
the
case
for
most
operators.
So
you
know,
since
around
version
11,
when
I
initially
read
it,
I've
kind
of
felt
that
riff's
approach
to
these
problems
have
had
a
ton
of
merit
and
knew
I
wanted
to
contribute
ever
since.
So
since
then
much
of
the
feedback
I've
seen
has
pertained
to
readability.
E
There
were,
but
that's
where
a
lot
of
my
time
has
been
spent
beyond
that,
as
rift
has
been
going
through.
Ed
review
alvaro's
been
giving
us
some
great
feedback
in
that
area
and
others,
but
that's
where
the
bulk
of
you
know
the
collective
work
went.
E
Let's
see
so
we've
added
a
new
reader's
digest
section
so
basically
helps
the
reader
figure
out.
What
they
want
to
learn
about.
Rifts
got
some
shiny
new
svgs.
E
I
think
we're
one
of
the
first
drafts
to
use
them,
let
alone
quite
so
extensively
and
as
such
we
hit
a
couple
of
bumps
in
the
road
along
the
way,
but
we
can
go
over
that
momentarily
and
then
some
other
restructuring
items
so,
with
the
help
of
some
of
the
folks
from
the
applicability
draft,
moved
a
couple
sections
over
there
as
they
were
just
a
bit
better
suited.
E
E
So
it's
a
new
protocol.
Obviously
the
draft
is
going
to
be
pretty
big,
but
you
know
and
as
with
anything
new,
you
got
to
start
from
scratch
a
little
bit,
so
it
kind
of
comes
with
a
steeper
learning
curve
compared
to
something
smaller.
So
again,
we
got
some
great
comments,
that
kind
of
suggested
that
the
draft
might
be
a
little
difficult
to
consume.
E
So
a
bit
more
detail,
you
know
we
streamline
the
abstract
and
introduction
sections
to
better
prepare
the
reader,
for
you
know
what's
to
come,
but
again,
most
importantly,
is
that
reader's
digest
section
so
helps
them
really
understand
what
matters
you
know
whether
they're
going
to
implement
or
operate
rifts
audience
doesn't
really
matter.
It
should
fit
for
just
about
anyone,
but
what
you're
left
with
is
you
know
kind
of
a
better
understanding
of
everything
you
know
abstract
introduction,
tell
you
what
rips
about
you
know
main
benefits
and
then
the
reader's
digest
section.
E
You
know
the
reader
now
has
the
ability
to
kind
of
break
things
into
more
reasonable
chunks
or
if
they
want
to
target
a
specific
subject
yeah.
You
know
they
know
which
sections
provide
the
level
of
detail
that
they
want.
E
You
know
maybe
they're
an
operator
just
want
to
know
how
it
works
at
a
high
level,
maybe
they're
doing
something
complex.
You
know
implementing
negative
desegregation.
It's
it's
basically
choose
your
own
adventure,
but
yeah.
We
felt
it
gives
the
reader
much
better
experience
and
kind
of
command
of
the
content,
but
other
than
that
throughout
the
draft
there's
been
some
additional
references
to
keep
some
things.
You
know
just
more
cohesive
right.
E
E
So
syntax,
not
inconsistency
tax
right,
so
kind
of
keeping.
With
that
readability
trend,
we've
made
some
terminology
language
changes.
E
You
know,
consistency
changes
across
the
board,
you
know
just
avoid
any
unnecessary
confusion
and
I,
I
think
it
helps
readers,
not
second
guess
themselves
if
something
varies
even
even
slightly
right,
whether
it's
an
implied
concept
or
just
a
difference
in
capitalization,
but
you
know-
and
the
same
thing
was
said-
for
shifting
between
kind
of
first
and
third
person
point
of
view,
I
moved
everything
to
third
person
now
so
there's
more
of
a
kind
of
consistent
flow
and
experience
for
the
reader
and
next.
E
Slide,
okay,
so
the
most
visibly
noticeable
change
is
the
addition
of
svgs.
We
ran
into
some
nifty
challenges
that
we
didn't
think
of
initially,
but
you
know
a
little
bit
of
learn
as
you
go,
but
we
actually
broke
the
draft
submission
tool
a
little
bit,
so
svgs
are
obviously
much
larger
than
ascii.
So
there's
a
three
meg
limit
on
that,
and
so
we
had
to
get
it
manually
posted
the
night
of
submission
cut
off.
We
did
reach
out
to
the
tools.
E
Folks,
I
don't
think
we've
heard
back
yet
so
kind
of
as
a
side
note.
If
the
chairs
have
any
suggestions,
that'd
be
appreciated
anyway,
you
know,
there's
some
other
considerations
but
yep.
I
I
digress.
E
Most
everything
now
has
an
svg
equivalent
image.
You
know
we
think
it
helps
the
reader
tremendously
in
certain
areas,
primarily
multi-plane
fabrics
and
negative
disaggregation.
E
So
you
know,
multiplying
fabrics
are
one
of
those
things
that
you
kind
of
you
kind
of
get
it
or
you
kind
of
don't.
There's
there's
not
a
lot
of
in
between,
so
they
can
be
quite
challenging
to
really
understand.
So
you
know
a
few
of
the
images
really
help
you
kind
of
bridge
that
gap
and
help
them
understand
how
things
fit
into
rift,
which,
which
kind
of
perfectly
segues
into
the
negative
disaggregation
components.
Right
as
we
know
it's
it's
required
for
multi-plane
fabrics
and
for
the
readers
that
want
to
know
those
concepts.
E
The
svgs
are
super
helpful,
but
yeah.
If
you
look
at
the
figure
to
the
right,
that's
what
we
used
to
do
some
of
the
multi-plane
fabric
and
making
that
work
and
ascii
is
it's
not
pretty.
Believe
me,
I
I
tried
probably
spent
more
time
on
it
than
I
should
have,
but
anyway,
and
then
the
the
fsm's
are
a
lot
easier
to
parse
and
digest,
since
we
don't
have
to
kind
of
pick
apart.
E
The
ascii
diagrams
and
kind
of
a
final
note,
the
text
versions
of
the
draft-
will
still
fall
back
to
ascii.
So
you
know
we're
not
gonna.
Leave
anyone
high
and
dry
next
slide.
Please.
E
So
some
other
points
that
came
up
in
review
was
you
know,
or
what
were
we
actually
standardizing?
So
to
be
clear?
It's
it's
the
thrift
models
and
it
leaves
things
a
bit
less
open
to
interpretation.
E
You
know
other
text
in
a
sense
of
supporting
detail,
describe
how
things
work.
So
one
of
the
things
too
is
avara
mentioned.
Is
we're
still
working
on
getting
a
stable
thrift
reference?
E
I
think
tony
reached
out
to
those
guys
we're
just
giving
them
a
little
bit
more
time,
but
you
know
we're
owning
it
and
pursuing
it.
But
beyond
that,
I
just
kind
of
continuing
to
respond
to
alvaro
and
going
through
the
review
process.
So
I
think
I'm
a
couple
minutes
under
if
there
are
any
questions.
A
E
A
D
Yes,
all
the
thrift
stuff,
I
poke
the
forks
I'll
be
poking
them
steadily.
Until
I
get
you
know
some
kind
of
commitment
from
them
for
the
study
reference.
Otherwise,
yet
on
the
work
couple
of
months,
thanks
alvaro
for
actually
drilling
down
very
very
deeply
in
a
lot
of
details,
and
most
work
has
been
done
by
yeah,
pretty
much
jordan.
Pascal
and
me,
I
think,
also
rules
and.
A
B
A
E
All
right,
let's
make
sure
we
can
still
hear
me,
it
looks
like
we
can.
Okay,
yes,
we
can
okay,
shifting
gears
a
bit
so
this
time,
I'm
sharing
our
our
new
iteration
of
rift,
auto
evpn,
so
we
submitted
the
first
version
last
meeting
at
110
and
it
was
you
know,
a
little
bit
of
a
teaser
kind
of
just
describing
what
the
solution
was.
E
You
know
with
the
submission
deadline
and
everything
we
didn't
really
get
a
chance
to
fill
in
quite
as
much
as
we
wanted,
but
that's
what
we
did
this
time
by
adding.
You
know
a
lot
more
detail
into
things,
how
things
actually
work
next
slide.
Please.
E
So
very
quick
recap,
so
what's
this
auto
evpn
thing
again,
so
the
short
of
it
is
rift.
Ztp
functionality
will
build
the
underlay
and
that
actually
provides
us
with
a
lot
of
really
good
topology
information
that
we
can
use
to
derive
things
necessary,
for
you
know
bgp
and
evpn
overlay.
So
you
know
we
get
that
ztp
functionality
extended
into
the
overlay,
so
you
know
we
received
there's
lots
of
evpn
purely
for
the
sake
of
stretching
layer.
E
E
Okay,
so
what's
actually
new
in
version
one
so
much
like
the
main
spec
we're
considering
the
thrift
model
to
be
normative,
we've
got
some
variable,
derivation
procedures.
So
previously
again
we
just
had
simpler
verbiage,
but
now
we
point
to
actual
algorithms
there's
some
scale
considerations
we'll
get
into
in
a
sec
and
then
something
I
find
particularly
interesting,
auto
evpn,
analytics
and
same
as
mentioned
above,
where
that's
also
gonna
be
a
normative
model.
It's
a
little
bit
noteworthy.
It's
also
the
first
major
use
of
risk.
Key
value
store.
E
Okay,
a
little
bit
more
about
the
model
and
kind
of
what
it's
describing,
so
the
model
itself
contains
all
the
necessary
variables.
You
know,
data
types
and
so
forth
that
we
use
to
build
the
bgp
sessions
and
the
mac
vrs
themselves.
So
just
you
know
brief
examples:
right,
lootback,
ips,
cluster
ids
route
targets,
vlans
vni's,
so
forth.
E
There
is
reliance
on
a
couple
of
modifications
of
the
line
tie
schemas
from
the
main
spec.
Those
were
mentioned
in
the
original
version,
but
just
they
essentially
define
interoperability
between
nodes
that
can
run
auto
evpn
nodes
that
can't
next
slide.
E
So
just
a
brief
example,
like
I
mentioned,
this
is
just
one
of
the
example
algorithms
for
how
route
reflectors
are
elected
but
similar
algorithms
are
present
for
for
the
other
variables
next
slide.
Please.
E
Okay
couple
scale
considerations:
we,
we
kind
of
had
our
default
set
to
do
one
fabric,
one
edi
with
seven
vlans.
E
This
version
of
the
draft
sets
the
max
to
three
fabrics
with
each
each
having
three
evis
and
15
vlans
a
piece
there.
You
know
it's,
it's
not
that
it
can't
scale
beyond
this
can,
but
you
know,
additional
mechanisms
would
have
to
be
defined,
describe
how
to
keep
vlans
from
colliding
just
one
example
right
whether
viewing
can
stretch
across
fabrics
or
not
next
slide,
okay,
so
the
analytics
piece.
So
this
version
introduces
what
we're
calling
auto
evpn
analytics.
E
E
E
So
digging
a
bit
deeper,
we
re
reserved
two
key
types
from
the
kv
registry.
One
identifies
kind
of
global
attributes
in
another
macbrf,
so
the
global
key
type
will
define
the
the
auto
evpn
nodes
role
itself,
so
auto
evpn
leaf,
for
example,
as
well.
As
you
know,
the
number
of
operational
peers
and
the
number
of
total
configured
peers.
E
So
I
from
just
the
top
you
get
the
ability
to
see
you
know,
eat
every
leaf's,
bgp
state
and
the
the
other
key
type
identifies
mac,
vrf
details,
so
the
number
of
operational
ce
interfaces,
as
well
as
the
total
and
kind
of
help.
You
understand
where
you
know
your
services
related
state
what
it
looks
like
downstream
of
a
leaf
the
you
know,
the
number
of
operational
irb
interfaces
as
well
same
thing,
total
totals
included.
You
know,
get
a
little
bit
more
understanding.
E
You
know
reachability
and
routing,
and
then,
given
that
evpn
is
data,
plane
driven
a
view
of
both
type
two
mac
and
type
two
mac
ip
routes.
Give
you
a
bit
more
insight
into
that
piece
of
it.
You
know
did
did
someone
just
advertise
half
a
million
max
into
the
fabric,
etc.
You
know
just
helps
you
look
out
for
outliers,
so
there's
some
other
identification
information
as
well.
E
How
many
vlans
are
configured
the
name
of
the
mac
brf
and
a
description
for
where
you
know,
maybe
that
name
doesn't
describe,
or
at
least
describe
well
what
the
service
really
is.
You
know
I
don't
know
being
able
to
see
those
factors
in
a
kind
of
quick,
condensed
view
all
from
the
top.
You
don't
have
to
log
into
multiple
devices
with
something
we
thought.
Operators
would
find
beneficial
and
next
slide.
E
Okay,
so
what's
next
co-authorship
and
comments
are
still
welcome.
The
next
revision
will
have
a
lot
more
detail
around
type,
5
routes
and
last,
but
certainly
not
least,
as
we're
asking
for
adoption
both
for
this
draft
and
the
key
value
registry
next
slide,
and
if
there
are
any.
C
A
D
Sure,
well,
I
hope
the
lsr
is
not
sabotaging
our
mics
or
something
just
joking
for
the
auto
edp
and
two
observations:
the
one,
the
maximum
numbers.
We
can
flip
back
to
this
view
graph,
wherever
it
was
the
maximum
numbers
you
can,
you
can
derive
you
want
to
flip
back.
So
people
have
context.
D
B
D
D
Between
maximum
and
defaults,
so
the
defaults
currently
are
you
derive
it
on
a
fabric
of
course,
so
the
fabric
is
not
really
a
default.
It's
just
the
number
one
fabric
is
the
default,
and
I
think
the
default
currently
stands
at
three
ddis
and
7d
lands.
And
what
do
the
maximum
mean?
The
maximum
does
not
mean
that
that's
the
biggest
config
that
you
can
generate
automatically,
but
what
we
did
when
we
provide
the
algorithm
we
tested
that
up
to
three
fabrics
generating
on
each.
You
know:
fabric
three
evis
and
in
egvi
15d
lands.
D
All
the
derived
values
are
collision
free.
So
in
the
sense
you
know,
the
maximum
here
means
you
can
implement
it
and
use
those
algorithms
up
up
to
these
values
and
everything
will
be
collision
free
and
from
there
on.
We
don't
consider
you
know
it's
important
or
you
know
relevant,
practically
speaking,
to
check
father.
D
So
that's
first
observation
and
then
on
the
analytics.
When
you
go
and
look
at
the
key
value
store
analytics,
I
don't
know
which
view
graph.
That
was
eight.
E
D
B
E
D
Those
chairs
are
slow
today,
all
right.
So
if
you
look
at
the
you
know
the
global
analytics
stuff
or
even
the
per
mac
vrf
or
you
have
a
lot
of
stuff.
You
ask
yourself
well,
but
lots
of
stuff
isn't
advertised
like,
for
example,
you
know
loopback
of
the
note,
which
is
also
autoderived,
but
the
trick
is
that
the
top
has
all
the
information
already
about
the
nodes
participating
to
be
able
to
derive
all
those
values
itself.
So
there
is
no
point
of
sticking
them
in
key
values.
D
So
if
you
want
to
see
the
status
of
the
fabric-
and
you
want
to
see
all
the
loopbacks,
you
don't
have
to
flood-
that
you
can
just
run
the
algorithms
proxy
for
all
the
involved
nodes
and
you
will
get
the
information,
that's
why
we
actually
do
not
flood
a
lot
in
the
key
value
store.
Most
of
the
stuff
can
be
derived
at
any
point
in
the
fabric
you
know.
Well,
actually
you
would
look
at
the
top
because
it
has
all
the
information.
A
C
F
F
Okay,
so
I
have
a
simple
question,
so
I
haven't
read
the
draft
just
yet.
My
my
first
part
of
the
question
is:
am
I
us
correctly
assuming
what
this
is
always
creates?
Essentially
a
single
evpn
service
per
fabric
and
a
single
broadcast
domain?
And
the
second
part
of
his
question
is
whether
you
want
where
you
specify
a
specific
type
of
vpn
service,
so
whether
it's
vlan
based
or
v1,
bundle
or
will
have
a
bundle
or
it
can
be
any
type
of
evpn.
F
D
Okay,
I'll
answer
so
the
first
question:
yeah
his
mic
died
again.
I
don't
know
what.
D
Seems
to
be
pay
as
you
go
all
right,
so
the
first
question
was
whether
you
have
a
single
broadcast
domain.
No
you
don't.
The
auto
evpn
derives
as
many
evis
as
you
want.
So
currently,
the
default
in
the
draft
is
three,
but
we
test
that
I
don't
remember
up
to
seven
evis
on
the
fabric
which
are
collision
free
and
within
each
of
these
evis.
It
derives
seven
vlans
and
some
of
them
can
be
stretched
across
fabrics
and
some
not
now.
D
What
kind
of
service
you're
running
on
this
thing
is
up
to
you.
In
a
sense,
we
do
not
specify
how
you
do
trunking,
because
the
trunking
is
not
clear
right.
So
an
implementation,
for
example,
choose
to
listen
on
interfaces
and
see
that
there
is
no
l3
running
on
it
and
that
basically
chooses
a
trunk
interface,
and
then
you
define
only
what
kind
of
service
you
want,
what
you
get
from
auto
ebp
and
is
basically
an
edi
and
the
vlans
derive,
and
then
how
you
bundle
them.
D
What
you
do
with
them
is
not
specified
by
autoevpn.
It's
interesting
discussion
with.
We
should
be
going
into
that.
The
problem
is
that
those
things
are
very
harder
specific.
D
What
kind
of
service
models
are
supported
on
different
hardware
platforms?
So
I
don't
think
we
will
find
a
solution
here.
Maybe
we
should
derive
a
certain
amount
of
evis.
You
know
providing
a
certain
service
type
and
define
that.
D
A
D
Yes,
because
that's
what
pretty
much
all
the
hardware
supports
right,
but
if
you
want
the
vl
and
bundle
service
I
mean
we
can
write.
The
draft
in
a
way
saying
like,
for
example,
derive
the
third
edi
as
a
vlan
bundle.
Let's
engage
on
the
list,
it's
a
good
observation,
but
yes,
we
implicitly
today,
frankly
implementation
wise,
pretty
much
everything
supports
vlan,
aware
and
that's
what
we're
doing.
C
C
If
we
go
talk
about
this
concept
in
the
in
the
best
working
group,
how
how
will
people
there
understand
this
autoeuvpn
concept.
D
Up
to
me
to
answer
so,
it
was
already
presented
last
itf
in
the
in
the
best
working
group,
and
you
know
the
concept
are
pretty
clear
to
people.
Is
that
stuff
very
specific?
No
and
yes,
why?
No-
because
this
is
basically
a
certain
deployment
model
which
is
called
the
ebr.
You
know
rr
ibgp
model,
which
is
very
common,
so
everybody
understands
this
kind
of
model.
It's
very
you
know
popular
and
implemented
by
all
the
vendors.
D
So
in
the
sense
it's
like
it's
just
instead
of
manually
doing,
you
know
lots
and
lots
of
configuration.
This
thing
just
automatically
pops
up
configuration
for
you.
Yes,
because
you
need
to
place
the
correct
nodes
in
the
correct
place
in
the
network
and
only
rift
has
enough
topology
understanding
to
do
this.
So
as
a
simple
example,
the
route
reflectors
are
placed
at
the
top
of
the
fabric.
Normally
and
rift
has
all
the
information
to
understand.
Where
is
the
top
of
the
fabric
and
put
these
things
on
top
of
the
fabric?
Now?
D
Could
other
protocols
place
it
somewhere
else?
Yes,
they
could.
You
could
possibly
build
isis
to
support
that,
but
then
you
know
like
the
leafs
are
at
the
bottom
of
the
fabric.
Isis
has
no
concept
of
a
bottom,
so
how
will
you
figure
out?
Who
the
leafs
are
right?
It's
almost
impossible
to
tell
isis
is
just
has
no
sense
of
direction
and
the
other
part
is
analytics.
But
there
is
nothing
particular
you
know
terrific.
D
D
What
we're
doing,
but
yes,
because
other
protocols
do
not
have
enough
topology
understanding
to
be
able
to
derive
the
correct
configuration
on
the
correct
nodes
unless
they
are,
of
course,
you
know
heck
to
put
a
lot
of
concept
in
at
which
point
in
time
to
start
to
look
to
look
like
rift
by
some
other
name.
You
know,
conceptually
speaking
just
by
different
encodings
and
mechanism.
C
Oh,
thank
you.
So
my
second
question
is:
I
think
you
mentioned
that
there
are
certain
features
we
couldn't
do,
because
we
don't
know
what
the
intention
is.
So
you
couldn't
derive
things
like
trunking
mode
or
whatever,
so
is
it?
I
assume
it
would
be
possible
to
have
mixed
autoevpn
and
then
non-auto
evpn
together
in
the
same
deployment.
D
Yeah,
absolutely
I
mean
it's
just
bgp,
you
just
set
up
more
session
and
you
put
more
apis
in
you
know.
It's
really
implementation
specific.
D
D
You
know
with
predefined
vlans
in
broadcast
domain
and
so
on,
which
is
an
interesting
offering
in
enterprise
space.
The
other
solution,
of
course,
having
a
controller
doing
all
of
the
stuff,
which
is
more
of
a
day,
one
config
right.
This
is
more
like
a
day,
zero,
config
controller
being,
of
course,
more
flexible
and
allowing
you
know
asymmetrical
deployments.
This
stuff
is,
in
a
sense,
completely
symmetrical
right.
It's
a
one-size-fits-all!
D
You
get
what
you
get
here.
If
you
don't
like
it?
Well,
you
know
bad
luck.
If,
if
you
put
in
too
many
knobs
pretty
soon,
it's
not,
you
know
ztp,
it's
basically
a
very
complicated
command
line,
so
it
depends
what
you're
interested
in
right,
but
we
don't
preclude
on
a
note
having
a
mix
implementing
and
you
know
a
node
implementing
something
where
beside
the
autovpn,
the
normally
vpn
is
also
being
run.
I
mean
we.
E
D
C
And
should
we
move
on.
A
B
D
A
D
Okay,
yeah
resize
the
browser
and
keep
it
in
the
mode
where
you
have
the
participate
on
the
left
and
the
presentation
on
the
right,
and
you
will
see
the
bulls
slide.
At
least,
I
think.
B
B
B
B
B
B
B
That's
all
for
the
problem
and
the
solution
we'd
like
to
know
does
this
problem
need
to
be
solved
and
if
there
is
any
other
solution
for
it
and
it
comes
welcomed
and
and
and
I
we
have
received
some
comments
from
tony
and
we
discussed
in
american
list,
if
you
have
interest
interesting
at
you
can
look
at
the
mailing
list
and
for
now
we
are
looking
for
more
comments.
B
D
Okay,
since
the
chairs
are
asleep,
I
jumped
the
mic
twenty
pg
reaper.
So
can
we
flip
back
to
the
second
geographies
okay?
So
I
think
I
gave
a
comment
on
the
list
that,
if
you
don't
do
anything
rift
will
work
fine
per
the
right
part
right,
the
leaf
where
it
basically
builds.
D
And
there
is
a
very
good
observation
from
sandy
that
when
you
break
a
link-
and
you
have
to
renegotiate
the
hierarchy,
then
of
course
new
adjacency
need
to
be
formed.
So
if
you
lose
a
link
between
the
gateway
and
an
a
then
this
a
will
fall
under
the
bottom,
a
hierarchy
wise
which
will
work,
but
it
will
of
course
interrupt
the
traffic
flow.
So
that's
that's
a
good
observation
itself
and
then
to
the
solution
that
sandy's
suggesting
next
next
view
graph.
D
Okay,
so
there
is
two
problems
here
right,
so
the
first
observation
is
that
there
is
no
north
type
ties
being
sent
across
a
horizontal
link
below
top
level,
although
we're
not
talking
to
off.
Let's,
let's
take
the
tops
out
of
the
equation.
So
when
you
have
leaves
horizontal
links,
horizontal
links
on
leafs
talking
to
each
other,
you
will
only
send
the
south
ties
to
each
other,
basically
to
attract
traffic
from
one
to
the
other
right,
because
right
now
leave
to
leave
you
don't
propagate
the
southbound
farther.
D
So,
yes,
we
could
extend
the
protocol
and,
like
I
told
you,
we
basically
start
to
be
built
our
ip
right.
The
lo6
sends
to
lo5
and
lo5
sends
to
l04,
but
it
sends
us
to
lo3
and
then,
if
you
find
the
shorter
metric-
and
it
will
lead
to
all
the
counting
to
infinity,
if
you
have
complex
breakages
like
an
rip,
but
it
can
be
done
and
it
will
not
re-establish
the
adjacency.
D
But
you
have
a
second
problem.
The
l1
and
lo3
will
not
advertise
d4
routes
because
there
are
the
leaves
and
they
have
no
southbound
neighbors.
So
they
do
not
generate
a
d4
out,
so
the
lo6
will
get
the
lo3
prefix,
but
it
will
not
get
the
default
necessary
to
forward
into
the
rest
of
the
fabric.
So
we
would
somehow,
in
those
extensions,
also
change
those
rules
which
is
doable
so
overall
yeah.
D
We
will
have
to
reinvent
our
ip
on
this
kind
of
topology
to
solve
the
problems
that
level
negotiation
when
the
level
different
level
is
negotiated,
the
link
is
being
torn
down.
We
could
also
look
also
at
that
in
more
detail,
but
I
do
not
think
that
it
will
be
very
fruitful
because
it's
very.
D
So
those
are
my
two
observations
right,
the
first
one
that
rift
works
already,
while
the
breakage
is
will
depending
where
the
bracket
is,
but
the
breakage
will
may
bring
down
the
adjacency
and
bring
it
up
again
and
the
second
one
is
that
we
would
have
to
change
the
default
advertisement
rules.
And
yes,
we
only
do
the
prefix
cell
ties,
which
is
enough
to
run
our
ip
on
on
this
kind
of
ring.
B
B
A
B
I
guess
we,
while
we
talking
this
topic,
is
when
we
talk
rift
with
our
customers.
They
think
that
we
should
do
something
to
research
to
for
the
depo,
the
sorry
for
deployment.
B
D
Here's
another
observation
sandy
because
of
course
I
dealt
with
this
kind
of
discussion
as
well.
It
is
very
easy
to
redistribute
rift
back
and
forth
into
other
protocols,
just
like
another
protocol
so,
and
I
had
it
also
in
different
contexts
with
bgp.
You
could
just
take
on
l01
and
lo3
and
just
redistribute
the
rift
did
for
route
into
an
rip
and
just
run
an
rip.
Lo
1
lo4
lo5,
lo
6
lo3,
also
very
easily
done
you
that
also
solves
the
problem.
If
lo4,
lo
f5,
which
are
not
even
rift
capable.
B
D
You
can
deploy
whatever
you
want
right,
it
doesn't
really
matter
any
any
dynamic
protocol
will
will
do
so.
Okay,
I
mean,
if
you
really
want
just
a
single
protocol
and
on
breakages
you
insist,
you
don't
want
to
change
topology
and
you
insisted
on
breakages.
You
cannot
have
a
link,
no
traffic
interruption,
then.
Yes,
we
would
have
to
add
something
like
that.
If
all
those
things
are
non-negotiable.
D
C
Okay,
tony
there's
a
question
to
you:.
A
From
sergey,
I'm
not
sure
whether
his
mic
is
working,
but
he
is
asking
the
customer
whether
the
primary
reason
for
customers
to
ask
for
it
is
because
of
its
auto
configuration
capabilities.
D
So
sandy
can
answer
where
you
know
discussions.
I
can
answer
for
my
discussion
so
right,
so
my
discussion
went
along
the
lines
that
the
metros
are
changing
to
claw
for
a
lot
of
reasons
and
5g
are
slower
to
go,
and
the
rings
actually
have
quite
a
lot
of
undesirable
properties.
For
example,
the
longer
you
make
it,
the
more
you
delay
becomes
non-uniform
and
and
and
longer
right.
So
the
discussion
goes
often
towards
like
why?
Don't
you
build
a
closet,
much
more
desirable
property?
D
Besides
redundancy
also
uniformity
right,
but
if
they
want
you
know
the
ring,
then
I
found
that
it's
not
a
big
concern.
If
I
tell
them
look
rift
works,
it
just
builds
a
hierarchy
that
you
don't
see
and
the
discussion
topic
that,
when
a
link
breaks,
it
may
need
to
renegotiation
of
hierarchy
and
you
have
a
traffic
interruption.
Frankly,
I.
B
Side,
yes
and
the
operators
think
that
if
the
topology
cannot
be
changed
and
the
new
technology
like
drift
can
be
used,
they
think
it's
rich,
but
if
they
they
want
to
use
drift
and
they
must
change
the
topology.
They
may
think
that,
oh
it's
it's
two
changes
for
the
topology,
so
they
may
not
want
to
update
it
so,
but
but
I
think
it
still
needs
more
discussion
because
the
network
changes
may
bring.
Some
may
bring
many
big
changes
for
the
topology,
so
anything
can
happen
right.
A
I've
seen
I
mean
any
tier
one
today
you
look
in
the
u.s
is
trying
to
build,
live
spine
network
disaggregating
and
a
lot
of
stuff
is
in
rings,
and
you
need
to
cut
rings
to
build
physically
explained
topologies,
so
there's
definite
transition
period
where
the
bottom
part
is
a
ring,
because
this
is
how
we've
been
building
network
in
optical
layer.
It
was
20
30
years
right.
A
D
D
D
C
So
apparently
we
have
people
from
zte
interested
in
working
on
this.
I
guess
they
can
at
least
they
can
continue
their
exploration
and
then
a
figure.
C
Make
their
solution
more
robust
and
address
the
concerns
that
so
far
tony
has
raised,
and
I
see
if
we
can
reach
a
level
where
the
working
group
can
consider
consider
it
should
be
adopted
not,
but,
as
initially
at
least,
I
think
you're
always
welcome
to
to
continue
the
the
work
as
as
individual
document
right.
That's
how
I
see.
C
A
So
sandias.
A
Let's
see
whether
there's
enough
critical
mass
so
anyway,
please
continue
working
on
this
again.
From
my
perspective,
I
see
it's
valid
problem
statement.
It
does
exist
right,
so
if
we
can
gather
critical
mass
would
be
better.
Obviously,
if
working
group
supports
you,
you
work
together.
If
not,
you
could
continue,
and
eventually,
when
drive
becomes
more
mature.
As
for.
A
Now
yeah
we're
out
of
time
standing.
Thank
you
for
presenting,
and
so
please
follow
up
on
the
send,
an
email
and
we'll
try
to
gather
working
group,
consents
and
see
what's
going
on
here
and
respectively.
Please
continue
working.