►
From YouTube: IETF106-NVO3-20191118-1810
Description
NVO3 meeting session at IETF106
2019/11/18 1810
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
C
C
D
C
C
Okay
milestones,
so
I
I
pushed
back
the
dates
of
all
of
the
milestones
that
we
still
had
open
on
the
on
the
Charter,
but
we
probably
need
to
have
a
discussion
on
whether
or
not
we
need
to
add
any
any
new
ones
or
remove
anything
we'll
probably
take
that
to
list.
But
if
anybody
has
any
any
any
quick
comments
on
on
the
milestones,
please
please
so
it
comes
to
Mike.
C
Okay,
so
document
status,
so
the
new
RFC
since
the
last
ITF,
we
have
one
two,
three
four:
you
have
six
RFC's
in
total
the
data
plane
encapsulation,
so
our
standards
chosen
standards
track
so
encapsulation
document
genève
is
now
with
the
is
G.
It's
I
think
it's
just
completed.
Ietf
last
call
I
think
the
authors
are
just
stressing.
There
was
an
ayah
and
a
comment
on
where
to
create
the
the
genève
registry.
C
We
also
have
the
MV,
oh
three
design
team,
encapsulation
design,
team
output.
So
we
think
this
is
probably
ready
for
working
group.
Last
call
we,
if
you
recall
way
back
a
few
years
ago
for
who
went
into
this
process,
we
kind
of
decided
that
it
would
be
valuable
to
publish
the
output
of
the
design
team,
which
was
choosing
between
various
tasks
to
choose
between
or
make
a
recommendation
on
which
encapsulation
to
take
forward
as
as
a
standard
track.
C
So
we
will
probably
last
call
that
shortly
after
this
idea,
if
there's
anybody
actually
read
the
latest
version
of
this,
this
draft-
you
have
put
your
hands
up.
Okay,
one,
hopefully
running
through
working
group
rascal,
will
cause
some
small
folks
to
to
review
it.
We
also,
in
addition
to
our
standard
script,
track
encapsulation.
We
had
some
informational
encapsulation
drafts,
so
these
were
kind
of
some
of
the
other
options
that
were
considered
by
the
working
group.
The
only
one
that's
actually
alive
at
the
moment
is
V
X,
LAN
GPA
and
that's
on
the
agenda
today.
C
So
what
we
originally
said
was
once
we
had
sent
genève
to
the
ISJ
we
to
consider
last
calling
as
informational
documents,
the
other
encapsulations.
So
like
I,
said
that's
on
the
agenda
today,
our
distributed
control
plane.
So
we
have
an
e
VPN
draft
that
describes
how
to
apply
evpn
with
with
genève.
That's
now
with
with
Martin.
C
The
virtual
machine
mobility
draft,
so
this
has
been
through
working
group
last
call
a
while
ago.
I
owe
it's
a
document.
Shepard
write-up,
though
I
found
when
I
read
it
I
found
there
was
some
editorial
kind
of
nets
that
editors
are
now
working
on,
so
I'd
rather
wait
till.
They
fix
fix
that
and
then
I'll
I'll
post
a
review
of
it.
Hopefully
we
can
move
forward
quite
quickly
with
the
vmm
draft.
C
We
have
a
lot
of
security
drafts
that
Daniel
was
editing,
is
a
currently
individual
drafts
that
presented.
Some
of
them
have
been
presented
a
few
times,
particularly
the
journey
of
security
requirements.
We
did
try
to
try
to
adopt
the
journey
of
security
requirements.
A
couple
of
times
unfortunate
has
been
afraid
to
reach
consensus
for
working
group.
Adoption
I
think
we
need
to
have
a
discussion
about
how
to
proceed
with
these
drafts
I.
If
I
can
characterize
I
think
one
of
the
concerns
for
the
cause.
C
That
was
one
of
at
least
one
of
the
issues.
So
does
anyone
have
any
comments
on
how
how
to
proceed
with
these
drafts?
I
think
we
know
that
security
is
a
C
is
a
major
requirement,
and
it's
something
that
we
do
need
to
address
properly
and
one
of
the
reasons
we
went
into
this
exercise
of
developing
a
set
of
security
requirements
and
architecture,
and
some
proposals
for
protocol
enhancements,
for
that
was
because
the
security
area
does
require
us.
C
C
E
E
E
F
So
Martin
this
we
have
tried.
I
think
this
is
a
second
time
we
went
through
the
requirements,
security
requirements,
effort
right,
I.
Think
one
of
the
major
concerns
is
that
if
the
the
the
folks
who
wanted
the
security
requirements
or
security
aspects
or
very
few
in
this
working
group,
I
mean
I
believe
it's
across
the
routing
area
itself.
It's
not
just
this
working
group.
So
it's
getting
hard
to
really
get
the
expertise
of
the
security
aspects
to
really
come
up
with
good
requirements
and
solutions
related
to
that.
E
C
Okay,
MV
o3o
a.m.
so
we've
had
a
number
of
drafts
in
the
working
group
over
the
years
and
for
various
OEM
tools
and
for
encapsulations,
based
on
the
outfit
of
the
routing
area,
OEM
design
team,
none
of
which
have
been
adopted
in
working
group.
Unfortunately,
and
we
haven't
reached
any
kind
of
consensus
so
far
on
a
common
encapsulation
for
OEM.
C
H
I
No,
if
I
just
wanna
point
is
that
there
is
a
draft
that
will
present
it
in
Montreal.
It's
a
result
of
collaboration
for
authors
and
it
lists
I
think
that
even
for
possible
encapsulations
and
their
purpose
of
this
draft
is
not
to
be
published
or
not
necessarily
probably
published,
but
to
initiate
the
discussion
and
the
working
group
and
select
preferably
single
encapsulation,
because
multiplicity
of
encapsulations
in
OAM,
it's
a
headache
and
we
should
avoid
it.
C
D
D
Just
to
give
the
context,
I
mean
I,
think
the
group
here
is
aware,
but
this
is
way
to
extend
the
week's
learning
capsulation.
Basically,
the
protocol
type
that
allows
to
include
additional
header
after
the
after
the
the
week's
planet
in
a
sense
is
similar
to
Geneva
force,
as
you
guys
know.
Well,
so
we
basically
have
a
certain
number
of
protocol
values
from
h0
to
FF
to
protocol
that
I'll
define
she
matters.
This
protocol
has
a
fixed
format
and
the
idea
is
that
there
are
some
functions
that
can
be
added
to
the
protocol
itself.
D
These
headers
have
a
fixed
that
structure
and
can
be
easily
skipped,
even
if
they
are
not
completely
known.
So
this
is
the
text
that
is
in
the
in
the
in
the
actual
draft
in
inversion.
Oh
wait,
there
were
a
few
comments
on
the
list
suggesting
to
you
know,
make
a
little
more
clear
and
this
one-
and
this
is
the
changes
that
we
will
put
in
version
online,
specifying
that
I
mean
this
is
basically
this.
The
reason
why
we
want
to
introduce
the
concept
of
she
matters
here.
D
Think
that,
in
the
final
version
of
the
draft,
the
new
this
table
should
only
report
protocol
types
that
are
already
assigned,
so
probably
this
table
will
will
be
in
the
actual
corresponding
draft,
but
I
mean
at
this
point
is
in
there
and
one
comment
in
terms
of
applications
that
make
use
of
these
similar
capability.
My
experience
is
that
I
have
seen
some
people
that
are
designing
next
generation
of
Essex
and
basically
to
application
that
are
well
known
and
that
have
a
chance
to
be
in
the
in
the
next
generation
Isaac.
D
So
I'm
not
sure
if
this
is
the
right
working
group
where
this
conversation
could
happen,
but
certainly
one
question
that
I
hear
is
okay.
So
while
we
are
designing
and
I
guess,
jean-yves
is
probably
going
through
the
same
process.
Why
we
are
designing
the
next
generation
of
aphasics
that
support
jean-yves
or
via
an
GP
which
options
should
I
include
and
typically
the
comment
that
I
hear
is
that
I
mean
there
is
a
cost
in
allocating
buffer
for
particular
feature
of
the
protocol.
D
So
if
the
feature
is
specified
and
standardized,
then
there
is
a
better
chance
that
whoever
designed
this
component
decides
to
allocate
cost
to
to
basically
support
those
features.
So,
in
my
opinion,
it
would
help
if
in
some
group,
I
don't
know
if
it
is
this
one
or
what
it
is,
there
will
be
some
conversation
on
how
to
basically
use
this
option.
This
I
think
could
be
helpful
as
well
for
for
for
genève
and
I.
Don't
know
if
you
have
a
question:
I
can
take
it
now
or
later.
D
D
D
Reviewers
that
I
think
should
be
reflected
in
this
draft
as
well,
is
basically
about
transport
implications
and
how
to
be
compliant
with
RFC
885
about
UDP
encapsulated
packet,
so
I
think
I
should
we
should
basically
do
those
updates
and
then
I,
don't
know.
I.
Think
one
of
the
question
for
today
is:
does
it
make
sense
to
advance
to
this
draft
information?
You
know
go
through
Laska,
let's
call
and
and
do
the
due
process,
and
these
I
guess
is
a
question
that
we
will
discuss
later
and
that's
it.
Thank.
I
I
D
What
we
define
here
is
just
the
capability
to
identify
your
next
protocol,
and
then
you
know
we
define
these.
She
matters
with
a
fixed
structure.
So
when
you
pass
the
packet,
you
will
find
the
type
the
length
and
basically
the
next
protocol.
So
if
you
know
about
a
particular
protocol,
you
can
go
and-
and
you
know
pass
further
deeper.
If
not
you
know
you
just
skip
to
the
next
header
and
do
it
for
encapsulation
of
I/o
I
am
in
particular
I
mean
from
the
Vic's
LAN
GPE
point
of
view.
D
I
D
Are
I
am
protocols?
Yes,
okay,
I,
think
that
there
is
a
bit
right
and
that
is
will
be,
will
be
the
there
isn't
a
further
protocol
further
down
in
the
stock
right.
It
will
be
the
last
protocol
carried
it
and
if,
in
the
reason,
I
am
draft
for
OMB
for
that
that
is
used
to
identify
that
the
payload
of
the
actual
Vic's
LAN
packet
is
an
OEM
packet.
What's.
I
D
B
I
Another
thing
is
that
you
have
a
protocol
type
v,
BN
g
yeah,
so
I
can
assume
that
it's
for
control
and
user
plain
separation
use
case,
so
I
would
probably
name
it
for
cups
or
something
like
that,
because
control
user
play
separation
not
necessarily
specific
to
VB,
M,
G
and
V,
B
and
G.
Again,
it's
more
accurately
will
be
this
desegregated
bng
that
uses
it
because
part
of
it
can
be
a
physical
entities
and
part
of
it
could
be
virtualized,
so
either
it's
DB
ng
or
our
cups,
because
cups
is
more
generic.
D
Yeah
in
general,
I
mean
what
week's
LAN
GP
does
define,
defines
the
wrap-up
right.
Then
what
goes
inside
it?
It
depends
from
from
the
particular
extension
that
one
wants
to
define
so
yeah
and
as
I
say.
Probably
all
those
reference
will
disappear
because
I
mean
the
they
should
be
defined
in
the
actual
draft.
That
is
specifying
what
VM
BG's
or
what
GBP
is
or
what,
whatever
particular
extension,
one
wants
to
define.
D
D
So
I
mean
traditionally
what
what
is
done
in
practice
is
using
some
form
of
IPSec.
Whenever
you
know
Vic's
LAN
GP
is
carried
typically
outside
of
the
data
center.
If
you
want
to
secure
the
Vics
LAN
GP
layer,
what
you
could
do
is
define
one
extension.
It
is
probably
similar
to
the
work
you
guys
were
doing
for
genève
that
could
provide
authentication
or
could
provide
encryption
of
the
rest
of
the
payload.
That
is
not.
F
D
F
J
G
From
Hawaii
go
back
to
the
modifications
yeah,
so
here
you
mean
that
the
tunnel
and
points
which
is
declared
to
be
to
support
weeks
on
T
P
is
that
at
least
it
should
know,
there's
a
tab
and
there's
a
list
of
the
shim
header
so
that
it
can
skip
it.
So
if
our
tunnel
endpoint,
which
does
not
recognize
the
type
Orleans,
should
not
be
declared
to
support
a
big
sign
TP
at
all,
yes,.
D
D
G
The
second
question
is:
do
you
think
the
order
of
the
shim
headers
matter?
Because
there
is
one
draft
I
think
Sammy
is
it?
Was
craft
I,
don't
know
its
current
statue?
It
is
basically
it
is
extension
of
the
evpn
which
is
used
to
negotiate
the
the
order
of
the
different
theories
in
Geneva
I
do
think
it
is
a
firm
requirement
to
fix
ntp
or
not
so
I.
D
Mean
I
think
there
is
more
flexibility
today
in
the
way
hardware
is
working
in
terms
of
having
some
more
flexibility
in
terms
of
parsing,
a
header
like
this
one,
the
more
structure
you
can
give
to
the
other,
the
better
it
is
for
sure
I
mean
it's
hard
to,
and
it's
the
same
conversation
we're
having
before
right.
When
you
go
and
design
some
Isaac,
you
allocate
some
cost
to
support
some
of
this
feature,
which
one
do
you
support.
So
that
is,
and
is
really
you
know
the
the
aspect
that
is
is
relevant
here.
D
That's
why
I
mean
having
the
she
matters
in
front.
One
of
the
motivation
is,
it
helps
you
know,
designing
and
locating
buffer
to
to
handle
those
use
case.
Ordering
might
be
helpful.
The
problem
is,
which
is
the
order,
and
what
do
you
do
when
when,
when
you
don't
support
in
a
certain
order,
if
you
have
suggestion
yeah,
that
I
mean
can
help
it's
it's
hard
to
to
say
that
a
B,
C
and
D
should
should
happen,
and
then
right.
J
I
think
it
would
be
beneficial
if
we
would
be
able
to
agree
on
an
order.
I,
don't
think
that
we
are
ready
to
agree
on
an
order.
If
you
look
at
the
lengthy
discussions
were
having
for
roughly
20
years,
yeah
on
extension,
header
ordering
in
v6
and
where
it's
still
like
could
I
go
prior
to
your
header.
Please
you're
not
sure.
Well,
that's
a
useful
discussion
to
go
and
do
it
again
here.
Agree
and
I
mean
I.
D
G
G
The
IDF
will
Surya
and
it
is
called
a
base.
Jung
is
that
it
is
focused
on
a
common
and
useful
part
of
the
three
technologies,
such
as
excellent
imagery,
generics
Lassiter,
and
it
is
designed
to
be
complained
to
the
unwary
architecture
and
for
the
current
status.
This
draft
is
adopted,
is
working
group
documents
as
September
and
the
version
0
0
is
just
rewrote.
G
Errors-
and
you
know
okay,
so
here
is
just
a
overview
of
the
very
base
young
for
people
who
are
new
to
this
draft.
The
basic
idea
is
that
we
firstly
define
the
via
instances,
and
we
indicate
which
interface
which
ve
that
this
via
instances
is
attached
to
and
multiple
via
instances
can
be
attached
to
the
same.
G
Every
interface
and
the
interface
Steve
is
defined
in
a
way
that
we
augment
the
interface
young
and
there
are
other
features
like
the
BGP
controlling
enabler
and
disappear
in
the
east
and
multicasts
and
I
won't
go
into
more
details
here.
So
here
is
the
results
from
the
young
validator
now,
and
we
have
six
hours
and
the
two
earnings
and
forth
burnings
the
not
hearts
handle
and
the
father
errors.
There
are
two
errors
about
the
keywords:
I
just
realized
that
we
have
put
it
at
the
wrong
place
and
I
will
update.
G
That
means
in
the
next
version
and
the
other
versions
are
all
related
to
the
same,
to
the
same
thing,
which
is
the
IETF
BGP
as
will
be
n,
because
this
draft
is
not
an
RC
yet,
but
we
augment
this
young
in
our
draft
to
indicate
which
VI
instance
is
used.
I
style
our
3
VPN
and
the
ITF
bgp
else
will
be
in
this.
Draft
itself
has
appeared
for
now
and
so
for
the
next
step.
I,
don't
know
how
to
I.
Don't
know
exactly
how
to
handle
this
situation.
G
Probably
we
should
contact
the
ITF
BGP,
as
we
repeal
sirs
to
verify
if
they
will
keep
working
on
the
draft.
If
now,
because
this
is
the
the
only
Australian
young
in
ITF,
so
I
think
we
are
not,
it
is
not
easy
to
decouple
from
it.
So
I
would
like
to
to
the
working
group
in
this
situation.
If
we
go
faster
than
this
ITF
pgpr
a
VPN,
will
this
cause
a
miss
Roffe
situation
or
something
like
that.
K
C
C
G
C
B
Hello,
this
is
Eagle
I'm,
going
to
give
brief
introduction
on
this
loops,
which
is
an
ongoing
effort,
happened
in
transport
area.
But
what
kind
of
thing
is
relevant
to
a
Maori
working
group,
especially
when
we
talks
about
how
to
binding
how
to
bind
the
functionality
to
their
to
the
certain
protocols.
B
Okay,
there
are
a
couple
of
use
cases,
but
here
I'm
going
to
only
talk
about
er,
the
the
most
typical
one
thinking
about
we
are
trying
to
use.
We
call
it
cloud
Internet
overlay,
Network,
trying
to
use
the
cloud-based
rather
than
the
public
Annette
based
OH
when
pass
to
build
a
better
pass
via
the
overlay
nodes.
The
overlay
nodes
here
means
some,
possibly
some
virtual
machines
created
from
the
cloud
providers
over
different
geographical
sites,
possibly
in
multiple
or
single
cloud.
We
did
some
experiments
based
on
37
such
cloud.
We
call
cloud
routers
globally,
then
eventually.
B
In
fact,
we
found
we
found
there
basically
have
71
percent
chances
of
finding
a
better
path
in
terms
of
the
latency
I'm
not
going
to
give
order
data
here.
This
is
just
to
give
a
very
brief
introduction
so
that
we
found
out
there
are
still
that
the
problems
of
the
laws
still
exist
even
with
the
selected
path
so
loops,
the
local
optimization
of
path
segments
and
the
goal
of
it
is
trying
to
provide
so
called
the
local
in-network
loss
recovery
over
specific
segments
or
segments
to
optimize
the
packet
delivery.
B
So
here
the
segments
actually
means
the
valet
hub,
the
in
local
means
over
a
single
overlay
hub,
so
the
in
network
loss
recovery
can
be
done
either
by
the
real
transmission
or
by
the
forward
error
correction
FEC.
So
there
are
basically
three
fundamental
elements
of
loops.
The
first
one
is
their
local
recovery,
the
generic
information
model
and
it
can
be
encapsulated
in
a
variety
of
formats.
B
So
this
is
where
genève
jumping
here
so
genève
could
be
a
protocol
that
can
embed
the
loops
functionality
there,
possibly
some
others
like
gie,
which
giant
natively
has
already
the
sequence
number,
which
is,
which
is
a
little
bit
different
from
ginny.
Of
course,
there
are
some
other
elements
of
loops
like
the
in
order
to
make
sure
the
retransmission
happens
in
time.
There
might
be
some
local
measurement
and
also
in
in
order
to
not
interfere
with
the
end-to-end
TCP
retransmission.
B
B
It
gives
the
whole
picture
of
loops
function,
for
example
like
the
sequence
space
and
how
to
determine
the
initial
sequence
number
and
how
to
generate
the
acknowledgments,
whether
the
neck
or
positive
action
be
used,
whether
the
selecting
actually
be
used,
and
if
the
forward
error
correction
is
used,
what's
the
structure
of
it
and
how
to
how
to
detect
loss,
how
persistent
the
retransmission
should
be
only
reference
me
for
once
or
retransmits
for
a
certain
amount
of
time.
All
these
are
actually
more
like
transport
technology
related
that.
So
that's
why
this
work
is
in
transport
area.
B
If
you're
interested,
you
can
look
at
the
draft
here,
but
of
course
there
it
comes
to
the
encapsulation
eventually
so
de
genève
binding
should
define
the
format
when,
if
we're
embedding
the
loops
to
Geneva,
so
basically
it
tries
to
map
the
functions
to
Geneva,
define
the
data
plan
format.
Also
there
possibly
some
Geneva
specifics
that
need
to
be
taken
care
of.
For
example,
the
Geneva
has
a
mandatory
field,
the
code
vni
how
to
set
this
value
there,
possibly
that's
I,
remember,
remember:
there
is
a
CC
bit
which
will
control
bit
to
indicate
it's
more.
B
Like
a
control
message
with
our
payload
in
Geneva,
so
there
are
possibly
some
specifics,
so
there
is
a
there
is
a
draft
which
can
be
served
as
a
starting
point
for
this
mapping,
but
the
function
mapping.
This
is
a
proposed
that
looks
option.
I
mean
oh
good,
I'm,
I,
don't
think
we
should
go
to
too
much
details
here,
because
it's
very
initial
version
and
we
haven't
reach
the
stage
that
we
have
a
broad
consensus
or
what
kind
of
functionality
the
loop
should
achieve
so.
B
But
this
is
just
to
show
that,
in
order
to
embed
the
function
of
loops
there,
we
possibly
need
a
namespace
for
it
and
we
need
tags
to
indicate
like,
like
the
packet
sequence
number
and
also
the
some
flags
to
indicate
whether
times
then
be
there
or
act
number
or
in
the
and
the
the
the
different
information
fault.
Knowledge
meant
the
things
like
that
it
has
to
be
defined
eventually.
B
So,
just
for
your
information
loops
had
above
in
last
ITF
meeting
in
transport
area,
there
was
a
some
feedback
showing
that
the
standard
standardization
was
required.
So
if
you're
interested,
you
can
see
the
slice
deck
from
last
meeting,
so
we
are
going
to
discuss
in
more
details
for
the
design
issue
which,
including
the
encapsulation
and
possibly
some
some
other
issues,
but
I
guess
the
encapsulation.
It
might
be
of
interest
to
email,
three
attendees
here
so
they're
the
people
might
have
interested,
including
the
transport
protocol,
designers
and
the
tunnel
protocol
designers
and,
of
course,
FEC
experts.
B
L
L
L
L
L
We
can
see
within
the
outer
UDP
header,
the
random
destination.
Part
1681
is
used
to
indicate
the
Geneva
header
and
the
reason
the
Geneva
header,
the
prototype,
is
set
to
the
value
2
indicating,
but
to
indicate
the
Ethernet
frame,
the
beanies,
the
Jem'hadar
they're
in
the
Ethernet
header
in
the
IP
UDP
header,
all
the
fields
in
East,
the
genome
header.
We
are
follow
the
format
and
the
value
said.
L
This
is
the
second
encapsulation
for
our
PFD
fortune
Eve,
when
a
pivot
on
o
is
used
to
carry
IP
packets.
This
packet
from
it
will
be
used,
we
can
see
within
the
UDP
outer
UDP
header
destination
powder
is
the
same
always
approved
previous
one
and
the
reason
a
new
header,
the
prototype,
will
be
set
to
the
value
of
ipv4
or
ipv6
and
immediately
fall
follows
a
to
new
header.
L
There
is
the
inner
IP
header,
the
source
I
peeled
off
the
in
the
IP
header
will
be
the
IP
address
of
the
VAP
of
the
originating
MBE
and
destination.
Ip
will
be
the
IP
address
of
a
IP
of
the
terminating
Vee
and
under
the
IP.
Ttl
must
be
set
to
1
for
the
inner
IP
header
and
the
beneath
of
the
IP
header.
There's
a
you'd
be
higher
in
the
UDP
header.
There's
a
well
known
destination
port
3784
used
to
indicate
the
PFD
control
message.
L
This
is
the
third
one:
twenty
new
handle
is
used
to
carry
amperes
packets.
This
packet
format
will
be
used,
we've
seen
the
outer
OTP
header,
it's
the
same
with
the
previous
two
within
the
genève
header,
the
product
petticoat
ID
will
be.
You
will
be
said
to
the
value
of
MPs
and
there
beneath
the
Geneva
header,
the
emperor's
interface
contacts
label,
ampere
scale
and
amperes.
The
GAC
edge
ampere
scale
is
a
special-purpose
label.
Certain
label
and
the
ampere,
the
GIC
edge,
should
be
said
to
the
value
0
X
0
0
at
22,
that's
requested.
L
During
a
discussion,
our
PFD
for
vex
LAN
on
a
meaningless
a
question
was
raised,
she
will
allow
multiple
PFD
sessions
for
one
being
I.
This
figure
is
derived
from
a
me
reference
model
of
a
MV
of
three
architecture.
Obviously
a
t14
I
think
from
the
Emil
3
architecture
point
of
view.
We
should
allow
multiple.
We
have
the
sessions
for
one
being
I.
L
That's
developed,
adopted
in
a
BOC
working
group,
so
a
question
raised
here:
do
we
need
to
and
some
notes
saying
it's
applicability
to
extend
GPE
because
comparing
the
Geneva
encapsulation
with
vexxt
ntp
encapsulation,
we
believe
that
the
mechanism
described
in
this
chapter
can
also
be
applied
to
phase
10
GbE.
So.
F
F
L
I
L
H
I
Bfd
specifies
RFC
58,
eighty,
that
it
monitors
the
path
between
two
systems
and
to
certain
extend
the
forwarding
engine
on
insist
on
on
the
systems
that
host
be
of
the
application.
So,
yes,
if
we
use
different
encapsulation,
we
will
have
some
benefit
of
verifying
that
this
particular
encapsulation
is
working
somewhat,
but
at
the
same
time
the
problem
would
be.
Is
that
how
to
endpoints
agree
on
which
encapsulation
use?
If
multiple
encapsulations
can
be
supported
so
they're
assessing
it?
There
is.
C
F
I
think
in
the
interest
of
time
right
what
we
need
to
do
if,
for
example,
take
and
peel
that
the
solution
number
two,
if
you
are
saying
that
that
is
not
going
to
solve
the
problem,
the
respective
payload
type,
I,
think
that
is
fundamentally
something
wrong
in
how
you
are
actually
designing.
Yes,
I
think
that
the
solution
right
so
we
need
to
really
think
through
it's
it's
not
going
to
be
payload
type.
There's
a
protocol
for
the
data
plane,
header
yeah,.
L
I
want
to
suggest
one
point
at
one
point:
the
PFD
over
Geneva
is
different
from
the
underlie
PFD.
So
if
we
run
PFD
between
the
MBE
just
for
underlay
test,
we
can
use
just
a
one
kind
of
encapsulation
because
it
has
to
underlie,
but
if
we
want
to
use
PFD
for
Geneva,
actually
we
want
to
test
the
overlay.
L
F
I
think
you
should
really
come
up
clearly
like.
Why
do
you
need
different
types
of
BFP
in
different
use
cases,
I,
think
and
we're
talking
purely
about
the
orderly
and
we're
not
talking
about
underlay
okay?
Why
do
we
need
that
I?
Think
if
you
can
make
really
good
call
on
that,
then
we
can
discuss
I.
Think.
C
The
thing
is
another:
you
know
that
another
cases
where
we
have
another
VPN
technologists
a
pseudo
eyes.
If
you
have
an
Ethernet
pseudo
eye
or
if
you
have
an
ATM
suit
away,
you
don't
have
a
different
bfdi
encapsulation
for
VCC
v
b,
FD
for
those
different
types
but
they're
completely
different
technologists
for
the.
I
C
We
are
we
monitoring
the
Geneva
tunnel
or
we
munching
the
vni,
the
connectivity
for
the
VN,
I
I,
think
I.
Think
one
of
the
issues
here
is
maybe
that
the
the
layering
here
is
not
very
clear.
The
OEM
architecture
is
not
really
that
clear
and
maybe
that
needs
to
be
clarified
somewhere
either
this
draft
or
and
in
the
OEM
requirements
we've
got
or
some
sort
of
om
architecture
draft,
so
it
so
we'll
meet
when
we
say
we're
monitoring
Geneva.
What
are
we,
what
we
mean
and
which
layers
do
we
inject
OEM?.
I
L
I
I
Like
in
IP,
so
there
will
be
done
on
outer
encapsulation,
then
there,
oh,
my,
be
sharing
fate
with
their
payload
with
the
data
traffic.
So,
regardless
of
how
active
I
am
is
encapsulated
so
and
again,
their
validation
of
their
the
capsule
aiding
side
of
their
tunnel
is
really
limited.
If
we
use
specific
transport
encapsulation
for
BFD
packet,
we.
C
K
L
L
L
So
you
can
see
this
encapsulation
is
a
similar
with
the
PFD
for
our
genève,
but
the
difference
is
that
funnel
in
the
UDP
header
within
the
Union
UDP
header,
we
use
the
destination
port
862
to
indicate
to
the
stamp
test.
Packet
stamp
is
a
IP
performance
management
protocol,
that's
developed
in
IP
p.m.
working
group,
so
we
use
stamp
to
achieve
performance
measurement
when
the
chin
with
handle
is
used
to
carry
easily
at
the
frames.
L
L
63
74,
that's
four
anchors
lost
delay
measurement,
so
beneath
the
encapsulation
there
is
a
tested
method,
it
can
be
lost
management
message,
dilemma,
human,
a
message
or
combined
loss,
delayed
measurement
message
and
it's
differentiated
by
different
MPEG
ACH
value,
his
values,
zero
eggs,
the
reserve,
the
a/c
D,
were
requested
by
the
FC
63
74
and
among
the
amperes
encapsulation
amperes
interface
context,
label
will
be
used
to
I,
did
identify
a
VAP
of
the
originating
MBE
and
the
VAP
of
the
terminating
IDE.
So
it's
also
similar
with
a
PFD
over
genève.
L
C
I
No,
no,
in
this
case
it
we're
not
monitoring
the
service,
in
this
case
we're
just
monitoring
the
tunnel,
and
it
helps
to
basically
understand
how
for
operators
it's
useful
because
then
they
can
understand
which
part
of
overall
path
to
the
tenon
system
contributes
most
to
certain.
If
they
experience
you
know,
service
degradation
or
something
that
they
can
separate,
what's
contributing
by
their
performance
in
a
tenant
system
versus
their
tunnel.
So
no
performance
is
clearly
for
their
tunnel.
Ok,.
I
No,
it's
not
service
per
se,
because
it's
not
behave
this
session
between
tenant
systems,
because
if
this
session
between
tenant
system
is
undistinguishable
for
their
genève
endpoints
for
Geneva,
it
doesn't
differentiate
between
tenant
data
and
B.
If
this
session
between
tenant
systems
so
again,
the
previous
draft.
Again
it
monitors
their
tunnel
and
if
there
is
a
multi
path
in
underlay,
then
they
can
run
and
if
they
know
how
the
Vienna
is
being
placed
on
different
underlay
pests,
they
can
use
some
intelligence
to
monitor
particular
paths
through
very
nice.
F
I
mean,
like
maybe
I'm,
not
clear
if
you're
monitoring
the
nve's
in
this
case
right
the
edge
where
the
the
inner
end
cap
is
going
to
happen.
Our
D
cap
is
going
to
happen.
So
why
do
you
care
about
what
kind
of
payload
will
be
scurrying
after
genève
header
right,
if
you
can
pop
the
B
of
the
packet
pipe
or
so?
Why
do
you
really
care
about
what
the
payload
is
gonna
be
as.
I
Again,
if
we
know
that
under
Lane
network
doesn't
use
the
payload
to
do
hashing
and
world
balancing,
then
it's
absolutely
irrelevant.
If
it
does
use
payload
for
the
load
balancing,
then
there
is
some
value
in
using
the
same
encapsulation,
because
then
you
can
use
certain
algorithms
and
certain
methods
to
try
to
monitor
a
particular
path.
I
It's
again,
it's
a
similar
how
you
do
B
of
D
over
IP
MPLS
Network,
okay.
So
if
there
are
underlay,
so
if
you
use
their
IP
encapsulation
IP
information
from
the
LSP
payload
to
do
load
balancing,
then
you
can
use
the
combination
of
methods
to
run
your
beef.
This
session
and
more
inter-party
q
ler
path
in
your
multipath
environment,
I.
F
F
So
if
at
least
the
architecture
document
doesn't
talk
anything
about
the
the
transit
devices,
maybe
that's
a
choice.
We
have
taken
beyond
me
to
answer
that,
but
I
think
at
least
from
what
we
have
is
that
the
transit
devices
do
not
play
a
role
in
terms
of
what
they
exist.
The
inner
payload
is
gonna,
be
I.
Think.
F
F
F
I
Actually,
to
the
point
of
IP
I
think
that
in
the
meeting
for
Montreal
we
had
a
discussion
and
use
of
IP
is
probably
sub
optimal
for
encapsulation,
because
it
creates
a
significant
overhead
and
moves
the
PFD
packet
out
and
possibly
out
of
there
fast
memory.
So
that's
why
effectively
probably
NPOs
encapsulation
is
most
efficient
for
the
Janine
I.