►
From YouTube: IETF114 BESS 20220725 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Yeah,
hello,
everyone
welcome
to
the
best
working
group
meeting.
My
name
is
the
disembodied
voice.
You
hear
coming
from
the
speaker.
Speakers
is
matthew
bocce.
My
chair,
co-chair
of
stefan
lekowski,
is
aware
at
the
moment.
So
man
commander,
our
secretary,
has
kindly
agreed
to
sit
at
the
front
and
help
run
the
meeting.
B
B
And
we've
also
been
asked
to
remind
you
of
the
the
itf's
mask
policy,
so
participants
in
sessions
and
other
itf
control
rooms
are
required
to
wear
ffp2,
equivalent
or
ffp3,
equivalent
or
locally
certified,
equivalent
masks
and
there's
the
exceptions
being
for
the
chairs
or
presenters
who
are
actively
speaking.
Participants.
Making
comments
or
asking
questions
from
microphones
are
expected
to
remain
masked
and
there's
a
link
on
the
slide.
If
you
would
like
to
have
a
look
at
the
covered
measures
at
the
meeting.
B
So
this
is
the
agenda.
One
change
from
the
published
agenda
mahesh
couldn't
make
it,
I
believe
so
we'll
be
skipping
over
his
slot.
B
Thank
you
so
now
we're
going
to
the
status
update
part
of
working
group
status,
update
part
of
the
meeting.
We
have
two
new
rfcs
published
since
the
last
ietf
9251,
which
is
igmp
mldp
by
mld
boxes
for
evpn
and
9252,
which
is
the
bgp
overlay
services
based
on
segment
routing
over
ipv6.
B
We
have
two
documents
in
the
rfc:
editor's
queue
the
evpn
bomb
procedure
updates,
which
has
a
misref
it's
held
for
a
misrep
on
the
evpn
aggregation
label
draft
and
the
evp
evpn
optimized
ingress
replication
draft,
which
is
waiting
on
the
bond
procedure
updates.
B
B
C
Yeah
thanks
matthew,
just
a
little
bit
of
an
update
from
my
side-
apologies
that
there
are
so
many
of
them
during
the
80
changeover.
Obviously
I
inherited
some
of
these
things
that
I'm
kind
of
going
back
on,
which
takes
a
little
bit
of
time.
I
am
following
up
on
these
and
hoping
to
move
them
through.
B
Yes,
please.
Please
respond
to
any
any
questions
from
from
andrew
your
comments
as
quickly
as
you
can.
He
does
have
quite
a
lot
of
drafts
with
him
and
that's.
We
did
push
quite
a
lot
out
over
the
last
year
or
so.
B
Okay
documents
under
shepard's
review
the
redundant
multicast
source
draft.
There
were
some
comments.
I
think
man
commander's
shepherding
that
and
he
provided
some
comments
and
he's
gonna
do
the
write-up.
B
Once
all
the
comments
have
been
discussed
and
closed,
the
evpn
multi-homing
pa
draft
stefan
has
provided
a
chairs
review
and
we're
waiting
for
a
write-up
from
stafford
on
that
draft
ietf
best
evpn
geneve
is
kind
of
moving
forward
a
bit
now
that
we've
also
been
moving
forward
with
the
evpn
applicability
draft
in
the
nvo3
working
group
and
that's
waiting
for
write
up
from
me.
B
The
evpn,
fast
dft
recovery
draft
again
is
waiting
for
a
shepherd's
write-up
from
me,
and
the
reason
for
the
delay
in
that
is
that
we
had
a
very
it
took
us
a
very
long
time
to
gather
all
of
the
ipr
responses.
So
this
is
kind
of
a
plea
from
the
chairs
and
everybody's
work.
That's
working
as,
and
volunteering
at
shepherds,
please
respond
to
the
ipr
requests
in
a
timely
manner,
because
we
cannot
move
the
drafts
forward
until
we
have
heard
from
you
one
way
or
another
about
ipr.
B
Evpn
unequal
load
balancing
is
waiting
for
write
up
from
stefan
the
evpn
ipvpn
interworking
draft.
So
there's
been
some
discussion
on
the
list
this.
This
is
in
working
group
last
call,
and
there
is
comments
from
one
of
the
idr
chairs
on
this,
and
these
need
to
be
resolved.
We
think
so
there's
some
actions
on
the
on
us
as
the
best
chairs
and
on
the
authors
and
to
get
together
with
the
ideal
chairs
to
sort
this
out.
B
The
evpn
split
horizon
draft
the
comments
that
were
on
the
list
appear
to
have
been
addressed
and
that
we
think
that's
ready
to
move
to
the
next
stage.
Now.
B
Currently,
we
have
one
document
where
the
authors
believe
it's
ready
for
working
group
last
call,
and
I
know
that
this
is
the
bgps
d1
usage
draft.
I
I
know
that
we
had
this
on
the
list
to
be
last
called
as
well
at
the
last
itf
I
apologize
for
the
delay
of
this
we've
been
deliberately
holding
back
a
little
bit
because
of
the
large
number
of
drafts
that
we
had
already
sent
to
our
ad
to
give
them
time
to
process
those.
B
I
think
we're
going
to
start
moving
forward
with
some
more
working
group
last
calls
and
adoption
calls
after
this
itf.
So
so
please
look
out
for
that.
B
Okay,
I
took
this
is
a
list
of
the
non-expired
working
group
documents
that
we
have
on
the
data
tracker.
I
think
at
the
next
itf
I'm
not
going
to
go
through
all
of
these
one
by
one.
Just
a
couple
of
comments.
The
the
multicast
controller
draft
there's
been
some
discussion
around
how
this
aligns
or
doesn't
with
the
with
some
other
drafts
in
the
idr
working
group
for
tree
sid
signaling,
and
we
we
need
to
go
back
and
look
at
that
draft.
B
The
huge
bgp
dmz
draft
was
recently
adopted.
The
the
multicast
flow
df
election
draft.
That's
going
to
expire
soon,
so
authors,
please,
could
you
just
refresh
the
draft
to
keep
it?
If
you
want
to
keep
it
going
there?
I
think
there
may
be
a
few
other
drafts
that
have
expired.
If
you
wish
to
keep
your
drafts
going
moving
forward,
please
remember
to
refresh
them.
B
Otherwise,
your
your
working
group
chairs
are
getting
a
bit
old
and
we
will
forget
about
them
quite
easily
the
young
models.
We
had
an
inquiry
about.
What's
going
on
with
the
young
models
generally
due
to
to
kind
of
lack
of
lack
of
interest
in
these
and
the
amount
of
other
work,
the
working
group
had
we
we've
put
kind
of
put
these
on
hold.
That
decision,
obviously
is,
is
you
know
we
can?
We
can
review
that
if
we
have
some
authors
that
are
interested
in
in
driving
those
forward.
B
Okay,
just
to
onto
the
working
group
slot
presentations
now
just
to
know,
because
this
is
a
hybrid
hybrid
meeting,
the
chairs
will
mostly
be
or
displaying
the
slides.
If
anything
goes
wrong,
I
think
man
come
on
is
going
to
try
and
pick
up
in
the
room.
A
So
there
are
two
drops
first,
first
one
of
the
draft
per
flow
df
election
that
is
going
to
progress
by
next
ietf.
So
we
were
waiting
on
ignp
proxy
to
become
rfc
because
it
uses
that
draft
on
that
rfc
now
and
the
second
one
extended
evpn
optimized
ir.
So
today
morning
I
was
talking
to
when-
and
this
is
ready
for
working
group
last
call
so
we'll
move
it
into
the
queue.
B
Okay
thanks
man
commander,
if
you
can
add
it
to
the
list
on
the
on
the
the
wiki
that
would
that
would
help
us.
Thank
you.
D
Okay,
so
this
presentation,
this
draft
is
about
transports
ip
payload
or
udp
payload
owning
in
an
ipvpn.
The
draft
started
with
a
pseudowar
as
a
pseudo-arrived
draft,
and
it's
just
recently
rehomed.
D
D
We
refer
to
it
as
the
instrument
vpn.
D
The
vpn
is
used
just
so
that
a
converged
transport
infrastructure
can
be
used
for
both
mobile
and
non-mobile
radio
transportations.
I
have
a
picture
at
this
end
added
at
the
bottom.
We
can
see
the
genome
b
on
the
left
side
and
the
upf
on
right
side.
Those
are
the
3gpp
and
network
functions
they,
the
gdpu
tunnels,
are
between
the
genome
b
and
upf,
and
that
is
transported
in
the
n3
vpn
and
so,
and
we
have
the
pes
there
to
support
the
vpn.
D
D
Finally,
the
ip
header
and
most
likely
ipv6
header
nowadays,
but
the
package
gets
to
the
pe
one
in
that
n3
n3brf
and
then
to
transport
it
over
that
infrastructure.
A
label
stack
or
an
under
srv6
header
is
proton.
So
now
and
that's
in
addition
to
the
original
ipv6
udp
and
gdp
header
when
it
gets
to
pe
2
that
additional
label
stack
or
srv6
header
is
taking
off,
and
you
expose
the
original
ipv6
udp
and
gdp
header
this.
What
we
I
call
it:
the
mpos
transport,
king
gdp
or
srv6
transport
in
gdp
next
slide.
Please.
D
There
is
a
draft
in
the
dmm
working
group
talking
about
using
srv6
to
replace
gdp,
so
this
will
cause
srv6
replacing
gdp,
not
transporting
gdp
that
is
actually
still
based
on
the
3gpps
n2n4
signal
the
gdp
parameters,
so
that
replacement
is
down
under
the
hood.
As
far
as
3gpp
is
concerned,
everything
is
as
usual,
but
now
under
the
food,
a
gtb
tunnel
is
replaced
by
srv6
and
that
sr6
is
could
be
directly
between
the
network
functions
or
it
could
be
just
between
the
gateways
attached
within
those
network
functions.
D
The
gdp
traffic
is
reconstructed
at
the
end
and
three
weekend
piece,
you
you,
the
ipv6,
header,
udp,
header
and
gt
header,
is
replaced
with
the
srv6
header.
D
This
is
acceptable
to
some
operators,
because
all
these
elements
are
under
the
same
control
operator
control.
So
the
advantage
of
this
is
that
with
sr
you
can
do
the
traffic
steering
and
you
can
do
a
service
function.
Chaining,
all
those
wonderful
things
and
by
the
way
there
is
also
bandwidth
savings.
Now
you
don't
have
the
two
two
ipv6
headers
and
things
like
that.
D
D
When,
when
when
that
happens,
the
g
information
in
the
gdp
header
is
moved
into
the
srv6
header
and
now,
if
your
operator
wants
to
do
this
and
you
are
but
your
mpos
operator
and
then
what
could
happen
here
is
that
instead
of
using
srv6,
you
use
a
label
stack
and
but
you
transport,
the
gdp
header
and
the
gtp
payloads.
As
is
you?
Don't
you
don't
need
the
original
ip
header
or
the
udp
header
anymore?
D
Now,
with
this
you
can,
especially
if
you're
doing
an
sr
mpos,
you
can
have
all
those
wonderful
advantages
of
the
sr
traffic
steering
and
the
service
chaining
all
those
things,
but
now
it
comes
with
even
more
bandwidth
savings.
Now
you
you
do
not
need
a
ipv6
header
at
all.
All
you
need
is
a
label,
and
then
label
will
tell
the
receiving
router
to
reconstruct
the
entire
iv
header,
including
the
udp
header,
based
on
the
information
associated
with
that
label.
D
Oh
okay,
I
guess
I
already
talked
about
this.
The
the
the
inner
label
in
the
stack
basically
tells
the
ingress
router
to
reconstruct
the
packet
ipacket
with
the
information
associated
with
that
label,
so
that,
essentially,
is
a
pseudo
wire
that
transports
udp
payload.
Only
a
control
work
will
be
used
to
prevent
transient
routers
from
mistaking
the
payload
as
ip
next
slide.
D
That's
why
the
the
draft
was
originally
put
into
the
as
a
piles
working
group
as
a
pseudo-wire
draft,
but
after
we
start
working
on
the
signaling
details,
we
realize
that
this
can
be
generalized
to
transport
ipvpn
traffic.
D
Without
considering
that
pseudo
wires-
and
so
it's
it
is
applicable
as
long
as
the
traffic
are
mostly
among
certain
codes
in
the
in
the
early
use
case,
it's
really
among
the
5g
network
functions
and,
and
also
it
means
that
it
needs
to
the
operator-
needs
to
accept
that
the
traffic
the
package
will
be
reconstructed
by
the
transit
devices.
D
If
that
is
not
acceptable,
then
our
bets
are
off.
So
I
want
to
point
out
that
in
in
this
ip
ipvpn,
the
traffic
can
be
transported
in
many
ways.
Some
traffic
could
be
transported
the
traditional
way
with
original
ip
and
the
udp
header
or
whatever
header
some
traffic
will
be
transported
with
just
iv,
header
removed
and
some
will
be
transported
with
both
ip
and
udp
header
removed.
Next
thing,.
D
Then
the
routes
will
be
identified
by
the
egress
pe,
let's
say
the
and
then
based
on
the
advertisement.
The
egress
key
would
create
a
forwarding
state
so
that
incoming
traffic
with
that
corresponding
label
will
be
reconstructed
with
the
ip
header
and
if
you
advertise
the
wildcard
or
address
or
wildcard
udv
port
or
things
like
that,
then
you
have
to
use
the
locally
configured
source
address
or
the
source
udp
port
and
the
ingress
pe.
D
So
appreciate
comments,
and
one
one
question
here
is
just
that:
do
we
want
to
consider
other
ip
payload
types,
not
just
udp
things
like
that.
D
Indeed,
the
use
case
started
with
a
5g,
but
I
think
I
alluded
to
in
one
of
the
slides
this.
It
will
be
generalized
to
any
use
case
where
the
traffic
is
mainly
among
certain
hosts
and
when
it
is
acceptable
for
the
package
to
be
reconstructed
by
transit
devices.
As
long
as
you,
those
two
conditions
are
met,
and
then
it
can
be
used
beside
beyond
5g.
F
F
D
Yeah,
okay,
so
I
use
the
5g
example,
but
lte
or
even
3gs
is
that
it's
basically
the
same
thing.
It's
you
you
use
in
the
gtbo
tunnel
among
the
network
functions
I
use
the
5g
terms,
but
lte
will
be
the
same.
Basically
any
situation
where
you
have
ip
traffic,
mainly
among
a
set
of
hosts-
and
you
can
it's
okay
to
reconstruct
the
package.
F
A
Can
we
take
some
of
the
question
to
the
list?
I
think
horizon
q.
G
D
So
the
in
the
initial
use
case
there
is
the
we
have
the
n3
vpn
right.
So
this
has
been
started
with
the
use
case
in
the
vpn
and
it's
natural
to
use
the
raw
distinguisher
and
raw
target
things
like
that,
and
of
course
it
can
be
extended
to
the
global
table
as
well,
and
indeed
there
are
some
discussions
on
whether
or
we
should
use
rdo
rt
for
the
global
table.
D
But
at
least
in
my
view
using
our
rdrt
for
our
for
global
table
could
be
argued
as
a
feature
instead
of
a
bug
and
but
I
think
that's
a
different
discussion,
but
indeed
at
least
if
we
only
focus
on
vpn
scenario,
then
using
rd
and
rt
is
is
natural
and
it's
required
here.
It's
you
know,
basically
we're
basically
doing
ipvp,
and
it's
just
that
we
only
transport
the
payloads
in
with
this
optimization.
Okay,.
G
So
you
could
use
the
the
safy
without
or
with
a
zero
raw
distinguisher
and
no
rough
target.
I
guess.
D
Okay,
so
this
presentation
is
about
an
old
draft
accuracy
even
before
the
pandemic.
I
will
not
go
through
the
content
of
this
draft.
I
mainly
want
to
to
refresh
that
there
is
this
draft
we
didn't
do
it
was
thought
before,
but
I
think
we
want
to
to
move
this
forward
now.
So
I
have
some
background
information
to
provide.
D
So,
basically,
to
go
to
fix
or
enhancements
some
mvpn
or
evpn
c
multicast
route
aspects,
the
c
multicast
routes
in
mvpn
and
evpn.
They
basically
carry
customer
multicast
states,
for
example,
mvpn
type,
6
and
7
and
evp
type
6.
it.
It
is
started
as
a
mvp
term,
but
generalized
to
cover
evpn
s
method
as
well.
D
It
was
initially
presented
in
the
itf
96.
I
included
the
the
slides
and
the
youtube
link
there
later
it
was
presented
again
in
iit
104,
with
additional
content
on
the
mvpm
interiors
homing
situation
again
slides
and
the
youtube
links.
Are
there
that's
right.
D
This
is
basically
a
snapshot
from
the
table
content.
It
talks
about
five
situations,
five
issues
there
to
be
enhanced
or
to
be
fixed
next
slide
materials.
Oh
okay,
all
right,
so
the
work
has
been
stalled
since
2019,
so
many.
The
main
reason
is
that
the
issues
and
the
enhancements
were
a
bit
ahead
of
the
time
at
that
time,
and
also
we
can
blame
the
pandemic.
D
I
hope,
but
now
it's
time
to
move
forward,
in
particular
one
of
the
issue
there
about
interiors
propagation
of
mvpnc
multicast
routes
that
addresses
a
main
problem
in
this
new
draft
from
from
huawei,
we
had
a
long
email
discussion
in
the
mailing
list,
and
I
see
he
has
a
a
presentation
at
the
end
of
this
session.
D
Unfortunately,
I
need
to
swi
run
to
another
session,
so
I
won't
be
able
to
comment
there,
but
there
is.
There
has
been
a
discussion
on
the
mainland
for
a
long,
long
long
list,
long
discussion.
If
you
go
through
the
next
slide,
I
included.
I
think
I
included
a
link
here.
D
So
basically,
I
would
like
to
move
forward
with
this
document
and
I'd
like
to
say
to
put
put
this
into
that
option
queue.
I
don't
think
we
need
to
re
repres
represent
this
draft
here.
I
have
included
links
from
from
before
and
please
review
and
then
join
the
discussion
on
that
is
happening
between
me
and
the
panhung
on
this
new
draft.
Here.
H
Hear
me:
yes,
we
can
I'm
from
huawei
hi
jeffrey.
I
have
a
explanation,
as
I
explained
in
the
early
part
of
the
main
list
of
my
document.
The
objective
and
the
solution
of
my
document
to
be
present
later
is
different
with
what
you
have
talking
talking
about
talk
about
in.
D
D
We
had
quite
some
discussion
there,
so
I
guess
we
need
to
convince
each
other
which
way
is
better
or
if
we
should
do
both
solutions
or
whatever.
D
B
So
gun
I
know
you
have
about
30,
slides
here
and
10
minutes.
Can
you
try
and
heaps
of
the
key
slides?
Please
and
just
please
ask
me
to
to
move
on
when
you're
ready.
J
J
So
that's
that's
the
initial
bcp
draft
that
was
adopted
in
april
21
and
then
that
second
draft
is
an
all
sappy,
so
that
supports
all
sappies,
and
then
we
have
another
kind
of
corresponding
draft
which
is
related
to
v4,
so
it's
an
ipv4
only
p
design
and,
and
that
relates
to
the
bcp
proof
of
concept,
testing
similar
to
the
v6,
only
p
design
and
then
the
and
then
the
subsequent.
The
last
draft
is
an
all-safy
related
to
the
before
only
pizza
next
slide.
J
J
Proof
of
concept
of
being
able
to
do
ipv6
only
peering,
and
it's
really
focused
on
three
saffies
unicast
safety
and
then
safety,
128
and
129
for
vpn
mvpn,
the
last
the
next
draft,
the
ipv6
only
all
safy
draft,
so
that
focuses
on
all
on
all
saffies
and
it's
really
broken
up
it.
All.
J
The
iana
sapphies
are
really
broken
up
into
three
categories:
it's
so
where
you
have
control
plane,
data
plane
in
line
so
like
a
pec
appearing
or
inner
asp
to
pe
peering,
and
then
the
third
category
is
a
controller
based
peering,
but
basically
all
saffies
are
supported
with
that.
Second
second
draft
next
slide.
J
So,
as
far
as
updates
on
the
on
the
ipv6,
only
pe
design
now
we've
we
have.
J
We
have
confirmed
that
all
all
vendors
us
says
both
cisco
juniper,
nokia
and
arista
and
huawei
sorry,
excluding
the
rest
of
cisco
junior
from
nike
and
huawei
support
the
there's,
a
vendor
pacific
knob,
that's
required
for
this
and
we'll
kind
of
get
into
that
in
detail
a
little
bit
that
requires
that
is
required
to
allow
v4
forwarding,
with
a
with
a
without
a
v4
address
configured
only
on
the
box,
so
that,
and
we
will
dig
into
that
a
little
bit
in
detail.
J
So
with
this
draft.
As
far
as
testing
goes
up
so
cisco,
juniper
nokia,
we're
planning
to
complete
all
the
proof
of
concept
testing
by
the
end
of
the
year,
we'll
have
that
all
documented
in
the
in
that
draft
and
then
arista
and
huawei
were
still
pending
on
on
on
getting
the
the
eta
of
completion
huawei.
The
plans
are
sometime
in
2023
to
complete
tesla
next
slide.
J
J
The
first
draft,
similar
to
the
v6
only
p
design,
is
a
focuses
on
three
sappys,
just
the
unicast
sappy
and
then
the
vpn
and
mvpn
sappy,
and
then
the
v4
only
p
design.
All
staffing
focuses
on
all
all
sappys
and
with
the
same
three
categories
of
inner
aspiring
edge,
pce
peering,
as
well
as
a
controller-based
periods.
Next
slide.
J
So
with
this,
so
at
a
list
here,
just
scope
and
benefit
so
I've
listed
here
just
the
benefits
of
of
the
ipv6,
only
p
design
and
what
I've
added
in
here.
It's
just
kind
of
breaking
up
the
three
categories
that
so
of
all
the
saffies,
so
you've
got
the
pc
edge,
peering,
interac,
peering
and
control
appearance.
J
It's
just
kind
of
focusing
on
those
three
and
that's
what
we'll
be
discussing
in
the
next
few
slides
of
how
that
how
that
plays
and
a
big
gain
is
really
the
opex
savings
here
and
that's
where
I
bolted
in
red
at
the
bottom
on
the
next
slide.
J
So
that's
in
this
next
slide.
The
difference
here
is
this:
is
the
v4
only
p
design,
so
the
same
scope
and
benefits?
The
only
difference
here
is
with
the
with
the
benefits.
Is
you
you
do
have
an
additional
possible
capex
savings
that
you
now
you
you
don't
necessarily
have
to
actually
migrate,
your
underlay
to
a
v6.
J
J
So,
with
with
the
actual
v4,
only
pd
design,
the
the
vendor
pacific
knob,
so
that
really
the
big
thing
I
wanted
to
kind
of
mention
here,
so
both
the
v4
only
p
design
and
v6
only
design
the
vendor
specific
knob.
It
allows
for
for
v4.
Only
p
design
allows
v6
processing
to
work,
just
as
you
would
have
normal
dual
stack,
but
without
having
a
v6
address
configured
on
the
interface.
So,
basically
the
interface
acts
as
a
layer,
3
interface,
normal
layer,
3,
hot
processing.
J
Everything
is
actually
works
exactly
the
same,
but
you
just
don't
have
a
v6
address
and
that's
where,
where
that
knob
comes
into
play,
so
100
same
functionality
that
you
would
normally
have
with
the
layer,
3
interface,
pinging
and
tracing
works.
Exactly
the
same,
the
one
caveat
is
you:
have
you
require
a
loopback?
The
loopback
address
interface
requires
a
v6
address
on
there
and
that's
just
for
the
icmp
to
work
properly
from
the
pe
everything
else.
Ipx
fpfix,
qos
acl,
any
interface
related
command.
J
Everything
else
related
to
v6
works
identically,
as
it
would
with
a
standard
dual
stack
architecture
with
so
with
the
v6.
Only
pe
design,
everything
is
exactly
the
same
as
far
as
the
functionality
of
basically
providing
the
same
with
the
vendor
pacific
knob
for
v4
processing
without
v4
address
configured
on
the
interface
next
slide.
J
So,
with
the
v4
only
p
design,
one
one
thing
I
wanted
to
talk
through
in
this
slide
is
the
next
hop
encoding
standardization,
so
rfc
4798.
I'm
sorry.
J
J
J
So
with
the
rfc
4798
and
rfc
4659,
they
define
a
the
next
top
encoding
is
a
ipv
ipv4
mapped
ipv6
address
so
with
ip
with
rfc
5549
and
then
updated
with
rfc
8950,
the
the
next
top
encoding
for
ipv4
noi
over
an
ipv6
next
top
is
not
a
v4
mapped
ipv6
address,
but
it's
a
it's
a
v.
It's
a
v6
address,
so
16
or
32
byte
for
sapi,
one
two
and
four,
and
then
for
sapi
128
129,
it's
24
and
48.,
so
similar.
J
So
in
the
industry,
the
implementations
have
have
moved
away
from
what
was
defined
in
rfc
4798
in
4659
related
to
the
ipv4
map.
Ipv6
address
using
a
a
four
byte
address
for
sapi,
one
two
and
four:
it's
just
a
standard
ipv4
next
stop
address
and
then
as
well
for
safety,
128
129
using
a
four
byte
for
a
a
12
byte
address.
So
four
byte
ipv4,
plus
the
eight
byte
route
distinguisher.
J
J
All
right
so
here
we're
just
going
to
breeze
through
it
and
we
have
a
handful
of
slides,
we're
going
to
go
through,
but
I'll,
just
kind
of
peck
through
this
real
fast.
So
what
here?
What
I've
done
is
I
I've
listed
all
the
saffies
and
they're
just
categorized.
Basically
what
I've
highlighted
cpdp?
That's
where
you
have
inline
control,
plane
data
plane.
So
that's!
Basically,
the
three
categories
are
pec
peering,
nras
peering,
which
falls
in
the
cpdp
category,
where
they're
in
line
and
then
a
controller-based
period
where
it's
cp
only
next
slide.
J
And
then
the
next
two
slides
I
just
kind
of
list
all
in
color
coded,
basically
just
showing
that
all
the
were
supported,
providing
the
same
thing
where
you're
you
have
either
an
ipv4,
only
p
design
or
v6
only
for
the
v4.
Only
you
just
have
a
v4
address
configured
on
the
interface
and
you
can
support
all
all
the
sappys
in
those
three
categories
and
then
say
same
as
well
with
the
v6
on
the
side.
Next
slide,
we
can
skip
through
this
one
go
to
the
next
one,
all
right.
J
So
this
this
slides
just
showing
a
just
basically
two.
This
is
unicast
safety,
just
two
separate
pier.
So
you
got
a
typical
dual
stack
appearing
next
line.
J
So
here
we're
actually
just
now,
we
just
have
a
single
pier,
I'm
in
her
ass,
just
just
showing
this
could
be
pec
or
enter
a
aspiring
where
you
have
a
single
v6
transport,
pier
carrying
a
unicas
safy
next
slide.
J
J
Here's
another
example,
so
this
is
showing
just
the
mcas
tree
safy,
which
I
think
we
talked
about
in.
I
think
in
a
previous
draft
earlier
us
and
then
srte.
J
So
here
we
have
two
two
separate
piers
go
to
the
next
slide,
and
now
we
have
one
pier,
basically,
a
single
v6,
pier
carrying
both
all
three,
so
you've
got
safety,
128
mcas
tree
and
then
srte,
I'm
just
showing
the
benefits
of
how
the
single
peer
now
you're
really
able
to
eliminate
all
that
control,
playing,
having
a
single,
pier
and
then
as
well
and
they've
still
got
that
same
dual
stack
functionality
next
slide.
J
J
And
now
you
have
a
single
peer
so
now,
you've
got
that
same
controller
control,
base
scenario,
controller-based
scenario
in
appearing
to
a
pc
or
sdn
controller
or
bgp
controller
bgpls
for
your
northbound.
And
then
your
ipv4
rpd
staff
next
slide
this
next
set
of
slides
and
I'm
just
going
to
work
through
these.
But
this
is
basically
doing
the
exact
same
thing,
but
it's
with
the
v4
only
design
and
it
shows
up
the
unicast
sappy.
So
what
I'm
going
to
do
is
I'm
going
to
skip
through
to
the
very
end
and
then
just
ask
any
questions.
J
But
the
next
set
of
slides
are
the
exact
same
functionality
and
the
exact
same
slide
deck.
But
it's
really
just
showing
the
it's
showing
the
functionality
where
we're
actually
doing
a
dual
stack
and
then
we're
showing
the
single
pier.
So
we
can
just
roll
through
these
so
showing
the
exact
same.
But
now
we're
just
having
a
single
pier
with
with
v4.
Only.
J
Thank
you
any
questions
or
comments,
or
anything
related
to
the
four
drafts
that
I
mentioned.
G
G
So
those
saffies
go
without
es25,
always
as
far.
A
A
F
K
Oh
yeah,
so
I
have
three
drafts
two.
So
there
are
two
new
ones
and
two
which
were
presented
in
itf
113,
the
last
one
so
attended
to
a
few
comments,
but
these
are
the
two
ones
which
were
written
in
between
13
and
14,
so
yeah
next
site,
please
I'll
I'll,
just
go
over
the
the
next
one.
I
mean
it's
okay
to
skip
this
one
yeah
yeah.
K
So
the
background
of
this
extension
of
the
lsp
ping,
the
evp
and
lsp,
is
all
about
the
comments
which
are
the
queries
which
I
had
for
the
the
base
draft
for
the
evpn.
I
I
believe
this
is
not
it's
a
working
group
draft,
so
I
mentioned
the
old
name
here.
Just
bear
with
me
on
that.
So
there
were
a
few
queries
which
I
believe
were
sort
of
once
unanswered,
with
respect
to
the
current
evpn
lsp
being
draft.
K
So
as
part
of
that,
so
there
were
two
options:
one
to
include
these
extension
as
part
of
the
initial
drought,
but
the
consensus
or
the
advice
coming
from
the
authors
was
to
it
was
too
late
in
the
cycle
for
that
draft.
So
to
pen
down
a
new
one,
so
that's
the
background
of
how
this
came
to
the
four
four
next
next,
one,
please
yeah.
So
the
queries
were
all
about
three
unique
requirements
here
so
from
so.
K
The
background
here
is
was
was
to
draw
parallels
with
the
management
interface
when
we
are
accessing
the
networking
devices.
Essentially
it
was
about
the
evp
and
nri.
So
from
the
operator
point
of
view,
just
as
in
a
management
interface,
a
partial
index
can
help
fetching,
let's
say
a
bunch
of
entries,
so
essentially
from
the
om
site
from
the
ping
side.
Also,
it
would
be
easy
for
a
remote
oem
access
or
the
om
ping
to
be
performed
with
a
partial
knowledge
of
the
key.
Essentially
within.
K
Let's
say,
if
the
operator
knows
about
a
prefix
which
is,
let's
say,
are
coming
from
one
source
and
there
are
no
dual
sources
known
per
se,
so
in
that
case
all
other
attributes
as
part
of
the
another
evp
and
lri
can
be
forgotten
and
just
the
prefix
or,
let's
say
a
prefix
or
a
mac
and
associated
parameters.
Not
no,
I
mean
the
major
ones
or
the
significant
ones
can
do.
Essentially,
so
that's
that
is
the
ease
of
usage.
That
is
point
number.
K
One
second
thing
which
do
the
attention
was
since
om
is
all
about
validating
both
control,
plane
and
data
plane.
K
Performing
the
validations
for
both
ends,
so
essentially
the
requirement
is
that
in
few
of
the
scenarios
where,
let's
say
the
routing
protocol
is
in
a
churn-
or
there
is
a
convergence
which
is
happening
in
place
in
that
case,
if
the
om
application
is
not
impacted,
then
the
best
bet
is
to
just
do
a
dp
validation
to
ensure
the
data
plane,
validation,
just
to
ensure
the
traffic
flow
won't
be
impacted
per
se
and,
conversely,
the
validation
just
for
let's
say
the
the
protocol
rip
pyramid
against
the
protocol.
K
Rib
information
can
also
help
wherein,
let's
say
there
is
there's
a
possibility
that
the
access
to
the
management
interface
is
denied
for
few
entities,
but
as
a
as
a
network
operator
as
a
or
as
an
administrator
you
need.
So
this
is
one
more
revenue
to
get
fetch
to
fetch
that
information
via
om
to
get
all
the
om
specific
to
get
all
the
control
plane.
K
Specific
entries
for
specific
for
prefixes,
let's
say
which
may
not
have
made
it
to
the
actual
forwarding
database
or
to
the
data
plane
right
so
that
that's
the
validation
type
check
which
which
was
suggested
to
be
introduced.
Third,
one
is
the
reachability
check
to
the
layers
and
vrfs,
as
in
we
all
have
come
across
the
vrs
which
don't
have
any
interface
interfaces
configured
on
them
or
no
subnets
which
belong
to
or
sourced
via
them
there
they
are
sort
of
a
liaison
vrf
wherein
the
routes
are
leaked
into
and
the
routes
are
moved
out.
K
Let's
say
the
fabric
is
the
outside
fabric
is
evpn
and
probably
inside
it's
mpls,
or
vice
versa.
I
mean
mpls
l3
vpn,
so
in
that
case
it
would
be
good
to
have
a
tighter
control
to
have
this
layers
in
vrf,
wherein
if
the
liaison
virus
is
not
having
any
leaked
routes-
and
let's
say
there
is
no
evpn
tunnel
found
because
of
the
same
reason
for
that,
for
let's
say
the
evi
corresponding
to
that
vrf
per
se,
then
in
that
case
it
would
be
good
to
do
a
health
check
via
om.
K
K
Yeah,
this
is
just
one
way
of
showing
the
overlapping
of
the
parameters
and
left
side
is
control,
plane
and
right
side
is
data
plane.
We
can
skip
this
here
next,
one
please
yeah.
So
this
is
what
I
was
mentioning
with
respect
to
the
layers
in
vrf.
So
we
have
a
border
router
here
in
the
vxlan
fabric,
and
then
you
have
an
mpls
l3
vpn,
inter
fabric
extension
for
l3
extension.
K
For
that
matter,
let's
say
there
is
no
evp
and
dci,
which
is
being
done
here
or
no,
on
the,
inter
in
inter
fabric
can
be
mpls
or
vx,
and
so
for
for
for
the
wide
prevalent
deployment
I
have
shown.
Mpls
l3
vpn
here
so
right
at
the
border.
Router
is
where
the
location
of
the
layers
and
vrf
will
belong
to
as
per
this
example,
and
this
is
where
we
would
need
om
check,
support
for
that
particular
vrf
yeah.
Next,
please.
K
So,
to
solve
this,
there
are
three
tlvs
or
subtitle,
which
is
proposed.
K
First
one
is
the
wildcard
tlv
which
will
carry
a
bunch
of
a
bit
map
which
will
map
to
which
should
map
to
the
list
of
sub
tlvs
carried
in
the
om
om
pdu,
the
mpls
evpn
ping
pdu
to
to
indicate
that
those
fields
or
those
tlbs
are
sort
of
wild
card
or
don't
care
when,
when
the
validation
has
to
happen
at
the
at
the
other
end
at
the
target
end
and
the
in
line
with
that
or
typically
wild
card
and
validation,
tlp
may
go
hand
in
hand
per
se,
so
the
validation
tlv
is
all
about
picking
up
the
mode.
K
K
So
this
is
a
little
description
of
the
wildcard
tlv
and
let's
not
go
with
the
type.
Probably
if
things
expand
more,
I
mean.
Maybe
these
are
long
wrong
descriptions
of
the
type
field,
but
what
essentially
the
sub
tlv
type
indicates
is
the
the
value
I
mean
of
the
corresponding
subtle,
for
which
we
can
actually
extend
this.
I
mean
I
mean
map
this
particular
this
this
this
new
wildcard
dlv,
but
the
the
the
most
important
part
is
the
bitmap.
K
We
need
to
come
up
with
a
bitmap
per
se,
wherein
the
each
of
the
bits
in
this
32
bit
field
will
map
to
or
should
map
to,
one
of
the
subtleties
which
which
are
which
get
carried
in
the
oem
pdu
so
and
the
send
side
and
the
receive
side
are
essentially
the
same
thing
which
I
have
already
explained.
So
we
can
hop
on
to
the
next
one.
K
Validation,
tlb
is
again
an
easy
one
here,
as
I
explained,
what
kind
of
validation
you
want
to
do
with
the
parameters
or
the
tlb
values
which
we
are
carrying
in
the
the
evp
and
lsp
ping,
so
yeah
zero
one,
two
zero
is
the
default
and
one
is
control
plane.
Only
two
is
data
plane
only
yep
and
next
one.
Please.
K
Sure,
yeah
yeah,
okay,
I
think
I
think
this
is
also
I
have
explained
this,
so
this
is
an
explicit
identifier
for
the
evi
or
the
corresponding
fabric
identifier
for
the
evi
to
be
carried
in
this,
which
will
map,
to
the
let's
say,
to
the
vni
or
map
to
the
vrf
on
the
target,
so
target
system
which
is
elias
and
we
are
fpm
and
next
one
please.
I
think
we
are
done
here
so
the
requesting
action
more
traction.
K
F
L
Yes,
I
can,
from
cisco
system
samia
a
couple
of
things
for
you.
First
of
all,
I
went
through
the
draft
and
there
was
a
comment
like
there
were
two
comments
about
the
problem
statement,
which
I'm
not
sure
if
the
problem
is
clearly
mentioned.
To
be
honest,
one
of
them
was
the
nlr
key
is
to
complex
to
remember
on
the
actual
draft
from
barack
jane
that
one.
I
don't
understand,
really
that
prompt
statement
and
the
second
one
you
were
mentioning.
That
is
no
iep
address
available
on
dci.
L
So
therefore
we
need
to
find
out
different
ways
that
one,
neither
I
don't
understand
so
can
I
can.
I
suggest
that
you
that
you
make
sure
the
problem
statement
is
very,
very
clear.
Stated
you
put
a
bunch
of
requirement
on
something
that
I
presume
I
anyway.
I
think
the
problem
itself
is
not
that
clear.
So
that's
number.
L
K
Sure
patrice,
I
hope
you
have
gone
through
the
draft
in
case
the
the
slides
are
not
so
clear.
Yeah.
G
Hi
samia
yeah.
My
first
comment
is
similar
to
patrice's
yeah.
I
didn't
understand
the
justification
about
the
leaking
into
a
vrf
for
the
the
avi
tlv,
so
yeah
I
I
agree
with
patrice.
The
second
comment
that
I
wanted
to
make
is
the
for
the
wildcard
tlv.
G
Basically,
the
draft
allows
you
to
wildcard
any
any
field
of
the
existing
sub
tlvs.
If
I
understood
correctly,
but
I
guess
you
need
to
put
some
limitations
in
the
sense
that
if
you
want
to
paint
a
mac
ip
route
in
the
egress
pe,
at
least
you
you
need
to
specify
the
the
mac
address
right.
So
it
is
not
that
you,
you
can
welcome
any
any
field
right.
So
I
guess.
G
Okay,
so
I
think
those
details
must
be
specified,
and
my
last
comment
is
that
if
you
look
at
the
ayanna
section,
you
are
not
requesting
for
any
code
point
or
anything,
and
you
are
saying
in
the
tlvs
and
sub
tlds
that
could
actually
be
proprietary
and
then
also
I
didn't
understand
if
you
are
writing
a
draft
in
my
mind,
it's
because
you
are
requesting
something
standard
right,
so
I
didn't
understand
that
part
either.
K
K
A
E
K
So
if
you
can
go
ahead
with
somebody
in
room
present
presenter,
then.
E
E
E
E
B
K
Okay
is
it.
Are
you
able
to
see
this.
A
K
We
can
yeah,
so
this
is
about
I'm
marrying
two
pieces
of
the
technology
here,
it's
all
about
the
ip
bindings
with
respect
to
the
network
deployments
where
the
as
in
the
legacy.
There
would
be
a
significant
approval
required
to
let
the
clients
in
I
mean
from
the
in
in
the
network
per
se
right
so
from
that
on
so
the
so.
The
l3
clients
can
also
be
looked
into
via
various
mechanisms,
dhcp
nd
and
thus
and
the
snooping
part
of
it
so
but
the
the.
K
But
these
procedures
are
very
local
to
the
access
side
of
the
network,
wherein
it's
between
the
access
switch
hosting
the
these
ip
bindings
and
requesting
for
the
approval
for
letting
the
the
client.
F
K
Packet
in
with
with
a
specific
credential
which
can
be
mac
addresses,
but
in
case
the
network
is
shared,
is
is
extended
across
the
sites
or
let's
say
there
is
a
potential
of
a
client
moving
between
the
between
the
access
switches
on
the
wireless
controllers
per
se.
Then
there
is
a
need
to
synchronize
this
approval,
which
has
been
granted
at
one
access
switch
to
be
to
be
synchronized
to
all
others,
whether
within
the
fabric
or
outside
the
fabric,
so
bgp
control
at
the
helm
of
it.
K
If
in
case,
we
have
three
vxlan
or
evpn
provision
sites,
and
in
this
case
you
have
I'm
just
coined
them
as
vteps,
and
you
have
host
two
host
one
on
one
of
them
and
these
vlans
are
extended
across
the
sides
per
se.
So
anything
learned
via
snoop,
which
is
moved
up
on
the
access
side
of.
Let's
say
we
tap
one
one,
two
or
let's
say
we
have
one
one.
K
Essentially,
dscp
packets
wouldn't
be
leaked
into
the
fabric,
essentially
or
should
not
be
leaking
to
the
fabric
more
so
we
shouldn't
be
allowing
the
nd
and
the
r
to
be
leaked
over
the
van
pipe
per
se,
so
these
are
the
three
ones,
so
is
local
to
the
client.
As
I
explained
in
data
packets,
which
are
the
dhcp
packets
or,
let's
say
the
relays
or
the
rpendees
essentially
should
be
avoided
and
should
not
eat
up
into
the
van
pipe.
K
The
solution
is
to
synchronized
leverage
the
route
type
to
the
android
mac
advertisement
by
tying
it
to
a
new
extended
community,
which
indicates
that
there
is
a
security
approval
for
this
particular
credential
or
a
bunch
of
credentials
being
carried
in
the
update
messages,
and
it
can
be
on
the
destination
vtep,
which
is
also
an
access
switch
per
se,
all
right
or
as
part
of
the
first
top.
First
stop
router
or
first
stop
switch.
I
shouldn't
say
router
for
stop
switch
for
the
for
the
access
network.
K
It
can
be
synchronized,
so
this
security
approval
or
this
ir
rt2
based
route
publishing,
can
be
appended
with
this
new
extended
community
and
can
be
leveraged
as
a
as
a
approval,
which
has
already
happened
at
the
other
end
of
the
network,
so
yeah.
So
this
is
what
it
is.
It's
a
simplex
solution.
K
It's
still,
I
mean
I'm
not
sure
whether
there
are
any
parallel
solutions
already
in
place
per
se,
as
as
far
as
bgp
control
plane
is
concerned
and
how
it's
dealt
with
at
the
at
the
receiving
side,
how
the
security
application
running
over
there
leverages.
This
information
is
again
implementation
dependent,
but
it's
all
about
carrying
this
information
as
part
of
the
mac
update.
K
I
understand
that
since
it's
extended
community
it
would,
it
would
be
applicable
to
all
the
mac,
ip
updates
which
are
being
carried
there,
but
since
it's
deployed
in
one
campus
and
where
we
expect
every
every
client
to
be
to
be
to
be
sorted
or
to
be
to
be.
K
Allowed
to
be
validated,
I
think
they
should
fall
in
place
yeah,
and
this
is
again
the
client
type
and
there
can
be
a
sync
id
which
can
be
configured
at
all
the
vteps
or
at
all
the
bgp
pairs,
which
can
be
validated
all
across.
So
this
ip
bins,
ip
binding
sync
id
is
nothing
but
a
instance
or
a
security
instance
which
needs
to
be
in
sync
across
all
the
vteps
and
it
can
be
configured
via
the
end
operator
and
it
can
be
double
validated
whether
this
mac
ip
binding
is
for
that
particular
security
instance.
K
So
this
can
be
generalized
for
all
the
fabrics
and
for
all
the
bgp
extensions
for
for
vpn,
and
it
can
also
be
extended,
if
not
in
place
for
other
control,
plane
protocols
like
ldp,
if
they
are
also
being
leveraged
to
provision
the
only
protocols
for
mpls
fabric
yeps,
and
the
request
is
to
for
the
best
members
to
review
this
track.
And
this
is
what
it
is
here.
L
Hey
hi,
I
think
I'll,
have
similar
comment
than
the
previous
draft
make
sure
the
problem
statement
is
very
clear:
it's
not
here
honestly,
so
that
will
be
the
first
things
to
do.
The
second
part,
is
you
you're
putting
a
kind
of
a
grouping
id
on
on
the
assumption?
This
is
more
secure,
but
in
fact
that
google
id
is
not
even
secure,
so
anybody
can
pitch
in
a
number,
so
I
don't
think
you're
making
it
more
secure.
K
L
L
So
you
still
lie
down
to
a
lan
at
the
end,
which
is
usually
your
avi
and
from
ddi
you're
going
to
take
your
you
can
generate
your
raw
targets
based
on
that
and
then
you
can
even
go
with
perhaps
something
similar
to
e3,
where
you
can
have
different
set
of
raw
digest.
That
will
help
you
to
do
that,
but
the
grouping
id
definitely
will
not
help
you
that
much
because
anyway,
you
need
to
you
need
to
import
the
route.
Then
you
need
to
look
at
the
grouping
id.
L
G
Hi
yeah,
my
question
is
yeah.
I
don't
know
if
I
understood
the
draft
completely,
but
if
the
this
binding
id
is
the
allocation
is
really
out
of
the
scope
and
what
you
do
with
it
when
you
receive
it,
it's
it's
also
up
to
the
implementation.
I
was
wondering
if
you
can
use
just
a
regular
community
or
a
large
community
along
with
the
mac
ip
routes
or
anything
like
that,
and
then
you
you
don't
really
need
to
standardize
a
new
extended
community.
I
think,
can
you
comment
on
that.
K
Yeah
george,
so
I
mean
in
this
case
we
wanted
to
tie
it
to
the
mac
ips
only
and
keep
it
restricted,
keep
it
specified,
rather
than
doing
leveraging
the
communities
per
se,
and
we
wanted
to
keep
it.
Let's
say
a
standard
tie-up
in
future
evolution
where
we
can
extend
this
particular
tlv
to
carry
other
parameters
as
well.
Let's
say
the
role
can
also
be
synchronized
in
future
per
se
if
the
bunch
of
updates
can
be
carried,
and
that
is
also
a
part
of
the
security
update.
K
A
new
attribute
or
as
part
of
the
extended
community
yeah,
so
it's
still
in
the
under
evolution,
I
mean
needs
to
evolve
further
to
carry
other
attributes
and
that's
the
answer.
John.
G
Okay,
but
for
the
current
solution
you
could
actually
use
any
communities
really.
K
Yes,
that
can
be
alternative,
but
what
I
meant
to
say
is
we
wanted
to
all.
Maybe
I
should
update
it
further.
Distract
your
point:
don't
it.
K
Nothing
in
here
actually,
this
is
just.
We
have
updated
with
all
the
comments
which
we
got
in
under
vienna,
itf
and
that
has
been
updated.
So
we
so
the
the
all
df
bomb
traffic
was
an
important
one
where
there
were
comments
of
for
the
the
actual
use
case
being
addressed
there,
where
we
wanted
all
the
vteps
in
in
a
segment
to
act
as
a
df
in
a
case
of
a
distributed,
active
firewalls
across
all
the
across
the
fabrics.
K
K
G
G
I
have
a
couple
of
comments,
so
the
first
one.
So
in
the
past
we
already
discussed
that
you
were
actually
requesting
a
df
election
algorithm
that
it
was
clashing
with
an
existing
working
group
document.
That
was
not
called
point
two.
You
changed
it
to
three,
but
unfortunately
that
one
is
also
taken
by
your.
K
G
To
be
yeah,
that
is
probably
a
better.
Thank
you,
and
my
last
comment
is
that
the
df
election
that
you
are
proposing
is
okay
is
just
proposing
that
all
the
the
ps
in
the
ethernet
segment
can
forward
bomb
traffic.
G
K
L
I
need
I
need
20
seconds
so
patrice
resets.
This
consistent
for
the
first
drive
on
the
all
the
f-bomb,
somehow
there's
already
under
the
draft,
which
is
bringing
the
single
flow
active
low,
balancing
mode.
It
is
exactly
doing
what
you're
trying
to
do,
and
I
think
you,
the
way
you
put
in
the
draft
is
wrong
because
your
ac,
your
esi,
is
wrongly
assigned
to
the
proper
device
on
the
network,
but
please
have
a
look
to
the
l2
gateway
protocols
draft
for
the
second
one
and
then
them
on
the
dampening
back
off.
L
K
A
I
H
I
have
seen
you
the
new
slides.
A
This
would
be
the
one
which
updated
over
weekend.
I
think
not
today.
I
I
Here
this
is
the
main
problem:
the
long
segment,
the
inter
s
tunnel,
establishment
procedure
which
defining
rfc,
6514
and
fc6v1
file
faces
some
problem
in
ipv6
infrastructure
scenario
in
the
regular
I'm
working
procedure
of
rfc
6514
leave
piece
in
the
long,
segmented,
inter
asc,
cinematic
castle
roads
using
the
originator
ip
of
the
root
key
to
fill
the
sources
field
of
li
and
sbr
control.
I
Here's
a
proposed
solution
for
the
pro
pro
propagating
control
between
asses
svr
still
controls
the
c
multicast
prograding,
along
with
the
result,
parcel
into
sad
studio,
use
rd
of
c
multicast
aoi
match
against
audio's,
corresponding
intro
sad.
The
modi
cafe.
The
modification
is
that
the
global
administrative
field
of
iv6
c
multicast
input
artist,
indeed
of
sources,
field
of
c
matrices
to
match
against
originator,
fc
of
corresponding
inter
sad.
I
I
I
If
there
are
only
one
root
p
for
specific,
multiple
source,
the
solution
prevails.
Lag
is
enough.
Here
is
a
scenario:
that's
a
specific
multicast
source
multi-homing
to
multiple
routing
piece.
The
long
segment
inter
semantically
must
be
distinguished
for
each
individual
pe.
There
are
three
options:
option
one.
It
should
be
configured
with
the
distinct
rd
which
is
recommended
in
rfc
rfc6514
option
two.
It
should
be
configured
with
a
distinct
format,
moving
distinguisher
to
be
used
to
fill
the
sources
field
of
c
multicast,
noi
or
option.
I
She
used
a
comma
hash
algorithm
to
calculate
the
16
password
type
c,
to
a
format:
unicode
distinguisher
to
fill
the
source
field
sources,
field
of
the
c
multicast
aoi
option,
2
and
option
3
are
used
in
the
scenario
of
all
english
p
configured
with
a
sim
rd
gtm.
As
an
example
in
this
document,
the
sources
field
in
cinematic
has
no.
I
is
renamed
to
a
loot
decrease
root,
distinguishable
field.
You
rename
the
true
root
distinguishable
next
slides.
Please.
I
I
I
I
Is
looters
at
your
address
field
in
route
is
filled
with
the
ipv6
address.
It
is
sent
to
ipcwi6
ptpc
neighbor,
otherwise,
it's
not
to
ipv
for
bp
neighbors
for
intel
as
ibm's
80
roots
and
source
active
a
route
it
is
sent
to
both
ipv6
bp
labor
and
ip
with
four
bp
labels
for
c
multiple
routes.
It
is
if
the
ipv6
vr
would
import
external
community
exists
in
the
route
it
is
sent
to
ipv6
bp
labels
ios
is
sent
to
ipv4
bp
neighbors
in
the
reflected
returns.
I
I
Next
slides,
please,
if
you
have
any
comments,
we
can
continue
to
discuss
it
in
many
needs.
B
Okay,
let's
just
comment
to
the
list
and
we'll
move
on
to
the
next
one.
Please.
A
E
M
F
M
Okay,
we
hope
to
use
some
existing
methods
for
the
selection.
Take
the
vrp,
for
example,
the
rows
of
the
vrp
routers
can
be
mapped
to
the
amvpn
dual
homing
upstream
piece,
so
both
the
primary
and
the
standby
piece
install
vrf
vrf
pim
state
from
bgpc
multicast
rows
and
send
join
to
customer
source
direction.
M
M
M
B
M
Thank
you
please,.
N
B
N
N
N
N
The
migration
procedure
in
draft
best
ep
vpws
seamless,
is
assuming
in
figure
in
the
first
step,
the
both
p
act
as
a
rule
of
the
latency
pe.
They
send
the
rtp
message
or
with
pws
80
routes,
with
the
fpv
full
advice.
N
N
N
N
If
you
pre-evaluate
high
priority
next
slide,
please
so
the
next
step
for
this
draft
is
basically
we
are
seeking
the
more
feedback.
That's
all.
L
First
of
all,
thank
you
for
the
draft.
Second,
though,
as
you
as
you
notice,
already
the
seamless
videos
and
less
graph
that
I
carry
since
a
couple
of
years
where
we
are
already
shipping
and
have
co-authored
from
various
also
providers.
So
may
I
suggest
that
we
should
look
definitely
at
the
solution.
L
The
comment
is
very
simple:
is
I
strongly
suggest
that
we
enhance
the
current
seamless
draft
that
we
have
already
for
vpwrest?
The
prom
is
real,
I'm
not
sure
about
what
what
is
suggested
here
is
the
right
solution,
but
definitely
a
solution
must
be
proposed
and
it
should
be
part
of
the
one
that
everyone's
already
corrupting.
A
G
Yeah,
I
I
kind
of
agree
with
patrice,
so
the
solution
is
in
the
evpn
vws
seamless
draft,
although
it's
hidden,
so
it
has
to
be
made
explicit
and
there
are
different
solutions
we
could
think
about.
You
could
even
think
about
using
the
you
know
in
ipv4
and
next
hop
on
the
srv6
route
that
you
can
easily
compare
with
an
ipv4
nexup
from
the
pseudo-wire
route
or
the
other
way
around
you
could
use.
G
It
was
at
the
time,
was
used
for
inter
es
option
b,
and
we
could
actually
you
know
resurrect
that
draft,
because
it
really
makes
sense
to
generalize
the
the
identification
of
the
pe
if
it
is
needed.
But
but
again
it
has
to
be
discussed
in
the
context
of
this
evpn
vpws
seamless
draft.
N
B
Okay,
great
so
with
that,
I
think
we
are
done.
B
Okay,
thank
you
very
much
everyone
and
see
you
in
london.