►
From YouTube: IETF105-NVO3-20190726-1220
Description
NVO3 meeting session at IETF105
2019/07/26 1220
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
Okay,
so
welcome
to
MPI
3
in
the
last
the
last
slot
of
this.
This
ITF
I'm
Matthew
botulin
shows
Chacho
Sam,
Sam
or
drea,
and
we
were
issued
doing
the
doing
the
minutes
today.
Our
secretary,
thank
you
here
is
a
note.
Well,
I'm
sure
you've
seen
this
many
many
times
this
week.
That's
we
have
to
show
it
once
again.
A
A
A
So
a
milestone
so
as
usual,
these
are
completely
out
of
date
and
we
need
to
update
them
I've.
Just
these
are
the
ones
from
from
the
dates
tracker.
I've
just
quickly
updated
the
milestone.
Regarding
that
the
data
plane
solution,
which
is
genève,
which
has
been
submitted
for
to
the
is
three
website
to
Martin
now,
but
we
need
to.
We
need
to
come
up
with
some
some
sensible
timelines
for
the
rest
of
the
milestones
so
watch
this
space.
A
A
So
that's
surgeon,
Eve
draftin
Eve,
which
was
the
data
encapsulation
identified
by
a
doe
deplaning
capsulation
design
team
is
now
with
Martin,
so
we've
requested
publication
for
that.
We
have
another
draft
which
describes
the
output
of
the
data
plane,
encapsulation
design
team,
which
I
think
at
the
time
we
thought
was
useful
to
publish
something
yeah.
B
A
A
Okay,
so
we'll
probably
take
that
to
list
and
do
a
poll,
because
we,
you
know
it's
a
pretty
mature
document,
it
was
just
the
output
of
the
design
team,
so
we
just
thought
it
was
a
good,
a
good
idea
to
at
the
time
to
publish
that
really
as
a
documentation
of
our
experience
in
picking
and
encapsulation
from
multiple
competing
encapsulations
Martin.
Do
you
are
something.
C
A
This
is,
this
is
more
more
for
the
benefit
of
the
broader
eyes
you
have
to
document
the
process
by
which
we
picked
picks
an
encapsulation
format
when
we
had
quite
a
lot
of
controversy
around
which
encapsulation
should
move
forward,
and
this
is
something
that
happens
repeatedly
in
different
working
groups.
So
it's
really
okay.
A
Should
be
okay,
we
in
working
group
last
call
so
he
had
the
eevn
applicability
to
dodging
Eve,
which
is
currently
with
the
document
shepherd
so
that
went
through
working
group
last
call
there
wasn't
any
objection
to
that.
I
think
Samuel,
you're
handling
that
you
only
give
an
update
on.
Where
are
you
I.
A
We
also
had
a
virtual
machine
mobility
draft
that
some
of
you
may
remember
that
went
through
working
group
last
call
last
year.
It
also
had
some
reviews
and
quite
a
lot
of
discussion
on
the
list
from
TSV
area
review
team,
the
ops
Directorate,
and
there
was
also
a
routine
Directorate
review
and
I
think
that
the
some
of
the
issues
that
were
raised
by
the
TSV
are
not
direct
reviews
weren't
fully
addressed
by
the
editor
at
the
time,
and
the
auditor
has
since
gone
absent.
So
we
have
a.
A
There
we
go
yeah
I'm,
quite
sure
what
happen
there
so,
hopefully
we'll
be
able
to
move
forward
with
that
document
and
get
those
get
those
get.
Those
reviews
addressed
I,
don't
think
there
was
any
other
real
problems
with
the
that
they
were
raised
during
the
during
the
last
call.
I
think
it
was
mostly
some
some
comments
that
were
raised
during
these.
These
area
reviews
that
needed
to
be
addressed
properly.
E
A
So
so
so
now
that
genève
has
been
published,
well,
not
been
published
yet,
but
now
Geneva's
with
with
the
ASG,
so
I
think
just
to
refresh
the
working
groups
memory.
The
original
decision
was
that
the
other
encapsulation
drafts
could
go
forward
as
informational
or
experimental
following
following
a
publication
of
Geneva.
So
that's
really
yeah
I
mean
it's
kind
of
up
to
the
up
to
the
authors,
to
at
least
refresh
the
drafts,
and
so
so
can
I
get
a
show
of
hands.
A
Okay,
if
you
I
think
it
would
be
I
mean
we
did
promise.
We
would
do
that
and
a
working
group
agreed
to
do
that.
So
I
think
we
should
probably
maybe,
after
the
design
team,
encapsulation
draft
has
been
published.
It's
gone
to
the
is
you
it'll
be
good
good
time
to
then
thanks,
then
so
then
publish
those
because
then
then,
then,
a
little
bit
of
context
to
the
is
G
about
why
we're
going
forward
and
publishing
or
so
publishing
these
some
other
end
cap
drafts.
F
F
A
F
A
F
A
Know
if,
for
the
experimental
case
Martin,
do
you
have
any
comment
on
that,
because
I
think
that's
probably
more
why
the
ambiguity
is.
Isn't
that
so
so
I
guess
the
question
is:
if
px
1
GP,
for
example,
is
published
as
experimental
or
goes
forward
as
an
experimental
document.
How
much
say
does
the
working
group
have
over
the
technical
details
of
the
draft
because,
of
course
it's
documenting
an
implementation.
G
F
And
that's
my
interpretation
of
experimental
that
it
reflective
of
in
some
cases
we
have
at
ITF
where
their
implementation
or
defect
the
standard
being
put
on
an
informational
track,
but
experimental
is
more
of
really
reflective
of
some
experience
of
particular
implementation.
So,
basically
that
you
know
we
cannot
really
say:
oh,
you
should
have
implemented
differently,
because
the
response
I
would
imagine
will
be
no,
but
did
it
this
way.
You
might
disagree,
but.
F
A
Like
to
do
I
think
we
kind
of
need
to
have
a
consensus
of
its
working
group
as
well
as
to
which
way
forward
I
want
to
go
with
with
this.
If
it's
just
simply
I
mean
you
know,
you
can
argue,
probably
they
could
be
experimental
because
we
have
one
standard
stripe
document.
So
why
are
we
arguing
over
there
or
debating
the
technical
details
of
another
encapsulation?
Why
don't
we
just
document?
What's
what's
been
implemented
for
the
other
encapsulations.
A
E
A
Okay,
so
the
security
requirements
draft.
That's
on
the
agenda.
It's
next
up
on
the
agenda.
I
just
want
to
have
a
notes
about
there's
a
draft
that
was
originally
discussed
in
the
BFD
working
group
for
BFD
over
genève,
and
it
doesn't
really
propose
any
changes
to
BFD
I.
Think
it's
not
more
about
how
you
encapsulate
in
Geneva,
and
there
was
some
discussion
with
the
between
the
BFD
and
the
NVA
for
three
chairs
about
where
this
document
should
be
progressed
and
the
feeling
amongst
the
chairs
was.
It
should
go
forward
in
nvo.
Three.
A
F
A
A
F
J
J
J
When
you,
when
you
have
transit
device
things
change
completely
depending
on
what
you
want
to
disclose
to
the
transit
device
and
what
you
don't
want
to
disclose.
But
it
is
a
fact
that
using
end
to
end
security
protocol,
you
will
always
result
in
a
I'm
hiding
everything
to
the
transit
device
or
I'm,
disclosing
everything
to
the
full
world.
And
so
there
is
a
balance.
We
need
to
find
that.
J
So
that's
what
I
can
illustrate
with
this
payload.
So
if
you
have
envy
both
nve
are
interpreting
all
the
options,
so
you
have
the
packet
that
is
transmitted
from
one
and
V
to
the
other
one
if
you
secure
that
with
DLA
DTLA,
the
same
with
is
a
layer
below,
but
if
the
in
that
case
TLS
will
provide
an
integrity
and
confidentiality
protection
for
that
jean-yves
packet
from
one
env
to
the
other
one.
J
So,
as
I
mentioned
earlier,
you
have
two
choice:
either
you
disclosed
everything
so
no
protection
at
all
or
you
provide
I
mean
you,
you
bypass
the
transit
device,
so
suppose
we
are
in
a
situation
where
envy
is
a
providing
option.
A
B
and
C
and
the
other
hand
nbe
is
provided,
is
only
processing
option
a,
but
the
transit
device
is
supposed
to
process,
option
B
and
C.
J
So
if
without
any
protection,
while
the
packet
is
sent
through
transit
device,
the
transit
device
as
a
full
access
to
everything
in
Geneva
packet
is
processing,
option,
B
and
C,
and
you
move
that
to
nve.
That
is
processing
option
a
if
you
use
DTLS
well.
The
thing
is
that
the
transit
device
can
process
the
expected
options.
Bcd
so
only
option
a
will
be
processed
I
mean
in
that
example.
The
transit
device
is
completely
bypassed.
J
J
If
you
use
DTLS,
while
all
the
transit
device
has
been
removed.
So
the
current
genius
specification
specifies
that
transit
device
can
only
read
and
I
think
everyone
agree
with
that.
It's
okay,
it's
fine,
but
if
you
disclose
everything
and
you
don't
provide
any
mechanisms,
I
mean
we
don't
have
genius
police.
So
if
the
device
you
you
have
no
way
to
enforce
this,
only
read.
So
it's
only
that
you
trust
that
the
transit
device
are
behaving
in
a
in
a
in
a
good
manner.
J
So
we
need
I
mean
the
purpose
of
the
security
here
is
really
to.
If
we
have
opted
agreed,
it
doesn't
mean
he
can't
cause
arm.
We
really
have
to
provide
some
mechanisms
that
and
force
that
the
transit
device
may
access
to
some
information.
We
can't
do
anything
else
then
reading
that
information,
and
then
we
must
also
be
able
to
limit
the
information.
The
transit
devices
having
access
to
I
mean
that
you
want
to
transit
device
to
read
an
option.
J
You
may
not
want
him
to
read
the
full
packet
or
being
able
to
monitor
whatever
traffic
is
being
provided
from
one
and
ve
to
the
other
one,
and
so
that's
why
you
also
need
some
sort
of
encryption.
So
with
friends
device,
if
you
would
like
that
so
transit
device,
so
two
things
I
mentioned
and
forcing
the
radio
only
the
data
and
restricting
the
data
are
being
accessed
by
the
transit
device.
J
J
Okay,
so
one
way
to
do
is
that
okay,
we
need
to
disclose
the
option-
and
maybe
the
Jeanette
fixed
header,
so
that
I
mean
where
you
have
the
the
network,
identifier,
because
that's
might
be
used
for
routing
purpose.
So,
okay,
so
this
should
be
disclosed
because
those
are
going
to
be
used
by
a
transit
device,
but
those
we
don't
need
to
disclose
them
because
they
are
not
useful
for
the
transit
device.
And
actually
we
don't
want
this
transit
device
to
have
access
to
this
data.
J
So
one
way
to
do
is
to
do
make
to
provide
a
security
option.
That
says
everything
after
is
going
to
be
encrypted
and
that's
gonna
be
negotiated
with
this
one.
So
this
layer
is
encrypted.
The
transit
device
can't
read
this,
but
he
can't
read
what
is
supposed
to
read
and
then
because
I
mean
I'm
telling
the
transit
device
AAA
you're,
not
you're,
only
allowed
to
read
I
mean
if
you've
rights,
you
will
change
the
data.
J
You
have
to
be
able
to
to
check
that
is
only
gonna
read
that
data,
so
you
need
a
kind
of
security
authentication.
So
I
put
a
security
option:
that's
ID!
Okay,
these
are
the
data
I'm
disclosing
to
that
transit
device,
and
that's
going
to
be
authenticated.
So
in
case
you
change
that
this
one
will
be
able
to
check
a
sum
option
has
been
changed:
it's
not
the
packet
that
this
nve
has
been
emitted,
am
issuing.
J
B
B
J
B
J
B
Not
possible
I
think
we
discussed
is
having
is
being
able
to
Asante
key,
and
we
can
you
know
I
think
we
are
saying
we
are
to
read
the
option.
It
would
be
good,
in
my
opinion,
right
to
change
some
of
the
option,
not
add
option
but
change
it,
which
means
that
you
can
authenticate
some
of
the
option,
not
all
options.
You
can
pick
what
you
want
our
son
to
get
to
allow
the
midpoint
to
change
some
of
the
options
they
want
say.
B
J
B
J
Okay,
so
that
we
can
discuss,
but
okay
I
mean
it
may
not.
It
may
makes
no
sense
to
encrypt,
but
not
one
option.
That's
and
I
mean
the
that's.
The
kind
of
things
we'd
like
to
know
on
how
to
design
I
mean
the
security
requirements
to
know
exactly
what
we
would
like
to
achieve,
because
we
can
end
up
in
something
very
complex,
which
is
what
were
you
I?
Think
I
mean
the
requirement
we
have
now
are
pretty
complex
because
we're
kind
of
opening
all
the
different
possibilities.
B
B
B
J
L
Okay,
good,
so,
first
of
all,
I
would
like
to
state
their
architectural
II.
What
we
envisioned
is
NV
is
an
entry
and
protocol.
I.
Think
I've
explained
this
multiple
times
during
the
you
know
in
the
mailing
list,
as
well
as
part
of
the
review,
it's
an
end-to-end
protocol
and
so
the
transit
devices
are
nothing
but
forwarding
elements
that
are
already
available
in
the
underlay
network.
You
know
it
could
be
routers
or
switches
and
so
on.
L
So
if
we
you
know
they,
if
there
is
an
end-to-end,
encryption
is
employed,
which
means
that
these
forwarding
elements
will
not
be
able
to
see
their.
You
know,
options
header,
anything,
that's
perfectly
fine,
and
we
have
already
described
saying
that
if
such
is
the
case,
these
elements
which
are
called
as
transit
devices,
will
have
to
forward
it
like
any
other
IP
packet.
That's
it
right!
So
that's
that's
that's
very
clear,
and
these
you
know
forwarding
devices
or
transit
devices.
L
Interpreting
these
options
is
not
an
absolute
requirement
for
the
functioning
of
the
NTN
protocol,
so
we
did
not.
You
know
an
omission
saying
that
okay,
let's
just
show
part
of
this
option
to
this
particular
transit
device
and
you
know,
exchange
keys
between
the
transit
device
in
the
endpoint.
That
was
not
the
intent
at
all
and
that's
very
clear.
If
you
read
the
draft,
I
mean
there
are
many
different
protocols.
L
Like
example,
if
you
take
it
in
RFC,
8:08
6,
which
is
GRE
over
UDP
same
thing,
you
know
equivalent,
you
know,
GRE
key
is
an
equivalent
to
an
option
here
there
is
no,
you
know,
requirement
that
you
go
and
just
selectively
encrypt
or
decrypt
or
send
it
in
the
clear
you
know
just
this
GRE
key
so
that
intermediate
forwarding
no
need
to
look
at
it.
No,
that's
not
the
intent
right
same
here.
I
mean
Geneva
is
no
different
than
any
other
European
capsulation
protocol.
L
F
M
F
J
F
The
bitumen
header
now
refers
to
as
a
control
packet
will
be
discussing
om
encapsulation
later
today
in
a
session.
What
I'm,
just
saying
is
that
active,
who
I
am,
is
specially
constructed
packet
that
injected,
but
what's
important
and
critical,
is
that
active
or
a.m.
follows
the
same
path
and
receives
the
same
treatment
as
date
of
law
packet?
So
basically
they
hate
sharing,
so
would
encrypting
the
data
packets
and,
for
example,
possibly
speculating
not
encrypting
test
packets
will
still
enable
us
to
do
page
sharing
or
not
so
okay.
So
that's
something
to
think
about
it
again.
F
F
F
D
The
packet
will
your
packet,
then
the
or
just
the
data
plane
itself
is
encrypted
right
from
end
to
end.
It
doesn't
mean
anything
because
you
cannot
peek
into
the
payload
you
respectively,
whether
you're
a
transit
device
or
are
so.
If
that's
how
it
should,
because
it
should
behave
just
like
any
other
day.
D
J
D
J
Is
part
of
that
then
kept
protocol?
Okay,
but
so
one
reason
is
that
there
is
an
envy
of
three
requirement
document
and
but
his
draft
has
not
been
continued,
so
we
started
a
genève
because
one
of
the
main
difference
between
the
the
security
requirements
provide
for
n
vo
3
did
not
consider
the
transit
device
sure,
but
that
goes.
J
Oh
yeah
yeah.
Definitely
because
I
mean
we
are
a
little
bit
like
because
we
don't
turn
it
what
those
transit
device
do
and
I
think.
Currently,
the
situation
we
are
is
that
we
said
ok,
so
this
device
have
not
been
defined
at
properly
so
well.
They
can
have
a
single
option.
They
can
read,
they
can
have
a
single
option
dedicated
for
that
diversity
can
encrypt,
and
so
and
probably
we
are
providing
too
many
use
cases
that
are
not
intended
to
be
used
so
and
Mister.
But
that
goes
to
the
solution.
Aspect
here
are
the
requirement.
D
J
D
Right,
yeah
yeah,
that's
pretty
much
it.
If
you're
considering
this
as
end-to-end
protocol
and
you're
going
to
define
the
protocol
for
end-to-end,
then
the
security
should
address
the
end
to
end
part
of
that
and
for
the
transit.
Then
we
need
to
I.
Think
Kamata
can
talk
about
that,
what
the
transit,
how
we
are
planning
to
do
that,
but
we
shouldn't
be
defining
what
transit
means
as
part
of
the
secure
okay.
A
But
the
problem
is
that
was
never
discussed
or
never
described
as
part
of
the
MV
o3
architecture,
any
of
that
functionality,
and
so
the
only
definition
that
we
really
have
of
a
transit
devices
in
the
genève
encapsulation
draft,
which
is
a
little
over
you
know
it's
problem,
may
not
be
a
complete
definition.
I.
B
Answer
transit
device
here
simply
a
router
should
not
be
looking
at
option.
It's
on
his
Andy,
who
looked
right
so
so,
and
we
can
look
and
now
when
we
are
talking
about
option
between
and
bees
should
we
encourage
them
should
be
only
authentic
ISM
and
that's
about
it.
So
if
an
NDE
will,
if
device
will
inspect
the
options,
that
is
an
MD,
yeah
and
I,
think
we
can
go
that
definition
to
that,
should
be
fine,
that
there
is
no
treasure
device
that
inspect
option.
B
B
Just
do
because
I
saw
they
do
assume
yeah
if
they
do
hashing
on
five
tuples
or
even
seven
couples
are
looking
at
UDP
or
the
transport
layer
force.
They
not
look
beyond
layer,
four
right,
so
so
so
the
router,
even
the
Faro
right,
if
you
are
talking
about
layer
for,
are
old,
they
look
only
at
UDP
ports
or
TCP
port,
so
they
look
at.
Therefore,
so,
yes
sure
you
can
look
at.
L
B
L
B
L
L
B
B
If
it
of
the
packet
goes
in
clear,
you
are
right,
the
currency
device
can
do
whatever
it
can
do
with
it,
but
without
changing
anything
of
the
packet.
If
security
is
in
play
with
the
sonication,
for
example,
right
so
so,
I
think
yeah.
Those
absorption
were
discussing
I
think
we
discussed
an
extra
option
in
which
you
are
saying
the
option:
header
between
and
v-not
a
transit
and
because
I
think
with
what
you
are
saying
here,
who
is
handling
options,
really
handling,
meaning
processing,
understanding?
L
Correct,
that's
what
we
have
a
clearly
explaining
the
draft
and
what
the
security
requirement
draft
is
trying
to
go
on,
interpret
it's
in
one.
It's
one
way
and
trying
to
give
some
solutions
like
what
you
know.
Daniel
is
right
now
explaining
and
that's
not
what
is
supported
in
the
Geneva
collection.
That's,
basically
what
I
am
trying
to
say:
okay,.
B
L
D
D
B
Is
not
different,
I
agree,
I,
agree,
so
I
think
the
partial
stuff
that
I
mentioned.
Yes,
I
I
agree
it's
not
if
they
are
Andes
nows
and
yes,
they
can
change
the
options
on
I
really
hate
that
scent
again,
so
so
so
yeah.
So
the
whole
option
of
the
whole
packet
can
be
encrypted
was
the
whole
packet
can
be
authenticated,
option
and
balaam.
D
J
A
So
you
know
going
back
to
the
the
the
parallel
with
VPN
architect,
as
we
do
at
least
recognized
in
I
believe
in
going
back
to
that,
the
provided,
provisional
VPN
architecture,
the
fact
that
Peru,
what
they
call
P
Reuters
exists,
and
they
do
describe
them
so
we're
not
defining
we've
got
to
recognize
that
they're
there.
So
just
saying
they
don't
exist,
but
you
can.
A
B
B
B
A
B
A
B
B
B
B
J
B
H
B
You
know
so,
if
you
are
touching
your
and
enbe,
you
are
knitting
a
family
or
an
IV.
If
you
want
to
do
trace
route
between
those
two
and
V
by
transit,
routers
right,
it's
fine
to
write
because
they
are
not
going
to
be
touching
anything
on
the
package
that
would
simply
be
sending
errors
back
or
something
right.
So
some
indication
back
to
the
English
point
that
yes,
I,
am
on
the
way
yeah.
D
G
D
In
other
words,
there
is
no
requirement
to
say
that
there
is
a
way
for
the
transit
device
to
look
into
that
as
long
as
the
pail
or
the
the
network
or
the
encapsulation
allows
it.
There
is
no
requirement
that
it
should
or
shouldn't
do
certain
things
selectively
things
if
the
end-to-end
is
encrypted
period.
Yeah
I
cannot
look
into
that.
Okay
if
it
is
not
restricted
or
not
encrypted,
then
yeah
in
transit
device
can
look
into
that
yeah,
but.
B
J
B
You
can
secure
it
because
you
are
either
encrypting
betweens
MV,
so
the
transit
is
a
pass
through,
doesn't
doesn't
look,
doesn't
know
what's
inside
the
packet
or
you
can
authenticate
her,
and
in
that
case
yes,
he
can
look,
because
the
data
is
Cle,
but
he
cannot
do
much
as
well
right.
You
know
he's
only
looking
at
what
you
sent
in
clear,
yeah.
B
K
M
So
hello,
everyone.
So
here
we
arrive
at
the
sixth
version
of
this
draft
and
you
may
notice
that
we
have
new
members.
Our
design
team,
especially
we
have
one
who
is
come.
Who
is
the
author
of
another
young
draft
which
is
dedicated
for
genève
and
vixen
TPE,
so
the
design
methodology
of
this
two
draft
is
aligned
and
in
the
future
the
two
draft
will
be
well
coordinated.
M
So
the
first
day
I
would
like
to
recall
the
motivation
of
this
draft.
So
in
ITF
for
the
in
terms
of
network
virtualization
overlay,
the
data
plane
and
the
control
plane
have
been
covered
and
that
there
are
several
ability,
the
works
on
it
and
clearly
the
Yamato
is
still
a
gap
so
to
be
covered
and
why
we
start
with
a
base,
a
very
young,
because
there
are
several
encapsulations
and
vivian
technologies
and
if
we
run
to
run
directly
into
individual
calculations,
will
run
out
run
into
with
a
positive
works
and
a
non
consistent
approach.
M
So
it
is
better
to
start
with
a
common
and
reusable
young
in
the
first
place
and
it
can
be
used
at
the
start
point
for
individual
encapsulation.
Two
people
can
actually
element
the
space
young,
any
type,
one
necessary
to
define
the
young
model
for
individual
encapsulation,
and
in
this
base
area
model
we
will
use.
We
have
used
the
reference
eyes,
such
as
vo3
RCS,
for
example,
the
framework
architecture,
and
we
have
used
the
rigid
RCS
and
works
in
progress
in
ATF.
M
So
there
is
a
relatively
significant
change
in
the
current
version
and
in
the
previous
previous
version,
the
NVE
is
defined
as
a
container
and
inside
this
container
we
defined
as
the
via
instances,
and
but
now
we
define
mve
as
an
interface.
Actually
Ignace
has
a
comment
during
the
last
ITF
and
we
think
it
is
a
good
idea.
So
we
adopt
it
and
now
the
e
is
defined
as
an
interface
via
augmenting
the
ITF
interface
young
and
and
in
the
pace.
M
M
It
way
if
it
is
enabled
here
and
if
it
it
is
enabled
we
should
have
a
bypass
with
high
P
to
you
know,
to
identify
uniquely
the
AE
inside
of
this,
and
it
has
to
get
way,
and
this
style
gives
you
a
impression
about
house
and
very
busy
is
mapped
to
the
architecture
and
inside
the
the
base,
a
very
young
module.
We,
we
define
the
via
instances,
and
here
we,
the
the
via
ID,
is
configured
and
used
as
a
K
of
the
VI
instance.
M
And
here,
as
you
can
see,
we
have
the
source
and
ve
indicating
that
which
and
we'll
a
very
interface
is
mount
82,
and
we
have
also
a
PDP
control
plane
in
Ebola
to
indicate
if
the
AES
are
configured
dynamically.
There's
a
bit
difficult
controlling
or
it
is
configurable
study
statistically,
and
if
it
is
the
later
case,
the
the
static
appear
and
they
define
here.
So
we
also
have
the
the
multicast
group
per
defined
per
VM
basis
and
for
different,
very
I.
We
can
have
different
multicast
service
note
and
another
change,
a
that.
M
M
A
B
So
so
the
idea
here
is
that
the
use
case
we
are
talking
about
here
is
a
dual
homed
device
right
between
nuts
a
couple
of
and
the
year
and
we
are
doing
data
clean,
Mac
learning,
so
so
so
we're
talking
here
about
data
plane,
Mac
learning
with
a
do
at
home
device.
So
now
you
know
that
do
at
home
device
if
there
would
be
a
failure,
so
so
here's
the
door
at
home
device
as
well
is
the
axis
here
is
not
villain.
B
It's.
It
is
a
genève
tunnel
between
what
we
call
they
have
to
service
and
then
these
so
so
you
have
a
genève
tunnel
between
the
nve's,
of
course,
and
between
the
layer,
2
device
and
then
V.
So
now
those
and
V
is,
of
course
they
can
be
talking
control
planes.
They
can
be
talking,
evpn
talking,
whatever
control
plane,
to
distribute
max
or
mac
IP
bindings.
B
So
for
for
it
to
know
that
we
are
proposing
the
extension
so
again
in
simple
term
a
device
that
device
could
be
hypervisor,
for
example
the
old
ho
doing
home
to
two,
and
these
two
leaves
to
two
tours
and
he
is
setting
up
be
excellent
tunnel
to
those
envies
sorry
setting
up
genève
tunnels
to
those
envies
and
now
the
env
is.
There
is
a
failover
between
a
primary
to
the
backup
and
B,
and
the
backup
and
V
has
to
give
an
indication
to
the
device
sighing.
Okay,
hey
switch
over
HAP.
So
this
is
it
right.
B
This
option:
TLV,
we
can
send
on
the
genie
packet
right
to
send
the
failover
notification
when
the
backup
or
the
standby
and
B
becomes
active,
and
the
document
describe
a
very
simple
protocol
following
what
we
did
as
well.
For
MPLS
TP
for
MPLS
CP,
we
had
a
Mac
withdrawal
draft
and
the
document
here
follows
the
same
thing:
follow
exactly
the
same
protocol.
B
It's
a
very
simple
data
pass
protocol
to
increase,
to
I,
to
increase,
of
course,
reliability
and
make
sure
that
that
message
will
arrive,
for
example,
to
the
device
sign
that
the
back
up,
sending
saying
I
am
now
active
and
ve,
and
all
the
Mac
that
you
learned
from
as
a
primary
and
ye
are
now
visible.
Barney,
so
I
think
ensures.
That
said,
any
comments.
I
B
B
B
Yeah
yeah,
of
course,
this
what
I
mentioned
as
well.
It
may
not
be
very
clear
here,
but
the
other
side
could
be
MPLS
based,
think
I.
Think
what
what's
being
said
here
if
he
imagines
the
whole
network,
is
this
a
plane
learning
right
data
pin
McCloud
nning
than
the
other
side
can
use
exact
same
similar
mechanism,
but.
B
B
I
I
B
A
A
O
P
Ensure
so
I
agree
on
the
comment:
it's
confusing
high
rated
number
of
times,
okay,
okay
and
some
of
the
name
is
confusing
as
well,
because
it's
not
really
that
much
mock
has
moved
is
that
the
interface
became
unavailable
so
you're,
pretty
much
signaling
you've
got
some
relationship
between
and
we
won
and
we
did
from
from
the
service
perspective.
So
if.
P
B
P
P
B
B
B
Q
B
B
H
B
Q
H
B
Think
I
think
you
know
the
slide
was
talking
about
an
old
genève
data,
clean
Mac,
learning
stuff
right.
But
what
will
change
just
to
make
sure
it's
it's
clear
and
very
easy
to
understand
is
that
we
won't
care
about
the
core
of
the
networks
cloud
sing,
the
core
of
the
net,
who
won't
care
about
it.
Only
the
access
is
what
we'll
focus
on
right
and
it's
similar
to
the
war.
If
you
are
familiar
to
the
war,
we
switch
from
primary
to
backup
and
we
send
in
pseudo
arias
and
what
we
call
a
pseudo
our
status.
G
B
G
F
F
Active
Orion
protocols
must
be
clearly
identifiable
in
Geneva,
so
we
have
four
options
for
your
consideration
and
discussion:
IP
UDP
encapsulation
direct
identifiers,
MPLS
generic
associated
channel
header
and
Geneva.
So,
okay,
let's
start
with
IP
well
understood
we
have
genève
header.
Obviously
there
is
transport
encapsulation
above
Geneva
and
after
Geneva.
F
The
next
protocol
points
the
protocol
type
points
to
ipv4
or
ipv6,
since
we
are
using
either
types
this
already
the
these
are
readily
available
and
after
the
genève
header
we
have
inner
IP
or
v6
header
and
the
destination
IP
address
it's
either.
So
it's
one
of
the
martian
addresses
and
the
multiplexing
is
based
on
destination.
F
H
F
It
adds
up
on
IP,
UDP
overhead
and,
as
was
mentioned
in
a
discussion
in
Prague,
it
potentially
creates
a
possibility
of
generating
false
negative
if
something
wrong
with
the
IP
UDP
encapsulation,
because
the
distances
are
there,
om
packet
from
the
genève
header
direct
encapsulation,
so
the
protocol
type
is
active
or
a.m.
type
for
each
of
protocols
and
then
following
their
genève
header,
you
have
your
control
message,
no
overhead,
but
then
because
the
probe
likely
will
be
multiplicity
of
protocols.
For
example,
echo
request
reply,
BFD
performance
measurement
protocol.
There
could
be
some.
F
Genève
header
will
follow
gell
generic
associated
level
label
and
it
will
be
marked
as
bottom
of
the
stack.
So
it
will
be
only
one
label
and
that
will
be
followed
by
generic
associational
header,
which
is
very
similar
with
the
well-known
and
pseudo
wire
associated
channel
header,
and
we
can,
in
we
use
the
channel
types
that
already
maintained
in
Ayana,
registered
to
the
wire
associated
SCH
types
and
followed
by
the
body
of
their
active
protocol
message.
F
F
Because
the
obit
is
not
defined,
obit
is
not
clear
where
the
OEM
is.
Is
it
om
in
extensions
or
om
in
a
payload?
Here
is
a
clear
protocol
type
and
then
we
go
in
the
protocol
and
the
protocol.
Just
then
we
go
it's
in
PL
s,
we
look
past
the
header,
it
tells
MPLS,
we
go,
we
look.
This
is
Gail.
We
know
that
Gail
means
it's
a
ACH
or
gas
and
then
we'll
go
there.
So
we
don't
need
a
bit
here.
Everything
is
straight
forward
without
oil.
A
F
F
Tuco
offers
discussed
it
and
put
it
there,
but
then
we
decided
to
extract
it
and
first
discuss
this,
but
I
don't
know
frankly,
draft
I'm
not
familiar
with
the
draft
it
here
yeah.
Just
if
you
can
find
the
draft
and
send
it
to
the
list.
Thank
you,
okay
and
and
the
worst
is
Geneva
associated
channel.
Then
we
need
to
define
om
protocol
type,
so
it's
either
net.
But
if
we
can,
you
reuse
existing
either
type
for
om
it's
already
there,
and
then
we
don't
need
a
gal.
F
F
R
F
R
R
F
F
F
A
F
A
F
Okay,
if
it's
confusing
that
we
can
get
the
neither
either
type,
but
I
think
that
one
option
for
the
genève
we
can
reuse
it,
because
if
we,
if
we
can
use,
for
example,
IP
over
Ethernet
as
indication
of
IP
payload,
then
why
we
cannot
use
ethernet
om
as
indication
of
geneva.
Am
I
understand
that
we
are
not
allocating
new
IP
over
genève
either
type
or
are
waiting
my
understanding
where
we're
using
IP
over
Ethernet
right?
F
A
F
H
A
F
G
D
D
F
You
well
I
think
that
we
need
to
start
eliminating,
so
we
need
to
start
eliminating
some
options
and
saying:
okay,
this
is
not
acceptable
at
all
and
so
probably
will
end
up.
What
I
would
like
is
first
in
the
first
phase
of
discussion,
and
that
was
two
options:
okay,
so
let's
first
eliminate
two
options
out
of
four,
and
once
we
get
to
two
options,
then
we'll
have
more
extended
discussion.
F
A
F
A
F
A
They
I
think
the
choice
would
have
to
decide
would
have
to
say
what
the
consensus
is
in
in
the
working
group
or
pick
or
get
a
design
team
to
come
up
with
a
recommendation
that
we
can
then
get
consensus
on
in
working
group.
Okay.
Well,
if
there's
notice,
if
there's
not
in
sufficient
discussion
on
the
list,
I
suspect
no.
S
And
I
do
have
a
comment
question
on
around
at
the
same
time,
what
is
the
goal
of
this?
What
we
are
trying
to
achieve
here,
and
especially
from
the
actual
usability
perspective
Greg
you
mentioned
about
CFM
and
the
complexity
of
that
CFM-
is
a
technology
stack
which
is
rather
well
understood
in
the
field
and
basically
the
community
uses
that
for
their
two-minute
ability
purposes,
that's
rather
well-known
for
trying
to
invent
something
similar,
but
not
the
same.
That
probably
would
not
resonate
too
well
with
the
community.
That's
just
additional.
S
Can
we
run
CFM
over
this
channel
and
what,
while
we
are
happily
talking
about
the
fields,
values,
bits
and
other
things?
What
is
the
general
problem
that
is
being
addressed
here?
What's
a
deliverable
out
of
that
to
provide
for
different
encapsulations
and
channels
to
carry
Oh
am
not
necessarily
knowing
what
are
the
problems?
What
that
OEM
solving
do?
We
have
the
requirements?
What
is
needed
for
running
these
types
of
networks?
Mui,
have
you
on
the
overall
manageability
of
the
stacks,
basically
than
the
old
tunnel
running
and
the
Oh
on
some
form
of
underlay?
S
F
Well,
we
don't
have
it
formulated
in
a
document.
Yes,
that's
the
case.
I
would
say
that
at
ITF
we
do
have
well-developed
and
longtime
deployed
and
tested
om
stack.
It's
not
that
might
be
coherent
like
again.
Cfm
might
not
be
the
best
example.
I
would
then
use
1731
because
1731
combines
fault
management
and
performance
monitoring,
but
we
do
have
a
suit
of
OM
active,
om
tools
that
are
functionally
match
to
1731.
So
I
would
not
say
that
we
inventing
new
OEM
protocol.
A
Know
so
no
other
way,
I
think
he,
mr.
you,
you
have
a
good
point
here,
because
if
I
think
back
to
the
the
OEM
protocols
that
we
defined
for
those
channel
types
or
that
were
identified
by
those
channel
types
you
listed
there,
a
number
of
them
were
originally
developed
in
the
context
of
an
MPLS
transport
network,
not
so
data
center
VPN.
A
S
If
we
look
from
the
field
perspective,
MPLS
OEM
is
another
technology
stack
which
is
rather
well
understood
by
the
community.
If
we
can
take
and
reuse
that
that
would
be
definitely
be
a
benefit
instead
of
trying
to
reinvent
something
new
which
basically
does
the
same
function,
but
in
a
different
way
right.
F
But
that's
basically,
if,
if
you
look
at
this
again,
mpls
om
stack,
an
IP
om
stack
are
practically
identical:
okay,
because
it
was
not
developed
for
MPLS,
it
was
adapted
from
IP
into
MPLS
or
at
least
created
look
alike.
For
example,
LSP
ping
BFD
works
the
same
way
as
it
works
in
IP
network.
It
works
over
in
paris,
OSP
channels,
tunnels.
S
F
S
I'm
very
happy
by
the
first
part
of
the
answer:
please
don't
invent
yet
another
William
thing,
because
there
are
plenty
I
think
this
is
definitely
for
I,
don't
want
to
occupy
the
time.
This
is
definitely
for
broader
discussion
over
the
broader
community,
I
kind
of
get
the
feeling
that
the
group
does
not
necessarily
see
the
clear
view
of
how
this
can
be
used.
What
are
the
actual
requirements?
Maybe
that
would
be
a
good
starting
point
to
see
what
is
available
and
how
those
things
are
being
used.
F
Agree
that
actually
the
requirements
for
om
functions,
it's
a
good
document
to
produce,
but
I
don't
see
that
this
discussion
of
how
we
encapsulate
active,
om
and
discussion
of
what
we
need
to
do
in
active
or
am
I
think
then
they
can
go
concurrently
in
parallel.
They're,
not
they're,
not
getting
each
other,
because
this
is
not
what
we
do.
This
is
how
we
do
it.
What
we
do
is
different.
F
Okay,
so
discuss
decide,
and
then
we
were
planning
to
do
look
at
what
extensions
we
need
for
echo
request
reply,
because
continuing
on
what
Agnes
said,
I
do
believe
that,
yes,
this
environment
may
require
certain
extensions
to
apply
functionality,
especially
to
probe
their
particular
things.
Okay,
but
so,
as
I
understand,
just
check
my
understanding
verify
with
you
that
I
will
send
the
email
starting
the
discussion.
You'll
be
judging
the
consensus.