►
From YouTube: IETF104-BESS-20190326-1610
Description
BESS meeting session at IETF104
2019/03/26 1610
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
A
A
So,
first
of
all
website
updates,
so
we
did
have
some
work.
So
first
one
is
that
we
are
now
providing
on
the
main
page
of
the
best
working
group,
some
additional
link.
So
there
is
a
link
to
the
implementation
requirement
for
EC,
which
was
previously
just
an
email
in
the
archive.
So
now
we
have
a
pointer
to
r2
this,
which
is
quite
clear
and
we
have
the
new
wiki,
so
I
hope
people
are
enjoying
the
wiki
and
I
think
it's
I
hope
it
will
be
useful
for
the
working
up.
A
Milestones,
one
of
the
action
item
we
had
from
the
last
meeting
was
to
refresh
the
milestones,
so
we
have
set
up
a
pair
of
milestones,
so
the
first
one
is
about
yeah
VPN
model,
which
is
targeted
to
be
sent
to
all
the
iesg
on
June.
So
it
is
quite
urgent
progress
on
this
document
for
any
sage
control
plane.
Based
on
the
discussion
with
the
Alfa's,
we
set
a
milestone
to
send
the
document
to
a
AG
by
March.
We
are
a
bit
late
on
that.
A
B
A
A
C
E
A
A
A
A
One
of
the
important
one
for
us
is
the
European
prefix
advertisement,
which
was
really
relying
also
on
the
internet,
subnet
forwarding,
but
this
document
has
just
been
pushed
too
much
in
for
ad
review,
so
we
are
on
the
good
traction
at
closer
to
closest
one
and
the
F
election,
it's
Aria
in
RFC
editor.
This
is
also
an
important
piece
of
work.
E
F
G
So
yeah
I
wasn't
listening
to
a
Manchu
and
he
said
it
wasn't
working
so
yeah
I
have
to
and
I
think
I've
pinged
the
authors
of
some
of
talk
of
some
documents
on
which
those
depend
because
I
don't
want
onward
ref.
If
you
don't
know
what
it
is
going
tomorrow,
see
no
I'm
waiting
a
bit
to
be
able
to
process
several
documents
which
have
dependencies
amongst
them
as
one
batch.
G
A
A
B
B
B
A
Okay,
next
one
is
the
best
solution
for
this
one.
We
have
a
major
issue
because
document
is
far
from
being
ready
to
be
sent
to
iesg
because
it's
targeted
to
be
standard
track.
However,
a
very
pretty
nothing
standout
in
term
of
nominating
longer
normative
language
in
this
document,
so
the
work
is
quite
huge
to
make
it
released
on
the
track
at
least
the
way
to
describe
today.
A
So
one
possibility
that
offers
offering
is
that
the
propose
to
split
the
document,
one
for
the
BGP
extension,
which
will
be
standard
track
and
the
other
one
to
be
informational,
and
this
may
is
the
possibility
for
the
document
to
progress
because
making
its
standard
track
the
way
it
is
present
today.
That
will
be
a
huge
work,
I
think.
A
B
Okay,
just
another
update
on
the
v+
multihoming
I
did
actually
receive
a
not
an
email
from
from
the
editor
other
day
ago.
So
they're
just
waiting
for
the
the
ATF
submission
process
to
reopen
and
then
they'll
they'll
submit
new
versions.
We
might
infer
a
few
months
I
think
to
that
I.
Think
after
that's
done
see.
A
A
No,
so
yeah
Greg
has
to
provide
some
some
feedback
to
Jay
friend
this
one.
We
have
a
lot
of
documents
that
are
pretty
ready
for
working
tax
code
if
our
Q
is
not
up-to-date
and
if
you
think,
for
example,
that
one
of
his
documents
is
not
ready
for
working
on
place
called.
Please
advise
us
to
make
it
updated.
A
So
fit
as
I
think
is
that
at
a
certain
point
we
have
a
bottleneck.
If
we
have
too
much
document
and
our
Shepherd
with
you
and
if
we
don't
have
enough
shipper
to
review
the
documents,
we
may
not
be
able
to
accept
any
additional
working
or
pleskot.
So
you
need
also
to
help
us
to
review
the
documents
to
make
as
process
going
faster.
So
if
you
want
to
review
any
documents
feel
free
to
be
around
here
as
a
shadow.
A
A
We
have
also
benches
of
documents
that
could
be
ready
for
working
up
last
call
again
if
our
who
is
not
up
to
date,
yeah
just
just
let
us
know-
and
yes,
we
are.
We
had
this
ongoing
for
about
the
I.
Am
the
extended
mobility,
so
support
was
extended
because
of
quite
a
lack
of
support,
but
now
we
have
significant
support
to
make
it
adoptive.
A
Working
up
statues
so
I
will
not
review
it
just
for
information.
This
is
a
feedback
that
we
have
received
from
the
different
editors
of
the
working
group
documents.
However,
we
are
still
missing
a
lot
of
updates
on
some
working
documents,
so
please
ensure
that
we
get
an
update
before
Semitic,
but
also
in
between
the
meetings.
So
we
can
track
the
different
issues
we
will
have
and
we
can
also
help
you
it's
as
if
it's
necessary.
A
H
A
A
A
A
I
First
Ali
so
Jesse,
so
the
errata
are
very
simple,
the
one
that
being
compiled
and
that
can
be
done
in
ten
minutes,
but
there
are
certain
sections
that
needs
to
be
improved
and
certain
sections
to
be
clarified
and
one
other
section
needs
to
be
added,
and
so
I
want
to
do.
You
know
all
these
in
the
these
new
7432
base,
and
so
it's
going
to
the
scope
of
the
work
is
bigger
than
just
initial
areata.
Yes,.
I
Over
the
past,
the
the
deforming
that
started
like
at
five
years
ago,
so
over
past
five
years,
we've
gathered
input
and
comments
with
respect
to
what
areas
are
not
clear
and
needs
to
get
clarified
and
so
forth.
So
I
think
we
got
the
data
points
to
to
move
forward.
So
it
is
the
right
time.
Okay,
so
anyway,
we
can
start
the
work
and
you're
gonna.
I
A
A
We
would
like
to
get
also
presentation
on
updates
of
working
group
documents,
because
this
is
IO
our
priority
in
term
of
work
of
processing
work
and
we
need
to
progress
through
working
of
documents.
At
a
certain
point,
honestly,
I
don't
think
we
will
be
able
to
adapt
any
new
working
group,
any
new
document
as
a
working
of
item
if
we
are
not
able
to
close
with
the
existing
working
of
documents.
Okay,
so
it's
been
now,
maybe
two
or
three
or
maybe
four
ITF,
where
we
have
almost
full
session
for
the
next
one.
J
Hello,
my
name
is
Luke,
hey
I'll,
be
presenting
today
updates
to
three
drafts,
one
working
group
document
and
the
other
one
personal
drafts.
So
the
first
one
is
the
evpn
yang
model,
as
you
heard.
Essentially,
the
the
evpn
yang
milestone
was
missed
and
we're
now
trying
to
close
this
working
group
document.
So
a
couple
updates
since
the
last
IETF,
the
first
one
is
the
Ethernet
segment
definition
in
the
yang
model
was
was
very
incorrect.
J
The
second
thing
that
we
changed
was
normalized
some
portions
of
the
yang
model
to
standard
yang
types.
So
two
things
two
major
things.
Actually
the
first
one
is
normalized
MAC
addresses
from
hex
strings
to
the
yang
MAC
address
type
from
69
91.
The
second
one
is
to
normalize
the
BGP
route
targets
to
82
94,
which
is,
which
is
sorry,
the
the
routing
area
of
base
yang
types.
J
A
third
thing
is
that
now
the
the
yang
Bala
dater
tool
is
available
and
is
actually
mandatory
for
free
yang
drafts
when
you
update
them,
so
as
a
sister
F
was,
was
reposted
updated.
Actually,
there
were
a
couple
couple
red
flags
that
came
up
from
yank
validator,
so
these
were
fixed
in
the
draft
just
minor
versioning
in
610
and
syntax
Corrections.
J
Actually,
the
BGP
portions
should
be
folded
into
essentially
the
BGP
base,
with
essentially
just
defined
only
the
the
extensions
to
that
free
VPN,
so
so,
essentially,
I
was
going
to
seek
last
call
I
think.
The
idea
here
would
be
to
publish
a
no
8
with
everything
that
I
that
we
collect
this
week
and,
and
that
would
be
on
the
on
the
alias
rather
than
then
here
today.
J
E
J
J
This
is
essentially
provided
more
as
a
as
a
background
or
an
option.
I
guess
I
should
say,
option
rejected,
but
an
option
which
is
which
this
draft
builds
upon
with
the
1x1
ESI
solution,
so
that
the
twee
si
solution
achieves
some,
but
not
all
of
the
requirements
that
were
trying
to
address
with
this
draft.
However,
it
has
the
benefit
of
being
100%
backwards
compatible.
So
a
new
subsection
on
this
backward
analysis
was
was
added
to
to
version
o4.
J
Next,
there
was
a
section
on
on
EPIRB
in
this
draft
that
was
added,
essentially
the
applicability
of
EPIRB
and
how
and
and
the
procedures
to
achieve
it.
You
can
RB
with
this
load
balancing
mode.
So
the
next
steps,
essentially
the
logical
next
steps
for
this
draft,
would
be
to
to
bring
it
to
the
working
group.
K
J
So
I
can
go
over
it
again.
The
claim
is
not
that
the
the
one
yes
I
with
a
new
flag
would
be
backwards
compatible
at
a
hundred
percent.
It
is
backwards
compatible
if
the
receiver
of
the
route
ignores
any
bit
other
than
the
two
existing
bits.
So
it's
a
third
bit
being
defined,
and
only
when
that
one
is
understood
can
the
others
be
ignored.
Even.
K
J
J
The
the
third
draft,
the
last
draft
I'm
presenting,
is
version
3
of
the
port
active
draft.
So
the
first
thing
that
was
done
is
essentially
a
cleanup
based
on
comments
either
on
the
alias
or
in
person.
I
forget
regarding
the
use
of
non
stand
on
standard
terminology
in
the
draft,
and
then
there
was
a
few
references
that
needed
to
be
update.
So
just
a
bit
of
house
housekeeping
there,
this
section
for
port
active
over
IRB
interfaces,
so
we
have
productive
into
UV
NRV.
J
We
found
that
I
was
actually
not
as
clear
as
it
could
be
and
and
somewhat
superfluous,
so
that
that
section
was
actually
removed
in
order
to
move
the
document
forward
and
in
the
sense
that
that
can
essentially
be
addressed
either
later
or
doesn't
have
to
be
addressed
in
this
draft
and
the
next.
Actually.
The
next
point
shouldn't
be
indented
like
that,
so
the
draft
was
updated
include
a
recommendation
to
to
use
RFC
82
14,
so
they've,
even
DPW,
sl2
attributes
extended
community.
One
port
active
is
the
load
balancing
mode
into
EVP
and
bbws.
J
So
the
next
steps
for
this
draft
is
it's
actually
something
that
we
forgot
for
the
zero
three
version,
so
it
would
be
to
define
either
ADF
election
type
or
IDF
capability
flag
in
the
DF
in
the
DF
extended
community
for
from
the
from
the
DF
Draft,
so
either
request
and
I
in
a
proactive
algorithm
or
a
capability
and
then
essentially
move
the
draft.
The
draft
forward,
okay,.
K
J
So
my
personal
I
was
personally
leaning
towards
capability
because,
as
the
draft
stands
today,
it
actually
defines
both
modulo
and
HRW.
So
in
order
to
keep
those
DF
modes,
it
would
have
to
be
a
capability
with
those
modes,
so
that
was
my
I
was
personally
leaning
towards
that,
but
obviously
I
left
it
open
yeah.
K
I
I
I
I
So
when
a
PD
first
comes
up,
and
once
the
celebrity's
like
I,
said
between
yourself
and
each
of
the
interested
remote
Pease,
it
generates
a
th
pair
for
each
of
its
intended
ipsec
essays
and
that,
based
on
the
IP
to
that,
the
Hellman
group
transform
IDs
and
their
originating
originating
PE
distributes
th
public
value.
Along
with
the
neurons
and.
I
I
So
the
changes
to
these
Rev
there
were
some
editorial
and
the
Rev
0jf
talks
about
different
level
of
granularity
that
you
can
set
up
the
IP
sake
between
two
peers
and
aggregate
all
the
traffic's
over
that
IPSec
tunnels
at
the
pier
that
what
we
call
it
pure
level
and
you
can
have
one
or
more
multiple
such
tunnel
pair
P.
So
that's
at
the
pier
level.
Then
the
next
level
up
is
at
the
tenant
level
and
then
the
next
level
up
after
that
is
at
the
subnet
logo.
I
And
then
you
go
on
and
it
is
at
the
VPN
IP
address
or
VPN
MAC
address
level.
So
we
have
these
this
level
of
hierarchy
and
we
added
one
more
in
case.
I
need
to
set
up
an
IP
succession
between
the
two
attachments
regions,
so
that
got
added,
and
we
also
added
a
new
section
on
inheritance,
because
there
was
some
confusion
regarding
that
and
I'll
go
over
it
in
a
minute,
and
also
we
modified
the
sub
theories
for
better
optimization,
which
I'll
go
over
it
shortly.
In
terms
of
the
inheritance
of
security
policy.
I
Ipsec
tunnels-
let's
add
the
tenant
level
for
some
villains,
but
not
for
some
other
villains.
How
does
that
work?
And
the
idea
is,
if
you
don't
specify
these
IPSec
attribute,
then
when
you
advertise
it
with
the
tenant
route
or
subnet
route?
If
it
doesn't
have
this
attribute,
it
inherits
the
attribute
of
its
parent
and
the
parent
can
be
appear.
So
you
set
up
the
IPSec
tunnel
for
a
peer
between
p1
and
p2
and
then
for
the
tenant.
I
If
the
tenant
has
explicit
attribute
for
the
IPSec
session,
it
uses
that
if
it
doesn't
have
it,
it
uses
the
pennant
one.
So
we
added
this
new
section
to
clarify
it
and
I
think
there
is
a
still
room
for
improvement
after
some
discussion
we
everything
is
still.
You
know
there
is
a
room
for
improvement
of
that
section
and
the
other.
These
are
the
different
level
of
quality
which
I
went
over
last
time
and
with
the
TLV
for
these
IPSec
we
have
a
minimum
set,
and
then
you
add
to
that
the
minimum
set
that
is
needed.
I
I
Ricky
contr,
along
with
the
Pete
and
then
once
this
tree,
we
packed
it
into
a
theory
called
base
TLV,
which
is
this
one
and
the
format
of
this
you
will
see
it
is
different
from
what
we
defined
before
and
then,
after
that,
we
can
send,
along
with
that,
the
other
subtly
to
indicate
the
key
exchange,
data
or
policy,
which
is
you
know,
we
call
it
as
a
proposal
so
TLB
for
the
minimum
set.
We
need
to
send
this
theory
along
with
one
of
these.
I
H
I
Can
see
it
is
bit
you
know.
The
previous
rave
was
just
purely
based
on
the
Ike,
the
finish
and
various
we've
optimized
it
for
our
purpose
in
here.
So
dance
wrap
for
this
version
of
the
draft
and
we
want
to
source
it
more
input,
publish
the
ref
tube
and
then
after
review,
we're
gonna
request
for
the
working
group.
Adoption.
E
Go
ahead
here,
put
in
our
case
our
there
are
three
different
proposals
going
on
between
ideal
group
and
best
so
no
to
a
working
group
chair.
Please
make
sure
you
coordinate
this
because
they
all
run
on
top
of
my
draft,
which
is
complain
kept
in
some
or
they
need
to
be
coordinated.
The
second
comment,
I
have,
is
you
on.
I
Keys
over
yes,
what
then
this
point
for
that
between
the
pease
and
the
controller,
those
are
the
point-to-point
tunnel,
it
can
be
TLS
somehow
or
it
can
be
right
with
you.
Okay,
you
establish
those
words
okay
and
then,
once
you
have
that
for
the
setting
up
the
peer-to-peer
between
the
PE
to
PE
that
part
of
it,
you
don't
set
up
the
you
know,
I
treat
you
session,
you
use
the
BGP
that
is
already
goes
over
the
secure
sauna,
all.
E
H
E
A
I
I
I
A
L
Want
to
bring
up
a
different
issues
here,
just
before
this
we
had
I
to
herself
discussion.
We
have
spent
actually
quite
a
few
months
the
IP
sac
configuration
from
the
controller.
So
my
suggestion
is:
we
should
have
one
place
to
discuss
all
the
controller
dictated
IPSec
configuration
then
putting
into
either
bgp
on
a
data
model
Netcom
data
model,
so
we
should
have
consistent
because
the
way
you
have
it
today
here
the
IPSec
miss
quite
a
few
things.
You
have
one
type
of
imitation
ipsec
finding
with
the
client
traffic
right.
There
could
be
other
implementation.
L
M
M
M
M
M
I
M
H
M
I
M
G
G
G
O
Okay,
so
a
very
quick
update
on
the
BGP
signal,
the
multicast.
There
are
two
drafts
about
this.
The
first
one
is
BGP
using
multicast.
It's
still,
the
traditional
mode
occurs
like
a
pin
or
ml
DP,
and
the
only
difference
is
that,
instead
of
pin
message
or
and
I'm
not
label
mapping,
whether
in
BGP,
everything
else
is
the
same.
O
There
are
advantages
of
doing
this
signal
in
PGP
I'm,
not
going
to
repeat
those
here.
This
is
the
updates
that
the
difference
in
the
D
road
full
version
is
that
the
signaling
we
now
use
and
different
Safiye.
Previously
we
use
the
C
I'm
cassava
defined
in
that
or
working
to
group
document.
I
do
pass
MVP
in
pc
p--
drafts.
The
authors
actually
have
decided
to
stop
working
on
that
one.
O
So
the
we
continue
the
say
comments.
The
the
authors
believe
that
the
documents
are
mature
and
stable
and
ready
for
requesting
the
adoption,
and
we
also
have
got
two
new
authors
join
the
mark,
a
signal
draft.
There
are
actually
customer
interesting
impulse
message,
so
we
want
to
go
for
with
that.
Okay,.
A
O
The
next
presentation
is
about
three
relative
drafts
I'll
get
through
on
what
happens
eventually,
some
some
backgrounds,
especially
this
team's,
a
term
they
use
the
Union
VPN.
It's
it's
provide.
America's
service
interface
is
a
virtual
interface
used
to
sending
or
receiving
customer
molecules
traffic
through
the
provider
network.
It's
instead
shaded
with
provider,
tunnels
and
advertised
in
the
inclusive
or
selective
Quincy
ad
routes
in
the
Radley.
O
Could
that
has
a
panel
attribute
week
or
PPA
that
there
you
specify
the
panel
type
and
pan
ID
in
the
Olympian
case
the
evening
key
I
met
route
is
the
equivalent
of
the
IP
IP
in
the
ad
routes,
and
then
the
panel
segmentation
give
let's
say
you
have
a
network,
consists
of
multiple
ASA's
or
areas
or
regions,
and
for
whatever
is
in
technical
or
administrative
reason.
You
have
to
use
different
panel
types
or
panel
to
your
different
instances.
Then
you
use
this
procedure
called
segmentation
points.
O
The
significant
points
readapt
has
those
pins
a
routes
from
mastering
region
to
dance
regime
and
changes
the
PTA
to
specify
the
panel
type
used
in
the
next
region.
So
the
forwarding
our
segmentation
points.
It
has
been
assumed
that
to
be
a
label,
switching
traffic
arriving
from
upstream
segment
on
that
segment
points
is
label
to
the
next
one,
and
it's
just
like
a
unicast
in
various
options:
option
B
to
do
that.
O
O
O
That
makes
it
keep
tracking
easier
without
corresponding
individual
Espeon
0.
But
that
caused
a
problem
with
segmentation,
because
now,
without
those
corresponding
SPD
routes,
you
can
no
longer
to
other,
has
corresponding
labels.
That
is
required
to
do
people
switching
so
now
get
into
this
draft
share
in
the
originally
in
the
beer
or
working
group,
its
it,
the
dead
rat
was
brought
out
because
beer,
a
Bacon's
explicit
this-
allows
the
per
flow
tracking
with
segmentation.
Because
of
the
problem
we
just
talked
about.
O
Therefore,
that
draft
was
a
breath
share
was
proposed
to
say
that
in
that
case,
let's
use
IP
forwarding
at
the
segmentation
points
that
way
you
can
still
to
the
error
per
flow
tracking
without
the
corresponding
the
SPG
routes,
but
that
generated
a
lot
of
disguise
the
most
important
wise.
That's
IP,
forwarding
at
segmentation
points
it's
much
more
heavy
weighted
Cantera
compared
to
label
switching.
O
So
if
some
operators
would
rather
do,
I
label
sleepers
swapping
they
were
switching,
and
in
that
case
you
could
actually
trigger
as
pinzhi
routes
from
the
relief
ad
routes.
It's
just
reverse
it
that
solves
the
label.
Switching
problem
that
there
is
a
counter
argument
for
that
is
now.
You
have
more
control
States
for
the,
because
in
now,
you're
defeating
the
purpose
of
ask
the
LIRR
per-flow
bit,
but
then
there
is
a
contraband
for
that
is
that,
yes,
you
have
more
control
plane
state,
but
your
foreign
state
is
much
less
than
IP
forwarding.
O
Another
kind
of
argument
for
that
is
that
when
you
do
that,
you
introduce
a
delay
in
the
setup
of
the
or
they
were
switching
a
state
and
they
cause
the
traffic
laws.
We
need
to
the
switching
now.
There
is
also
a
counter
argument
for
that
and
the
mitigation
so
now
for
discussion
there,
and
also
this
is
not
specific
to
be
R
or
MD
p.m.
so
draft
John
best
MVP,
Olympian
graft
was
brought
up
to
first
explain
the
the
problem.
O
That
is
not
a
peer
specific
that
applies
to
both
MEP
EVP
and
explain
why
the
label
switching
has
been
the
sort
of
de
facto
supporting
option,
and
then
it
also
documented
IP
forwarding
method.
If
you
really
want
to
use
it,
but
we
point
out
the
pros
and
cons
of
both
Messer's
and
also
we're
trying
to
laying
out
the
basic
rules
that
can
be
allow
you
to
do
label
switching
when
when
you
want
to
even
when
you
want
to
do
IP
forwarding
so
others
rules,
I,
wanna
get
into
and
balan
II
that's
original
beer.
O
O
I
Clarification
questions
Alicia
agency,
so
that's
not
raining
here,
as
you
mentioned
earlier,
is
you
do
label
switching,
so
the
service
layer
is
MPLS?
How
about
this
situation
that
I
am
doing
you
know?
One
area
is
doing
MPLS.
The
other
area
is
doing
V
expand.
That
requires
the
IP
forwarding
at
the
switching
point
right.
That's.
O
I
The
question
is
would
be,
doesn't
make
sense
as
a
common
denominator
to
use
the
IP
forwarding,
because
IP
forwarding
works
for
all
scenarios
and
it
makes
a
control
plane.
You
know
simple
and
then
the
country
argument
with
the
IP
forwarding
that
you
mentioned
it
is
heavy
that
is
platform
dependent
for
some
platform.
It
is
heavy
for
some
others
they're,
not
so
that.
O
O
We
can
discuss
further,
but
I
think
it's
up
to
the.
We
is
probably
not
good
to
have
this
default
option,
but
we
lately
are
the
options
for
the
operators
to
because
different.
My
appraiser
may
have
different
opinions
for
different
scenarios,
so
we
just
talked
them
into
options
and
they,
whatever
they
choose
so.
O
First
of
all,
this
draft
the
earlier
versions
of
our
car
cover
quite
a
few
scenarios
with
terrific,
usually
enhancements
escape.
Those
I
will
talk
about
the
new
scenario
that
these
optic
turrets
look
at
this
diagram.
Here
we
have
our
four
ASA's
source,
a
s100
at
the
top,
a
transit
es,
220
s,
300
400
at
the
bottom,
while
using
entire
segment
ation
and
we're
doing
per
area
segregation,
which
means
that
ASPRS,
who
are
advertiser
interests,
IP
n
0,
which
is
type
2
Nepean
case
the
a
source
is
multihomed
through
p1
and
p2.
O
In
the
same
yes,
and
now,
if
you
look
at
that,
p3
at
the
bottom
is
300
and
p4
in
the
s400
they
do
their
upstream
P
selection
in
potentially
they
could
choose
different
extreme
piece.
For
example,
p3
to
the
p1
as
upstream
water
and
p4
chooses
p2
as
a
screen
router.
Because
of
that,
when
p3
and
p4
construct
there
seemed
odd,
considering
routes,
say
Marcus
routes.
Basically,
it's
like
a
equivalent
of
pin
joints.
They
will
use
this
construct
the
same
our
RL
and
basically
the
same
rocky,
but
with
different
well
targets.
O
O
Now
the
first
problem
with
that
is
that
some,
if
you're
using
selecting
panels,
then
P
3
and
P
4
only
enjoins
that
tunnel
routed
as
its
choosing
option.
P.
So
let
say
P
3
was
your
in
PE
ones
panel
and
people
or
joins
P
2
Stano
now
Olympia
is
ending.
Then
people
will
not
get
traffic.
So
that
is
one
problem.
O
There
is
a
solution
for
that.
In
fact,
the
procedures
specified
in
version
0
about
Samaras,
rather
propagation
rules,
actually
allows
you
to
construct
the
symbolic
a
straight
route
based
on
the
ingress
PE,
instead
of
based
on
the
ingress
ASPR,
with
that
P
3
and
P
4
work
instructs
different
routes,
so
now
P,
1
and
P
2
will
both
get
the
samantha's
routes
and
then
both
was
in
traffic
and
when
you
use
selective
tunnel
issue
will
just
receive
the
traffic
from
their
corresponding
upstream
PE
and
the
corresponding
panel
no
problem.
O
The
second
problem
is
that
after
your
problem
is
solved,
but
if
you're
using
inclusive
interest
tunnel
now,
when
post
P,
1
and
P
2
are
sending
and
then
the
same
ASPR
will
inject
the
traffic
into
the
same
interest
tunnel.
Now
P
3
and
P
4
work
at
two
copies
for
each
packet
and
it
does
not
know
which
copies
from
which
router,
so
they
cannot
do
the
discarded
traffic
accordingly.
The
other
problem
is
that
well
actually
that
first
problem
to
a
can
be
solved.
O
O
O
O
That's
that's
still,
the
that's
still
the
selectively
pano
case.
I
got
a
lead
runner,
but
then
in
the
inclusive,
hello,
kids,
that's
where
you
have
the
charity
work
to
pick
a
problem.
That's
the
problem
to
be,
and
there
are
choose
options
to
do
to
salute
solve
that
problem.
The
one
is
that
the
ingress,
a
SBR
or
attach
the
label
to
the
traffic
when
the
injected
the
traffic
into
the
interest
tunnel
that
way
the
egress
P
can
pair,
which
copy
is
from
which
ingress
PE.
O
The
second
option
is
that
ingress
ESP
are
actually
does
the
IP
forwarding.
That
comes
back
to
that
earlier.
For
a
topic,
that's
seen
some
cases,
IP
forwarding
is
desired.
So
in
this
case
the
ingress
ASPR
will
do
a
IP
boarding
and
it
was
shoes
on
behalf
of
others,
ingress
P,
and
it
will
only
accept
traffic
from
its
own
choice
of
oxygen,
P
and
inject
the
traffic
into
the
panel
and
the
heroines
happy.
So.
O
I
quickly
went
through
this.
It's
a
lot
of
details
there
Rick.
If
you
could
read
the
document,
talk
to
a
truss
on
the
email
on
the
mailing
list.
We
want
your
comments
so
then,
this
draft,
the
documents
covers
quite
a
few
scenarios.
This
new
one
is
new,
but
other
than
that.
The
authors
believe
that
the
document
is
ready
from
the
author's
point
of
view.
We
want
to
to
request
the
adoption,
because
it
solves
a
real
problems
in
a
bikini
and
some
EVP
use
cases.
P
Sorry,
okay.
So
the
main
sort
of
motivation
for
this
proposal
is
the
EVP,
an
IRB,
Network
or
layer
to
overlay
network
that
uses
a
VPN
as
the
control
plane.
So
as
it
stands
today
for
an
EVP,
an
IRB
or
a
layer
to
overlay
network
using
a
VPN,
we
don't
really
have
a
dedicated
PC
control
plane.
So
as
a
result
of
that,
all
C
eMac
learning
is
based
on
data
plane,
source
mac
learning
and
any
host.
P
This
data
plane
based
mac
and
IP
learning
is
also
subject
to
or
has
to
deal
with.
Non-Deterministic
hashing
of
packets
across
the
multihomed
lag
link
and,
in
addition
for
use
case
where
the
C
might
have
prefixes
behind
it,
but
does
not
run
a
dedicated
PC
dynamic
protocol
on
the
PC
link
advertising.
These
prefixes,
with
our
behind
a
c
e,
is
typically
done
using
local
policy
configuration
on
the
b.
P
So
in
addition
to
so
the
eventual
sort
of
goal
being
by
by
doing
that
is
to
achieve
a
very
consistent
and
reliable
convergence,
behavior
across
all
convergence
scenarios
and
host
mobility
events,
and
in
addition,
while
we
do
that,
we
also
achieve
a
fair
bit
of
or
significant
simplification
in
lot
of
multihoming
related
and
MOOC
workload.
Mobility
handling
scenarios
so
just
a
quick
overview.
The
control
plane
proposed
is
based
on
link
state
over
Ethernet
as
the
base
protocol
that
protocol
it's
a
fairly
simple
link
layer,
auto
discovery
protocol
that
is
covered
in
a
separate
raft.
P
In
addition
to
that.
So
what
this
graph
focuses
on
is
basically,
it
defines
procedures
and
LVS
for
mac
learning
using
this
control
plane.
It
defines
procedures
and
tlvs
for
ipv4
and
ipv6
host
IP
learning,
and
it
defines
overlay
alvey's
for
ipv4
and
ipv6
prefix
learning
via
this
control
plane.
Then.
In
addition,
the
draft
also
discusses
essentially
how
to
do
all
of
this
learning.
P
So
the
control
plane
itself
is
I
mean
it's
fairly
straightforward,
LSO
EE
that
is
used
as
the
base
protocol.
It's
a
connection-oriented
link
layer
protocol
so
using
LSO
e,
a
connection
or
a
session
LSO
a
session
is
established
between
the
PE
and
the
C
on
the
PE
at
a
CH
Minh
circuit.
Once
the
session
is
established,
which
is
essentially
using
LSO
e
hello
and
open
packets
overlay
host
tlvs
are
exchanged
which
can
include
mac,
IP,
tlvs
and
overlay
prefix
tlvs
and
once
the
tlvs
are
exchanged
and
learnt
LS.
P
On
the
multihomed
links,
the
peas
have
to
implement
significant
procedures
to
basically
keep
the
tables
and
sync
across
the
two
peas,
as
well
as
handle
unsolicited
ARP
and
indeed
once's,
as
as
an
example
I
mean
when
PE
to
arts
for
c1,
the
arc
response
could
go
to
p1
and
the
p1
has
to
handle
that
unsolicited
response
and
then
sync
the
entry
over
to
the
other
P
you
you
have
to
go
to
some
conclusion.
You
are
also
tied.
P
P
Now
the
are
probe
reply
might
go
to
the
other
PE
and
that
our
country
has
to
be
synced
over
to
this
PE
and
the
route
type
2
has
to
be
really
generated
to
achieve
I,
P
and
Mac
ecmp
conclusion:
physical,
okay.
So
so
basically
I'll
just
conclude
with
this
particular
use
case
right
like
so
as
opposed
to
that.
Basically,
with
LSO
e
is
essentially
once
the
host
moves.
The
LSO
a
session
is
established
to
the
new
PE
and
the
route
type
2
is
advertised
and
the
network
essentially
converges.
P
Mixed
it,
okay,
all
right
so
classical
conclusions;
okay,
okay,
so
the
conclusion
being,
basically,
you
know
what
it's
essentially
trying
to
achieve
is
deterministic
convergence,
behavior
across
all
sort
of
link,
failures,
host
mobility
and
boot
up
scenarios;
a
learning
procedure
that
is
fully
d-cup
from
any
non-deterministic
behavior,
with
respect
to
data
traffic
coming
from
Cee
and
so
forth,
and
and
also
address
prefix
learning
for
scenarios
where
there
isn't
a
dynamic
routing
protocol
running
between
the
P
and
C.
All
right.
D
So
we
I
mean
at
the
very
basic
level
right.
We
have
a
bunch
of
servers
and
some
objects
and
we
need
to
devise
a
mapping
of
the
objects
to
the
servers
that
will
ensure,
like
uniform,
load,
balancing
and
also,
very
importantly,
is
like
it
should
satisfy
some
minimal
disruptions
when
like,
for
example,
a
server
goes
down
or
a
new
one
comes
up.
You
want
the
reassignment
to
be
as
minimal
as
possible.
D
That's
the
basic
idea,
and
here,
as
I've
shown,
there
are
like
servers
at
the
top
s1
s2
s3,
and
there
are
some
objects
which
I
have
put
some
number
like.
That's
the
key.
So
it's
easy
to
see
that
the
modulo
n
assignments
are
very
unfair
like
if
something
goes
down
server
goes
down,
then
the
mod
operator
over
s
will
result
in
all
kinds
of
reassignment.
So
this
is
standard
stuff.
So
what
we
did
some
time
back
is
we
use
this
highest
random
wave
concept?
D
We
get
a
hash
out
of
the
server
ID
and
the
object
ID
and
that
some
concatenation
in
some
form
and
we
compute
the
hash.
Whichever
hash
comes
out
to
be,
whichever
value
comes
out
to
be
maximum.
We
assign
the
object
to
that
particular
server.
So,
for
here
you
can
see
that
597,
that's
the
object,
ID
object,
key
with
597,
is
mapped
to
s1
and
similarly
for
3
1,
8
10,
2,
3
3,
okay.
So
all
this
is
standard
and
we
have
used
it
in
the
DF
election
framework.
D
We
have
used
it
in
a
couple
of
other
evpn
wraps
like
multicast
and
then,
but
the
key
thing
is
I
mean
the
talk
today
is
like
what
happens
when
there
are
weights
like
the
servers
are
not
of
the
same
weight
and
in
this
talk
we'll
cover
what
is
the
application?
So
one
approach
is,
we
can
take
the
weighted
score.
D
We
take
the
the
load
fraction,
which
is
the
weight
over
the
we
take
the
normalized
weight,
basically
the
weight
over
the
sum
total
of
all
the
weights
and
multiply
the
with
that,
and
whichever
comes
out
to
be
highest,
we
can
again
map
that
that
object
of
that
particular
server
right.
But
the
key
thing
is:
does
it
obey
this
minimal
disruption,
properties
of
the
JW,
so
I've
just
cooked
up
an
example
here,
the
same
thing
as
before
with
object
key
ID
233
and
we
have
some
weights
like
server.
D
One
is
associated
with
the
weight
of
50
server
to
wait,
15
server
3
is
20
and
server
for
is
like
15,
we
take
the
normalized
weight
and
those
are
like
0.5,
0.15,
0.2
and
0.15.
As
you
can
see,
and
then
we
just
these
things,
these
things
we
will
just
multiply
together
and
then,
whichever
comes
out
to
be
highest,
will
put
233
there
right
and
so
now,
let's
say
that
the
server
s
2
that
we
changed
from
15
to
25,
so
the
normalized
weight
for
everybody
changes
and
again
to
do
this
computation.
D
D
So
using
this
method,
we
can
come
back
to
our
the
unequal
load,
balancing
problem
that
this
advanced
to
the
working
group,
some
time
back
top
one
and
there
these
are
the
DMZ
links.
These
are
the
PE.
These
are
the
VLANs
and
you
can
see
that
this
whole
problem
that
we
did
there
we'd
use
some
empirical
methods
and
that
kind
of
like
set
us
thinking
that
this
is
not
probably
the
right
way,
and
then
we
thought
over
this,
and
then
we
find
this
whatever
has
been
done
prior
and
what
I
just
showed.
D
We
can
just
apply
this
here
and
it
will
automatically
solve
this,
so
there
are
some
couple
of
other
applications.
That's
why
the
name
of
the
draft?
Yes,
you
have
to
conclude
now,
okay,
so
the
conclusion
is
it's
a
new
efficient
way
to
compute
the
HRW
for
the
unequal
costs.
I
think
that
would
summarize
it
thank.
A
G
A
C
Thank
you.
My
name
is
guru.
Rivera
I'm,
with
LinkedIn
purpose
of
this
talk
is
to
cover
the
bee
tree
based
overlay
services.
This
draft
has
been
presented
before
in
IDR.
Couple
of
times
was
focused
on
BGP.
It
was,
and
has
been
now
moved
to
BES,
so
there
were
six
revisions
which
were
there
so
we
presented
a
ninety-eight
ITF
ninety-eight,
the
l3
VPN
over
SR
v6.
We
presented
the
EVP
anniversary
six,
also
there,
including
the
Glo
laughy's
in
idea.
101
we
have
the
this
document,
has
matured
and
also
the
service
s.
C
A
v6
ecosystem
has
matured
quite
significantly.
We
have
multiple
deployments.
Some
of
the
customers
are
here,
in
fact,
for
our
own
use
case
as
an
operator,
we
have
use
cases
for
this.
We
also
have
relevant
documents
like
network
programming
for
our
v6,
which
are
already
in
working
group.
Adoption
calls
and
also
the
deployments
are
there,
which
has
been
announced
by
a
few
vendors
for
asar
v6,
VPN
v4,
and
there
is
work
already
going
on
for
VPN
visas,
alright.
So
this
is
a
minor
update
to
the
document.
C
We
took
a
lot
of
feedback,
which
was
there
during
on
the
thread
and
also
from
the
implementation.
I
have
a
slide
which
covers
all
the
implementations
across
multiple
vendors,
so
we
modified
the
CID
TLV
I'll
cover
that
we
also
included
the
SR
v6
data
sub
sub
TLV
for
some
optional
for
the
future
proofing,
and
besides
that,
there
has
been
not
been
any
major
updates
into
the
document.
C
C
That's
the
service
tree
will
be
so
essentially
now
you
have
a
TLV
type,
basically
for
l3
services
to
you.
Li
are
the
l2
service,
TLV
TLB
length
of
16
bit
and
some
reserved
bits
for
future.
Then
the
info
set
information.
Tlv
is
the
core
of
it,
which
basically
carries
the
set
information,
so
you
can
have
L
three
sets
for
enabling
the
l3
services
like
nd
X,
4,
D
D
at
60,
T
6,
and
these
are
already
find
in
the
that
spring
network
programming
document.
So
there's
goes
into
lot
more
details
there.
C
The
alto
sets
are
also
designed.
We
also
have
some
arguments
which
is
I'll
cover
in
the
next
slide.
What
that
means
and
those
provide
all
the
l2
services
with
segment
auditing
v6
and
as
I
mentioned,
there
is
a
data
subsidiary,
which
is
optional
properties,
for
the
SRV
succeed
for
the
of
to
be
able
to
encode
some
more
information
all
right.
So
what
does
the
set
looks?
Like
so
service
said,
actually
has
three
functions
or
three
properties.
C
There
is
a
locator
which
actually
tells
you.
You
know
how
to
route
to
that
particular
location,
a
function
which
actually
is
a
property
of
once
you
reach
there.
What
do
you
have
to
do
and
an
optional
argument
which
tells
you,
if
you
have
to
do
something
else,
and
it's
a
function
of
that
particular
node-
is
just
for
the
purpose
of
demonstration.
It's
showing
that
locator
is
bigger
than
function,
but
there
is
no
such
thing
of
locator
can
be
very,
very
small
and
a
function
takes
most
of
the
part.
So
it's
purely
flexible.
C
C
The
only
thing
is
we
are
putting
an
implicit
nullable
along
with
that
we
are
putting
the
SR
v6
in
for
sub
TLV,
which
has,
if
you're,
trying
to
do
d
t6
in
that
in
that
route,
type
5,
which
is
basically
doing
a
global
lookup
or
RDX
X
or
DX
4.
So
these
are
all
defined
in
the
network.
Programming
document
all
right.
Similarly,
for
since
the
service
set
is
kept
separate,
TLB
it
doesn't.
Actually,
it
also
enables
for
to
be
used
for
other
Hafeez.
C
So
in
this
case
the
ipv4
ipv6
base
behavior
does
not
change.
The
only
thing
is
the
ipv6.
Next
stop
is
used,
and
this
is
the
whole
idea
to
achieve
the
habituate
free
core
and
the
same
tlvs,
which
I
was
showing
earlier.
You
can
use
it
for
the
global
office,
so
you
have
n
DX,
X
and
DX
4
or
DT
6,
which
is
basically
saying
look
up
into
a
v6
table
or
DT
4,
which
is
saying
look
up
and
toward
a
v4
table
all
right
implementation
status
hours.
C
This
is
kind
of
as
if
you
can
see
the
overall
segment.
Routing
v6
has
matured
quite
a
bit,
so
we
have
implementations
on
two
Enders,
so
cisco
has
supports
it
on
their
iOS
XC
and
our
sex,
our
operating
system
and
it's
across
multiple
platforms.
So
you
have
it
on
a
SL
1,
K
s,
a
9000
and
NCS
5500
on
Huawei
side,
it's
implemented
on
multiple
hardware's,
as
you
can
see,
and
then
on
the
operating
system.
Vr
p,
v8
barefoot
also
has
implementation.
C
Since
it's
it's,
it
hasn't
presented
few
times
an
idea
will
we
are
seeking
the
I
think
the
the
document
has
matured
quite
a
bit
and
there
is
already
the
implementations
for
the
our
document
in
the
production
network,
so
we're
seeing
the
working
reproduction
also,
we
are
open
to
any
suggestions
and
Commons,
so
we
can
address
it
before
the
adoption.
Yeah.
Q
Peril,
thank
you
here
and
thank
you
for
the
Ayane
section,
which
has
cleared
up
the
previously
used
code.
Point
quite
nicely.
I
just
want
to
check.
Implementation
is
really
really
good.
You've
talked
about
deployment
to
to
production
networks.
What
happens
if
this
is
adopted
and
the
working
group
make
substantial
changes
to
the
protocol.
D
Q
Q
Q
K
Horrible
on
nokia.
Well,
thanks
for
bringing
this
draft
to
this
working
group,
but
you
know
I
know
that
the
truck
has
been
around
for
two
years,
but
this
is
the
first
time
that
is
presented
here
so
I
don't
think
it's
ready
for
working
the
adoption,
and
it
requires
some
discussion
in
this
working
group
and
in
particular,
in
the
last
meeting.
K
Some
of
us
gave
some
comments
about
the
use
of
the
trial
for
evpn
and
his
family
and
the
fact
that
it
was
actually
breaking
some
stuff
that
we
hear
we
usually
do
in
evpn
like
it's
breaking
the
packing
of
evpn
routes
or
is
also
breaking
things
like
the
busy
being
observation
as
you
could,
we
usually
send
with
the
dividend
routes,
so
there
are
still
a
lot
of
things
that
require
some
discussion,
especially
for
they
problem
feel
deployments.
So
that's
my
comment.
F
Mass
mass
of
the
van
and
I'm
near
the
operator
food
depot
in
his
future
with
for
the
LSB
pin
on
top
of
the
ax,
is
our
basics
network
successfully.
We
deploy
in
the
future
I
think
they
did
big
extension
for
all
the
segment
routing,
nah
I,
don't
think
it's
affected
the
normal
procedure
of
the
players,
VPN
c9
using
PvP.
F
What
did
the
significant
change
will
be
happy,
so
please
make
sure
the
what
the
exact
change
we'll
be
seeing
in
the
future
in
our
network
in
the
in
this
working
group,
so
does
that's
mention
the
uncertain
approaching
possibility
to
mention
that
uncertain
discussion
down
the
road
indeed
is
working.
It
kind
of
is
just
a
threat
important.
They
be
added
upon
the
production,
not
a
really
counterproductive.
F
F
C
R
S
Hi
I'm
one
from
Juniper
Networks,
so
today,
I'm
gonna
talk
about
the
strap
extended
an
optimized
ingress
replication
for
a
VPN.
So
some
for
some
background
information.
We
have
optimized
ingress
replication
for
a
VPN
Josh,
which
is
also
known
as
a
citizen
replication.
It
is
I
IDF
passive
in
draft,
so
optimized
the
ingress
replication
it
is.
It
is
a
way
to
using
overlay.
You
can
technology
to
deliver
broadcast
multicast
traffic
in
a
more
efficient
ways.
S
So
taking
example,
you
have
a
see
a
diagram
here
and
if
we
have
a
low-end
leaf
node
while
it
receive
a
copy
of
multicast
traffic.
So
in
order
to
do
the
river
to
east-west
traffic
to
the
rest
of
the
nodes,
it
has
to
do
ingress
replication
in
the
evpn
overlay.
So
this
consume
the
bandwidth
uplink
bandwidth
in
the
core,
so
a
system
replication
provide
optimized
scheme,
so
the
leaf
only
deliver
one
copy
of
the
multicast
traffic
and
in
the
spying
has
a
replicator
would
do
a
system
replication
to
replicate
to
the
rest
of
the
nodes.
S
So
this
way
you
see
the
advantage
of
the
saving
band
was
in
the
core
and
uplink
memories,
and
also
alleviate
the
burden
of
the
leaf
node
to
do
the
ingress
replication
so
next
to
support
a
on
leaf
multi-homing
for
assistant
replication.
It
requires
a
relief
to
using
the
localized
spur
horizon
scheme
and
because
of
that,
the
replicator
has
to
retain
the
source
IP
address
of
the
its
ingress,
a
relief
when
they
dude
assistant
occupations.
So
the
spy
in
this
example
has
to
remember
the
source
IP
address
IP,
one
love
the
leaf.
S
Does
the
assister
replication
to
the
rest
of
the
envy
notes,
so
this
bring
some
challenge
to
the
implementation.
First
of
all,
nada
hardware
can
support
his
features
and
second,
the
way,
there's
a
incrementation
complicity
in
order
to
do
this,
so
the
extending
optimized
ingress
replication
draft
to
specify
a
solution
to
simplify
AR,
multi-home
support
and
also
you
know,
is
sometimes
the
use
case-
some
use
case
using
amperes
/
x
encapsulation.
It
may
be
desirable
to
using
ESI
label-based
specialized
indoors,
so
the
extender,
optimized,
ingress,
replication
draft
or
support
oppose
spur
horizon
method.
S
On
top
of
that
at
simplified,
the
a
a
replicator
procedure-
okay,
so
this
is
a
highlight
what
would
be
was
to
extend
procedure
for
a
replicator.
A
a
replicator
is
no
longer
required
to
dude
a
system
application
for
it's
AI
leaf.
So
this
way
it
does
not
need
to
retain
the
source.
Ip
address
are
dealing
with
the
ESI
label
of
a
relief
in
case
ESI
label
based
this
horizon
rule
is
a
used.
So
now
a
replicator
support.
This
draft,
who
extended
remote,
informing
a
replicator,
a
signal
to
as
a
a
octopod
knows
its.
S
It
is
following
this
extended
procedure.
Through
the
control
crane
by
attached
EBP
mo
to
cast
a
flag
extended
community,
there
will
be
a
new
bit
set
when
this
bit
is
set.
It
means
AI,
replicate
replicator,
is
a
perform.
This
procedure
extended
procedure
on
the
AI
leaf,
so
first
of
all,
it
will
detect
the
Aegon
replicator
is
doing
the
extending
the
optimized
a
ingress
certification
procedures
through
this
community
and
the
behavior
today.
A
leaf
is
that
is
to
send
a
copy
of
one
copy
of
the
traffic
to
its
replicator.
S
There's
no
change
on
that
front,
but
AI
leaf
in
addition,
yeah,
and
if
we
do
the
normal
assistant
replication,
our
normal
ingress
replication
to
send
a
multicast
or
bound
traffic
to
its
multi-home
p.m.
so
this
way
conclusion
and
the
next
steps.
So,
as
you
can
see,
this
extend
and
optimized
ingress
or
casing
procedures
in
provide
a
way
how
to
support
a
le
AR.
S
S
Within
five,
so
am
I.
Gonna
talk
about
a
procedure
for
proxemic
IP
advertisement
in
a
VPN.
This
is
a
enhancement.
Build
based
on
I
have
C
seven,
four,
three,
seven,
four
three
two.
So
this
is
the
scenario
in
the
SE
e.
Is
the
motorhome
to
a
set
of
redundant
EVP
MPs,
so
in
active
Actimel,
no
more
I
depend
on
data
burning
data
plan
learning
that
mechanism
only
a
subset
of
he
or
one
of
the
P.
You
will
learn
the
Mac
IP
host
findings-
operandi.
S
In
this
example,
only
p1
like
this
macro
Messiah,
be
binding
and
a
through
bgp
control
plan.
The
recipe
learned
this
findings
through
bgp
right.
So
what
happened
now?
If
the
PE
one
suffered
a
failure
or
the
link
between
the
P
and
C,
goes
down
the
whole
trace
of
this
map.
Press
IP
is
gone.
A
custom
type
to
pol
withdraw
the
type
two
routes
right,
so
they
will
be
a
gap
before
the
PA.
We
learned
this
map
plus
IP
through
as
a
PA
in
the
network
right,
so
this
cause
unnecessary
network
sure.
S
So
the
solution
to
that
is
one
p.
One
received
this
data
paren
learned
map
pacified
IPS
through
the
control
prime,
if
as
if
he
only
in
London
Express
IDs
through
the
control
parent,
not
a
Datagram,
it
will
also
advertise
the
same
Makris
IPS
through
the
type
to
rob,
but
was
the
proxy
indication
the
proxy
indication
is
done
through
up
and
the
extended
community.
We
allocate
a
new
new
bit
to
specify
when
that
bit
is
set.
This
is
the
proxy
and.
S
So
remote
EU
what
happened
to
the
remote
PE
behavior?
There's
no
change
remote
piece.
There
is
no
change
in
the
precision
normal
P,
not
on
this
mother
home.
The
Ethernet
sacrament
just
behave
as
as
is
today
so
now
when
the
no
darling
calf
area
goes
away
and
if
data
plan
learned
of
macros
IP
is
withdrawn.
Basically
they
don't
have
a
proxy
bit
set.
That
means
data
and
learn
a
mattress,
IP
type
2
routes.
Then
those
PE
has
proxy
type
Tourelles
worse
than
the
timer.
S
S
I
I
Him
no,
no
just
Mack,
then
let's
say
the
Mac
gets
hashed
to
one
of
the
multihoming
Pease.
How
do
we
handle
that
other
Pease
receive
it
and
then
the
remote
keys
to
the
proper
load
balancing
we
do
that?
Let
me
you
know,
answer
my
own
question.
We
do
that
via
the
aliasing
okay-
and
this
is
basic
and
alternative
method
for
aliasing
for
IP
plus
Mac
question
is
why
not
use
aliasing
for
IP
plus
man
and
for
that
I
introduced
a
draft
two
years
ago
regarding
how
to
do
it.
S
So,
okay
I
also
have
this
question
when
I
first
working
on
this,
you
know
anything
function
on
the
way,
also
achieved
the
load
balancing.
If
you
withdraw
a
little
later
start
a
timer
same
scheme
right.
So
the
reason
I
see
the
advantage
for
for
using
the
proxy
is
that
you
know
it
seemed
it's
the
whole
VPN
network.
So
we
have
a
different
implementation
from
different
vendor.
S
You
do
not
know
what
is
the
timer
whether
this
product
has
a
timer
whether
the
other
prop
does
not
have
a
time
across
erasing
features
will
also
help
overcome
the
network
channel
if
the
timer
is
in
used
on
the
motorhome
PE
and
the
remote
piece,
so
they
need
to
work
cooperatively.
But
when
you
have
a
different
Venice
product,
a
different
version,
you
do
not
know
whether
they
all
have
the
same
scheme,
so
is
the
proxy
fit.
S
The
idea
is
that
remote
PE
is
ignorant
about
whether
this
type
to
routes
is
learned
from
data
plan
or
learned
from
control,
and
so
when
the
P,
who
advertised
the
sprouts
through
the
data
plan,
withdraw
the
rest
of
these
to
advertise
through
the
proxy,
so
remote
PE
was
to
keep
it.
So
that's
the
one
other
advantage.
I.
S
I
E
K
Thank
you,
okay.
So
this
is
a
very
simple
and
straightforward
draft.
So
speaker
item
filtering
is
basically
what
we
use
in
any
VPN
to
avoid
peas
from
looping
the
traffic
back
to
the
SCE
in
all
active
multihoming,
and
there
are
two
types
of
split
speaker,
eyes
and
filtering.
So
one
is
the
ESI
based
spray
horizon
and
the
other
one
is
what
we
refer
to
as
local
bias.
So
when,
when
you're
dealing
with
MPLS
tunnels-
and
you.
H
K
Use
this
ESI
label-
speaker
Eisen,
that's
what
you
have
on
the
left
hand.
Side
of
this
slide
so
basically
see
to
send
spam
traffic
to
p1
p1.
It's
going
to
send
it
the
bomb
traffic
to
p2
and
pushes
the
ESI
label
and
on
p2.
Because
of
that
we
know
that
is,
that
is
coming
from
the
Ethernet
segment
and
we
will
not
send
the
traffic
to
the
local
same
Ethernet
segment.
So
when
you're
dealing
with
other
tunnels
like
at
the
exam,
for
instance,
or
MV
GRE,
you
don't
have
that
ESI
level.
K
There
are
no
labels
whatsoever,
so
you
rely
on
the
tunnel
source
IP
in
order
to
do
the
filtering,
and
that
requires
some
changes
and
the
changes
are
basically
that
the
ingress
B
needs
to
Ford
locally
to
all
the
local
Ethernet
segments.
So
anyway,
so
both
mechanisms
I
have
pros
and
cons.
Basically,
you
have
them
reflect
it
on
the
slide,
but
here
the
bottom
line
is
then
some
tunnels.
They
only
support
one
of
the
mechanisms,
but
there
are
some
other
tunnels
that
they
support,
potentially
both,
for
instance,
and
pls,
over
GRE
MPLS
over
UDP
or
genève.
K
K
So
that's
why
it's
a
composite
tunnel,
so
in
RFC,
83,
1
7,
and
this
composite
PT
is
only
defined
first
of
all
for
evpn
entry
and
secondly,
it
is
very
scope-
is
very
narrow
in
the
sense
that
is
basically
a
composite
and
PT
a
means.
We
use
always
P,
2
and
P
to
transmit
an
English
application
to
receive.
K
So
we
want
to
generalize
the
concept
and-
and
we
want
to
make
it
available-
also
for
M
VPN,
also
for
multi-point
to
multi-point
tunnels,
also
for
assisted
replication,
and
we
also
want
to
generalize
the
concept
so
that
when
we
advertise
a
composite
tunnel,
we
may
also
want
to
transmit
on
English
application
and
not
only
on
20.
So-
and
we
do
this
basically
because
we
have
some
use
cases
where
this
is
important.
K
So
in
order
to
do
that,
so
basically
what
we
do
is
we
advertise
a
composite
channel
from
all
the
t's,
even
those
that
do
not
support
beer
in
the
data
path
and
and
in
this
composite
QT
a
for
instance,
we
advertise
the
appear
tunnel
information
along
with
an
English
application
available,
so
with
that,
basically,
what
we
can
do
using
the
EVM
beer
tour
after,
along
with
a
beer
PHP
draft,
we
can
have
you
know
all
the
ApS
that
do
not
support
beer
in
the
data
plane.
They
can
actually
use
English
application
to
send
bump
traffic.
K
We
have
a
similar
use
case,
which
is
basically
instead
is
similar
to
their
previous
one,
but
they'll
leave
P
routers.
They
send
a
single
copy
of
the
bum
packets,
and
now
we
do
that
because
we
combine
the
whole
thing
with
assisted
replication
and
again
in
this,
we
are
modifying
the
rules
that
we
have
in
assisted
replication
draft,
in
the
sense
that
the
leaves
now
they
need
to
advertise
a
composite
tunnel
with
their
with
angels
application
label
and
also
with
a
beer,
a
ton
of
information.
K
A
T
So
you
are
able
to
go
beyond
what
we
currently
have
with
source
and
group,
but
also
to
extend
it
a
little
bit,
and
we
do
that,
though,
using
an
extended
committee
attribute
using
new
types,
both
type
for
bandwidth
and
a
type
first
date,
and
we
leverage
the
the
extended
community
from
IDR
or
link
bandwidth
extended
community
to
be
able
to
share
that
among
species.
So
that's
kind
of
it.
T
In
a
nutshell,
those
of
you
that
are
familiar
with
this
problem
space
know
that
there
has
been
with
evpn
designated
for
door
election
and
an
increased
granularity
with
selecting
the
designated
foreigner.
It
began
with
7432
and
there's
been
some
drafts
that
many
of
you
have
worked
on.
I
have
not
participated
in
that,
so
I'm,
not
sure
if
you've
had
conversations
with
regards
to
making
it
even
more
granular.
I
So
I
can
read
till
end
of
the
presentation,
but
basically
I
just
want
to
mention.
There
is
a.
There
was
a
draft
that
Satya
presented
earlier.
It
is
for
the
exact
same
problem
and
space,
and
that
is
when-
and
it
is
called
baited
HRW.
So
instead,
when
you
have
different
link
bandwidth,
how
you
do
the
DF
election
at
the
different
level
of
granularity
with
the
minimum
disruption
and
the
application
for
it
is
warm.
The
application
is
for
multicast,
okay,.
U
T
Alright,
so
I
probably
don't
need
to
go
over
the
justification
of
it,
but
it
just
suffice
it
to
say
with
the
existing
IDF
election
mechanisms,
there
could
be
links
that
are
overloaded
and
at
the
bandwidth
is
not
shared
properly
amongst
the
different
links.
So
that
says
what
the
problem
that
we're
trying
to
solve
our
solution-
I've
kind
of
already
described
it
and
again
we're
using
the
IDR
link
bandwidth
to
that
extended
community
to
be
reused
to
transfer
among
the
peas.
T
I,
don't
have
time
to
go
through
these,
but
just
basically
show
how
you
can
like
how
that
we
can
make
this
work,
and
next
step
is
we've
done
already.
What
we
want
to
do
just
make
sure
we're
working
on
this.
If
you
do,
you
have
interest,
please
talk
to
us.
If
you
think
it's
a
silly
idea,
the
more
drop
up,
if
you
think
it's
a
good
idea,
I'll
keep
going
so.
R
Good
good
afternoon,
I'm
Susan
from
DTE.
This
presentation
is
for
PFD
usage
for
evpn
years,
fair
over
use
case.
We
have
Cola
syrup
on
the
grab.
Let's
see
the
problem
statement.
We
know
that
Elise
is
a
traditional
network.
Reading
European
say
he
is
multi-home
through
pul
and
Peru
and
we
know
God.
If
the
link
between
PU
RMSA
he
fails
on
top-2
at
work
is
elected,
is
EF.
The
packet
will
all
be
discarded
because
the
procedure
includes
the
PTP.
R
So
in
order
to
express
the
packet
discarding
from
p2,
we
use
the
mechanism
defining
FC,
58
84
and
the
structure
we
define
me
Jim,
miss
Olivia
RSVP'ing
to
improvement
the
situation.
So
you
know
that
was
the
PDF
in
this
example
is
p2
generates
our
sleeping
echo
requests
the
message
to
strap
up
after
station
between
PD
F
and
DF
likes
p2
to
p1
the
European
internet
auto-discovery
subtly
defining
jumba's
European
are
speaking,
is
currently
in
this
message
and
also
local
PFD
discriminator
is
carrying
the
message.
R
1Pf
in
this
example
is
p1
responds
with
the
PFD
control
packet,
you're
discriminators.
That
who
receive
the
discriminator
from
PE
to
the
PFD
session
can
be
beaut,
and
we
know
that
p1
will
send
a
pyramid.
We
have
the
control
happen
to
p2,
so
people
will
know
that
the
if
the
situation
between
purC
is
normal,
one
t2
fans
that
link
between
p1
and
the
C
link
fails.
R
I
R
I
I
But
the
couple
of
issues
I'd
like
you
to
consider
one
is
what,
if
there
is
a
congestion
between
p1
and
p2
and
the
messages
gets
lost,
and
in
that
case
the
back
of
the
earth
thinks
that
it
should
be
at
the
F
and
not
be
cut
to
DF
and
they
have
duplication,
that's
1,
and
the
second
thing
is
what
happens
when
I
have
on
eco.
You
know
unequal
bandwidth,
and
in
that
case,
that
link
fails
and
the
PDF
moves,
and
you
know,
are
you
going
to
try
to
set
up
a
new
game?
I
R
You
and
I'd
like
to
say,
and
between
P
1
and
P
2.
They
are
many
ways
to
build.
A
secession
in
the
setting
can
be
through
the
RSVP
RSP
or
IP
packet
L.
So
this
is
the
first
and
we
know
that
PDF
form
a
maybe
they
are
in
many
in
PDFs
in
this
situation
right,
so
one
PDF
is
elected.
According
to
the
same
algorithm,
the
election
algorithm
I
mean
a
lot
from
the
TF
relocation
framework.