►
From YouTube: IETF113-BESS-20220321-0900
Description
BESS meeting session at IETF113
2022/03/21 0900
https://datatracker.ietf.org/meeting/113/proceedings/
B
Okay,
so
let's
get
up
here,
it's
10
am
europe
time
now,
so
welcome
everyone
to
this
hybrid
etf.
B
So
we
will
start
with
our
chair,
slides
so
jorge
is
helping
us
locally
on
site
to
manage
via
my
cue
in
case
there
are
some
comments,
so
thank
you
jorge
for
doing
that.
B
B
Status
updates,
we
have
one
rfc
that
has
been
published
since
last
itf,
which
is
about
the
operational
aspect
for
proxier
in
evpn
environments.
B
So
I
think
the
igmp
mld
proxy
draft
is
quite
close
to
to
the
end
and
the
distribution
are
progressing
well
and
there
are
still
couple
of
documents
that
have
been
that
haven't
been
processed
yet
by
the
ad.
B
We
have
currently
four
documents
that
are
under
shepherd
with
you,
so
on
the
evpn
unequal
cost
load
balancing
we
sent
a
request
to
idr
shares
a
couple
of
months
back
if
I'm
not
mistaken,
to
get
some
review,
especially
because
there
was
some
discussion
about
this
load,
balancing
community
and
so
on.
So
we
really
need
to
ensure
that
we
are
that
we
agree
on
our
on
the
solution,
so
it
will
be
good
to
have
the
feedback
from
or
at
least
via
agreement
of,
idr
shares
in
this
one.
B
Evp
and
fxe
and
mhpa
I
have
provided
a
review
to
the
offers.
I
know
that
some
documents
have
been
updated,
so
I
just
need
to
to
read
the
updated
version
again
to
check
that
all
the
comments
have
been
addressed.
B
We
have
currently
product
two
documents
that
are
ready
for
working,
replace
call.
We
have
the
evpn
resident
multicast
source
and
we
have
here
bgps1
document
from
from
linda
as
well.
B
B
We
did
the
last
call
for
the
evpn
emultioning
split
horizon
document
again
on
this
one.
We
are
still
missing
some
ipr
for
feedback
from
co-opers.
B
So
maybe
jorge,
I
think
you
are,
I
think
you
are
managing
this
document
correct.
B
A
B
Okay,
working
group
document
update,
so
we
will
not
go
through
through
all
the
draft.
A
few
things
that
I
wanted
to
highlight
so
on
the
draft
itf
best
bgp
multicast
controller.
B
Evpn
genius,
I
think
we
still.
We
still
wait
for
the
first
tour
to
update
the
draft
to
be
able
to
move
the
document
forward.
B
A
D
B
We
we
can
check
again,
but
I
I
think
there
was
still
some
comments
after
the
last
version
that
have
that
has
been
published.
So
if
you
can
cross
check
on
your
side
and
confirm
that
everything
has
been
updated,
then
we
can
probably
move
forward.
Okay,.
C
We
also
have
a
bit
of
a
dependency
issue,
I
think,
between
this
and
the
the
geneve
drafting
the
uv
vpn
drafting
in
mvo3,
which
was
kind
of
small
due
to
lack
of
lack
of
review.
D
Oh
okay,
I
I
saw
geneve
already
done
right,
so
it's
not
done
yet
in.
C
No,
it's
not
done
because
we
didn't
get
any
comments
on
it.
We
need
to
get
more
review
on
it.
It's
very
quiet
over
there.
A
Yeah,
I
also
had
a
question
about
the
evp
and
ipvpn
interworking
draft,
so
we,
the
the
trap,
is
going
to
expire
soon.
So
we
we
plan
to
refresh
it
and
add
some
minor
changes
that
we
discussed
among
the
authors
and
once
we
do
that,
do
we
have
any
any
dating
in
mind
for
that
discussion
with
the
idr
chairs
happening.
B
A
B
A
There
was
a
what
I
remember:
there
was
an
email
from
sue.
I
replied
with
with
my
comments
and
that's
all
I
remember
okay,
so
there's
a
comment
here
from
keur.
E
Yes,
patel
arcus
and
I'm
one
of
the
idr
chairs,
so
stefan
I
will
make
sure
we
will
take
it
back
to
the
idr
and
the
chairs.
Will
I
will
poke
chairs
and
get
you
the
feedback
yeah.
B
Yeah,
because
there
was
a
couple
of
really
important
points
that
we
need
to
to
clarify
in
terms
of
our
internal
process,
because
the
document,
for
instance,
if
I
remember
correctly,
is
defining
for
rules
some
rules
about
aggregation
of
of
some
attributes
and
so
on,
but
moving
forward.
We
really
need
to
ensure
that
we
have
the
right
process
because
for
each
new
attribute,
which
is
defined,
there
is
a
requirement
to
define
what
are
the
aggregation
rules.
E
A
A
So
good
morning,
everyone,
my
name-
is
jorge
rabalam.
I'm
presenting
this
draft
about
evpn
vpws
gateway
solution
on
behalf
of
my
authors
next
night,
please,
so
we
are
going
to
talk
about
three
things
here.
So
following
pretty
much
the
the
outline
of
the
draft,
so
the
first
part
is
we'll
talk
a
little
bit
about
what
evpn
vpws
interconnect
is
and
why
we
are
talking
about
service,
interworking
or
service
gateway,
service
gateway
solution
in
this
draft,
then,
we'll
briefly
talk
about
the
extensions
that
we
are
defining
in
the
draft.
A
A
This
is
a
draft
about
how
to
interconnect
evpn,
vpws
services
or
in
other
words,
how
to
have
an
evpn,
vpws
expan
spanning
multiple
domains
where
each
domain
can
be
an
igp
instance
or
an
autonomous
system,
and
typically
this
is
for
high
scale.
A
So
looking
at
the
all
the
different
options
that
we
have
for
evp
mvpws
into
domain,
we
in
the
draft
we
classify
the
solutions
in
three
groups,
so
the
first
group
is
what
we
call
the
service
interworking
solution
or
service
gateway
solution.
The
second
group
is
what
we
call
the
inter
domain
option
b
solution
and
the
third
one
is
what
we
call
the
transport
interworking
solution.
A
So
the
three
solutions
are
illustrated
here
in
this
slide,
so
the
the
first
one
is
the
service
interworking
solution.
In
the
example,
you
have
three
domains
and
two
border
routers
connecting
those
domains.
So
in
this
solution,
basically,
we
instantiate
a
vpws
service
on
the
border.
Routers,
the
80
per
evi
route
for
the
evpn
vpws
service
is
advertised
from
the
igrisbe
it's
imported
and
processed
by
the
border.
Router
2
and
basically,
the
the
route
is
distribu
redistributed
into
the
domain.
A
A
This
would
be
the
case.
This
is
a
typical
case
with
mpls,
but
that
would
be
also
the
case
if
you
have
a
vxlan,
dni
or
even
potentially
a
service
x
as
well.
The
third
group
is
the
the
one
at
the
bottom
and
what
we
call
the
transport
interworking
solution.
A
In
this
case,
you
may
notice
that
the
the
route,
the
80
preview
route
issued
by
the
eagus
p,
goes
all
the
way
up
to
the
ingress
p.
That
route
is
not
processed
by
the
border
routers.
A
You
can
obviously
have
a
control
plane
route
reflectors
in
between,
but
the
there
is
no
inline
route,
reflectors
processing
the
the
routes
or
doing
any
any
swap
operation
with
the
with
the
labels,
and
in
this
case,
if
the
domains
they
have
different
encapsulations
like
in
the
example,
the
only
rule
is
that,
obviously,
since
there
is
no
border
router
in
in
the
middle
processing,
the
the
route,
the
egress
p
and
the
ingress
p,
they
must
have
the
same
encapsulation
next
slide.
Please.
A
So,
in
the
draft,
what
we
are
doing
is
basically,
we
describe
the
three
groups,
and
what
we
are
saying
is
that
the
three
solutions
are
perfectly
valid,
but
if
you
have
the
requirements
that
we
represent
here
in
the
table,
the
service
interworking
solution
is
probably
the
the
ideal
one
and
those
requirements
are,
for
instance,
if
you
want
to
have
per
domain
evpn
multi-homing
capabilities
of
per
domain
must
withdraw
or
you
want
to
to
provide
the
ability
to
translate
rds
rts
tags
or
l2
attributes.
A
A
So,
based
on
that,
basically
we
are
extending
the
procedures
in
evpn
vpws
to
handle
this
inter-domain
scenario.
This
is
the
service
gateway
concept
is
already
defined
in
rfc
9014
for
evpn
multi-point.
This
is
pretty
much
extending
the
procedures
for
evp
and
vpws
routes
and
all
the
procedures
in
the
draft.
They
refer
to
what
we
call
redistribution
and
redistribution
here
means
all
the
procedures
that
involve
three
things.
So
the
first
thing
is
the
reception
and
process
of
the
evpn
route
that
is
coming
from
the
source
domain.
A
The
second
one
is
the
programming
of
the
forwarding
path
and
the
third
one
is
the
re-advertisement
of
the
route
to
a
different
domain,
which
is
what
we
call
the
next
destination
domain,
so
the
for
the
first
one,
the
reception
and
process
of
the
routes.
Basically,
we
follow
the
rfc
8214
and
we
extend
that
with
the
d-path
that
we
we
use
in
this
type
of
scenarios
for
loop
prevention
and
also
for
best
path.
Selection.
A
The
the
forwarding
state
programming
is
basically
we
receive
a
route,
we
program,
the
the
received
label
or
vni
or
sed.
We
allocate
a
new
label
vni
or
set,
and
we
re-advertise
that-
and
we
program
this
a
switching
operation
between
the
two
and
the
third
part
is
the
re-advertisement
of
the
routes.
So
in
the
draft
there
are
certain
rules
that
you
need
to
comply
with.
A
Usually
you
will,
when
you
re-advertise,
you
use
different
route
distinguishers
to
provide
enough
diversity
in
the
in
the
in
within
the
domain.
You
can
use
the
same
or
different
route
targets
and
and
ether
tags.
A
We
use
esi
zero
unless
you
define
an
interconnect,
ethernet
segment,
as
we
will
see
in
the
next
slide,
you
can
regenerate
the
layer,
2
attributes,
which
includes
the
control
word,
signaling
the
flow
label
and
also
the
mtu,
the
p
and
the
b
flags
that
we
use
for
multi-homing
are
not
propagated,
but
they
are
regenerated
based
on
the
interconnect,
ethernet
segment
state
and
we
yeah.
We
also
describe
some
other
rules
like
the
propagation
of
communities
and
also
how
you
update
the
d-path
attribute
next
slide.
Please.
A
A
So
here
the
idea
is
when
we
received
the
routes
from
the
egress
p
in
this
example
in
domain
three,
that
route
is
imported
by
the
border
routers
or
those
service
gateways,
21
and
22,
and
they
are
redistributed
in
the
into
the
domain
too,
with
the
same
ethernet
tag
identifier,
so
the
border
routers
11
and,
I
should
say
12
at
the
bottom:
basically,
they
they
do
best
pass
selection
and
they
pick
up
one
of
the
of
the
two
and
they
re-advertise
or
redistribute
the
the
route
into
the
main
one,
with
the
same
ethernet
tag
as
well.
A
A
The
other
solution,
which
is
a
bit
more
sophisticated,
is,
is
what
we
call
the
vpn
full
evpn
multi-homing
with
the
interconnected
ethernet
segment.
The
interconnect
ethernet
segment
is
something
that
we
defined
in
the
rfc
9014
only
now
extended
for
evpn
vpws,
and
this
is
a
full
ethernet
segment
construct.
A
So,
basically,
you
can
define
all
active
or
single
active
multi-homing.
You
have
properties
like
a
mass
withdrawal,
aliasing
backup
and
it's
all
happening
within
the
the
context
of
the
domain,
so
the
ad
per
es
routes
are
not
propagated.
They
are
consumed
within
the
domain
by
the
service
gateways.
A
So
and-
and
this
is
the
more
powerful
solution
providing
on
a
per
you
know-
on
per
flow
load
balancing
if
you
want
it
for
all
active
next
slide,
please
so
next
steps
for
this
draft
is
basically
we
are
seeking
for
feedback
from
the
working
group
and
and
yeah.
We
wanted
to
hear
if
this
is
useful
and
and
eventually
we'll
request
a
working
group
adoption
any
comments
or
questions.
F
Yes,
I
hi
himanshu
from
siena.
Is
this
the
service
gateways
based
on
the
vpws
l2
vpn
survival,
switching
type,
almost
the
same
concepts
right?
It's
a
service
gateway
solution
for
evpn,
vpws
yeah.
A
It's
called
eppm
vp,
vpws
gateway,
yeah,
yeah,.
F
F
F
Right
so
the
it
is,
it
is,
and
it
is
it
is.
I
think
I
I
I
feel
this
is
similar
to
the
surah
wire,
switching
and
multi-segment
pseudo
wire
right.
The.
F
A
Okay,
so
you're
saying
the
service
interworking
term
means
something
else
that
in
the
past
created
some.
B
C
F
G
G
The
comment
is
that
on
the
agenda,
this
document
has
another
name
sure.
So
there
are
quite
a
number
of
people
that
hasn't
been
able
to
prepare
the
meeting
and
if
you're,
only
requesting
more
feedback.
I
think
it's
fine,
but
if
you're
saying
that
this
is
ready
for
working
group
adoption,
then
I
think
you
should
hold
that
off
a
bit
and
allow
us
to
actually
read
the
document
within
youth
with
new
file
names.
A
Sure
and
yeah
I
yeah
my
apologies
again
because
we
we
changed
the
the
name
of
the
draft
at
the
very
last
minute
before
posting
the
draft
and
yeah
I
forgot
to
to
update
the
chairs
so
that
that's
why
it
was.
It
was
not
the
right
name
on
the
agenda
and
yeah
we're
not
requesting
for
working
group
adoption.
Yet
I
mean
this
is
draft
zero,
zero.
So
for
the
moment
it's
just
feedback.
A
H
A
A
A
I
mean
what
we
are
saying
here
is
that
we
recommend
the
the
road
distinguisher
rewrite
yeah,
okay,
because
that
is
giving
you
a
pad
diversity
across
domains
right.
It's
problematic,
you'll
and
mail.
A
Yeah,
okay,
this
draft
is
was
already
presented
in
last.
Ietf
is
a
revision01.
A
It's
called
the
domain
path
for
ethernet
vpn,
so
we'll
talk
about
a
short
refresh.
What's
new
in
the
draft,
the
next
steps
so
next
slide.
Please
yeah
domain
path
is
defined
in
this
evpn
ipvpn
interworking
draft
and
that
graph
is,
is
used
for
layer,
three
routes,
meaning
ipvpn,
pc
and
pgp
routes,
and
you
know
40
vpn
routes,
35
and
routes,
type
2
in
the
symmetric,
irb
model
and
yeah.
This.
A
This
trap
is
basically
modified
by
service
gateways
along
the
way
and
is
used
for
control,
plane,
loop
protection
and
best
path,
selection,
yeah.
There
are
some
procedures
related
to
it.
So
next
slide
so
in
this
draft.
Basically,
what
we
are
doing
is
extending
the
use
of
the
path
also
for
evpn
routes
that
are
not
used
for
layer
3,
but
also
for
the
rest
of
the
capabilities
so
and
just
like
in
the
evp
and
ipvp
and
interworking
draft.
This
is
used
for
loop
protection
on
the
gateways
and
also
provides
traceability
and
best
path.
A
So
what
is
new
in
this
revision?
So
there
are
new
authors
added
malika,
patrice
and
wen,
and
their
contributions
are
now
incorporated
to
the
draft.
So
you
will
notice
section
one
has
changed
now.
It
includes
the
use
cases
that
are
justifying
the
use
of
d-path.
In
this
these
environments,
we
clarify
the
terminology,
we
did
a
general
cleanup
and
also
we
are
making
some
changes
in
the
specification
itself,
which
is
in
section
4..
A
A
So,
in
particular
for
the
mac
ip
advertisement
routes,
if
you
are
in
an
rfc,
9014
gateway
type
of
scenario,
the
d-path
is
used.
If
you
look
at
the
left-hand
side
of
your
slide,
p1
advertises
a
mac
ip
route
that
is
imported
by
the
gateways,
gateway,
1
and
2..
So,
for
instance,
when
gateway
2
re-advertises
that
route
into
domain
2,
it
basically
slaps
the
d-path
with
the
domain
1
identifier
that
is
received
by
gateway,
1
and
identified
as
a
looped
route.
A
So
what
we
are
doing
in
this
revision
is
we
we
allow
to
actually
install
that
looped
route
as
long
as
there
are
no
other
routes
available
in
the
router.
A
typical
example
would
be
what
you
have
on
the
right
hand,
side
of
the
slide
in
the
diagram.
A
So
if
gateway
1
loses
its
peer
to
the
route
reflector
in
domain,
one,
for
instance,
the
obviously
the
the
mac
ip
route
received
directly
from
p1
is
actually
lost,
and
in
that
case
the
the
route
that
is
received
from
gateway
2
can
be
installed
and
in
this
case
is
used
for
fast
convergence.
A
You
know
for
in
flight
packets,
and
you
know
it
can
help
in
that
sense.
So
that's
why
I
included.
We
included
this
case
next
slide,
so
we
identified
also
some
cases
where
you
know
the
the
two
gateways
that
are
stitching
domain,
one
to
domain
two:
they
they
advertise
in
rfc
9014,
they
advertise.
I
met
routes
for
the
two
domains
and
we
want
to
avoid
parallel
evpn
paths
for
bump
traffic
between
the
two.
A
In
case
you
have
local
attachment
circuits
on
the
on
the
two
gateways
and
one
way
to
differentiate
those
routes
and
and
pick
up
only
one
and
and
and
have
only
one
bomb
path
is
to
actually
use
the
path
right.
If
we
add
the
path
with
the
local
domain
to
the
gateways
on
the
imed
routes
that
are
advertised
for
domain
two,
we
can
identify
those
and
not
install
those,
and
we
only
install
the
ones
for
the
main
one
next
slide,
please
so
next
steps.
A
So
there
is
a
section
in
the
draft
that
talks
about
best
path,
selection
for
the
vpn
routes,
but
we
basically
discussed
and
we
we
think
that
section
should
be
clarified
in
in
the
rfc
7432-bis
draft,
and
this
document
should
just
refer
to
that
section
and
modify
that
section
with
the
new
addition
of
the
d-path
for
the
evpn
routes.
A
So
we'll
make
those
changes
and
we'll
synchronize
those
changes
with
the
the
rfc
7432
based
draft
and
after
that
yeah
we
want
to
receive
more
feedback
from
the
working
group
and
and
after
that,
the
draft
we
think
will
be
ready
for
working
group.
Adoption.
A
And
that's
it
any
comments.
A
A
So
changes
in
revision.
Four,
there
is
a
new
author
lucas,
based
on
the
the
use
cases
that
he
brought
up
for
the
draft,
and
actually
we
included
one
of
those
use
cases
that
we
call
centralized
routing
model.
A
Other
minor
changes,
general
cleanup
of
fixed
type
of
fixing
and
references
updated
next
slide,
please
yeah,
so
this
centralized
routing
model
is
described
now
in
the
draft.
Basically,
what
this
is
about
is,
if
you
have
this
an
environment
where
you
use
the
ip
aliasing
procedures
or
these
layer
3
ethernet
segments.
A
We
want
to
simplify
the
configuration
on
and
the
operation,
so
the
basically
instead
of
having
a
direct
ebgp
pc
session
to
the
directly
connected
leaf.
What
we
want
is
to
have
a
appear
to
a
centralized
leave
in
this
diagram.
We
call
it
pec,
as
in
centralized
and
all
the
cnfs
and
vnfs
will
have
this
bgp
session
to
the
centralized
leaf
right.
So
in
this
diagram
we
are
only
illustrating
the
the
procedures
for
one
of
them.
You
you
see
the
cnf.
A
A
So
if
we
didn't
do
anything
special,
the
traffic
coming
from
h4
for
for
to
a
host
in
that
subnet,
basically
will
with
trombone
through
pc
and
then
to
the
directly
attached,
leaves
p1
or
p2.
A
A
I
J
J
This
is
regarding
a
use
case
which
we
have
encountered
in
one
of
our
I
mean
we
came
across
this
use
case
in
one
of
our
customers
deployment,
so
we
thought
of
taking
this
up
in
the
in
the
best
forum
before
writing
this
together,
putting
putting
up
this
together-
and
there
were
few
discussions
where
a
few
of
the
best
members
have
responded
back.
This
is
more
of
implementation
requisite,
but
we
thought
it
was
otherwise
we
can
solve
it
in
a
generic
way
via
a
control
plane
based
solution.
J
So
that's
where
we
are
so
the
agenda
here
is
again
the
introduction,
the
problem
statement
and
the
use
case,
which
is
tied
to
it,
the
solution
and
then
how
this
control
pin
extension
is
backward
compatible
or
otherwise.
Please
next
slide
so
next
slide.
Please.
J
Essentially,
this
was
a
case
of
active,
active
firewall
deployment,
wherein
you
have
the
same
physical
device
with
a
virtual
credential
and
it's
placed
on
the
same
ethernet
segment
but
in
let's
say
a
different
fabric
which
is
connected
over
van
or
let's
say
over
over
a
dci.
It
can
be
a
typical
envio
fabric,
which
I
don't
want
to
use
the
word
engineer,
but
just
for
an
overlay
reference
which
can
be
deployed
via
evpn
control,
plane
or
supported
by
iev
pin
control
right,
that's
the
reason
I
mentioned
it
here.
J
So
it's
about
the
active
active
firewalls,
where
two
instances
of
the
same
wire
firewall,
which
are
carrying
the
same
virtual
credentials,
are
active
instances,
but
they
serve
their
local
site.
They
don't
talk
to
each
other
per
se
or
or
we
would
want
it
to
be
a
not
as
in
a
load
balance
kind
of
dealing.
It
has
to
be
preferred
in
such
a
way
where
the
local
deployment
serves
the
requisite
next
slide.
Piece.
J
This
is
what
I
was
referring
to,
where
the
bricks
are
the
firewalls
and
assume
that
this
is
a.
These
are
two
evpn
based
fabrics,
one
on
the
left,
another
on
on
the
right
side,
one
and
side
two
and
the
firewalls
here,
which
are
hooked
to
the
which
are
also
hosting
the
gateway,
are
hosted
by
the
border
league.
That's
just
just
a
sample
topology.
It
can
definitely
differ
from
this
one.
J
So
this
is
both
firewalls
are
hooked
to
the
same
ethernet
segment,
though
carrying
the
same
potential
same
virtual,
mac
ip,
for
example,
and
but
they
are
two
separate
physical
devices
per
se,
which
may
or
may
not
have
an
orthogonal
way
of
talking
to
each
other.
Maintaining
states-
that's
oblivious
here
and
the
red
lines
show
the
typical
flow
of
data
traffic
within
the
site.
B
J
Sure
so
we
can
skip
this
one.
I
think
this
I
have
already
covered
the
probably
I
should
have
yeah
so
the
requisite
the
requisite
here
is
that
all
the
both
the
border
leaves,
or
both
the
b
taps
here
or.
J
Should
be
should
act
as
a
designated
folder
both
can
flood
the
traffic
both
should
be
able
to
flood
the
traffic
at
the
same
time.
So
it's
about
supporting
more
than
one
designated
forwarder
for
the
same
ethernet
segment
and
and
bd
combination
right.
So
that's
the
idea
here
and
that's
what
we
are
proposing
here,
that
we
want
to
have
a
new
mode
of
selection
for
df,
which
is
equivalent
to
a
all
pe's
in
scenarios
like
this
all
p's,
which
can
act
as
a
df
and
yeah.
J
So
that's
that's
what
the
request
here
is
yeah.
We
can
move
to
the
next
one.
J
So
the
send
side
and
receive
side
are,
I
mean
again.
We
support
the
new
df
bit.
New
df
value
suggest
an
increment
to
the
existing
ones.
We
have
zero
and
one
right
now
being
supported
for
default
and
one
which
was
extended
in
and
extended
by
rfc85847432.
J
So
if
at
all
we
have,
I
mean
we
can
choose
the
label
next
value
and
the
the
tentative
proposal
to
use
the
next
value,
which
is
two
again
to
be
backward
compatible
if
any
of
the
routers
which
doesn't
publishes
or
publishes
a
non-two
value
or
it
doesn't
supports
this
extended
community,
the
the
default
falls
back
to
the
existing
rfc
7432.
The
default
selection
received
side
processing
is
again
the
same,
so
send
side
and
see
side
is
mostly
about
being
backward,
compatible
or
being
able
to
revert
back
to
defaults.
J
If
one
of
the
p's
don't
publishes
the
all
all
psdf
mode,
so
yeah
next
one
please.
I
think.
J
Yeah
same
thing,
and
the
last
slide
this
this
can
be
skipped
here.
J
Yeah,
so
I
think
this
is
what
we
expect
more
discussion.
I
shouldn't
say
working
group
draft,
but
more
discussion
and
feedback
on
this
proposal
on
this
draft
or
if
there
are
any
existing
ways
which
are
already
providing
these
enablers.
Definitely
we
want
to
collaborate
well.
B
K
A
Yeah,
I
have
a
couple
of
comment
questions
so
thanks
for
for
this
presentation.
So
the
first
one
is,
you
are
requesting
code
point
two
for
the
df
algorithm
for
the
df
election
extended
community.
That
is
actually
the
the
one
we
use
for
the
preference
based
df
election.
So
hopefully
you
can
actually
remove
it
from
the
from
the
draft
as
soon
as
you
can
please
and
the
the
second
one
is,
since
you
are
asking
for.
A
You
know
any
other
way
of
of
doing
this,
so
in
7432
base
we
we
have
this
default
gateway,
extended
community
that
is
already
specified
that
can
be
used
with
mac
ip
routes,
and
actually
it
indicates
that
the
the
route
is
being
advertised
for
a
kind
of
a
default
gateway,
which
is
what
I
understood
in
your
use
case.
You
want
to
achieve,
and
it's
already
specified
that
this
extended
community
is
not
going
to
be
subject
to
mobility
and
things
like
that.
A
So
the
only
difference
with
your
draft
or
your
your
use
case
is
that
in
seven
four
three
two
bits
that
is
used
for
irb
mac
ip
routes.
In
your
case,
it
wouldn't
be
an
irb,
but
it
would
be
something
attached
to
an
attachment
circuit,
but
I
don't
see
why
you
you
wouldn't
use
that
instead
of
an
ethernet
segment
to
me,
an
external
segment
here
in
this
use
case
is
kind
of
a
strange
thing
to
use,
but
we
can
discuss
more
in
the
on
the
mailing
list.
M
M
J
Essentially,
there
is
one,
but
we
don't
want
the
trump
warning
of
traffic
when,
let's
say
site,
one
based
host
are
sending
a
traffic
not
south
to
the
outside
world.
It
should
not
get
tromboned
to
the
remote
sites.
Firewall
instance
right.
It
should
only
be
routed
to
the
local
one
yeah
I
understand.
Typically,
you
have
different
credentials,
but
this
is
one
specific
case
where
we
want
to
have
same
virtual
credential
for
both
the
cases
for
both
the
both
the
sides
and
in
case
the
local
one
fails.
I
In
that's
right.
C
B
Okay,
I
will
come
back
to
this
presentation
later,
so
next
will
be
again.
Yes,.
N
N
So
this
first
draft
ipv6
only
t
design
was
adopted
last
year
on
the
28th.
N
So,
with
this
draft
one
update
that
we
have
to
the
draft
as
we
initially
the
draft
was
we
were
in
scope,
was
you're
testing
for
this
bcp
was
the
pc
edge
scenario,
so
we
added
a
s
scenario
to
that.
That
was
in
the
in
the
original
draft
and
we
had
removed
it,
but
now
we're
adding
that
test
back.
I
guess
into
the
draft,
so
that's
testing
both
safety,
128,
so
vpn
and
mvpn
into
into
the
draft.
N
Did
you
draft
it?
So
this
draft
is
a
bcp
draft,
so
this
next
draft
that
we're
introducing
that
that
I've
been
providing
an
introduction
for
on
this
call
is
a
it's
called
ipv6
only
p
design
all
sappy.
This
one
is
standards
track,
and
this
is
a
this
is
a
super
set
of
the
original
draft,
the
ipv6
only
tv
design,
the
difference
between
this
draft.
So
this
is
is,
is
what
I
call
the
design
draft
and
related
to
the
the
original
draft.
N
The
original
bcp
draft
is
is
testing
with
with
the
five
different
vendors,
cisco,
juniper,
arista,
nokia
and
huawei,
and
this
draft
is
providing
the
design
framework.
With
this
draft
the
focus
is
and
and
how
it's
different
is.
It
focuses
on
all
all
sappy's,
so
not
only
the
the
atheists
happy
that
are
being
tested
in
the
in
the
original
draft,
but
all
all
other
staff
next
slide.
N
Next
slide
thanks,
so
here
what
I've
done
is
I
I
actually
kind
of
broke
I
from
the
ayanna
page
for
aki
sapi.
What
I
did
was
I
I
took
all
the
fsf
and
kind
of
broke
them
up
into
functional
groupings.
So
the
first
case,
functional
case
of
the
of
accusative,
is
an
edge
customer,
mlri
ipv4,
an
ipv610
lri
and
that's
a
unicast
staffing,
multicast
staffing.
N
The
unicast
staff
is
one
of
the
staffers
that
we're
testing
in
the
original
draft
ipv6
only
design
the
inner
as
acting
safety
is,
is
the
additional
one
that
we
are
testing.
So
that's
happy
128
for
vpn
at
129
for
mvpn
we're
also
testing
as
well
bgpl
labeled
your
cast
for
6pe
and
4pe.
N
N
N
Then
in
the
next
category
is
ltvpn,
the
one
after
that
is
optimizations
and
then
the
last
category
is
any
kind
of
routing
policy.
Next
life.
N
Next
slide,
that's
thanks!
So
here
I
just
what
I
did
what
I
had.
This
is
the
thing
just
the
ayanna
happy
shaping
link
that
has
all
the
app
staffers
and
I
have
color
coded
into
functional
next
slide.
N
Next
slide,
sorry,
and
then
here
as
well,
so
basically
all
what
I'm
showing
here
is
this
color
coding,
you
know
of
all
functional.
Basically,
the
ipv6
only
p
design,
all
sappy,
all
all
of
the
address
families
and
subsequent
average
families
are
supported.
I
did
highlight
in
yellow
the
dubs
after
76..
N
Next,
so
so
here
here,
I'm
showing
just
a
dual
stack
scenario.
So
this
is
a
typical.
You
know
a
pec.
You
have
two
separate
piers,
a
traditional
dual
stack
next
slide.
N
Okay,
so
here
this
this
is,
this
is
one
of
the
scenarios
we
are
testing
in
the
original
ipv6,
only
p
design
draft
so
that
we've
added
sap,
128
and
sap
129
mvpn.
So
this
is
separate
fears
next
slide.
N
N
And
so
this
fight
is
showing
kind
of
the
the
frame
of
the
all-safety,
so
other
additional
staffing,
so
here
we're
showing
exactly
128
we're
showing
em
cash
free
for
this.
So
this
is
a
bg.
This
is
the
new
draft,
I
think
with
bgp
sapphire,
stateless
multicast
states,
multicast
and
then
srt
so
in.
Instead,
I
see
you
have
two
separate
peers
carrying
this
happy
next
slide.
N
N
Oh
sorry,
all
sappy's
such
good
applications
next
slide.
N
And
this
this
this
slide
shows
a
controller
scenario,
so
you
have
a
pe
peering
to
a
pc,
sdn
controller,
and
here
we
have
vgpls
and
then
routing
policy,
safety,
rpd
safety,
and
here
we
have
two
separate
piers.
This
is
traditional:
dual
stack
next
life.
N
And
here
we
have
a
single
pier,
so
we
can
see
the
savings
you're
actually
really
able
to
eliminate
the
v4,
pier
and
you're
able
to
carry
just
showing
various
a
variety
of
scenarios
where,
instead
of
having
single
p,
I
mean
separate
piers
for
v4
v6.
Now
it's
really
any
sappy
any
of
those
diana's
happy
that
are
in
the
list
that
are
all
you
know.
You
know
they're
that
they're
defined
they
can
all
be
carried.
You
know
with
a
single
single
v6,
pier
next
slide.
N
N
This
is
our
our
test
plan
that
we
have
so
we
have.
You
know
the
core
we're
using
isis
as
the
underlay
vcnp.
We're
testing,
really
the
main
things
that
we
need
to
test.
I
think
related
to
the
phone
functionally
testing
and
ensuring
that
everything
works
with
the
ipd60p
design.
We're
testing
bgp
pick
next
step
cell
label
allocation
mode
for
c
per
vrf,
brow,
reflector,
function,
add
path;
next,
stop
and
change;
p,
lincoln,
node
failure
and
then
edge
scenarios,
we're
testing,
vfd,
lag,
ipccos
and
and
ce
lincoln
node
failures.
N
So,
let's
go
to
the
next
slide
next
slide,
so
this
is
the
inner
as
our
architecture
that
we're
that
we
have
set
up
in
the
in
the
lab
with
each
of
the
vendors.
What
we've
added
in
here
is
the
nras.
So
we
have
two
two
paths
between
the
as
the
as
on
the
left
and
the
asl
right
to
test.
So
we
now
we're
able
to
test
both
the
edge
scenario
and
then,
as
well
as
the
intra
as
scenario
next
slide.
N
N
Right
this
is
the
last
slide,
so
we
made
some
significant
progress
with
juniper
in
testing
and
with
the
testing
we've
been
able
to
successfully
test
the
pec
edge
scenario
where
we
have
an
ipv4
and
ipv6
mlri
from
a
control
plane
perspective,
they're,
they're,
being
carried
over
a
single
v6,
only
pier
and
we're
forwarding,
v4
and
v6,
and
we
have
end
end
reachability
cdc
and
we're
using
the
default
per
cd
label
allocation.
N
We've
tested
with
a
v4
only
core
we've
also
tested
with
a
v6
only
core
and
we've
proved
that
the
solution
works
so
everything's.
So
far,
so
good,
we
haven't
seen
cnn
issues
and
the
testing
is
basically
we're
trying
to
prove
out
that
you
know
what
you
would
normally
do
with
dual
stacking:
we're
able
to
do
with
a
single
v6
pier
and
provide
the
same
identical
functionality
as
the
dual
stack.
Thank
you.
B
Okay,
unfortunately,
we
don't
have
time
for
questions.
So
if
people
have
some
questions,
please
raise
them
to
the
list.
Thank
you
and
thank
you
again.
Next
speaker
will
be
ko.
E
E
E
So
here
is
the
motivation.
There
is
a
srv6
map.
Architecture
mop
stands
for
mobile
user
plane
draft
that
is
present
presented
in
dmm
working
group
and
it
defines
a
srv6
based
mobile
user
plane
architecture
for
distributed
mobility
management.
E
Basically,
this
architecture
integrates
mobile
user
plane
into
srv6
and
the
way
it
does
that
is
that
it
transforms
session
information
from
mobility
management
system
into
necessary
routing
information,
but
with
srv6
as
a
forwarding
fabric,
one
forwarding
fabric
as
part
of
this
architecture.
It
also
defines
the
following
things:
it
also:
it
defines
a
notion
of
mobile
user
plane,
router
or
a
pe
router
and
a
controller.
E
Two
new
segment
types
are
defined,
srv6
segment
types
for
the
map
segments,
it's
called
direct
or
interwork
segment,
and
then
there
are
two
new
session
transform
routes
that
are
defined,
and
these
are
the
routes
that
controllers
would
announce.
The
mob
segments
would
pretty
much
reside
on
pe
next
slide.
Please.
E
Now
it
also
defines
two
new
well-known
routing
instances
akin
to
very
similar
to
vrfs.
It's
called
interwork
segment
for
n3
ran.
This
is
the
segment
that
allows
you
to
connect,
n3
interfaces
between
g
note
b's
and
ups
and
a
direct
segment
n6dn,
which
is
an
n6
interface
between
upf
and
data
networks.
E
Again,
you
should
think
of
these
segments
connecting
into
earlier
three
vrf
like
routing
instances
and
with
that
being
said,
what
this
draft
does
is
that
it
defines
a
new
pgp
safy
that
allows
this
mock
in
extensions
to
work
with
bgp
as
a
control.
Plane
also
adds
a
new
extended
community
as
part
of
defining
a
new
software
yeah
next
slide.
Please.
E
So
this
is
how
the
nlri
format
looks
like
it
has
an
architecture
type
which
is
one
octet,
followed
by
route
type
length
and
then
route
type
specific
fields.
The
architecture
type
defined
in
this
draft
is
3gpp.
5G
subsequent
drafts
can
define
newer
architecture
types,
but
for
now,
for
this
draft
it
is
3gbp
5g
next
slide.
Please.
E
So,
as
part
of
this
architecture
type,
there
are
four
new
route
types
that
are
defined
specifically
for
this
architecture.
Two
of
them
are
discovery
routes
for
different
segments
that
we
have
defined
and
two
of
them
are
session
transport
routes
that
carries
routing
information.
Two
discovery
routes
are
interwork
segment,
discovery
and
direct
segment
discovery
routes.
Now
the
route
types
could
be
shared
across
different
architecture
types
as
and
when
they
get
defined,
but
for
this
architecture
type
there
are
only
four
route
types
that
are
defined
next
slide.
Please.
E
So
a
little
bit
about
again
the
well-known
routing
instances
that
are
being
defined.
You
have
n3ran
as
a
routing
instance
and
then
6dn
routing
instance,
and
then
you
have
discovery
route
interwork
discovery
route
that
connects
with
n3
ran
routing
instances.
So
anytime,
you
have
n3
ran
vrf
like
routing
instance
on
a
pe.
You
would
announce
interwork
segment,
discovery
routes
anytime,
you
have
an
n6d
and
routing
instance.
You
would
announce.
Direct
segment
require
discovery
routes.
E
E
All
right,
so
two
new
route
types,
a
little
bit
about
that
type.
One
route
carries
end
user,
reachability
information,
it
carries
tunnel
end
points,
gtp,
deid,
qfi,
all
these
things.
Where
you
talk
about
eid,
qfi
and
and
under
a
tunnel
endpoint,
they
are
architecture,
specific
3gbp,
5g,
specific
and
therefore
the
nlri
has
an
architecture,
specific
field
in
which
it's
been
carried.
E
Now
this
route
types
are
announced
by
controllers,
while
the
discovery
routes
were
announced
by
pes
so
tunnel
endpoint,
that
is
announced
by
controller.
It's
been
resolved
using
interwork
segment
discovery
route,
which
also
carries
the
locator
and
prefix
id.
So
you
would
have
this
route
recurs
over
the
tunnel
endpoint
route
and
resolve
that
when
it
comes
to
creating
forwarding
said
for
gtp
46e,
it
is
basically
generated
using
the
procedures
mentioned
in
srv6
mobile
u-plane
draft
yeah
next
slide.
E
E
This
route
type
also
carries
mop,
extended
community
and
it
carries
the
direct
segment
in
information
on
a
pe.
There
could
be
a
multiple
and
three
rand
routing
instances.
What
this
direct
segment
information
allows.
You
is
to
map
a
appropriate
segment
for
a
routing
instance
that
is
present
on
a
muppy
on
a
pe,
and
it
lets
you
simply
forward
the
traffic
to
that.
E
E
This
is,
I
believe,
my
next
slide
yeah
this.
This
is
my
last
slide.
The
draft
is
in
fairly
good
shape
version.
One
of
the
draft
will
be
submitted
soon.
We
we
would
really
like
to
get
our
working
group
feedback,
and
once
we
have
submitted
a
version,
one
would
like
to
have
one
working
group
consider
adopting
this
draft
I'll
be
open
for
any
questions
that
are
that
you
may
have.
B
M
Question
about
this
ensuing
ram
versus
in
sixth
rank.
Are
they
one
domain
segment
running
domain
or
separate.
M
E
There
is
an
architecture
draft
that
talks
about
it
very
nicely.
I
can
forward
that
to
the
working
group
as
well,
but
it
defines
the
rule
sets
to
say
how
the
routing
information
is
stitched
across
different
vrf's
as
and
when
or
different
routing
instances
as
and
when
you
want
to
forward
the
traffic
towards
yeah.
E
P
When
we're
matrix
nokia,
my
question
is:
what
is
the
goal
of
this
draft
and
is
street
vp
somehow
going
to
adopt
this?
Because
today,
can
you.
P
E
No
because
I
haven't
as
part
of
defining
this
drop,
I
haven't
done
any
modifications
through
3gpp.
What
we
have
done
is
universally
defined
bgp
as
a
mechanism
to
build
a
fabric
or
a
control
plane
in
a
manner
that
the
packets
would
be
carried
from
ran
into
the
data
networks.
So
I
believe
this
is
a
standalone
draft.
It
has
vpn
like
semantics.
That
is
one
of
the
reasons
I
have
brought
it
to
best
because
best
deals
with
services.
E
Not
replacing
the
signaling
but
can
be
encompassing
the
signaling
from
gtp
to
srv6,
which
is
defined
in
the
architecture
draft,
but
this
draft
relies
on
the
procedures
that
are
defined
in
the
architecture
drop
to
do
an
appropriate
conversion.
Here
we
have
defined
bgp
as
a
fabric.
That
makes
sure
how
does
it
work
and
interwork
between
the
rams,
as
well
as
the
dns?
That
is
the
data
networks.
N
I'm
sure
I'm
here
I
was
wondering
you
know
with
the
3gpp
have
you
had?
Has
there
been
like
a
maybe
a
gap,
analysis
or
problem
statement
of
of
what
was
in
the
existing
3gpp
architecture?
N
E
So
again,
thank
you
for
the
question
again.
I
thought
I
described
it
well
in
the
motivations
part
of
the
draft
early
on
the
motivations
are
that
there
is
no
bgp
based
mechanism
or
a
fabric
that
can
achieve
this.
The
draft's
goal
is
to
use
bgp
as
a
fabric
to
build
where
you
can
translate
a
service
6
to
gtp,
and
that
is
the
motivation.
One
of
the
reasons
again,
I
will
repeat,
but
I
will
be
quick-
is
that
bringing
it
to
best
because
it
has
a
vpn
semantics.
E
Q
All
right,
this
is
mahesh
nandani
and
I'm
going
to
talk
about
the
srv6
map.
You
got
the
introduction
from
ku
and
I
did
post
this
draft
actually
this
morning
into
the
best
working
group.
Sorry
for
that
confusion,
I
should
have
done
it
before
the
cutoff,
but
we
posted
it.
The
wrong
working
group
next
slide,
please
all
right.
So,
as
ku
talked
about
his
route,
this
particular
yang
model
is
talking
about
the
configuration
aspect
of
bgp
and
I'll.
Q
Q
So
let's
talk
a
little
bit
about
what
is
the
actual
model
doing
it's
augmenting
the
current
existing
bgp
yang
model
in
the
idea
working
group
and
it
adds
a
srv6,
a
particular
node
at
a
global
level
and
inside
that
particular
container
or
node.
We
all
add
the
map
capability
for
both
uplink
and
downlink
configuration
in
addition
to
the
base
bjp
engmall.
It
also
augments
the
bgp
policy
model
for
a
defined
set
it
in
this
particular
case
and
interface
sets,
and
it
add,
adds
both
a
match
and
a
set
options.
Q
Q
Right
so
essentially,
we
have
gone
through
one
cut
of
the
yang
model
and
we
made
sure
that
it
validates
it
compiles,
but
we
do
expect
a
revision
not
only
of
the
model
but
also
the
draft
and
in
particular
we're
going
to
focus
on
an
example
of
for
how
it
could
be
used
for
configuration.
Q
I
B
Okay,
so
we
are
not
able
to
get
you,
so
we
will
move
in
the
main
time
to
the
next
pair.
R
And
whether
the
service
providers
like
it
or
not-
and
if
you
look
at
the
bottom
line
of
those
discussions,
it's
always
something
like
ipv6
is
giving
us
a
lot
of
hassle
because
we
have
no
control
on
the
address.
We
have
no
control
on
who
is
who
and
that
really
boils
down
to
neighbor
discovery
and
the
way
addresses
are
formed
with
auto
configuration,
and
so,
if
you
can
go
to
the
next
slide,
please
yeah
compared
to
ipv4,
which
are
you
know
what
everybody
operates.
R
Ipv6
is
different
it
it's
very
clear.
It
has
very
observable
difference
which
impact
the
way
the
network
can
be
operated
with
v4
we
had
phdp
one
address
per
node.
The
dhcp
flow
was
observable.
You
could
see
the
the
request
coming
in
the
response
coming
back,
you
could
snoop
far
from
it
and
know
which
mac
address.
Basically,
that's
what
the
service
providers
many
use.
R
Obviously,
six,
the
uid,
but
basically
who
owns,
which
it
trusts
and
usually
there
was
one
ip
address
per
node,
so
that
made
the
the
network
side
of
the
operation
kind
of
simple
here.
Deterministic
and
another
thing
which
comes
with
dhcp
is
the
fact
that
for
each
address
that's
been
performed
on
the
network
given
to
a
device.
You
could
say
how
long
at
most
it's
going
to
stay
on
the
network,
so
either
it's
refreshed
or
it's
gone
next
slide.
Please.
R
If
it
can
do
that
and
without
retelling
the
network,
how
long
it's
going
to
use
that
address
when
the
address
can
be
deprecated,
if
there
is
any
state
in
the
network
associated
to
that
address,
so
it's
it's
all
linked
to
the
fact
that
the
expectation
is
the
network
has
a
cache
of
the
addresses
and
it
can
do
least
recently
used
and
that's
going
to
work
and
well
the
guys
at
nano.
R
They
just
ate
that
for
some
reason-
and
in
fact,
enterprise
networks
hate
that
as
well,
because
for
everything
we
build
and
vpn
is
no
exception,
we
are
meant
maintaining
more
and
more
stent
in
the
network,
so
the
desire
on
one
direction
is
what
the
android
android
guys
will
tell
you.
They
don't
want
to
support
the
hdb
they
they
just
want
to
be
able
to
use
and
claim
any
address
they
want
and
if
anything
goes
wrong,
it's
the
fault
of
the
network.
It's
never!
R
The
fault
of
the
of
the
user,
asking
too
many
addresses
or
doing
wrong
things
within
the
class,
always
the
fault
of
the
network.
The
master
is
the
device.
Well,
when
you're
network
operator
corporate
network
admin
or
what
it's
it's,
not
what
you
want
you.
You
basically
want
at
least
some
control
on
on
the
addresses,
because
at
some
point
you
may
be
asked
who
is
behind
this
address.
R
You
may
be
you,
you
may
be
forced
to
to
provide
some
services
for
which
you
have
to
deploy
resources
associated
with
addresses,
so
just
to
be
able
to
have
the
proper
resources
deployed
to
face
the
the
need
of
the
network.
You
need,
you
need
to
be
able
to
have
some
control
on
it
say:
hey!
R
You
can't
have
more
addresses
than
that
you're
already
using
too
much
of
that
or
who's
this
guy
being
this
address,
can
I
trust
that
it's
not
somebody
stealing
this
address
and
guess
what,
with
stateless
advance
of
the
configuration,
it's
very
very
easy
to
steal,
no
trust
and
just
claim
it
and
start
getting
the
traffic.
R
The
bottom
line
is
the
way
this
this
reactive
protocol
operates
is
completely
non-deterministic.
The
network
cannot
build
a
clear
view
on
which
addresses
are
present
on
the
network,
which
devices
on
which
centers
you
don't
necessarily
know
when
it's
formed,
and
you
definitely
don't
know
when
it
stops
being
used,
and
this
is
the
major
cause
of
broadcast
and
unknown
and
multicast
traffic
in
in
the
network,
because,
basically
this
this
cache
based
reactive
operation
forces
the
network
to
look
up
anything,
that's
not
known
so
yeah
auto
configuration
could
be
very
fine
having
the
devices,
for
instance.
R
If
you
think
of
this,
this
cluster
of
servers
and
the
devops
deploying
stuff
they
they
really
might
like
to
have
auto
conf
like
the
device
such
as
which
drive
some
prefix
gonna
use
and
as
long
as
it's
doable
on
the
network.
Yes
network
would
say
yes,
but
on
the
other
hand,
there
should
be
a
way
to
say
no,
and
there
must
be
a
way
to
make
sure
that
you
know
exactly
deterministically,
which
address
is
where,
in
your
network,
looks
like
this.
R
So
this
slide
basically
summarizes
the
kind
of
issues
you
get
with.
Slack
slack
doesn't
tell
you
when
there
is
a
movement.
Slug
does
not
tell
you
how
long
you're
gonna
use
the
the
address.
R
The
only
thing
you
can
do
for
slack
is
snoop
the
the
dad
basically
and
tnd
protocol,
and
that's
very
unreliable
because
it's
based
on
broadcast-
and
you
have
some
wireless
environment,
for
instance
you
might,
you
might
lose
them
with
them
completely
and
the
the
look
at
basically
is
the
only
way
to
find
a
silent
node,
which
means
that
you
will
have
a
a
broadcast
through
your
fabric
or
you
won't
be
able
to
serve
that
type
of
node.
The
whole
concept
of
sign
up
node
is
something
that
we
don't
want.
R
We
want
to
make
sure
we
have
a
state
for
everything.
That's
present
on
the
network
and
basically
slack
is
the
major
cause
for
not
knowing
that
the
result
is
the
number
of
enterprise
networks
won't
support
slack.
They
will
only
support
the
hcp
and
guess
what
android
does
the
reverse?
They
only
support
slack.
So,
at
the
end
of
the
day,
you
can't
survive
ipv6
android
devices
on
an
enterprise
network.
R
So
yeah
I
mean
that
that
was
the
status
20
years
ago.
She
realized
ipv6
is
25
years
ago.
Ipv4
is
40
years
ago,
from
the
perspective
of
2020.
Both
are
all
protocols.
The
difference
is
ipv6
has
evolved,
it
has
evolved
because
of
srv6.
It
has
evolved
because
of
the
iot,
not
because
of
the
mainstream
ipv6,
but
it
has
evolved
and
in
particular,
this
concept
of
the
bad
aspect
of
the
sl
in
slack
has
been
addressed.
It's
been
addressed
by
rfc8505,
which
basically
is
kind
of
a
reverse
dhcp.
R
This
takes
itp
off
the
picture
you
put
any
podcast,
but
for
the
rh
life
coming
from
the
network,
the
device,
but
basically
you
you
go
up
here:
the
multicast
operations
which
are
related
to
the
neighbor
discovery,
stateless
operation.
All
this
is
gone.
You
get
the
stateful
observable
exchange
between
the
device
and
the
network
and
based
on
that,
we
can
effectively
build
a
reliable,
stateful
deterministic
state
to
evpn,
because
now
we
know
exactly
which
ip
addresses
are
present
on
which
device
and
rfc89
weigh
basically
the
security
of
it.
R
R
So
it's
all
about
configuration,
you
don't
need
to
care
about
it,
but
basically,
when
you,
when
you
train
for
the
first
time
in
addition
to
the
network,
you're
associated
with
a
token
that
you
can
prove
later
so,
if
you
will
or
you
re-register
your
drive
and
prove
you're
the
same
guy
as
he
did
before
next
slide.
Please.
R
Yeah,
so
so
that's
I'll
be
good.
This
is
basically
the
goal
of
this
draft
basically
enables
to
use
those
rfc8505
and
then
line
two
up
to
eight
in
the
context
of
here
and
so
using
the
signals
that
come
from
the
whole,
we
have
a
better
tools
for
sorting
out
duplication
from
any
palette
from
movement.
R
We
have
a
sequence
contour,
for
instance,
that
each
time
the
device
is
saying,
I'm
here
I'll
get
this
address
and
it
says
it
moves
it
will
have
to
do
that.
Then
we
can
sequence
that
we
can
know
exactly.
What
is
the
location
of
future
drives,
which
means
that
we
can
know
where
to
inject
it
in
evpn.
R
R
So
here
is
between
the
flow
that
that
happens.
In
that
case
different
shot
of
time.
I
will
go
relieve
that,
but
basically
you
have
to
bring
every
address
with
a
lifetime
and
do
that
carefully
to
and
when
you
move
you
have
to
register
it
for
for
the
same
location,
then
we
are
signaling
from
north
carolina
next
slide.
R
So
here
is
important
how
the
the
labor
discovery
registration
works
for
for
host
that
that
the
security
piece.
So
you
see
there
is
a
challenge,
the
north
exchange
and
so
many
of
the
the
key
pair
that
was
auto
configured
by
the
host,
and
that
is
used
to
generate
the
token
that
the
network
will
keep
next
slide.
Please
so
yeah
the
draft
has
been
stable
for
one.
We
got
a
discussion
by
your
so
this
this
is
the
I
mean
we
are
now
ready
for
for
adoption.
R
The
group
is
interested
in
following
up
with
this
another,
a
number
of
other
protocols
I've
already
had-
and
that
includes
ripped
infants
ripple,
and
we
also
have
redistributed
m505
to
rfc
8929,
which
is
actually
a
labor
discovery
property.
So
you
can
interrupt
classical
neighbor
discovery
with
h505
using
a
nd
plus.
R
H
I
I
I
I
It's
a
typical
3pm
general,
the
user
see
we
are
single
home
to
one
access
pe
and
the
service
is
multi-home.
That
was
two
service
piece.
The
the
user,
the
accessory
will
create
a
spfe
svme
instead
of
pm
session.
Then
they
can
save
the
resources
over
smsp
each
accent
key.
Now
we
are
correct.
We
will
create
a
spf
session.
The
psh
will
be
maybe
very,
very
huge,
then
the
remote
and
each
sql
decision
will
will
use
work,
many
manual
manually,
convicted,
remote,
discriminators
and
and
for
srv6
service.
I
I
I
This
is
our
solution
in
our
solution.
We
want
to
reuse.
The
vip
meter
attribute
also
defined
in
rc
99026,
it's
the
earlier,
the
type
38
attribute,
and
we
don't
do
any
change
to
spfd
and
in
our
solution
we
are
introduced
two
new
vip
modes.
The
first
one
is
splv
for
srv6
locator
session.
The
second
one
is
a
spf
for
comment
session.
The
first
one
will
be.
We
will
use
it
to
detect
the
srv6
locator
prefix
in
this
type
wall.
The
optional
tov
will
contain
source
ip
address.
I
I
So
we
will
use
the
asset
tool
detect
other
mode
endpoints
next
time,
please,
okay,
and
also
we
have
do
some
more.
We
have
received
some
comments
in
the
middle
east
and
we
still
welcome
more
comments
and
discussions,
and
also
later
we
may
only
we
may
revise
our
jobs
according
to
our
summer
discussion.
Thanks.
B
Okay,
it's
still
it's
still
not
working.
We
are
not
able
to
hear
your
angle.
B
B
Thank
do
you
want
to
take
over
and
present
your
slides.
B
J
Yeah,
hello,
everyone
I'm
back
here
again,
so
this
was
a
draft
which
we
did
again
around
half
a
year
back
because
of
the
same
reason
we
were
not
able
to
build.
So
I
work
with
aruba,
hp
and
my
co-authors,
vinayak
and
swati
also
worked
there
next
site.
Please.
J
Next
slide,
please
yeah!
You
can
have
this.
J
So
the
problem
statement
here
is:
we
have
talked
about
mac
dampening
in
rfc
7432,
which
talks
about
the
dampening
counts
and
the
timer
and
the
mac
moves
observe
within
that
right.
That
has
already
been
talked
in
detail
and
there
was
some
portion
left
to
implementation
per
se,
including
how
do
we
handle
with
the
freezing
of
the
mac
and
how
do
we
unfreeze
it
or
deep
freeze
it
post
and
freezing?
Do
we
freeze
it
forever
or
there
is
an
organic
way
to
freeze
unfreeze
check
it
again
and
go
on.
J
I
mean
it's
all
left
to
implementation,
but
I
want
to
sort
of
put
forth
a
thoughts
here
where
we
want
to
actually
do
something
on
that
side
as
well
right.
So
the
the
best
option
here
would
be
to
freeze
it
forever,
but
if
no
operator
is
taking
care
of
it
right
when
sort
of
it's
frozen
forever,
it's
it's
down
down
the
drain
strike
and
there
is
no
correction
which
is
happening.
Let's
say
the
time
is
non-deterministic
here
right
it.
J
It
would
be
okay
to
handle
it
in
a
organic
way
where
we
want
control,
plane
and
say
control
plane,
but
extensions
to
control
plane
where
we
define
certain
ways
of
de-freezing
and
again
running
mac
damping
on
top
of
it
as
a
complete
solution.
So
this
is
what
we
have
been
trying
to
propose
here
in
this
draft.
It
can
be
more
of
information,
if
not
standardized
per
se.
J
So
again,
as
already
discussed,
the
typical
problems
of
mac,
duplication
or
mac
move
per
se,
which
leads
to
damping
or
dual
map
configuration.
Sorry,
the
mag
configuration
wrong
configuration
of
match
and,
let's
say,
two
different
vms
in
a
dc
scenario,
or
let's
say
in
campus
per
se,
where
the
where
there
is
a
rogue
device
which
is
mimicking
two
map
maps,
we
have
two
vtep,
so
that's
very
possible.
J
So
another
case
is
of
the
loopy
access
side,
client
network,
where
you
have
the
client
side
network,
where,
let's
say
the
fabric
operator
has
no
hole.
So
that's
it.
It
would
lead
to
a
relearning
of
max
at
dynamic,
max
dynamically
learning
at
two
different
weekends,
and
this
can
go
on
forever.
The
stickiness
of
the
mac
will
also
not
help
because
this
loopy
side
network
won't,
I
mean,
help
you
converge
right.
So
that's
where
we
are
and
you
can
move
to
the
next
like
this.
J
So
what
we
intend
to
define
here
is
something
called
a
mac
freeze,
timer
and
a
wrapper
around
mac
dampening
timer,
which
was
defined
and
the
mac
dampening
counts,
which
were
already
defined
in
7432
and
have
all
of
this
under
the
same
umbrella.
Called
a
mac
dampening
attribute
set,
and
so
essentially
the
the
aim
here
or
the
goal
here
is
to
get
to
the
duplicity
as
soon
as
possible.
J
If
the
operator
hasn't
taken
control
of
the
situation,
this
may
entail
freezing
the
map
for
a
longer
duration.
Then,
let's
say
an
earlier
iteration
when
that
can
happen,
and
the
map
was
frozen
right
or,
and
a
combination
of
two
that
would
help
us
to
elongate
the
freezing
time
and
reduce
the
duplicity
detection
time
or
the
damping
timer
here,
along
with
the
count
in
an
organic
way
where
we
can
define
the
iteration.
So
we
can
define
the
complete
package
in
one
iteration
and
take
it
further.
J
Can
you
move
to
the
next
slide?
Please
yeah.
So
this
is
how
it
works.
So
we
have
these
three
values
under
an
umbrella.
When
I
say
one
at
one
iteration,
it's
an
iteration
of
dampening
detection
and
freezing
right
and
unfreezing
on
this
day.
J
So
this
whole
bunch
of
procedures
or
the
two
procedures
can
be
put
into
one
iteration
and
can
be
tracked
and
cached
instead
of
just
going
ahead
and
freezing
the
mac
right.
So
essentially,
as
we
see
here
in
the
slide
that
the
nth
iteration
of
the
mat
damping
time
can
be
a
little
lesser
as
compared
to
the
pre
previous
iteration.
The
counts
can
increase
where
we
want
to
have
more
number
of
counts
within
the
same
iteration,
and
also
the
freezing
timer.
J
The
freeze
timer
can
increase
where
we
may
give
ample
opportunity
or
provide
appalachian
opportunity
for
the
admin
to
take
care
of
it.
Take
care
of
this
problem
situation,
if
not
done
in
the
within
the
organ
iteration,
and
this
is
how
it
proceeds
so
yeah.
This
is
the
solution
in
the
next
slide.
Please.
J
So,
with
respect
to
time
and
ft
the
the
freeze
timer,
it
increases
till
infinity.
So
eventually
you
are
going
towards
a
complete
freeze,
but
in
an
organic
way
you
are
going
up
the
blip
and
showing
up
and
then
freezing
again,
whereas
the
dampening
timer
is
shortening
enough
to
go
into
zero.
So
eventually
we
want
both
of
these
to
converge,
where
it
leads
to
a
complete
freeze
of
mac.
If
these
intermediate
stages
or
iterations
of
the
whole
solution
doesn't
work
next
slide,
please.
J
J
So
yeah,
please
go
through
these
details
in
the
draft,
and
let
me
know
your
views
on
this
yeah
and
next
next,
like
this
and
backward
compatibility.
Since
all
this
is
restricted
to
one
diff
one
device
and
there
is
no
control
plane
exchange,
I
mean,
except
the
extended
community
maximus
number
which
leads
to
this
dampening
or
which
helps
derives
the
dampening
state.
There
is
nothing
much
which
is
exchange
all
this
is
under
the
purview
of
the
same.
J
O
It's
just
just
a
general
comment
on
this
slide.
If
there's
no
control
plane
exchange
of
the
values,
I
think
the
feedback
would
be
why
why
do
we
understand
that.
J
Sorry,
I'm
not
able
to
hear
completely.
Can
you
repeat
again,
please.
O
The
question
with
it
is:
if
there's
no
control,
plane
exchange
of
the
values,
this
seems
to
be
very
implementation
dependent,
which
is
where
7432
had
ex
you
know
explicitly
left
it
off
on
purpose.
O
So
maybe
that
that
was
really
the
only
feedback
is,
if
2ps
don't
need
to
communicate.
This
value
maybe
expand
on
the
benefits
of
standardizing.
J
A
Yeah
hi.
I
have
similar
comments
to
to
what
look
was
trying
to
say,
since
you
are
not
changing
the
control,
plane,
change
or
you're,
not
adding
any
any
changes
in
the
signaling
at
least
yet
the
draft
should
be
informational.
In
my
opinion,
not
standard
struck.
G
K
B
L
K
Okay,
here
is.
K
O
K
P
K
As
we
know,
rsp
8826
has
defined
new
image
based
on
ketone
scatters
for
m
routine
fat
failover.
The
main
procedures
include
first
determining
the
status
of
a
p
tunnel.
Second,
the
standardized
demonstration
approaching
advertising
is
a
new
standby,
its
community
and
the
third,
the
hot
house
standby
mechanism.
K
K
K
K
K
K
K
K
K
K
Next
steps,
we
are
going
to
specify
more
details
for
more
failures
scenarios
to
provide
the
relief
for
even
slow
ds
batteries.
B
Thank
you,
okay,
thank
you.
We
are
already
out
of
time,
so
we
don't
have
time
for
the
last
presentation.
B
So
thank
you,
everyone
for
your
attendance
and
hopefully
we
can
see
each
other
at
the
next
year
thanks
everyone.