►
From YouTube: IETF112-BESS-20211109-1200
Description
BESS meeting session at IETF112
2021/11/09 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
Not
well
so,
if
some
people
are
not
aware
about
it,
please
please
read
it,
but
it
should
be
well
known
for
most
of
the
people.
A
Here
is
our
agenda.
It's
pretty
packed
so
to
all
the
speakers.
Please
keep
your
timing
and
don't
overlap.
Otherwise
we
will
have
some
issues.
We
have
a
very
limited
buffer
today.
A
Status
update,
so
we
have
four
rfcs
that
have
been
published
since
the
last
summer.
Idf
two
are
really
interesting,
so
it
took
a
lot
of
time,
but
at
the
end
we
succeeded
to
publish
the
rfv2
rfcs
that
are
related
to
our
evpn
routing,
so
vr
irb
evpn,
as
well
as
via
ip
prefix
advertisement.
So
this
is,
it
took
a
lot
of
time,
but
this
is
a
very
good,
a
very
good
achievement.
A
We
have
two
documents
that
are
still
under
shepard's
review,
one
which
is
related
to
evp
and
lsp
ping,
so
matthew,
if
I'm
not
mistaken,
has
to
do
video
right
up
on
this
one.
A
A
We
have
two
documents
that
are
still
under
working,
replace
call
call
for
a
long
time,
so
on
v
I
see
the
smack
flash.
Unfortunately,
we
got
very
very
few
feedback
and
responses
during
the
working
rash
call,
so
matthew
requested
a
routing
directorate
review
on
this
one,
so
I
think
ross
was
appointed.
I
provided
a
couple
of
comments
that
video
first
have
two
two
answers
before
before
we
can
move
forward
on
the
ibm,
ws
vpws
fxc.
A
A
Similarly,
we
have
the
bgp
evgp
dmz
draft
under
working
group
adoption,
but
we
are
still
missing
some
ipr
response.
So
I
don't
I
don't
know
if
we
have
sat
here
connected
no
satya,
isn't
there
so
yeah
two
voters,
please
reply
to
vr
to
the
ipr
poll.
So
we
can.
We
can
move
forward
with
the
adoption.
A
Working
group
document
updates,
so
you
will
be
able
to
review
offline.
So
this
is
the
latest
update
that
we
have
for
the
documents
a
couple
of
things
to
highlight
so
on
mhps
becoming
protective,
there
was
a
single
plus
call
that
failed.
It
seems
that
the
comments
have
been
addressed
by
the
offer,
so
I
need
to
check
if
everything
has
been
resolved
and
then
we
can
move
forward.
A
A
B
Yeah,
your
audio
is
clipping,
I
don't
know
if
anybody
else
has
that
problem
or
if
it's
just
me.
B
A
B
Okay,
thanks
stefan
I'll
I'll
talk
over
these
now
so
for
the
multicast
flow
df
election
draft.
We
think
this
is
going
to
be
ready
for
working
group
last
call
soon.
So
that's
in
our
queue.
The
mvpn
siemens
interrupt
draft
is
on
the
agenda
today.
Evpn
bfd
and
sd1
usage,
so
evpn
bfd
do
any
of
the
authors
or
any
of
the
authors
on
in
the
meeting
that
they
can
give
us
a
quick
update
on
that.
B
Okay,
so
I
treat
that
as
ongoing,
I
think
sd-wan
usage
so
linda
has
asked
for
working
group
last
call
on
that.
We've
just
got
an
open
point
about
the
depend,
whether
there's
a
dependency
on
that
and
some
companion
work
in
the
idr
working
group.
I
don't
know
if
linda
is
on
them
in
the
meeting
to
say
something.
D
D
E
B
B
This
is
the
monotony
split
horizon
draft,
so
we
believe
that's
ready
to
progress
to
the
next
step,
which
would
be
working
group
article,
the
extended
evpn
optimized
ir
draft,
so
the
authors
have
said
that
they
believe
it's
ready
to
move
forward,
martin's
waiting
for
the
the
bomb
procedures
draft
to
move
ahead
for
this
one
bgp
multicast.
This
will
be
ready
for
working
group.
Last
call
after
an
update
of
the
document.
B
B
Okay,
so
the
rfc
7432
bis
draft.
So
there
were
a
few
changes
in
this.
I
don't
know
if
any
of
the
authors
are
on
the
in
the
meeting,
apart
from
stefan
who
can
get
maybe
talk
about
this
update.
G
Yes,
go
ahead,
thank
you,
sorry
yeah!
So
it's
it's
actually!
Zero
two
is
actually
a
fairly
mechanical
update,
so
we
received
four
sets
of
feedbacks.
G
One
of
them
actually
is
is
is
a
bit
of
a
slip
or
or
a
purposeful
emission
from
rfc
85
84.
I
think
it
is
or
8534,
via
the
df
election
draft,
previously
sort
of
specified
how
to
auto,
attract
auto
extract,
yes,
important
route
targets,
but
that
was
removed
at
the
last
minute
before
publication.
G
So
that's
incorporated
here
and
then
the
other.
I
guess
substantive
changes
in
section
8.5.
G
It's
specifying
the
deflection
behavior
for
two
different
originating
ips
soybean
fee,
v4
and
fev5,
and
the
rest
is
fairly
mechanical
wording,
changes
and
just
updating
sort
of
the
applicability
of
flow
label,
both
signaling
and
data.
B
Okay,
so
nick,
thank
you.
Next
up
is
castlevan
stephanie.
If
you
could
share
the
slides
for
the
vpn
seamless
intro.
B
H
H
This
is
about
an
update
to
the
existing
iuvpn
seamless
interrupt
draft,
so
this
draft
describes
a
procedure
to
do
seamless
interrupt
between
evpn
and
mep,
and
pe
the
same
procedure
can
also
be
used
to
do
optimized
inter
subnet
forwarding
with
an
evpn
fabric.
Oh,
this
is
a
old
slider.
I
H
Uploaded
the
new
slides
for
case
one
and
jeffries.
H
Okay,
so
so
this
draft
has
been
adopted
as
working
group
document
in
2019.,
so
in
property.
L2
eupmpe
was
not
covered
that
time,
so
this
has
been
covered
now
and
addition,
few
section
has
been
reorganized,
so
I'm
probably
I'm
primarily
covering
l2
vpn
evpart
right
now,
so
what's
needed
for
intra,
so
you
get
a
gateway
device
needed
to
reinterpret
the
l2
l2
uvp
is
your
turn
and
domain
can
be
provisioned
with
one
or
more
gateway
device
known.
H
As
you
know,
seamless
entrapy,
vpn
gateway
cpe,
which
is
configured
as
gateway,
must
be
provisioned
with
all
bds
that
are
available
in
the
tenant
system.
So
given
set
of
eligible
pds
ps1p
is
selected
as
a
df,
so
any
of
the
existing
evp
and
df
selection
procedure
can
be
used
for
this.
H
So
there
are
four
possible
use
cases
depending
upon
whether
the
remote
p
or
local
p
supports
igmp
mld
proxy.
So
it's
this.
This
can
be
supported
either
at
a
seamless,
entropy
or
remote
pe
or
you
know,
a
few
set
of
l2
evpn
pas.
H
So
there
are
four
cases,
but
primarily
we
will
just
you
know:
build
l2,
multicast
state,
either
by
smart
out
or
igp
control
plane
depending
upon
whether
the
remote
p
or
local
ps
supports
a
multi
proxy
draft.
H
So
operation
overview
so
given
set
of
you,
know
eligible
gateway
nodes.
One
node
will
one
node
will
be
elected
as
idea,
so
the
df
will
detect
a
remote
p
capability
and
based
on
that
it,
it
tries
to
learn
l2
multicast
state
either
3s
not
out
or
igmp
rpm
control
packets.
H
The
df
will
also
act
as
a
fr
for
sources
behind
l2
evpnp,
with
respect
to
other
seamless,
interrupt
capable
p
as
well
as
mep
and
pe.
So
the
df
uses
bump
tunnel
for
traffic
forwarding
towards
clp
vpnp
the
df
uses.
You
know
where
tunnel
or
mvp
internal
for
traffic
forwarding
towards
other
me
pnp
as
well
as
other
seamless
in
top
capabilities.
H
So
this
is,
you
know,
quick
overview,
so
so
I've
seen
that
so
here,
like
you
know,
the
blue,
the
blue
notes
are
seamless
in
drop,
cable,
p
and
p.
Four
and
p
e
five
are
seamless,
interrupt,
cable
p,
which
are
configures,
like
you
know,
gateway.
H
So
between
these
two
nodes,
as
in
the
techno
p5
got
elected
as
a
df.
Now
it
tries
to
send
smart
start
slot
out
to
pull
all
source
traffic
towards
dear
so
that
it
can
act
as
a
first
stop
router.
So
I
think
that,
like
you
know
now,
sources
are
tasked
behind
the
p
p,
eight,
so
as
soon
as
so
start
sending
traffic.
So
it's
going
to
send
traffic
towards
you
know
pe5,
so
pa5
will
start
advertising.
H
You
know
ipip
ip
vpn
and
evpn
host
routes
towards
evpn
fabric,
as
well
as
mpn
fabrics
with
associated
with
associated
with
import
community,
now
assume
that
we
have
a
receiver
behind
the
pe
one.
So
when
it
detects
mvpn
ac
routes,
it
starts
sending
mvpn
type
67
towards
remote
pe
and
it
start
pulling
the
traffic
via
verb
tunnel.
H
So
now
this
is
like
you
know,
for
l3
l3
case
now.
Assume
that
you
have
a
receiver
behind
pa7,
which
is
you
know,
lte
vpn
pe,
so
this
can
send
the
interest
to
df,
either
through
smart
route
or
igp
control
packet.
Depending
upon
whether
p7
support
you
know,
igp
proxy
draft.
H
We
are
just
learning
l2
multicast
state
at
pa5,
so
once
we
learn
the
state,
then
it
it
it's
try
to
create
a
l2
state.
Then
again
it
sends
a
request
to
irb
interface.
Then
we
will
just
create
your
three
state.
So
now,
when
p
is
eight
sends
a
traffic
towards
p5
see
it
does
like
a
local
routing
on
irb.
30
assume
that,
like
a
receiver
has
began
vlan
30
at
pa7,
then
after
routing
it
will
try
to
send
the
traffic
towards
the
pe
7
using
l2
state.
H
Now
so
this
is
about,
you
know,
source
behind
a
seamless
entropy.
What
will
happen
in
this
case?
It's
pretty
much.
You
know
pe
three,
since
p5
will
pull
the
traffic
from
p3
using
mepn
signaling
when
it
has
received
behind
the
pa7,
so
the
p5
doesn't
advertise
any
host
out.
Pe3
will
take
care
of
that.
H
This
is
about
new
flags
in
evp,
multicast,
extended
community,
so
this
multicast
flux
extent
community
is
defined
in
a
igmp
multiplexing
dropped,
so
bit
14
and
bit
15
are
used
by
a
gmp
multiplexing
draft.
So
now
we
have
proposed
two
additional
bits
for
seamless
interrupt
draft,
so
bit.
H
13
indicates
seamless
and
drop
capable
pe
and
b12
indicates
indicates
that
this
p
is
capable
of
you
know,
acting
as
a
gateway,
so
so
all
eligible
gateways
will
set
these
flags
and
one
of
them
will
act
as
a
df.
B
Okay,
okay,
so
can
you
try
and
wrap
it
up?
Please,
because
I
think
we're
out
of
time
on
this
one.
H
Yeah
yeah,
so
this
is
last
complaint:
okay,
so
yeah.
So
this
drought
has
been
around
for
almost
five
years.
Yes,
it's
widely
deployed
requesting
last
call.
If
there
are
any
comments
or
feedback,
we
will
just
sing
ticket.
I
Yeah,
very
quick,
so
the
bits
12
and
13
in
the
multicast
accident
community
are
taken
and
they
are
actually
used
in
in
two
drafts.
One
of
the
angus
and
last
call
the
oism
draft
so
yeah.
We
should
remove
it
from
from
this
draft
as
soon
as
possible,
and
the
other
comment
I
have
is
the
oism
draft
also
defines
procedures
for
l2
multicast.
You
know
interoperability,
so
I
wonder
if
you,
if
you
look
at
that
draft
for
that
specific
procedure,.
H
So
why
is
purely
based
on
evp
signaling
etcetera?
It's
here,
like
you
know,
we
are
just
using
anything
signaling
between
evp,
so
some
additional
producers
are
okay,
so
that
has
been
captured
here
so
with
respect
to
bits
yeah.
So
when
I
looked
at
last
time,
so
I
haven't,
you
know,
find
any
bits.
So
that's
why
I
just
you
know
took
it
yeah.
I
can
just
you
know,
take
a
look
at
that.
Then
I
can
just
move
the
bits.
A
G
Hi
should
I
should
I
share
my
screen.
Stephanie.
G
Perfect
so
I'll
be
presenting
draft
builder
best
evpn,
fast
reroute,
on
behalf
of
my
partners,
patrice
and
takuya
from
kddi.
G
So
this
draft
takes
a
look
at
evpn
convergence
solutions
that
exist
today.
B
G
How
convergence
is
achieved
for
evpn
deployments,
so
evpn
based
convergence
is
largely
control
plane
driven
today,
it's
it's
route,
scale,
dependent,
topology,
dependent
and
largely
depends
on
any
delays
in
the
network
right
raw
reflector
network
delays
and
so
on.
G
So
there
is
a
straightforward
solution
which
is
using
the
peers
service
label
as
an
edge
redirect.
However,
there
are
two
major
problems
with
this
solution
that
sort
of
has
been
floating
out
there
for
a
while.
G
The
two
problems
are
basically
that
if,
if
we
use
this
peers
service
label,
it
may
lead
to
loops
in
the
network
between
the
two
peering,
pes
or
extra
data
plane,
work
to
to
prevent
that
and
using
the
peer
service
label
for
redirects
actually
does
not
work
for
all
for
all
existing
load
balancing
modes.
G
So
with
that
premise
effectively,
e-10
convergence
can't
reasonably
meet
any
sub-second
or
you
know
even
more
stringent
than
sub-second
converged
requirements.
G
So
the
only
way
to
achieve
rapid
convergence
for
evpn
is
to
remove
the
reliance
on
the
control
thing.
So
what
this
means
is
effectively
local
failure.
Detection
at
pu1
and
local
failure,
restoration
at
pe-1,
where
then
the
control
plane.
So
then
the
crimp,
the
edit
procedures
would
kick
in
as
we
know
them
right.
The
edit
then
mass,
withdraw
and
the
correction
of
the
control
plane.
G
Addresses
you
know
rerouting
evpn
traffic
at
the
edge
in
particular,
I'm
gonna
go
over
issues
with
using
the
peer
service
label.
So
the
issue
of
the
continuous
reroutes.
If
multiple
failures
that
p1
and
p2
are
detected
and
in
the
second
step,
I'm
going
to
be
covering
effectively
rerouting
to
a
non-df
interface.
G
So
with
any
kind
of
reroute
active,
it's
it's
very
easy
to
observe
how
basically
pe
one
will
be
redirecting
to
pe
two
and
p2
will
be
redirecting
to
pe
one
and
and
that's
gonna
continue
until
you
know
it's
going
to
generate
a
traffic
storm
between
p1
and
p2,
and
it
will
continue
until
either
ttl
drop
or
or
forever.
G
So,
if
you
go
to
the
next
slide,
the
solution
proposed.
Actually
it
proposes
a
a
specially
allocated
downstream
label,
which
I
I
you
know.
I
call
the
reroute
label
and
what's
different
between
this
reroute
label
and
the
standard,
vpn
edp
and
service
label
disposition
is
in
standard
disposition.
Basically,
the
traffic
from
the
north
from
from
the
e3
to
pe1,
will
use
a
what
I
call
a
state-based
forwarding
chain
depending
on
the
ac.
G
So
if
the
ac
is
up,
the
traffic
will
be
get
sent
from
be1
to
the
switch
on
the
south.
If
the
ac
is
down,
typically
traffic
will
be
dropped,
but
if
I
use,
for
example,
the
peers
reroute
label,
the
ac
down
can
be
re-encapsulated
with
this
reroute
table
so
far
so
good
and
that's
basically
the
same
thing
as
the
the
proposal
using
the
service
label.
G
However,
by
using
a
specially
allocated
label
at
pe2,
the
the
disposition
of
the
reroute
label
at
pe2
of
the
once
rerouted
packet
is
terminal.
So
it's
a
final
disposition
right.
So
this
disposition
occurs
at
p2
of
the
packet
that
was
rerouted
from
pe1,
and
it
happens
regardless
of
the
ac
state.
The
packet
is
either
forwarded
or
dropped
into
the
ac.
G
So
if
the
ac
is
down,
pe
2
will
not
try
to
redirect
this
packet,
so
the
once
rerouted
packet
that
comes
in
with
this
special
label
will
will
now
get
dropped,
and
so
because
this
is
a
downstream
allocated
label
at
the
e2.
There
are
no
no
data
plane
modifications
required.
I
don't
need
to
change
anything
in
the
core.
G
G
There's
also
no
further,
no
extra
labels
on
the
stack,
so
I'm
not
adding
a
label
onto
the
onto
the
forwarding
stack.
It
just
replaces
the
service
label
for
the
traffic
from
pe
one
to
be
two
on.
B
G
G
What
what
you'll
see
is
effectively
pe3
sends
traffic
to
pe1,
which
is
down
so
without
a
reroute.
We
lose
traffic
at
pe
one.
If
I
use
this
reroute
label
or
if
I
use,
for
example,
the
the
service
label
p1
re-routes
to
p2,
but
I
haven't
really
gained
much
there
because
p
2
is
still
is
still
waiting
for
control
plane
to
convert
so
p.
2
is
still
non
dx
and
we'll
drop
the
re-routed
traffic
so
by
by
allocating
this
special
rerub
label.
Again,
it's
the
same
label
as
the
previous
use
case.
G
This
reroute
label
carries
effectively
a
context
of
the
fact
that
it
is
a
a
once
forwarded
packet.
It
is
a
reroute
packet
and
at
pe
2
it
has
a
special
characteristic,
allowing
it
to
bypass
the
collection.
G
So,
while
control
plane
is
busy
reconverging
over
to
pe2
this,
once
rerouted
packet
will
actually
bypass
df
election,
it
is
allowed
to
bypass
the
reflection
and
you'll
see
how
this
is
is
especially
applicable
to
load
balancing
modes
like
single,
active
and,
to
a
lesser
extent,
port
active
also.
G
So
the
traffic
ends
up
getting
rerouted
much
faster
than
the
df
election
procedures
and
but
then
rely
on
the
df
election
procedures
to
restore
traffic
using
the
what
I
thought
was
purple,
but
the
the
purple
traffic
path
from
pe
three
to
pe
two.
So
traffic
does
reconverge
and
takes
the
load
off
of
the
rear
up
path.
G
Next
slide:
that's
the
phone!
Please.
G
So
I
have
here
implementation
results,
so
the
table
in
this
slide
at
the
bottom
of
the
slide
highlights
the
typical
results
that
are
seen
with
an
implementation
of
this
draft.
So
this
is
storing
implementation
results
from
from
shipping
code
for
some
time
now,
and
you
can
see
actually
there's
two
things
that
I
that
I
want
to
highlight
on
this
slide
is
first
of
all.
G
By
using
this
reroute
you
can,
you
can
achieve
some
50
millisecond
traffic
restoration
and
the
other
important
part
to
that
sort
of
jumps
out
is
the
fact
that
this
plays
orthogonally
to
fast
recovery
procedures
right,
so
the
the
fast
recovery
in
blue
here
is
not
being
exercised,
but
that
is
the
other.
The
other
draft
that
is
in
working
group
last
call.
G
Yeah
so
who's
the
first
in
the
queue
hi
bo.
K
Hello,
hello,
luke
yeah.
Can
you
hear
me.
H
K
Firstly,
I
agree
with
your
proposal,
but
I
think
I
find
that
there
was
a
drought
of
team
general
before
I
think
we
may
go
general
doctor
named
fr
label.
Uepf
label
is
always
same
general
with
you.
D
So
I
have
a
questions.
A
couple
comments,
one.
You
know
an
evpn
fr
for
known,
unicast
traffic.
You
can
done
this
with,
as
you
mentioned,
with
a
special
label,
so
the
at
the
there's-
a
draft
presented
a
couple
ideas
ago,
but
was
using
specially
not
using
a
special
level
with
your
proposal
at
the
comments
is
you
also
need
to
consider
a
vlan
aware,
bundle
service,
and
if
you
have
a
forbidden,
aware,
bundle
service,
you
may
have
a
4k
bridge
domain
and
also
need
to
consider
the
label
allocation
scheme
was
used.
D
G
Label
can
be
per
bridge
per
ac
or
per
per
mac,
and
the
the
net
effect
would
actually
be
the
same
because
it's
a
it's
a
local
decision
at
pe
2
of
what
label
that's
allocated.
D
That's
right,
and
but
you
need
to
consider
in
that
case
once
and
especially
labeled
for
bridge
domain
or
labor
pro
evi.
This
is
it
has
much
to
do
with
the
forwarding
model.
Then
you
need
to
do
them
and
you
have
to
support
240
model
in
the
local
pe.
In
that
case,
maybe
it
will
be
convenient
just
to
make
its
implementation
simpler.
It
has
a
one
forwarding
scheme
on
the
egress
pe.
Otherwise
you
need
to
do
different
forwarding
scheme
because
of
label
allocation,
different
label
allocations
and
yeah
yeah.
This.
This
is
the
scale
concern
yeah.
A
Okay,
I'm
really
sorry,
but
we
have
to
to
together.
A
J
You
guys
hear
me
hello,
yeah,
okay,
I
think
we
lost
the
stephan
he's
still
there.
J
Okay,
great,
so
this
is
a
updated
version
for
the
secure
evpn,
rev05
and
nexus.
B
J
Hello,
okay,
so
a
little
bit
of
about
the
history
of
this
draft,
the
latest
rev,
the
main
difference
between
this
rev,
zero,
five
and
the
previous
river
f-zero
f03
that
was
presented
is
the
merge
of
ipsec
enemy
control,
ike
draft,
which
was
a
companion
draft
of
this
trap
into
here,
and
the
two
got
merged
because
of
the
synergy
between
them
to
have
a
one,
comprehensive
giraffe
that
covers
both
the
procedure
of
the
wreaking,
as
well
as
the
framework
and
the
architecture
for
the
security
vpn
and
the
bgp
routes
that
are
needed.
J
The
main
changes
relative
to
rev03
is
basically
the
addition
of
section
four
and
five
and
section
four
talks
about
the
generating
the
initial
ipsec
security
associations
and
the
section
for
the
two
gets
into
the
reking
of
these
sh,
and
it
covers
a
single
ip6
device
wiki,
as
well
as
the
multiple
reclaim
for
the
multiple
devices
section.
5
covers
ipsec
database
generation.
J
J
Another
change
in
here
was
the
correction
for
one
of
the
encapsulation.
It
covers
correction
for
the
diagram.
There
are
two
encapsulation
one
is
vx
landing
cab
within
the
esp
and
then
one
is
vxram
within
the
esp,
which
is
in
itself
incorporated
within
the
udp
figure
five
of
the
draft
in
the
previous
rev.
It
was
correct,
but
the
there
was
a
current
page
zero
and
we
corrected
that
that
issue
in
this
round
next
slide.
J
So
basically,
this
draft
has
been
around
for
a
few
years
and
it
has
been
stable
and
baked
and
after
the
we
were
waiting
for
merging
the
draft
with
the
other
one,
and
I
think
right
now
that
we
got
it
merge
and
everything
is
in
one
place.
It
is
ready
for
a
working
group,
adoption
co,
all
right.
That
is
the
end
of
my
presentation.
J
E
Ali
thank
you
for
merging
the
two
drafts.
I
can
see
that
there's
quite
a
lot
of
text
moved
in
from
the
draft.
I
will
ask
one
key
question
and
then
follow
up
with
minor
points
to
the
list.
The
main
question
is
how
much
dependence
does
the
web
of
trust
in
bgp
play
for
the
security
associations?
J
So
for
the
bgp
sessions
we
expect
the
bgp
sessions
to
be
completely
secure
and
either
to
be
done
via
the
tls
or
ipsec.
So
those
the
connection
between
the
pes
and
rrs,
the
bgp
connection.
It
is
expected
to
be
completely
secure
so
that.
F
F
B
E
I
I
I
So
domain
path
is
an
optional
transitive
attribute
it's
composed
of
a
sequence
of
domain
segments
where
each
domain
is
defined
by
a
length
and
a
sequence
of
domains.
I
You
see
here
the
format
of
a
given
domain,
including
the
domain
id
and
the
safy
type,
where
the
staff
type
can
be
evpn
ip,
vpn,
ip
or
zero
for
local
routes.
So
the
the
whole
idea
is
in
the
ip
vpn
vpn.
Networking
draft
at
each
service
gateway
with
an
ipverv
connecting
two
domains
can
actually
add
or
append
a
new
domain
for
the
routes
that
are
the
the
gateways
are
re-advertising
to
the
destination
domain
and
the
d-pad
has
impacts
on
you
know
the
control
plane
loop
protection
as
well
as
the
best
path
selection.
I
So
here
you
have
two
examples:
the
use
case.
One
is
basically,
you
have
a
bunch
of
gateways
that
are
interconnecting
different
domains.
So
p4
originates
a
route
and
route
i5.
It
goes
to
p3
p3
installs,
that
into
into
the
ipv
verv,
and
we
advertise
that
into
a
second
domain
in
an
and
route
and
when
it
does
that
it
slaps
a
d
path
with
a
with
domain
6500
column,
one
colony,
vpn
and
so
on,
and
so
forth
for
the
gateways
pe2
and
an
evp
and
p1.
I
So
the
idea
is,
if
p1
and
p4
they
have
a
backdoor
connection
or
a
peering
and
p1
re-advertises.
The
route
back
to
p4
p4
can
actually
recognize
the
one
of
the
local
domain
ids
as
a
his
own
local
domain
and
can
actually
prevent
you
know
re-advertising
back
the
route.
So
basically
it
drops
the
route.
I
A
more
you
know
simpler
case
is
the
use
case
two,
which
is
a
typical
data.
Center
gateway,
loop
protection.
I
Where
you
know
you
have
a
p1
advertising,
an
evp
and
route
type
5
to
gateways
one
and
two,
and
they
exchange
the
routes
in
an
ipvpn
address
family
and
they
because
of
the
you
know
the
domain
path.
They
can
actually
identify
a
potential
loop
and
they
do
not
re-advertise
the
role
back
to
the
evpn
domain.
I
So
what
we
are
doing
here
in
this
draft
is
use
the
d-path
for
non-intersecting
forwarding
evpn
routes.
In
particular,
you
have
here
the
some
details
for
the
mac
ip
advertisement
routes
when
those
routes
are
not
used
for
intersection
forwarding,
and
here
basically,
we
are
not
connecting
like
domains
as
defined
in
the
avp
and
ipdp
and
interworking
draft.
But
what
we
are
interconnecting
here
is
layer,
two
domains
and
the
layer.
I
Two
evpn
gateways
between
the
domains
are
actually
modifying
the
d
path,
and
here
we
also
use
the
safety
type
is
going
to
be
always
70
so
evpn,
but
other
than
that
the
gateways
will
will
use
similar
procedures
and
the
use
cases
are
typically
the
rfc9014
interconnect
gateways
and
we
can
reuse
this
attribute
to
detect
the
loops.
I
You
know
in
a
very
simple
way,
and
because
of
the
capabilities
of
this
attribute,
we
can
also
use
it
for
route,
traceability
or
best
path,
selection,
a
special
attention
to
section
4
and
0.2
in
the
draft
that
summarizes
the
current
best
path:
selection
for
mac
ip
routes
in
general,
so
I
should
be
looked
at
with
you
know
in
a
careful
manner.
I
Next
one
please
yeah,
so
I
have
two
examples
that
we
have
in
the
draft
here,
a
very
simple
one:
you
have
data
center
gateway,
one
and
two:
it's
a
for
an
evpn,
rfc,
9414.
I
Sorry,
nine,
zero
one,
four
interconnect,
so
a
mac
route
makes
it
to
data
center,
one
one
and
two
which
you
know
we
advertise
that
into
another
domain
and
because
of
this
attribute,
we
can
protect
the
loop.
If
you
go
to
the
next
next
slide.
A
I
It
took
a
while
for
my
screen.
Yes,
sorry
yeah
here
is
a
similar
example,
but
now
in
data
center
gateway
2,
you
have
a
local
attachment
circuit
and
an
se
connected
to
it.
So
you
advertise
that
macro
out
with
you
know
a
special
local
domain
id
and
you
you
know
the
data
center
gateway,
one
you
receive
both.
If
you
configure
the
same
domain
id
for
local
routes
on
both
data
gateway,
one
can
actually
drop
the
those
routes
immediately.
I
I
You
still
prevent
routes
because,
let's
say
data:
they
would
one,
for
instance,
selects
the
the
one
coming
from
domain,
one
it'll
re-advertise
to
domain
two,
but
now
you
know
appending
the
new
domain
id,
so
the
route
that
is
advertised
into
domain
2
will
have
domain
id,
1,
column,
1,
evpn,
comma
1.3,
column,
0.,
and
that
can
be
used
first
of
all
on
the
p
or
data
center
gateway
to
identify
that
this
is
coming
from.
I
You
know
it's
potentially
a
loop,
so
data
center
gateway,
two
is
not
going
to
advertise
that
into
domain
one
and
also
evpn
p2
can
take
that
into
the
best
path,
selection
and
use
the
one
that
was
pre
previously
advertised
by
data
center
gateway
2
directly.
So
basically
the
forwarding
will
be
properly
done
next
slide.
Please.
I
Yeah-
and
this
is
pretty
much
it
so
this
is
first,
you
know,
version
zero
zero.
So
we
are
looking
for
feedback,
so
any
any
questions
or
feedback
are
welcome.
J
Please
hear
me:
okay,
yeah
hurry
thanks
for
the
appraisal,
so
quick
question.
So
basically,
this
is
enhancing
the
procedure
in
rfc
9104
for
the
to
connect
two
domains
where
it
is
cover
over
there
in
here
we
can
expand
it
to
multi
beyond
two
domains
to
do
loop
prevention,
as
well
as
beta
selection,.
F
I
I
Yeah
so
so
in
revision02
was
presented
in
the
last
ietf
and
we
were
talking
about
three
different
use
cases
for
ipa
aliasing.
I
I
There
was
some
feedback
in
the
main
list
that
triggered
some
clarifications,
as
well,
in
particular
about
the
ethernet
segment
when
it's
used
as
a
layer,
3
construct
which
is
a
which
is
a
new
concept,
and
we
also
added
a
section
which
talk
talks
about
the
compatibility
of
ip
aliasing
and
the
unequaled
acmp
draft
next
slide,
please
so
yeah.
I
One
of
the
points
is
the
how
you
construct
this
layer,
three
ethernet
segment,
and
the
idea
was
that
for
this
use
case
three,
basically,
the
ethernet
section
is
really
defined
as
a
set
of
layer.
Three
links
that
are
connecting
the
multi-home
leaves
into
the
the
same
ce.
I
The
esi
in
this
case
should
be
a
type
four
using
the
router
id
of
the
multi-home
se
for
the
for
the
esi.
I
We
can
also
run
df
election.
If
we
have
single
active,
there
is
no
need
for
it
in
all
active,
but
in
single
active
yeah.
It's
a
it's
an
option
here
and
and
then
with
that
all
the
pec
routes
that
we
received
receive
on
the
ces
with
the
the
loopback
as
the
next
hop
I
mean
the
loopback
that
is
defined
for
this
ethernet
segment.
If
it
is
received
as
a
nexup,
the
re-advertised
routes,
type
5
will
use
the
associated
ethernet
segment.
Identifier
next
slide.
Please.
I
So
yeah,
so
the
draft
is,
it's
been
around
for
quite
a
bit
and
I
think
we
we
addressed
all
the
different
comments
and
you
know
and
feedback.
So
we
believe
the
yeah
is
definitely
ready
for
a
working
group.
Adoption.
C
C
C
So
let
me
start
with
the
background.
We
have
rfc
7524.
C
Which
is
about
mvpn
vpos,
inter
area
segmentation?
Basically,
a
provider
tunnel
from
p
to
p
consists
of
intra
area
segments
of
different
types
or
instances.
For
example,
you
can.
They
have
a
mlg
tunnel
in
area,
one
and
but
rcp
the
p20
tunneling
area
too.
The
way
it
works
is
that
area
border
routers.
They
they
work
as
a
route
reflectors.
They
modify
the
tunnel
type
and
identification
in
the
pins,
a
tunnel
attributes
that
is
attached
to
the
pins
a.d
routes
when
they
re-advertise
the
routes
to
the
next
area.
C
They
also
update
a
community.
It
is
called
segmented
next
hub,
extended
community.
It's
basically
another
protocol,
desktop
embedded
in
the
in
the
in
the
message
in
a
bgp
update.
So
that's
when
the
pes
send
back
when
they
need
to
send
back
leave
80
routes,
they
will
send
back
to
the
router
identified
in
this
community.
C
Now
that
is
limited
to
the
inter
area
case
and
also
limited
to
lsps.
Both
these
limitations
can
be
removed,
and
this
is
what
this
draft
is
about
next
time.
Please.
C
So
to
remove
this.
C
Area
limitation,
we
introduce
this
concept
concept
region.
So,
even
if
you
have
a
provider
network
is
a
single
area
flat
topology,
you
can
still
still
define
regions
actually
before
we
get
to
the
regions.
We
can
first
talk
about
how,
even
in
the
intel
area
case,
how
it
can
be
be
done
for
inter
area
to
modify
that
pnz
tunnel
attribute
and
that
extended
community.
C
Typically,
we
we
have
a
bgp
neighbor
group
so
that
all
peers
in
that
same
group
will
get
the
same
pta
and
and
that's
segmented,
next
hop
extended
community.
Because
of
this
pgp
neighbor
group
we
can.
C
C
C
So
that's
the
inter
region,
segmentation
now
the
next
one
is
we
can
actually
extend
it
to
intro
region
so
that
we
can
do
essentially
replication.
Here
is
an
example.
It's
too
bad.
I
cannot
use
animation
here,
but
we
have
three
areas.
Those
three
three
blue
clouds
there,
the
first
area
or
first
region,
is,
is
enlarged
to
show
where
the
focus
is.
C
What
happens
is
that
when
the
p1
advertise
the
pinzi
route,
it
gets
re-advertised
by
the
first
border,
router
there
when,
when
for
inter,
inter
region
well,
when,
when
the
border
rod
reader
prizes,
it
updates
the
panel
attributes
and
but
when
it,
when
we
read
the
prize
to
to
the
scene
into
the
same
region,
those
are
not
modified
now,
in
case
ingress
replication.
C
What
happens
is
that
all
the
pes
in
the
same
region
will
send
back
a
leaflet
route
directly
to
the
source
pe
and
then
the
source
pe
tracks,
those
leaves
and
and
then
what
do?
We
ingress
replication
to
all
of
them
now,
if,
if
we
in
extend
the
intro
reach
the
inter
region
segmentation
to
infrared
region
as
well,
basically,
when
the
when
the
first
abr
rbr
are
re-advertised
in
back
into
the
same
region,
it
also
modifies
the
tunnel
attributes.
C
C
So
this
is
a
show.
This
shows
that,
when
the
sp1,
which
is
stands
for
a
segment
point
segmentation
point
as
the
it
is
the
reasonable
order,
router
there,
it
re-advertises,
always
a
modified
tunnel
attribute
or,
and
the
extended
community
that
way
the
the
source.
C
Pes
the
the
pe
is
in
the
first
region
will
send
the
leaf
80
route
back
to
sp1
instead
of
pe
one,
and
because
of
that
now
the
p1
will
only
send
traffic
to
sp1,
who
will
then
relate
the
traffic
to
both
ps
in
the
same
source
region
and
the
next
in
the
next
region.
C
Another
issue
here
is
the
butt
node
support,
so
here
the
segmentation
point
the
stitches,
the
upstream
segments
or
downstream
segments.
This
is
done
by
a
label
swapping,
but
it
could
also
have
local
receivers
and
that
needs
to
do
ip
forwarding.
C
The
implementation
typically
can
replicate
the
incoming
package
for
both
label
swapping
to
downstream
segments
and
for
ipv4
and
local
vrs,
but
sometimes
a
particular
implementation
may
not
be
able
to
do
that.
Yeah,
it's
just
because
an
imitation
of
that
device,
so
it
needs
one
extra
copy,
so
one
copy
for
label
swapping
another
copy
for
ip40
next
slide.
Please.
C
So
this
is
about
optional
procedure
or
for
a
banner
to
request
an
extra
copy
for
local
ip4.
In
the
context
of
the
segmentation,
this
optional
is
only
accommodate
certain
bundles
with
with
the
limitation.
C
Now,
if
the
upstream
and
panel
segment
is
rcp
to
np,
then
the
rcpp
don't
be.
Signaling
can
actually
request
the
upstream
p-hop
nodes,
which
could
be
a
which
is
a
p
router
to
send
x
the
extra
copy.
Nothing
else
needs
to
be
done,
but
if
the
austrian
timer
is
increased,
replication
or
beer
or
mldp,
then
that
extra
copy
needs
to
be
tunneled
directly
from
upstream
pe
or
rbr.
C
It
cannot
be
done
by
a
core
router.
So
this
request
is
sent
by
by
a
tunnel
encapsulation
attributes
in
the
leaf
id
routes.
C
So
summary
is
that
the
inter
area
segmentation
is
extended
to
both
inter
region
and
intro
region.
This
does
not
require
a
a
new
signaling.
It's
just
that
for
intra
region
case.
The
every
border
router
needs
to
update
the
panel
attributes
and
the
extended
community
next
topic
extended
community
for
introducing
purpose,
and
then
it
allows
a
bundle
to
request
the
extra
copy
and
for
local
forwarding.
C
A
Ali
go
ahead
with
your
questions,
but
really
quick.
J
Sure,
jeffrey
thanks
for
the
prison,
quick
question
in
your
presentation.
You
didn't
cover
the
redundancy
when
we
got
multiple
gateways
for
the
enter
into
our
region.
Is
your
draft
covers?
You
know
the
redundancy
and
the
df
election
aspects
of
it.
C
7524
is
because
that
the
leafy
routes,
the
egress
pe-
will
only
pick
one
segmentation
point
as
upstream
so
and
send
the
levy
route
towards
that
one.
So
you
will
not
get
duplicate
traffic,
so
you.
C
Thanks,
so
this
draft
is
about
having
a
controller
using
mvp
and
evpn
for
provider
tunnel
discovery
presenting
on
behalf
of
my
co-authors,
rishabh
sandy
and
human.
This
is
actually
a
draft
that
is
two
years
old.
C
I
we
pres
we
published
that,
but
I
actually
didn't
present
it
for
a
while,
and
I
think
it's
time
to
to
try
to
move
this
forward
next
slide,
please.
C
So
let
me
first
summarize
the
potential
usage
of
a
controller
in
an
mvp
and
event
network.
The
first
one
is
that
is
the
calculation
and
the
signaling
of
the
provider
tunnels
it.
C
This
is
covered
by
two
drafts.
The
first
draft
is
basically
how
to
set
up
p2mp
srp2mp
panels
in
the
underlay,
and
the
second
draft
is
the
mvpn
evpn
sr.
P10P
always
talks
about
that
ingress.
Pe
collects
the
tree
information,
the
provider
tunnel
information
and
which
includes
root,
information,
leaves
and
constraints
and
then
pass
on
to
controllers
for
calculation
and
signaling.
C
Presumably
the
similar
could
be
done
for
year,
vpn
and
bomb
traffic,
but
I
I
had
not
talked
about
the
in
that
draft
yet
so
that
is
covered
as
in
in
the
bgp
multicast
controller
draft,
which
covers
art
things
as
well,
and
finally,
the
controller
could
actually
participate
in
the
mvp
signaling
to
collect
a
signal
provider
tunnel
information
at
the
overlay.
C
That
way,
we
do
not
need
the
ingress
pe
to
first
collect
the
tree
information
which
include
leaf
information
and
then
password
pass
on
the
controller.
The
controller
will
just
do
its
collect
the
information
itself,
and
that
is
what
this
presentation
is
about
next
slide.
Please.
C
C
You
could
have
inclusive
pinzo
selected
pnz
and
we
have
corresponding
av
routes
that
announces
tunnel
that
used
to
instantiate
that
pinside.
We
talked
about
that
ingress.
Pe
advertise
ipad
routes
and
then
they
may
track
leaves
explicitly
and
based
on
the
trapped,
leaves
the
ingress
pe
will
trigger
tunnel
setup
in
the
old
days.
If
you
use
rcpt
piton
b
tunnel,
the
ingress
pe
will
ask
the
rcp
module
to
set
up
the
tunnel.
C
C
Now
the
basic
idea
of
the
the
main
topics
for
this
draft
is
that
the
controller
will
do
the
tree
and
leave
discovery
by
participating
in
the
mp
mvpn
evpn
signaling,
to
collect
the
tree
information
here.
If
you
look
at
the
picture
on
the
right
side,
I
have
numbered
those
routes.
This
basically
indicate
the
the
sequence
of
the
events
or
which
corresponds
to
the
animation.
C
Now
the
first
step
is
I'm
using
the
spnz
example:
p1
advertise
spg
routes
and
the
controller
is
participating
in
the
signaling,
so
the
controller
gets
that
spg
route.
It
knows
that
oh
okay
for
this
spg,
I'm
using
this
provider
tunnel
with
the
root
id
and
tree
id
that
ingress
pe
gave,
and
then
it
re-advertises
to
other
pe's
in
step.
Two
now
pe2
and
p3
gets
that
sp
in
z
route
send
the
leaf
80
route
back
targeted
at
the
controller.
C
So
now
the
controller
knows
that
the
p2
and
p3
are
the
leads.
So
it
has
the
entire
information
the
tree
id
the
leaf
sets,
so
they
can
set
up
the
tree
using
the
controller
to
three
nodes.
The
signal
name
now
for
the
p
egress
p
to
direct
the
leaflet
route
to
the
controller.
C
Then
the
ingress
pe
will
attach
the
extended
community
to
the
pinz
route
that
basic
encodes
the
controller's
address.
So
now
the
panel
leaves
will
use
that
information
to
construct
a
raw
target
attached
to
the
dvd
route
so
that
it
can
be
targeted
that,
at
the
controller,
that's
the
basic
idea
next
slide.
Please.
C
Now,
in
the
previous
example,
the
ingress
pe
originated
origin,
the
initial
pinzi
route
now
for
ingress
pe
to
advertise
the
ping
routes-
it
typically
is
done
because
of
the
configuration
and
that
configuration
is
from
a
central
planning
entity
anyway,
ahead
of
time.
So
what
if
we
relieve
the
ingress?
Pes
from
that
burden
of
learning
that
configuration
and
advertising
those
png
routes?
C
We
have
the
controller
that
is
pre
loaded
with
all
the
information
and
that
is
planned
by
the
central
planning
entity,
and
then
it
will
just
advertise
the
pinsy
route
on
the
ingress
pe's
behalf.
So
now
you
can
see
that
in
the
first
step,
the
controller
added
has
the
pinzi
routes
and
then
the
other
pes.
They
will
send
back
the
leave
80
routes
when
they,
if
they
decide
determine
that
they
are
then
tunnel
leaves.
C
So
this
not
only
relieves
the
increased
p,
the
burdens
of
learning
the
configuration
and
advertise
those
routes.
It
also
makes
the
dcb
label
allocation
easier.
The
dcb
label
is
it's
basically
like
a
global
like
global
labels
or
similar
to
the
srgb
labels.
C
Basically,
all
the
p's
will
use
the
same
label
value
for
for
vpn
or
for
internet
segments,
so
they
are,
they
need,
they
must
be
allocated
from
the
common
block
by
a
central
entity,
so
that
could
be
the
controller
itself.
So
now
the
controller
has
all
the
information
and
and
to
advertise
the
png
routes
and
then,
with
the
dcp
label,
allocated
from
from
that
that
block.
C
There
are
some
special
considerations
when
the
tunnel
segmentation
is
used
next
slide.
Please.
C
So
in
in
previous
case,
we
talked
about
controller
advertising,
those
pz
routes
now
in
a
segmentation
case,
because
we
want
the
propagation
of
the
pinzi
rouse
to
follow
a
certain
order
to
go
through
all
the
segmentation
points.
So
if
we
don't
do
anything
special,
those
routes
may
be
propagated
out
of
order,
and
then
we
don't
get
the
benefit
of
segmentation
points
updating
those
attributes
we
talked
about
in
the
previous
presentation.
C
The
ingress
pe
is
first,
even
though
we
need
is
advertising
routes
on
behalf
of
the
ingress
p,
so
the
first
step,
the
controller
advertised
pin
the
router
was
p1
and
then
pu1
and
guess
it
and
then
turn
back
and
advertise
to
to
everyone.
Now
this
extra
step
is
achieved
by
manipulating
the
raw
targets,
so
I
think
I'm
going
to
skip
some
details
here
next
slide.
Please.
C
Yeah,
okay:
yeah:
can
we
get
the
next
slide?
Yeah
summary?
Yes,
so
we
talked
about
the
controller
advertising,
the
let's
participate
in
signaling,
including
controller
learning,
the
panel
id
and
new
information
and
all
advertising
the
png
routes
on
behalf
piece
and
that
allows
the
tcp
label
allocation
more
easily.
And
so
that's
the
idea.
Comments
appreciated.
L
Hi
everyone
I'm
yau
from
ct,
and
this
draft
is
about
the
issues
that
may
be
encountered
during
the
deployment
of
srv6
based
pgp
services
in
the
srv6
and
nprs
coexistence
scenario
and
the
possible
solutions
next
slide.
Please
and
the
best
srv6
services
draft
defines
how
pgp
messages
between
peas
may
carry
s36
services
to
10
to
form
vpns.
L
L
The
first
method,
srv6
services
are
encoded
as
a
hole
in
srv6
service
theories
and
the
mpls
label
field
of
the
corresponding
analyse
is
set
to
implicit.
Now,
the
second
method,
the
srv6
server
trv,
carries
only
the
locator
part
of
the
set
and
the
function
and
argument
part
are
encoded
in
the
ampere's
label
field
from
the
nri
next
slide.
Please.
L
P1
is
a
legacy
device
that
can
only
support
nprs
vpn
on
p3,
an
srv6
service
set
and
the
mpls
vpn
label
are
assigned
for
the
same
service
service
one
and
both
the
srv6
vpn
root
and
nprs
vpn
root
of
p3
are
sent
to
p1
and
since
p1
only
supports
mpls
vpn,
it
may
discard
the
srv6
service
tle
and
treat
the
srv6
we
can
root
as
an
nprs
vpn
route
for
service
one.
Then
there
are
two
mps:
vpn
rules
for
the
same
service,
one
on
p1
and
then
on
the
data
plan.
L
L
L
To
avoid
this
problem,
the
the
srv6
services
draft
suggested
suggests
that
implementations
should
provide
a
mechanism
to
control
advertisement
of
srv6
based
bgp
service
routes
on
open,
enable
and
upper
service
basis.
L
One
common
way
to
do
this
is
by
configuration
and
first
the
network
operator
should
obtain
whether
the
keys
are
capable
of
srv6
based
service
routes.
Then
the
operator
configures
some
key
or
neutral
factors
based
on
each
piece
capability.
The
penable
configuration
specifies,
which
piece
can
the
srv6
service
routes
psn
2.?
L
And
to
control
the
advertisement
of
srv6
service
rules
without
per
never
without
per
neighbor
configuration.
This
document
uses
a
simple
way:
it.
It
defines
a
new
capability
code
for
srv6
pgp
service
and
a
bgb
speaker
must
not
send
any
update
message
that
includes
the
srv6
service
tvs
on
a
particular
bgp
section
unless
it
has
sent
or
received
the
srv6
based
bgp
service
capability
in
the
open
message
on
that
session
and
like
other
b2b
capabilities.
L
M
So
this
is,
this
is
a
new
draft
which
basically
discusses
the
quality
of
the
information
that's
being
redistributed
in
evpn
and
in
particular,
we
are
trying
to
alert
community
that,
with
ipv6
slack
and
the
way
we
are
snooping
it
today,
in
our
networks,
we
are
probably,
as
we
say,
build
on
build.
We
are
probably
building
on
sale,
meaning
that
we
are
building
a
very
solid
architecture
on
something
which
is
not
solid
at
all.
M
If
you
think
about
the
hcpv4
ipv4
general,
we
can
build
something
solid
because
dhcp
is
stateful
and
we
could.
We
can
observe
the
dxcp
exchange,
make
sure
that
it
happens
in
both
directions
and-
and
so
we
can
reasonably
well
snoop
the
hcp
and
derive
a
state
of
which
ip
address
is
where
with
which
mac
address
and
then
inject
that
in
vpn
or
anywhere
else,
with
dhcp
v6.
M
Arguably
we
can,
we
can
get
same
result
and
have
a
reliable
state
that
we
can
inject
in
the
fabric.
Now
ipv6
comes
in
with
stateless
address
configuration
which
is
a
major
way
of
forming
addresses
and
as
opposed
to
the
hcp
slacks
stateless
thruster
configuration
is
not
stateful,
it's
not
deterministic.
You
don't
know
when
the
nodes
will
form
addresses.
M
You
don't
know
how
many
addresses
they
will
form
you
don't
you
have
no
idea
when
the
notes
release
those
addresses,
so
you
end
up
with
a
state
which
is
only
partially
valid
with
regard
to
what
the
host
really
wants
and
do,
for
instance,
there
is
this
case
that
we
call
a
silent
node
where
we
have
missed
or
forgotten
a
broadcast
like
a
duplicated
detection
that
message
by
the
host-
and
we
have
not
learned
that
the
host
has
this
address,
so
we
have
forgotten
it
and
there
is
no
way
it's
going
to
be
reformed,
and,
and
now
we
we
stay
with
a
missing
guy
and
because
it's
it's
me
saying
if
somebody
looks
him
up,
this
has
to
be
a
broadcast
the?
M
U
in
across
the
fabric,
which
is
really
something
we
don't
want
to
not
to
have.
Similarly,
when
the
node
ceases
to
use
an
address-
and
that
can
be
very
often
not
can
really
form-
maybe
say
an
address
per
day
and
release
one
address
per
day
and
maintain
like
seven
addresses-
that's
quite
typical.
M
We,
we
might
very
well
maintain,
addresses
and
state
neural
networks
for
addresses
which
don't
exist.
So
we
are
wasting
resources
as
much
for
state
as
for
bandwidth
in
the
case
of
consent
notes-
and
there
is
no
information
in
slack
about
when
the
device
moves
and
what's
the
order
of
movement
etc.
So
even
the
location,
the
latest
location
of
a
given
ip
address
is
uncertain
and
that
that's
just
for
maintaining
the
addresses.
M
But
the
fact
that
slack
realizer
broadcast
is
also
opening
not
only
to
to
too
many
broadcaster
fabrics
but
also
different
sorts
of
attacks
which,
which
can
be
very
harmful,
like
ddos
attack
against
addresses,
which
don't
exist
and
for
which
we
have
to
broadcast.
M
Another
angle
which
is
more
like
for
iot,
is
the
way
slack
is
built,
imposes
that
the
devices
defend
their
address
like
they
can
respond
to.
Now
they
can
respond
to
an
s
and
if
they
don't,
then
an
attacker
can
actually
take
over
the
address,
but
even
if
they
do
sometimes
the
attacker
can
take
over
the
address.
So
it's
it's.
M
The
end
result
is
when
you
want
to
deploy
a
solid
vpn
network
based
on
on
this
kind
of
unreliable
undeterministic
information
about
the
address.
Is
your
you're
bound
to
to
face
problems
in
the
field
in
a
lab?
It
will
work,
fine
and
then
someday
in
the
field.
You
will
have
those
very
hard
to
to
develop
situations
which
are
really
due
to
the
fact
that
you
don't
have
a
real
stateful
information
about
the
address
and
it's
much
appearing
next
slide.
Please.
M
Stephen
yeah,
so
this
is
just
a
reminder
of
what
I
just
said:
slack
is
prone
to
to
attacks.
We
can
have
band
flows
just
because
of
of
silent
nodes
which
can
exist
and
they
do
snooping
only
observes
a
portion
of
the
messages
as
no
concept
of
order.
So
we
don't
know
for
sure
where
the
last
location
of
this
address
is
and
if
it's
still
in
use
at
all
next
slide.
M
Now
the
the
atf
has
has
come
up.
You
know
in
it
started
in
cyclopaedia
working
for
iot,
because
really
iot
cannot
have
broadcast
just
the
way
even
fabric
scale.
So
there
was,
there
was
no
way
to
accept
all
those
broadcasts
and
the
iut.
Finally,
after
trying
went
for
a
stateful
approach
for
auto
configuration
and
that's
rca
505,
which
defines
a
mechanism
whereby
the
host
talks
to
the
router
and
agrees
with
the
router
that
is
going
to
have
this
address,
and
this
address
mac
mapping
and
there
will
be
a
lifetime.
M
There
will
be
a
unique
idea
associated
to
to
this,
meaning
that,
with
the
other
rfc
that
you
see
here,
eight
nine
two
eight
we
can
actually
check
when
the
address
shows
up
somewhere
else
in
the
network,
that
it
is
the
actual
user
owner
of
the
address.
So
after
sudan,
if
you
start
deploying
in
505
and
then
928,
there
cannot
be
a
not
rise
in
your
tables.
M
That
is
not
effectively
news,
you're,
not
missing
any
address,
because
you
have
an
effective
state
for
each
of
them
and
the
networks
cannot
be
stolen
and
because
you
know
every
damn
address
in
your
network,
if
there
is
a
ddos
attack
against
address
which
don't
exist,
this
can
indeed
else
well
that
one
will
just
fall
into
the
null
zero.
Basically.
M
So
this
brings
two
things:
a
state
for
reliable
state
for
each
and
every
address
and
a
secure.
That's
what
you
find
secured
in
in
the
title
of
this
draft,
a
secure
knowledge
that
the
the
guy
for
whom
you
we
inject
an
address
in
vpn
is
actually
the
owner
of
this
address
and
we
can
do
savvy.
We
can
filter.
You
know
traffic,
that
comes
from
a
guy
who
is
impersonating
somebody
else,
because
we
know
for
sure
where
the
owner
of
this
address
is
next
slide.
M
That's
okay!
I
don't
have
many
many
slides,
so
basically,
this
is
summary
of
what
I
just
said.
This
is
how
the
the
interaction
happens,
starting
from
bottom
right
and
not
auto,
configure
whichever
ipv6
address
it
wants,
but
instead
of
doing
that
waiting
one
second
extra
involving
a
broadcast-
it
just
tells
the
router
mr
router,
please
can
I
have
this
address
the
router
checks
step
three
based
on
policy
bla.
M
If
this
guy
cannot
decentralize,
it
goes
through
the
distributed
database,
which
is
a
vpn
whether
this
address
already
exists
and
because
we
have
parameters,
we
we
know
if
it's
if
this
address
already
exists,
if
it's
the
same
owner
and
it
has
moved
if
this
is
the
most
recent
position
or
if
it's,
if
it's
a
different
under,
in
which
case
it's
duplicated,
we
have
to
reject.
So
we
have
all
this
information
available
without
doing
anything
on
the
network
next
slide.
Please.
M
So
this
is
more
detail
than
the
previous
slide
about
how
stateful
address
configuration
works,
but
basically
that
there's
always
an
abstract
registrar,
a
whiteboard
where
we
list
every
address
every
mapping
and
as
it
goes,
the
vpn
is
a
perfect
example
of
of
how
this
it
can
be
operated
as
a
distributed
database.
Next
slide.
M
M
We
have
this
uni
direct
interaction
with
the
host
and
we
we
have
to
modify
the
mac
mobility,
excellent
community
and
we
provide
backward
compatibility
with
the
existing
operation
and
with
the
modified
mac
mobility
exam
community.
We
provide
this
this
rover,
this
proof
of
ownership,
actually
the
hash
of
it
and
the
tid,
which
is
the
sequence
counter
and
based
on
those
two
information.
M
We
can
effectively
discover
if,
if,
when
the
guy
shows
up
somewhere
else,
it's
the
same
with
a
fresher
sequence
or
if
it's
a
different
in
because
in
which
case
we
can
say
duplicate
without
going
through
the
exchanges
that
exist
today,
and
I
think
I'm
done
but
next
slide.
I
think
that's
it.
Yes,
that's
it
so
ready
for
four
questions.
I
Yeah
pascal,
thank
you
thank
you
for
this.
You
are
actually
extending
the
mac
mobilities
in
the
community.
However,
rfc
9047
defines
a
new
extended
community
that
is
especially
for
arp
and
naval
discovery
protocol
things,
and
so
I
wonder
why
you
didn't
use
that
one.
Instead
of
the
mac
mobility,
extender
community
seems
more
appropriate.
M
M
Okay,
if
you
could,
if
you
you
know,
it
would
be
very,
very
neat
if
you
could
look
at
what
we
have
today
in
this
new
extended
community
and
propose
a
way
to
use
the
other
one
and
how
we
would
structure
it.
That
would
be
really
appreciated.
I
M
And
and
think
about
the
background
compatibility.
What
what
key
aspect
here
is
once
we
supported
five
or
five
yeah
and
we
face
someone
who
does
not,
we
need
to
sort
out
who's
the
winner,
and
normally
we
say
guys
who
supported
five
or
five,
since
they
can
prove
their
stuff.
They
are
the
winners,
and
so
so
we
we
played
with
the
the
writing
of
the
sequence
in
such
a
way
that
the
net
fight
for
five
tier
live
sequence
always
is
always
a
higher
number,
then.
So
that's
why
it's
on
the
left.
I
M
We
basically
added
a
few
flags
just
to
notify,
for
instance,
that
we
do
effectively
check,
for
instance,
the
source
address
validation
right
with
this
rover
thing,
which
is
the
ownership
token
that
that
is
actually
the
rover
is
actually
a
rover
and
stuff
like
that.
So
so
we
have
to
lose
like
four
or
five
sticky
bits.
M
K
A
K
K
K
We
may
use
spfd
to
detect
the
pe
failures
quickly
for
direct
deployment
for
spft
for
activity
for
network
reflector.
When
we
use
sid
address
as
a
duplicator,
so
we
can
simply
simply
simplify
operators
calculation,
but
for
ipv6
network,
the
determinator
for
each
destination
pe
had
to
be
remastered
conflict
manually
there.
Also
two
rc
7883
and
7884
define
the
easy
and
the
odpf
extension
to
flood
the
spfd
meter.
K
Page
three
please,
there
are
the
the
here
is
the
first
central
the
service
for
the
service
over
srv6b.
K
There
are
two
areas
that
the
inter-domain
center
row
and
also
it
may
be
also
used
for
s
for
intro
to
make
p1
p2
and
advertise.
There
are
vpn
roads
which
contain
the
v6
vpnc
to
p3.
The
tropical
arriving
at
p3
will
be
forwarded
to
p1
or
p2
based
on
sr6
locator.
Reachability
p3
needs
to
create
the
fbx
session
to
detect
the
p1
and
p2
the
locator
reachability
for
each
spf
session.
K
In
introducing
the
nodes,
maybe
create
a
redundant
with
redundant
sprv
session,
because
the
idp
planning
will
fly
into
every
node
page
4.
Please.
K
For
center
center,
two,
there
is
a
service
over
srv6
policy
in
this
central
is
similar
to
the
central
one
so
and
also
it
can
be
used
for
intro
domain.
The
we
can
also
also
advertise
from
p1
and
p2
to
p3,
and
but
they
are
in
this
scenario,
they
will
use
their
ipv6
loopback
address
as
a
network.
The
traffic
arriving
at
the
p3
will
be
folded
based
on
the
srv6
policy.
Reachability
and
p3
may
be
created
as
vip
session
to
detect
the
p1
or
p2
reachability.
K
For
each
session
there
we
may
use
the
remote
heavy
address
donation
to
p1p
to
the
loopback
address
and
configure
the
also
manual
configure
the
discriminator
tool
for
the
svl
session
in
practice.
In
practice,
this
scenario
is
not
limited,
limited
to
srv6
policies,
and
they
also
maybe
applies
to
npr's
general.
K
This
is
our
the
our
extension.
We
may
use
the
bb
extension.
We
may
reuse
the
pft
discriminator,
that's
built,
which
is
that
is
defined
in
the
what
I've
said:
9026
it
has
defined
as
the
type
38
we
now
we
introduced
the
two
new
bfd
modes.
The
type
one
is
spld
for
srv6
locator
session.
This
is
only
used
to
detect
srv6
locators
and
in
this
mode
we
may
use
the
optional
trv.
We
are
container
as
a
source
appear
just
rv,
which
contains
the
srv6
locator
address
and
also
we
may
introduce
another
type
2.
K
Another
type
of
vld
mode
means
spfd
for
comment
session.
In
this.
In
this
type
mode,
we
may
use
the
the
user
to
detect
a
rows
net
hope
this
mode
can
be
used
for
both
ipv4
and
ipv6.
The
optional
tov
will
container
source
ip
address,
carry
which
contains
a
network
address
page
six.
Please.
K
This
is
this
is
a
proceed,
proceed
procedures
first
photo
of
the
advertising
pdp
speaker,
the
vpn
roads
may
advertise
with
a
local
designator
and
carried
in
the
brd
discriminator
attribute.
Then
the
dmd
mode
is
set
to
one
of
the
new
modes
defined
for
the
receiving
bb
speaker.
We
will
use
the
discriminator
to
notify
the
bfd
model
to
create
a
sblv
session
for
mult
type
well
known
for
known
for
model
mode.
One.
The
locator
characters
in
the
source
address
carry
used
as
the
destination
of
the
sbi
session
for
the
model
2.
K
N
If
we
can
go
back
to
the
previous
slide,.
N
My
question
and
I
tried
to
express
it
in
the
comments
before
the
meeting.
Was
it's
not
clear
how
dfd
control
messages
are
encapsulated,
so
are
they
encapsulated
with
the
same
as
a
traffic
over
the
service,
6
policy,
or
something
else
so
the
receiving
speaker?
K
Okay,
okay,
because
I
have,
I
have
received
more
much
comments
for
you
from
you
yeah.
I
see
that
we
may
describe
not
very
clear
for
this
general.
We
may
describe
it
more
clearly
after
after
this
meeting
and
we
may
update
our
our
jobs.
Okay,.
N
Yeah,
yes,
because
thank
you,
yeah
bfd
is
not
really
able
to
differentiate
between
the
path,
value,
failure
and
the
node
failure
of
endnote.
So
I
think
that
that's
something
to
be
aware
of
and
understand
of
what
is
possible
to
track
and
what
you
are
really
monitoring.
N
Another
note
I
want
to
add
is
that,
because
of
evpn,
you
might
find
that
you're
duplicating
you
have
twice
as
many
as
bfd
sessions
as
you
would
have.
If
you
use
a
bfd,
because
if
each
of
the
pe's
involved
advertise
its
own
discriminator,
then
other
pes
will
start
as
bfd
sessions.
So
you
are
multiplying
by
two,
the
number
of
bfd
packets
being
in
the
network.
B
B
Yeah
I
just
had
thanks.
I
I
just
had
a
sort
of
generic
comment
really
about
where
this
lives,
because
it
wasn't
clear
to
me
looking
at
the
draft
if
the
primary
objective
is
simply
advertising
or
flooding
the
the
reflector
discriminator
in
in
bgp
or
if
it's
also
defining
these
new
session
types
for
particular
services.
If
it's
simply,
the
primary
function
is
just
to
is
to
have
a
mechanism
in
bgp
to
flood
the
reflected
discriminator
similar
to
what
we
have
in
in
the
igps.
B
I'm
not
sure
it
really
lives
in
bet
that
part
of
it
and
if,
but
secondly,
if
you're
defining
your
spft
session
types
for
particular
services,
we
also
probably
need
to
talk
to
the
bfd
working
group.
O
Hi
sorry
microphone
issues.
Jeff
house
is
a
bfd
chair.
I
I
think
the
reason
why
they're
answering
matthew's
comment
had
originally
gotten
broached
as
part
of
a
bfd
attribute
that
originally
was
done
as
part
of
best
work,
which
I
suspect
is
why
it
is
being
brought
to
your
original
attention
we'll
be
taking
a
look
at
this
draft
and
you
know
if
it
needs
to
move
over
to
bfd.
That
will
be
fine,
but
we'll
have
to
take
a
look.
What
the
scope
of
it
actually
is.
Okay,.
M
A
B
They're
only
yeah
yeah.
B
Yeah
he
says
he
has
a
problem
on
the
chat,
but
not
sure
what
the
problem
is.
B
B
A
A
A
P
P
Fixed
rfc
9136
bumping,
the
where
user
keys
centralized
floating
is
adopted
for
intra-subnet
communication.
That
means
our
inter-subnet
flow
must
be
proceeded
by
dc
guitarist.
This
will
put
in
the
dgws
in
order
to
decrease
bgw
pressure
distributed
forwarding
should
be
considered
for
intra-subnet
communication,
especially
when
awes
have
the
capability
of
fpvr
flooding
next
speech
police.
P
Thank
you,
for
example,
distributed
community
communication
between
sn2,
and
I
think
I
think
one
and
the
distributed
communication
between
sn2
and
h3
are
expected,
however,
mve2a
and
me
to
only
have
microwave
according
to
fc9136,
so
they
have
no
ap
routine
tables.
This
thus
directly,
inter
subnet,
can
not
be
supported
next
page.
Please.
P
We
can
configure
our
ipvf
instance
to
hme
in
order
to
activate
their
inter
forwarding
capabilities
on
this
species.
We
can
go
a
step
further
to
achieve
the
distributed,
inter-subinator
flooding
behavior
in
this
case
the
advertisement
of
the
rt1
providers
of
esa
2
3-
should
be
changed
from
rc
9136,
because
av-8
don't
have
an
instance
of
bd10
as
a
aileros
treated
in
this
figure
when
av2
advertises
rt1
at
av2
at
10
for
bd10
and
when
av3
advertise
rt1
at
av380
for
bdt.
P
These
rt1
rules
are
both
advertised
along
with
an
actual
target.
The
extruded
target
is
exported
to
the
target,
subliminal
bd,
havee
and
hdw
should
be
configured
with
that
spd
instance
as
a
result
that
extra
root
target
these
two
rt1
artillery
will
be
imported
into
the
spd
by
ave,
8
and
the
dc
guitarist.
Then
the
corresponding
data
package
can
be
sent
from
av-8
spd
to
av-3s
bd3,
without
passing
through
every
series,
ipvf
instance
and
next
speed.
Please.
P
As
illustrated
in
this
figure,
multiple
synthesized
bumper
in
the
air
instances
are
integrated
into
the
same
fpf
when
ddgw1
receives
a
rt5
root
from
one
one
instance,
acsa
cannot
be
resolved
in
the
context
of
another
pump
in
the
world.
Instances
take
the
rt5
root,
rt5
and
sn1,
for
example,
when
it
is
received
by
dw1
before
ecs
is
resolved.
Dgw
one
shouldn't
do
that
acsn
must
be
resolved
in
the
context
of
bd10.
P
P
Thank
you.
In
such
cases
the
rt1
prevails.
Rt188,
mve283
and
rt1
is
3,
rt1,
8,
ev2,
820
and
rt1
me
3810.
We
will
both
be
advertised
for
the
sim
esl
and
their
ethernet
tag.
Ids
may
both
be
0
in
case
of
vlan
based
service
interface.
P
P
But
in
order
not
to
interfere
the
mac
forwarding
of
btt,
we
should
rely
on
advertising
two
different
artie
roots
for
the
sim
aco.
The
first
one
is
advertised
in
pdt
for
mac
14..
The
second
one
is
advertised
in
the
spd
for
fp
forwarding.
Only
the
secondary
the
internet
technology
should
be
set
to
work.
Yeah.
A
P
P
Yes,
yes,
I
think
the
rt5,
which
is,
for
example,
rt588
s1,
for
example,
it's
l3
out
interface
in
the
rb
interface,
so
ecsa
must
be
resolved
in
the
routing
table
of
the
broadcast
cast
domain.
Behind
that
rb
interface,
then,
as
illustrated
in
the
tables
on
the
left
side,
we
can
use
the
esa
and
soa.
It
was
at
rt5
at
sn1
to
do
recursive
router
resolution
in
the
spd's
routine
table
after
the
recursive
router
resolution,
two
rt1
prevails
will
be
selected
as
rt5
at
suv.
P
A
You,
okay,
so
yeah!
Thank
you
all
for
your
attendance
and
yeah.
Let's
look
at
the
next
atf
hoping
it
could
be
a
physical
meeting.