►
From YouTube: IETF108 NVO3 20200728 1300
Description
NVO3 session at IETF108
2020/07/28 1300
A
A
A
So
the
agenda
we've
got
50
minutes,
so
we've
got
this
working
group
status
update
and
then
we've
got
greg
with
talking
about
geneve
oem
and
then
the
geneva
bfd
for
geneve
draft
from
german
and
then
finally
she's
going
to
do
talk
about
the
loops
I'll.
Give
us
an
update
on
loops
any
comments
on
the
agenda.
A
A
A
Data
plane,
encapsulation
so
geneve,
which
is
our
standards
track.
Encapsulation
is
with
the
rfc
editor.
Now.
Thank
you
for
that.
That's
good.
We
also
have
this
draft
ietf
mvo3n
draft.
That
is
the
description
of
the
work
of
the
dataplane
encapsulation
design
team.
I
started
a
working
group
last
call
on
this
in
february,
but
I
haven't
seen
any
responses
on
the
list,
so
I
would
appreciate,
if
I'm
going,
to
keep
that
open.
A
I
know
this
is
rather
lengthy
and
send
a
reminder
to
the
list,
but
we
had
originally
said
that
we
would
like
to
publish
ideally
like
to
publish
this
this
document
as
because
it's
a
useful
description
of
how
to
pick
an
encapsulation
and
that
challenge
comes
up
and
a
decision
comes
up
many
times
in
the
work
of
the
itf.
So
we
thought
it
was
useful
to
publish
this
document.
A
We
also
had
some
informational
encapsulation
drafts.
The
vxlan
gp
draft,
we
think
is,
is
probably
right
ready
for
for
working
group
last
call
I
will
start
a.
We
will
start
a
last
call.
I
think
for
that,
after
after
this
itf
it's
about
time,
we
move
forward
with
this
now,
especially
since
geneve
is
in,
is
in
the
rsc
editor's
queue
regarding
the
control
plane.
So
we
have
an
evapn
applicability
to
geneve
draft.
A
A
Okay,
virtual
machine
mobility,
so
this
has
finally,
after
numerous
revisions,
gone
to
been
publication
requested.
So
that's
with
with
martin,
we
have
some.
We
have
some
yang
models.
There's
the
basic
the
base
yang
configuration
document
I
would
ask,
is
if
this
is
ready
for
working
group.
Last
call
I
don't
this
is
this
is
kind
of
a
high
level
high
level
model?
It
doesn't
go
into
all
the
details
of
how
to,
for
example,
configure
the
the
options
of
the
encapsulations.
A
A
B
We
have
from
ibpm
working
group
rfc
7799
that
give
classification
or
some
strict
definitions
of
three
types
of
oil,
active,
oem,
pacifim
and
in
between.
So
we
refer
to
this
hybrid
oem
and
that
class
divided
into
subclasses,
so
just
to
make
to
repeat
their
classification.
The
passive
oem
is
oem
that
does
not
affect
data
packet
in
any
way,
so
usually
that
would
be
snmp
gets
or
information
from
pop
sub
or
yang
notifications,
the
hybrid
oam.
B
So
the
requirement
for
data
active
oem
is
that
it
must
not
be
leaked
out
of
geneve
domain
and
we
have
several
protocols
that
being
developed
and
used
to
do
the
job
of
active
oem.
So
some
of
them
it's
proactive
defect,
detection,
some
of
them
performance
measurement
and
some
of
them
are
on
demand
oem
to
do
the
defect,
localization
and
troubleshooting.
B
B
For
active
oem,
we
propose
two
types
of
encapsulation
non-documents,
so
if
you
can
recall
we
had
more
types,
we
moved
them
in
the
appendix
archived
it
and
now
we
are
suggesting
to
have
ipvp,
encapsulation
and
use
our
geneva
association
channel.
So
let's
go
to
details
of
two
types
that
we're
proposing
next
slide.
Please.
B
B
B
So
everything
works
at
least
appears
to
work
out
of
box.
The
concern
is
here
is
that
additional
ipedp
overhead,
which
creates
a
distance
between
geneve
header
and
packet
payload,
so
with
their
active
oem,
whether
it's,
for
example,
bfd
or
performance
measurement,
using,
for
example,
simple,
two-way,
active
measurement
protocol.
B
B
B
B
B
C
C
B
Okay,
well
in
that
case,
that
very
interesting
information
and
thank
you
sam.
So,
yes,
I
should
have
stressed
probably
or
should
be
stressing
more
than
that
fate
sharing,
is
a
critical
requirement
for
active
oem.
So
if
dni
information
is
used
for
load
balancing,
then
effectively,
we
are
talking
about
service
oem,
because
then
it
has
to
be
tenant
to
tenant,
not
necessarily
right,
because.
C
We
are,
you
are
using
the
oem
bit
or
whatever,
to
trap
the
packet
so
not
necessary
that
you
always
have
to
go
to
the
tenant.
My
point
is
that
you
are
trying
to
validate
your
assumption,
you're,
making
an
assumption
here
that
the
traffic
for
management
vni
will
always
take
the
same
fate
as
customer
traffic,
which
is
not
true.
So
that's
my
point.
I
mean
you
might
have
a
use
case
to
measure,
but
I
I
don't
see
what
exactly
you're
trying
to
measure
in
that
case.
B
C
B
But
okay,
so
basically
you're
saying
that,
but
then
still
we
have
their
problem
of
number
of
sessions
because
their
suggestion
to
use
management
vni
is
that
well
first
for
their
defect
detection.
It
gives
us
a
continuity
check,
so
it
gives
us
assurance
that
there
is
a
way
for
the
network
to
get
from
one
geneva
node
to
another
node
in
regard
to
the
performance
measurement.
B
B
C
I'm
sorry
I
mean
I'm
sorry
taking
time,
but
we
can
take
it
offline,
but
my
point
is
that
any
policies
you're
going
to
apply
based
on
that
the
customer
traffic
and
the
kind
of
encapsulation
use
and
those
kind
of
things
right.
So
here
you
are
proposing
a
general
packet
and
you're
trying
to
validate
the
customer
path.
So
that's
where
I'm
not
able
to
see
one
to
one
there,
but
we
can
take
it
offline
and
let
others
speak
on
who
are
on
the
line.
E
E
E
Lot
of
sense,
if
I
can,
if
I,
if
I
can
find
two
nodes
that
don't
seem
to
be
talking
to
each
other,
and
I
want
to
find
out
where
they
are
talking
to
each
other.
I
think,
as
sam
points
out,
if
there's
something
weird
going
on
with
a
customer's
traffic,
you
might
want
to
use
the
same
dni
to
to
figure
out
where
it
went
off
the
rails.
D
Okay
agreed,
so
only
in
those
cases
I
agree,
but
then
that
is
something
like
you
are
really
verifying
a
tenant
to
tenant
right
I
mean
it's
for
a
tenant
that
you're
verifying
and
that's
when
the
vna
comes
into
picture.
But
if
you
are
verifying
a
node,
then
probably
you
really
don't
need
to
get
up
until
the
geneve
header
itself,
the
outer
ip
and
the
outer
udp
is
the
one
which
is
actually
getting
used
to
load
balance.
A
A
F
F
F
F
F
3.1,
the
new
bfd
session
originates
and
terminates
at
bad
profit,
mve
key
point
2
web
and
b,
and
I
have
the
relationship
of
n
to
1
using
one
mve
key
point:
three
originating
vap
decides
genevieve
bft
encapsulation.
Being
I
key
point
four
pl
web
address
can
be
obtained
by
management
or
control,
plane.
F
F
F
F
F
F
F
F
A
F
F
E
F
G
G
G
G
So
so
there
are
basically,
there
are
three
elements
that
loops
try
to
provide.
The
first
one
is
to
the
first
one:
is
the
information
model
for
local
recovery?
Basically,
there
are
two
modes
of
packet
recovery:
one
is
the
retransmission.
The
other
is
the
fec,
so
both
of
them
can
be
encapsulated
in
a
variety
of
formats
in
loops,
trying
to
define
some
of
those,
for
example.
Geneve
for
sure,
is
one
of
the
candidate
protocol.
G
The
local
measurement
is
basically
used
to
set
the
recovery
parameters,
for
example
for
the
timeout
or
the
forward
error
correction
rate.
The
third
one
is
the
congestion
feedback,
because
certainly
the
in-network
loss
recovery
won't
impact
won't
have
negative
impact
to
the
end
to
end
congestion
control
loop.
So
the
basic
idea
here
is
the
loops
egress.
Try
to
easier
mark
the
recovered
packet
so
that
the
air
host
sender
can
use
this
ce
marking
to
trigger
the
appropriate
contextual
control.
G
G
G
There
are
different
way
to
send
back
the
ack.
It
could
be
in
some
aggregated
format
and
if
the
re-transmission
is
used,
then
the
ingredients
should
determine
when
the
packet
is
lost
and
perform
the
retransmission
in.
If
fact,
if
forward
error
correction
is
used,
then
there
there
must
be
some
fake
encapsulations
inside
it
could
be.
G
It
is
applicable
to
various
scenarios.
We
talked
about
this,
so
I'm
not
going
to
talk
too
much
details
on
this.
For
example,
there
are
multiple.
There
are
multiple
segment
based
overlay
pass
or
tunnels
over
the
clouds,
or
there
are
sd1
based
branch
office
interconnection
there.
It
could
be
a
three
segment
based
interconnection
from
the
enterprise
cpe
to
a
pop
and
between
two
pops
and
from
pop
to
another
enterprise
cpe.
G
G
G
Basically,
we
want
to
convert
the
package
up
to
a
c
marking
and
we
want
to
define
a
effect
default
for
the
loops
and
it
relates
to
geneve
in
the
sense
that
we
we're
trying
to
focus
on
the
geneva
encapsulation
first
and
leave
all
the
other
potential
protocol
encapsulate
encapsulations
for
future,
so
the
genie
so
so
the
loops
is
going
the
solution.
The
solution
sketch
is
going
to
give
a
whole
picture
of
the
loops
function.
G
For
example,
what
are
the
sequence
number
space
how
to
determine
the
initial
sequence
number
how
to
generate
egg
or
neck
how
to
detect
the
laws
these
are
available
in
the
draft
here
in
the
gener
generic
information
draft.
Then
later,
a
genetic
binding
draft
defines
the
format
how
to
embed
those
loops
information
inside
the
geneve
map.
All
these
functions
to
geneve
it.
G
So
we
are
thinking
because
the
geneve
is
the
is
the
current
focus
of
the
loops
encapsulation.
So
if
you
are
interested
in
in
this,
so
you
might
want
to
join
us.
It
it
is,
is
this
buff
is
for
is,
is
belonging
to
transport
area.
Of
course
it
talks
about
quite
a
lot
of
transport
features,
but
encapsulation
is
is
also
a
very
important
part
there
for
loops.
So
we
welcome
you
to
to
join
this
buff.
G
Not
yet
because
we
want
to
make
sure
the
transport
area
are
comfortable
with
what
we're
proposing
it
does
not
break
the
internet
transport.
First
then,
if
that
part
is,
is
okay,
then
later
talking
about
in
the
details
of
the
encapsulation,
we
probably
want
to
apply
for
the
code
point,
but
basically
I
think
it's
for
the
options
it
could
be
in
the
form
of
the
geneve
options.
C
G
Slide
yeah,
so
we
are,
we
are
expecting
that
the
ingress
and
the
egress
node
here
actually
are
me-
is
not
in
host,
so
it
can
be
some
nfv
format
of
the
virtual
nodes
and
we
are
seeing
that
some
of
the
we
are
seeing
that
some
of
the
geneve
options
are
in
use,
but
but
it
is
more
likely
in
the
controlled
environment,
for
example,
in
data
center.
So
here
in
in
in
our
specific
use
case,
all
the
virtual
nodes
here
actually
can
be
configured
by
a
controller.
G
A
If
not,
then
I
think
we're
done
thanks
very
much
for
more
or
less
on
time
and
see
you
all
here
next
time.
Thank
you,
oh
and
please
do
review
any
of
the
drafts
that
we've
discussed
today
and
post
comments
to
the
list,
especially
those
rem
drafts
that
we
would
like
to
continue
discussion
on
and
move
forward
with,
some
oem
solutions.