►
From YouTube: IETF105-BESS-20190723-1520
Description
BESS meeting session at IETF105
2019/07/23 1520
https://datatracker.ietf.org/meeting/105/proceedings/
A
So,
let's
Tata,
so
this
is
the
best
session
in
Montreal,
so
this
week,
for
the
first
time,
we'll
have
two
sessions
so
one
today
and
there
will
be
one
very
late
on
Thursday
and
fortunately
so
we'll
start
with
our
our
statues
of
LG
not
well
pleased
with
it.
If
you
are
not
aware
about
it,
but
it
says
that
whatever
you
are
saying,
you
are
contributing
to
or
to
be
a
part
of
your
participation.
A
Okay,
so
let's
start
to
your
status.
So
since
last
time
we
have
a
three
new
RFC's.
We
have
two
documents
that
are
still
in
an
RFC,
a
little
cute,
but
still
awaiting
due
to
our
to
mr.
F.
So
this
year,
Aquino
very
still
awaiting
for
the
turnaround
caps
from
idea,
I
think
and
the
ETP
and
profits
advertisement
is
waiting
for
me.
Intel
intercepted
forwarding
an
hour
sang
which
is
a
I
think
and
Martin
review.
A
A
Fortunately,
we
have
some
help
some
home
over
people.
So
when
proceed,
your
updates
I
think
she's,
a
writer
isn't
going
so
it
should
should
happen
sooner
NS,
h,
bgp
control
pain.
I
don't
know
if
we
have
adrian
in
the
home
or
not.
There
is
still
a
small
update
to
do
in
the
document
before
moving
moving
forum.
A
We
have
a
problem
with
the
bestsellers
changing
draft,
so
I
started
the
Shepherd
with
you.
We've
seen
that
document
is
really
really
far
from
being
ready
to
be
published
because
it
is
targeted
to
Bastogne
attract
an
area.
There
is
no
possibility
to
make
it
stand
out
as
it's
done
today,
and
this
is
a
huge
work
to
make
it
I
will
not
say
readable
but
be
read
evil
to
be
a
beast
on
the
track,
and
we
have
portal
working
good
to
know
if
there
is
still
some
support
to
help
proceeding
with
this
document.
E
A
We
don't
have
any
people
that
really
want
to
add
progressing,
and
the
authors
also
are
not
responding
any
more
on
this
one.
So
our
proposal
is
to
have
to
this
document
that
we
would
like
also
to
know
maybe
formatting.
If
there
is
an
issue,
probably
with
another
wardrobe
like
SFC,
though
we
don't
know
yeah.
C
C
A
So
we
are
still
a
bunch
of
documents
that
are
all
ready
for
working
up
last
quarter.
As
per
our
of
you.
Please
just
review
this
and
it's
not
accurate
and
if
you
still
need
to
do
some
updates
on
this
document,
just
let
us
know
so
we
can
remove
these
documents
from
our
home.
Aren't
you
I
got
a
question
with.
B
A
C
A
A
Milestones
so
we
are
clearly
laid
on
some
topics,
so
the
first
one
is
yeah.
We
have
the
top
yet
to
submit
at
least
reading
layer,
three
layer,
two
and
evpn
in
January.
We
are
now
in
July
and
not
done
yet
so
I
think
we
will
have
an
update
on
yang
on
our
first
accession,
the
GP
and
SH
control
plane.
We
are
targeted
to
ascend
aah
by
March.
A
So
we
had
this
kind
of
site
meeting
with
the
idea
of
shares
in
June,
try
to
see
how
we
can
organize
this
work
for
the
IPSec
PGP.
Similarly,
what
has
been
agreed
is
that,
if
we
need
to
define
some
sincerely
for
internal
encapsulation,
this
will
be
done
in
idea,
but
people
from
best
can
I
can
contribute,
but
then
a
part
of
that
we
need
also
to
try
to
work
on
via
security,
Association
mechanism
and
how
to
do
be.
A
A
One
of
the
fact
is
that
we
don't
really
have
all
the
IPSec
expansion
idea
on
even
invest.
So
what
has
been
decided
is
that
there
will
be-
and
discussion
in
idea
of
tomorrow
discuss
this
topic,
including
some
IPSec
experts
that
will
help
us
to
determine
whoa
yeah.
What
is
the
best
way
to
are
to
do
this?
So
if
you
are
interested
in
this
topic,
please
beware
tomorrow,
in
idea
to
our
to
air
power
and
provider
for
by
your
comments.
B
F
Hi
everyone,
my
name,
is
Gerard
Avril,
LinkedIn
I'll,
be
presenting
on
behalf
of
the
authors
and
sorry
le
for
bumping
it
on
so
I'll,
be
presenting
the
SR
v6
BGP
overlay
services.
We
have
presented
this
draft
few
times
before,
if
presented
in
ITF
98
for
l3
VPN.
Then
we
presented
again
evpn
services
in
idea
101
in
idea,
then
we
presented
change
the
draft
and
presented
in
bests
in
idea
104,
and
this
document
has
matured
significantly.
F
There
has
not
been
any
significant
changes
made
to
the
document
in
multiple
years
and
it
has
even
multiple
customer
deployments
in
the
field
around
the
globe.
So
in
this
update
we
are
doing
some
minor
modification
addressing
all
the
comments
which
are
coming
in
from
the
working
group
members
and
also
special
thanks
to
Jorge
and
Allie,
for
you
know
for
me
to
be
packing
issue,
which
was
there
which
we
have
addressed
in
this
document.
So
thanks
for
their
contribution
and
we
have
added
them
as
the
contributor
and
authors
in
this
document.
F
So
the
one
other
problem
which
was
originated
in
the
last
working
group
was
about
the
BGP
packing
in
certain
conditions,
especially
when
it's
a
EVP
and
VP
WS.
We
have
a
case
where
we
may
be
able
to
do
suboptimal
packing
in
BGP.
So
let's
say
all
the
attributes
in
BGP
are
common
across
certain
set
of
LR
eyes,
but
because
of
the
EVP
and
VB
SS
ID
might
be
different.
It
can
actually
lead
to
the
suboptimal
packing
of
the
BGP
updates
going
out.
F
So
what
we
have
created
is
introduced
a
flexibility
of
having
the
function
and
arguments
in
the
and
this
in
the
label
field
of
the
NLRA.
So
the
attribute
will
remain
the
same
and
we
are
advertising
that
as
a
sub
sub
TL
via
structure
sub
sub
TL
v
in
the
bgp
update.
Because
of
the
nature,
this
is
an
optional
sub
sub
TL
v.
It's
fully
compatible
with
a
the
current
implementation
which
are
out
there.
F
So
this
is
how
the
sub
the
stage
structure
sub
sub
TL.
We
will
look
like
so
we'll
have
the
SS
SR
service
data
subsidy
LV
set
to
1,
which
represents
the
structure
TLB
length?
The
usual
boilerplate
fields,
we
also
have
a
transparent
transfer
position
length,
which
is
basically
the
part
of
the
CID
shifted
into
the
label,
the
label
field
and
then
the
offset
for
those
bits.
F
Just
to
go
over
the
implementation
status,
as
I
was
saying
earlier,
there
has
been
deployments
which
are
publicly
announced,
so
Softbank
China
Telecom
has
already
deployed,
and
there
are
multiple
other
deployments
which
are
not
public
yet
which
will
be
released
by
the
vendors.
There
has
been
three
Cisco
Harding
hardware
forwarding
planes
which
have
already
supported
and
two
Cisco
operating
systems.
Huawei
has
also
supported
multiple
platforms
and
then
it's
also
supported
in
Linux
kernel
natively.
We
also
have
barefoot,
Tofino,
OCP
and
wedge
implementation.
F
B
A
F
A
Perfect
seed
was
fought
with
MPs
in
mind,
which
was
consistent
will
be,
as
I
said.
He
is
using,
but
I'm
pretty
find
that
you
are
using
the
DGP
privacy
to
signal
all
necessary
attributes
that
you
need,
but
for
me
it
would
be
great
to
add
an
addition
turn
on
caps
for
consistency.
Reason
to
tell
that
it's
doing
the
services
will.
A
My
other
point,
still
speaking
as
your
is
about
packing,
which
is
a
good
thing
to
add
what
I
don't
like
is
that
you
have
two
ways
to
do
the
same
thing.
So
can
you
consider
doing
just
a
single
one,
because
you
know
we
don't
it's
not
really
clear
in
the
drug.
You
are
not
telling
that
you
must
do
be
a
I.
Would
save
it
back
to
me
friendly
way.
Most.
A
F
A
B
A
B
A
B
For
for
them
to
solve
the
packing
they
introduce,
you
know
this
flexible
structure
and
all
that,
and
that
basically
is
a
superset.
So
once
you
have
that,
then
sending
getting
a
you
know
opaque
way
that
introduces
very
little
complexity
so
having,
in
other
words
having
both
of
them.
Once
you
have
the
way
to
address
the
packing
having
the
second
way
introduces
very
little
overhead.
A
B
Okay,
you
know
a
status
update
for
two
short
drafts,
the
first
one
for
the
multipad
procedure
for
evpn
all
active
waited
multipath,
and
that
is
basically,
if
you
have
a
all
active
multihoming
and
not
all
the
links
are
of
the
same
bandwidth
and
either
as
a
result
of
the
failure
or
the
way
it
was
configured
right
from
the
beginning.
Then
the
question
is:
how
do
you
do
weighted
load
balancing
toward
these
different
links
from
the
for
both
unicast
and
multicast
traffic?.
B
So
that's
where
the
unicast
traffic
for
the
multicast
traffic.
They
do.
These
bandwidth
attribute
exchange
among
the
multihoming
pease,
and
then
they
decide
how
to
do
the
DF
election
or
weighted
DF
election
and
the
based
on
that.
They
decide
PE
between
p1
and
p2,
p1
and
p2
among
themselves.
Decide
who
should
forward
more
traffic
to
the
cee
based
on
that
weighted
DF
election?
B
So
these
are
some
quick
summary
of
the
solution
section
we
added
a
very
short
section
section,
4.4
to
optimize
the
weight,
the
weighted
DF
election
based
on
weighted
HRW,
and
there
is
a
new
draft
that
talks
about
how
these
weighted
HRW
is
done.
So
this
is
a
quick.
This
is
a
very
brief
section
pointing
to
that
draft
in
terms
of
the
status
of
it.
It
is
in
good
shape
and
has
been
a
stable
for
quite
some
time,
and
it
is
pending
implementation
and
I
think
it
is
ready
for
the
working
group,
Co
Lascaux.
A
A
A
B
G
A
B
Okay,
extended
mobility
procedure
for
evpn
IRB.
This
is
a
draft
that
also
been
around
for
a
while,
and
this
one
I
know
the
status
of
implementation.
It
has
been
implemented
this.
If
you
look
at
the
baseline
7432,
it
is
assumes
one-to-one
mapping
between
the
Mac
and
IP
address.
So
the
host
has
one
Mac
and
one
IP
address
and
that's
the
fixed
mapping.
There
are
a
bunch
of
use
cases
that
has
nicely
been
described
in
this
draft
that
talks
about.
That
might
not
be
the
case.
B
You
might
have
many
IP
to
Mac
binding,
or
vice
versa,
many
Mac
to
IP
bonding
and
in
those
cases
the
host
IP
moves
hoseok.
We
can
move
to
a
different
Mac
or
host
Mac
and
move
to
a
different,
IP
binding,
and
the
last
case
is
well.
There
is
also
when
you
talk
about
l3
purell,
three
use
cases
you're
not
going
to
have
a
MAC
address
at
all
you're
just
going
to
have
an
IP
address.
So
then,
how
do
you
take
care
of
the
IP
mobile
in
those
cases
how
you
take
care
of
the
mobility?
B
B
They
anchored
the
sequence
number
to
only
the
MAC
address
and
then
the
IP
in
heresy
and
if
Mac
moves,
then
that
takes
the
anchor
sequence
number
with
it
and
with
the
rotted
overlay,
which
is
pure
IP
case,
adjusts
the
sequence
number
our
applies
to
the
IP
address,
just
as
if
it
applies
to
the
MAC
address.
So
the
procedures
in
the
routed
overlay
is
basically
the
same
as
Mac
mobility
in
7432.
B
B
There
was
a
the
changes
relative
to
the
last
riff.
It's
been
minor
when
had
a
comments
with
respect
to
some
certain
race
condition
that
we
thought
it
is
worth
a
worthwhile
to
capture
it
in
the
draft
making
sure
it
is
documented.
So
we
added
a
short
section
to
capture
the
race
condition
and
the
remedy
for
that
also,
we
fixed
some
terminology
and
for
consistency
with
the
other
evpn
documents
and
some
minor
edits.
This
one
is
also
being
implemented
by
multiple
vendors
and
we
are
good
to
go
for
the
working
group.
Lascaux.
H
B
J
That
action
actually
might
amuse
on
me
Jeff,
as
I
haven't,
follow
up
on
the
link
bandwidth
just
for
a
second,
so
junipers
implementation
has
been
transitive
for
ages.
It
squats
on
exactly
the
same
code
points
just
with
the
different
transitivity.
This
is
a
known,
Interop
problem.
The
link
bandwidth
draft
has
gone
ietf
dead
for
a
while
got
dusted
off,
I
think
my
Keith
on
the
about
a
year
ago.
We
really
should
just
work
together
and
try
to
actually
get
this
taken
care
of
sure.
J
B
One
question
this
attribute
is
frankly:
defining
a
new
dress,
is
a
different
draft
and
it's
been
around
for
ages
and
somebody
I
think
volunteers
to
move
it
forward.
So,
okay,
so
I.
Basically
what
I'm
trying
to
say
it
is
nothing
to
do
with
this
draft,
because
this
draft
just
references
the
other
one,
but
we
need
to
solve
that
one
in
order
to
make
sure
you
know
the
crit
for
the
transitive
and
non-transitive
cases,
it's
okay
right.
J
K
K
L
G
Caravel
on
Nokia,
no
just
a
couple
of
comments,
so
in
the
ISO
in
the
earth
tlvs,
you
put
a
tournament
tag
ID
before
the
Ethernet
segment
identifier,
whereas
if
you
look
at
the
routes
in
RFC,
seven,
four
three
two
is
the
other
way
around,
so
the
the
ESI
is
actually
above
the
ethernet
tank.
Is
there
any
reason
for
it
or
it's
just
there?
It's.
K
Just
alignment,
no
there's
no
any
particular
ease
and
we
are
just
defined
because
these
are
new
definition
for
these
sub
t
always
right.
So,
even
though
they
are
based
on
what's
in
the
RFC
4:32,
but
these
are
I
mean
new
TLDs
really,
so
we
have
put
it
this
way.
But
today
we
can
take
your
comment.
Yeah.
K
G
G
O
O
So
the
draft
was
first
presented
at
IETF
99
in
2017
in
Prague.
So
what
is
that?
What
the
draft
is
about
is
that?
How
can
we
extend
the
EVP
and
control
plane
to
support
an
ink
cap
for
Geneva?
Geneva
has
been
a
tunnel
encapsulation,
that's
adopted
now
by
enviously
as
a
sender
in
cap,
so
so
this
is
why
it
makes
sense
to
have
a
VPN
control
plane,
support,
Geneva
encapsulation.
So
the
draft
specify.
O
How
can
we
support
that
in
the
BGP
tunnel
encapsulation,
as
well
as
the
draft
defined
a
new
genève
option,
an
option
TLB
or
the
reason
described
here
so
that
option
TLB
is
going
to
be
used
to
carry
indication
for
the
bomb
traffic
as
a
wee
bit
as
well,
an
indication
for
Zelly
for
root,
leaf
handling
and
as
well.
It
will
have
an
optional
24-bit.
This
is
for
between
codes
ESI
equivalent
to
the
ESI
label
for
split
horizon
business.
So
this
is
what
that
20
is.
Those
24
bit
will
be
useful,
which
is
going
to
help.
O
P
Well,
let
me
ask
you
this
question:
where
were
you
intended
cherish?
How
does
this
relate
to
the
last
discussion?
We
had
about
tunneling
caps
additions
going?
Are
we
gonna
put
them
in
ID?
Are
we
going
to
put
them
in
best,
or
do
we
just
sort
of
figure
out
which
one
and
go
from
there?
Okay,
tunneling
cap
draft
is
closed.
Last
time
we.
A
Discussed
about
the
IPSec
congratulation
that
general,
but
yeah,
I
I
just
end,
at
least
in
my
opinion.
We
could
invest
at
the
new
types
with
in
vitro
their
own
caps.
A
P
So
you
have
a
look
okay,
so
one
of
the
things
is,
we
have
we're
finishing
off
the
current
tunneling
caps
draft
and
we're
both
taking
tunnel
end
caps
additions.
We've
either
got
a
you
know.
We
work
well
together.
We
just
got
a
cross.
Do
this
and
not
have
people
having
the
same
type
of
tunnel
end
caps
next
set
so
I
think
we
need
to
harmonize
that
together.
P
Both
places
have
good
things,
but
they
have
to
be
cross
reviewed.
We
need
to
not
have
things
coming
for
the
same
thing,
but
that
that
is
I'm.
Assuming
we're
going
to
do
that
because
you
guys
are
great
for
the
genève
and
the
beer
stuff.
We
need
to
be
careful
on
the
on
the
basic
functionality,
and
that
is
where
I'm
gonna
make
a
direct
comment
towards
your
draft
good
stuff
want
to
see
it
in
tunneling
caps,
no
problem.
We
need
to
think
about
the
chicken-and-egg
approach
with
tunnel
and
caps
with
Geneva,
if
once
an
overlay
underlay.
P
B
Me
try
to
address
it.
I
mean
this
is,
is
a
good
concern,
because
the
tunneling
cap
draft
is,
you
know,
we're
trying
to
publish
it
as
the
RFC
is
in
the
last
stages
been
around
for
ages
and
we
don't
want
to
add
any
more
to
it
and
if
you
want
to
add
it,
then
we
want
to
make
sure
that
we
are
in
sync.
So,
however,
with
respect
to
this
draft,
as
specifically
and
with
respect
to
other
evpn
drafts,
we
don't
use
tunnel
in
cap,
we
just
use
the
extended
community,
which
was
defined
in
RFC
5512.
P
P
First
there's
the
chair,
stuff,
I'm,
trusting
you
guys
just
mentioning
we,
we
gotta
go
deal
with
where
we
do
this
stuff.
If
you're
shoving
forth,
for
example,
extended
communities,
that's
against.
What's
in
the
current
version
of
the
that's
been
passed
through,
working
group
calls
sent
to
you
guys.
We
need
to
deal
with
that
with
the
rest
of
you,
pants
I'm,
trusting
the
chairs
I'm
trusting,
although
we're
gonna,
do
that.
That's
not
my
point.
I
was
making
to
this
author
to
be
respectful.
My
point
is
genève.
P
B
Thing
the
tunnel
in
cap
is
backward
compatible
with
respect
to
the
extended
community.
They
inherited
extended
community,
which
defines
a
tunnel
tight
from
5512.
They
put
it
into
the
tunneling
cap
and
whatever
we
have
in
the
evpn
is
consistent
with
the
tunneling
cap
that
uses
the
PGP
X
and
the
community.
So
these
are
not.
You
know.
We
are
not
in
conflict
on
anything
like
that
is
compliant
with
5512,
that's
true,
well,
50s
and
then
5512
is
obsolete
in
and
got
superseded
by
tunneling
cap,
but.
O
Q
Q
So
so
today,
if
you
look
at
the
RFC
742
the
way
we
are
doing
recovery
for
any
length,
failure
or
node
failure,
we
use
a
peering
timer,
which
is
I
think
by
default,
the
three-second
timer,
and
so
therefore
your
recovery
is
about
three
seconds,
so
it
takes
a
bunch
of
time
and
and
for
surely
a
lot
of
customers
are
not
happy
about
it.
So
therefore
we
scratch
our
heads
and
came
up
with
two
different
options
and
one
of
the
options
is
the
handshake
and
another
one
is
a
recorded.
Q
Basically,
we
to
Newark
ties
has
been
introduced
and
pretty
much
you
just
tell
the
other
guy,
hey
I'm
gonna,
be
the
I
need
I'm
gonna,
be
covering
basically
giving
you
kind
of
a
message:
European
peace
and
the
pinkies
when
they
are
ready
and
they
have
done
their
their
switching
for
the
D
afresh
and
again,
you're
gonna
give
you
kind
of
an
acknowledge.
That's
one
of
the
mechanism,
pretty
straightforward.
However,
we
got
a
couple
of
complaints
that
you
all,
so
why
do
we
need
new
route
time?
Q
So,
as
author
we
are
looking
at
really
optimizing
the
the
way
we
are
doing
it
just
for
two
keys,
because
it's
usually
cover
maybe
90
to
95
percent
of
all
the
multihoming
use
case
that
we
are
doing
so
soon
on
the
next
videos.
You
will
see
some
tanks
there
how
we're
gonna
do
this
regarding
the
the
other
option
is
really
with
the
DF
addiction
synchronization.
So
pretty
much
that
one
is
very,
very
simple,
so
the
guy
which
is
which
is
recovering
is
encoding
inside
a
a
new
BGP
x10
committee.
Q
Just
a
time
stand
say:
hey
I
thought
at
a
point
of
time:
I'm
gonna
switch
over
and
and
and-
and
we
carve
my
my
service,
so
you
give
that
to
the
European
bees
and
that
that
time
that
that
value
that
we
are
passing
is
like
in
the
future.
So
all
the
green
viewers,
okay
cool,
so
we
are
empty
peacocks
saying
so.
Therefore,
I
5
p.m.
at
32nd
everywhere
we're
gonna
switch
over,
and
this
is
how
it's
the
mechanic.
So
we
have
both
options.
Q
I
think
we
are
still
seeking
for
more
comments,
but
one
thing
that
you
need
to
be
aware
is
both:
an
implementation
has
been
implemented.
Both
option
has
been
delivered,
also
the
customers,
so
it's
being
used,
and
we
are
getting
good
result
with
that
work.
Group
eruption
also
will
be
very,
very
nice
for
this
draft.
R
Okay
and
making
source
discover
interrupts
into
operation.
This
is
a
ongoing
collaboration
between
the
co-authors
or
existing
traps
and
stake
neck
neck
Amana.
A
new
aspect
of
this
topic,
so
MVP
MSD
PSC
interoperation
drafts,
is
about
translating
MVP
and
sorcerer
key
routes
into
MSTP
source.
Active
messages
that
drafts
is
ready
in
queue
for
the
working
group
last
call
it
has
not
been
called
yet,
but
then
steak
and
the
McManus
said
wait.
Could
we
add
another
small
thing
into
this
as
well?
They
were
which
is
pfm
SD,
and
what?
R
What
and
what
is
that
its
existing
RFC
pin
flooding
mechanism
and
source
to
gas
discovery?
Basically,
the
pimpy
SR
mechanism
is
extended
to
flood
general
information
through
a
pin
domain,
and
in
this
case
that
is
used
for
announced
source
information
throughout
the
pin
domain.
For
example,
the
first
hop
router
once
it
detects
a
particular
source
for
per
group.
R
It
will
use
the
pfm
to
flood
the
information
and
the
last
hop
routers
will
join
that
sg3
directly,
instead
of
going
through
the
share
tree
and
switch
so
the
first
hop
router
will
also
include
its
own
address,
as
the
originator
address
in
the
PFL
message,
with
that,
each
hub
will
use
that
address
for
RPS
checking.
If
you
receive
that
PAP
messaging
from
the
non
PR
RPF
neighbor,
then
you
will
discuss
the
discarded
that,
as
the
information
is
encoded
as
TLD
in
that
message,
so
that's
basic.
R
What
that
pfm
as
the
RC
it's
about
now
now
comes
to
the
interoperation
with
em
VPN.
So
we
so
in
the
MEP
in
case,
if
you're
using
MSTP,
then
this
the
once
the
a
PE
learns
that
as
a
source
and
group
information
from
either
MSD
P
or
from
NPM
register,
it
will
advertise
a
ma,
p,
NS,
a
routes.
That's
the
MSTP
case
now.
Similarly,
that
PE,
once
he
received
the
prm's
as
the
flooding,
the
SSE
information,
it
could
also
trigger
Mbps
a
routes
and
under
egress
PE.
When
the
when
you
receive
the
MSD
p
sa.
R
When
you
receive
mm
dpns
a
routes,
you
could
trigger
MSD,
PSA
announcements
and
similar
to
that
here.
Instead
of
clicking
MS
D
P,
you
could
figure
PF
m
SD
messages
and
in
both
cases
you
use
the
existing
making
s.
Arp
address
extended
community
that
is
defined
in
that
draft
I
mentioned
earlier.
We
can
use
that
to
carry
the
early
originator
address.
So
that's
when
the
egress
P
received
that
Mbps
a
route
you
can
use
that
some
address
carried
in
in
that
extended
community
as
the
original
address
in
the
triggered
p
FM.
As
the
message.
R
There
are
some
details
about
this,
for
example,
if
a
suicide
is
multi-home
to
p1
and
p2,
then
it
will
trigger
to
Mme
PSA
routes
from
those
two
keys
respectively.
As
for
the
same
as
G
mapping,
they
carry
the
same
extending
community
because
it
does
Messier
coming
from
the
same
first
hop
router,
but
those
to
em
and
being
sa
routes
who
will
have
different
are
our
deeds
and
the
third
PE
receiving
those
multiple
as
a
Mbps,
a
routes.
R
R
Another
small
thing
is
that
when
the
under
and
I
on
the
source
side,
if
that
p,
FM
SDS
in
mapping
x
outs,
then
as
Mbps
a
route
is
withdrawn
by
the
originating
PE
and
on
the
other
side,
when
you
receive
that
withdrawal
route
withdraw,
then
the
PE
could
optionally
change
the
whole
time
in
their
group.
Sauce
Haute
I'm
Tod
in
the
P
at
MSD
music
to
zero
that
basic
Cal,
the
downstream
Rogers
hey
you
can.
This
is
timing
out
you
timed
out.
R
You
can
remove
it
so
now
it's
it's
simple
enough,
straightforward,
very
similar
to
MSTP
case.
There
is
one
small
cut
shot.
We
need
to
get
some
opinions
of
the
working
group
on
and
it
shares
the
that
RFC
about.
Pf
MSD
is
experimental,
so
we
could
we
rename
the
existing
drafts
about
MSD
p
sa
incorporation.
We
rename
it
to
a
media
source
discovery
interoperation
cover
boss
as
long
as
it's
not
a
croissant
concern
that
the
p
FM
as
the
ARP
C
is
experimental.
R
M
Cylinder
Cisco,
how
many,
how
widely
the
implemented
and
deployed
is
is,
is
that
PF,
MSD
impairment.
S
I
Russia
project
Cisco,
so
there's
a
question:
does
this
also
cover
scenarios
where
the
source
active
discoveries
are
both
MST
fee
and
pfm?
A
different
each
citizens
here,
using
the
same
extended
community
to
carry
the
RP
address
and
Mississippi
source
active
as
well
as
the
euro
generous?
If
2p
is
discover
sources
by
these
two
different
mechanisms?
R
R
I
L
L
M
L
S
Stick
stick
on
us
again,
so
what
I
imagine
will
happen
and
I
know
people
are
in
just
some
people
interested
in
doing
is
having
some
pim
domains
where
they're
using
around
the
weak
points
in
MSTP
and
having
other
PIM
domains
where
they
are
using
PF
MSD.
So
I
could
imagine,
use
cases
where
you
basically
the
same
organization.
S
They
might
have
one
site
using
MCPS
out,
on
the
other,
a
PF
MSD
and
most
useful
to
be
able
to
actually
have
BGP
to
to
kind
of
bridge
those,
and
you
can
say
it
doesn't
matter
for
one
site
what
technologies
use
for
sources
covering
in
a
remote
side.
So
whether
it's
one
draft
or
not
find
the
leader
but
I,
think
it's
useful
to
actually
it's
the
same,
the
same
route
to
announce,
regardless
of
how
we
learned
the
source.
A
A
A
R
R
So
traditionally,
l3
VPN
are
signaled
by
BGP
amperes
label
braking
address
safely
and
use
mpos
tunnels.
Initially
it
was
our
fare,
RC,
25:47
and
later
on
became
4364
and
correspondingly
multicast
is
specified
in
RFC,
6513
and
14,
and
then
some
time
earlier,
the
with
the
EBP
in
this
new
draft
between
prefix
other
husband
specifies
another
way
for
signal.
There
are
three
BPM,
they
say:
use
eBay,
bian
and
Safie
hi-5
routes.
There
are
two
reasons
for
for
the
new
signalling
one.
R
R
R
It
could
do
the
same
thing:
that's
even
with
be
cheap
with
the
bgp,
with
a
25:47
signaling
by
using
panel
encapsulation
attributes,
but
that's
that
that
came
later
then
now.
The
thing
is
that
if
you
do
have
the
ER
through
VPN
signal
with
the
impact
five
routes,
the
way
to
do
multicast
is
not
specified.
Yet
it's
outside
the
scope
of
the
or
it's
no
document,
and
so
this
is
what
this
crap
is
about.
R
R
R
Each
they
listener
who
have
some
peas
in
that
rectangular
box
and
the
our
shapes
in
those
peas
are
basically
the
bridge
domains
now
with
EBP
entellus
in
the
interconnects.
Typically,
the
bridge
domains
are
not
stretched
across
the
data
centers
or
you
could
have
them
stretched,
but
when
you
don't,
then
you
use
the
there's
really
pink
aside
at
the
to
interconnect
them
in
this
case.
R
Even
if
you
don't
have
the
bridge
domain
stretched,
you
could
use
the
optimal
intercept
multicast
with
the
Supplemental
bridge
domain,
stretched
across
the
data
centers,
and
with
that
you
can
just
reuse
existing
already
defined
or
ism
procedure
to
do
the
multicast
and
the
its
advantage
is
that
it's
all
a
bit
in
solution,
and
it's
and
also
in
case
of
all
source,
multicast
or
any
social
markets.
You
don't
need
any
of
the
RP
procedures.
R
R
You
need
to
make
use
of
the
routes
that
are
signaled
by
even
being
paid
five
routes
and
also,
if
you
have
a
piece
at
a
source
or
customer
source
or
customer
RPE
sites
than
the
routes
for
those
customers
or
customer
RP,
they
need
to
carry
to
extending
communities
that
are
used
by
RFC
6514
procedures.
Now,
with
the
even
even
type
five
routes
you
need
to
attach
those
extended
community
to
those
routes
as
well.
R
R
R
The
third
scenario
is
that
you,
you
have
the
layer,
3,
VPN
and
datacenter
interconnects,
and
you
could
use
all
them,
but
you
may
decide
that
I,
don't
want
stretch
SPD's
across
that
there
are
cinders.
So
in
that
case
you
can
use
this
to
interconnect
data
center
gateways.
However,
this,
while
this
works,
it
may
not
be
desired
for
some
more
creatures.
R
The
reason
is
that
one
of
the
reason
to
use
the
type
5e
signal
distribution
is
to
so
that
you
don't
have
to
run
another
set
by
you
can
just
use
a
VPN
set
back
to
signal
your
nursery
this
unica's.
Now,
if
you
start,
you
want
to
use
a
new,
you
use
the
multicast
VPN
sapphi
to
follow
market
reports,
this
kind
of
defeats,
the
purpose
of
that
one
Ally.
B
The
a
VPN
rata
five
unique
s
and
using
the
for
the
setting
of
the
MVP
and
tunnels,
so
that
is,
as
you
may
know,
has
also
been
captured
in
the
a
VPN
MVP,
an
interrupter,
so
some
of
it
is
overlapping.
So
I
haven't
gone
through
your
draft
to
see
exactly
the
extent
of
the
overlap.
What
I'm
sure
you
are
aware
away.
I
R
B
That
for
some
use
cases
when
you're
talking
about
they're
just
pure
l3,
you
are
specifying
the
use
case
for
that.
So
I
think
we
need
to
have
some
chat
of
mine.
Sure.
G
Okay,
what
about
nokia
ya
know
I,
just
wanted
to
to
comment
on
what
Ali
said.
I
think
this
is
a
very
nice
trap,
because
it
basically
codifies
the
all
the
different
solutions
that
we
have
in
a
multicast
for
a
VPN
right,
but
really
the
option
one
and
two
are
specified
somewhere
else.
Where
is
it?
The
only
new
thing
is
the
option
three
right,
but
you
are
going
to
talk
about
now.
Yeah
thanks.
R
Right
so
we
mentioned
that
this
option
2
may
not
be
desired
for
some
repeated
operators
because
they
didn't
want
to
run
another
set
by
and
so
the
options
3
is
that
we
adapt
the
ARP
6514
procedures,
but
instead
of
using
the
MCAS
VPN
server,
we
use
immediately
in
self
I.
Here
are
listed,
so
the
route
types
in
for
M
VPN
in
6514.
R
R
So
if
you
have
an
operator
who
really
wanted
to
use
nursery
VPN
signal
by
evpn
type
5-
and
they
really
don't
want
to-
you-
can't
use
another
set
by
then
and
just
want
to
keep
using
eBay
being
set
by
for
the
signaling,
then
we
can
kind
of
reinventing
the
wheel,
basically
just
signaled
all
the
procedures
that
is
already
defined
in
our
65
to
514,
just
signally
using
evasion,
SFI
manin
time.
We
do
have
some
enhancements.
R
R
That
thus
America's
routes,
the
that
could
now
now
once
we
do
it
in
using
SME
routes,
then
we
can
introduce
a
optional
leaf
tracking
that
is
not
defined
in
the
6514,
but
it
was
mentioned
in
another
draft
and
also
currently
SML
routes
are
not
targeted.
They
are
just
flooded
at
all
the
PE,
seeing
a
pattern,
priests
domain.
When
we
use
it
for
the
layers
of
idiomatic
us,
then
it
could
be
contacted
for
optimization
again.
R
So
we're
just
right
now
we're
just
taking
comments.
We
will
add
more
details
about
specification,
so
the
draft
has
an
introduction
section
that
talks
about
those
scenarios
and
options
and
then
of
make
the
profile
for
specification.
We
need
to
have
some
normative
texts
about
details
and
we
will
add
those
and
we,
after
a
couple
more
round
the
revisions
or
discussions
at
that
time,
would
or
second
option.
L
You
know
campus
energy
between
seamless
entrap,
that
that
we
are
presenting
and
then
one
that
you
are
presenting,
so
the
one
difference
is
with
the
seamless
entrap.
We
are
just
using
a
median
signal
everywhere.
The
one
you
are
presenting,
we
are
just
trying
to
use
EVP
me
everywhere,
including
in
the
network,
is
that
correct
way
of
interpreting
your
work.
R
A
Okay,
so
now
it's
time
for
a
more
open
discussion,
so
we
had
to
comment
on
the
mailing
list,
pointing
that
the
RFC
5549,
which
is
dealing
with
IP
for
analyzed,
carried
over
with
an
ipv6
next
up.
So,
for
example,
a
VPN
before
our
querido
with
96
next
up
does
not
follow
really
the
same
encoding
flavor
that
we
are
using
for
the
TLD
for
charitable
ipv4
next
up.
A
So
this
triggered
a
kind
of
interesting
discussion
on
the
list.
I
have
tried
to
wrap
up
different
points
that
have
been
raised
and
then
yeah.
It
will
be
time
for
an
open
discussion
if
we
need
to
do
something
or
not
on
this
on
this
topic.
The
first
thing
is
that
the
RFC
5549
is
really
clear
about
I
wish
would
encode
the
next
up.
So
there
is
no
how
to
distinguish
our,
so
we
are
just
yeah
ipv6
address
that
should
be
encoded.
A
Of
course,
this
creates
a
kind
of
inconsistency
compared
to
what
we
have
done
for
VPN
before
with
ipv4
next
up
and
VPN
v6
with
ipv6.
Next
up,
it
is
clear
that
we
have
distinguished
a
is
not
something
that
is
really
a
relevant
for
our
next
step
because
just
create
a
uniqueness
from
genera
hi,
but
for
our
next
stop
it
does
not
really.
It
does
not
really
make
sense.
A
A
The
other
point
is
that
we
also
have
some
analyze
that
make
how
a
multiple
ipv6
next
up,
so
one
which
is
using
the
global
address
and
the
other
one,
which
is
the
link
local
address,
and
there
was
a
question
about
which
one
which
should
use
and
is
it
causing
some
implementation,
unknown
or
interoperability
issues.
And
the
last
point
raised
is
that
in
terms
of
implementation,
how
do
the
implementation
are
dealing
with
next
up
today?
A
So
are
we
checking
the
next
plans
to
know
if
it's
an
IP,
v4
next
up
or
IP,
fro
plus
and
the
next
up
our
ipv6
next
up
and
so
on?
So
plenty
of
questions,
so
I
have
tried
to
do
a
kind
of
inventory
of
some
of
the
areas
that
we
have
invested
to
know
exactly
how
we
are
doing
the
encoding
and
is
the
specification
telling
that
we
should
do
a
kind
of
next
up
length
check.
A
So
I
will
let
you
read
it
off
and
if
you
have
some
some
comments
about
it,
but
what
we
see
is
that
the
only
inconsistency
that
we
have
today
is
really
with
this
a
VPN
style
encoding
of
next
up.
So
RC
4364
and
46
59
against
this
55
for
tonight,
which
is
using
just
for
now
the
ipv6
and
without
a
hard
distinguish,
are
otherwise.
We
don't
really
have
any
inconsistency
in
them
of
income
of
encoding.
A
So
Hobart
has
proposed
and
the
idea
is
to
do
a
kind
of
implementation
survey
on
how
the
next
step
passing
is
the
North
to
debate
on
implementation.
So
I
was
speaking
about.
The
I
will
show
that
implementation
today
are
checking
the
next
up
plans
field
to
ensure
and
to
infer
what
kind
of
next
up
T's
are
dealing
with.
If,
yes,
is
it
done
for
all
the
FS
Fe,
so
it's
kind
of
generic
code,
or
is
it
just
done
for
a
few
of
our
sessions
that
we
have
defined
and
I'll?
A
Do
our
implementation
today
deal
with
the
case
where
we
have
two
agencies
next
up
anchor
D,
so
this
is
globally.
What
is
a
what
the
discussion
is
about
so
yeah,
it's
an
open
mic,
so
I
don't
know
if
someone
has
something
to
say
about
the
subject.
So
the
first
thing
is:
are
we
aware
about
some
implementation
issues
or
not
Jeff,
something.
J
Jeffires
I
don't
actually
know
on
a
specific
basis.
I
just
know
that
this
detail
pops
up
pretty
much
any
time.
Somebody
makes
a
new
implementation
and
ends
up
being
some
form
of
inter
a
problem.
It's
one
of
the
common
details.
People
are
just
going
to
get
wrong.
It's
inconsistent.
The
justification
back
in
25,
28
58
were
no.
The
same,
family
obviously
isn't
getting
followed.
I
think
it's
just
sort
of
a
long-term
fallout
from
we
did
multi-protocol
bgp.
J
We
had
to
figure
out
what
the
rules
looked
like
at
the
time,
and
next
stop
was
one
of
the
things
that
wasn't
quite
gotten
right
like
there
was
no
lingering
thing
in
there
very
original
version
of
the
spec
for
a
subnetwork
point
of
attachment
thing,
which
you
know
I
as
I
asked
people
recognized
or
our
site,
people
recognized,
but
never
really
got
used,
and
when
they
read
the
spec,
they
got
rid
of
that
piece.
So
I
think
for
actual
spec
stuff.
John
Scudder
would
be
a
better
person.
J
A
J
J
What
I
suggest
is,
after
the
survey
is
complete
and
we
have
no
confirmation
that
people's
implementations
really
are
doing
what's
in
the
spec,
because
that
sometimes
is
not
the
case
that
we
figure
out
what
behavior
we
would
like
to
carry
forward
and
do
the
necessary
update
to
20.
You
know
what
was
2888
a
member
of
the
current
RFC
number
is
and
carry
that
for
it
in
all
further
specs.
P
P
If
for
some
reason,
you
really
want
to
take
this
out
and
the
offs
people
want
to
take
this
out
and
do
this.
I
can
of
course,
use
my
other
hat
and
survey
cool
stuff
on
Survey
Monkey
to
create
a
one
page
survey
on
this.
If
it's
useful
I
can
do
it.
That
was
what
I
said
on
idea.
So
we've
done
ID
our
list.
I
can
give
you
better,
because
we
really
do
need
this
to
know.
P
If
we
can
do
things
that,
maybe
we
should
do
in
the
future
that
might
help
our
tunneling,
like
Laird
next
tops
or
nested
tunnels,
which
is
some
of
the
questions.
I
was
trying
to
ask
the
genève
foxes.
Are
we
gonna
get
into
nested
tunnels?
What
sort
of
things
you
have
there
good
stuff
I
don't
know
so,
plus
one
on
the
survey
+1
on
IDR
doing
and
if
you
want
me
to
do
something
better,
let
me
know:
ok,
thank
you.
Yeah.