►
From YouTube: IETF106-BESS-20191119-1520
Description
BESS meeting session at IETF106
2019/11/19 1520
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
A
A
Okay,
blue
sheets,
there's
two
sets:
there
are
two
blue
sheets
making
their
way
around
the
room.
Please
can
you
sign
them
and
feel
the
last
one
at
the
back.
You'll
be
greatly
appreciated
if
you
could
pass
them
back
towards
the
front,
so
eventually
they
arrive
back
here
for
us
to
take
them
to
the
Secretariat
at
the
end
of
the
meeting.
A
A
A
D
E
D
E
E
E
A
A
A
A
And
the
evpn
reference
DF
has
just
passed
working
group
last
call
and
we
have
a
long
list
of
drafts
that
we
believe
are
already
for
any
authors
have
indicated
they
think
are
ready
for
working
group
last
call
and
we
will
set
up
a
schedule
following
this
IETF
to
get
those
processed
as
well.
So
we
know
some
of
the
authors
have
been
quite
eager
to
to
get
on
with
that
and-
and
we
are
doing
our
best
to
to
get
through
the
through
the
list.
A
A
A
A
D
Okay,
so
regarding,
if
you
hit
all
updates
that
we
are
requiring
from
the
office,
so
sometimes
it's
working,
sometimes
it's
not
working.
We
are
really
expecting
to
get
in
between
updates
for
all
the
editors
of
working
group
documents,
so
we
can
track
if
there
is
something
going
wrong
or
if
you
are
blocked
and
if
we
can
probably
help
in
any
way
yeah.
So
young
models
are
really
the
one
which
are
yeah
harassing
really
slowly
right.
F
This
is
Mancha
from
Siena,
both
for
l2
VPN,
any
VPN
right
yang
model
size.
You
say
we
did
not
make
any
progress
in
the
last
six
months,
but
we
are.
We
are
planning
to
finish
it
up
as
soon
as
possible.
There
are
very
few
things
left,
I
mean
obvious.
When
you
are
at
the
last
stage,
the
newer
things
crop
up.
People
want
different
things
in
it
and
we
recognize
the
Nate's
and
a
couple
of
items
that
we
need
to
so
we'll
have
to
gather
all
the
other
co-authors
and
get
it
done
before.
D
F
G
G
H
H
H
Good
afternoon
folks,
so
I'll
be
talking
on
behalf
of
proxy
draft
author,
and
we
had
a
working
group
last
call
I,
think
two
weeks
back
two
or
three
weeks
back
when
working
group
last
call
passed
for
this
document
and
thanks
to
her,
he
had
pretty
good
comment,
and
one
of
the
comment
was
about
one
field
in
the
NLRA
of
route
type.
Eight,
and
after
having
multiple
discussion
among
authors,
we
don't
see
that
there
is
any
real
use
case
for
that
particular
field.
H
So
we
had
couple
of
half
sons
and
there
is
one
proposal
which
I
would
like
to
bring
to
the
working
group
and
see
the
feedback
from
the
room
as
well,
and
the
scope
of
this
change
will
be
limited
to
multihoming,
peers
and
majority
of
the
I.
Think
deployment
are
cases
where,
most
probably,
you
will
have
same
vendor
multihoming
peers
and
these
routes
are
scoped
within
same
ESI.
H
So
right
now
the
NLRA
looks
like
in
the
left
side,
and
it
has.
There
is
something
called
as
a
leaf
sync
sequence
number,
and
this
route
is
nothing
but
IGMP
leave,
and
we
don't
think
that
there
is
any
use
case
where
we
have
to
send
IGMP
leave
sequence
number,
and
we
did
speak
to
a
couple
of
vendors
who
have
implementation
and
none
of
them
find
any
real
use
case
for
sequence
number
to
be
used.
So
one
of
the
proposal
is
to
to
keep
it
clean.
H
Remove
that
complete
four
bytes
from
the
NLRA
and
NLRA
will
look
something
like
in
the
right
side,
since
there
are
already
existing
running
code
in
the
field,
who
might
be
using
the
old
version
of
NLRA.
So
one
of
the
proposal
was
to
in
the
BGP
we
would
accept
both
both
of
the
routes,
so
it
it
might
come
with
NLRA.
What
is
the
new
value?
Let's
say
that
it
is
X
and
it
might
come
with
X
plus
4
bytes
as
well.
If
it
is
implemented
in
the
older
version.
J
Just
want
to
bring
up
Micah
for
this
work
group
consideration.
The
sequence
number
is
part
of
key
for
BGP
and
an
eye
for
type
six,
a
type
eight
evpn
routes,
so
I
would
request
to
support
backward
compatibility,
because
this
is
something
we
cannot
take
lightly.
This
is
not
part
of
attribute
for
tenon
I.
This
is
BGP
key,
so
if
we
support
have
lens
with
without
this
sequence
number
as
a
key,
you
know
it
seems
to
me
like.
J
In
order
to
achieve
this,
the
key
has
to
be
consistent
for
people
to
support
sequence
number
as
a
part
of
key.
This
has
to
be
there
and
an
eye
has
this
has
been
there
defined
like
this
for
past
three
years,
so
backward
compatibility,
that's
a
problem
to
take
it
out.
It's
a
key:
it's
not
a
attributes!
J
K
Jeff
has
so
I'm
going
to
build
and
the
other
two
points
made
for
slightly
different
reasons.
I
spend
a
large
portion
my
day,
job
dealing
with
BGP
incremental
deployment
issues
of
the
negative
consequences
when
you
get
it
wrong.
Mmm-Hmm,
the
general
rule
set
that
you're
violating
is
that
once
a
NL
or
I
type,
forgive
at
a
fee
Saffy's
been
defined.
You
can't
change
it
because
once
you've
changed
the
key
or
the
syntax,
the
reaction
that
the
receiving
pure
and
receiving
something
it
doesn't
understand.
K
For
whatever
reason
you
know
that
when
it's
syntactically
incorrect
is
to
drop
the
session,
so
what
you
are
showing
up
here
is
drop
the
session.
If
you
want
to
make
these
things
on
a
box
by
a
box
change,
that's
partially
what
bgp
capabilities
are
for.
You
can
get
variances.
That
way,
you
know,
and
it's
like
a
patch
situation.
K
If
you
really
want
to
it's
not
generally
a
good
idea,
because
you
then
have
to
figure
out
how
this
flows
across
the
entire
network,
my
recommendation
would
be
the
field
it's
preserved,
even
if
it's
considered
useless
I
would
leave
it
to
the
experts
on
EVP,
honest
what
that
field
should
contain.
But
minimally,
though,
if
since
it's
a
fixed
byte
value
in
the
current
PD,
you
know
stick
zeros
in
there
or
whatever
makes
you
happy.
K
If
that's
a
necessary
thing,
there's
already
precedent
for
that,
then,
like
multi-protocol
bgp
has
a
field
that
used
to
be
called
SNP
a
it
hasn't
been
used
for
that,
since
it
was
originally
specified
and
now
on
the
update
of
the
spec,
it's
just
the
magic
zeroes
value
so
don't
be
afraid
to
waste
space
in
the
NRI,
because
the
consequence
is
that
what
you're
doing
is
basically
potentially
making
the
network
unstable,
making
it
drop
sessions.
You.
K
Unfortunately,
the
problem
is
that
it
fort
to
accept
both
of
them:
you'd
have
to
change
the
route
type
if
you're
willing
to
define
a
basically
a
version,
two
of
this
route
type
and
allow
for
the
procedures
that
do
that.
That
would
be
acceptable.
But
if
you
can't
change
the
existing
one,
because
you
have
code
out
there
that
will
treat
in
either
direction,
it
is
a
syntax
here,
I'm
going
to
offer
a
little
bit
of
reading.
K
H
L
For
that
Nokia
I
think
we
have
an
issue,
no
matter
what,
because
there
are
two
shipping
implementations
in
the
field
with
different
route,
key
with
or
without
the
sequence
number.
So
what
I
would
do
I
mean
this
presentation
is
very
good
because
it
raises
awareness
of
the
issue,
but
I
would
also
send
an
email
to
the
list
so
that
you
know
other
vendors
with
potential
implementations
can
also
say
something
about
it
and
yeah.
My
preferences
still
would
be
to
remove
something
that
has
no
use
in
the
air
in
the
route.
H
M
Chris
power
is
juniper
networks.
I
mean
it's
good
to
raise
awareness
of
the
issue,
but
you
know
you're
asking
for
feedback
from
the
working
group,
but
not
really
supplying
the
information
about
the
actual
implementations
right.
You've
sort
of
address
presented
this
as
if
it's
a
green,
you
know
this
is
the
draft
zero
2
of
this,
whereas
they're
shipping
implementations,
so
it
would
really
be
good
to
actually
go
into
the
details
of
the
backwards,
compatibility
and
say:
okay,
there
are
multiple
implementations
doing
things
differently
and
saying
this
would
be
the
impact
of
doing
this.
M
This
would
be
impact
of
doing
this
and
really
get
him
that
detail
as
opposed
to
sort
of
a
hypothetical.
You
know,
oh,
if
we're
designing
this
from
scratch,
what
would
it
be
so
in
your
email
to
the
list?
It
would
be
good
to
actually
get
into
that
level
of
detail,
because
you
know
someone's
gonna
be
unhappy
with
the
final
decision.
I
believe
yeah.
N
Q
Patel
arcus
I
know
you
talked
with
me
about
this
and
sorry
if
I
was
jet-lagged
back
then,
but
if
you
wanna
take
that
filled
out,
you
have
an
existing
implementations
and
if
they're
doing
a
strict,
NLRA
check,
there's
a
chance,
you
might
bounce
a
session.
If
you
want
to
take
the
filled
out,
maybe
you
want
to
use
some
kind
of
a
capability
exchange
to
indicate
the
new
NLRA
field
or
the
size
has
been
changed,
I'm,
not
sure.
N
N
O
Well,
I
hypo
one
from
highway
color
we
see.
We
think
that
if
you
delete
this
second
number,
although
it
may
be
no
some,
not
some
news,
but
it
will.
You
must
consider
how
to
involve
with
other
vendors,
because
some
in
some
manner
hi
were
implementing
information
disease
and
also
many
many
many
operators
I
want
to
each
here
many
vendors
who
in
Harper
with
each
other
so.
H
P
D
Q
Hi
good
afternoon,
so
just
fairly
quick
updates,
this
drafts
been
discussed
a
few
times
before
so
not
significantly
new.
So
just
a
quick
reminder,
this
is
essentially
a
mobility
draft
that
details,
mobility,
procedures
and
sequence,
number
assignment
procedures
across
various
evpn
IRB
scenarios,
as
well
as
duplicate
address
detection
procedures
across
these
scenarios.
Q
What's
changed
since
the
last
revision?
There's
basically
one
new
section
on
mobility,
convergence,
which
essentially
details
specific
triggers
where
arc
or
nd
probes
may
be
used
to
speed
up
mobility
convergence,
and
it
also
kind
of
shows
how
the
fundamental
idea
within
the
draft
that
is
used
for
sequence
number
inheritance,
may
also
be
used
for
this
specific
convergence
scenarios.
Q
Q
Okay,
so
this
one's
also
been
discussed
a
few
times
before
this
is
again
just
recapping.
This
is
essentially
defines
handling
or
usage
for
link
bandwidth
attribute
in
route
type
1
for
unequal
load,
balancing
of
overlay,
unicast
traffic
from
remote
piece
based
on
ESI
bandwidth
distribution,
as
well
as
defines
usage
of
link
bandwidth
attribute
in
route
type
phone
for
DF
election
for
the
ESI
in
proportion
to
the
bandwidth
distribution.
For
that
ESI.
Q
For
the
DF
election
part,
it
essentially
defines
how
this
how
the
link
bandwidth
attribute
is
to
be
used
for
each
of
the
four
odd
DF
election
algorithms
that
are
defined
today.
So
no
major
updates.
Since
last
time,
I
mean
the
last.
The
last
update
to
the
draft
was
essentially
addition
of
weighted
HRW
DF
election,
which
is
such
as
soft.
Q
Again
from
draft
perspective,
this
is
ready
for
last
call.
It's
been
fairly
stable.
There
was
an
AI
last
time
to
kind
of
check
on
the
implementation
status
from
Cisco
side.
I
did
check,
it
has
not
been
implemented,
yet
it
is
fairly
close.
It's
kind
of
like
in
design,
but
it's
not
it's
not
implemented
yet
so
I
wanted
to
kind
of
you
know
also
check
with
any
other
vendors
anyone
else
who's.
Aware
of
any
other
implementations
to
let
the
authors
know,
that's
it
on
this
one.
Any
any
questions
comments.
Q
Okay,
so
PC
control
plane
for
evpn.
This
is
this
is
a
draft
that
was
first
presented
in
Prague
couple
of
ITX
back
since
then,
it
has
gone
through
a
couple
of
revisions
and
couple
of
name
changes
that
I
will
cover
just
a
recap.
Without
going
into
all
the
details
again,
it's
essentially
defines
a
PC
control
plane
for
Mac,
Mac,
IP
and
prefix
learning.
The
main
motivation
behind
this
draft
is
essentially
to
provide
an
alternative
control
plane
based
alternative
for
learning
that
is
decoupled
from
data
plane,
traffic
for
simplicity
and
more
deterministic
behavior
as
well.
Q
As
may
I
mean
the
biggest
sort
of
use
case
that
has
been
kind
of
detailed
in
the
draft
is
essentially
how
it
simplifies
a
lot
of
the
learning
and
convergence
scenarios,
particularly
across
a
multihoming
lag,
based
learning,
so
revisions,
since
it
was
lost,
presented,
there's
a
new
use
case.
That's
been
added.
It's
essentially.
It
has
extensions
added
for
a
CD
to
be
able
to
signal
a
desired
SLA
to
an
EVP
NP.
That's
essentially
extends
the
existing
Mac
and
Mac
IP
tlvs
that
are
defined
in
the
drop.
Q
Two
also
carry
a
desired
SLA
value
to
the
PE
and
the
main
idea
there
is
essentially
to
to
enable
any
VPN
or
the
set
of
E
VPN
pease
to
be
able
to
provide
an
SLA
based
service
to
a
c
e,
which
is
essentially
be
able
to
route
or
bridge
traffic.
To
that
c
e
on
traffic
engineered
paths
in
order
to
meet
the
c
requested
SLA.
Q
The
other
changes
that
it's
kind
of
gone
through
3dl
protocol
that
this
draft
is
based
on.
As
the
underlying
protocol
has
gone
through
some
revisions,
it
was
L
SOE
earlier
and
now
it's
l
3d
L,
so
it
basically
incorporates
changes
that
have
that
have
happened
in
the
base
protocol
to
be
in
sync,
with
the
latest
l
3d
inspect
other
than
that.
It's
basically
replaces
these
older
versions.
Q
The
first
one
was
called
EVP
analyst
OE
and
the
next
one
was
called
EVP
NL
3dl
that
the
draft
does
also
now
explicitly
mentioned
with
the
work
happening
on
lldp
v2
that,
even
though
the
craft
is
currently
based
entirely
on
l3
dl,
there
are
future
extensions
possible
to
incorporate
new
underlying
protocols
like
L
LD,
be
v2
and,
and
that
is
inflected
in
the
name
change
for
the
draft
as
well
overall
status.
It
is
still
work-in-progress,
largely
so
yeah.
Any
any
input
interest
comments
more
than
happy
to
collaborate
and
take
feedback.
R
R
R
The
section
for
essentially
was
going
over
the
the
port
active
DF
mode
and
what
we
did
is
we
expanded
an
entire
section
to
address,
essentially
the
the
orthogonal
of
the
orthogonal
T,
sorry
of
this
new
pivot
and
the
three
existing
DF
election
modes.
So
we
added
a
section
for
essentially
the
RFC
7432
DF
election,
the
modulo
based
one
with
a
change
that
we
received
I
figured
it
was
on
the
alias
or
or
at
the
last
IETF
to
to
select
a
different
bite
for
the
modulo
operation
or
a
different
set
of
bytes.
R
R
R
R
So
we
went
into
more
detail
of
the
to
ESS
solution
and
how
this
draft
improves
upon
that
ESI
solution.
But
we
actually
went
through
all
the
steps
of
how
this
can
also
be
achieved
with
a
ESI
solution,
then,
based
on
some
feedback,
we
also
added
a
section
addressing
essentially
the
route
resolution
of
a
of
a
remote
PE
that
operates
in
strict
7432
mode,
because
if
you
recall
in
the
proto
draft,
essentially
we're
claiming
a
1/3
1/3
load-balancing
bit
in
the
in
the
ESI
label,
extended
community
and
remote.
R
Peas
may
not
understand
this
this
new
bit
and
they
would
essentially
then
operate
in
all
active
mode.
So
we
addressed
that
in
this
new
section,
so
the
convergence,
the
and
the
mobility
sections
we
already
addressed
after
the
the
last
night
or
two
ATF's
ago,
based
on
feedback
we
received.
So
this
0
5
version
of
draft.
If
you
go
over
the
diff
I'm
really
sorry
about
that,
but
we
switched
from
the
source,
for
men
are
off
to
XML.
So
there's
quite
a
bit
of
formatting
noise
in
there.
R
L
Ok,
I
still
find
a
few
things
quite
confusing
in
the
draft
and
I
can
send
you
guys
an
email
later.
But
so
one
of
the
things
is
the
trophy
is
valid
for
pure
layer,
two
and
also
for
IRB
on
the
ring
piece
and
at
some
point
you
talked
about
using
our
probes
when
you
have
a
Mac
flush
in
one
of
the
peas.
But
it
isn't
clear
to
me
if
it
works
in
the
pure
layer,
2
scenario
or
not,
because
in
that
case
you
may
not
even
know
that
the
ARP
entries
of
the
connected
hoses
okay.
L
Yeah
yeah
I
can
I
can
let
you
know
the
other.
The
other
comment
is
so
in
the
past:
I
suggested
to
use
for
the
Mac
flash
message,
the
Mac
mobility
X
in
the
community,
and
that
it
seems
that
you
guys
added
that,
but
the
still
you're
calling
it
McFly
text
in
the
community
and
in
the
Ayana
section
you
are
requesting
a
value
for
it,
which
is
not
needed.
Although.
R
R
D
S
Okay,
good
afternoon,
okay,
so
this
time
we
got
some
comments
from
the
mailing
list
and
also
from
IT
105
about
this
bgp
usage
or
sd-1.
This
time,
I'm,
primarily
just
goes
through
different
scenario,
how
we
use
PGP
to
scale
sd1,
so
the
purpose
is
really
to
show
to
the
other
s
deals
or
industry
places
like,
for
example,
map
has
this
sd1
project.
They
have
lots
of
debates
on
how
to
achieve
some
of
this
management
on
the
IPSec
tunneling
and
using
PGP
actually
make
it
very,
very
nice
solution,
so
this
it
just
shows
them
see.
S
For
example,
in
this
case
you
may
have
I'm
just
using
one
p1
CPE
SE
p2
as
an
example.
If
you
two
have
three
attach
routes
and
with
the
regular
PGP
update,
you
basically
have
the
Browse
encoded
in
the
allow
I
pass
attribute
and
using
the
tunneling
cap
to
indicate
detailed
property
of
the
tunnel
and
true
that
tunnel
in
cap
today
doesn't
have
the
IPSec
properties
encoded
in
IDR.
S
There
is
a
draft
discussing
how
to
weigh
at
that
particular
IP
sac,
so,
but
the
one
difference
in
IPSec
is
in
a
way
that
is
very
different
than
our
traditional
configuration
and
normally,
when
you
configure
IPSec,
which
is
always
the
point-to-point
protocol
like,
for
example,
on
the
on
the
note
c
p2.
When
you
configure
IPSec,
you
usually
have
to
configure
who's
your
remote
end
and
who
see
a
remote
subnet,
for
example,
for
the
CPE
one.
S
You
have
to
basically
configure
them
who's
your
certificate
and
who's,
a
remote
and
such
effect.
So
when
you
receive
a
request,
you
can
validate
your
certificate
and
then
be
able
to
establish
that.
So
we
assume
in
this
in
this
sd1
case
we
have
a
reflector
at
home
and
which
has
a
policy
to
to
determine
where
this
update
is
forwarded.
To
you
couldn't
have
a
network
consists
of
hundreds
of
nodes
and
its
route
reflector,
basically
sending
it
to
like
CPU,
1
and
CP
3.
S
Another
thing
is
those
routes
attached
to
the
CPEs:
they
are
not
routable
in
the
underlay
when
network,
and
so
it
is
very
important
in
a
bgp
update
to
include
the
next
half
that
with
routable
address
so
that
remote
end
can
establish
actually
continue
or
can
test
whether
this
node
is
reachable
or
not.
So
that's
slightly
different
than
our
traditional
impairments
VPN.
S
So
this
example
shows
the
fine
grant
encryption,
meaning
that
for
the
three
different
routes
attached
to
CP
2,
each
of
them
have
their
own
IPSec
tunnels.
So
with
that,
you
need
to
send
three
different
update,
so
this
shows
that
the
PGP
apps,
like
CP
2,
was
an
update
1
with
the
first
route
encoded
in
the
and
I
passed
attribute
and
then
IPSec
property
in
the
tunneling
cap.
Then
there's
an
update,
2
and
then
that's
updates
3.
So
similarly,
you
can
allow
the
remote
end
to
aggregate
all
the
routes
or
you
can
do
individually.
S
As
seen
the
idea,
the
drive
talks
about
remote
local
pairs.
That
configuration
is
very
complicated.
It
works
well
when
you
just
have
two
nodes
are
talking
to
each
other,
but
when
you
have
multiple
nodes,
they
become
a
really
big
mess,
so
in
this
case
we're
using
PGP
to
update
their
own
information.
For
example,
c
p2
is
the
authentication
method,
whether
it's
a
H
authentication
or
ESP
authentication,
his
public
key
Rob
reflector,
distributed
to
the
other
cities
which
I
in
the
scope
to
be
able
to
authorize
to
talk
to
the
CPU.
S
This
is
another
example
which
has
been
discussed
a
lot
in
the
math
recently
they
called
application
based
segmentation
in
s
t1,
so
so
for
s.
T1
will
most
people
know
that
this
SD
one
for
the
traffic,
the
past
augmentation?
Basically,
you
can
aggregate
multiple
paths,
but
there's
two
other
characteristics
so,
and
one
of
them
is
based
on
forwarding
based
on
application
ID
instead
of
a
destination.
S
So
in
this
example,
for
the
retail
business,
for
example,
you
could
have
red
is
the
one
application
for
the
payment
system
so
for
payment
system
you
can
only
talk
to
the
payment
gateway.
You
cannot
communicate
with
anybody
else
so
that
particular
application
only
can
go
to
the
payment
gateway
and
for
the
purple
applications
and
you
can
actually
is
any
to
any
mash.
So
the
two
cases
assume
that
this
application
actually
have
unique
address.
Then
BGP
can
be
used
very
nicely.
S
We
can
send
to
update
from
CPE
twos
perspective
well
update,
to
show
the
red
apology
like
from
CPE
to
the
red
topology
is
only
to
payment
gateway,
so
in
the
you
have
route
attached
to
this,
IP
sacs
are
attached
to
this.
The
route
encoded
in
the
past
and
now
I
pass
attribute,
and
you
have
the
tunnel
to
describe
that
tunnel
is
only
from
Gateway
to
you,
then
for
the
purple
one
you
can
have
all
the
routes
and
then
you
can
indicate
different
tunnels
with
different
locations,
so
that
works
pretty
well.
S
Ok,
so
this
example
shows
that
just
from
CPE
twos
perspective,
because
IPSec
tunnel
is
all
point
to
point,
so
you
need
to
establish
all
the
pointer
pointer
nose.
So
that's
a
lot
of
configurations.
This
is
just
one
node
and
then
from
all
the
cps
any
to
each
of
them
need
to
have
this
basically
stand
and
square
problem.
S
S
We
may
retreat
IPSec
as
the
transport
tunnel,
meaning
that
connecting
the
nose
together
through
the
untrusted
Network
and
then
the
traffic
can
be
routed,
meaning
that
each
of
the
CPE
will
process
the
BGP
update
propagated
by
the
route
reflect
reflector
and
based
on
the
BGP
update.
It
can
build
up
the
falling
table
and
then
can
route
to
the
destination.
So
with
this,
the
number
of
IPSec
tunnels
to
be
created
and
much
much
less,
but
then
this
introduced
a
new
problem,
which
is
the
traffic
engineering
right.
So
for
the
path
between
CPU
1
to
cp24.
S
S
Five
to
now,
we
added
a
more
detailed
packet
walk
through
the
control
signal,
what
walks
through
and
so,
hopefully
we
can
ask
for
working
group
adoption
and
with
the
working
group
adoption
we
can
bring
it
to
other
places
like
math
or
to
show
hey,
IETF
PGP
actually
is
very
good
and
you
don't
have
to
bring
Bend
will
do
another
thing.
Just
use
this
to
achieve
what
you
need.
That's
it.
D
S
D
Okay
guys,
so
this
draft
is
a
kind
of
follow-up
of
the
discussion
which
started
in
Montreal,
so
there
was
a
nish
appointed
on
the
mailing
list.
It
was
a
thing
back
in
June,
which
was
that
basically
regarding
the
VPN
unique
sfe,
so
we
have
multiple
RFC's
dealing
with
this,
so
we
have
a
4364
dealing
with
a
VPN
which
form
of
ipv4
network.
D
We
have
the
46:59,
which
is
dealing
with
VPN
v6
over
ipv4
or
ipv6
network,
and
we
have
the
5549,
which
is
dealing
with
VPN
before
over
an
ipv6
network,
and
the
comment
that
was
made
on
the
mailing
list
was
that
we
55:49
is
bringing
a
kind
of
inconsistency
on
how
we
are
including
the
next
stop
in
via
envy
bgp
update.
So
usually
in
the
VPN
service.
We
are
encoding.
D
Then
we,
then
we
preface
again
it's
it's
completely
useless
and
it
does
not
make
sense
but
yeah.
That's
our
only
guess
from
a
pure
standardization
standpoint,
it
works,
there
is
no
arm
and
it
could
work
because
we
have
envy
5549.
We
have
a
specific
BGP
capability
which
tells
that
we
are
in
a
specific
case,
so
specification
from
a
pure
specification
standpoint.
D
It
works.
However,
if
we
look
at
how
the
industry
is
today,
so
we
have
looked
at
nine
beach
implementation
that
are
shipping
now,
including
all
the
major
vendors,
and
what
we
have
found
is
that
on
this
nine
bgp
codes,
we
have
seven
of
them,
which
are
following
a
consistent
way
of
encoding,
the
next
step,
which
means
that
in
the
case
of
5549,
we
are
including
the
next
stop
using
a
VPN
IP
address.
So
we
are
consistent,
but
not
compliant
with
the
55:49,
and
we
have
two
codes
that
are
not
supporting
the
future
at
all.
D
So
we
have
an
issue
from
an
industry
point
of
view.
The
issue
is
not
an
interoperability
issue,
because
maybe
by
chance
everyone
is
interoperable,
because
at
least
all
the
implementations
that
we
have
seen
are
interoperable
because
between
each
other,
because
we
are
using
this
VPN
IP
next
up,
maybe
by
chance
but
yeah,
it's
working
this
way.
The
issue
is
now
a
kind
of
compliance
issue,
because
all
these
implementations
are
not
compliant
today
to
vrse.
D
So
what
we
would
like
to
propose
is
to
change
55:49
to
accommodate
the
reality
of
the
shipping
code
today
and
yeah
the
reality
of
the
deployments.
Of
course,
it's
not
a
trivial
change
to
say
that
blindly
we
are
moving
to
a
regular
IP
address
in
the
next
stop
to
to
the
VPN
IP,
but
yeah.
This
is
mainly
the
spirit
of
ITF,
which
is
mainly
driven
by
running
codes.
So
we
really
think
that
this
is
the
way
to
do,
and
the
other
point
is
of
cool.
D
We
could
get
all
this
implementation
to
move
to
compliance,
but
what
will
be
the
value
of
changing
all
the
codes?
It
will
be
just
pain
for
the
customers.
It
will
be
pain
for
the
vendors
and
also
we
will
possibly
introduce
bugs
in
with
the
implementations
each
time
you
have
touching
your
code,
possibly
you
will
introduce
new
bugs,
so
it's
purely
a
risk
for
customers
without
bringing
any
value
from
an
industry
point
of
view.
D
Backward
compatibility,
of
course,
if
we
go
to
this
straight
change
of
changing
the
55:49,
there
is
no
backward
compatibility,
which
means
that
if,
but
it
is
unlikely,
vary
somewhere,
an
implementation
which
is
compliant
with
55:49.
We
will
this
implementation
will
not
be
compliant
anymore
and
it
will
not
be
interoperable
anymore,
but
main
question
is:
do
we?
Are
we
really
creating
any
arm?
D
There
are
three
things.
First,
one
is
today.
There
is
no
possibility
to
mix
an
implementation
which
is
consistent
with
an
implementation
which
is
compliant
okay,
because
we
don't
have
interoperability
between
between
them.
So
in
case
there
is
an
existing
deployment
somewhere,
which
is
using
routers
that
are
fully
compliant
with
55:49.
D
This
deployment,
we
will
not
really
break
anything
because
it
can
keep
living
like
this.
It
will
not
be
compliant
anymore,
but
if
the
vendor
is
not
changing
its
implementation,
it's
not
breaking
any
deployment.
Of
course,
if
we
wants
to
get
to
come
to
the
new
compliancy
knob
could
be
added
of
something
to
enable
future
interrupt
with
an
additional
vendor
which
is
using
VAP
next
up
and
for
the
existing
real
deployment
that
we
know
that
are
using
this
VPN
IP
address
today.
D
There
is
no
change
at
all,
and
this
is
really
what
we
the
spirit
that
we
want
to
are
to
share
areas.
We
want
to
have
the
less
change
in
the
code
widely
in
the
industry,
as
we
can,
so
it
seems
that
most
of
the
implementation
today
are
using
this
VPN
IP
code.
Possibly
yes,
there
could
be
somewhere
an
implementation
which
is
fully
compliant
with
5549,
but
maybe
it's
just
one
or
two.
It
may
be
easier
to
change
this
one
compared
to
the
massive
ones
that
are
already
deployed
today.
D
In
addition
to
this,
in
fact,
there
is
a
very
small
thing
which
is
also
missing
in
the
5549,
is
that
it
does
not
address
via
safely
129,
which
is
via
VPN
for
multicast
address,
and
we
just
also
would
like
to
add
some
text
that
yeah
see
this.
A
few
ways
will
be
exactly
will
use
exactly
the
same
procedure
as
we
do
for
front
of
ships
and
for.
D
So
we
really
think
that
this
is
a
reasonable
proposal,
because
yeah
first,
that's
really
the
spirit
of
ITF.
We
show
them.
We
are
driven
by
running
code,
so
yeah
it's
a
bit
unusual
here,
but
we
need
to
accommodate
the
standard
to
the
reigning
code.
Of
course,
if
anyone
has
any
feedback
about
existing
implementations
that
are
fully
compliant
with
5549
and
deployed,
we
will
really
be
happy
to
hear
about
this
because
we
need
to
focus
not
just
on
theory.
D
I
D
D
5549
is
coming
from
software,
which
is
in
via
internet
area,
so
Evernote
now
in
our
domain,
but
the
VPN
selphie
are
usually
managed
InBev
in
this.
So
if,
of
course,
the
working
group
agree
to
go
to
a
change
of
55:29,
we
would
like
to
have
this
managed.
In
best
we
have
already
engaged
execution
with
martin
and
also
with
a
diesel
from
our
own
software
on.
I
think
we
have
an
almost
an
agreement
on
that.
D
Yeah
and
again
in
case,
we
agree
to
continue
with
this
kind
of
work.
What
do
we
and
if
we
agree
to
we
spin
on
5549?
What
do
we
do
with
this
document?
Do
we
just
forget
it
and
we
spin
55:49?
Oh,
do
we
keep
it
and
progress
it
at
the
same
times,
I've
the
new
55:49
just
for
estoy
purpose,
yeah,
that's
it!
No!
What
okay.
T
So
first
I
kind
of
agree
with
most
of
what
you
said:
I
think
it's
a
reasonable
plan.
We
probably
should
go
ahead
and
do
it.
The
tricky
issue
is
if
there
is
a
compliant
implementation
out
there
somewhere,
that
we
don't
know
of
what
situation
do
we
actually
put
that
vendor
in?
If
we
change
the
standard
are
underneath
them,
so
that
say.
B
T
T
E
E
E
T
Well,
if
I
have
a
compliant
implementation
and
you
change
the
standard,
you
actually
changed
my
market
situation
quite
a
bit
hope
we
agree
there
I'm,
not
saying
that
it
is
the
case,
but
I
say
there
is
a
potential
case
and
that
we
should
actually
look
for
and
make
sure
that
there
is
no
compliant
implementation
hanging
around
somewhere.
I,
don't
know
about
lawyers
I,
just
kinda
I
would
seek
advice
from
the
people
that
could
advise
me.
T
I
I
Actually
I
mean
I
a
few
few
weeks
ago,
when,
when
I
first
heard
about
this
thing,
I
was
sort
of
like
more
in
the
position
that
I
guess
Lola
finds
himself
in.
At
this
point,
I
I
find
myself
convinced
that
you've
already
been
diligent
enough
and
and
as
both
Laura
and
Martin
said,
you
change
the
RFC
number.
You
know
old
implementations
are
still
compliant
with
5549
new
implementations.
N
Marcus
speaking
as
a
coder
and
working
group
member
I
think
this
is
a
good
work.
We
should
do
it
ASAP
if
you're
too
paranoid
about
any
compliant
implementations
out
here.
We
could
probably
use
the
same
office
aathi
and
use
new
capability
and
get
done
with
it
like
how
we
did
RFC
3107.
We
spent
mm-hmm.
V
A
conf,
Cisco
I
think
the
fact
that
anybody
that's
interrupting
today
would
be
broken
and
the
fact
that
we're
doing
it
through
a
biz
document
which
will
take
a
minimum
of
a
year
that
should
be
enough
time
for
any
nascent
or
implementations
to
be
discovered.
I,
don't
I
think
this
is
much
to
do
about
nothing.
The
fact
that
we
haven't
found
one
just
in
you
know
the
the
survey
that
you
you
took
off
the
time
to
do
so.
I
think
I
think
this
is
I,
think
this
is
kind
of
ridiculous.
V
C
C
I
Probably
the
most
important
thing
is
to
get
a
new
version
out,
at
least
in
you
know,
some
rough
draft
form
that
you
know
updates
5549,
so
that
somebody,
I
wonder,
actually,
if
you
can
even
use
an
errata,
to
indicate
this.
Basically
what
you
don't.
What
would
be
most
embarrassing
right
now
is
for
someone
to
come
along,
find
5549
and
implement
it
newly,
not
very
likely,
but
it
would
be
quite
embarrassing.