►
From YouTube: IETF99-BESS-20170720-1550
Description
BESS meeting session at IETF99
2017/07/20 1550
https://datatracker.ietf.org/meeting/99/proceedings/
A
You
are
so
silent
good
afternoon.
Everyone-
and
this
is
the
best
session
in
Prague,
sorry
for
the
minute
lost
at
the
beginning,
I'm
alone,
but
Thomas
is
here
remotely
the
new
note.
Well,
please
wow
I
guess
you
know,
but
please
take
a
look
at
the
latest
version
of
that
slide
and
the
latest
RFC's,
which
it
mentions
very
quickly.
I'd
mean
I'll,
send
the
blue
sheets.
A
A
Ali
sent
Olli
slides
late,
but
since
he
was
the
only
one
at
the
at
the
bottom
of
the
of
the
agenda,
it
didn't
lead
to
any
agenda
change
time.
Management
will
try
to
be
a
bit
strict
and
if
anyone
can
help
me
in
taking
minutes,
I'm
fine
I'd
be
I'd,
be
glad,
but
I
can
live
without
it
very
rapidly
because
we
don't
lose
time.
We
don't
have
any
new
RFC
for
nine
month,
which
is
quite
a
while,
but
not
stressful,
but
we
have
20
to
work
in
hope.
A
B
B
With
respect
to
one
of
them
just
clarify
the
III,
you
had
a
comment
on
the
and
adding
the
IANA
code
request
in
the
draft
and
I
did
that
that
I,
it
was
just
a
couple
of
lines
of
modification
and
I
would
appreciate.
That
is
a
very
quick
check.
If
you
can
check-
and
you
know
give
a
check
mark
on
that
and
then
the
EVP
and
overlay
takes
much
longer
to
review
so
that
one
you
know
you
can
do
it
as
your
timer.
B
A
So
it's
a
bit
unusual
but
we'll
be
talking
about
meap's
I've,
always
wondering
why.
But
we
like
work
to
be
finished
cleanly,
so
we
had
to
mips
and
nobody
wanted
to
work
on.
This
they've
been
couple
of
people
trying
but
never
managed
to
go
a
bunch
on
the
end,
but
we've
su
no
volunteer
and
who's
going
to
do.
A
quick
update
is
working
very
hard
in
addressing
these
charter
items
or
milestones.
G
The
I
am
preparing
the
latest
draft.
According
to
the
latest,
meet
doctors
review,
so
I
think
new
pattern.
New
revision
will
be
submitted
after
this
ITF
meeting
for
the
second
one
BDP
Imperius,
raya,
3bp
and
birch
cosmic.
So
the
you
see
the
the
discussion
in
the
mailing
list.
The
doctor
suggested
ask
to
reconsider
the
design
of
me
modules.
So
please
understand
dubs.
Some
more
revision
will
be
required
to
finalize
this
draft.
G
So
I
really
try
to
give
some
comments
from
the
especially
technical
point
of
view
for
this.
The
second
draft
and
I
would
like
to
confirm
the
purposes
of
this
mod
gives
me
modules
so
for
the
first
one,
the
purposes
of
the
modules
is
to
provide
the
textual
conventions
to
represent
the
tonal
type
internal
identifier.
G
The
purpose
is
the
purpose
of
the
second
to
me
is
to
monitor
the
operational
information
of
the
l3
VPN,
much
cast-on
provider
edge
routers,
and
to
configure
em,
brf's
and
EMS
ID
on
the
provider,
ID,
shelters
and,
of
course,
to
provide
the
notification
mechanism
to
the
network
administrator.
So
this
is
my
understanding,
so
please,
let
me
know
if
my
understanding
is
not
correct.
H
G
G
According
to
the
doctor
comments
he
said
there
is,
there
may
be
some
the
program
in
the
coverage
of
my
modules,
so
actually
the
second
one
busy
p.m.
virus
l3
VPN
much
just
means
currently
does
not
have
information
object
to
represent
the
this
information
components.
So
I
think
these
are
required
for
managing
and
configuring
the
l3
be
within
March
cast.
So
I
am
thinking
to
add
the
management
object
for
representing
this
vehicle.
G
These
variables
into
the
mid
definition
so
what's
next
is
I,
am
really
seeking
the
input
from
the
working
groups,
so
especially
from
the
technical
point
of
view.
I
am
NOT
an
expert
in
this
area.
So
please
give
me
some
comments
so,
for
example,
if
there
there
are
any
information
that
should
be
included
in
or
removed
from
these
mid
modules,
so
pre,
let
me
know,
and
as
especially
the
comments
on
the
use
case
scenario
of
me,
modules
they'll
really
help
for
me,
so
anything
I
would
like
to
keep
working
to
finalize
these.
I
Configuration
variables
great
limit,
BGP
messages,
don't
do
that.
Oh.
F
J
K
L
You
thank
you
for
those
four
minutes.
59
seconds
you've
ordered
me.
I'm
agent,
Farrell
I
just
want
to
do
an
update,
update
on
draft
great
best
data
center
gateway,
mainly
because,
although
the
file
name
says
data
center
gateway,
this
is
really
now
segment
routing
enabled
domain
gateway
as
follows.
So
when
we
started
this,
we
were
interested
in
data
center
sites
that
were
running
on
segment
routing
and
wanting
to
connect
across
non
segment.
Browsing
back
backbones
or
certain
granting
backbones.
L
We've
revised
that
just
to
generalize
the
concept
for
any
domain
that
is
segment
route,
incapable
largely
speaking,
that
required
a
global
search
and
replace
in
the
document
and
not
very
much
else.
Apart
from
going
back
and
looking
at
all
the
changes
and
say
no
I
didn't
mean
that
one,
the
work
is
stable.
L
L
A
reference
model,
a
picture
two
domains
that
are
during
segment
routing
and
some
backbone
made
up
of
one
or
more
ases
with
multiple
roaming,
and
we
want
to
be
able
to
steer
traffic
right
the
way
across
from
a
source
in
one
domain
to
a
destination
in
the
other
domain.
So
we
want
to
do
segment
routing
end
to
end
and
an
actually
traffic
engineer
how
that
traffic
goes
across.
Those
AES
is
which
points
of
interconnection
it
uses.
L
So
there
are
two
aspects
we
have
to
handle.
One
is
gateway
discovery.
How
do
you
know
what
other
gateways
are
out
there?
Firstly,
what
are
the
gateways
to
your
own
domain
and
what
are
the
total
set
of
gateways
that
are
that
are
out
there
and
providing
rich
ability
into
domains?
Very
briefly,
we
use
a
route
target
to
autodiscover
and
we
then
install
import
rules
so
that
only
the
gateways
to
a
domain
import,
the
routes
to.
L
So
the
whole
magic
is
when
a
gateway
to
a
domain
discovers
other
gateways
to
the
domain.
It
actually
also
adds
those
to
its
advertisement.
So
back
in
the
original
picture,
there
are
multiple
ASAS
BRS
along
path
and
they
might
start
dropping
paths
because
they're
not
optimal.
Well,
you
want
that
information
to
make
it
all
the
way
through.
L
We
need
to
make
a
first-come-first-served
code
point
request,
which
will
obviously
involve
us
also
talking
to
IDR.
It
would
be
silly
for
us
to
make
protocol
extensions
here
without
talking
to
IDR,
and
we
would
like
more
reviews,
especially
as
I
said
in
the
context
of
the
document.
That
gives
much
more
background.
L
M
Memories,
I
have
one
comment:
there
is
an
alternative
solution
to
this,
which
is
being
so
nice,
which
is
the
BGP
as
RTE
policy
framework,
which
is
being
discussed
in
I,
think
segment
in
spring
and
in
IDR
as
far
as
I'm
aware,
and
that
does
actually,
if
the
use
case
is
traffic
engineering
between
data
centers
end
to
end
with
segment
routing.
That
is
actually
what
it's
also
supposed
to
do,
and
it's
using
bindings
it's
and
stuff
like
that.
L
M
I,
what
my
personal
view
is
that
the
as
of
the
policy
framework
is
even
I.
You
have
more
options,
or
even
it's
more
extensive,
because
you
can
have
even
multiple
paths
across
multiple
pieces
of
the
network
and
you
can
actually
do
even
more
complicated
traffic
engineering
than
what
you're
suggesting
here
in
my
view,
but
we
probably
need
to
go
to
the
details.
Yeah.
L
I
think
we
might
we
might.
It
might
be
worth
looking
at
looking
at
that
in
the
context
of
the
the
new
spring
document
that
that's
on
this
slide
and
just
saying:
okay,
so
that's
actually
what
John
and
Adrienne
are
trying
to
do
so
would
the
would
be
BGP
srte
solution
achieved
that
as
well
right,
yeah.
M
I
At
Jeff
foul,
so
they
addressed
that
last
comment.
The
te
policy
document
is
really
more
about
traffic
string
of
different
types.
So
it's
really
about
tunnel
selection
to
be
all
the
foot,
traffic
is
physics
I
found
there
and
to
bind
those
tunnels
to
know
the
individual
each
be
routes.
So
it's
it's
potentially
usable
in
some
of
the
same
context
is
this,
but
the
only
sense
that
both
of
these
are
sort
of
BGP
and
SR
and
no
view
of
the
network
can
let
you
do
this.
M
I
Crude,
what
your
visibility
points
change
a
little
bit
and
that's
a
lot
of
work,
this
back
of
its
getting.
You
is
visibility
more
than
in
terms
of
choosing
how
to
bind
the
traffic
so
T.
The
T
policy
is
about
colors
on
the
routes.
That's
really
winsome
yeah,
but
also
the
de
part
of
it.
That's
true
yeah.
So.
M
M
M
B
N
L
B
L
L
L
B
O
L
P
Hi
I'm
Lou,
burger,
I'm
gonna
be
giving
an
update
or
an
impact
discussion
on
how
the
network
instance
model
work.
That's
taking
place
in
the
round
working
group
is
going
to
impact
layer,
two
and
late
layer,
3
VPN
device
models
for
context.
We
have
broken
down
the
representation
of
virtualization
that
happens
on
network
devices
into
two
things.
We
have
something
called
logical
network
elements
which
are
separable
separately,
managed
partitions
of
a
device,
and
then
we
have
network
instances
that
we
use
to
model
burps
and
BS
eyes,
layer,
2
and
layer,
3
VPN.
P
I'm
gonna
try
to
skip
a
bunch
of
slides,
but
I
want
to
say
one
thing:
that's
important
here
we
model
both
using
a
new
capability
within
yang
called
schema
mount.
What's
even
mount
allows
you
to
do
someone
else,
use
this
analogy.
I
really
like
it.
You
use
a
whole
module.
You
treat
a
whole
module
as
a
grouping,
meaning
you
can
import
a
whole
module
and
a
different
place
in
the
tree
and
that's
what
we're
using
here
is
a
fundamental
building
block.
There's
a
tree
representation.
You
can
read
about
it.
P
Here's
our
basic
model.
We
have
something
called
a
network
instance.
It's
a
top-level
module,
you'd,
see
it
that
the
root
of
a
device-
and
we
instantiate
what
we
call
it
a
network
instance
pervert
or
for
vsi.
We
have
an
ni
type
network
instance
type
that
we
would
expect
to
be
specific
to
every
layer
or
layer,
3
VPN
technology.
P
So
if
you
have
something
that's
specific
to
bgp
layer,
3
VPN,
it
would
go
here.
If
you
were
gonna,
do
a
VPN
it
would
go
here
is
a
different
type.
This
is
really
the
PE
information
PE
facing
information
used
to
support
her
4
vs
I
in
order
to
support
the
modeling
of
information.
That's
in
the
network
instance
context
in
the
birth
context
and
this
in
the
seee
context.
We
produce
something
called
these
route
types
you
can
have
one
of
these
and
it's
an
implementations
choice
which
they
use.
P
You
can
read
the
draft
as
why
we
have
three:
that's
really
a
yang
ism,
but
logically,
you
can
think
of
there's
a
place
where
you
drop
your
verb
or
vsi
representation.
This
is
again
what
would
be
used
to
model
the
information
that
goes
to
the
seee,
the
seaside,
and
that
is,
you
would
put
there
any
top-level
module
so
oops.
P
Somehow
there
we
go
so
what
do
I
mean
by
a
top-level
module
underneath
a
l3
VPN
instance?
We
would
have
some
l3
information
that
would
go
in
the
PE
facing
side
and
you
have
put
routing
information
underneath
the
ver
fruit
and
you
could
have
OSPF
if
you're
running
OSPF
between
the
PE
and
C
II
didn't
even
have
rip.
If
you
really
want
it
or
bgp
or
whatever
protocol
makes
sense.
P
The
schema
mount
has
a
notion
of
instantiating
new
data
through
this
scheme
amount
mechanism,
so
every
instance
gets
its
own
piece
of
data,
even
though
the
schema
is
the
same.
The
data
in
it
is
instantiated
per
in
this
case
Network
instance.
The
data-
that's
reinstated,
has
a
slash
after
it
that's
mounted
modules.
You
can
also
from
a
there's
a
yang
ISM
again
the
ability
to
you
can
reference
information
from
within
this
context
to
information.
That's
outside
the
context.
P
For
example,
you
could
have
something
inside
OSPF
referencing
the
interface
information
at
the
top
level
through
something
called
a
parent
reference,
I
think
of
it
as
a
symbolic
link.
That's
why
it
looks
like
an
app.
So
this
says
you
can
reference
information
models.
Can
reference
information
at
a
top
level
when
you're
four
client-side,
you
wouldn't
actually
be
able
to
retrieve
anything
underneath
here
you
would
go,
go
back
to
the
top
level.
So
in
terms
of
impact,
we
think
there's
three
areas
of
impact.
You
have
core
informa
core
facing
PE
information.
P
That
is
not
instant
specific,
so
that's
not
perverse.
That
goes
either
into
the
protocol
like
BGP
or,
if
you
don't
have
another
home
to
put
it
elsewhere,
you
can
put
it
at
the
top
level.
Network
instance.
We
really
think
that's
mainly
going
to
show
up
in
the
protocols
if
you
have
core
facing
information,
that
is
per
instance
that
goes
under
ni
type
and
then
I'll
see
in
Cee.
Information
goes
under
birf
again.
The
intros
up
here
is
an
implementation
time
choice,
so
we
don't
specify
it.
We
don't
tell
you
that
you
should
be
doing
it.
P
P
F
Q
So
after
the
after
the
last
IETF,
there
was
a
revision
submitted
in
l3
VPN
young
model.
That
mainly
is
about
removing
the
private
definitions
of
some
of
the
data
types
like
our
DN
RT
and
reusing
them
from
IETF
routing
types.
Besides
that
there
are
a
bunch
of
updates
in
progress,
mainly,
they
are
following.
One
is
md
n
md
alignment,
which
is
removal
of
state
containers
which
are
really
reflecting
the
flight
config
state
and
those
have
to
go
away
from
the
model.
Secondly,
alignment
with
the
network
instance
model,
as
you
described
earlier.
Q
The
model
was
of
menteng
network
instance
container
conditional
upon
that
type
of
network
instance
as
default
versus
the
named
Network
instance.
This
has
changed
and
what
what's
going
to
happen
is
in
n,
as
more
details
coming
in
the
next
slide,
based
on
n
I
type
as
a
3
VPN,
some
of
the
the
portions
of
the
model
content
will
go
in
there
and
bgp
related
augmentations
for
l3
VPN,
which
fall
under
the
category
of
core
facing
configuration
and
then,
for
instance,
configuration
in
BGP.
Those
will
be
will
have
to
be
placed
in
the
right
places.
Q
So
here
is
an
example
of
it's.
A
young
tree
depiction
our
DS
NRT
kind
of
configuration.
It
is
per
per
Network
instance
configuration
which
will
be
available
under
Network
instance
and,
under
a
particular
Network
instance
with
case
being
n
I
type
as
as
new
VPN.
The
second
category
is
BGP
specific
l3,
VPN
extensions.
Q
Q
Then
the
second
category
is
for
BGP
specific
extensions.
The
second
category
is
cone.
Facing
instance.
Configuration
like
ESB
are
options
and
one
example
for
that
is
SBR
option
be
peering
the
region
route
target
knob
and
such
knobs
will
go
in
the
augmentation
of
BGP
model
at
the
top,
and
it
was
mentioned
earlier
that
aim
in
the
hole,
routing,
mod,
the
hole,
routing
model
and
control
protocols
and
a
protocol
bgp
under
that
is
mounted
under
under
a
network
instance
by
using
schema
mount.
Q
But
here
because
we
are
augmenting,
the
top
BGP
container
and
l3
VPN
is
a
separate
module.
We
can
control
it
not
from
we
can
control
it
in
such
a
way
that
it
won't
show
up
in
the
context
of
our
Network
instance,
under
the
scheme
amount.
So
this
way
we
can
achieve
the
three
categories
that
what
this
is
described
in
loose
presentation
through
bpn
top
configuration
and
then
the
BGP
specific
configuration
which
is
per
Network
instance,
as
well
as
for
the
court
facing
instance.
Q
R
Patrice
reset
school
system,
okay,
so
today,
just
to
as
a
follow-up
of
the
boring
stuff.
The
being
so,
let's
go
with
LT
VPN,
so
I'm
going
to
be
quick.
Basically
what
we've
done
is
we
just
try
to
finalize
the
yang
model,
so
we
can
also
call
the
workgroup
task
all
very
soon.
So
we've
been
doing
the
all
the
details
about
episode
warriors
also
make
sure
that
the
we
are
compliant
to
an
MDA
style,
and
we
play
also
bit
with
the
instances
make
sure
that
people's
are
happy.
We
name
it
a
bit.
R
So
how
about
the
latest
I
think
we
are
very
close
to
get
it
done
so
and
hopefully,
and
on
the
evpn
side.
Well,
there's
the
same
thing
for
the
Ethernet
segment
Yang
and
the
VPN
yang.
We
try
to
finalize
pretty
much
everything
we
add
the
last
bits
and
bytes
and
advice
and
the
episode
of
wire
stuff
also
that
we
added
recently
to
the
Ethernet
segment
so
again
try
to
align
the
model
with
the
nmda.
R
So,
on
the
VPN
side,
again
all
the
last
stuff
that
we've
been
doing
so
we
add
the
VP
WSVN
and
aware
to
it
absurd
wires,
reshuffle
a
bit
the
model
between
the
interaction
between
a
VPN,
any
VPN
and
also
mainly
for
the
for
all
of
them,
as
you
can
and
those
two
models
is
we
added
the
stagehands
identification
so
everything
which
is
over
data
so
that
one?
Unfortunately
we
the
team,
wants
to
apologize.
We
got
issues
to
upload.
S
Manchu
from
Siena
I
wanted
to
give
you
an
update.
There
was
a
presentation
in
the
pal
working
group
about
the
pseudo
wire
yang
model
and
we
we
basically
said
that
we
are
doing
that
in
the
best.
So
we
have
to
consolidate
into
a
single
pseudo
wire
yen,
the
container
that
we
have
here
and
I
think
the
only
other
things
there
is
the
pseudo
wire
types,
ATM
frame
relay
all
that
and
multi
segments
for
a
wire,
so
rest
of
it.
We
have
it
covered,
but
some
of
that
other
things
will
pick
it
up.
Okay,.
S
So
I
have
a
very
simple
diagram.
Just
to
you
know,
put
this
problem
in
perspective
and
I
have
a
case
and
I
bgp
network,
in
which
r1
is
the
source
router
and
generates
a
prefix
1.1.1
and
that
is
propagated
by
r2
route
reflectors
and
then
it
goes
to
the
destination
which
is
not
to
the
receiving
router
and
the
router
flickers
do
not
set
the
next
talk
to
themselves.
S
S
Now,
if
we
decide
to
change
the
next
stop
at
the
route
reflector
using
like
next
stop
self,
which
is
again
very
standard,
then
at
r2
we
will
receive
both
the
paths
and
they
will
have
different
next
stops
and
then
both
will
be
treated
as
candidate
multipaths
and
they
will
be
eligible.
And
then
both
the
paths
will
be
in
the
then
just
a
quick
introduction
to
interests:
option
B.
This
is
defined
in
RFC,
two
five,
four
seven,
and
here
the
control
and
the
forwarding
over
the
SBR
or
thought
no
system
boundary
router.
S
Is
it
both
the
control
plane
and
the
data
plane
is
across?
This
is
yes,
and
the
next
stop
is
reset
at
that.
But
I
guess
we
are
I,
didn't
write
it,
but
there
is
an
option
whether
you
want
to
reset
the
next
of
at
the
receiving
is
we
are
also
or
not
so
again,
just
very
standard
diagram.
We
have
the
worth
of
the
VPN
existing
at
P,
one
and
P,
and
the
advertisement
is
across
an
a
is
from
a
s102,
a
s
200.
S
So
the
C
one
is
sending
a
prefix
1.1.1,
/
32
and
at
p1
it
is
in
the
context
of
the
worth
its
advertising
with
touches
about
distribution,
Rd
one
and
then
at
s
PR
one.
It
has
to
set
the
next
after
itself
right
and
notice
that
in
p1
the
advertisement
came
with
the
label
l1
and
in
asbr
one.
It
is
set
well
to
write,
and
then
it
goes
towards
the
receiving
S,
which
is
deceiving
sorry
s
200
and
there
I
just
choose
that
on
SBR.
S
Now
we
take
a
case
in
which
the
c1
is
dual
home
to
p1
and
p2,
and
as
in
the
first
in
the
previous
figure
here,
the
VPN
prefix
on
spr
one
changes
from
label
l1
to
l-3
and
then
goes
toward
c2
and
split
second
later,
the
same
advertisement
or
rather
than
if
the
advertisement
from
the
same
seed
out
1.1.1
is
sent
to
P.
2
and
P
2
attaches
its
own
Rd
right,
which
is
active,
and
it
goes
to
s
PR
1,
which
again
rewrites
the
next
hop
and
the
label.
S
N
S
So
the
second
thing
we
could
do
and
I
think
that
is
easy
fix
is
we
can
use
the
tuple
next
hop
and
label
when
determining
the
multipath
and
the
receiving
P,
so
in
the
previous
from
the
previous
figure,
even
if
the
next
stop
at
the
receiving
P,
which
is
p3,
is
same
as
V
r1,
then
that's
the
next
stop.
The
labels
are
different.
So
then
both
the
paths
can
be
programmed
in
the
forwarding
right.
S
So
what
happens
is
if,
for
example,
I
am
now
wanting
to
send
traffic
from
p3
towards
c1
for
two
different
source
nuts,
which
I
didn't
show
from
two
different
sources,
and
the
destination
is
the
same,
which
is
the
1.1.1
at
c1,
from
t3
to
SBR
one?
There
is
only
1
LSB
right,
I
mean
even
though
there's
like
separate
levels
rather
I
should
say
the
path
is
the
same,
and
then
at
SDR
one.
What
happens
it's?
S
T
Draft
on
Geneva
with
evpn,
so
you
need,
as
you
folks
know,
is
an
envious
fee.
Encapsulation,
it's
being
adopted
now,
as
the
standard
poor's
enviously
in
cap
and
evpn,
currently
as
a
control
plane,
does
not
use
Geneva
as
one
of
the
tunnel
encapsulation
option.
So
this
draft
is
about
extending
the
tunnel
encapsulation
options
at
EVP
and
support
to
include
unique
to
one
unique
thing
about
Geneva
as
well.
Is
a
genève
allow
the
tunnel
to
carry
option
tlbs?
T
T
So
we
are
defining
a
bgp
extension
here
that
will
carry
what
options
that
will
be
present
in
the
tunneling
cap
after
the
column,
header
and
as
shown
here,
those
are
gonna
be
carried.
Those
tunnel
option
types
are
going
to
be
carried
in
a
new
tunnel,
encapsulation
attributes
up
yet
so
we
are
gonna,
have
a
sub
TLD
type
for
each
option
that
will
be
carried
and
it's
a
regular
klv
or
mat
similar
to
what
genève
is
going
to
be
carrying
in
the
founding
cap.
T
So
in
terms
of
operation,
the
bgp
encapsulation,
extended
community
is
currently
being
carried
on
only
en
route
that
BGP
extended
community
is
carrying
the
funnel
encapsulation
attribute
tunnel
pipe
to
be
genève
autonomy,
capsulation
and
the
tunnel
encapsulation
tunnel,
sub
DMV
for
the
Junaid
will
carry
those
tunnel
options
up.
The
alleys
that
can
be
transmitted
and
received
the
operation
is
straightforward.
T
So
if
an
NDE
is
expressing
what
option
has
to
be
carried
on
the
tunnel
in
caps,
and
he
is
not
expecting
that
the
other
and
he
to
be
sending
any
tunnel
in
car
any
option
other
than
what
he
is
capable.
Obviously,
is
that
I
think
yeah
that's
about
it
in
terms
of
operation,
so
for
the
next
step?
Of
course,
we
have
to
a
bit
more
because
actually
genève
tunnel
in
cap
caddy
as
well
next
protocol.
T
It
has
some
other
as
well
parameters
that
can
be
negotiated
or
signal
between
the
NBN
point,
so
I
think
we
are
going
to
be
progressing.
The
draft,
as
we
are
solid,
defying
more
the
control
plane
requirement
from
the
NGO
ski
stem.
So
so
the
draft
definitely
is
going
to
be
progressing
or
we
are
going
to
be
adding
more
meat
and
more
information
to
it
as
as
we
go
and
as
we
are
as
well.
So
the
defying
the
requirement
from
zangoose
is
that
so
I
think
that's
about
it.
We
can
have
comments
now.
T
T
T
A
solution
that
so
this
is
why
we
I
was
talking
more
about.
We
need
to
Salah,
define
more
a
requirement
requirement,
pull
the
control
plane,
and
this
is
works.
That's
going
to
be
done
by
and
viously,
so
enviously
working
group
is
working
as
well
on
solidifying
a
requirement
document.
So
this
solution
document
can
progress
as
we
are
solidifying
more
the
requirement
to
this.
What
I'd
say:
okay,.
B
Just
a
clarification
with
the
you
know,
your
answer
to
Gregg
with
respect
to
the
VX
man
encapsulation,
there
is
already
you
know,
a
draft
that
is
going
to
become
you
know.
A
VPN
is
a
control
plane
for
VX,
I
kneecap
and
it's
going
to
become
RFC
soon.
It
is
sitting
in
the
pipeline.
So
when
you're
talking
about
the
other
end
view
a
tree
encapsulation,
if
it
is
really
expand.
Yes,
it
is
already
there.
If
you're
talking
about
the
you
know,
GP
e
or
GUI,
then
as
needed,
we
can
add
it.
B
J
T
Definitely,
if
I
think
for
your
comments,
Jorge
on
the
multicast
bits
or
as
well
as
other
comment
about
the
local
bias
and
so
on.
If
we
are
going
to
be
defining
an
option
here,
Lisa
goes
for
enviously.
If
you
are
going
to
be
changing
something
of
the
most
when
Bo
City
my
people
are
gonna,
be
signaling
between
the
NVE.
What's
gonna
be
available
in
the
header
or
available
as
an
option,
then
we
need
a
control
plane
for
that
or
signaling
to
be
done.
Yeah
make
sense.
Thank
you.
T
J
F
J
Afternoon,
my
name
is
Jorge
rollin
nokia
at
this
traffice
about
blue
protection
in
a
VPN
networks.
Here
you
have
my
Cather's,
and
what
is
this
about
is
about
you
have
any
VPN
broadcast
domain
and
you
need
to
get
it
protected
against
loops.
First
consideration:
there
is
a
distinction
between
a
local
loop
and
a
global
loop.
J
What
is
a
local
loop
is
something
local
to
an
to
a
node,
for
instance,
in
the
example
here
in
the
diagram
you
have
on
p2,
for
instance,
if
you
receive
traffic,
let's
say
broadcast
from
host
1
and
the
traffic
goes
out.
They
see
two
attachment
circuit
two
goes
to
se
and
comes
back
somehow.
That
is
a
local
loop
until
loop,
that
is,
within
the
same
port,
same
bra
or
Castlemaine
in
p3.
You
have
the
same
thing,
so
it's
a
local
loop
because
it's
actually
within
the
same
P
right
and
same
broadcast
domain.
J
So
those
two
cases
are
not
addressed
in
this
draft,
because
the
assumption
is
that
the
local
implementation
should
be
able
to
deal
with
them,
but
we
are
addressing
in.
This
draft
is
a
global
loop
that
is
caused
by
a
backdoor
Lane
somewhere
and
the
between
sees
that
is
causing.
You
know
this
in
this
example,
this
loop
between
p,
p2
and
p3.
So
this
is
what
we
are
talking
about
these
global
loops.
So
what
are
we
doing
to
prevent
that?
J
So
what
we
are
doing
is
basically
completing
the
RFC
7:43
to
mak
duplication
mechanism
with
an
optional
loop
protection
procedure.
J
It's
a
fully
compatible
with
the
the
base
e
TP
and
a
specification
is
not
adding
any
control
plane
piece
of
information,
and
the
only
thing
we
are
suggesting
is
upon
detecting
a
loop
based
on
multiplication
event
carry
out
some
of
the
the
following
due
protection
actions.
So
there
P
shoot
this
card.
The
P,
detecting
a
loop
for
a
given
flow
should
discard
that
flow,
that
is
in
loop
and
while
allowing
other
flow
of
flow,
sorry
and
optionally,
the
P
can
also
bring
down
the
the
AC
where
the
loop
was
detected.
J
J
Yeah,
so
in
the
drug
that
you
have
these
diagram
a
bit,
not
clear,
but
basically
there.
It's
an
example
with
two
P
is
P
2
and
P
3,
and
you
have
a
local
attachment
circuit
with
Mac
two
injecting
broadcast
traffic
and
P
2
and
P
3.
They
are
part
of
the
same
VPN
broadcast
domain
and
you
have
also
a
backdoor
link
between
AC,
3
and
AC
4.
Obviously
you
have
a
loop
here,
so
the
way
we
detected
is
actually
taking
advantage
of
the
immaculate
Asian
procedures
in
in
the
VPN
and
those
procedures.
J
Basically,
what
they
say
is
if
I
receive
a
if
I
learn
a
Mac
locally
in
AC
2.
I
really
ties
it
at
the
same
time,
I'm
sending
that
traffic
over
the
backdoor
link
and
over
the
core,
obviously
on
P
3
I'm,
going
to
receive
the
route
but
I'm
also
at
the
same
time,
I'm
going
to
learn
the
same
Mac
locally
on
AC
4,
so
I'm
going
to
be
advertised
a
Mac
with
a
higher
sequence
number
and
so
on,
so
on
and
so
forth.
J
At
the
end
of
the
process,
when
you,
when
you
reach
a
number
of
moves
of
Mac,
moves,
you're
going
to
declare
that
MAC
address
as
duplicate
right
and
all
this
is
specified
in
a
VPN.
So
the
new
thing
we
are
doing
is
once
you
detect
that
Mac
2
is
duplicate
and
you
add
it
to
a
duplicate
Mac
list.
We
are
taking
some
actions,
so
what
RFC
742
says
is
basically
the
action
is
if
P
3
is
detecting
Mack
to
us
duplicate,
it
has
to
stop
advertising
Mack
to
can
and
log
an
event,
and
that's
it.
J
So
we
are
extending
that
and
we
are
saying
well,
p3
should
actually
start
a
retry.
Timer
and
p3
should
actually
trigger
some
blue
protection
actions,
and
those
actions
are
what
we
call
we
should
blackhole
Mac
to
in
this
example
and
a
black
hole
in
this
context.
What
it
means
is
that
Mac
2
should
be
installed
in
the
rich
table
as
a
black
hole.
Mac
address
black
hole,
MAC
address
is
not
associated
to
any
attachment
circuit
or
any
a
VPN
tunnel.
J
J
So
what
is
this
draft
informational?
Well
because
it's
compatible
fully
compatible
with
the
seven
four
three
two
procedures
is
not
modifying
any
VPN
routes
and
can
be
deployed.
Even
if
you
don't
support
this
in
all
the
peas
in
the
broadcast
domain.
Obviously
it
will
help
better
if
you
support
this
in
all
the
peas
in
the
broadcast
domain,
but
it's
not
necessary,
and
why
do
we
think
it's
important?
J
B
Especially
my
comment,
so
basically,
the
detection
mechanism
is
already
you're
leveraging
the
detection
mechanism,
which
is
already
in
the
RFC
7432.
That's
right
right
and
RFC
72
this
cusses
how
to
take
care
of
the
control
plane
and
you
know,
stop
advertising
the
MAC
addresses
and
notify
the
operator
mm-hm.
B
Basically,
this
is
discusses
what
actions
will
be
taken
on
the
data
plane
by
stopping
the
traffic
flow
and
optionally
disabling
the
attachment
circuits-
yes,
I,
think
four,
so
that
is
fine
it
just
for
that
aspects
of
it.
Frankly,
the
draft
is
two
variables.
You
know,
I
mean
you
can
condense
that
to
a
couple
of
pages,
I
will
say
max
I
hope
you
don't
take.
This
comment
around
way--just.
It
is
awfully
lot
of
requirement
definition
and
discussing
too
many
things
to
capture
the
essence
of
what
the
giraffe
is
going.
Yeah.
B
Likely
yeah
the
problem
with
having
a
giraffe
to
talk
about
the
data,
plane,
action
and
the
result
of
the
data
plane.
Action
is
to
make
sure
you
know
to
prevent
the
loop
in
case
there
is
a
backdoor.
You
know,
that's
fine,
I'm
saying
you
know
it
for
that.
Fine,
let's
have
a
draft.
What
having
a
10-page
draft
for
something
that
we
can
write.
Two
pages
for
I
think
it
just
I'm
saying
that
giraffe
is
a
bit
verbose.
If
you
can
condense
that
all.
S
S
J
F
J
All
right,
so
one
more
draft:
this
is
pimp
Roxy
in
E
VPN
networks.
This
is
the
list
of
my
cars
and
basically
this
draft
is
a
natural
evolution
to
of
the
the
work
we're
we've
been
doing
in
a
VPN.
The
idea
is,
if
you
have
an
e
VPN
broadcast
domain
within
optimizing,
a
VPN
to
take
care
of
the
the
flooding
of
the
art
messages,
enable
discovery
messages
even
IGMP.
J
What
where
we
don't
have
any
any
multicast
router
same
thing
with
pin
joints
or
pro
messages.
They
are
flooded
everywhere
right.
So
we
can
do
it
better
in
along
the
lines
we
are
doing
with
IG
MP.
We
can
do
actually
the
same
thing
with
with
pin,
so
the
objectives
of
this
trap
is
to
reduce
a
limited,
eliminate
the
the
pain
message
of
flooding
in
the
poor.
We
also
want
to
to
Ford
the
IP
multicast
streams
efficiently.
J
J
So
these
are
the
procedures
that
we
have
in
the
draft
at
the
moment,
I'm
going
to
go
through
some
of
them,
so
the
first
one
is
the
what
we
call
the
multi
rather
discovery,
so
we
are
defining
a
new
EVP
and
route
type
that
we
call
MRD,
multicast
router
discovery
route,
and
this
router
is
actually
replacing
the
pim
hello's
in
the
core
with
bgp
route.
It's
actually
replacing
the
soft
state
hello
messages
with
the
hard
state
bgp
route.
So
the
idea
is
a
TV
access.
J
You
receive
hello
messages,
team,
kalokhe
messages
from
routers
and
you
add
the
pim
router
to
your
neighborhood
database
and
you
trigger
this
multicast
or
MRD
route
and
you
take
their
the
the
IP
address
of
the
the
router
the
secondary
addresses.
If
you
have
such
a
thing
dr
priority
and
that's
pretty
much
it
for
the
timing,
you
handle
the
timers
and
the
gen
ID
and
other
things
locally,
the
receiver
piece
basically
based
on
the
route,
we
add
the
multicast
routers
to
the
neighborhood
database
and
you
generate
the
hello
messages
again.
J
We
also
have
we
take
advantage
of
the
same
route
to
also
autodiscover
IGMP
queriers.
So
there
is
a
flag
in
the
route
where
you
can
actually
indicate
whether
the
route
is
a
is
a
four-year
right,
and
in
that
case
we
with
just
one
route.
We
discover
both
things
so
pimp,
routers
and
IgM
peak
warriors.
You
have
a
question
about
this
yeah.
E
So
stick
so
in
PIM.
You
know
we
have
a
lot
of
other
PIM
options
or
hello
options
and
the
arm
that
potentially
could
be
useful,
like
a
load
balancing
or
there
could
be
other
things,
so
I'm
wondering
a
little
bit
if
it
would
make
sense
to
instead
of
having
a
fixed
format
like
this.
So
maybe
hello
like
a
list,
though
hello
options
to
be
in
the
route
and
it
could
be
coming
for
implementation
dependent,
perhaps
which,
which
hello
options
you
choose
to
actually
include
them
in
the
BGP
route
yeah.
So.
J
We
thought
about
the
rest
of
the
options
because
they
are
in
the
I
agree
with
you
in
the
hello
messages.
There
are
lots
of
them.
Basically,
we
we
decided
to
put
in
the
NLRA
insisted
the
main
ones
that
we
thought
were
important.
We
also
did
decided
that
it
was
some
of
them.
They
liked
the
timers
and
jain
ID
doesn't
make
sense
to
propagate
that
in
around.
N
J
E
I
would
say
so
two
things
one
is
I
wonder
if
the
format
should
maybe
be
more
flexible,
so
you
know
it's
easier
to
add
new
things
later
and
the
other
thing
is
yeah.
If
you
make
it
more
more
flexible,
you
can
still
recommend
which
one
should
be
used
or
if
you
choose
stuff
to
make
it
more
flexible
yeah,
then
we
should
discuss
exactly
which
ones
should
either
but
yeah.
Just
thinking
is
worth
thinking
more
about
this.
Okay.
J
J
Basically,
we
can
do
proxy
and
generate
a
single
route
summarizing
that
we
are
using
here.
The
s
met
route,
which
is
the
same
route
that
we
are
using
in
the
IGMP
proxy
draft,
and
the
only
difference
is
that
we
are
extending
a
little
bit
the
route.
So
in
the
the
flags
failed,
there
will
be
a
new
flag,
we
call
it
P
flag
and
that
is
indicating
that
we
actually
received
a
pin
joint
from
a
pin
router
and
the
information
there
is
also
applicable
to
pin,
and
when
that
happens,
basically,
we
need.
J
We
need
also
to
add
the
upstream
router
information
which
is
not
needed
in
a
IGMP.
Along
with
that,
we
are
also
introducing
a
new
route
type,
the
RPG
prune,
drought
and
therewith.
The
reason
why
is
because
we
need
a
state
for
the
Eskimo
gr,
PT
states
right,
and
we
need
to
to
propagate
that.
In
in
BGP
as
well
important
thing
that
we
are
doing
is
we
are
optimizing,
the
the
PM
assert
procedures,
so
one
of
the
things
is
when
you
have
a
bunch
of
team
routers
with
you
know,
sharing
the
land.
J
Sometimes
you
may
have
two
or
more
upstream
multicast
routers,
injecting
the
same
multicast
content
and
then
then
actually
trigger
assert
mechanisms,
and-
and
we
could
do
that-
and
just
let
the
assert
messages
do
their
thing.
But
we
thought
that
you
know,
since
the
assert
mechanism
is
actually
painful
for
the
routers,
and
we
don't
want
any
duplication
in
the
this
EVP
and
broadcast
domain,
we
thought
that
we
could
do
better.
So
actually,
what
we
are
doing
is
if
we
receive
pin
joins
for
the
different
upstream
browsers.
J
J
So
in
this
case
P
3
and
P
4,
they
will
pick
up
only
one
upstream,
neighbor
it'll
be
so
the
the
neighbor
coming
in
these.
The
estimate
for
s
Komachi
is
preferred
over
this
R
comma
G.
So
in
this
case
they
will
pick
up
our
R
for
now,
once
they
do
that,
basically,
the
peas,
they
instruct
the
datapath
to
discard
multicast
traffic
coming
of
multicast
traffic
for
s,
1
G
1,
coming
from
a
different
router
than
the
selected
one.
In
this
case,
P
4
would
discard
multicast
traffic
traffic
for
s.
J
1
G,
1,
coming
from
r5
and
immediately
after
P
4
will
actually
send
a
broom
as
1
G,
1,
IP,
5,
r
PT
message
to
our
five
so
that
our
five
that
stops
sending
the
multicast
traffic
so
with
this.
Basically,
there
is
no
way
you
can
have
duplication
and
this
shared
evpn
broadcast
domain,
and
we
avoid
the
assert
mechanism
between
r4
and
r5
yeah.
Finally,
I'm
talking
about
a
multi
coming
a
little
bit
just
as
we
we
do
have
in
the
ICMP
proxy
draft
when
you
have
multi
coming
it.
J
My
main
happens
that
our
one
since
the
a
joint
message
to
p1
and
we
actually
need
to
synchronize
that
state
in
p2
as
well,
if
p2,
is
part
of
the
same
internet
segment
right.
The
reason
why
is,
if
you
have
a
failure
on
p1
or
the
link
p2,
must
have
already
the
state
in
order
to
be
able
to
do
a
fast
failover.
That's
the
first
thing
of
the
a
synchronization.
J
The
other
thing
is
because
now
we
are
building
the
the
hello
or
the
pin
neighbor
database,
based
on
not
only
on
hellos
but
also
based
on
the
MRT
route.
The
MRT
route
also
has
to
be
tagged
with
the
Ethernet
segment
identifier
to
actually
synchronize
the
beam,
neighbor
databases
and
that's
pretty
much
it
so
with
this.
Basically,
we
we
complete
the
set
of
multicast
optimizations
for
a
VPN
broadcast
domains
and
I
have
here
that
we
need
to
agree
on
the
the
route
types
to
be
supported.
J
We
already
met
the
ICMP
proxy
and
and
the
authors
of
this
draft,
and
we
agreed
that
we
would
reduce
the
road
types
as
much
as
we
can,
and
an
open
question
is
whether
we
need
to
support
any
other
procedures
like
a
bimbo,
bootstrap
or
RP
discovery,
or
even
dense
mode
and
yeah.
We
need
some
more
feedback
and
comments
from
the
working
group.
I
just
try.
J
B
B
E
Stigmas
select
your
conclusions.
I
know
there
was
some
work
in
the
past
on
trying
to
do
be
SRO
a
BGP.
It
gets
very
complicated,
I'm,
not
sure
if
it's
worth
the
effort,
but
at
least
there
is
some
work
if
you're
interested
that,
maybe
can't
look
at
not
sure
if
you
want
to
support,
then
small,
but
it
depends
of
people
deploy
but
generally
trying
to
get
people
away
from
dense
mode
and
I
thought.
J
B
B
If
you
want
to
go
between
these
pease,
the
second
one,
to
give
you
a
better
optimum
forwarding,
you
know
among
these
P,
so
you
don't
have
to
do
it
rumbling
of
the
traffic
and
if
you
want
to
go
between
EVP
MP,
20
PN
or
vice
versa,
don't
have
to
to
do
the
through
the
Gateway
and
third,
is
you
don't
have
a
gateway
to
four
region,
eight?
So,
let's
for
visioning
the
requirements
are
pretty
intuitive.
You
know
have
optimum
forwarding
among
the
PE
is
whether
there
are
M
VPN
or
a
VPN
optimum
replication.
B
So
if
a
VPN-
and
so
one
thing
I
needed
to
clarify
ahead
of
time-
is
when
you,
when
we
talk
about
a
VPN
one,
can
I
get
puzzle
and
say:
okay,
evpn
is
l2.
Why
the
hell
are
we
talking
about
a
VPN
to
MVP
and
was
that
is
l3
interoperability
between
them?
This
is
not
l3
VPN.
This
is
I,
are
building
a
VPN
that
does
both
l2
and
l3.
B
If
you
look
at
em,
VPN
Keys,
you
can
think
of.
It
is
a
PE
with
a
bunch
of
IP
where,
if
this
IP,
where
are
the
US
tour,
a
host
multicast
addresses
there
and
these
IP,
where
are
connected
to
a
C's,
and
you
terminate
post,
pimp
Oracle
on
these
ACS
and
then
toward
the
core.
You
do
bgp
signaling
and
you
set
up
the
overlay
and
underlay
tree
using
RFC,
6513
and
40.
B
So
if
you
leverage
that
model,
then
you
can
say
my
EBP
and
PE
can
be.
Modeled
can
be
model
as
a
MVP
NPEs
connected
to
a
bunch
of
mac,
vr
af-s
vr,
these
IRB
interfaces,
so
basically
I'm
gonna
for
the
interoperability
between
a
VPN
and
MVP
and
Pease
I'm
gonna
treat
my
EVP
NP
is
@m
VPN
and
VPN
language
to
the
other
MVP.
B
So
well,
that's
all
good
and
dandy,
but
the
there
are
few
things
that
needs
to
be
considered,
and
one
of
the
challenging
aspects
is
how
to
do
the
how
to
solve
the
multi
all
active
multihoming
and
is
horizon
that
we
had
on
a
VPN.
Are
we
gonna
take
care
of
it
on
the
if
you're
trying
to
use
em
VPN
for
Rocco?
And
for
that
you.
A
B
I
think
I'm
gonna
cover
the
other
pretty
bottle
time
from
my
other
protection,
so
because
this
is
important,
so
I'm
not
gonna
get
into
the
too
much
of
details,
but
the
eggs.
We
need
to
handle
all
active
multihoming
in
here,
and
the
problem
is
when
you
do
IRB
you
cannot
use.
Are
you
know
what
you
work,
the
mechanism
you've
defined
in
RFC
7432,
because
that
is
only
intended
for
the
single
bridge
domain
and
not
for
multiple
bridge
domains
and
so
forth.
So
what
we
do
we
expand
that
mechanism
and
we
are
saying
that.
B
Okay,
you
know
what
we
we
cannot
live.
We
are
expanding
the
mechanism
in
pvp
and
VX
land,
which
we
call
local
bias
and
we
use
their
local
bias
in
here
and
we're
saying
that
we're
gonna
be
doing
that
not
just
for
a
single
bridge
domain
but
across
multiple
bridge
domains
and
they
trap
describes
in
detail.
How
do
we
do
that?
So,
once
you
solve
this
main
challenge,
then
the
risk
falls
into
its
place
and
basically
from
the
MVP
and
then
from
IRB
interface,
to
the
MVP
and
to
the
IP
where
to
the
core.
B
That's
all
ambient
procedures,
so
these
are
slide
talks
about.
We
gonna
do
the
blocking
across
multiple
bridge
domains
in
the
same
IP
ver.
As
you
know,
it
considers
bunch
of
you
know
a
given
IP,
where
fee
is
connected
to
a
bunch
of
Mac
waves
and
each
Mac
virtually
represented
by
a
single
bridge
domain
and
how
the
local
bias
mechanism
can
be
extended
to
handle
look
prevention
in
case
of
the
all
active
multihoming.
B
V
V
If
there
are
remote
receivers
across
the
fabric,
then
traffic
is
delivered
to
the
to
the
fabric
you
via
the
IP
birth
and
it's
encapsulated
with
the
IBM
Z,
or
s
flimsy
encapsulation
associated
with
that
work
and
the
egress
leaf
traffic
is
received
on
the
IP
birth,
and
if
there
are
local
receivers
behind
some
mock
birth,
it
is
delivered
to
those
receivers.
One
important
aspects
of
aspect
of
our
solution
is
that
the
tenant
multicast
signaling
terminates
at
IKEA,
so
we
say
families
the
inside
the
fabric,
the
tenant,
multicast
signaling,
is
delivered
via
BGP
MVP.
V
V
Also,
all
the
peas
that
are
part
of
this
em
VPN
they
they
join
the
I
pimsy
tunnel
in
this
case
that
white
tunnel,
so
they
so
if
there
is
some
remote
receiver
lock
on
p3,
it
will
send
out,
joins
to
p1
in
the
end
BGP,
MVP
and
others
family
and
the
p1
will
deliver
traffic
to
through
that
whites.
I
pinch
the
tunnel,
so
everyone,
including
p2,
will
receive
that
traffic,
but
I'm
p2.
Since
there
is
no
local
receiver,
traffic
is
dropped
and
p3.
It
is
router
2
receivers
behind
my
first
2
and
3.
V
V
But
we
will
need
gateways
in
this
case,
because
the
encapsulation
on
the
two
domains
is
different
and
usually
for
redundancy
and
load
balancing
purposes.
We
have
more
than
one
gateway
between
two
domains,
so
we
have
to
address
the
multihoming
between
the
gateways.
So
in
this
case
we
have
a
source
behind
in
v1.
That
source
is
viewed
by
any
receiver
on
MPLS
domain
as
a
multi-home
between
the
two
gateways
and
note
that
any
signaling
that
comes
from
one
domain
to
the
gateways
is
ryojun
ated
on
the
gateways
with
the
Gateway.
Next
stop!
V
So
that's
why,
on
the
other
domain,
the
p's
don't
know
anything
about
the
details
and
the
other
domain.
So
in
this
case,
receivers
in
the
MPLS
one
sense
that
joined
to
both
the
Gateway
and
the
traffic
from
source
lands
on
both
gateways
and
is
delivered
to
the
MPLS
man.
If
there
is
some
inclusive
tunnel
on
MPLS,
when
this
traffic
may
get
received
by
gateway
to
but
Gateway
to
has
an
RPF
looking
to
to
the
source
on
weeks
nine
you
see.
V
J
J
B
C
D
A
B
Basically,
the
IPL
is
saying
in
a
VPN
has
been
defined
for
the
two
runs
for
the
MAC
addresses
and
then,
when
you
do
IRB
there
are
two
flavor
of
IRB.
One
is
symmetric.
One
is
asymmetric.
Asymmetric
gets
resolved
to
your
local
MAC
addresses,
so
you
can
leverage
the
IP
aliasing
already
defined
for
the
l2.
B
When
you
go
to
the
symmetric,
then
the
symmetric
IRB
needs
the
IP
aliasing
at
the
IP
rods,
and
this
graph
covers
that
and-
and
it
is
pretty
straightforward
in
a
sense
that
I
could
have
covered
that
in
the
existing
IR
redraft.
But
it
has
gone
through
the
working
group
Glasgow
and
that's
why,
for
the
new
draft,
so
I'm
not
going
to
cover
what
the
aliasing
is.
The
first
white
talks
about
what
the
aliasing
is.
B
We
don't
have
a
time.
We
assume
that
everybody
knows
the
aliasing
procedures
for
a
VPN
and
in
a
nutshell,
these
things.
This
proposal
leverages,
like
you,
know,
exact,
same
procedure
of
evpn
aliasing,
which
we
do
for
mac
addresses.
It
says
now
use
it
for
the
IP
addresses
for
the
symmetric
IRB
and
once
you
do,
that
the
fast
convergence
using
the
mass
withdraw
and
all
that
works.
So
it
is
a
short
draft.
I
encourage
you
guys,
read
that
and
as
I
mentioned,
this
is
to
cover
the
symmetric
IRB
case.
I
go
ahead.
Alright,
okay,.
J
Ramadan,
are
you
playing
to?
It
include
the
RT
v
or
you
don't
belong
here,
RT
v
and.
J
J
If
you
learn
the
the
mankini
key
binding
through
gratuitous
harp,
and
basically
you
hash
it
on
one
link
and
you
bridge
to
the
other
guy
right,
you
discover
them
both.
You
are
going
to
advertise
it
from
both
P.
So
in
that
case
you
don't
really
need
any
aliasing
right,
then,
with
the
same
token,
we
wouldn't
need
the
aliasing
for
the
bassline
evpn
yeah,
but
in
the
bassline
evpn
you
can
receive.
You
know,
unicast
what
the.
B
Same
principle
applies
in
here;
in
other
words,
if
you
receive
it
on
both,
you
can
say
you
know
you,
don't
you
wouldn't
need
aliasing,
because
both
will
send.
However,
you
can
not
assume
you're
gonna
receive
it
in
both
because
it
can
get
traffic
and
get
hash
about
the
ARP
traffic,
as
well
as
the
ARP
message,
as
well
as
the
traffic
can
get
hash
into
the
morning.
Yeah.
F
S
S
B
S
B
B
So
the
question
is:
how
do
you
solve
these
Mac
flip-flopping
when
you
have
all
active
VPN
and
all
activity
we
can
is
very
important?
Is
one
of
the
as
I
say,
key
feature
of
the
evpn
so
to
address
that
we
do
it
very
you
know
simply.
We
are
saying
that
we're
going
to
be
using
the
concept
of
the
mirror
pseudo
wires
and
for
a
given
PE
for
a
given
EVP
and
PE,
based
on
the
DF
election
on
that
Ethernet
segment
and
on
that
Ethernet
segment
based
on
that
DF
election.
B
If
it
is
a
DF,
then
that's
full
of
wires
becomes
D
F
and
we're
gonna
PE
we'll
use
the
same
pseudo
wire
label.
Okay!
So
that's
why
we
call
it
mirroring,
because
PE
2
uses
the
same
sort
of
wire
label
as
PE
1.
When
you
do
that,
PE
3,
when
it
receives
a
traffic,
it
basically
assumes
it
receives
the
traffic
from
the
same
originating
PE
and
it
avoids
flip-flopping.
So
the
advantage
of
that
takes
care
of
the
Mac
flip-flopping
and
the
traffic
from
the
evpn
toward
the
PE.
B
It
gets
load
balance
across
both
to
the
wires,
but
from
the
VPLS
PE
to
EB
PNP.
It
goes
it
gets
sent
via
only
a
single
to
the
wire,
but
that's
okay,
I
mean
that's,
that's
the
VPLS
works
anyway,
and
the
load
balancing
is
basically
asymmetric
in
one
direction
in
one
from.
If
you
can
PE
2
PP
LSP,
the
load
balancing
is
done
on
a
per
photo
basis
over
the
core
in
the
reverse.
Reaction
is
done
on
a
pair
of
VLAN
basis
over
the
core,
so
that
that,
basically
it
and.
B
B
The
draft
talks
about
what
control
plane
changes
needed.
We
can
leverage
a
lot
of
a
VPN
and
Ross
and
basically
very
minor
changes
is
needed
on
the
control
plane
and
a
bit
of
changes
needed
in
the
data
plane,
but
it
discusses
in
detail
what
those
changes
are
and
it
talks
about
the
also
how
you
handle
the
multicast
traffic
in
vs.,
unique
chance
or
I
should
say
bomb
traffic
that
covers
multicast
broadcast
an
unknown
unique
ends,
so
is
a
is
the
interesting
graph
definitely
encourage
reading
it.
K
But
often
folks,
Neeraj
from
cisco,
these
are
the
co-authors
I'm
gonna
be
talking
about
extended,
evpn
mobility
procedures
for
EVP
and
IRB
use
cases,
as
the
title
suggests.
The
main
objective
of
the
draft
is
to
define
mobility
procedures
for
Mac
and
IP
for
all
evpn
IRB
use
cases,
and
the
work
here
is
based
on
top
of
Mac
mobility
procedures
defined
in
7432.
K
So
for
the
scenario
a
it's
pretty
much,
the
existing
Mac
mobility
procedures
can
be
leveraged
and
applied
to
scenario
a
it's
the
scenario
B
and
C,
with
changing
Mac
IP
bindings
that
are
complicated
by
the
fact
that
in
evpn
I
rvv
advertised
both
Mac
and
IP
beach
ability
by
a
single
Mac
IP
route
type.
Two,
with
a
single
sequence
number
attribute
attached
to
that
route.
That
signals
the
route
version
for
both
Mac
and
IP
components
of
that
of
that
route.
So
essentially,
if
I
have
an
IP
that
moves
to
a
different
Mac
binding.
K
Now,
how
do
I
assign
sequence
number
to
the
new
Mac
I
feed
out
if
I
treat
it
like
a
fresh
route
and
assign
a
new
sequence
number,
then
the
mobility
for
the
IP
component
would
not
take
effect
because
it's
already
advertised
with
a
higher
sequence
number.
Similarly,
if
the
Mac
moves
to
a
different
IP
binding,
if
I
treat
it
like
a
fresh
route,
assign
it
a
new
sequence
number,
the
mobility
for
the
Mac
component
of
the
route
would
not
take
effect,
because
the
Mac
is
already
advertised
with
a
higher
sequence
number.
So.
K
The
key
part
of
the
solution
is
that
we
associate
the
sequence
number
attribute
only
with
the
local
Mac
component
of
the
route,
so
only
with
the
local
Mac
route
and
the
Mac
IP
essentially
inherits
the
sequence
number
from
the
parent
Mac
and
we
define
two
key
rules
that
must
be
followed
when
assigning
sequence
number
to
the
Mac.
The
rule
1
is
essentially
same
as
the
existing
Mac
mobility
rule
and
the
rule.
K
So
just
a
few
other
things
that
are
also
covered
in
the
draft.
It
covers
the
Mac
sharing
scenario
where
multiple
IPS
could
share
the
same
Mac
binding.
It
also
defines
a
duplicate,
IP
detection
procedure
for
the
use
cases
where
the
IPS
might
be
misconfigured
with
two
different
Mac's,
something
that
wouldn't
be
covered
with
the
existing
Mac
duplicate,
Mac
detection
procedure,
and
it
also
talks
about
sequence,
number
synchronization
across
redundant
V's.
So
that's
basically
what
I
have.
A
A
W
Nine
minutes
from
Juniper
Networks
today
I
want
to
introduce
you
to
this
draft,
which
basically
talks
about
how
to
create
private
MPLS
namespaces,
which
is
private
labels
using
BGP
next,
at
least
so.
Basically,
this
is
a
problem
statement.
How
do
we
achieve
predictable
label
assignment
at
a
receiving
router
at
a
router?
Who
is
not
me
myself
so
as
we
know
that
MPLS
has
locally
significant
level
allocation
semantics?
So
with
that
in
mind,
how
do
we
get
a
predictable
label
allocation
at
a
router?
W
So
it
basically
combines
two
RFC's
together.
We
know
the
upstream
label
allocation,
that
is
are
say:
5
3,
3
1
and
we
have
all
25:47
VPNs.
So
if
you
think
about
it,
25:47
VPNs
provides
us
different,
forwarding
context
for
IP.
So
this
mechanism,
basically
URI,
uses
25:47
and
uses
some
extensive
signaling
to
provide
private
MPLS
context
for
MPLS
forwarding
an
exciting,
so
here
I'm
trying
to
explain
what
context
tables
are
and
how
do
we
use
it
for
an
off
box
label
allocator.
W
So
in
this
diagram,
I've
shown
a
router
which
has
its
own
low
but
locally
allocated.
I
mean
local,
a
significant
labels
in
its
blue
fab,
which
is
the
MPLS
wave,
and
we
see
that
this
doctor
is
connected
to
through
two
interfaces
as
an
example:
the
G
zero
zero
zero
is
a
shared
common
interface,
which
kind
of
goes
to
the
core
and
g2
0.
0
is
kind
of
a
private
interface
which
comes
into
a
specific
forwarding
context.
You
can
assume
this
is
like
interface
that
comes
into
the
CVR
of
for
l3
VPN.
W
So,
if
you
think
about
it,
this
is
very
similar
to
l3
P
n,
where
a
dot
MP
Lazar
zero
is
instead
of
a
dot
and
a
dot
zero
and
the
impedance
R
zero
global
fabious,
the
core.
So
the
seal
one
is
the
context
label
that
is
locally
significant
and
it
points
to
the
aide
or
MP
lists
tables.
So
taking
the
power
lives
with
l3
VPN,
the
CL
one
is
like
the
VPN
labels
and
whatever
traffic
comes
inside,
that
that
is
the
pl
one
that
becomes
a
private
label.
W
So
I
can
have
multiple
routers
in
the
network,
where
I
create
the
a
lor,
MPLS,
fab
and
I
can
install
the
same
label
value
PL
one.
So
that
I
am
able
to
deterministically
get
the
same
label
value
at
different
routers,
using
which
I
create
this
private
MPLS
web
on
a
shared
MPLS
network.
So
this
way
users
can
create
multiple
MPLS
planes
in
the
network
and
use
them
with
their
own
label
values
with
decide,
forwarding
semantics.
So
that
is
the
main
idea
and
each
MPLS
plane
is
actually
identified
by
a
context.
W
W
So
this
slide
basically
explains
the
constructs
and
some
of
the
constructs
we
described
in
the
previous
diagram.
So
the
main
thing
I
want
to
point
at
this
slide
is
that
each
MPLS
plane
that
is
identified
with
a
context
protocol
next
hop
the
service
routes
can
bind
through
this
MPLS
plane
by
using
that
context.
Protocol
next
hop
address,
ask
the
protocol
next
arc
and
the
bgp
update
and
the
label
can
be
a
private
label
that
the
application
itself
allocated
next
site
this.
W
So
these
are
the
protocol
extensions
that
are
being
done
for
this
mechanism.
The
first
draft
is
what
we
are
talking
about
right
now,
that
is
a
for
4364
style
extension
to
provide
with
the
basic
the
link
for
the
private
labels.
So
second
draft
is
a
multi
next
wrap
attribute,
which
basically
allows
other
bgp
route
to
carry
multiple
next
hops,
with
different
forwarding
semantics,
which
could
be
a
four
would
push
Papa's
lap.
The
forward
is
applicable
for
both
IP
and
mpls
traffic,
but
pushpop
swap
is
applicable
for
MPLS
traffic.
That's
right,
please!
W
So
these
are
the
details
of
the
route
types
that
this
mechanism
provides.
So
the
first
route
type
is
that
call
the
context
for
our
next
operatives
meant
every
router
that
creates
a
context.
Web
error
and
pay
less
for
MPLS
plane
a
hydrolyzes,
the
context
to
other
BGP
speakers
and
applications.
So
prefix
is
the
Rd
:
context.
Protocol
next
hop
address.
So,
as
we
already
mentioned
context,
protocol
next
hop
address
is
the
same
IP
address
on
each
of
the
routers
which
are
participating
in
that
MPLS
plane.
W
So
the
Rd
is
the
one
that
uniquely
identifies
each
instance
router
so,
and
the
attribute
of
this
route
would
be
multi
next
hop
attribute,
which
would
just
say,
push
the
context
label
towards
me.
Where
meaning
is
a
global
l,
o0
and
all
of
these
routes
have
the
route
target
identified
the
MPLS
plane,
because
it
is
just
a
lcvps
next.
I
please
so
once
the
context
has
been
advertised
to
the
applications.
Now
the
applications
can
install
their
own
private
label
values
into
the
a
tour
MPLS
context.
W
Just
like
we
do
install
the
l3,
VPN
IP
vrf
routes,
and
so
the
prefix
is
nothing
but
a
Rd
:
label
and
the
forwarding
semantics
can
be
anything
that
the
application
wants,
which
could
be
identifying
a
certain
resource,
which
is
the
next
hop
that
is
attached
to
next
wrap
interface
that
attach
to
the
MPLS
plane
or
a
vr
of
that
is
attached
to
the
MPLS
plane
or
when
they're
out
is
getting
the
advertised
to
other
speakers
in
the
MPLS
plane.
It
will
be
forwarded
to
me
where
me
is
identified
by
Rd
:.
W
W
So
this
slide
has
a
lot
of
detail,
but
if
you
think
about
it,
it
is
very
similar
to
l-3
VPNs.
So
p1
and
p2
are
like
the
C's
in
a
European
which
come
into
a
forwarding
context,
and
once
we
come
into
the
forwarding
context,
we
are
in
a
MPs
plane
and
we
use
the
same
l3
VPN
context
label
to
remain
in
the
same
l3,
VPN,
plane,
I,
think
I'm,
seven
minutes
now
so
next
slide
I
have
shown
an
example
of
a
use
case.
I
think
next
slide.
W
So
here
we
have
a
case
where
we
have
a
virtualized
environment
and
a
bunch
of
routers
are
vcv
p1,
which
is
a
conglomeration
of
v.
Cp
+,
VF,
p1,
v,
f
p2,
and
there
is
a
fabric
interconnecting
all
this.
So
there
is
an
upstream
node
the
service
forwarding
helper,
which
basically,
that
is
getting
all
the
traffic
that's
coming
from
the
core.
Now.
W
W
P1
is
able
to
have
a
context
fehb
for
itself
at
the
ssh
and
he
is
able
to
program
the
routes
that
he
allocated
locally
significantly
in
his
embolus
r0
into
the
VP
1
dot
embolus,
so
that
when
the
traffic
comes
from
the
core,
SSH
knows
exactly
whether
the
label
l1
is
behind.
We
have
P
1
or
V
F
P
2.
So
this
is
one
use
case
and
because
this
just
makes
an
API
into
the
network's
forwarding,
plane,
I
think
more
use
cases
can
emerge,
so
the
backup
slides
have
more
use.