►
From YouTube: IETF100-NVO3-20171115-1330
Description
NVO3 meeting session at IETF100
2017/11/15 1330
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
A
Okay
meeting
logistics,
so
this
time,
it'll
be
a
normal
meeting
so
and
I'm
going
to
break
up
into
round
tables
or
anything
as
we
have
done
in
the
past.
Although
we
are
going
to
hopefully
ask
for
a
little
bit
of
discussion
around
some
of
the
points
on
the
agenda,
we
have
a
very
packed
agenda,
so
speakers
please
try
and
keep
to
your
fine
thoughts.
A
A
Okay
milestones:
we
really
need
do
need
to
update
these
they're,
not
quite
as
behind
as
they
have
been
at
some
points
in
the
past,
but
nevertheless
so
I've
noted
in
red
on
these
slides.
Any
changes
that
I
think
needs
to
be
done
will
also
post
I
promise
will
post
these
to
the
list
straight
off
to
the
ITA.
A
So
the
main
changes
on
this
really
are
just
shifting
some
of
the
milestones
backwards
and
also
I
suggest
removing
the
operational
requirements
milestone.
We
did
have
a
draft
on
this
a
very
long
time
ago.
I
think
it
was
last
updated
in
2013
around
that
time
doesn't
seem
to
be
progressing.
So,
let's
just
write
the
milestone.
A
A
data
plan
encapsulation
our
chosen
data
plan
encapsulation,
which
is
janay-
that
is
on
the
on
the
ITF,
but
ideally
like
to
send
this
for
working
group
last
call
after
this
idea,
but
we
probably
need
some
some
area
reviews
in
a
couple
of
well.
We
probably
suddenly
still
routing
area
chat,
review.
We've
never
done
that.
I
think
that
the
genève,
but
we'll
probably
need
a
transport
error
review
as
its
new
encapsulation
will
also
need
a
security
area
review.
A
A
Once
the
world,
what
good'll
a
school
for
that
is
underway,
I
think,
as
we
said
before,
with
did
the
design
team
draft,
which
was
empty.
A
korean
cap
said
that
to
the
last
goal
as
well,
so
there's
been
some
progress
on
the
MVA
control
plan
requirements
in
a
few
areas,
for
example
the
hypervisor
to
NBA
control
plan
requirements.
Document
needs
to
be
last
called
after
this
idea.
A
A
Okay,
I
just
wanted
to
have
some
slides
up
now,
just
to
kind
of
review
where
we
are
with
what
kind
of
dress
we
have
in
the
working
group
related
to
some
of
our
milestones
so
around
the
control
plane.
I
think
we
have
drafts
at
least
targeting
each
of
the
main
control
plane
areas.
One
is
the
MBE
to
NBA.
Well,
we
call
it
a
control
put
in
in
quotes
a
control,
plane,
I
think
we
discussed
a
while
ago.
This
would
be
net
comp.
A
Obviously,
there's
an
appropriate
young
models
and
the
current
young
model
that
we
have
in
mvo.
Three
only
supports
VX,
LAN,
I.
Think
really
what
we're
looking
for
is
as
a
young
model
that
supports
junaid,
since
that's
our
standards
track
approach,
so
I
think
it
would
be
very
good
to
get
to
see
some
drafts
in
that
pathways.
A
C
A
Okay,
so
the
other
part
is
hypervisor
28
control
plane,
so
we
have
the
high-priced
won't
be
a
control
plane
requirements
that
kind
of
corresponds
to
the
VDP
work
in
the
metric
awake,
which
is,
is
now
done
so
we,
as
I
mentioned,
we
need
to
move
forward
with
basketball
innistrad.
We
also
have
also
discussed
applicability
of
distributed
control.
Planes
such
as
bgp
evpn,
so
have
the
draft
particular
to
statement
for
this
on
the
agenda.
A
One
thing
I
noticed
there
is
that
our
charter
is
a
little
bit
pat
strict
in
not
the
skin
literally
says
it
doesn't
mention
the
distinction
between
an
applicability
statement
and
a
protocol
solution
with
regards
to
the
BGP
control
plane.
It
said
it
basically
is.
If
you
it
could
be
very
much
interpreted
as
you
shall
not
talk
about
BGP
in
this
working
group,
which
perhaps
perhaps
we
need
to
look
at
tweaking
that
part
of
the
Charter.
A
A
We
need
to
show
some
progress
in
this
area
and
some
concrete
concrete
steps
to
making
progress
on
developing
security
solutions
within
an
OPI
three
really
in
order
to
get
Junaid
through
now.
This
means
we
probably
need
to
adopt
those
solutions
documents
pretty
rapidly.
So,
ideally,
it's
very
good
to
make
progress
on
the
on
the
requirements.
Now.
Tech,
security
architecture,
but
really
the
young
goal-
is
to
get
those
solutions
adopted
in
the
working
group
and
published
eventually.
A
The
other
area
that
wanted
to
mention
was
OEM
and
how
we're
going
to
progress
on
Oh
am
so
over
the
years
own
vo3
has
really
had
a
variety
of
OEM
solutions.
We
had
some
kind
of
point
solutions
for
for
a
non-standard
track
data
plane,
for
example
the
exelon,
the
x9
GPAs
or
the
OEM
bit
definition
for
the
GPA
we've
got
drop
today
on
the
epsilon
BFD
there's
a
path,
MTU
discovery.
Draft
there
was
a
draft
on
transcending
traceroute.
A
A
A
E
C
Two
other
methods
that
listed
here
IOM
and
alternate
marking
method
is
hybrid
because
hybrid,
an
IOM
they
exist
only
when
there
is
a
data
flow.
Their
characteristic
of
active
I
am
that
this
test
packet
can
be
injected
in
the
network
when
there
is
no
traffic.
So
if
we
consider
that
we
need
to
do,
for
example,
this
part
of
like
service
activation
testing
or
service
activation
protocol,
so
to
do
verification
of
service
without
live
traffic,
then
F
before
M
is
strong
requirement.
C
If
we
think
that
it's
sufficient
to
do
om
only
when
there
is
a
data
present,
then
our
hybrid
as
well.
Another
application
of
active
om
is
obviously
the
protection,
because
without
at
before
M,
we
cannot
monitor
the
protection
pact
as
there
may
be.
No
data
flow.
Okay,
so
I
would
clarify
this
question
to
the
group.
E
A
Ok,
so
I
think
this
basically
comes
back
to
and
what
I
was
trying
to
get
to
on
this
slide
was.
We
need
to
address
specific
problems
that
can't
be
addressed
with
existing
tools
within
NBO
3.
We
need
to
identify
what
those
problems
are
that
we're
trying
to
address
in
his
working
group
and
then
derive
what
we
need
to
do
in
OEM
from
that,
because
many
of
our
solutions
in
the
past
have
been
he.
E
A
C
D
I,
don't
think
we
are
disagreeing
on
the
requirements.
Are
such
I
think
what
we
are
trying
to
convey
here
is
that
the
proposed
work,
or
whatever
we're
going
to
bring,
should
address
the
requirements
which
are
already
captured
right,
so
the
existing
things
do
not
exist
in
tool
set.
So
that
means
we
need
to
do
that
work
and
that's
one
of
the
things
which
outlines
here.
These
are
the
proposals
out
there
and
we
need
to
progress
forward
with
the
pointed
solutions.
A
A
F
F
So
yeah
draft,
you
know
Jenny
was
updated
on
in
September
and
then
we
made
you
know
few
changes
based
upon
the
previous
working
group
discussions
and
also
based
on
the
design
team
recommendations.
So
on
one
of
the
point
was
to
add
clarifications
on
the
critical
options
bit
and
we
did
that
in
Section
3.2.
The
key
point
here
you
know
how
what
we
clarified
is.
It
is
helpful
in
options
processing
in
hardware.
F
It
gives
the
flexibility
for
the
the
hardware,
the
options
to
be
processed
either
in
the
hardware
fast
path
or
in
the
software
and
the
slow
path,
and
you
know
the
next
point
is
regarding
the
fragmentation
and
there
was
a
discussion
and
also
request
to
add
additional
clarification
on
the
fragmentation
and
also
add
an
infinitive
reference
to
a
similar
protocol,
which
is
actually
PW
III.
That
also
offers
similar
recommendation.
So
what
we
did
is
we
provided
some
clarification
on.
F
What
are
the
breast
best
practices,
and
one
of
the
best
practices,
of
course,
is
to
help
to
set
them
to
use.
I
saw
the
physical
layer,
that
is,
that
also
accommodates
the
encapsulation
and
a
similar
you
know
or
recommendation,
has
also
been
provided
in
P.
We
know
P
W
III
and
we
provided
an
infirmity
reference
so
that
it
can
also
refer
to
that,
and
also
we
updated
additional
references
that
touches
upon
multiple
sections
and
also
the
reference
section.
F
So
I'm
sure,
okay,
so
on
the
next
slide,
actually
we
are
discussing
about
one
of
the
you
know
the
comments
on
you
know
the
alternate
marking
proposal
that
was
made.
As
part
of
you
know,
this
is
again
a
point
solution,
as
the
chairs
you
know
discussed
earlier
in
the
previous
I
am
discussion.
There
are
many
different
solutions
on
table
and
this
is
another
one
of
them
and
we
did
as
Geneva
tha's.
We
reviewed
the
proposal
to
see
you
know
what,
if
there
is
any
impact
to
Genevan
itself
and
what
we
believe
is.
F
We
strongly
feel
that
this
should
be
implemented
as
an
extensibility
and
so
that
the
extensibility
can
be
used
not
just
for
this
solution,
but
also
it
it
can
have
wider
adaptability
for,
for
I
am
in
general.
An
example
of
such
one
is
actually
I
am
actually
in.
Third,
there
is
a
proposal.
That's
going
to
come
up
for
discussion
today.
That's
that,
that's
just
we
are
showing
that
as
an
example,
but
I'm
not
discussing
about
the
merits
of
for
one
a
and
proposal,
most
of
the
other
a
way
and
proposal.
F
But
what
we
are
saying
is,
you
know
you
need
not
necessarily
impact
the
base
header,
but
extensibility
is
used
for
such
kind
of
you
know
purposes
so
that
you
know
om
can
independently
evolve
as
an
extension
and
again
this
depends
upon
you
know
if
there
is
a
working
group
consensus
on
way,
M
solutions
in
general
and
then
that
needs
to
progress.
You
know
independent
of
it
independent
of
the
base
protocol
and
moving
on
to
the
next
slide.
F
F
So
as
the
next
steps
you
know,
what
we
are
doing
is
to
working
on
adding
additional
description
to
the
security
best
practices
based
I
mean
are
also
to
add,
an
in
know,
potentially
adding
an
infirmity
reference
as
well
in
this
section
as
requests.
You
know
the
chair
already
mentioned
about
adding
an
infirmity
references
and
also,
you
know,
also
to
add
additional
clarification
in
there.
Basically
taking
taking
some
some
kind
of
you
know
the
previous
reviews
that
has
happened
in
other
similar
drafts.
G
G
F
I
mean
the
matrix
of
the
alternate
marking
itself
will
be
separately
discussed
as
the
part
part
of
the
ym
solution.
So
what
I
am
suggesting
is
one
of
the
you
know
that
are
specifically
called
out,
for
you
know
allocating
two
bits
in
the
base
header
in
order
to
do
that,
and
what
I
am
proposing
on
behalf
of
the
authors
is
to
you
know,
use
an
extension
for
achieving
such
such
solution
provided,
provided
the
working
group
decides
to
go
in
that
direction
for
ultimate
part
in
pro-am.
F
So
my
point
is
I
mean
this
is
one
solution.
It's
not
just
cover
the
entire
way
and
framework,
but
there
are
multiple
different
proposals
on
table
and
if,
if
you
know
all
those
solutions
needs
to
be
accepted,
then
we
are
allocating
more
and
more
in
the
base
header.
As
such,
you
know
our
our
opinion
is
it's
best
to
be
addressed
as
an
extension,
so
that
you
know
it
can
not
only
cover
this
particular
problem,
but
we
could
also
address
other
use
cases
for
OAM.
F
C
B
C
C
I
I
I
We
focus
as
well
on
engineering
so
because
the
ambulation,
a
security
requirement,
was
more
generic
to
any
gap,
not
really
focused
on
a
specific
in
cap.
So
we
aligned
the
draft.
Then
you
see
security
requirement
and
then
we
put
specific
requirement
that
will
protect
any
cap
out
and
you
see
cap
of
Jeannie.
So
next
slide.
Okay,.
I
So
so
I
think
this
is
the
status.
This
is
exactly
what
I
mentioned
that
aligning
was
idea,
and
you
see
security
requirement.
Sorry
is
not
written
right
here
with
the
focus
on
the
genève,
so
so
it's
protecting
the
Geneva,
a
packet
component
we
mentioned
in
the
draft
that
protecting
the
whole
Ginny
packet
is
out
of
scope
because
there
are
already
solution
that
can
protect
with
that.
So
it's
how
to
protect
portion
or
different
packet,
which
is
Geneva's
header
and
options,
for
example
right.
So
I
think
that's
it.
A
A
A
E
Oh
yeah
this,
so
this
is
when
I
stand
up
and
remind
you
that
we
really
need
to
pay
attention
to
the
security
and
exhort
you
to
please,
please,
please
actually
review
the
security
work.
Okay,
I
we
wish
to
have
Geneva
go
through.
We
need
to
make
sure
that
we
are
not
causing
substantial
security
issues
that
are
going
to
impact
the
deployments,
and
we
need
to
be
sure
that
we
have
ways
of
accommodating
increased
security.
You
know
integrity
or
confidentiality,
particularly
in
multi-tenancy
data
centers.
E
J
Good
afternoon
my
name
is
Jorge
Rob
Allen,
and
this
draft
is
applicability
of
the
VPN
2003
networks.
This
is
the
my
two
colors
for
Matthew
and
Tommy,
so
a
short
introduction
about
the
year
to
draft.
So
this
is
an
informational
draft,
so
in
applicability
draft
and
intends
to
describe
from
a
very
high
level
how
to
use
a
VPN
as
a
control
thing
for
an
MDL
three
network.
So
it's
you
will
notice.
J
So
it's
not
a
standard
track
document,
so
we
are
not
trying
to
specify
any
new
code
of
protocol
or
any
extension
to
the
existing
me
began.
So
for
that
we
got
their
best
working
group
and
we
make
some
assumptions
here.
So
we
make
the
assumption
that
we
have
a
bunch
of
network
virtualization
edge
devices.
They
need
to
change
the
mapping
tables
the
information
we
are
mechanically
addresses
the
I
control
plane
protocol
and
that
control
plane
protocol
is
going
to
be
EDD.
J
N,
so
the
trough
has
this
section
about
why
a
VPN
any
VPN,
sorry
in
and
vo3
networks.
So
there
are
certain
reasons
why
a
VPN
is
being
used
today
from
a
control
perspective.
We
need
a
these
three
things
that
you
have
in
this
slide.
We
need
to
have
the
discovery
of
the
remote
MDEs
in
the
network
that
are
attached
to
the
same
broadcast
domain.
J
We
also
need
the
dissemination
of
the
maknae
P
host
information,
user
mapping
tables
that
you
need
on
the
NDEs
in
order
to
forward
the
the
packets
for
the
same
within
the
same
tenant,
and
you
also
need
some
advanced
features:
things
like
mobility
or
Mac
detection,
or
the
reduction
of
suppression
of
the
bump
traffic,
our
multi
going
just
to
name
a
few.
So
all
these
things
you
can
do
with
a
VPN.
The
trap
also
compares
well
actually
tells
that
you
could.
J
You
could
achieve
some
of
these
things
using
the
flood
and
learn
approach,
and
that
describes
the
solution
with
the
flood
and
learn
and
then
basically
concludes
that
that
solution
has
some
shortcomings
that
you
can.
You
can
actually
fix
with
the
evpn,
and
then
you
have
a
bunch
of
sections
explaining
how
to
again,
from
a
high
level
point
of
view,
how
to
apply
a
VPN.
I
J
Layer
to
services
for
layer,
three
services
and
also
for
some
advanced
features,
for
instance,
for
layer
two
services.
You
can,
if
you
gather
a
group
of
nd
ease
that
are
attached
to
the
same
subnet
same
tenon,
you
can
use
the
the
basic
evpn
routes
in
order
to
do
the
how-to
discovery
of
their
remote
employees,
and
you
can
also
use,
of
course,
the
Mac
IP
routes
to
distribute
the
Makah
IP
information
of
the
different
hosts.
J
J
The
trap
also
discusses
some
other
topics
like
in
vo3
encapsulations,
for
a
VPN
and
in
particular
since
Geneva's
the
the
chosen
one
and
this
working
group
there's
a
draft
already
does.
That
is
tackling
how
the
how
to
use
EBP
unfortunate
actually
in
the
in
slide
I
have
the
wrong
reference,
but
in
the
in
the
track
you
will
find
a
the
right
reference.
There
is
also
some
talk
about
om
in
the
context
of
MgO,
3
and
evpn,
and
finally,
you
have
a
section
for
advanced
features.
J
You
can
also
do
smart
things
with
a
bump
traffic,
especially
the
vm,
originated
a
control
plane,
bump
traffic
like
a
how
to
reduce
or
even
suppress
things
like
are
flooding
for
naval
discovery
or
IGMP
messages
or
even
same
messages.
Another
separate
a
draft
documents
for
that
in
the
best
working
group.
J
Some
of
the
things
that
we
are
describing
in
the
draft
is
how
to
optimize
ingress
application,
how
to
tackle
multihoming,
how
to
do
intercepted
forwarding
with
recursive
resolution,
even
how
to
do
intercepted
forwarding
for
multicast
traffic
and
DCI
and
again
you
have
a
long
list
of
reference
documents
and
that
you
can
check.
Take
you
if
you
need
to
to
see
the
details,
so
that's
pretty
much.
It
so
pleased
with
the
on
the
draft,
and
the
idea
is
that
it
has
to
be
useful,
and
we
would
like
to
low
to
hear
your
feedback
about
it.
J
A
E
K
K
Erratic,
our
layering
that
are
out
of
scope
here
we
want
to
make
support
measurement
for
pair
BNI
between
two
nd
devices.
That
support
is
Indian
anatomy.
Now
why
we
need
to
present
the
marking
needed
operation
in
mu
3.
There
is
an
angle
change
updraft
that
recommend
the
use
of
alternate
marking
to
perform
measurement
and
means
it
needs
to
be
initiated.
K
Machi
meters
split
the
our
flow
consecutive
batches
of
pocket
by
change
a
flag
a
bit
in
the
other.
In
this
way,
you
can
create
consecutive
of
batches
that
are
unambiguously
recognized
along
the
path
and
each
measurement
point
can
easily
take
the
counter
for
each
batches
and
by
comparing
the
counters
of
the
batches
between
two
million
two
measurement
point.
You
can
calculate
particle
in
a
very
simple
way.
The
same
methodology
can
be
applied
for
delay
in
memory,
so
we
distinguished
about
tooth
technique.
The
third
single
marked
method
and
double
mothman.
K
K
K
But
this
can
be
done,
but
it's
just
an
approximation
some
time,
because
it
does
not
work
in
case
of
alt
order,
because
the
first
or
last
part
of
our
batch
can
be
and
can
even
out
of
see
them.
Otherwise
we
have
a
do
a
rage,
delay
calculation,
so
each
batch
for
each
batch.
You
can
calculate
the
average
time
stamp
to
collect
the
time
stamp
for
each
batch
calculate
the
average
to
instant
and
difference
between
the
average
times
time
to
between
two
and.
E
B
K
L
E
K
K
For
more
precise
measurement
and
more
complete
measurement,
we
need
the
double
mark
method,
so
we
need
to
add
another
flag
to
the
first
one
to
the
L
flag,
that
we
call
the
big
flag
delay
flag
or
to
select
some
special
packet
in
our
path
dedicated
for
the
delay
measurement.
So
this
packet
are
markedly
good,
it
is
implied,
and
so
on,
ambiguously
recognized
along
the
our
fat
and
we
can
calculate
the
delay.
K
E
K
Or
about
alternate
mark
method,
but
we
are
working
on
this
technology
and
ultimately
I
want
to
mention
also
a
new
draft
about
compact
mark
anita
that
they
give
you
also
some
some
solution
that
used
the
hashing
methodology
for
select
some
pocket
to
perform.
Delay
measurement
also
multiplexing
technique
to
use
one
bit
and
to
perform
the
delay
with
the
opposite
date
and
so
on.
So
there
is
an
advance
and
there
is
a
variation
of
the
basic
to
end
the
foundation
document,
but
I
suggest,
if
you
are
interested,
you
can
be
okay.
K
This
is
our
proposal
about
the
Geneva
scale.
So
again
the
amulet
rien
cap
document
suggests
and
considered
generally
the
most
suitable
expression
for
a
conduct,
additional
network
and
yeah
about
the
request
of
the
to
be
together.
We
make
this
proposal
to
consider
me
to
be
team
leader
designed
dedicated
for
this
methodology
and
called
the
massiveness
okay,
but
next
step
we
can
consider
new
application
of
this
methodology
because
it
is
an
ongoing
activity
on
this
technology,
so
I
suggest
also
to
read
the
multi-point
of
markup.
K
E
C
C
Reason
interesting
for
in
two
or
three
to
discuss
this
document
going
back
coming
back
to
question
of
allocating
bits,
I
believe
that
it
would
be
good
to
have
this
discussion
on
a
list
and
there.
In
my
opinion,
there
are
options
because
use
of
all
bit
and
see
bit
that
currently
allocated
in
the
header
probably
could
be
better
explained
and
I
think
that,
at
least
in
an
experience
discussion
with
a
as
a
sim
working
group,
it
was
reviewed.
E
C
E
F
Yes,
so
specifically,
I
wanted
to
talk
about
another
C
bit.
I
just
mentioned
that
you
know
there
will
be
our
added
additional
clarification
on
the
use
of
C
bit
and
that's
useful
in
hardware
implementations.
Are
it
gives
the
flexibility
for
the
you
know
the
the
package
to
be
processed,
all
options
to
be
processed
either
in
the
hardware
fast
path
or
the
software
slow
path?
That
information
is
already
been
updated
in
the
top
and
the
second
point
about
öbut
again.
F
This
is
specifically
for
our
am
messages
so
when
you
are
processing
the
entire
packet
stream
of
the
data
packets,
as
well
as
the
OEM
messages
in
the
NVE
endpoints,
it
allows
the
it
and
typically
in
the
NVE
endpoints
you
have
multiple
queues
and
the
data
queues
and
the
exceptions,
queues
or
the
control
Q
in
which
the
OEM
messages
are
typically
processed
and
sent
to
the
ym
agent.
That's
in
the
NVE
endpoint,
when
you
typically
implement
in
the
service
and
and
the
orbit
allows
to
send
this
through
the
control
Q.
F
C
Well,
okay:
I
can
refer
to
I
understand
that,
as
if
C
working
group
has
its
own
reasons
to
deprecate,
save
it,
but
I
think
that
there
is
something
to
be
looked
at
and
given
a
thought
in
terms
of
using
orbit
to
prioritize
processing
for
en
packet.
I
strongly
disagree
with
this
premise,
because
the
whole
idea
of
om
is
that
your
plate,
sharing
with
their
data
that
you're
measuring
flow,
that
you're
measuring
or
monitoring
doing
something
special
for
om,
really
skews
and
alters
your
so
I
strongly
disagree
with
this
idea.
C
F
E
F
We
don't
see
any
difference
because
you
are
approximating
over
a
batch
of
products,
I'm,
not
a
pro
packets
I'm,
not
even
going
and
questioning
the
merits
of
whether
your
alternate
marking.
My
third
is,
you
know
accurate,
and
it's
all
serves
its
purpose.
That
will
be,
you
know,
discussed
separately.
All
I'm
talking
about
is
the
proposal
of
using
bits.
Rather,
you
know
the
architectural
II.
It
makes
sense
to
implement
as
an
extension
so
that
this
can
evolve
independently
and
you
can
add
additional
capabilities
to
that.
One.
F
For
example,
if
you
wanted
to
add
sequence
numbers
to
the
packets
or
you
want
to
identify,
because
you
are
really
not
proposing
doing
time,
stamping
on
a
specific
packets-
and
this
allows-
you
know
you
can
also
add
additional
capabilities
in
there
in
order
to
identify
specific
packets
to
do
your
time.
Stamping
so
so
I
mean,
as
I
said,
right
extensibility
is
allows
you
to
do
specifically
such
kind
of
use.
Cases
and
I
would
strongly.
You
know,
recommend
you
to
go
and
look
at
me.
Look
into
that
as
a
possibility.
Yes,.
C
I
want
to
mention
two
things:
first,
we're
not
asking
for
timestamp
in
sequence
numbers
and
what
Kyle
mentioned
that?
Could
they
additional
options?
I
invite
that
proposal,
because
I
think
that
these
are
governor
proposals.
So,
let's
stay
on
our
quest,
so
we're
only
requesting
to
this
we're
not
requesting
time
stamp
on
sequence
numbers.
A
K
K
We
need
a
little
of
effort
more
so
we
don't
need
to
beat.
We
don't
need
an
extension
to
the
finally
in
an
orchestration
also
my
experience
for
the
application
and
on
on
the
network,
seeing
that
with
the
ACL.
You
can
configure
this
on
router
and
you
can
implement
by
using
the
current
Rooter
implementation.
A
G
A
G
G
I
can
hold
it
okay,
so
the
base
document
of
IOM
defines
data
fields.
Basically,
these
data
fields
include
information
which
can
be
either
included
on
a
hop
by
hop
basis
or
on
an
end
to
end
basis,
and
this
information
includes,
for
example,
information
like
node,
IDs
interface,
ID
is
timestamps
and
also
other
types
and
IOM
is
defined
in
a
way
that
can
fit
different
types
of
encapsulations,
so
it
can
be
encapsulated
over
ipv6
sr,
v6
and
a
sage
and
also
Geneva.
This
is
the
context
of
this
graph.
G
Okay,
so
this
is
briefly,
this
is
what
IOM
over
genève
looks
like,
so
we're
going
to
have
obviously
the
Geneva
header
and
then,
after
that,
the
IOM
data
is
encapsulated
in
a
Geneva
tunnel
option,
so
we
can
see
the
Geneva
tunnel
option
and
then
it's
followed
by
the
IOM
header
and
then
the
IOM
data.
Obviously,
after
that,
we
have
the
payload,
and
the
idea
is
that
in
the
Geneva
tunnel
option
we
have
the
option.
Class
in
type
would
specify
what
kind
of
volume
data
resides
after
that.
G
So
now,
at
this
point,
we
we
come
to
the
interesting
part,
which
is
the
open
questions,
so
I'm
going
to
mention
the
open
issues
that
we'd
like
to
talk
about
here
and
then
after
that,
we'll
open
it
for
questions
and
discussion,
and
obviously
we
want
I
owe
em
to
be
hardware
friendly.
So
some
of
these
open
issues,
there
are
two
main
open
issues
which
are
kind
of
related
to
the
way
IOM
is
implemented
in
hardware.
G
One
open
issue
is
about
the
tunnel
option
lane
and
today
the
way
Geneva
is
defined
is
that
you
can
define
a
Geneva
tunnel
option
up
to
128
bytes
in
length.
So
the
question
we're
asking
here
is
given
that
we
can
certainly
think
of
use
cases
where
we'll
need
IOM
information,
which
is
greater
than
128
bytes.
Would
it
be
a
good
idea
to
allow
Geneva
tunnel
options
to
be
longer
than
128
bytes?
G
G
G
So
one
way
to
do
that
on
the
right
side
is
to
have
these
three
options,
all
as
part
of
the
Geneva
extensibility.
So
we'll
have
three
different
Geneva
tunnel
options:
three
tlvs:
okay,
that's
the
right
option
and
the
left
option
is
to
use
a
dedicated
protocol
type
for
IOM.
So
that
means
that
in
the
Geneva
header,
the
protocol
type
will
say.
G
G
So
the
right
alternative
may
be
difficult
in
some
implementations
and
obviously
there's
also
an
advantage
to
the
right
alternative,
because
the
genève
header
includes
an
optional
length
field
which
actually
tells
you
where,
at
the
end
of
all
the
options
is
so
if
you
want
to
just
skip
the
options,
you
can
do
that
okay.
So
it's
not
a
clear
cut
between
the
two
options.
There
are
poison
content
with
again
we'd
like
to
hear
opinions
about
that.
The
current
version
of
the
draft
describes
the
right
alternative,
which
uses
Geneva
options.
G
It's
being
discussed
there
and
this
week
we're
presenting
different
encapsulation
specific
drafts
in
different
working
groups,
so
we're
presenting
here
the
IOM
over
Geneva
and,
as
you
can
see,
there
are
other
grafts,
in
other
words,
and
basically,
what
we
would
like
to
ask
right
now
is
to
receive
feedback
about
whether
the
working
group
is
interested
in
adopting
this
work
about
whether
we're
interested
to
work
on
this
and,
of
course,
specifically
related
to
the
open
questions
that
we
raised
here
so
good
time
for
questions.
Okay,.
C
Because
you
you
talk
about
telemetry
telemetry
is
some
information,
that
is
our
state
of
the
no
physical
resources
like
CPU
utilization
memory,
utilization,
buffer
queues,
that's
a
telemetry,
that's
not
measured
by
the
flow,
and
usually
this
being
exported
out-of-band
transport,
so
you're
suggesting
to
export
this
telemetry
information
using
the
wide
traffic
you
state
that
this
is
advantage.
I
would
like
to
understand
why
this
is
advantage.
Okay,.
G
So
I
just
want
to
emphasize
I'm
not
going
to
focus
on
the
term
telemetry.
This
may
be
the
wrong
term,
okay,
but
what
we
want
to
do
here
is
to
gather
information
about
a
path
which
includes
static
information
like
node,
IDs
interface,
IDs
in
state
information
like
time
stamps
and
queue
depth,
and
so
on.
Okay,
what.
C
C
G
C
E
C
G
B
G
L
So
yesterday
was
talking
to
Frank.
So
is
there
an
outer
problem
like
no?
This
is
the
max
limit
where
I
won't
that
I
can
be
collected,
say
Mike,
please,
okay!
Is
there
any
max
limit
on
the
OM
data
that
can
be
connected
calculate
in
the
packet?
It's
like
500
bytes
are
300
bytes,
but
there
is
no
max
limit
as
long
as
you're
empty
your
supports
you
can
collect
it.
Is
it
yeah.
G
L
G
G
L
G
M
Frank
Roberson
just
to
be
clear,
the
left
hand
side
doesn't
really
exist
today,
right
because
it
would
mean
so
Jimmy
has
its
own
protocol
option
64
something
right,
so
define
new
ones
for
doing
something
like
on
the
left
hand
side.
So
you
can
almost
say
that
that
is
complimentary,
orthogonal
whatever
to
genève.
So
if
we're
riding
with
engineer
tunnel
option,
is
he
on
the
option
which
leads
to
nested
lookups,
which
is
a
challenge
from
a
hardware
implementation
perspective,
at
least
to
some
extent?
M
But
the
bigger
question
is
really
because
it
leads
us
to
128
bytes
max,
which
is
a
way
of
constrain,
and
so
it's
a
concern
and
if
we
could
spare
another
bid
or
two
for
length
in
the
genepattern
that
would
kind
of
relax
things
quite
a
bit
so
that
I
think
the
end
cap
would
be
more
workable
and
I
wanted
to
go.
Come
back
to
the
original
discussion,
so
I
OEM
do
certain
things.
Certain
things
are
quote
unquote
up
by
hob
and
there
is
a
notion
of
a
transit
hop
result.
M
So
those
are
things
that
are
end
to
end
like
that.
He
can
do
use
end
to
end.
Like
sequence,
numbering
time,
stamping
and
others
so-
and
it
depends
on
the
use
case
on
how
you
use
these
options.
So
if
you
want
intermediate
things
to
go
and
fill
in
well,
maybe
maybe
not
I
think
that's
orthogonal
to
the
discussion
here.
What
we
want
is
a
container
to
carry
IOM
data
and
what
happens
within
the
container
I
think
it's
up
to
what
the
operations
remain.
B
N
We've
got
two
edges
that
are
connected
to
an
l2
access
network
and
those
two
Geneva
edges
are
working
in
active
standby
mode
to
avoid
loops
in
the
l2
in
the
access
network
and,
of
course,
in
case
of
error,
of
the
primary
node.
We
want
to
signal
very
quickly
to
the
rest
of
the
Jenna
fabric
that
how
to
reach
l2
access
network.
So
this
is
the
goal.
This
is
a
use
case
here
for
this
drug.
So
what
are
we
doing?
N
We
are
using
OEM
mechanism
inbound
in
the
Geneva
Geneva
tunnel
to
to
signal
that
the
over
edges
in
the
fabric
need
to
flush
or
move
the
max
from
one
edge
to
another.
The
goal
is
to
have
a
faster
convention
convergence
not
to
wait
for
Mac
edging.
That
would
be
done
normally
in
this
case,
so
this
in
this
drive.
What
we
propose
is
a
new
TLV
that
would
be
sent
by
the
standby
edge
to
the
entire
fabric
with
the
rest
of
year,
energy
in
in
the
fabric
there.
N
N
O
D
N
N
O
Data
plane,
learning
in
t,
v--,
BB,
pls
and
so
forth,
and
to
make
it
encapsulation
and
transport
independent,
RFC,
62
46
suggests
using
existing
I
Triple
E
flushing.
You
know
you
can
just
send
the
mbrp
message
inside
your
Geneva
Inca,
indicating
the
vni
and
that
basically
understood
by
the
remote
and
flashes
the
night
address
for
that
DNI,
and
that
makes
it
transport
independent.
So
have
you
given
any
consideration
to
the
existing
solutions.
O
I
O
I
O
O
G
E
J
M
J
P
I
My
my
name
is
Sammy
Woodrow,
so
I'm
presenting
a
draft
on
Geneva
applicability
for
SFC,
so
SFC
has
defined
and
in
cat
is
an
SH
in
tap
and
for
n
sh
has
FC
already
have
defined
a
protocol
for
it,
so
it
can
be
carried
by
any
transport.
So
you
need
to
carry
an
SH
that
would
be
state
forward.
Geneva
ready
is
a
transport
that
can
carry
the
protocol,
so
we
simply
need
to
put
in
the
genève
header
protocol
type
or
an
SH,
and
now
we
can
carry
on
City.
I
So
we
are
proposing
having
a
source
routing
LV,
very
similar
segment,
routing
consisting
of
a
list
of
service
function.
We
call
that
option
a
service
function
list.
It's
simply
a
list
of
IP
addresses
of
the
service
function
that
service
function
passes
to
gusu.
Of
course.
By
doing
this,
we
eliminate
as
a
need
of
having
a
pass
ID
or
a
service
topology
or
a
service
forwarding
table
that
map
the
path
ID
and
service
index,
as
defined
by
nsh2,
n
IP
and
as
well.
I
We
can
carry
into
another
option
here:
visa,
an
SH,
metadata
and
SH
has
defined
metadata
v
on
take
stand
by
two
variable
lines,
so
those
can
be
carried
as
well
as
option
of
course
yeah.
You
know,
as
I
mentioned,
we
we
can
carry
a
message
as
a
protocol
into
Geneva
and
and
that
doesn't
really
require
any
graph
to
say
so.
I
So
this
is
the
use
case
here
following
the
SFC
architecture,
so
those
and
bees
can
be
sought
as
service
function
for
order
that
are
connected,
or
rather
he
connected
to
the
different
service
function.
So
at
the
ingress
and
V
we
are
doing
the
classification
and
the
class
apart
here
such
is.
The
service
function
pass
information
into
the
genies
tunnel
as
an
option
and
send
it
and
and
then
sorry
resolved
the
first
service
function
to
the
genies,
funnel
that's
connected
to
the
NVE
or
the
service
function
or
order
that's
connected
or
hosting.
I
It
was
an
easy
hypervisor
that
could
be
hosting
the
BNF
function,
so
it
will
resolve
it
to
the
tunnel
to
the
person
B
and
then
the
nd
here
can
send
the
packet
to
the
service
function
and
the
return
packet
when
it
comes
it
can
find
into
the
service
function
list.
The
next
service
function
to
go
to
resolve
it
again
to
another
genève
tunnel
and
and
pass
goes
on.
Of
course,
it
multiple
service
function
are
hosted
within
the
same
service
function
for
order
or
MBE.
Then
you
know
service
function
border.
I
We
have
the
intelligence
to
send
the
different
service
function.
Now,
when
the
last
NDE
or
the
egress
and
the
e
received
a
last
packet
it
it
will
forward
to
the
last
service
function
and
for
the
return
it
can
forward
the
final
destination
of
the
customer.
This
means
there
are
definitely
a
lot
of
details
on
exactly
how
to
do
that
and
I.
Think.
The
previous
slide
I
forgot
to
mention
that
that
source,
routing
TLV
follow
could
be
secured,
as
well
with
some
authentication
here
following
procedure
described
in
the
segment
routing
header
draft
ecigs.
I
That
source
routing
here
B
can
include
both
ipv4
and
ipv6
addresses
so
start
limited
to
only
sixes
before
or
v6
can
be
into
that
service
functionality.
So
yeah
I'm,
saying
you
know,
please
read
the
draft.
There
are
lots
of
detail
that
describe
the
exact
mechanism
and
as
well
as
some
details
about
what
we
are
gonna
be
passing
along
the
packet.
If
even
surface
function
is
nsh
aware
or
not
you
know,
and
how
are
we
going
to
pass
me?
H
H
I
H
Eros
and
mine,
I,
haven't
I,
didn't
was
reading
the
draft
at
lunch
and
then
I
got
distracted
and
finish.
It
I
think.
Maybe
you've
just
explained
as
quickly
in
your
last
little
comment
there.
But
do
you
discuss
how
to
map
so
be
we're
stripping
the
encapsulation
before
sending
into
the
service
function?
Could
how
do
we
map
that
packet
back
to
you.
I
B
H
I
D
I
C
So
this
is
a
short
update
on
a
draft
that
been
working
on
the
need
for
of
the
explain
so
two
version
updates.
We
clarified
edit
a
use
case
that
actually
what's
remarkable
if
I
go
to
the
last
bullet,
you
see
that
there
are
already
two
individual
implementations
of
the
V
over
V
X,
then
and
I
think
that's
kind
of
clue.
Us
hey
guys.
Can
you
finish
this
so
and
one
of
this
implementations
they
illustrate
their
use
case
to
use
the
monitoring
of
multicast
bomb
traffic
replicator
so
which
is
really.
E
C
C
But
you
know
if
you
cannot
do
any
better
than
you
have
to
do
this,
so
you
have
outer
Ethernet
header,
IP,
header,
UDP
header
than
the
extend
header
and
inner
Ethernet
header.
You
know
IP
header,
UDP
header
and
then
finally
only
give
the
control
message
just
for
pure
scientific
interest.
This
is
how
the
excellent
GP
will
look
for
the
view
control
packet.
C
So
thanks
to
the
multi
protocol
support,
it
looks
much
nicer
and
more
elegant
and
actually
it
can
have
either
IP
encapsulation
to
demultiplexing
of
give
the
control
packet
using
well-known,
UDP
port
for
the
single
hop
give
this
session
in
forward
direction,
or
it
can
use
encapsulation
or
a.m.
header
and
then
give
the
control
message
can
go
without
any
IP
UDP
overhead.
C
So
here
our
request
to
the
working
group:
please
discuss
it
and
world
like
adoption
of
this
document
and
we'll
think
that
it's
really
new
time,
because
there
are
implementations
and
second
we
are,
would
you
agree
or
suggest
to
address
the
excel
NGP
in
the
same
document
or
you
think
that
it
should
be
a
different
document?
Oh.
E
Yeah
Atlas
so
I'm
very
happy
to
see
that
the
excellent
work
it's
you
know.
The
excellent
GP
is
something
that
we
decided
as
a
working
group
is
not
going
to
be
standard
track,
and
the
working
group
needs
to
focus
on
OAM
for
Geneva
we're
happy
to
see
stuff
for
the
excellent.
That's
what's
out
there
and
deployed.
Q
Hi
I'm
John
lemon
first,
my
apologies
for
omitting
the
co-authors
Bobby.
Oh
my,
oh,
no
and
Michael
Smith
I
recognized
the
lack
of
urgency
on
vehicle
and
GPE
instead
portion
F,
but
as
mentioned
it's
still
in
use,
and
we
are
actively
trying
to
add
up
just
a
little
bit
to
it.
I
would
appreciate
if
you
could
take
a
very
brief
look
at
this
five
page.
Long
draft,
provide
any
comments
about
the
approach
towards
it
and
provide
feedback
on
this.
Q
The
basics
of
it
is
it's
just
carrying
a
group
based
policy
and
using
GP
e
to
carry
it
so
that
we
can
carry
it
along
with
other
simultaneous
subheaders
such
as
IO
am.
This
is
an
example
usage
of
it.
You
notice
it's
a
extremely
short
little
header,
not
much
to
it
and
for
those
that
might
be
familiar
with
draft
Smith.
The
excellent
group
policy
that
extends
VX
LAN-
and
this
is
different
in
that
it
would
expand
the
Excel
and
GCE
the
status
of
the
internet
draft
is.
This
is
the
very
initial
proposal.