►
From YouTube: IETF105-BESS-20190725-1740
Description
BESS meeting session at IETF105
2019/07/25 1740
https://datatracker.ietf.org/meeting/105/proceedings/
A
B
D
F
F
F
First
of
the
matter,
cos
of
VPN
models
is
at
the
same
level
as
unique
as
layer,
3
VPN
models
mother's
second,
nearer
to
levels
in
mark
with
Americas
to
Llamados.
The
first
level
is
the
VBA
instances
of
level.
The
second
level
is
the
key,
a
nice
here,
my
eye
level.
Here
we
have
an
inclusive,
PMSI,
selective
OPM,
I
sign
third,
both
ipv6
and
ipv4.
They
have
the
same
structure
of
Marrakesh
weakened
models,
and
here
I
introduce
the
major
changes.
The
first
updater
is.
We
introduced
new
type
P
tunnel,
which
is
defined
according
to
RFC
6513.
F
F
F
It's
defined
under
selective
PMSI
also.
We
have
introduced
upstream
of
VPN
labels.
This
is
the
for
the
scenarios
for
multiple
VPNs
sharing
the
same
pita
knows:
provider
Thanos
and
those
are
the
major
changes
since
day
and
we'd
like
to
have
more
comments
from
you
and
prepare
for
a
young
doctor
review.
G
I'm
rishabh
from
cisco
I
just
took
a
quick
look
at
the
model
is
actually
many
errors
which
you
might
not
see
on
the
data
tracker
page.
But
if
you
go
to
yang
Bali
later
yang,
catalog
yang
I
think
some
of
these
models
you're
using
have
changed
and
your
arguments
are
incorrect
and
all
that.
So
it
would
be
good
to
it's.
F
F
F
E
I
think,
as
part
of
this
model,
we
need
also
to
think
about
the
extension
to
vase
pgpr
model.
So
I
have
started
to
contact
via
a
few
guys
who
are
editing
via
VPN
weather,
to
try
to
agree
on
our
words
and
all
the
responsibility
ana.
And
what
should
we
do
as
part
of
the
best
of
the
best
work
so
globally?
The
conclusion
seems
to
be
that
we,
as
part
of
best,
should
be
responsible
to
add
a
kind
of
BGP.
E
Modules
that
should
amend
the
BGP
yang
model
to
provide
the
officially
an
Associated
container,
but
also
the
extension
to
the
routing
table
so
to
be
able
to
get,
for
example,
dbgap
local
read
for
M,
VPN
or
piano
l2.
If
you
know
whatever
address
family
that
we
are
creating
at
that,
are
not
fully
supported
in
the
base.
Bgp
model.
H
So
we
had
several
meetings
since
Prague
offline,
but
we
followed
up
with
another
one
during
this
IETF
week
with
all
these
stakeholders
to
to
close
on
many
of
the
open
issues
that
we
were
still
having,
including
some
of
the
issues
that
were
raised
already
on
the
mailing
list.
This
was
on
last
Tuesday.
H
Three
of
the
major
conclusions
from
from
this.
This
meeting
is
that,
first
of
all,
the
models
proposed
use
MPLS
encapsulation
as
the
as
the
de
facto,
and
what
that
means
is.
There
are
references
to,
for
example,
the
explan
encapsulation
in
these
yang
models
and
following
that
discussion,
the
the
base
concept
here
would
be
that
these
drafts
propose
essentially
a
foundation
for
the
end
caps
other
than
MPLS,
but
do
not
define
them,
so
there
is
some
cleanup
to
be
done
there.
H
H
So
we
do
have
a
list
of
those
the
more
the
more
striking
examples
are,
for
example,
moving
the
ingress
replication
to
be
attached,
for,
if
you
can
instance,
rather
than
the
way
it's
currently
defined,
which
is
global
per
evpn,
are
so
global.
In
the
model.
Sorry,
and
as
I
mentioned
previously,
some
of
the
things
like
AC
or
pseudo
are
choices
should
be
made
more
generic
to
be
extensible
in
the
future.
H
One
idea
that
came
up
would
be
to
create
a
base,
identity
for
load,
balancing,
so
currently
load
balancing
is
defined
for
all
active
and
single
active,
but
there
are
other
modes
being
defined
already
and
that
I
think
I
presented
in
Prague.
So
the
idea
would
be
having
a
base
identity
that
can
be
extended
and
there
was
a
conversation
around
a
splitter
rising
group
for
for
Evi,
so
it'll
be
completed
for
that.
H
H
I
This
is
a
mantra
from
Siena
I.
Don't
know
whether
you
just
touched
up
on
the
topic.
I
was
going
to
make
a
comment
on,
but
I
know
that
Stefan
and
Jeff
are
discussing
the
BGP
RDR
t,
inclusions
and
I
haven't
followed
up
the
thread,
but
I
won't
know
whether
that
means
we
have
to
do
some
more
work
or
what's
the
deal
there
with
respect
to
the
RDR
T
types
and
which
would
be
related
stuff,
the
policies
and.
J
Jeff
has
so
the
a
speech
P
model
right
now
is
where
some
identity
is
like
a
feast.
A
few
live
right
now
you
know
we're
in
the
process
of
figuring
out.
You
know
what
module
ends
up
owning
those
and
where
they
get
extended
from
you
know,
there
are
two
options
open
for
each
of
those
one
of
those
is
to
have
it.
I
am
a
managed.
It
just
gets
extended
there.
J
That
makes
it
fast
to
revise,
but
since
this
is
one
of
the
things
that,
in
the
end
that
you
can
revise
the
individual
module,
that's
also
a
possibility
as
well
the
inclination
that
I'm
pushing
right
now,
when
please
keep
in
mind
that
I've
just
started
helping
out
with
this.
This
is
a
long-standing
work.
Is
that
things
that
are
extensions
to
BGP
that
are
tied
to
one
of
the
VPN
servers
battles?
No,
should
actually
go
in
no
by
augmentation
when
possible.
J
If
we,
if
you
can
do
that,
it
means
that
the
design
that
the
ensign
of
the
base
peach-pit
module,
is
doing
its
job
and
you're
going
to
probably
end
up
with
separate
sub
modules
such
that
you
can
add
the
BGP
pieces
in
your
model
and
therefore
bgp
can
operationally
handle
the
protocol
components.
So
you
can
do
a
show,
BGP
and
see
here's
this
Fe
Safi,
no
4
do
Pedras
family
and
through
the
counters
court
as
an
example,
and
you
can
have
policy
extensions
to
the
idea
policy
module.
J
K
J
C
On
the
encapsulation
specific
parts
of
the
model,
I
think
probably
we
need
some
discussion
between
the
chairs
of
different
working
groups,
own
encapsulations,
applicable
to
a
VPN,
an
l2
VPN,
so
that
so
they
have
kind
of
a
modular
approach
where
maybe
the
working
group
that
owns
or
is
largely
developing
data.
Encapsulation
technology
takes
the
does
the
model
for
the
encapsulation.
So
we
don't
end
up
risk
ending
up
with
multiple
models,
the
same
encapsulation
or
application,
specific
models
for
the
encapsulation.
H
C
H
C
K
They
see
again
yeah
the
it
it
couldn't
be
a
couple,
but
it
should
I
think
it
should
reference.
Eighty
to
ninety
four
I,
don't
I,
don't
see
why
at
least
take
a
look
at
it,
and
this
isn't
I
Anna
maintain
model.
We
split
up
the
types
that
were
relatively
static
with
the
enums
for
the
address
friendlies
in
and
sat
BGP
Saffy's
just
to
in
order
in
order
to
allow
the
latter
model
to
be
maintained
by
and
I
Anna
and
periodically.
H
L
L
You
know
redundant
sources
that
are
single
home
or
redundant
sources
that
are
multihomed
to
the
network,
and-
and
this
should
work
in
any
evpn
tennen
domain
configuration
which
means
that
the
sources
and
receivers
they
can
have.
It
can
be
attached
to
the
same
broadcast
domain,
different
broadcast
domains
or
a
mix
right.
L
So
when
you
have
redundant
sources
and
what
that
means
is,
if
you
don't
do
anything
special,
let's
say
that
in
the
diagram
here
in
the
example,
you
have,
two
sources
are
actually
sending
the
same
flow.
The
same
multicast
flow
from
a
multicast
perspective
because
they're
coming
from
different
sources,
they
are
treated
as
different
flows,
and
what
that
means
is
that
basically,
the
receivers
will
get
to
placate
traffic,
so
they
will
have
to
deal
with
it.
L
Well,
we
want,
with
this
draft,
is
to
provide
a
solution
so
that
a
network
avoids
this
duplication
and
provides
a
redundant
solution.
So
one
important
concept
that
we
are
handling
here
is
what
we
call
the
single
flow
group
or
s
FG,
so
NS
FG
is
basically
a
multicast
group
that
represents
you
know
single
flow
that
can
be
sourced
from
different
IP
addresses
from
these
different
sources
right,
but
those
sources
they
basically
send
the
same
content
and
that's
what
the
you
know:
the
application
that
we
want
to
avoid.
L
So
there
are
two
solutions
in
the
draft,
so
the
first
one
is
what
we
call
the
warm
standby
solution
or
ws,
and
the
second
solution
is
what
we
call
the
hot
standby
solution.
So
the
first
one
and
apologies
for
the
this
slide
is
not
in
PowerPoint.
Actually,
it
looks
nicer,
but
basically
the
first
one,
the
it's
about
the
upstream
T's,
the
ones
connected
to
the
SFG
sources,
the
ones
selecting
only
one
of
the
piece
as
single
for
water
and
and
the
other
one
not
sending
the
DSF
G
right.
L
The
second
solution
is
basically
set
down
cmp
based
solution.
The
idea
is
that
the
upstream
keys
are
connected
to
the
redundant
sources.
They
both
will
send
the
traffic
and
the
downstream
piece
that
are
attached
to
the
receivers.
They'll
they'll
pick
up
one
of
the
two
right
and
they
will
avoid
the
duplication
and
obviously
there
are
procedures
in
case
of
a
failure
of
one
source,
the
other
one
will
have
to
take
over
and
you
know
with
a
fast
failover
so
which
one
is
better
now
why
we
are
including
both
solutions
in
the
draft
so
well.
L
It
depends
on
what
your
requirements
are.
If
your
requirement
is
to
optimize
the
the
bandwidth
consumption,
you
should
go
to
the
WS
solution.
If
your
requirement
is
to
upgrade
the
the
least
amount
of
piece
in
the
network,
you
should
go
to
the
AWS
solution.
But
if
your
requirement
is
to
have
you
know
the
fastest
failover
possible,
you
should
go
to
the
hot
standby
solution,
so
what
he
will
change
in
revision,
zero,
one
so,
basically
based
on
the
feedback
from
the
working
group.
L
Actually,
in
particular
from
manga
mana,
we
changed
the
definition
of
the
SFG,
so
individual
zero
zero
was
represented
as
star
Komachi,
which
pretty
much
means
that
any
source
transmitting
that
group
was
considered
to
be
a
redundant
redundant
source
for
the
sfg.
Now
we
have
finer
granularity
in
the
sense
that
we
are.
We
are
defining
an
Eskimo
G
where
the
S
is
actually
a
prefix,
it's
not
a
host,
and
so
the
any
two
sources
or
more
sources
that
are
contained
with
an
within
that
subnet.
L
The
Hansa
lengths
are
considered
redundant
sources
for
the
s
FG,
and
you
have
to
bear
in
mind
that
we
are
allowing
here
prefixes
to
be
sent
with
the
SP
MCAD
routes
only
for
the
particular
application
of
the
redundant
redundant
sources.
Only
that
the
other
improvement
that
we
are
adding
to
the
draft
is
in
in
version
0
0,
we
add
a
nes.
I
attribute
that
we
needed
to
send
along
with
the
SMC
routes,
but
it
was,
it
was
kind
of
open.
We
didn't
say
what
kind
of
attribute
it
was
so
here.
L
Basically
among
the
authors
we
agreed,
the
best
solution
was
to
add
any
si
label
extended
community,
which
is
already
defined
in
RFC
743
to
the
only
thing
is
that
we
are
advertising
that
community,
along
with
the
SP
MC
rounds,
and
then
this
is
used
for
the
hot
standby
solution
and
besides
that,
we
added
some.
You
know
we
fixed
some
typos
and
added
some
clarifications.
L
So
with
those
improvements,
this
is
how
the
warm
step
by
solution
works.
You
have
here
an
example
with
two
redundant
sources
for
one
s
FG,
and
that
receivers
are
attached
to
the
downstream
T's
and
again
this
can
be
any
type
of
PvP
antenna
network.
So
you
know
all
the
hosts
can
be
attached
to
the
same
broadcast
domain
or
different
with
you
know,
single
broadcast
domain
or
or
based
on
on
in
Oia
SM
Network.
So
here,
P,
1
and
P
2
would
be
configured
to
know
that
you
know.
L
L
We
will
advertise
the
SPM
z80
routes,
evpn
s
been
c80
routes
and
those
will
be
advertised
with
a
DF
election,
extended
community
defined
in
RFC
85-84
and
with
that
extended
community,
basically
the
the
to
upstream
piece.
They
will
be
able
to
select
what
we
call
a
single
forwarder
and
the
single
for
weather
will
be
the
only
one
sending
the
SF
g
and
the
other
one.
In
this
case,
p2
will
program
an
RPF
check
rule
to
basically
discard
the
traffic
as
long
as
the
single
forward
is
is
a
different
P.
L
So
this
is
if
the
first
solution,
the
second
solution-
is
a
hot
standby
solution,
and
here
you
have
an
example
about
how
it
works.
In
this
particular
example,
you
have
two
redundant
sources
for
the
s
FG
that
are
multihomed
both
of
them
so
in
in
this
configuration.
Basically,
you
need
to
upgrade
all
the
t's,
whereas
in
the
previous
one
you
only
had
to
upgrade
their
the
upstream
please
so
here,
p1
and
p2
will
be
configured
to
know
that
and
start
Komachi
for
instances
and
s
FG.
L
It's
important
to
highlight
that
the
the
ESI
labels
that
we
are
using
here,
they
are
DC,
be
allocated
ESI
level,
so
domain
wide
common
block,
and
we
do
that
because,
basically,
we
need
to
make
sure
that
you
know
p1
and
p2.
They
use
the
same
label
for
years
years,
one
and
they
use
a
different
but
the
same
label
for
years
too,
because
in
that
way
we
can.
We
make
sure
that
they
downstream
piece
they
can
identify
the
flow
coming
from
either
source
without
any
ambiguity.
L
So
after
that
they
use
a
labels,
are
also
advertised
in
a
deeper
years
routes
and
and
with
all
that
information
downstream
piece
are
able
to
make
some
RTF
check
programming.
The
idea
is
that
and
they
will
be
receiving.
You
know
the
same
s
FG
from
two
different
sources
and
therefore
from
two
different
with
two
different
ASI
labels,
and
they
should
be
able
to
discard
one
of
them
and
of
course,
there
are
procedures
about
what
to
do
in
case
of
a
failure
on
a
you
know,
on
a
link
on
the
the
whole
source
etc.
L
M
L
So
we
know
there's
a
PFT
draft
for
evpn,
so
actually
one
of
the
things
we
wanted
to
do
this
to
collaborate
with
the
authors
of
that
draft
and
see
if
we
can
use
it
here.
So
at
the
moment,
if
you
look
at
this,
the
PFD
section
in
this
traffic
is
just
mentioning
that
you
can
use
PFT
learn.
There
are
no
details.
Okay,.
H
H
L
This
so
basically,
you
should
use
either
or
in
a
single
turn
on
domain
right,
and
this
is
so
this
mode
basically
says
it's
purely
controlling.
If
you
will
so
the
upstream
piece
where
you've
configured
that
you
may
have
written
on
sources,
they
will
select
this
single
folder
and
that's
it.
But
there
is
no.
There
is
no
need
to
differentiate
in
the
data
path,
both
flows,
because
there
will
be
only
a
one
flow
coming
from
one
source.
That's
the
idea
and.
H
L
No,
this
is
so,
of
course,
these
are
regular
different
segments,
which
means
that
you
need
to
advertise
ad
various
routes
with
The
Associated
labels
right,
but
you
need
a
way
to
correlate
a
given
an
s
FG
to
a
given
it
on
a
segment.
So
the
way
you
do
it
is
basically
on
one
hand
you
advertise
the
regular
ad
routes,
but
on
the
other
hand,
you
advertise
the
tsfc
location
with
SB
MC
routes,
and
you
attach
the
same.
Esi
label
extended
community
that
you
are
using
for
that
particular
psi
and
you
can
have
multiple
sites.
K
H
L
N
So
it's
draft
on
the
network
layer,
OAM
and
where
that
fits
is
described
in
this
other
D
draft
on
the
OEM
requirements
and
framework
I
just
want
to
show
a
couple
slides
from
that
to
show
how
this
fits
in
this
is
the
typical
flow
from
CD
to
PE,
through
the
peas,
to
PE,
to
see
in
that
different
levels
of
OEM
are
shown
at
the
bottom
of
this
draft.
So
the
ones
that
are
handled
by
other
mechanisms
are
it's
pretty
straightforward.
Link
OEM
depends
on
the
link
technology.
N
The
transport
OAM
between
the
various
P
nodes
depends
on
what
transport
you're
using
this
different
methods
there
and
the
service
of
course
being
provided
is
Ethernet
service,
so
typically
you'd
use,
Ethernet,
OAM
end-to-end,
so
what's
left
is
the
the
network
o
am
from
p2p
just
what
this
draft
is
concerning
and
the
use
of
describes
the
use
of
BFD
for
that.
So
it
uses
VF
e,
asynchronous
mode
right.
Proact
default
detection,
basically
ferry
VPN,
based
on
things
in
the
pattern
of
RFC
7432.
N
It
covers
in
the
current
version,
MPLS
and
VX
lan
encapsulation
taps
lations,
unicast
traffic
broadcasts,
unknown
unicast
and
multicast
traffic
using
multi
point
to
point
and
point
to
multi-point,
so
the
BFD
discriminators
are
obtained
for
the
VFD
here
via
bgp.
This
graph
references,
the
MVP
n
fast
failover
graft,
which
provides
means
of
distributing
PFD
discriminators.
N
The
changes
from
the
last
graph
that
was
presented
are
to
add
that
mechanism
for
distribution
to
add
VX
encapsulation,
which
wasn't
previously
covered
and
there's
a
bunch
of
miscellaneous
improvements,
including
considerably
more
diagrams
of
practice,
headers
PFD,
discriminators
use
the
BGP
BFD
attribute
and
that's
pretty
simple,
as
shown
what
their
value
that
attribute
is
here
as
the
discriminator
and
some
flags
come,
none
of
which
are
actually
defined
currently
but
they're
available.
There's
some
future
need.
N
So
the
bulk
of
this
draft
is
devoted
to
specifying
the
encapsulations
for
MPLS
and
of
vvx
lan
as
a
type
of
there
for
these
different
types
of
traffic
and
there's
both
textual
descriptions
and
also
diagrammatic
descriptions
of
these
encapsulations.
So
to
show
the
level
of
detail.
I
have
a
couple
ones
which
you
probably
can't
read,
but
I
don't
know.
Maybe
if
you
should
download
the
slides
and
look
on
your
screen,
you
can
probably
read
them.
This
is
a
MPLS
unicast
encapsulation
and
the
X
LAN
unicast
encapsulation,
there's
also
diagrams
for
other
stuff
in
there.
N
So
I'm,
not
claiming
all
this
as
flawless
I'd
be
happy
to
have
people
look
at
this
and
they
find
problem
as
well,
we'll
fix
them.
There
are
things
that
could
be
added
to
this
draft,
the
covering
pvb
e
VPN
or
covering
the
IRB
invaded
routing
and
bridging,
or
you
can
even
add
additional
encapsulations.
N
So
that's
those
are
possible
things
that
could
be
added,
but
we
think
this
draft
is
pretty
good
for
the
areas
it
covers
currently
and
it
would
be
a
reasonable
graph
to
be
adopted
by
the
working
group.
Working
group
can
decide
whether
it's
essential
or
not.
To
add
these
other
things
to
the
draft
over
coverage
which
could
be
done
after
adoption.
Perhaps
yep.
L
Porque,
no
then
Nokia,
yes,
lady
dress
looks
much
better
than
in
the
previous
version.
Thank
you,
so
I
yeah
I
think
I
support
it
for
working
up
adoption.
Do
you
the
thing
that
I'm
missing
is
the?
How
are
you
going
to
use
this
destructive?
Eft
is
the
intention
to
advertise
a
discriminator
or
Mac,
verse
or
interface?
You
can
even
advertise
one
per
MAC
address
if
you
want
it
missing
kind
of
the
use
cases
and
I
said
earlier
in
my
presentation.
L
N
N
L
Other
thing
I
was
wondering,
as
I
saw
in
that
section,
where
you
are
saying
how
you
are
distribute
the
discriminator
south
with
BGP.
You
took
up
about
the
Mac
I
IP
routes
for
unicast.
You
talked
about
English
multicast
route
for
MMP,
20-ton
oats
and
the
p20
is
TBD,
so
yeah
I
would
assume
it's
a
inclusive,
multicast
route
or
it's
been
around.
But
yes,
well,
okay,
I.
N
N
L
G
Bhushan
raman
Cisco
question
I,
just
read
the
draft
before
the
meeting
I
see
busy
dedicated
mark
question
for
Greg
to
the
VX,
the
VFD
VX
and
draft
there's
been
lots
of
changes
recently
and
lots
of
questions
regarding
the
need
of
a
dedicated
Mac.
So
that's
something
which
might
have
to
go
okay
and
the
other
question
mine
pls
forwarding
is
a
bit
stale,
there's
an
ACH
in
there,
but
there's
no
gals
of
that
part
also
wasn't
dear.
M
G
M
M
C
M
Do
agree
because
we're
not
defining
we
are
reflecting.
So
if
the
working
group
believes
that
it's
too
much
information,
it's
duplication
and
just
simple
reference
will
do
that
makes
sense
similar
with
their
MPLS
as
a
Rashaad
pointed
out.
Basically,
it
should
not
be
any
different
from
what
we
know
we're
using
the
gal.
M
A
C
N
O
O
How
do
we
use
PGP
to
handle
VPN
so
are
using
that
template
and
here
the
the
Colossus
and
now
go
to
the
detail
so
scenarios
on
Monday
actually
we're
discussing
the
RTG
working
group
about
network
to
cloud
different
scenarios,
and
here
we
actually
elaborate
much
more
than
what
being
discussing
the
RTG
working
group.
So
for
the
first
scenario
like
homogeneous
sd-1,
we
talked
about
like
a
shopping
mall
or
cloud
datacenter.
O
You
instantiate
virtual
CPE,
and
allow
traffic
to
be
encrypted
to
all
your
other
PS
or
actually
it's
like
remote
PE
connecting
to
all
the
VPN
PE.
So
that's
just
showing
that
all
the
traffic
from
there
can
be
encrypted
to
their
destinations,
not
showing
on
this
picture.
But
it's
describing
the
drug
I
encourage
people
to
read
it,
showing
that
the
remote,
a
node
in
the
cloud
could
need
to
connect
to
remote
nodes
through
the
VPN.
O
So
the
traffic
can
trim
passing
the
PE
and
also
that
for
the
remote
CPE
you
could
have
they
call
it
internet
local
drop
out,
meaning
some
of
the
traffic
don't
get
encrypted.
The
second
scenario
is
about
when
we
have
CPEs
in
different
locations,
including
cloud
locations
where
you
have
some
ports,
which
is
that
existing
ports
connecting
to
the
VPN
service
providers
and
some
other
ports
being
connected
to
the
Internet.
O
This
is
more
applicable
to
enterprise
themselves.
They
buy
service
from
VPN
service
provider
and
they
decide
to
adding
a
few
more
ports
to
interconnect
them
together
and
also
interconnect
you
clown
locations,
which
the
current
service
providers
don't
provide.
Connectivity's
to
the
same
scenario
is
about
today's
VPN
service
providers.
Actually
many
of
those
small
service
providers,
even
large
ones.
They
use
MPLS
to
interconnect
all
the
PE
s
and
they
do
have
internet
dropout,
local
branch
out
or
over
congested
routes
to
be
able
to
connect
all
the
PE
s
by
internet.
O
So
in
this
document
in
the
best
working
group,
we
focus
primarily
on
usage
requirement
like
in
order
to
achieve
this.
What
are
the
key
requirements
and
demonstrate
how
PGP
can
achieve
this
purpose?
The
the
key
requirement
is
that
three
parts
right
so
one
part,
is
very
important
for
the
zero
touch
provisioning
and
they
were
touch
provisioning,
meaning
you
have
a
box,
you
ship
it
to
your
customer.
They
power
it
up.
They
are
supposed
to
be
able
to
work
right
away.
O
So
normally
the
box
shipped
out
will
have
burned
address
to
your
central
controller,
which
is
not
the
robbery
flag
rot.
Reflector
we
talked
about
here
is
really
a
central
controller.
The
remote
device
reached
there
and
based
on
the
location
of
this
remote
device
and
the
controller
will
designate
a
local
network
control
for
this
particular
device
based
on
the
proximity
of
the
of
the
node
and
another
important
part
is
the
remote
device
they
may
have
attached.
Applications
need
to
reach
the
far
end,
and
but
they
don't
really
know.
Where
is
the
remote
device?
O
Remote
CPE
because
although
CPS
can
be
having
private
addresses
or
maybe
even
have
addresses,
not
reachable
by
IP,
they
may
have
a
identifier,
even
though
they
may
have
this
32
bits.
And
then,
if
I
similar
to
IP
address
is
not
routable
in
the
internet.
So
they
need
to
go
through
the
their
own
local
controller.
Be
able
to
establish
the
proper
channel
tunnel
or
channel
to
the
designated
peers
are
authorized
peers,
and
so
those
three
P's
can
be
geographically
in
different
locations
in
different
cities
and
different
countries.
O
Here
I
show
that
one
tenant
could
have
CP
1
CP
in
Dallas,
another
CP
in
Beijing,
and
they
have
their
own
local
controller
to
be
able
to
control
the
connection
between
them,
control
the
authentication
between
them
and
they
control
the
policy
between
them.
So
that's
a
very
important
part
and
the
reason
we
chose
BGP
is
because
why
deployment
of
BGP
and
very
minimum
learning
required,
and
also
all
the
mechanisms
supported
by
GP
GP,
that
incremental
update
all
those
already
inherited
there.
O
So
for
scenario,
one
in
a
document
talks
about
how
the
traffic
in
provision
the
example
walks
through
I
don't
have
time
to.
You
illustrate
those
details
in
the
high
level.
The
key
deployment
is
like
a
lot
of
law
office
into
office.
In
the
past
they
may
have
just
IP
accessible,
but
because
of
so
many
cloud
applications
and
they
need
interconnection
between
themselves
securely
to
their
cloud
applications.
O
There
may
also
seek
enterprises
which
they
already
have
campus
network,
and
now
suddenly
they
have
lots
of
workload
being
instantiated
in
different
locations,
different
bruh
clouds,
and
they
need
to
have
instant
connection,
and
the
key
thing
is
the
those
devices
can
be
ephemeral
different
from
our
CPE,
a
device
in
the
routing
domain
been
talking
for
decades.
We
have
a
CPE,
we
configure
them
and
they
are
working.
We
have
connection
to
them.
The
key
is
in
error.
Here
is
based
on
the
demand
based
on
the
application,
and
today
they
may
need.
O
Enterprise
may
need
their
workload
to
be
extension
in
Montreal,
and
there
may
be
a
month
later,
depending
on
their
user
Geographic
requirement.
They
may
need
to
instantiate
similar
application
in
say
Dallas
or
in
Brazil,
and
that's
why
st-1
come
into
the
picture
being
able
to
quickly
interconnect
those
workload
and,
more
importantly,
is
once
you
connect
to
the
remote
nodes
and
those
ramona's
may
need
to
talk
to
each
other,
so
communicate
with
each
other.
O
The
evpn
secure
VPN
as
a
draft
already
identified
for
different
grant
narrative
minority
of
the
IPSec
management
and
also
how
to
secure
those
evpn
when
the
PE
is
not
directly
connected
and
over
there.
They
have
detailed
the
scheme
on
how
to
manage
the
key
mechanism
using
bgp
Emma
appears
for
the
second
scenarios,
so
it's
becoming
Motty
players.
It's
not
just
enterprise
and
network
service
providers
now
we're
introducing
enterprises,
their
network
service
providers
and
cloud
providers.
In
this
example,
it
shows
that
my
remote
router
is
instantiate
in
the
in
the
cloud
datacenter
right.
O
So
in
a
cloud
datacenter,
normally
mostly
cloud
operators
allow
multiple
access.
You
can
have
IPSec
access.
You
can
have
the
rat
connection
access
so
as
a
virtual
router
themself.
They
have
different
access
and
different
connections
and
they
will
have
be
able
to
get
information
on
the
performance
of
each
network
and
make
local
decisions,
whether
certain
traffic
can
go
through
the
IPSec
tunnel
to
the
destinations
or
they
can
go
through.
The
and
parents
network
natively.
Without
encryption.
O
Encryption
itself
is
very
processing,
expensive
and
the
volume
cannot
be
huge
so
still
to
most
enterprises.
It
preferable
to
use
most
of
the
secure
translate
transport
using
them,
their
direct
connect
and
MPLS
network
only
for
the
one
that
other
networks
congested
or
when
some
traffic
are
not
important.
They
can
go
through
the
internet
and
in
this
example,
I
didn't
show
that
you
could
have
multiple
virtual
routers
in
different
cloud
data
centers
how
they
are
connected
with
each
other.
O
Yes,
the
many
cloud
operators
offer
connectivity
among
themselves,
but
many
enterprises
still
want
to
see
the
being
visible
to
see
how
they
are
connected.
They
may
halt
backhaul
they're,
helping
the
traffic
all
the
way
back
to
their
customer
gateway
and
using
a
customer
gateway
to
interconnect
the
traffic
between
different
cloud
data.
Centers,
as
shown
in
this
example,
we
have
data
center.
One
data
center
to
the
BGP
route
reflected
here
is
running
in
different
areas,
different
instance
from
the
underlay
Network.
O
O
There's
overflow,
there
you
add
the
Internet
ports
so
that
you
can
utilize
the
Internet
and
the
key
things
here
is
actually
the
security,
because
in
the
past
the
peas
are
interconnected
by
the
underlay
network
and
is
secure
and
this
within
the
administrative
domain
of
the
operators.
And
now
suddenly
you
open
an
Internet
Court.
All
kinds
of
threats
could
coming,
even
though
you
make
we
get
a
request
from
certain
provider
and
certain
notes
and
the
colleague
spoofing
they
could
be
DDoS
all
kinds
of
tech
or
come
see.
O
Another
key
requirement
we
demonstrate
in
the
in
a
draft
is
talking
about
site
based
forwarding,
meaning
that
for
certain
applications
they
may
have
application
money
in
different
sites
and
it's
very
important
for
the
routes
to
reach
certain
size.
This
really
the
policy
like
you
may
reach
certain
sites
that
one
each
note
is
fine,
but
in
in
some
other
application
you
can
now
reach
certain
sites
so
for
the
BGP
route,
distribution
and
the
port
distribution
site
has
to
be
included
in
one
of
the
attributes.
O
So,
in
a
in
a
draft
talk
some
more
examples
like
for
scenario,
one
how
the
device
being
powered
up,
how
the
client
routes
being
distributed
to
other
nodes,
which
is
very
similar
to
a
VPN
and
there's
also
inform
scenario
number
two
that
how
the
one
ports
need
to
be
registered
with
the
controller.
Here
in
the
best
working
group,
we
don't
talk
about
how
those
encoding
are
down.
O
We
are
only
focusing
on
the
actual
content
need
to
be
registered
and
in
the
idea,
working
group,
we
had
a
drug
talking
about
encoding
by
yesterday
that
she
asked
us
not
to
get
your
details
to
the
encoding,
because
that
many
different
ways
to
skin
a
cat
and
idea
Cheers
want
us
to
focus
on
the
detailed
requirement.
The
substance
of
content
to
be
forwarded
between
the
rail,
reflector
and
device
and
then
later
are.
O
So
here,
just
the
summary
of
the
control
plan,
the
components
for
the
component
itself.
They
need
to
the
end
notes
when
powered
up
may
not
even
have
a
IP
address
and
maybe
have
a
burning
ID
and
which
is
not
routable
and
the
ports
connecting
to
ISPs,
they
may
get
assigned
IP
address,
then
some
of
the
ports
may
have
assigned
DHCP,
dynamic,
IP
address
or
private
address.
So
it
is
important
for
the
1
port
addresses
to
be
reported
to
the
rail
reflector.
O
If
CP
you
wanna
need
to
talk
to
CP
2
and
CP
3
the
if
they
are
also
right
to
communicate
with
each
other,
those
one
port
addresses
and
how
the
private
how
the
net
has
to
be
propagated
to
the
remote
site.
Just
like
ATM
days,
they
have
this
NH
RP
for
the
address
resolution.
The
local
address
to
the
one
address
resolution.
Similar
things
has
to
be
done
here
and.
O
K
O
P
P
Should
brief
overview,
it
was
was
the
only
person
today
that
right,
if
99,
so
what
is
this
all
about?
So
this
draft
defense
procedure
to
do
seamless,
interpret
wean
EVP
in
and
MIT
networks
and
the
same
procedure
can
also
be
used
to
do
optimize
to
intercept
at
forwarding
with
an
EVP
in
fabrics.
We
have
very
good
support
from
industry,
and
this
is
a
revision,
for
there
are
some
comments
on
loosen
three
which
we
have
addressed
here.
P
So
these
are
main
comments.
One
s.
The
proposal
doesn't
provide
to
Ethernet
emulation
for
intercepted
traffic
because
we
always
use
routing
approach
between
two
different
ease.
So
even
interest
of
the
topic
will
also
get
routed.
Then
second
committees-
we
don't
this
graph-
doesn't
cover
eevee,
eevee
pian
and
the
MEP
and
Gateway
model.
P
So
if
you
look
at
the
module
draft,
what
we
proposed,
so
the
solution
is
really
meant
for
evpn
and
a
VPN
being
on
the
same
fabrics,
but
you
can
also
connect
a
million
networks
to
subset
of
EVP
in
fabrics
that
is
not
covered,
so
that
phone
of
the
comment
and
third
comment
is,
you
know:
are
the
configuration
needed
a
new
in
peace,
so
in
Division
four,
we
are
a
new
section
which
talks
about.
You
know
how
to
take
care
of
tickle
problems.
P
P
We
will
decide
the
leftover
out
or
bridge
on
the
outgoing
interface
regarding
MEP
need
a
ve.
We
can
get
your
model
CBR,
a
new
section
which
talks
about
get
a
model,
and
there
are
two
scenarios
where
to
get
a
model
can
be
used.
One
is,
if
you
use
two
different
tunnel
between
MEP
and
evpn
a
P.
Then
we
have
Q's
get
a
model,
so
other
thing
is:
if
you,
if
a
medium
P
is,
are
connected
to
subset
of
EB
thin
piece
that
time
also,
we
can
just
use,
get
a
model.
P
So
for
our
P
configuration
we
are
at
more
collaterally,
so
we
are
as
section
which
talks
about
very
sarpy
configuration
use
cases,
and
we
also
clarified
that
in
unit
in
fabrics
we
don't
have
to
explicitly
configure
out
the
configuration.
There
are
some
other
minor
changes
that
we
just
made
say.
One
of
a
command
which
talks
about
in
optimum
forwarding
can
only
only
be
done
if
you
use
the
same
tunnel
type
so
that
we
just
are
no
updated
and
two
new
one
that
we
have
added
to.
P
You
know
for
the
completeness
purposes,
and
there
were
some
comment
that
was
made
that
even
eveything
only
fabrics
venereal
treaty
in
conjugation,
so
we
clarify
that
that's
not
needed,
then
again
hosted
advertisement
or
a
kid
for
MEP
in
peace.
That's
only
when
MEP
is
part
of
youth
in
fabrics
not
for
the
get
your
model
that
also
be
clarified
next
steps.
So
this
has
been
our
for
three
years
and
we
have
two
different
implementation
and
again
it's
all.
In
production
we
have
50
plus
deployments
a
Turkish
team.
E
R
Alright,
so
talk
about
looting
of
background
and
the
problem
statement,
and
then,
let's
see
what
the
proposals
are.
Okay,
so
yes,
our
v6
+,
Ron
Monica
has
presented
in
couple
of
working
groups,
and
this
is
just
a
very
short
primer
on
what
is
relevant
for
this
particular
draft.
Sr
v6
+
provides
a
unidirectional
connectivity
between
two
nodes.
It
introduces
programmable
instructions.
R
The
draft
talks
about
there
is
a
segment
instruction.
There
is
a
path
instruction
and
it
relies
exclusively
on
ipv6
data,
plain
talk
about
bgp,
bgp,
VPN
services
or
on
multiple
different.
Various
types
of
tunnels
could
be
MPLS,
IP,
GRE
and
that
so,
let's
look
at
the
simple
VPN
topology,
as
shown
in
the
diagram
here.
Sr
v,
6
plus
underlay,
relies
on
the
PPS
I
the
poor
path
segment
instruction.
R
What
it
does
is
at
the
piece
the
P
is
P
1
and
P
2.
They
allocate
the
P
psi,
and
that
is
what
that
is
used
for
identifying,
which
particular
connect
seee,
that
you
need
to
send
it
to
P.
Psi
is
embedded
in
the
destination,
opsin
options,
header
and
ipv6
Tunnel
and
pier
routers
or
P
or
ipv6
capable,
and
they
are
not
P
psi
cable.
R
R
So
we
have
the
mechanism
already
in
the
tunnel.
Encapsulation
attribute
Divine's.
What
sort
of
tunnels
you
can
have
between
the
two
PE
routers,
so
we're
gonna
leverage
that
a
survey
6
plus
path
is
considered
as
a
tunnel,
and
we
are
gonna
request
for
a
service,
Express
tunnel
type
and
that
sub
tlvs,
as
defined
in
the
talent
captivation
a
document
whether
this
terminal,
endpoint
or
protocol
type
or
the
color
can
be
used.
R
Some
coding
encoding
examples
have
only
taken
to
the
office
of
a1
128,
as
well
as
the
EDR
out
on
the
a
VPN
side.
You
can
clearly
see
that
all
others
are
maintained,
except
when
it
comes
to
the
label
field.
You
embed
the
PPS,
identify
you
and,
along
with
that,
you,
you
will
be
sending
that
unlink
cancellation
path,
attribute
where
you
say
the
SPV
is
a
v6.
R
And
the
proposal
on
the
various
bgp
procedures
on
the
ekeus
PE,
the
PPS
things
are
soldered
with
the
forwarding
table
and
that
is
useful.
D
mixing
in
the
dáil,
plane
and
P
psi
is
encoded
as
embedded
label
like
we
talked
about
and
the
tow
line
condition
attribute
is
advertised
with
that.
Nl
RI
and
the
ingress
PE
PPSA
is
constructed
with
the
embedded
label.
That
is
three
bytes
and
appending
the
the
top
border
byte
0,
that's
the
p
PSI
that
is
used
in
the
dissipation
options,
header
that
the
wrong
bond
occurs.
R
Draft
talks
about,
and
this
topple
the
PPS
identifier
and
the
prefix
is
what
there
is
programmed
in
the
s5.
The
segments
forwarding
table
now
when
the
in
the
actual
data
plane
in
the
destination
options
centre
of
the
tunnel
after
tunnel
header,
the
ingress
PE
inserts
the
p
PSI
in
the
destination
of
some
header,
the
P
routers
do
not
process
it,
because
this
is
the
destination
of
consider
in
the
last
header.
R
L
E
L
L
Next
comment
is
that
there's
a
section
that
you
say
that
a
label
is
downstream
allocated
except
for
p2
MP.
In
that
case
you
its
upstream
allocated
there
is
no
key
to
empty
in
here
right
and
there's
four
EVP
and
there's
no
point
of
multi-point
0.0.
So
you
should
remove
that
part
of
the
that
section
sure
and
finally,
well,
you
you
are
asking
for
a
working
group
adoption,
but
I
think
there
is
still
a
lot
to
to
go
till
that
point.
L
S
S
R
S
E
Okay,
I
fully
agree
with
what
Horace
said.
It's
clearly
too
too
early
to
add
a
document
or
even
to
do
an
abduction
call,
because
we
need
to
agree
at
the
IETF
level,
especially
in
spring
Eve
service
expressed
concept
that
you
are
trying
to
push
is
something
that
we
want
in
spring
and
if
it
is
accepted,
of
course,
this
is
a
world
that.