►
From YouTube: IETF102-BESS-20180720-0930
Description
BESS meeting session at IETF102
2018/07/20 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
C
C
Admin
so
there's
a
set
of
blue
sheets
going
down
each
side
of
the
room.
Please
sign
the
blue
sheets
yeah
this
one's
blue
sheets
when
it
gets
to
you
a
minute
minute
takers,
mine
Chronos,
is
offered
to
take
the
minutes,
but
if
anybody
else
is
taking
some
minutes
as
well,
this
you
know
take
some
send
them
to
the
chairs
afterward,
so
I
would
be
much
appreciated.
C
C
Okay,
so
I
took
a
look
at
the
working
group
milestones
on
our
Charter
and
there
touch
out
of
date,
I
think
these
are
going
to
need
to
be
updated.
I
think
they
were
last
updated
a
couple
of
years
ago,
so
the
chairs
will
send
a
proposal
to
the
list
to
update
some
of
these.
So
please
watch
out.
Thank
you.
C
So
document
status
updates,
so
we've
had
three
RFC's
published
since
the
last
ITF,
which
is
really
good
going.
Thank
you.
Eighty
three.
Eighty
eight,
eighty,
three
sixty
five.
Ninety
three.
Ninety
five:
we
have
two
documents
in
the
ROC
editors
queue:
the
EVP,
an
overlay
draft
and
the
EPP
n
prefix
advertisement
draft.
These
are
both
in
a
misread
state
waiting
for
other
drafts
to
progress,
so
those
obviously
will
move
forward
once
the
other
drafts.
C
We
have
one
document
ready
for
submission
to
the
isg.
That's
the
PPR
multicast
map
and
we're
holding
that
to
send
it
together
with
the
MVP
m-may
open,
that's
ready,
so
we
have
four
drafts
who
are
with
the
document
shepherd
so
they've
been
through
working
group.
Last
call.
We
just
thought
it
needs
a
little
bit
to
give
Martin
a
chance
to
process
the
documents
the
heat
house
before
week
before
we
do
these,
that's
largely
the
case.
So
then
MVP
ma
in
submit
forwarding
this
we
think,
needs
a
short
repeat
of
the
working
grid.
C
Last
call
because
there
are
some
significant
updates,
I
think
on
that
EVP,
an
optimized
IR.
So
that's
waiting
for
a
new
version
to
fix
some
knits
in
the
draft,
a
VP
RS
multihoming
draft,
so
this
past
working
group
last
call
a
year
or
so
ago.
It
really
needs
to
be
refreshed.
The
authors
list
is
totally
other
date.
There's
people
with
affiliations
that
are
no
longer
with
those
organizations
anymore.
We
can't
get
in
touch
with
some
of
them,
and
we've
tried
as
chairs
to
get
in
touch
with
the
editors
and
they
haven't
responded.
C
If
you
are
an
editor
or
an
author
of
this
draft,
please
because
you
contact
the
chairs.
Otherwise
we
are
going
to
have
to
either
ask
ask
for
a
new.
You
know,
appoint
new
editors
or
just
drop
the
draft,
because
it
really
doesn't
work
to
have
non-responsive
editors
trying
to
trying
to
go
through
isg
review
and
all
48
with
the
draft.
C
C
C
E
C
So,
after
the
last
on
ETF,
we
we
ran
a
proposal
to
park
a
whole
bunch
of
very
old
working
group
documents.
I
hadn't
really
moved
forward
for
a
long
long
time
and
so
fan
sender,
proposals
the
list,
and
that
was
largely
adopted
by
the
working
group.
Those
consensus
to
do
this,
so
the
drafts
are
listed
on
the
slide-
have
been
now
parked.
C
If
there's
significant
interest
in
the
future,
we
can
resurrect
those
of
course,
but
they
really
have
weren't
going
anywhere
for
long
periods
for
those
marking
part
there's
four
other
drafts.
That
would
be
very
helpful
if
there's
any
authors
or
editors
in
the
room
to
give
us
a
very
quick
status,
update
on
this
draft
so
as
a
DC
gateway
drive.
First
of
all,
I.
F
Jeffrey
from
juniper,
our
EVP
IRB
magic
has
drafts.
A
new
revision
was
just
recently
submitted
and
we
are
still
working
on
putting
details
perfectly's
also
on
some
procedures.
Bound
procedure
updates,
I
sent
one
send
email
to
the
church
that
the
authors
believe
is
ready
to
remove
to
the
next
phase.
I,
it's
pop
I,
don't
know
if
it's
cottagey
review
or
something
like
that.
Basically,
we
think
we
are
we're
ready.
You.
C
G
C
D
A
comment:
okay
with
respect
to
the
working
group,
last
call
for
the
EBP
and
intercept
and
forwarding
that
was
yes
regarding
the
short
repeat
of
working
group:
let's
go,
we
had
Alaska
and
I
receive
some
comments
and,
as
a
result,
the
changes
that
I
made
some
of
the
changes
are
expensive,
so
I
like
to
make
sure
that
everybody
get
a
chance
to
review
the
whole
thing.
It
has
enough
time
so
I
like
to
request,
make
it
like
another
short
call,
but
a
regular
call
working
group
package
a
week.
H
H
H
We
define
the
local
procedure,
how
to
advertise
bootstrap
and
instantiate
BFD
for
multi-point
networks,
so
to
track
their
wideness
of
e
and
in
several
scenarios
next
slide.
Please
so
updates
include
advertisement
of
the
discriminator
and
for
ops,
3p
and
downstream
procedures
and
pc-bsd
discriminator
again
for
upstream
and
downstream
PA
procedures
and
editorial
cleanups
next
slide.
Please.
H
H
H
Bgp
PFD
attribute:
can
they
advertise
so
the
be
if
the
accession
deleted
on
the
leaves
next
slide
if
we
have
a
downstream
PE
procedure
so
to
bring
it
up,
the
procedure
is
similar
to
described
for
the
upstream
P,
using
BGP,
PFD
and
advertising
my
discriminator
using
the
same
ip
address
as
in
B
in
the
control
packet.
Our
next
slide
please
and
take
him
down.
H
Okay,
so
next
slide,
please
so
next
steps
BFD
for
multi-point
networks
now
in
is
gos
call,
and
there
are
some
discussion
on
issues
when
the
last
call
is
closed
and
document
goes
in
RFC
editor
q.
The
plan
is
to
review
procedures
defined
for
MVP
n
for
any
changes
and
then,
as
was
mentioned,
that
will
be
ready
for
the
working
group.
Westco.
D
Thanks,
alright,
a
question:
first,
a
disclaimer
I
haven't
read
the
draft
from
your
a
slice.
What
is
not
clear
to
me
is:
are
we
having
to
point
to
multi-point
tunnel
and
we
are
sending
the
we
are
having
to
a
point
to
multi-point.
We
have
decisions,
and
if
the
receiving
PE
egress
PE
doesn't
roses,
the
primary
ones
BFD
session
is
going
to
switch
to
the
other
tunnel.
Is
that
the
proposal
here.
H
Yes,
so
each
PE
can
be
a
multi
head
and
its
originates
its
own
multi-point
this
session.
So
the
difference
between
multi-point,
BFD
and
RFC
5818
so
point
to
point
b
is
that
the
multiplexing
on
session
is
different
and
that's
why
it's
important
that
the
source
IP
address
for
BFD
session
is
the
same
as.
H
D
That
much
into
the
like
obvious
at
this
point
to
multi-point
VF
decision,
but
with
a
little
bit
of
higher-level
with
respect
to
the
switchover
just
wanted
to
make
sure
that
before
switching
over
to
the
other
one,
we
make
sure
that
the
other
VF
decision
is
also
on
the
receiving
key
it
receives.
You,
then,
is
healthy
and
then
we
switch
over,
in
other
words,
ensuring
that
the
other
tunnel
is
healthy
before
searching
over
again
BFD
on
the
primary
tunnel.
D
H
H
D
Okay,
good
morning,
my
name
is
ELISA
Jesse
and
I'll
be
going
over
a
couple
of
drafts
this
morning.
First
one
the
IGMP
MLD
proxy
draft.
This
is,
as
you
saw,
their
status.
We
request
that
the
working
group
call
and
it
is
sitting
and
it
is
in
the
queue
that
answers.
My
last
question
in
this
way.
Thank
you
and
we.
D
Within
the
within
the
period
of
since
last
ITF,
we
realized
that
there
is
a
one
aspect
of
it
that
needs
to
be
also
cover
and
I'll
go
over
it
can
you
Nexxus
rightly
so,
to
just
give
you
guys
a
background
before
jumping
directly
into
solution.
I'm
just
going
to
give
you
a
background
of
what
the
issue
is,
we
need
to
distribute
the
IGMP
join
and
leave
sync
routes
among
multihoming
Pease,
and
these.
D
Receiving
Pease
need
to
identify
the
corresponding
Evi
for
these
routes
and
insert
these
routes
into
those
table
corresponding
to
those
he
is
so
how
we
did
that
in
Rev
zero.
We
didn't
wanted
this
route
to
go.
You
know
we
didn't
want
it
to
you,
Evi
RT,
because
if
you
use
the
EBI
RT
instead
of
the
rod
going
to
just
multihoming
piece,
it
goes
everywhere.
So
we
used
es
import
RT,
which
is
only
limited
to
the
multihoming
Pease,
and
that
takes
care
of
the
distribution
aspects
of
the
rods
to
the
multihoming
PE.
D
D
So
we
have
different
type
of
RT
and
the
question
is
okay,
which
one
and
this
new
extended
community
correspond
to
you.
When
we
wrote
the
draft
we,
as
you
know,
we
assume
that,
because
we
are
doing
things
other
drivi
other
drive
it
and
the
other
derivation
of
the
RT
is
being
defined
in
these
in
the
RFC
83
65
that
Otto
derivation
RT
is
based
on
the
to
bite
a
s
and
we
assume
it
to
bite.
Yes,
but
the
question
is:
what
happens?
D
The
operator
doesn't
want
to
use
the
auto,
derive
RT
and
wants
to
manually,
configure
it
and
wants
to
use
instead
of
to
bite
a
s
want
to
use
either
for
bite
Asri
PV
for
base
Artie.
What
are
we
gonna?
Do
then
next
slide
please.
So
we
evaluated
the
several
options.
One
of
them
was
to
define
through
expand
that
what
we
defined
for
the
EC
from
just
a
su
to
two
white,
a
SRT
tied
to
the
other
RT
type,
so
define
one
extended
community
pair,
rot
type
rah-rah
target
type.
D
The
second
option
was
used,
the
es
import
raw
target
and
multiple
X,
the
Evi
ID
into
that,
but
because
we
don't
have
in
office
space,
we
needed
to
truncate
the
ESI
ID.
So
three
bytes
of
ESI
ID
and
three
bites
of
Evi,
and
we
call
that
three
plus
three
scheme
and
then
the
third
one
was
to
define
a
extra-large
RT
that
can
multiplex
the
complete
ESI
and
Evi.
D
Yes,
and
we
verify
that
that
the
current
vendors
that
he
have
implemented
it.
You
know
it
is
based
on
it
to
bite
a
s,
and
we
say:
okay,
if
that's
the
case,
that
let's
just
go
with
option
one
and
it
gives
us
backwards.
Compatibility
fares
and
in
terms
of
implementation,
is
in
the
same
ballpark
ballpark
as
option
two,
so
we
went
with
option
one
and
we
define
those
four
types
of
EC
corresponding
to
the
four
row
target
types
and
next
slide.
Please.
D
So,
as
you
can
see,
we
have
type
0,
1,
2,
3
and
type
0,
which
we
underlined
is
the
one
which
is
currently
as
specifying
the
draft.
It
is
implicitly
refers
to
that
and
we
made
it
not
explicit
that
this
is
refers
to
a
2-byte,
a
s,
a
specific
road
target,
and
then
we
define
three
more
extended
community,
corresponding
to
type
1
2
3,
and
we
added
a
new
section
also
in
the
draft
describing
in
case
of
the
we
got.
D
You
know
in
case
of
a
SV
ours,
and
we
need
to
have
a
raw
target
translation,
making
sure
that
the
extended
community
corresponding
to
the
raw
target
translations
are
also
being
done
properly,
so
that
got
captured
and
right
now
we
are
good
to
go
everybody
all
the
quarters
and
everybody
seems
like
a
happy
with
it.
So
that's
the
end
of
the
presentation.
Next
item
I
just
a.
D
K
On
your
ID,
our
discussion,
the
thing
that
was
questioned
in
idea
was
not
whether
you
could
do
something
like
adding
4
byte
asses.
It
was
the
proposal
on
how
to
encode
it.
There
is
an
ID,
our
draft
called
white
communities
to
which
you
could
do
that
at
the
cost
of
maybe
one
or
two
tail
B's
and
pointers.
So
if
that
changes,
your
authors,
discussion,
I
just
wanted
to
make
sure
I
express
my
view
of
what
was
the
problematic
right.
K
D
You
I
am
very
well
aware
of
that,
and
it
was
an
option
that
we
consider-
and
we
are
not
even
doing
that,
so
we
decided
to
do
go
with
the
option,
one
so
that
extra
extended
community
that
we
had
discussion
yesterday,
whether
to
do
that
or
whatever
use
flexible
external
community-
and
we
had
all
that
discussion
that
there
is
already
working
group
draft
on
a
flexible,
EC
and
so
forth.
That
is,
frankly,
is
not
pertinent.
At
this
point.
That's.
L
D
I
think
are
we
Jorge
we'd
discussed
to
change
the
name,
I
think
removed
the
IGMP
from
it
with
respect
to
the
sink
and
their
leave
and
join
so
that
we
need
to
generalize
yeah
and
also
reflected
throughout
the
draft
meshing,
making
sure
the
change
is
reflected.
So
can
you
please
stick
that
action
item
as
well.
E
D
D
All
right,
the
next
draft
talks
about
the
evpn,
MV,
MVP
and
seamless
intro,
that
if
you
are
in
a
situation
that
we
are
having
evpn
Pease
running
IRB
and
at
the
same
time
we
have
MVP
entries
in
the
same
DC
and
we
don't
want
to
use
gateways
within
the
same
DC.
How
do
we
do
that
and
this
draft
got
presented
about
a
year
ago
we
received
some
good
comments
and
I'm
going
through
the
resolution
of
the
major
comments
that
we
received
next
slide.
Please.
D
D
The
main
comments
falls
into
basically
these
three
categories:
one
is
a
umh
selection
in
rev,
zero
that
we
described
that
was
based
on
the
source
active
discovery.
That
is
not
consistent
with
the
for
seizures
described
in
65,
13
and
14,
and
if
you're
trying
to
do
seamless
integration,
how
does
that
gonna
work?
Then?
D
The
second
comment
or
category
was
falling
into
well
for
the
intra
subnet
for
the
interest
of
net
traffic.
You
are
decrementing
TTL
and
also
you're,
rewriting
the
Mac
header.
Then,
how
is
that
going
to
be
affected
for
the
you
know
with
respect
to
the
service
and
then
the
third
comments
first
category,
what
we
restrict
to
the
some
clarification
on
the
requirements
section,
so
we
go
on
one
by
one
on
each
of
these
three
categories
on
the
umh
selection.
D
Basically,
what
now?
What
the
issue
at
hand
is
is
if
the
source
is
being
connected
via
multi
chance,
we
are
the
multi
chassis
lag
to
p1
and
p2
and
or
in
other
words,
all
active
EBP
and
multihoming
and
I
got
the
receivers
on
the
remote.
Please,
as
you
can
see
in
here,
p3
and
p4,
then
the
source
can
be
learned
by
a
one
PE
or
may
be
by
both
PE
and.
D
D
C
D
It
enables
that
all
the
multihoming
pease
serves
as
a
umh
to
the
remote
please,
and
they
both
advertise,
that
they
are
the
umh
for
these
source
or
for
this
rendezvous
point
along
with
the
vrf,
rot
import
external
community
and
then
both
p3
and
p4,
remotely
user
receive
it
put
it.
You
know
create
the
list
that
they
have
both
of
them
and
now,
when
they
select
I,
one
of
them
doesn't
matter
which
one
they
select,
whichever
they
select
and
join
for
a
given
flow
they're
going
to
join
only
one
of
the
PE.
D
Because
of
that
algorithm
we
talked
about
either
highest
IP
address
or
hash,
and
the
tree
is
going
to
build
from
one
of
these
PE
to
the
remote
piece
for
that
flow
or
if
the
true,
if
there
is
aggregate
tree
and
the
tree,
is
already
there,
the
Eskimo,
G
or
run
you
know,
R
comma
G
estates
guess
installed
and
it
allows
for
the
flow
go
into
that
aggregate
tree.
So
that
takes
care
of
the
you
know
the
issue
with
the
umh
that
we
have
and.
D
Allows
that
I
loves
that
the
remote
pe
EVP
MVP
NPEs
receives
the
multicast
flow
and
based
on
the
exactly
M
VPN
procedure.
So
a
couple
of
things
to
note
that
remotely
is
gonna
receive
only
one
copy
of
the
of
the
multicast
traffic
multicast
and
traffic
can
be
point-to-multipoint,
so
it
can
be
optimum
replication.
We
are
the
VPN
network,
the
core
network,
the
the
only
the
only
sub
optimality
in
here
is.
D
We
are
sending
the
sanity's
multicast
flow
from
P
1
to
P
eat
you,
you
know,
send
a
copy
of
it.
If
the
PE
T
already
has
a
receiver,
there
is
no
issue
or
there
is
a
no
sub
optimality
of
receives
it.
If
it
doesn't
have
it,
then
we
just
sending
it
to
one
pease
that
doesn't
have
the
receiver,
so
that's
the
only
little
sub,
optimality
or
drawback.
So
let
me
see,
should
I
take
question
right
now.
Wait
till
the
end.
There
is
up
to
you.
Oh,
go
ahead!
F
J
F
The
meantime
it
needs
to
send
the
traffic
to
p3
and
p4
on
the
NDP
internal,
if
that
emmab
internal
is
also
inclusive
dunno.
That
means
that
P
2
is
also
going
to
receive
traffic,
so
p2
is
going
to
receive
two
copies
of
traffic,
one
on
the
entry
Astana
well
on
the
MEP
internal.
It
will
not
cause
duplication
in
delivery,
but
it's
just
once
more
so.
D
D
The
definition
that
you're
giving
is,
let's
say
if
you
go
with
that
definition,
that
all
traffic
goes
into
it,
I
can
say
that
it
would
be
the
that
I
can
extend
or
expand
that
for
the
a
VPN
and
with
respect
to
with
respect
to
the
multicast.
If
I
have
a
joinha
state,
then
I
can
put
the
traffic
in
there
right.
F
M
D
D
As
I
mentioned
that,
given
that
even
we
are
decrementing
the
TTL
and
rewriting
the
Mac
header
for
intra,
not
just
inter
sub
net
but
for
interest
of
net,
then
how
does
that
impacts
the
land
service
that
we
are
talking
about
for
the
interests
of
net?
Well,
if
we
delve
into
it
a
little
bit
more
evpn
provides
an
emulated,
LAN
service,
not
exact,
which
or
LAN
service
pair
that
want.
You
I
mean
that
one
queue
is
a
1500
page
standards
that
we
are
not
compliant
with.
D
You
know
lots
lots
of
the
chapters
of
that
document,
so
even
when
we
limit
it
to
a
simple,
real
and
bridging
still,
we
are
not.
If
you
want
to
go
based
on
the
exact
one
queue
we
are
still
not
compliant
so
question,
and
it
is
the
emulation
that
we
are
doing,
and
example
of
it,
with
the
EVP
and
IGMP
pin
proxy
procedure,
which
is
you
know,
one
example
of
that
emulated
LAN
service.
So
we
are
not
doing
MV
RP.
Instead,
we
are
doing
the
IGMP
proxy
and
we
are
expanding
that
concept
of
emulated
LAN
service.
D
We
are
saying
that
in
this
case,
this
emulated
LAN
service
is
going
to
allow
for
the
TTL
decrement
for
interest
of
net
multicast
flow
and
with
respect
to
the
all
the
application
that
we've
come
across.
We
don't
see
any
you
know
issue,
but
again,
if
there
are
certain
application
that
they
absolutely
have
to
have
no
TTL,
decrement
and
so
forth,
then
there
is
the
other
draft
that
they
can
use.
D
You
know
villain
based
villain,
aver
bundle
and
so
forth,
and
we
are
saying
that
the
solution
should
operate
without
impacting
any
of
them
next
step.
Basically,
I
think
it's
been
around
three
years
since
the
first
version
got
publish,
it
has
been
implemented
and
deployed
by
one
vendor
and
being
a
plant
by
two,
more
and
I.
Think
is
at
this
point
we
like
to
request
for
a
working
group.
Co
Azure
go
ahead
with
Asha.
I
F
D
E
Okay,
so
so
I'm
glad
to
see
that
you
actually
addressed
some
of
the
issues
of
the
previous
version.
However,
I
don't
think
we
we
should
adopt
this
draft.
As
the
working
group
document,
we
have
the
EPIRB
multicast
draft,
which
is
covering
intra
and
Inter
subnet
multicast
forwarding
it's
also
covering
MVP
entry,
VPN
interworking,
so
my
proposal
would
be
why
don't
we
focus
on
that
trunk?
D
D
No,
when
all
of
the
H
devices
becomes
a
PE,
then
it's
gonna
transfer
into
this
or
the
other
way
around
alright.
So,
basically,
if
you
look
at
it,
if
I
have
basically
no
gateway,
because
the
one
of
the
requirement
is
not
insert
the
gateway
in
the
middle
of
a
data
center-
okay,
because
everything
now
we
have
created
a
bottle
neck
in
there,
and
this
is
if
your
based
on
that
requirement.
D
If
you
go
with
that-
and
we
say
that
the
Gateway
is
not
every
pianist-
we
have
gave
a
functionality
basically
translates
into
this-
that
we
need
to
know
the
EVP
MVP
and
please
need
to
be
able
to
have
the
MVP
and
procedures
and
you
image
selection
and
all
that
based
on
just
the
HP's
ingress
piece.
But.
D
Yet
what
you're
talking
about
you're,
talking
about
when
they're
you
talking
about
partitioning
your
network,
I'm,
not
talking
about
the
partitioning
network
you're
talking
about
the
partitioning,
your
network
based
on
the
MA
VPN
domain
and
MVP,
and
you
have
some
gateways
in
the
middle
okay,
I'm,
not
talking
about
that.
Okay!
Do.
D
Have
a
network,
okay
and
based
on
that,
then,
when
you're
talking
about
that,
the
source
is
directly
coming
to
the
to
that
pair
of
pease,
and
now
that
pair
of
keys
need
to
set
out
the
MVP
and
tunnel
to
the
rest
of
it
is
not
going
through
any
gateway.
It's
going
to
be
doing
the
Gator
functionality
so
communicate.
D
M
D
No
I
didn't
I
didn't
say
that
I
said
me:
I'm
not
coming
across
any
application.
That
says
you
have
to
have
a
TTL
decrement
for
the
intra
subnet
traffic
of
IP
multicast
I
am
NOT
I
haven't,
so
this
address
is
99.99%
of
the
application
there.
If
you
have
an
application,
which
is
you
come
in
the
future,
then
go
with
the
other
giraffe.
You
don't
have
to
do
this.
M
G
D
C
N
N
N
The
draft
that
that
defines
EVP
and
routes
is
already
now
published,
as
RFC
like
7432,
and
also
the
IP
IP
prefix
advertisement
draft
is
also
widely
deployed
now,
so
this
draft,
which
is
which
is
essentially
defining
om
alvey's,
which
are
based
on
7432
and
also
IP
prefix
advertisement
draft,
is
also
very
stable.
Now.
N
N
N
N
Auto-Discovery
sub
TLV
format
next
slide.
Please,
and
the
IP
prefix
of
TLB
format
next
slide,
please.
So
in
the
start
we
are
proposing
that
the
LSB
ping
packet
be
encapsulated
using
the
GAR
label
as
the
bottommost
label
and
followed
by
ipv4
or
ipv6
the
associate
channel
header.
So
this
provides
a
uniform
way
of
the
on
a
peer
outer
which
is
processing
these
LSP
pink
packet
to
detect
that
it's,
the
OEM
packet
using
the
GAR
label,
plus
the
ipv4
or
v6
edge,
and
and
punt
the
packet
for
further
processing,
rather
than
forwarding
them
to
this.
E
So
if
you
send
the
test
from
an
ingress,
P
or
checking
state
of
a
give
a
Mac
or
if
prefix,
on
the
egrets
key,
but
that
doesn't
necessarily
mean
that
the
the
host
that
owns
the
eggman
called
the
IPS
is
a
life
right.
You're
not
proposing
to
based
on
that
to
trigger
any
unique
Azhar
or
any
other
extra.
N
N
It's
also
verifying
the
state
throughout
the
network,
as
well
as
on
the
B,
that
there
is
a
path
right,
because
we
used
the
same
label
stack
that
a
data
packet
will
use
to
get
forwarded
through
the
network
router.
So
it
is
actually.
This
draft
is
very
much
in
line
with
the
MPLS
procedure
that
we
use
for
hit
up
in
connection
right.
Yeah,
I,
understand.
E
D
Cfm-
and
this
is
doing
different
check-
CFM
is
basically
doing
the
check
at
the
ethernet
layer,
whereas
this
is
trying
to
check
at
the
service
layer
the
VPN
ID
that
you're
using
in
the
data
plane
that
matches
to
what
the
control
plane
is
talking
about
somewhere
in
the
middle.
It
didn't
get
corrupted
and
so
forth.
So
this
is
verification
of
the
data
plane
to
the
control
plane
and
this
seriously
not
that
the
eternal,
a.
D
D
So
that's
where
the
framework
document
is
the
framework
document
talks
about
all
these
different
and
there's
going
to
be
a
presentation.
It
talks
about
the
different
layer
of
the
OEM
and
what
we
need
for
each
layer
and
it
talks
about
the
CFM.
It
talks
about
the
OEM
for
that
MPLS
tunnel
and
OAM
for
the
service
MPLS
service
layer.
This
a
specific
presentation
is
really
aspect
to
the
MPLS
service
layer
and
then,
on
top
of
that,
you
have
at
the
end
to
end
customer
connectivity
and
all
the
layer.
L
L
It
means
that
type
4
will
be
capable
of
doing
both
star
G
and
SG,
and
type
5
will
be
only
star
G.
So
even
if
there
are
edge
mtv3
join,
which
are
which
are
SG,
we
are
still
going
to
use
star
G
d/f
election
and
why
exactly?
It
was
needed.
There
were
few
customer
who
we
are
looking
to
have
some
kind
of
policy
for
a
group,
so
they
wanted
to
make
sure
that
the
same
group
traffic
doesn't
get
distributed
among
redundancies.
L
C
D
So
juicy
co-author
of
this
draft.
This
is
basically
one
of
the
DF
election
that
we
need,
and
especially
it
is
a
must
have
when
you
have
a
lot
of
flows
into
the
same
VLAN
in
case
of
the
you
know,
subscriber
use
cases,
and
this
is
how
you're
gonna
load
balance
the
traffic
across
for
the
same
fat
reel
and
across
different
piece.
So
it
is
a
pretty
important
draft.
D
D
A
D
One
of
those
days
so
the
objective
in
here
is:
if
I
have
a
lag
and
all
active,
you
know
multihoming
lag
and,
let's
say,
I'm
a
start:
I
I
have
a
C
which
is
the
home
to
two
PS
and
each
to
you
know
to
one
gig
interface
to
each
of
them
and
then
suddenly
one
of
them
fail.
One
of
the
interfaces
fails
or
one
of
the
link
fails.
D
D
The
first
part
of
it,
which
is
with
respect
to
the
unicast
load
balancing
that
was
covered
in
the
first
version
of
the
draft
and,
as
you
can
see
in
these
is
white.
The
Cee
is
dwarf
home
to
P,
1
and
P
2,
and
they
might
both
start
with
200
gig.
But
then
there
is
a
failure
and
one
of
them
loses
hundred
gig.
D
So
what
we
do
in
here,
we
advertise
the
HPE
advertised
the
rot
associated
with
his
Ethernet
segment,
which
is
ether
ad
pair
es
rot,
along
with
the
corresponding
bandwidth
for
that
yes,
so
PE
one
advertises
200,
gig
PE
to
advertisers,
100,
gig
and
receiving
te
PE
x-ray
receives
it.
It
basically
creates
the
pathways
for
that
ESI
innovated
fashion.
D
This
one
is
for
unicast
non
unique
as
traffic
and
everything
is
fine.
The
question
is
okay
for
the
multicast.
What
we
gonna
do
for
the
multicast.
We
need
to
make
sure
now
that
the
DF
election
procedures
that
has
been
done
among
the
multihoming
PE,
that
also
takes
into
the
account
these
link
bandwidth
for
the
Ethernet
segment.
And
this
is
what
we
added
in
this
new
rev
and
we
went
and
through
different.
D
D
This
is
the
list
of
the
updates
that
we
made.
As
I
mentioned,
we
included
the
bomb
traffic
in
addition
to
the
unicast,
and
we
specify
detail
procedures
that
how
this
link
bandwidth
is
gonna
influence
these
different
DF
election
algorithm,
and
we
also
added
a
section
in
case.
We
just
have
rotted
overlay
a
use
case,
and
we
also
mentioned
that
we
need
in
case
we
have
interest,
we
need
to
have
transit.
This
attribute
needs
to
be
transitive.
D
Solution
so
Mary
I
already
went
over
that
that
how
it
works
in
the
figure
and
just
in
case
of
the
DF
election.
We
add
this
extended
community,
along
with
the
road
type
for
for
the
DF
election
purposes,
and
we
added
a
new
capability
bit
to
that
X
to
the
DF
election
extended
community
to
indicate
whether
a
PE
can
support
this
kind
of
the
rated
load.
Balancing.
D
D
D
C
C
D
C
P
D
This
is,
he
is
talking
with
respect
to
the
bandwidth
extended
community
that
we
are
using
and
is
defining
another
draft
and
it
is
non
transitive
and
we
want
it
to
be
transitive.
I
think
if
the
author's
remains
on
the
responsive,
then
we're
going
to
either
bring
that
I,
don't
know
bring
that
EC
into
this
draft
or
have
somebody
else's
pick
up
the
other
draft
to
push
it
through.
C
Q
E
D
This
is
another
draft
on
extending
the
mobility
procedures
for
IRB.
The
mobility
lack
mobility
has
been
described
in
baseline,
evpn,
RFC
7432,
and
here
we
are
extending
it
for
the
IRB
and
not
just
the
IRB
case,
which
is
there
is
a
one
to
one
Mac
two
IP
mapping,
but
for
the
cases
that
one
Mac
can
be
associated
with
two
IP
or
two
max
can
be
associated
with
one
IP
in
those
cases
which
there
are
certain
scenarios.
How
do
we
handle
that?
D
D
Scenario,
what
we're
gonna,
how
we're
gonna
take
up
the
IP
mobility?
These
are
already
been.
You
know,
capture
in
the
initial
Rev
and
we
added
some
clarification
to
this
rev
and
also
the
draft
talks
about
duplicate
as
risk
detection
for
these
advents
european
IRB
scenarios.
If,
with
a
duplicate
max
detection,
we
already
have
that
in
baseline,
but
duplicate
IP
detection
with
different
nack
windings
or
duplicate
IP
detection
in
rotted
overlay.
How
are
we
gonna
take
care
of
that?
It's
been
described
here
and,
along
with
these,
how
we're
gonna
do
the
duplicate
host
recovery.
D
So
the
updates
that
went
into
this
Rev
is
addressing
the
comments
that
was
received
so
far
and
we
expanded
the
scope
to
cover
rotted
overlay.
Routed
overlay
means,
basically,
you
don't
have
any
mac
address
as
it's
just
a
pure
IP,
pure
l3,
and
that
is
users
based
on
the
road
type
five
and
how
we're
gonna
cover
this
views
case
and
that
it
got
added
and
distract
how
we
are
doing
that
and.
D
D
D
If
the
local
Mac
sequence
number
follows
the
following
rules
that
it
must
be
hired
and
the
existing
remote
Mac,
which
that
is
the
same
as
7432
or
rule
number
two,
if
ipsi
associated
with
a
different
remote
Mac,
then
you
take
the
sequence
number,
which
is
higher
than
the
one
from
the
the
bigger
of
the
sequence
number
between
that
and
the
remote
Mac.
So
always
we
pick
the
higher
sequence
number,
so
these
procedures
been
described
in
a
good
level
of
details
in
the
appendix.
R
R
R
D
R
D
G
R
R
R
D
D
R
D
R
J
D
No,
the
IP
inherits
the
sequence
number
of
his
MAC
address.
So
when
that
IP
moves
from
left
to
right,
it
inherits
and
the
sequence
number
of
the
Mac
for
which
it
is
the
local
Mac
that
is
associated
with
you
pick.
The
sequence
number
of
it
is
a
parent-child
relationship,
the
child
picks
of
the
sequence
number
of
the
parents.
That's.
D
R
D
D
R
R
R
R
E
Okay
level
on,
if
you
came
into
working
with
IP
VPN,
this
is
the
list
of
my
connoisseurs
and
well.
The
idea
here
is
that
you
may
have
a
tenant
network
that
may
span
multiple
domains
in
each
of
those
domains.
You
can
actually
use
a
different.
We
call
it
intercept
net
forwarding
Safi,
an
intercepted
fall
in
Safi
is
actually
a
Safi
that
is
able
to
exchange
IP
prefixes.
So
evpn
is
an
example,
but
also
VPN,
ipv4
or
a
VPN,
ipv6,
etc.
E
So,
when
you
have
all
those
domains
and
we
need
to
stitch
them
together,
there
are
certain
interworking
aspects
that
must
be
clarified.
So
this
is
the
Deval
of
the
draft
to
clarify
the
interworking
aspects
in
terms
of
BGP
route
selection,
loop
prevention,
path,
attribute,
propagation
and
also
and
route
aggregation.
So
what
is
it
domain?
E
There
are
no
IP
lookups
in
the
tan
space
in
the
intermediate
routers,
so
you
have
two
examples
in
the
end,
the
slide
so
right
hand
side,
you
have
two
peas,
they
are
in
the
same
domain
because,
even
even
though
you
have
a
USB
arse
in
between
on
those,
you
don't
have
IP
lookups,
you
don't
have
an
IP
verve
instantiate
it.
So
those
two
pease
are
considered
to
be
within
the
same
domain.
On
the
left-hand
side,
you
you
actually
have
three
different
domains.
You
have
two
evpn
domains
and
an
IP
VPN
domain
in
between.
E
E
You
need
to
identify
the
domains
with
an
ID,
and
that
is
also
defined
in
the
draft
now,
once
you
have
the
domains
we
play
with
the
different
types
of
domains
and
and
therefore
we
also
define
the
terminology
for
the
APS,
so
we
refer
to
a
regular
domain
to
this
domain,
where
you
have
peas,
with
IP
verbs
and
use
only
one
control
plane,
one
intercept
net,
forwarding
Safiye,
for
instance.
If
you
look
at
the
right-hand
side
of
this
slide,
you
have
an
example
where
you
have
two
regular
domains
in
each
domain.
E
There
is
only
one
protocol,
either
a
VPN
or
IP
VPN
on
the
left-hand
side.
That
is
what
we
call
a
composite
domain
composite
domain.
Is
you
have
a
single
domain,
but
some
of
the
piece
they
actually
support.
More
than
one
intercept
net
forwarding
Safiye,
for
instance,
the
interworking
p.
On
the
left
hand,
side
basically
supports
activity
and
a
new
VPN,
whereas
the
other
two
pieces
are
either
a
VPN
or
IP
VP,
and
only
so,
therefore,
we
also
define
the
role
of
the
composite
P.
E
Composite
P
is
attached
to
a
composite
domain
and
it
uses
multiple
into
some
net
forward.
In
surface
to
advertise
a
prefix
now
because
you
have
all
these
domains
and
you
can
grow
your
network
and
stitch
them
all
together
and
have
multiple
operators
with
their
own
domains,
we
have
the
requirements
of
defining
a
new
attribute.
No,
a
new
path
attribute
that
we
we
call
D
path
or
domain
path
attribute.
E
That
is
similar
to
an
alias
path,
but
is
not
a
yes
dependent
and
a
good
example
would
be
what
you
have
in
the
diagram.
So,
for
instance,
when
you
have
a
prefix
being
advertised
by
the
EVP
mp2
on
the
right
hand,
side
you
advertise
it
to
the
gateway
gateway,
p2
gateway,
p2
needs
to
advertise
it
to
a
different
domain,
and
then
it's
going
to
attach
the
this
D
path
to
the
route
in
this
and
D
path.
We
are
actually
encoding
the
domain
ID
and
the
Safi
itself.
Right
now.
E
The
previous
gets
to
Gateway,
p1
and
p1
will
do
the
same
thing.
Will
realtor
ties
in
evpn?
So,
at
the
end
of
the
end,
the
way
basically
evpn
p1
will
receive
the
prefix
and
we'll
know
exactly
how
many
domains
and
for
you
know
how
many
different
intercepted
for
oneself
is
that
prefix
has
gone
through.
E
So
we
use
this
to
avoid
loops
and
to
have
visibility
of
all
the
domains
in
Saffy's.
The
other
thing
we
are
covering
is
the
attribute
path
propagation.
So,
when
you
have
a
gateway
and
you
receive
a
prefix
and
evpn
and
you
need
two
realities
it
to
IP
VPN,
what
do
you
do
with
the
demand
attributes?
You
can
either
do
nothing
and
restart
the
path
attributes
or
you
can
do
what
we
call
the
uniform
propagation
mode
and
what
that
means
is.
E
Basically,
we
pick
up
certain
relevant
attributes
from
one
family
and
we
actually
carry
them
over
to
the
other
Safiye,
and
you
can
see
you
can
see
the
list
on
the
air
on
the
draft.
But
basically,
when
you
you
configure
the
gate,
wait
for
uniform
propagation.
We
want
to
propagate
AES
path
and
the
path
and
some
other
attributes
on
the
other
aspect
we
are
covering.
E
The
draft
is
the
route
selection,
and
this
is
because
on
a
gateway
P,
you
can
actually
receive
the
same
route,
the
same
prefix
on
different
surface,
and
even
if
you
receive
it
in
any
VPN,
it
can
be
in
a
router
v
and
the
route
type
to
so,
which
one
do
you
pick?
So
we
are
actually
yes
setting
some
rules
for
preference.
E
We
are
even
allowing
if
the
Gateway
is
configured
to
do
so.
We
are
allowing
ecmp
across
a
VPN
and
I
ppm
for
the
best
paths.
So
this
trap
was
presented
the
the
first
time
in
IETF
100.
It's
been
there
for
a
while
getting
feedback
and
within
incorporating
all
the
feedback.
The
major
changes
in
revision
1
have
been
first
one.
We
clarified
that
mineralogy
section
and
we
did
a
general
cleaning
special
thanks
to
John
for
doing
that.
E
We
also
added
some
clarifications
for
some
other
procedures
and
we
added
a
section
on
broad
aggregation
and
in
particular
our
aggregation
refers
to
this
typical
use
use
case
where
you
have,
for
instance,
a
data
center
where
you
have
EVP
M
for
layer
3
and
you
receive
tones
of
house
routes
on
the
Gateway.
So
in
some
cases,
if
you
don't
need,
you
know,
host
mobility
across
different
data
centers,
you
can
actually
aggregate
those
routes
and
send
a
single
aggregate
to
IP
vpm,
for
instance
right.
E
So
we
are
defining
the
rules
under
which
you
can
actually
aggravate
those
routes
or
those
cases
where
you
cannot
aggravate
the
routes
and
that's
pretty
much
it.
So
we
believed
in
the
trough
is
pretty
much
or
now
and
it's
ready
for
working
group
adoption.
So
we
would
like
to
request
the
and
this
adoption.
Okay.
C
S
S
S
It
really
applies
to
our
c-47
7432
and
76238
p.m.
and
basically
leverages
a
lot
of
existing
concepts,
including
those
from
various
OEM
RFC's
and
continuity
fault
management
from
802
dot1q
and
the
itu-t
document
on
Ethernet
based
om
functions.
So
this
should
not
be
a
terribly
startling
figure.
This
is
the
typical
diagram
showing
the
framework
and
the
different
layers
of
OAM
from
link
on
a
link
up
through
transport
network
and
the
end-to-end
service.
O
am
the
different
layers
are
handled
by
different
mechanisms?
Typically,
the
link
o
am.
S
It
really
depends
on
on
the
link
technology
and
given
you
have
an
Ethernet
link,
for
example,
you
would
typically
use
in
the
kind
of
OAM
that
you
have
in
nato.
2.3
transport
depends
on
the
transport
there's
a
little
choices
there,
there's
a
PFD
or
MPLS
or
ICMP,
depending
on
what
technology
are
using,
of
course,
and
actually
I'm
going
to
sure
talk
about
another
graph
which
is
on
BFD
based
o.
Am
the
network
o?
Am
it's
really
the
sort
of
the
PE
2
p
EO?
S
S
Should
test
that
these
are
requirements
and
that
DF
filtering
is
is
working
properly
now
that
car
graphed
provides
that
it
has
to
support
in
band
man
and
the
messages
need
to
have
the
same
sort
of
entropy
characteristics
as
the
data
that
you
want
to
get
through
and
should
support
both
proactive
and
on-demand
Oh
am
the
service.
Oh
I
am,
since
what
we're
providing
is
Ethernet
service.
It
basically
uses
a
condor
default
management
for
that
service
and
that's
visible
to
the
seas
and
the
peas
and
the
peas
must
support
the
maintenance.
S
Indication
then
talks
about
them
for
a
connectivity,
verification
draft
says
you
need
to
have
variable
length,
so
you
can
test
for
MTU
problems
and
you,
of
course
they
have
to
be
able
to
isolate
the
fault.
That's
the
one
of
the
primary
goals
of
the
OEM
function
for
performance.
Its
graph
says
you
should
detect
packet
loss
and
delay
and
you
made
it
monitor
jitter
so,
and
there
are
security
considerations
it
needs
to
protect
against
the
tile
service
to
the
OEM
messages.
You
need
to
be
able
to
authenticate
the
endpoints.
S
You
know
you're
talking
to
who
you
think
your
talking
to,
and
you
want
to
prevent
the
OM
messages
from
leaking
outside
the
evpn
Network.
So
this
is
a
0-0
draft,
but
it
was
actually
previously
at
brows,
LOM,
l2v
p.m.
Bessie,
VPN,
OEM
requirements
and
framework
Oh
is
this
is
actually
the
fourth
version
of
the
draft
and
I
think
this
is
a
pretty
solid
draft.
S
D
Just
a
comment:
this
is
a
very
old
draft
and,
as
you
know,
all
the
OEMs
stuff
typically
gets
pushed
to
the
end
of
the
cycle.
When
new
evpn
works,
guess
you
know
going,
everything
is
on
the
control,
plane
and
data
plane
and
then
the
OEM
is,
you
know
less
so,
given
that
we
are
getting
into
the
stable
phase
of
the
evpn,
we
are
resurrecting
the
OEM
documents
in
here
and
they're
needed.
Ok,
all.
S
Okay,
this
is
a
much
shorter
presentation.
This
is
on
PFD
for
a
fault
management
in
EPM
networks
so
basically
specifies
how
to
do
EFT,
a
synchronous
mode,
proactive
fault
detection
and
it's
the
current
version.
Laos
coverage
is
to
RFC
7432
MPLS
based
evpn
and,
as
I
tells
how
to
do
it
for
a
unicast
traffic
BOM
traffic
using
MP,
2,
p,
&
MP
2
MP,
so
this
draft
is
not
quite
as
complete.
The
other
previous
draft
I
talked
about
the
four
acquirements
in
framework
has
no,
you
know,
there's
no
TP
DS
or
anything
like
that.
S
In
this
draft,
it's
a
little
bit
less
polished
and
probably
needs
somewhat
more
work,
but
it
does
cover
the
bases
in
the
current
version
that
the
draft
states
that
it's
out
of
scope
for
other
encapsulations
and
mpls
doesn't
say
any
cover
or
anything
to
do
with
demand
mode
or
echo
functions
and
doesn't
cover
packet
loss
or
delay
measurement,
and
there
are
also
topics
that
could
probably
be
added.
It
could
be
added,
there's
not
any
coverage
in
the
current
draft
of
anything
related
to
any
changes
related
to
PvP,
vbe
v
PM,
and
we
had
it.
S
E
No
Kia
so
in
the
drafted
Greg
presented
earlier
this
morning,
we
using
MVP
and
we
use
a
PFT
basically
for
fast
failover
and
he's
using
two
distributed.
Discriminators
he's
using
actually
BGP
routes
right.
My
PvP
'invalid,
so
I
was
wondering
why
here
you're
actually
is
saying
that
this,
the
dis
community,
that
this
can
discriminate-
oh
sorry,
are
actually
distributed
through
LS
peeping
and
not
if
bgp
routes.
D
Let
me
take
that
question
again.
This
is
a
all
draft,
so
that
was
a
thinking
as
of
like
a
few
years
ago.
Okay,
so
if
the
this
reading
ability
of
PGP
is
a
more
consistent
approach-
and
it
is,
we
keep
the
same
mechanism
between
M
Vivian
and
this
one.
We
can
adopt
that
approach.
We
have
nothing
against.
T
Hello,
Ron
Bonica
and
I'm
presenting
graphed
Rosen
best
secure,
l3
VPN.
It's
mostly
the
work
of
Eric
Rosen
I
worked
along
with
him
on
it.
The
goal
is
to
augment
l3
VPN
for
use
over
a
public
backbone.
The
public
backbone
is
both
untrusted
and
it
won't
offer
MPLS
transport,
but
you
have
to
remain
retain
the
concept
of
multi-tenancy.
T
T
The
CPE
control
plane
is
IPSec,
protect
protected
BGP
to
a
secure
route.
Reflector
private
routes
are
advertised
as
a
VPN,
IP
V
route,
VPN
IP
routes
with
private
CPE
loopback
is
the
next
stop.
The
private
CPE
loopback
is
advertised
as
an
IP
route
list.
Public
CPE
addresses
the
next
stop
and
tunnel
encapsulation
attribute
that
specifies
a
CPE
to
CPE
IPSec
security,
Association
and
the
data
plane
uses
these
IPSec
security
associations.
T
So
what
do
we
have?
First,
we
have
CPE
read
routes.
Cpes
have
read
interfaces
back
to
the
private
side,
that's
behind
the
CPE
in
black
interfaces
that
go
forwards
across
the
untrusted
Network.
Each
CPE
has
a
red
loopback
interface,
private
and
a
black
loopback
interface
and
CPS
originate
two
kinds
of
routes:
a
VPN
IP
routes
pointing
out
the
red
interfaces
red
routes
they
set
the
next
stop
the
red,
loopback
and
IP
route
to
the
red
loop
back.
We'll
talk
about
that
in
the
next
slide.
Red
routes
are
only
advertised
over
IPSec,
protected
red
bgp
sessions.
T
T
The
C
PE,
the
customer
PE,
has
two
loop
backs
red
and
black.
The
red
one
is
the
next
hop
for
all
the
red
VPN
routes
that
are
advertised.
The
black
one
is
the
interface
to
which
the
IPSec
tunnel
is
anchored.
So
when
you
send
a
packet,
it
will
be
sent
through
the
tunnel
with
a
next
top
of
the
red
loop
back.
T
U
T
There
is
one
IPSec
Association
from
well
okay.
The
thing
that
is
pre-configured
is
the
IPSec
association
between
the
CPE
and
the
route
reflector.
When
you
learn
a
route
through
the
route
reflector
mm-hmm,
then
you
set
up
another
security
association
between
the
CPE
and
the
red
and
the
next
top
of
that
route,
and
that
is
a
different
CPE,
so
you
have
to
configure
one
IPSec
association,
the
route
reflector.
Yes,
as
you
learn
routes
that
gives
you
a
clue
that
you
need
to
set
up
another
security
Association.
If
you
don't
already
have
one
the
next
hop
yeah.
T
U
T
T
K
T
K
T
T
K
K
P
Name
is
J,
so
I
know
where
Linda
is
coming
from,
and
this
question
will
keep
on
popping
up
whether
you
could
use
this
for
distribution
of
keeps
and
seats
the
public
keys
unless
they
run
and
either
you
explicitly
shade.
No
because
it's
insecure
and
it
doesn't
work
for
that
and
probably
already
said
it
requires
some
outer
band
configuration
which
makes.
P
O
T
C
C
D
J
J
T
We
have
five
minutes,
I'll
skip
over
the
slides
entirely
and
just
tell
you
what
I
want
to
do
over
the
last
20
years,
we've
all
gone,
grown
old
and
gray,
creating
VPN
technology
cell
3,
VPN,
L,
2,
VPN,
VPLS,
evpn
of
dmvpn.
All
of
these
things
have
a
few
things
in
common.
They
have
CII's
pease,
v,
RF
context,
labels
and
tunnels.
T
Let's
talk
a
minute
about
context,
labels
and
tunnels.
Think
about
a
classic
l3
VPN.
You
have
a
packet,
it
comes
to
the
ingress
PE,
you
look
it
up
in
the
correct
vrf.
The
lookup
yields
context
information
in
a
neck.
Stop
you
push
the
context
information
as
an
MPLS
VPN
label,
and
you
push
something
else
to
get
the
packet
to
the
remote
PE.
That's
the
tunnel,
encapsulation!
T
Okay.
We
have
lots
and
lots
of
choices
for
tunnel
encapsulations.
You
can
encapsulate
an
MPLS
or
GRE
or
IPSec
or
pick
your
favorite
tunnel.
We
only
have
one
choice
for
context:
information.
We
always
put
the
VPN
label
in
that
we
always
put
the
contact
information
in
an
MPLS
VPN
label.
Well,
there
were
some
people
who
would
like
to
build
PE
s
that
cannot
process
MPLS
VPN
labels,
so
they're
asking
for
an
alternative.
How
else
can
I
encode
that
information?
T
Well,
what
leaps
to
mind
is
how
about
an
ipv6
destination
option,
an
ipv6
destination
option
gets
stuck
between
an
ipv6
header
and
whatever
comes
next.
So
if
ipv6
is
your
transport,
you
put
what
would
have
in
the
VPN
label
in
an
ipv6
destination
option:
here's
a
picture,
payload
context,
information
tunnel,
encapsulation
and
here's
a
look
at
what
the
destination
option
looks
like.
It
basically
has
three
fields
in
it:
an
option
type,
the
first
two
bits
of
the
option:
type
tell
the
destination
what
to
do.
T
If
he
doesn't
understand
this
option-
and
in
this
case
the
behavior
is
discarded
the
packet
and
send
an
ICMP
message.
Next
is
the
length
of
the
payload
data.
That's
the
you-know-whats,
now
of
the
20
bits
of
a
VPN
label,
so
that
would
be
like
three
and
the
option.
Data
is
the
context
information
itself
notice.
When
we
have
a
destination
option,
this
length
is
variable.
If
you
need
20
bits,
you
can
support
it.
If
you
need
more
bits,
you
can
support
that
too.
T
In
any
event,
here
we're
not
asking
for
this
as
a
working
item
in
this
working
group,
because
since
we're
codifying
a
new
ipv6
destination
option,
it
has
to
be
in
six-man,
but
we
are
looking
for
this
groups
blessing.
Do
we
break
anything
by
encoding
this
a
different
way?
The
next
thing
is
a
word
of
warning
about
what's
to
come.
If
we're
going
to
encode
the
context
information
as
something
other
than
an
MPLS
label,
we
have
to
wait.
T
D
Is
the
issue
in
this?
This
is
we're
trying
to
take
care
of
the
song
hardware
issue
in
here
and
we
are
creating
some
interoperability,
because
right
now,
MPLS
I
can
have
MPLS
Network
at
one
site
and
then
I
P
network
and
the
service
layer
can
work
nicely
because
I'm
just
terminating
the
tunnel
right
now.
I'm
not
messing
around
with
the
context
label
and
I
need
to
do
the
mapping
between
the
terminate
the
MPLS
completely
here,
not
just
a
tunnel
and
then
map
it
to
the
other.
One
on.
T
D
We
have
that
we
don't
want.
No,
no,
no
I
hear
you.
So
in
that
case
we
don't
want
to
do
MPLS,
and
then
we
spend
what
five
six
years
on
maybe
longer
on
an
vo
tree
having
four
different
proposal:
okay,
vx
LAN,
NV,
GRE,
genève,
GPE,
GUI,
just
name
it
okay,
and
we
agreed
after
the
end
of
the
five
six
years
on
Geneva
and
now
you're
doing
no
some
white
different.
D
D
Know
all
I'm
saying
is
no
you're.
Coming
with
the
new
encapsulation,
that's
I'm,
pointing
to
that
and
I'm
saying
that
if
you're
coming
to
the
we're
coming
up
with
a
new
encapsulation
that
you're
saying
MPLS
is
not
good,
you
want
to
do
something
cancellation
over
IP
we've
done
that
on
the
NGO
tree
and
then
the
question
is
what
would
be
the
justification?
I
mean
I'm,
just
saying
the
Baris.
We
should
consider
a
bar
a
little
bit
high.
What
we've
done
is
not
sufficient.
B
B
Farrell
to
follow
up
on
that
slightly
I,
don't
think
this
is
defining
a
new
encapsulation.
This
is
saying
there
is
an
IP
network
over
which
we
are
running.
We
need
to
carry
the
context,
and
this
is
actually
saying
so
doing
it
without
a
new
encapsulation.
So
do
it
without
an
MPLS
encapsulation
underneath
IP
or
do
it
without
genève
under
IP,
just
say:
look
IP
is
running
and
here's
the
context.
Yes,.