►
From YouTube: IETF108-BESS-20200728-1100
Description
BESS meeting session at IETF108
2020/07/28 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
Okay
for
the
note
taking
there's
actually
a
link
in
me
taco
to
a
new
tool
for
for
note
taking,
but
you
can
use
etherpad
as
well,
but
we
have
anchorman,
also
who's
our
secretary
who's
going
to
be
taking
notes
during
the
session.
So
thanks
to
mana.
A
A
Please
stick
to
your
slots
as,
as
I
said,
we
have
a
very
tight
agenda
and
me
tekko
has
has
a
habit
of
just
kicking
us
kicking
us
after
the
meeting
five
minutes
after
the
time,
without
very
much
warning.
A
So
onto
the
status
subject
update
we
have
no
new
rfcs
since
the
last
ietf
we
have
two
in
the
rfc
editor's
queue:
the
overlay
draft,
ebp
overlay,
dci
draft
and
evpn
prefix
advertisement.
A
There
are
a
couple
of
questions
I
think
for
ali
to
address
for
the
inter-subnet
forwarding
draft
na
flags,
optimized
ir
and
the
proxy
arp
noble
discovery
draft
are
all
in
iesg
review.
Bgp
control
plane
for
nsh
is
in
ice
g
review,
the
really
old
voltage
vps
multi-homing
draft.
It's
been
working
with
very
long
time.
It's
with
martin.
At
the
moment
there
was
one
ipr
hiccup
that
had
to
be
addressed.
B
A
Think
that's
been
addressed
now
I
I
did
post.
There
was
a
late
ipr
declaration
on
that
I
did
post
something
to
the
list
on
that
we
didn't
see
any
comments.
A
The
one
procedure
updates
is
with
the
isg,
as
is
the
rfc
5549
revision,
and
we
have
just
sent
the
publication
request
for
the
next
couple
of
few
weeks
for
the
evpn
oem
framework.
So
that's
with
hopefully
with
martin
now.
A
Quite
a
few
documents
in
shepherd's
review
as
well,
so
the
iob
multicast
document.
My
commander
is
reviewing
this
at
the
moment.
He
expects
to
finish
it
in
the
next
few
weeks.
A
A
Write-Up's
completed
for
the
mvpn
msdpsa
interoperation
draft
evap
evpn
preference
default
florida.
Stefan
is
following
that
up
at
the
moment
and
mancumana
is
currently
updating
the
igmp
mldp
proxy
document,
which
is
expected
to
have
done
in
the
first
week
of
august.
A
D
A
Okay,
the
evpn
lsp
king
draft
was
in
working
group
last
call
there's
a
few
comments
on
that
and
also
comment
from
one
of
the
mpls
working
group
chairs.
A
If
the
authors
could
please
address
those
comments
before
we
move
that
forward,
that
would
be
appreciated
and
the
evpn
geneve
draft
there's
a
few
comments
on
the
list
as
well.
That
need
to
be
addressed
by
the
author
before
moving.
A
Forward:
here's
the
list
of
the
ones
that
we
have
in
our
queue
for
as
being
ready
for
working
group
glass,
call
the
aggregation,
evpn
aggregation
label
document,
ivpn,
interworking
and
irb
extended
mobility.
A
Now
some
status
on
some
of
the
working
group
documents,
the
multicast
flow
df
election
mankind-
is
updating
this.
Since
ignp
proxy
draft
is
now
advanced.
There's
no
update
to
the
fast
df
recovery.
A
No
updates
to
a
few
of
the
drafts
listed
on
this
side
as
well.
There
are
some
questions
to
the
authors
for
the
mvp
and
yang
draft.
We've
received
a
response
from
them
yet
stephanie,
I
don't
know
if
you
want
to
say
anything
about
the
young
drafts.
D
A
Okay,
one
new
working
group
document,
which
was
draft
gm
sm,
best
evp
and
bfd.
A
Okay,
we
also
have
a
list
of
documents
that
we're
going
to
poll,
we
believe,
are
ready
for
working
adoption.
Are
we
going
to
poll
shortly
in
this
order?
The
vpn
l2
gateway
protocol,
split,
evp
and
multimedia
horizon,
and
the
yang
model
for
vpn
service
pm.
A
E
F
Hi
everyone
good
morning
afternoon,
depending
where
you
are
so
as
this
is
the
srv6
based
pgp
services
draft
next
slide.
Please.
F
So
this
draft
specifically
covers
the
extensions
for
l3vpn
for
v4v6
evpn,
and
also
for
the
global
v4
and
v6
services.
F
F
F
F
F
Next
slide,
please
allocation
has
been
made
for
the
city,
lv
type,
the
l3
services
tlv,
and
also
for
that
ultra
services
tlv,
and
these
are
used
in
the
field
deployed
implementations
in
various
customers.
F
Now,
in
terms
of
implementation
and
also
from
the
deployment
it's
it's
widely
deployed,
it's
widely
implemented.
We
have
shipping
versions
and
pretty
stable
versions
coming
out
from
two
vendors,
cisco,
huawei
and
other
vendors.
F
We
also
have
open
source
implementations
of
the
protocol
in
extra
bgp
and
the
go
version
of
the
bgp
and
also
being
leveraged
in
the
data
planes,
linux
and
fdio.
In
terms
of
the
deployment
the
it's
it's
deployed
in
multiple
customers
at
softbank,
china
telecom
illiad
line,
corp
china,
unicorn
md
in
uganda.
F
The
full
implementation
list
can
be
found
in
the
document
below,
but
it's
it's
widely
deployed
and
used
in
the
field
and
also
the
multi-vendor
interop
was
presented
at
entc
since
2018.
F
Next,
we
as
an
author
is,
we
believe
the
draft
is
in
pretty
much
your
state
now
with
multiple
external
existing
implementations
from
various
vendors
and
also
the
deployment
list.
As
someone
mentioned
I
mentioned
with
the
customers,
so
we
would
like
to
request
the
last
call
for
this.
A
A
Good,
okay,
sherman,
I
can
see
you
hello,
can.
G
You
hear
me
yeah,
okay,
jimmy
from
huawei,
since
this
is
the
srv6.
The
king
are
very
important
and
I
have
deployed.
I
have
multiple
deployments,
so
we
think
that
the
draft
has
also
well
written.
So
I
think
I'm
not
sure
how.
How
can
we
show
this
the
we
want
the
request
for
the
working
group
last
call.
So
is
it
okay
in
this
meeting.
A
Or
in
many
least
yes,
if
you
believe
it's
if
you
believe
this
is
mature,
then
certainly
make
the
requests
in
this
meeting
and
we
can
look
adding
to
putting
it
onto
our
list.
A
Okay,
as
it
states
on
the
side,
so,
okay,
okay,
sue,
I
think
you're.
H
A
So
actually
this
this
brings
a
a
good
point.
So
we've
had
a
few
issues
in
best
recently
where
we've
got
kind
of
getting
references
between
drafts.
So
if
authors
could
please
make
sure
that
all
of
their
references
are
in
line
ideally
well,
that
would
be
the
ideal
case
before
you
request
working
group
last
call.
Obviously
it's
part
of
our
job
as
shepherds
as
well
to
check
that
that
that
is
in
place.
I
Stefan
that
reference
was
a
leftover
in
error,
so
I
think
dot
should
remove
that
and
to
answer
sue's
question.
This
document
doesn't
have
any
dependencies
on
any
document
in
idr.
They
are,
you
know
unrelated.
I
F
H
I've
I've
I've
got
one
if,
if
I'm
on
you're
on
okay,
the
question
was
not
whether
there
were
dependencies,
I
assumed
you'd
get
dependencies.
If
you
had
other
things
that
enabled
the
deployments
that
we
should
push
along
an
idr
that
we're
not
just
let
me
know
that
was.
That
was
the
real
request.
Thanks.
F
I
will
drop
off
in
that
case.
This
is
done.
A
A
J
Okay,
can
you
hear
me
now
yeah?
Okay,
so
I
want
to
provide
an
update
on
the
two
graphs.
One
is
vb
multicast,
otherwise
you
might
have
controller
next
side.
Please.
J
So
the
pg
multicast
draft
is
about
using
btp
to
do
hard
by
hub
signaling,
basically
as
a
replacement
for
pim
and
the
mldp.
So
the
there
are
basically
two
major
changes.
J
Well,
it's
not
that
major
either
the
first
one
is
we
added
a
raw
distinguisher
to
the
nrri
that
way
we
can
do
signaling
in
the
vr
apps.
This
is
mainly
to
support
signaling
from
controllers,
but
since
the
nri
is
defined
in
this
document,
so
we
we
updated
this
document
for
what
about
the
rd?
J
The
next
one
is
inter-region
support.
Here
the
region
could
be
a
area
or
it
could
be
a
as
there.
There
are
three
sub
topics
about
this.
One
is
that's
bgp
signaling
through
a
region,
especially
when,
when
you
are
using
the
bgplu
such
that
the
internal
routers
in
a
region
do
not
have
the
routes
towards
the
source
or
towards
the
tunnel
route.
In
that
case,
how
does
the
internal
routers
do
the
rpf
check
towards
the
root
of
the
source?
This?
J
This
is
a
a
solved
problem
for
pim
and
mldp,
using
pin
rpf
vector
or
mld
recursive
effect.
The
same
idea
will
be
applied
to
here.
We
basically
add
rpf
extended
community
to
specify
the
upstream
border
router,
to
which
you
should
be
doing
rpf
against
the
next
one
is
the
overlay
signature
over
and
region.
This
is
very
much
like
the
mldp
over
or
targeted
session.
Where
you
have
you
have
a
region.
J
That's
you
do
not
run
on
pcb
signaling
towards
the
to
the
internal
routers,
but
you
just
do
the
pgp
signaling
over
that
region
to
the
border
routers.
But
when
it
comes
to
how
to
get
through
that
region,
then
you
can
use
either
p2p
tunnel
from
border
router
towards
a
quarter
router
or
you
can
do
p2mp
tunnel
inside
that
region
and
you
stack
the
traffic
on
top
of
that
p20
tunnel
again.
This
is
just
like
mldg
over
a
targeted
session
and
finally
interworking
with
controllers
signal
broadcast.
J
So
in
this,
in
the
inter-region
scenario,
it
could
be
that
it
spans
multiple
regions
and
where
you
have
a
hardware
hub
signal
in
your
wind
region,
and
you
have
controller
signaling
and
another
region
and
yeah
you
have
another
controller
for
different
region,
so
how
the
interworking
is
done
together.
So
that's
next
slide.
J
And
then
for
the
controller
signal
pgp
multicast
scraps,
there
are
three
changes
in
this.
One
is
that
tunnel
encapsulation
attribute
enhancements.
The
other
one
is
also
multi-multi-domain
support
and
we
also
added
the
srp20
support
next
next
slide.
Please.
J
So
panel
enhancement
encapsulation
attribute
enhancements.
So
when
we
talk
about
the
markers
forwarding,
there
is
this
with
reporting.
There
were
includes
upstream
information
and
downstream
information.
So
now
the
upstream
information
is
actually
included
in
the
tunneling
transformation
attribute
itself
so
before.
J
J
The
next
change
is
the
incoming
labor
stack.
This
is
what
this
was
introduced
for
mpa
to
mp
support.
J
You
have
that,
for
example,
when
you
have
a
multiple
intermolecular
mldp
and
then
for
for
each
neighbor,
whether
it's
upstream,
labor
or
downstream
labor,
you
may
send
traffic
to
it
and
you
may
also
be
receiving
traffic
performance,
and
so
currently
the
labor
stack,
tlv
subtitle
in
for
mpos
tunnel
is
for
outgoing
traffic
and
for
incoming
traffic.
We
added
this
new
incoming
label
stack
just
sub
tlb,
all
right.
J
It's
the
same
as
the
existing
label
stack
tier
sub
tray,
except
that
it's
a
new
type
so
for
mp2mp
atana
will
have
both
the
incoming
label
stack
and
the
regular
label
stack
and
then
even
for
p2
mpks,
the
for
the
upstream
tunnel.
Then
it
will
have
an
income
enabled
stack
instead
of
a
regular
label
stack,
but
then
for
the
other
downstream
tunnels,
then
for
p2mp,
then
you
will
only
have
a
regular
labor
stack
for
outgoing
traffic.
J
So
much
domain
support
you
consider.
The
situations
where
you
have
multicast
trio
tunnel
spends
multiple
domains,
multiple
regions
where
different
domains
have
different
controllers.
Oh,
I
realized
that
in
the
earlier
when
we
talked
about
multicast
straps,
I
was
using
the
term
region
and
here
in
the
controller
drive
that
switched
to
domain,
and
that's
a
mistake
on
my
site
here.
When
you
see
domain
origin,
it
is
the
same.
I
will
update
this
the
drafts
to
be
consistent.
J
So
here
you
have
a
controller
one
for
the
region
on
the
left
and
the
controller
two
for
the
region
on
the
on
the
right.
J
Now,
the
router,
a
and
b
in
the
in
region,
one
or
domain
one
router
c
and
d
in
the
other
region,
now
notice
that
the
controllers
only
control
the
the
routers
in
its
own
region
and
now
for
native
ip
multicast.
It
is
simple:
if
the
only
control
controller,
one
only
needs
to
say
that
router
b
needs
to
replicate
to
this
downstream
interface
and
the
controller
2
will
only
need
to
tell
roger
c
that's
your
option.
Interface.
J
J
Is
that
somehow
the
controller
one
computer
to
the
coordinates
so
that
they
know
that's
well
able
to
use
on
that
inter
origin
interval
main
link,
the
other
one
is
that
they
don't
coordinate,
but
you
do
the
hard
by
half
signaling
between
the
router
c
and
router
b,
so
rather
c
tells
rather
b
that
hey,
I'm
I'm.
J
I
I'm
joining
your
tree,
and
here
is
my
label
to
use
things
like
that,
so
that
the
next
situation
is
that
the
there
is
the
border
router
b
that
sits
on
both
domains
and
now
the
controller
y
and
controller
2.
J
Both
talk
to
router
b-
and
we
had
talked
said
before
that
with
the
router
b-
receives
the
liquid
routes
from
both
controllers.
J
The
bhp
rough
selection
procedure
will
pick
one
of
them
and
and
and
that
is
used
to
pro-
to
set
up
recording
stage,
and
now
the
router
b
actually
needs
the
information
from
controller
one
to
set
up
the
upstream
information
and
is
the
route
from
controller
two
to
set
up
downstream
information.
So
in
this
case
rather
b
is
provisioned
as
a
border
router,
so
that
so
it
can.
J
J
Please,
okay,
srp20
supports
srp10p,
has
been
accepted
by
the
sprint
and
pim
working
groups
in
the
spring
working
group
is
about
replication
segments,
which
is
a
building
block.
It's
red.
J
J
J
Why
is
btp
srt
based
and
the
other
one
is
bgpm
class
based
bgbm
cast
is
basically
this
draft
hard
drive
here,
b2b
broadcast
controller,
as
people
say,
those
are
the
different
ways
to
seeking
a
cat,
and
here
the
cat
is
the
srp
to
impeach
you
and
now
notice
that
with
bgpmcast,
all
we
need
is
a
new
nri
type
to
do
the
srp20p,
so
this
is
the
same
way
existing
way
to
skin
a
different
cat.
A
different
cat
here
means
the
srp20p
instead
of
ip
multicast,
3
or
mrdp
tunnel.
J
Next
up
next
slide,
please
so
the
replication
segments
is
identified
by
root
id
tree
id
and
node
id.
The
node
id
is
basis,
says
that
which
node
this
replication
segment
is
for.
You
can
see
that
in
this
nri
I
have
three
red
fields.
That's
basically
how
I
is
identified.
J
J
J
So
what
is
our
sr
sr
policy
tunnel?
Originally
it's
defined
to
to
instantiate
the
srp2b
policy.
Now
here
the
sr
policy
tunnel
is
a
tile
type
in
the
title,
encapsulation
attributes.
So
that
part
that
tunnel
specifies
the
binding
state
and
outgoing
seedlings
for
the
srp2p
policy
among
other
things,
but
when
we
use
that
sr
policy
in
the
tunnel
encapsulation
attribute
for
srp20p,
it
basically
is
refers
to
a
pre-installed
srp2p
policy.
As
a
replication
branch.
You
see
it
basically
says
you
have
downstream
node
and
you
can
use
srp.
J
This
is
our
p2p
policy
to
reshoot.
Now
how?
How
does
it
work
in
that
sr
policy
tunnel?
You
specify
a
binding
sheet
and
when
the
node,
when
the
node
gets
it
you
the
signaling,
then
he
used
the
binding
seat
to
look
up
the
pre-installed
outgoing
seat
list
and
that
tunnel
also
has
a
seat
list.
It's
just
one
series
that
basically
specifies
the
argument
sheet
for
the
tree.
Now
you
put
this
together
two
together,
you
have
a
seedless
that
you
use
to
send
the
traffic
to
downstream
next
slide.
J
Sure
next
slide,
please
srpw
policy
is
under
on
the
treehead
and
that
can
be
actually
signaled
using
the
replication
segment
itself.
We
just
attached
a
new
attributes,
a
big
community
container,
to
to
specify
the
information
for
the
for
their
peer
policy,
including
the
candidate
past
priority
and
set
of
leaves
and
policy
names.
Things
like
that.
Next,
please.
J
So
summary,
this
draft
for
b2b
multicast
and
with
his
republic
hub
signal
control,
signaling,
it's
getting
more
and
more
mature
in
both
the
draft
work
and
up
proof
of
concept
implementation.
J
I
do
need
to
spell
out
more
precise
procedures,
but
it's
just
exactly
how
what
you
kind
of
route
you
are
originated,
what
kind
of
things
you
do
in
the
receiver
route,
but
other
than
that?
It's
pretty
much
there,
the
concept
and
then
and
how
you
implement
it.
So
I
will
present
to
the
idr
working
group
on
the
proposed
tea
changes,
but
we
do
have
more
work
to
do
to
spell
out
the
precise
procedures
I'm
done.
H
Yes,
I
look
forward
to
hearing
the
te
changes.
I
wondered
if
he
had
a
two-line
sentence
that
can
tell
me
what
he's
looking
for
there.
J
Oh,
I
talked
about
some
ta
changes
in
this
slide
already,
but
in
the
idr
presentation
it's
more
systematic.
I
I
have
sent
the
slides
to
the
idr
and
once
they
publish
you
will
see
it
and
then
in.
A
You
thank
you
all
right.
Next
up
is
shabba.
K
You
hear
me
yes,
so
yes,
I'm
presenting
this
draft
on
behalf
of
the
other
authors.
It
is
about
mvpn
and
evpn
services
over
sr
p2p
trees
that
jeffrey
just
presented
next
slide.
K
K
K
So
I
think,
as
jeffrey
mentioned,
we
have
basically
a
srp2mp
consists
of
two
building
blocks.
One
is
what
we
call
as
a
replication
segment,
which
is
the
foundational
construct
for
providing
a
p2mp
replication
in
sr
segment,
and
then
we
have
srp2mp
policy
which
builds
on
top
of
that
and
allows
a
pc
to
compute
a
tree
and
then
instantiate
as
a
tree
in
sr
domain
by
by
stitching
these
replication
segments
together.
K
So
these
two
are
covered
in
in
the
drafts
that
I
mentioned
over
here
in
the
spring
and
and
the
pim
working
groups,
and
recently
both
of
these
drafts
have
been
adopted
by
the
respective
working
groups.
K
So
in
in
this
graph,
we
basically
specifying
how
mvpn
and
uvpn
procedures
are
modified
to
to
support
such
services
over
the
srp
termitry
right.
K
So
the
basic,
the
the
basic
approach
is
that
a
root
of
a
p2mp
service
discovers
the
endpoints
using
the
auto
discovery
routes,
and
then
it
communicates
with
the
pc
to
create
and
update
a
srp-20
policy
with
this
endpoint
that
endpoint
set,
that
is
discovered,
and
then
the
pc
can
compute
a
srp
to
mp3
and
instantiate
the
tree
in
sr
domain.
Using
any
southbound
protocols
like
p7.conf
or
bgp,
all
right,
so
the
the
in
this
draft,
the
real
standardization
effort,
is
just
defining
a
new
pimzi
tunnel
attribute
for
srp2p
tunnel.
K
K
Next
slide,
so
at
this
moment
we
are
just
seeking
comments
from
the
working
group.
This
draft
has,
as
I
said,
this
draft
has
been
published
for
well
over
a
year
now
and,
and
it
is
supported
by
by
different
vendors.
So
we
just
want
a
working
group
to
go
and
provide
comments
on
the
job
any.
A
Thank
you
folks,
please
step
up
to
the
queue.
If
you
would
like
to
make
any
comments.
A
C
C
Okay,
I'll
talk
louder,
so
this
is
the
update
for
the
bgp
usage
for
sd1.
The
main
purpose
of
this
draft
is
to
tell
the
industry.
There
are
quite
a
few
other
organizations
during
sd1
and
we
want
to
show
that
btp
actually
is
very
well
equipped
to
do
the
control
plan
for
the
overlay
network
next
page.
Please.
C
Okay,
so
this
is
just
helping
people
to
understand.
The
draft
here
are
the
main
thing
being
discussed
in
the
draft.
We
have
requirements,
we
have
three
scenarios
and
we
use
the
bgp
the
control
plan.
How
do
we
walk
through
how
the
bgp
control
plan
works
for
each
of
the
scenarios,
and
then
we
describe
the
traffic
flow,
how
the
traffic
goes
from
one
side
to
another
side
for
each
of
the
scenarios?
C
So
this
one,
the
we
described
the
key
characteristics
of
the
sd1
networks,
mainly
their
argument
of
the
transport
instead
of
using
vpn,
or
this
one
can
use
different
type
of
overlay
and
actually
can
aggregate
traffic
from
multiple
overlay,
multiple
underlying
networks
and
another
one
we
added
to
in
this
draft
is
application.
Routing
application
based
routing
can
be
based
on
application
id.
It
can
also
be
based
on
specific
performance
of
the
network.
C
So
for
the
sd1
segmentation,
which
is
highly
desired
by
many
deployment,
there
are
two
aspects:
one
is
the
control
plan
to
be
able
to
using
being
able
to
represent
control
messages
by
different
different
instances
or
segments.
C
This
is
actually
sd1
overlay
target
id
all
the
instances
and
then,
from
data
plane
perspective,
the
data
traffic
themselves
need
to
carry
the
sd1
id
and
for
the
vpn
existing
vpn,
there
are
already
methods
to
carry
the
differentiators
and
for
the
ipsec
vpn,
the
virtual
network
id
can
be
carried,
can
be
carried
by
the
the
the
encoding,
whether
it's
gie
or
vxlan,
which
is
in
cap
inner
encapsulation
of
the
ipsec
esp
tunnel,
so
both
can
be
covered
by
the
vgp
can
be
achieved
by
bgp
next
next
slide.
Please.
C
Okay,
so
this
is
just
to
show
that
why
bgp
is
used,
bgp
itself
has
the
ability
to
control
the
constraint.
The
distribution,
one
of
the
characteristics
of
sd1
is
the
edge
divide.
Edge
nodes
are
very
far
apart
from
each
other
and
some
of
the
notes.
One
power
up,
don't
even
know
who
his
authorized
peers
are,
so
they
require
using
like,
for
example,
ifc
484684
to
be
able
to
constrain
the
distribution
of
the
propagation,
and
there
could
be
also
policies
being
enforced
so
that
only
authorized
peers
can
receive
the
update
next
page.
Please.
B
C
Okay,
so
here
is
through
the
drive
itself,
showing
how
do
we,
the
bgp's
message
flow,
so
this
just
shows
example
of
when
a
cpe
or
edge
node
has
a
bunch
of
client
routes
and
a
being
propagated
through
the
con
through
the
rr
to
the
authorized
peers.
C
So
with
this
kind
of
method
that
can
simplify
the
ipsec
attribute
distrib
distribution,
because
here
in
this
picture,
which
we
assume
that
there
is
a
already
secure
channel
between
the
rr
and
the
edge
nodes,
so
that
can
ease
the
authorization
of
the
message
of
the
ikey
v2.
C
C
This
one
shows
that
for
the
st1
they
may
have
different
topologies,
like,
for
example,
here
in
this
example,
the
vlan
25
and
the
route
22
dot.
Slash
24
need
to
be
only
exchanged
with
cpe
3
versus
vlan
15,
only
being
communicated
with
cpu
one.
So
with
that
using
two
separate
bgp
messages
with
different
target
can
achieve
this
purpose.
C
So
this
one
to
show
that
if
the
client
prefer
to
have
a
client
address
based
encryption
per
route
based
and
they
can
use
different
bgp
messages
to
be
able
to
indicate
like,
for
example,
10.1
using
specific
ipsec
attributes
and
vlan
15
used
another
set
of
ipsec
and
sa
security
association
attributes
and
then
the
last
one
being
the
12.1
using
another
new
set
of
ipsec
security
association
attributes.
With
this,
the
different
client
routes
being
encapsulated
by
different
ipsec
essay
attributes.
C
This
one
is
showing
how
use
btp
to
to
control
the
second
scenario,
which
is
to
show
that
the
client
routes
can
be
carried
by
either
the
ipsec
tunnel
or
through
the
private
vpn.
So
the
cp
itself
has,
in
this
example
show
has
four
different
paths
basically
like,
for
example,
vlan
15.
C
Or
can
be
carried
by
the
port
170.0.1
or
can
be
carried
by
the
loopback
address,
so
using
bgp
we
can
very
easily
to
represent
this
property.
So
basically
you
have
the
prefix
10.1,
for
example,
and
using
tunneling
cap
to
to
indicate
that
this
particular
route
can
be
carried
by
one
of
the
four
tunnels.
C
C
Oh,
this
one
is
about
in
the
sd1
deployment.
C
Next
page,
please,
no!
I
don't
have
to
talk
about
this
page
next
one.
So,
oh
nick,
can
you
give
me
another
page,
just
the
previous
one?
Okay,
so
this
page,
not
this
one,
next
one,
okay,
so
this
page
is
sorry.
C
This
one
yeah
yeah
yeah,
so
so
this
this
is
to
show
that
all
right,
this
is
a
pe
based,
st1.
Okay,
I
don't
have
to
talk
about
that.
This
is
a
similar,
bgp
explanation.
C
Okay,
so
I'll
just
conclude
my
presentation,
then
I
know
that
the
working
group
adoption
call
has
issued
and
I
think
it
is
very
important
document
for
the
other
standard
bodies
to
show
how
ietf
has
handled
this
sd1
and
be
able
to
use
bgp
to
to
achieve
the
control
plan
for
this
overlay
network.
A
Thanks,
linda
adrian,
do
you
want
to
ask
your
question.
B
Yeah,
listen.
I
won't
use
up
time
except
to
say
that
I'm
I'm
bothered
by
the
term
application,
routing
and
I'll
write
something
about
it
on
the
mailing
list.
M
L
Okay,
so
I'm
just
gonna
present
this
draft
mpl
mps
nfr.
This
has
been
presented
last
time
in
the
intro
meeting
in
in
the
mps
intro
meeting
by
karidy.
So
today
I'm
going
to
present
it
in
the
best
working
group
next
slide.
Please.
L
So
problem
problem
statement:
fr
has
is
a
very
efficient
way
in
protect
link
theory
and
achieve
linked
node
failure
and
achieve
fast
convergence,
so
it
reduced
packet
loss-
and
this
is
a
well
known-
and
usually
it
is
a
strong
incentive
to
use
npms
as
a
data
plan.
L
L
So
when
this
happened
it
caused
problems
and
congestions
to
some
links.
This
draft
describes
some
of
the
situation
and
proposed
a
solution
to
using
special
purpose
label
next
slide
space
so
situation,
one.
This
is
mps
based
service,
it
could
be
evpn
or
ipvpn
in
the
picture
described
here.
We
have
a
c1
and
c2
clients
of
evpn
or
ipvpn,
and
the
c1
is
dear
home
to
p1
and
then
p
tune
in
all
active
fashions.
L
So,
in
a
lightweight
fr
case,
one
when
c2
send
traffic
to
c1
and
a
p3
forwarded
to
p1
p1,
detect
the
link
variant,
l1
and
it
in
that
case,
p1
will
use
a
protection
pass
which
is
pre-signaled
and
programmed
in
the
pfe,
and
the
p1
will
send
the
packets
to
c
through
the
protection
parts
via
p2
and
p2
or
4
to
31.
L
Similar
things
happen.
If
the
packets
arrive
on
p2
for
traffic
go
to,
c1
p2
will
do
the
same.
The
protection
pass
for
for
that
l2
will
be
p1
and
then
p1
sent
to
c1.
This
is
a
very
generic
egress
link
protection
in
a
light
weighted
way
and
for
layer
three
vpn
could
be
or
evpn.
Next,
please.
L
So
what
happened
is
in
in
if
fc
itself
fail
and
p1
sees
the
link,
failure
and
the
triggered
egress
link
protection.
L
The
package
the
packet
to
c1
will
were
sent
to
were
sent
to
the
p,
to
a
backup
pass
and
to
via
p2
and
the
2c1,
but
since
cc1
also
suffers
c1
suffer
the
node
theory
a
lot
most
likely
p2
will
also
see
the
failure
on
its
local
link.
L2
p2
will
also
trigger
its
fr.
In
that
case,
the
p2
will
send
packets
to
p1
and
and
again
getting
on
to
the
pe
one.
So
it's
trigger
another
effort,
so
this
is
in
this
case
second
fr.
L
It's
not
helpful.
It
causes
a
congestion
in
the
link
l3.
L
L
L
So
situation
three-
and
this
is
imr
note
fairy
case
so
in
imr
protection-
is
done
by
two
counter
rotating
lsp,
either
clockwise
or
anti-clockwise.
To
the
egress
note
now
say,
for
example,
if
a
note
5
need
to
send
traffic
to
node
1
and
it
sends
using
the
clockwise
path
and
the
link
between
7
and
note
seven
and
the
eight
fill
so
node
seven
will
send
the
traffic
anti-clockwise
to
node
one
that's
in
single
league
fairy
case.
L
However,
if
note
one
itself
suffer
failure
in
this
case,
node
0
will
protect
the
traffic
and
send
the
traffic
backwards,
the
anti-clockwise
to
to
node
trying
to
send
to
no
one.
But
when
they
get
down
to
note
2
note,
2
also
detect
the
faded
and
trigger
the
fr
and
the
protection
by
sending
the
traffic
clockwise.
L
L
So
so
this
is
talking
about
what's
the
solution,
so
the
for
situation
without
no
further
reroute,
which
is
nfr
so
as
stated
before,
in
this
case,
the
label
vl1
and
vo2-
are
vpn.
Labeled
vl1
is
advertised
by
pe1.
Vl2
is
advertised
by
pe2
and
the
tl
represent
the
transform
label.
L
L
So
when
traffic
arrives
at
p1,
what
p1
sees
is
a
label
vl1
the
transfer
channel,
the
tunnel
label
will
be
popped
or
php
apprised
and
the
p1
detector
link
favorite
to
l1.
It
will
trigger
the
fr,
send
the
traffic
to
p2.
Instead,
the
label
stack
will
be
t
and
transport
label
2
and
enable
2..
So
when
traffic
arrives
at
p2,
it
sees
the
label
vpn
label
l2,
which
is
allocated
by
himself,
and
he
also
detected
link
l2
failure.
It
would
trigger
fr.
This
is
a
loop
right,
as
you
talked
about
before.
L
Exercise:
price,
yeah,
okay,
so
the
solution
proposed
to
use
an
nfr
nfr
is
a
special
label
to
indicate
that
fr
has
already
happened.
So
in
this
case,
a
similar
case
as
before,
when
p1
triggered
the
fr,
it
will
push
nfr
label
after
vpn
label,
so
p2
receive
it.
P2
will
see
the
when
hip
hop
the
vpn
label
l2.
It
was
the
nfr
the
indication
and
fr
indicate
to
p2
that
this
is
traffic
coming
from
a
backup
pass
through
fr.
L
A
L
L
So
only
things
we
need
to
add
is
to
signal
the
capabilities
to
support
an
ffr
label
and
we
do
not
need
the
control
plane
extension
to
specify
how
to
signal
this
label
for
prevent
another
fr.
So
that's
the
reason
to
go
with
us.
The
special
label-
and
we
like
to
have
a
further
discussion
on
this
on
this
draft
in
the
mailing
list
and
also
have
a
companion
document
to
signal
the
ability
to
process
the
nfr.
L
N
Okay
hi,
can
you
hear
me.
N
Hey
when
yeah
a
very
quick
one,
so
in
these
slides
you
talk
about
evpn
and
ipvpn,
but
in
the
draft
documenta
I
read
in
section
to
the
one
that
you
refer
to
a
vpls
as
well.
Is
that
a
mistake
or
is
intentionally.
L
Yes,
that's
not
a
mistake:
yeah
vpn,
os2.
N
So
you
so
this
can
happen
also
with
vpls.
L
N
I
see
okay
and
the
the
other
one
is
in
the
evpn
case.
It
would
be
nice
to
specify
how
the
procedure
works
when
you
receive
from
the
from
the
remote
pe.
You
receive
traffic
with
a
with
a
multicast
label.
You
know
a
multicast
vp
vpn
label,
but
at
the
multi-home
ps
the
traffic
is
on
is
known,
unicast
right,
so
you
know
all
those
details
are
important.
I
think.
L
O
Straight,
can
you
hear
me
yeah,
I'm
wondering
that
instead
of
using
an
explicit
nfr
label,
can
pe
2,
given
that
pe
2
advertise
vpn
label
2
it
allocates
it
such
that
when
it
receives
the
label,
it
knows
it
is
used
for
the
fr,
and
thus
it
doesn't
send
the
packet
again.
If
it
is
locally
attached,
ac
is
fail,
so
do
it
basically
do
it
implicitly,
as
opposed
to
exclusively.
L
L
L
Bridge
domain
like
evpn,
are
labeled
for
evs,
so
it
means
a
lot
of
labels
need
to
be
allocated
to
distinguish
traffic,
whether
it's
coming
from
p1
or
from
p3,
which
is
the
remote
one
so
and
also
you
need
to
relay
to
signaling
and
evpn.
What
does
his
own
way?
Ipv
piano
would.
Does
this
his
own
way,
so
it's
rsvp,
you
know
all
that
different
protocol
does
in
his
own
way.
So,
like
you,
have
a
control
plan
extension
to
to
do
this.
L
A
Okay,
can
I
absolutely
take
it
to
the
list
now
and
to
move
on
to
garand's.
A
A
A
A
There's
a
problem
with
your
on
your
own.
I
think
with
your
your
audio.
I
think
we
need
to
move
on
because
we're
gonna
run
out
of
time
and
get
get
cut
off.
So,
okay,
sorry
about
that
ali.
I
think
you're
on
next.
P
O
Yeah
yeah,
that's
correct,
so,
given
that
the
mirage
is
not
here,
I
can
cover
his
presentation
as
well,
so
I
can
go
over
this
one
and
then,
after
that
we
go
over
the
unequal
load.
Balancing
is
that,
okay.
D
O
Okay
sure
so
I
got
it
10
minutes
or
slide
10
minutes
time
slot
we'll
see
how
much
I
use,
maybe
I
can
use
it
within
like
10
minutes
time.
So
this
is
a
short
presentation,
so
this
is
rev
0
of
the
secure
evpn
draft
and
the
nexus
flight.
Please.
O
O
O
A
little
bit
about
the
background
and
solution
overview
to
just
refresh
people's
memory,
the
secure
evpn
it
says
the
whole
gist
of
it
is
setting
up
point
to
point
ipsec
tunnels
among
endpoints,
using
point-to-multi-point
bgp
signaling.
O
To
do
that.
We
do
a
secure
control
channel
between
hpe
and
the
ros
reflector,
and
that
can
be
done
using
the
existing
iq2
to
set
up
the
point-to-point
tunnel
over
which
the
bgp
session
can
go.
So
bgp
session
goes
over
a
secure
point-to-point
tunnel,
and
once
we
have
that
then
bgp
signaling.
O
O
In
doing
that,
we
don't
need
to
use
a
point-to-point
signaling
and,
as
such,
we
reduce
the
number
of
the
message
exchanges
from
order
ns4
to
order
end
and
thanks
to
slime.
Please.
O
So
when
a
pe
first
comes
up
and
wants
to
set
up
an
ip
second
say
between
itself
and
each
of
the
interested
remote
pes,
it
generates
a
define
helmet
tear
for
each
of
his
intended.
Ipsec
essay,
using
the
algorithm
defined
in
iqv2
development
group,
transform
the
originating
pe
distributes
these
defilement
public
values,
along
with
the
nouns
using
ipsec
tunnel
tlv
in
the
tunnel
encapsulation
attribute
to
the
other
remote
pes.
O
We
are
the
roth
reflector
and
each
receiving
pe
uses
this
public
that
development
number
and
the
corresponding
nouns
in
creation
of
the
ipa
sec
essay
pair
to
the
originating
pe
next
slide.
So
that's
basically
a
gist
of
how
these
point
to
multiple
signaling
is
used
to
set
up
the
point-to-point
ip6
tunnel.
O
So
the
changes
in
rev01
we
added
the
requirement
for
setting
up
an
ipsec
essays
between
ingress
the
requirement
for
setting
up
an
ipsec
tunnel
between
a
pair
of
aces
between
ingress
and
eques
pe.
O
We
added
new
section
on
inheritance
of
security
policy
and
we
modify
relative
to
the
rev
zero,
the
ipsec
tunnel,
attributes
of
tob
for
better
optimization
and
in
rev02.
We
added
sections
on
zero
touch,
bring
up
configuration,
management,
orchestration
and
signaling,
and
which
is
this
one
is
basically
a
refresh
so
nexus.
One.
O
So
one
of
the
one
of
the
things
that
the
draft
covers
is
basically
a
method
of
the
inheritance
and
for
the
and
the
granularity
of
the
ipsec
tunnel.
So
the
ipsec
tunnel
can
be
set
up
at
a
very
fine
grain
of
granularity
on
a
pair
mac
address
or
pair
or
it
can
be
set
up,
as
at
the
corsair
granularity
of
top
net
or
per
tenant
or
even
per
pe,
and
once
you
like,
you,
set
it
up
on
a
pair,
tent
or
subnet
basis.
O
O
This
is
one
way
of
inheritance
and
there
are
two
other
two.
Other
stream
of
inheritance
exists,
one
based
on
the
recursive
ros
resolution
and
the
second
one
based
on
coloring
and
those
two
are
being
described
in
the
tunneling
chakra,
so
nexus
line.
O
So
the
draft
has
been
around
for
a
couple
of
years
and
it's
been
a
civil
for
over
a
year,
so
it
is.
We
think
the
authors
think
that
it
is
ready
for
a
working
group.
Adoption
call
so
we
like
to
be
the
draft
to
be
put
in
the
queue
for
the
working
group
adoption
so.
A
E
H
Okay,
ollie
there
I
find
a
few
things
that
you
stated
in
your
slides.
If
you
go,
if
you
can
go
back
two
slides,
I
can
be
much
briefer.
I
I
we
went
through
this
at
itf
105
to
try
to
work
on
the
security
issues.
H
O
So
the
encapsulation
is
ipsec
tunnel
and
then
you
can
use
the
you
can
use
the
ip6
tunnel
over
udp
and
because
we
got
the
vxlan
encapsulation
okay,
it
describes
how
we
can
do
vx
ipsec
encapsulation
that
covers
vxlan
and
those
formats
being
described
in
the
draft,
because
this
is
not
your.
H
Okay,
so
the
natural
tunnel
and
caps
draft
has
vx
tunnel
encapsulation
in
dash
17,
and
I
wondered
why
you
didn't
use
it
and
I'm
going
to
be
really
brief
and
just
point
things
that
I
I
don't
understand
the
second
is
you
actually
define
a
new
tunnel
type
and
you
seem
to
be
doing
the
same
sort
of
things
that
are
in
the
itf.
I
wanted
to
know
in
the
draft
why
it's
different,
why
you
needed
the
new
tunnel
type?
How
that
interacts?
H
O
O
O
O
And,
as
I
said,
that's
just
you
know,
we
looked
at
it
and
I'm
in
terms
of
the
available
tunnel
type
and
the
encapsulation
and
I'll
be
more
than
happy.
Why.
O
Can
you
please
send
me
exactly,
you
know
the
references
that
you
made
that
it
is.
You
said
there
is
already
a
thermotype
exists
that
can
handle.
You
know
that
we
can
cover.
We
expand
with
the
ipsec.
H
A
Thank
you,
linda
you're,
you're.
Next.
C
Okay,
so
my
question
is.
C
Okay,
so
in
the
in
the
draft
you
have
two
tunnel
types,
one
is
the
esp
transport
another
one
is
esp
in
udp
transport.
I'm
just
curious.
What's
the
difference
in
those
two,
I
race,
three
or
draft.
I
couldn't
understand.
O
E
N
N
Yeah
I
was
saying
that
in
the
ayanna
section
there
is
a
request
for
a
new
evpn
extended
community,
but
I
couldn't
find
in
the
traffic
about
how
to
do
it.
That
might
be
a
mistake.
A
Okay,
all
right
thanks,
so
we
have
christian
next.
Q
I
would
like
to
introduce
you
to
the
private
line
emulation
we
have
published
through
the
draft
that
you
can
see
here
and
I'm
speaking
as
a
representative
of
the
folks
that
here
on
the
list
of
authors,
we
have
been
working
on
this
concept
for
quite
a
while
with
a
group
of
service
providers
and
actually
verizon
co-authoring.
The
draft
because
has
been
on
the
forefront,
defining
this
technology.
Q
Thank
you.
So
there
are
two
drafts.
The
first
draft
is
defining
the
data
plane.
Essentially
it's
defining
an
encapsulation
mechanism
for
bit
strings
into
a
packet
switch
network
stream.
Q
You
may
wonder
why
am
I
dividing
this
now,
because
we
have
actually
10
to
15
years
ago
in
the
pwe3
group
already
defined
things
like
structure,
agnostic
transfer,
transfer
over
packet
like
rfc,
4453
and
and
others,
but
back
then
it
was
a
focus
on
low
speed
signals
like
ds1
and
e1
or
frame
relay,
and
now
we
are
trying
to
tackle
the
problem.
Q
How
can
you
a
bit
transparent,
transparent,
carry
high
speed
signals
such
as
10gb,
100gb
or
even
400db
in
the
future,
and
I
will
touch
base
on
why
somebody
would
want
to
do
that
in
the
next
slide,
but
also
important
is
that
essentially,
we
are
trying
this
time
also
to
define
the
encapsulation
to
be
underlay
agnostic,
so
it
shall
apply
to
mpls
as
well
as
srv6
networks.
Q
Essentially,
we
are
proposing
a
new
ple
pack
attribute
for
pgp
so
that
we
can
use
the
evpn
vpw
signaling.
That
already
exists
to
signal
those
special
epws
types.
You
can
go
to
the
next
slide.
Please.
Q
Q
We
shall
not
forget
that
today,
in
the
carrier
space,
there
are
still
a
lot
of
services
which
are
circuit
oriented
where
somebody
wants
a
a
point-to-point
connection,
potentially
100
between
two
data
centers,
and
there
needs
to
be
gated
bandwidth
or
less
like
a
time
slot.
People
are
asking
for
a
dedicated
wavelength,
for
example.
Right
and
you
know,
a
connection
less
packet
service
would
not
satisfy
these
requirements,
and
people
are
using
either
direct
wavelength
or
optical
transport.
Q
Networking
switching
technology
to
accomplish
those
kind
of
services,
but
what
we
have
seen
is
with
the
explosive
growth
in
packet
switching
silicon
capacity.
It
is
now
no
longer
cost
effective
to
actually
carry
these
kind
of
services
over
otn,
but
rather
actually
the
cheapest
way
to
carry
this
kind
of
traffic.
Even
if
you
don't
oversubscribe
and
pre-allocate
the
bandwidth,
it's
actually
deploying
an
mpls
or
packet,
which
network
this
also
gets
amplified
by
innovation
and
optics.
Where
now
you
can
actually
implement
dwm
optics
inside
the
routers,
which
makes
the
network.
Q
A
A
A
It's
not
just
me.
It's
yeah
yeah
go
ahead
anyway,
to
see
how
it
goes.
A
Q
Q
The
first
draft
proposes
an
encapsulation
for
those
bit
streams
using
somewhat
you
know,
a
known
reference
model,
where
basically
a
vpws
instance
is
established
between
the
two
p's
in
my
example
here
p1
and
p2,
and
you
can
use
it,
you
can
use
any
underlay
underneath
being
in
an
mpls.
You
know
tunnel
or
an
srv6
data
plane.
Whatever
you
have.
The
interworking
function
is
responsible
to
take
the
big
streams
and
encapsulate
that
into
packets,
and
we
are
proposing
two
payload
types.
Q
One
is
a
constant
bitrate,
payload
type,
where
basically
just
a
bunch
of
bits
without
any
care
of
structure,
are
getting
received
and
encapsulated
in
the
packet
and
the
packet
is
getting
sent
across
we're
also
proposing
a
frame
aligned
payload,
which
is
specific
to
cases
where
the
the
interface
would
be
an
opm
interface.
Q
We
leveraging
on
well-known
mechanisms
like
using
a
control
word
to
support
sequencing,
as
well
as
have
the
ability
to
have
data
plane,
failure,
indication
being
it's
a
client
layer
forward
indication
with
the
help
it
works.
Overlay.
A
Q
Okay,
sorry,
is
it
better
yeah?
Okay?
Last
but
not
least,
we
are
applying
differential
clock
recovery
to
make
sure
that
the
bit
stream
has
the
proper
clock
on
the
risk
on
the
far
end
for
those
of
you
that
might
have
looked
at
pwf3
stuff
from
the
past.
You
know
we
are
trying
to
align
with
previously
well
accepted
technologies
and
we're
basically
just
adopting
it
for
different
and
new
types
of
clients.
Q
Thanks
from
a
signaling
perspective,
we
are,
you
know,
leveraging
the
evpn
vpws
mechanisms
that
already
have
been
defined.
Really,
the
only
new
thing
is
because
evpn
really
is
centered
around
ethernet,
as
the
name
already
indicates.
Q
We
now
need
a
new
pgp
path
attribute
to
indicate
the
non-ethernet
aspects
of
attachment
circuits
things
like
what's
the
bitrate
of
the
big
stream
right.
What
is
the
payload
size
for
this
technology?
It
is
important
that
both
endpoints
are
using
the
same
payload
size,
for
example.
Otherwise,
the
the
transfer
would
not
work.
Q
Q
N
Yeah,
can
you
hear
me
yes
yeah,
so
the
first
draft
talks
about
an
encapsulation
so
wha?
Why
is
this
drafting
best?
I
mean
there
is
no
bgp
enabled
services
in
there
right.
It's
just
explaining
describing
the
encapsulation.
Q
Yeah,
this
is
a
very
good
question
and
apologize,
I'm
also
an
itf
newbie
from
a
contribution
standpoint.
We
got
the
feedback
that
potentially
this
draft
should
be
better
positioned
in
pals.
I
think
this
is
from
you
know
under
consideration.
N
A
With
the
pals
chairs,
because,
obviously
it's
a
case
of
where
the
expertise
of
the
encapsulations
resides
and
because
all
that
all
the
emulation
over
you
know,
encapsulations
for
emulating,
tdm
and
and
sdh
services,
and
so
on,
was
done
in
pw3,
which
kind
of
became
pals
and
and
that's
really
agnostic
of
the
the
control
plane
in
many
respects.
A
H
A
Think
I
was
just
quickly
checking
the
charters
and
I
think
pals
is
probably
still
sort
of
charted
to,
even
if
it's
just
an
encapsulation
to
do
that.
So
anyway,
we
should
sync
up
with
with
stuart
andy.
N
Yeah
and
even
the
the
second
draft,
there
says
yeah
ongoing
section
about
ldp.
That
should
also
go
to
pulse
somehow.
N
A
Okay,
thanks,
we
have
five
minutes,
I
think
left
ali
you,
I
think
you
were
going
to
quickly
go
through
the
one
that
niraj
could
not
was
not
available
for
the
unequal
load,
balancing.
A
O
Is
only
fewer
slides
nexus
right,
please
just
a
quick
recap:
the
draft
is
about
the
unequal
pec
link,
bandwidth
distribution
within
a
multi-home
ethernet
segment,
and
that
itself
consists
of
two
things.
One
is
procedure
for
unequal
load,
balancing
of
flows
from
the
remote
pes
and
then
the
other
one
is
procedure
for
unequal
load
sharing
of
df
roads
across
pes.
In
that
ethernet
segment
and
both
overlay,
unicast
and
bank
flows
load
balancing
needs
to
be
done
in
proportion
to
these
access
link.
O
Bandwidth
shared
in
the
lag
next
slide,
so
the
status
of
this
working
group
lascaux
got
initiated
in
the
march
2020
and
the
comments
we're
addressing
the
latest
revision
except
one
outstanding
issue,
and
that
outstanding
issue
is
a
link
bandwidth
extended
community
which
is
referenced
in
draft
idf
ideal
link
and
it
nexus
nexus
way.
O
The
issue
that
we
run
into
with
using
that
extended
community
is,
it
is
being
defined
as
non-transitive
and
evpn
needs
it
to
be
transitive
and
because
of
the
existing
implementation
and
deployment
of
the
existing
extended
community
link
bandwidth,
excellent
community.
It
is
difficult
to
try
to
use
that
in
a
transitive
mode,
so
the
proposal
is
a
simple
proposal.
It's
just
define
a
new
link,
bandwidth
extended
community
40
vpn,
that
is
transitive
and
the
type
is
0
6
evpn
and
the
subtype
is
the
next
available
subtype,
which
is
currently
one
zero.
P
O
And
that
has
currently
been
already
added
to
the
latest
rev
of
the
strength
and
it
got
published
a
couple
of
years
ago.
R
Yeah,
john
scott,
so
ali.
If
I
understand
you
correctly
with
the
proposed
transitive
version,
you
would,
it
would
sometimes
be
transitive
and
sometimes
be
not
depending
on
the
whether
you're
doing
next
top
rewriting.
So
there
has
to
be
a
logic
on
the
border
router
that
decides
whether
to
transit
the
thing
or
not.
Is
that
correct?
R
So
in
that
case
I
would
say
that
you
can
do
that
just
as
well
with
the
non-transitive
community,
because
what
you're
really
doing
on
the
border
router
is
you're
originating
a
new
community
based
on
the
condition
that
you've
defined
the
the
new
community
originating
happens
to
have
exactly
the
same
set
of
bits
in
it
as
the
old
community.
You
terminated,
but
that's
you
know.
That's
like
the
point.
R
If
you're,
if
you're
conditioning
it
on
on
on
the
next
hub.
O
Be
planning
to
interrupt
run
into
issues
that
the
existing
deployments.
O
You
know
that
the
existing
deployment
that
use
these
existing
ec
they
basically
behave
certainly,
and
we
cannot
update
the
changes
that
how
they're
gonna
behave
and
so
forth
for
these
excellent
for
the
existing
extended
community,
but
for
the
new
external
community
you're
at
the
position
that
they
can
define
the
behavior,
including
the
conditional
transitivity.
O
So
because
of
that,
we,
as
I
said,
we
started
by
using
the
existing
one,
but
we
ran
into
issue
with
the
existing
deployment.
O
To
the
existing
ec
and
the
deployment
issue
that
we
saw
with
the
existing
deployment
thanks.
M
A
M
A
M
Four
minutes
before
being
kicked
out
so
jeff
transfer
hi.
Can
you
hear
me.
S
Yes,
yeah,
so
the
problem
with
the
community.
It's
been
abused
or
used
incorrectly
in
transitive
way
in
in
egypt
deployments
as
well,
especially
in
data
centers.
I
tried
to
contact
authors,
probably
three
four
times
and
linkedin
didn't
really
work.
So
I
suppose
we
should
really
redefine
the
community
as
transitive
and
be
done.
A
Very
good,
thank
you,
jeff
jeffrey.
Maybe
just
one
quick
comment
from
you:
you
were
in
the
queue
jeff
house.
T
Thank
you
for
your
confirmation,
a
very
quick
comment:
employer
juniper
work
on
implementation.
We've
been
using
the
transitive
version
of
the
link
bandwidth
code
point
for
our
entire
time.
We
actually
don't
support
the
non-transitive
one.
T
My
suggestion
is,
you
know
we
have
a
code
point
that
works
the
primary
issue
that
we
have
and
we've
had
this
discussion,
as
we've
been
recently
asked
to
support
the
non-transitive
version
is
how
you
actually
make
the
two
code
points
comparable.
So
I
think
that's
actually
the
way
we
probably
should
want
to
take
this
forward.
T
The
problem
is:
how
do
you
actually
take
both
a
transitive
and
a
non-transitive
link
bandwidth,
which
are
you
know,
different
code
points
technically
really
they're,
just
something
with
a
different
bit
flipped,
and
how
do
you
make
them
comparable
to
each
other?
So
if
you
have
implementation
that
receives
a
transitive
from
one
route
non-transit
from
another
route,
how
do
you
make
sure
that
you
compare
the
two
for
load
balancing
purposes?
T
O
T
O
So
that's
the
thing
now
the
question
is:
with
the
you
know,
many
vendors
have
implemented
non-transitive
based
on
what
the
traffic
has
specified.
O
That
can
cause
issues
with
the
existing
deployment,
but
the
all
I
will
follow.