►
From YouTube: IETF102-NVO3-20180718-1330
Description
NVO3 meeting session at IETF102
2018/07/18 1330
https://datatracker.ietf.org/meeting/102/proceedings/
A
B
B
My
name
is
Mathew
Bochy
Sam
I
have
a
coach
I,
couldn't
make
it
to
this
meeting,
so
I
try
and
do
this
on
my
own.
So
please
go
easy
on
me.
We
also
have
a
new
secretary
issue,
who's
going
to
help
and
take
the
minutes.
So
thank
you
very
much
here
is
the
notes.
Well,
I
will
leave
it
up
for
a
few
seconds.
If
you
could,
sir,
it's
please.
B
B
B
B
B
Okay,
I'll
send
these
to
the
list.
So
if
you
could
take
a
look
at
those-
and
let
me
know
if
you
have
any
any
comments
and
then
we'll
get
them
updated
on
on
the
Charter,
so
working
group
document
status.
So
we
have
quite
a
few
rfcs
and
we
have
one
new
RFC
since
the
last
ITF,
our
c83
94,
which
was
the
split
NVA
control
plan
requirements.
B
A
few
notes
on
some
of
our
working
group
documents
for
the
data
plane.
Encapsulation,
we
have
a
new
version
of
draft
genève.
This
is
on
the
agenda.
There's
been
some
discussion
less.
The
discussion
on
this
recently
has
been
around
the
security
section
and
that's
going
to
be
discussed
during
the
session
today.
We
would
like
to
really
push
this
for
working
with
last
call
after
this
ITF
I
dearly.
B
B
We
have
a
couple
of
ongoing
working
group
adoption
polls
so
after
the
London
IETF,
we
started
a
poll
on
the
Geneva
security
requirements
and
I
was
quite
a
lot
of
discussion
around
that
and
that's
on
the
agenda
today,
but
as
it
stood.
We
think
that
there
wasn't
sufficient
consensus
on
the
content
of
the
document
to
adopt
it.
So
hopefully,
with
the
latest
revisions
that
Daniels
going
to
talk
about,
we
will
be
able
to
run
another
adoption
poll
for
that.
B
B
B
A
A
B
A
B
C
This
Paul
Condon
yeah,
the
I
Triple
E
plenary
meeting,
is
immediately
following
the
IETF
meeting
in
Bangkok
at
the
same
hotel,
and
so
we
wanted
to
try
to
take
advantage
of
that
opportunity
to
see
if
we
could
get
together
some
of
the
thought
leaders
around
data
center
technologies,
the
I
Triple
E
just
recently
approved
a
project
around
congestion
management
and
it's
intended
to
work
in
in
early.
It
work
with
higher
layer,
congestion
management
in
the
IETF
as
well.
So
we
think
that
there
would
be
some
fruitful
discussions
in
that
area.
C
There's
also
some
strong
interest
in
the
I
Triple
E,
where,
of
course,
all
the
switch
vendors
are
and
ASIC
vendors
around
how
we,
how
we
interconnect
other
data
center
technologies,
such
as
the
overlay
networks,
as
well,
so
the
interplay
between
layer,
2
and
layer
3,
and
would
be
a
great
opportunity
to
have
such
discussions
again,
a
congestion
being
one
of
the
interesting
areas.
A
lot
of
the
new
proposals
here
in
the
IETF
are
using
option
fields
in
the
TCP
header
which
would
be
inside
the
encapsulation.
C
So
it's
not
clear
how
the
fabric
switches
themselves
would
be
able
to
see-
or
do
anything
about
that.
So
that
would
be
interesting
to
know
how
we
can
communicate
indications
of
congestion
and
things
like
this
to
the
edges
of
the
network
as
well,
in
order
to
take
appropriate
action.
So
the
proposal
is
that
this
would
take
place
on
a
Saturday
immediately
after
the
ietf,
the
I
Triple
E
has
indicated
they
have
room
space
available.
B
C
B
D
B
C
B
E
E
So
a
typical
example
is
that
well,
if
well,
we
mentioned
very
clearly
that
we
have
to
reuse
whenever
possible,
IPSec,
DTLS
and
so
on,
and
it's
true
that
details
provide
encryption,
authentication
and
anti
replay
mechanisms,
but
for
the
wool
packet.
So
then-
and
this
is
also
something
that
has
been
raised
in
the
former
security
requirement
document
for
nb3-
if
the
tenants
are
sending
IPSec
packets,
it
was
mentioned
as
yeah.
E
You
should
not
consider
that
as
protected,
because
the
tenants
are
using
IPSec,
but
on
the
other
hand
you
might
be
willing
only
to
protect
the
the
header
of
the
idea
of
the
packet
exchange
between
the
tenants
to
an
end
security,
in
which
case
you
don't
encrypt
the
whole
packet,
but
you
just
encrypt
a
fraction
of
this,
so
we
had
some
discussions
Rigas
regarding
is
it?
Is
it
an
optimization
or
should
it
be
a
requirement
because
at
the
end?
E
Okay,
if
you
encrypt
everything
you
achieve
this
partial
encryptions,
but
maybe
the
necessary
result
is
going
to
be
gonna
prevent
the
the
security
deployment
of
G&M.
E
E
F
Good
so
I
have
comments,
I
mean
I,
think
we
have
had.
You
know
extensive
discussions
with
the
security
requirements.
Authors,
but
I
just
wanted
to
point
out
that
you
know
the
transit
nodes
was
as
an
important
point
where
the
security
requirement
document
made
certain
assumptions
that
is
not
supported
by
any
architecture,
and
there
are
several
requirements
that
are
associated
with
this,
and
then
we
have
given
detailed
feedback
to
them,
saying
that
these
are
unsupported
once
and
we
shouldn't
have
those
requirements
and
that's
number
one.
F
The
second
one
is
regarding
the
optimization
versus
requirement,
so
so
I
think
I
think
Daniel.
You
know
discuss
that
one
as
well,
so
there
are
two
things:
one
is
multiple
flows.
We
don't
believe
that
you
know
multiple
flows
is
more
of
a
nice-to-have
and
is
an
optimization
and-
and
it
is
not
an
absolute
requirement
to
secure
the
communication
between
the
two
nve
pairs.
That's
that's
one
point
and
the
second
one
is
on
whether
the
tenant
can
can
encrypt
the
data
or
whether
the
tenant,
encrypts,
the
data
or
not.
F
If
an
operator
deems
necessary
that
the
communication
between
the
NV
pairs
needs
to
be
encrypted
and
they
will
encrypt
it,
that
is,
irrespective
of
you
know
what
happens
here
with
the
payload,
and
so
we
believe
that
that's
also
an
optimization
and
not
a
requirement.
So
these
we
have
submitted
detailed,
detailed
comments
to
the
authors
of
the
requirements.
Tab
and
that's
not
been
addressed
in
the
current
version,
that's
been
released,
and
so
with
that
my
opinion
is,
it
is
still
not
ready
for
adoption.
F
E
Well,
we're
working
on
on
the
new
version,
but
if
we'd
be
good
to
figure
out
that
the
assumption
we
had
before
we're
really
bad.
So
it's
it's
it's
more
to
to
see
the
direction
where
we
have
to
go
and
to
me
optimization
can
be
discussed.
Oliver
multiplex,
saying
it's
gonna
be
a
shoot
instead
of
mass.
So
that's
not
a
big
thing:
the
transit!
No,
the
issue
is
seems
to
me
more
drastic
regarding
the
because,
as
Allegro
mentioned,
a
lot
of
the
requirements
were
coming
from
these
transit
nodes.
E
G
B
F
F
So
we
will
talk
about
that
and
the
other
important
point
about
the
security
considerations
section.
So
we
had
made
changes
or
added
content
to
the
security
consideration
section
for
the
BCP
72
guidelines
and
so
I'll
talk
about
that
one
as
well,
and
we
also
made
some
updates
to
the
option
class
assignment
table.
F
There
were
two
organization
that
requested
for
option
class
assignment,
and
then
we
have
made
that
and
I
won't
be
make
you
know
having
any
discussion
on
this
point,
because
it's
it's
more,
it's
more
obvious
from
the
updated
draft
itself
as
to
the
the
companies
that
has
requested
for
additional
option
class
assignments,
so
the
one
of
them
is
actually
Amazon
and
the
second
organization
is
actually
Cisco.
So
those
two
option
codes
are
there
and
we
have
been
assigning
it
on
a
first-come,
first-served
basis
and
eventually
we
will
when
this
goes
through
the
iest
review.
F
So
let's
move
on
to
the
next
slide.
So
this
is
the
clarification
on
the
role
of
transit
devices,
so
per
genève
architecture.
The
transit
devices
do
not,
you
know,
originate
or
terminate
the
journey
packet.
Actually,
that
is
the
responsibility
of
the
endpoints,
and
this
is
also
you
know.
The
end
points
are
the
ones
which
have
the
complete
understanding
of
you
know.
What
is
this
tunnel?
F
And
you
know
what
is
the
you
know,
UDP
port
number
that
we
are
using,
and
all
of
that
association
is
actually
with
the
end
points,
and
it
is
not
with
the
with
the
time
seat
devices.
So
there
were
some
queries
or
I
would
even
call
it
as
some
kind
of
a
misinterpretation
on
the
role
of
transit
devices,
and
that
was
obvious
during
the
discussion
of
the
security
requirements
draft
and
also
some
of
exchanges
that
we
saw
on
the
mailing
list.
F
Regarding
the
IOM,
you
know
our
drafts,
so
hence
we
added
clarifying
statements
so
that
it
is
very
clear
that
what
the
transmitted
devices
can
do
and
and
what
it
cannot
do
so
again
to
to
clarify
that
point.
It
has
non
terminating
devices.
Trans
devices
must
not
insert
or
delete
options,
because
that
is
the
responsibility
of
the
endpoints.
There
are
two
two
other
sub
sub
points
that
is,
transit
devices
may
be
able
to
interpret
the
options,
but
this
is
this
feature
is
also
optional,
and
that
was
also
clear
in
the
top.
F
We
just
made
it
you
know,
or
we
made
it
very
clear
that
you
know
the
options
ordering
or
our
options
cannot
be
changed
by
the
transit
devices.
So
so,
basically
we
don't
want.
You
know
the
transit
devices
to
be
going
and
updating
it,
but
it
may
be
able
to
interpret
the
options
again.
This
is
not
very
new
because
any
of
the
you
know
if
you
look
at
UDP
datagrams
that
are
being
exchanged
between
two
endpoints.
It
is
the
same
thing.
F
Example
there
could
be
transit
devices
that
may
decide
may
be
able
to
interpret
it,
but
there
may
be
cases
where
it
may
not
be
able
to
interpret
it.
But
you
know
it
is.
It
is
basically
the
understanding
is
the
endpoints
or
the
one
that
establishes
the
connection
and
then
and
then
maintains
it,
and
and
also
you
would
like
to
state
that
there
was
a
note.
F
You
know
that
transit
devices
must
not
attempt
to
interpret
or
process
geneva
way
in
packets
and
there
are
no
changes
to
the
draft
I'm
just
reiterating
it
in
his
here
in
this
slide,
so
that
you
know
all
the
members
are.
The
members
are
aware
of
aware
of
it
and
that's
that's
about
the
transit
devices,
so
there
was
also
an
exchange
I
believe
there
was
an
exchange,
I
think
Tom
her,
but
in
you
know,
on
greg
Mirsky.
F
Actually
they
were,
they
were
having
some
exchange
on
the
mailing
list,
and
in
in
that
you
know,
it
was
also
clarified
about
the
same
point
that
you
know
you
will
not
be
able
to
update
the
options
and
in
which
case,
if
you
have
to
use
om
packets,
then
it
has
to
be.
You
know,
based
on
endpoint,
to
endpoint
kind
of
an
options
that
that's
what
you
do.
You
will
have
to
use:
okay,
okay,.
H
So
the
one
before
last
bullet
says
options
or
the
ordering
must
not
be
changed
by
transient
devices.
So
actually
the
sentence
says
two
different
things,
so
first
of
all,
I
would
suggest
to
to
split
it
into
swing
two
sentences,
one
talks
about
the
ordering
and
one
talks
about
changing
or
not
changing
the
option.
H
F
So
if
you
are
able
to
go
and
modify
it
as
I
said
right,
the
Datagram
has
the
meaning
only
at
the
endpoints,
and
you
know,
even
if
you
look
at
RFC
7605,
that
makes
it
very
clear
that
you
know
the
port
numbers
association
is
also
established
by
the
endpoints.
So,
even
though
the
you
know,
the
transit
devices
may
be
able
to
interpret
that
doesn't
guarantee
any
security
that
doesn't
guarantee
that
the
association
will
always
be
on
this
port
number.
So
it's
the
same
thing
with
Jenny
vessel.
F
F
It's
like
this,
like
you,
are
establishing
a
tunnel
between
a
end
point
to
the
end
point
and
end
points
are
the
ones
that
are
establishing
the
tunnels
and
maintaining
it,
and
you
don't
want
the
contents
of
that
tunnel
to
be
modified
by
the
you
know
intermediate
devices,
and
that
was
not
an
intent
of
genève
architecture,
and
we
just
wanted
to
make
it
clear
that
that
is
the
case.
So
just.
H
F
E
F
Okay,
next
to
the
security
considerations
section,
so
we
made
we
received
a
feedback
from
the
recently
completed
RFC.
This
is
the
NS
h
at
the
RFC
8300.
During
that
review
process,
it
was
brought
to
the
attention
that,
in
a
security,
consideration
section
should
be
updated
for
the
BCP
72
guidelines,
and
there
was
also
a
comment
by
Paul
Quinn
on
the
mailing
list
in
VO
three
mailings
mailing
list
as
well.
So
so
what
we
did
is
we
added?
F
You
know
additional
content
so
that
we
can
highlight
the
potential
security
risk
that
may
be
applicable
to
genève
deployments
and
also
the
approaches
to
mitigate
such
risks,
and
that
includes
you
know,
data
confidentiality.
You
know
that
is
between
the
NVE
pairs
and
also
you
know
the
data
integrity
to
be
protected,
to
ensure
that
you
know
the
data
and
also
aren't
so
they
ensure
that
the
NV
pair
is
actually
receiving
data
from
an
Envy
that
it
is
supposed
to
receive
from
so
the
authentication
of
the
NV
as
well.
F
So
all
we
have
added
additional
information
in
there
to
that
is
clear
in
the
draft
to
indicate
you
know
what
are
those
risk
scenarios
and
how
to
mitigate
those
risks,
and
also
we
added
some
additional
information
regarding
how
to
handle
the
broadcast
and
multicast
and
also
the
control
plane
communication.
Some
of
this
would
be
within
the
scope
of
of
this
data,
and
some
of
this
may
not
be
within
the
scope
of
the
trap,
because
the
control
plane
communications,
for
example,
needs
to
be
handled
by
you
know
it's
not.
F
This
is
a
data
plane
draft
and
but
then
we
still
pointed
to
that
that
it
needs
to
be
handled.
You
know
elsewhere
and
then,
let's
move
on
to
the
next
slide
before
we
take
questions.
If
we
have
one
more
slide
on
on
the
security
consultation,
section
yeah,
so
this
was
you
know
the
the
comment
raised
by
Tao
on
on
on
the
mailing
list.
So
not
all
the
risks
are
outlined
as
applicable
to
all
the
deployments.
That
is.
That
is
very
true,
and
that's
exactly
you
know
what
we
try
to
communicate
in
the
tap.
F
So,
for
example,
there
could
be
risk
that
may
be
only
applicable
to
say
public
cloud
or
multi-tenant
kind
of
our
deployments,
and
there
could
be
other.
You
know
risks
that
you
know
those
risks
may
not
be
applicable
to
say,
for
example,
a
private
data
center
kind
of
deployment,
and
only
the
data
center
operator
will
be
able
to
assess
this
risk
as
it
is
applicable
to
their
you
know,
deployment,
and
so
they
will
be
able
to
go
and
mitigate
those
risks
accordingly.
So
what
we?
F
It
said
that
you
know
the
certain
requirements.
May
not
be
applicable
to
all
operators,
and
it
is
possible
to
you
know
so,
so
what
we
are
saying
is
like,
if
it's
possible,
to
add
qualifying
statement
to
qualify.
You
know
clarify
that.
Not
all
the
comments
are
applicable
to
all
the
situation.
That
is
very
clear
right.
F
We
can
have
a
qualifying
statement,
show
that
there
is
no
missile
big
booty
here,
so
that
an
operator
should
actually
do
the
threat
assessment
and
based
on
that,
they
need
to
enable
the
protection
that
is
applicable
to
tear
a
specific
deployment,
and
that's
it's
possible
for
us
to.
You
know,
make
that
clarifying
statement
so
that
there
is
no
ambiguity
that
you
know
it.
You
need
to
apply
a
certain
requirement
to
all
situations
and
yeah,
but
these
were
these
were
the
in
updates
that
we
made
to
the
made
to
the
draft
so.
H
But
how
does
slide
5
work
with
the
fact
that
the
confidentiality
integrity
and
authentication
are
must
requirements,
I
mean
if
we
need
on
a
persistent
basis,
we
need
to
do
a
threat
analysis
based
on
that
threat
analysis.
We
need
to
decide
which
requirements
are
applicable
and
which
ones
are
not.
Why
are
we
requiring
as
a
must
to
implement
confidentiality,
integrity
and
authentication.
F
Okay,
it's
a
must
in
that
particular
scenario
right.
It
is
not
a
must
all
the
time.
So
if
that
condition,
for
example,
let's
say
in
a
multi-tenancy
data
center,
the
requirement
is
to
protect
the
data
between
the
two
NV
pairs
and
that's
a
requirement,
and
in
that
case
the
data
center
operator
must
enable
it
in
order
to
protect
the
data
right.
We
can't
you
know
we,
you
know,
we
can't
be.
F
You
know
not
saying
what
the
requirements
are,
so
that
is,
that
is
what
is
there
if
you
go
and
read
through
the
BCP
72
guideline,
it
is
very
clear,
then,
that
you
know
we
need
to
identify
the
threat
and
also
we
need
to
clearly
specify
you
know,
watch
what
is
the
must?
What
is
you
should?
Or
you
know
what
is
a
must
not
that
needs
to
be
very
clearly
explained,
and
if
you
go
back
to
look
at
RFC
8300,
you
know
that
was
the
recently
went
through
this
process.
F
H
F
We
can
add
qualifying
statement,
that's
what
I
said
right
in
the
in
the
next
page,
it's
possible
to
add
qualifying
statement
to
make
sure
that
it
is
applicable
only
in
in
such
scenario
provided
I.
The
operator
has
done
there
is,
you
know
the
risk
assessment
and
based
on
that,
you
know
they
intend
to
enable
it
so
I.
H
Would
really
suggest
you
I
think
we
have
to
rephrase
it
because
right
now
it
says
something
which
is
very
difficult
to
follow.
I
think
if
we're
saying
you
must
implement
confidentiality
and
we're
not
defining
an
encryption
algorithm
we're
not
defining
a
protocol.
First
of
all,
no
one
when
will
implement
it.
Second
of
all,
there
is
no
way
to
interoperate,
so
it
won't
work.
So
I
would
suggest
to
be
very
careful
about
using.
F
Or
talat
I
think
we
still
have
to
include
the
mistake
statements
in
there,
because
we
need
to
clear
clearly
specify
that,
but
you
can
also
refer
back
to
the
you
know.
The
recently
completed
RFC
process
and
I
also,
you
know
I
also
monitored
some
of
the
exchanges
that
went
through
during
that
you
know
draft
review
process,
so
we
will
have
to
clearly
specify
the
risk
and
we'll
also
clearly
specify
what
the
require
those
requirements
are.
F
B
B
H
The
way
we
read
the
text
right
now,
it
says
as
an
instruction
to
the
implementer.
You
must
implement
these
things
and
as
an
implementer
I'm
reading
this
and
I'm
saying
I
can't
comply
to
Geneva,
because
I
can't
implement
confidentiality.
I,
don't
know
what
to
implement.
So
we
can't
leave
it
like
this
yeah.
B
One
other
way
there
are
other
ways
to
phrase
it
that
that
are
perhaps
less
prescriptive,
but
but
satisfy
satisfied
that
the
kind
of
purpose
of
the
security
considerations
section,
so
you
can
I
mean
I.
You
know
this
is
just
from
my
person,
speaking
as
a
co-author
of
other
RFC
s,
where
we've
had
to
do
this,
you
just
have
to
you.
You
have
to
start
it's
kind
of
state
what
the
threat
is
and
then
say,
and
these
and
there
are
mechanisms
available
to
enlist
some
mechanisms
to
mitigate
against
that
threat.
So.
H
Just
as
a
suggestion,
what
we
did,
for
example,
in
the
tic-tock,
we
had
security
requirements.
So
what
we
did
was
we
define
the
security
requirements
for
a
security
mechanism
that
is,
if
you're
implementing
a
security
mechanism
in
a
system
that
requires
this
mechanism
based
on
threat
analysis.
These
are
the
requirements
some
of
them,
or
must
some
of
them
are
should
and
so
on,
but
that's
if
you're
implementing
the
mechanism,
so
it's
not
a
must
to
the
implementer
it's
a
must
to
whoever
is
using
or
deploying
security
mechanism.
F
B
So
somehow
we
have
to
obviously
come
to
a
compromise
here
as
to
what
makes
sense
for
a
protocol
spec
while
having
sufficient
text
in
there
to
also
guide
the
fact
that,
if
you,
if
you
need
to
meet
these
requirements
in
certain
deployments,
obviously
there
must
be
a
protocol
or
there
must.
The
implementer
must
have
implemented
these
other
mechanisms.
F
B
Well,
I
I
would
have
been
trying
to
rephrase
it
in
a
way
that
makes
sense
for
an
implementer.
First
of
all,
it
sounds
like
we
don't
yet
have
consensus
or
we
don't
have
consensus
on
the
current
text
and
there.
So
let's
get
some
consensus
in
this
working
group
first
and
then
send
it.
Send
it
for
wider
review.
B
E
One
thing
could
be
to
mention:
I
mean
to
existing
things
and
what
is
missing
somehow
and
yeah
it
doesn't
have
to
secure.
You
know
all
santoor
have
fulfill
all
the
security
requirements,
but
we
have
to
understand
both
what
he's
doing
the
limits
and
basically
position
Geneva
regarding
the
security
and
the
security
requirement.
Rush
should
clarify
that
this
is
my
expectation
yeah.
B
For
this
this
section
try
and
get
consensus
on
on
the
mvo
three
list.
First
of
all,
so
in
the
next
couple
of
weeks
it's
only
a
couple
of
sentences,
I
think
so,
and
then
we
will
no
revise
the
draft
and
we'll
go
for
I.
Think
I
proposed
actually
that
we
go
for
a
security
area
review
first
and
then
we
don't
be
working
group
last
call
based
on
any
any
feedback
from
that.
So
we
definitely
I
definitely
like
to
get
a
working
group
get
this
sent
to
Martin
before
Bangkok.
B
H
H
H
H
So
the
way
alternate
marking
works
in
RFC
8321
is
that
you
use
a
marking
bit
in
the
header
of
the
data
packets
and
this
marking
bit
its
value
changes
periodically
like
a
wave
function
and
it
kind
of
splits
the
data
traffic
into
consecutive
blocks
of
data,
and
this
allows
the
measurement
points
to
count
the
traffic
consistently,
which
allows
you
to
compute
the
packet
loss.
That's
in
a
nutshell,
without
going
into
details.
H
So
this
is
the
marking
bit.
It's
also
called
the
color
bit
now.
The
double
marking
method
uses
2
bits,
and
the
idea
is
that
one
bit
is
used
as
a
color
bit.
It's
used
for
loss
measurement
and
the
second
bit
is
used
for
delay
measurement,
and
the
idea
in
the
delay
bit
is
that,
most
of
the
time
it's
zero
and
then
once
per
period,
its
value
is
reversed
and
that's
specific
in
which
the
value
is
reversed
is
used
as
a
reference
for
delay
measurement.
H
Okay,
it's
time-stamped
by
both
measurement
points
and
that
one
is
used
for
delay
measurement.
So
this
is
double
marking
it
require
requires
two
bits:
multiplex
marking,
basically
multiplexes
the
two
bits
onto
a
single
bit,
so
that
single
bit
is
actually
the
result
of
the
exclusive-or
between
the
Elbit
and
the
D
bit.
So
what
we
get
is
we
get
the
same
functionality
as
the
double
marking,
the
same
measurement
accuracy,
the
same
measurement
resolution
using
just
a
single
bit
in
the
header.
H
H
One
of
the
comments
that
was
made
on
the
mailing
list
is
that
in
some
cases
maybe
two
bits
is
too
much,
and
so
it's
up
for
discussion,
but
if
we
end
up
deciding
that
we
can
only
allocate
one
bit,
that
means
we
will
still
be
able
to
support
single
marking
or
multiplex
marking.
Okay,
so
again,
it's
up
for
discussion.
H
E
E
H
E
F
B
F
Question
so
if
that
is
the
case,
then
why
won't
they
use
the
options
in
order
to
do
this,
because
that
that
was
the
intent
of
having
extensibility
engineer
rather
than
using
the
base
header,
because
you
can
have
the
option
to
indicate
this
information
and
you're
not
limited
by
in
the
number
of
bits.
You
know
you
have.
You
know
a
lot
more
space
in
order
to
do
in
order
to
in
or
provide
metadata
between
the
NVE
right.
H
You
can
use
the
options,
but
the
idea
is
that,
since
this
this
approach
only
requires
a
single
bit
or
two
bits
very
small
number
of
bits.
It's
a
bit
of
a
waste
to
use
an
option
for
this.
If
we
can
spare
a
bit
for
or
to
for
this
in
the
Geneva
header,
we
can
just
be
more
efficient
and
and
still
get
that
functionality
I.
F
Mean
I
believe
that
this
is
exactly
the
reason
why
we
have
extensibility
and
also
not
all
the
deployments
will
need
this.
So
so
it
will
be
better
to
have
an
option,
and
then
you
know
and
then
how
you
are
not
limited
by
you
know
one
or
two
bits.
If
you
want
one
or
two
bit,
that's
fine,
but
if
you
want
to
use
you
know
more,
that's
that
that
allows
you
know,
use
the
extensibility
feature
of
genève
in
order
to
do
this.
So
that's
that's
my
opinion.
F
D
So,
strictly
speaking,
there
is
no
consumption
of
the
marking
field
and
I
probably
have
a
different
opinion
from
toss
that
effectively
the
test
point
that
acts
on
the
value
of
the
marking
field
can
be
anywhere
in
the
tunnel.
It's
not
necessarily
and
the
edge
in
V,
ok
and
the
benefit
of
using
fixed
position
of
the
marking
field
field.
Is
that
simplification
of
the
operation
of
the
test
point
because
then
it
makes
its
well-known
position
in
a
packet
rather
than
you
need
to
parse
their
verbal
length
portion
of
the
header
to
identify
where
the
field
is.
D
No,
it's
not
the
question
to
tell
it's
basically
my
answer
to
your
suggestion
to
use
a
variable-length
extensible
part
of
the
header
for
the
marketing
field,
because
that
will
make
it
hardware
support
of
it
less
efficient.
Again.
I
want
to
point
that
this
method
is
even
though
it's
this
classified
as
a
hybrid
method,
similar
to
other
hybrid
methods.
D
F
Mean
I
still
believe
that
you
know
you
can
use
the
options
for
this
purpose
and
because
most
of
the
Geneva
endpoints
that
are
that
are
implementing
will
also
be
able
to
implement.
Options
is
not
just
the
one
and
the
efficiency
is
not
an
issue,
so
so
I
don't
believe
that
efficiency
is
an
issue
whether
you,
whether
you're
interpreting
an
option
or
whether
interpreting
bits
in
an
option.
Okay,
yes,.
D
I
agree
with
you:
everything
can
be
done
differently.
There
is
not
one
way
to
slice
the
bread,
but
in
terms
of
performance,
monitoring
being
able
to
identify
the
packet
as
close
as
possible
when
it's
being
received,
it's
almost
critical,
because
if,
for
example,
the
time
stamp
is
not
taken
during
the
reception,
the
physical
reception
of
the
packet,
then
you
are
measuring
something
else.
D
B
Greg
I
think
it's
Matthew
here,
I
think
I
had
similar
similar
comment.
If
you're
adding
options
in
a
in
a
performance
monitoring,
you
know
so
you're
making
the
packets
bigger
european
packets,
bigger.
You
know
you
don't
want
that.
The
the
fact
that
you've
added
added
these
additional
option,
fields
or
headers
to
to
impact
your
OEM
measurements,
which
are
supposed
to
represent
the
the
user
traffic
behavior.
D
Well
again,
the
alternate
marking
method
works
on
the
user
traffic
and
the
idea
of
using
pre-allocated
filled
in
a
fixed
size,
header
or
at
least
big
sized
portion
of
the
header,
makes
it
almost
as
tacit
measurement,
because
there
is
no
increase
in
the
size.
As
thou
pointed
out,
the
size
of
the
flag
is
so
small,
so
adding
option
will
be
significant
overhead
to
the
actual
size
of
their
marking
field,
but.
D
D
The
question
I
had
is
when
looking
at
in
having
discussions
in
groups
that
work
on
overlay
encapsulations,
is
that
how
we
achieve
unambiguous
identification
of
om
and
om
has
a
three
different
methods.
So
it's
an
active
William,
hybrid,
OM
and
passively
passive
om
is
always
out
of
Bend
and
it's
monitoring
or
sending
out
some
data,
and
it's
not
in
scope
of
this
analysis,
an
active
M,
it's
characterized
as
a
method
that
uses
specifically
constructed
test
packets
and
what
we
achieved
with
these
methods
is
the
fault,
management
and
performance
monitoring.
D
It's
an
F
and
B
of
F
Cox
network
management
paradigm.
This
methods
could
be
single,
ended
or
dual
ended.
So
the
single
ended
example
would
be
echo
request.
Reply
like
ping
dual
ended:
it's
example:
B
of
D
in
a
synchronous
mode.
When
two
ends
are
independently
set
theoretic
text.
It
could
be
a
two
ways
or
one
way,
the
two
ways
again.
D
It's
an
echo
request,
reply
in
one
way:
it's
BFD
in
the
man
mode
when
only
one
endpoint
transmits
packets,
then
we
have
a
hybrid
Orion
in
I
TPM
working
group
where
we
discuss
different
performance
monitoring
methods,
performance
measurement,
the
hybrid
OM
was
defined
as
a
method
that
combines
characteristics
of
active
om
and
passive
area,
and
their
weight
of
each
method
that
contributes
to
the
hybrid
OM
could
be
different.
So
examples
are
hybrid.
Om
could
be
that
I
want
to
discuss
just
earlier.
D
Its
alternate
marking
method
that
triggers
measurement
in
situ
om
is
another
example
that
triggers
measurement
and,
at
the
same
time
collects
and
transport
the
measurement
results
or
network
state
information.
What
we
use
sometimes
refer
as
a
telemetry
information
in
the
database.
Another
example
is
the
hybrid
2
step.
It's
a
method
that
collects
and
transports
their
telemetry
information,
I.
D
Think
that
overlay
network
protocols
can
be
character,
separated
in
two
categories:
encapsulations
that
support
optional
metadata.
So
thus
it's
variable
size,
size,
headers,
and
that
includes
a
Geneva
as
FC
Anna
sage,
gooey
and
encapsulations-
that
use
fixed
size
headers.
So
they
don't
in
support
optional
metadata,
and
these
examples
are
beer
and
VX
1
GP.
D
D
So
thus
there
seems
to
be
a
contradiction
in
GUI.
The
OEM
packet
is
not
defined
and
there
is
no
mention,
but
the
mechanism
that
they
suggest
is
to
use
C
bit,
which
changes
their
interpretation
of
command
protocol
field.
And
if
the
bits
said,
then
it
means
that
there
is
a
control
information
and
in
this
namespace
om
can
be
defined
as
a
product
as
a
command
type.
D
My
note
to
that
method
would
be
is
that
if
there
is
an
intention
to
separate
slope
at
processing
from
the
first
breast
processing,
so
if
cbiit
said,
then
it
goes
to
the
slope
at
processing
that
some
Orion
methods
are
Hardware
implemented.
So
basically
like
PFD
or
performance
measurement,
precise,
accurate
performance
measurements
methods
and
making
this
differentiation
based
on
fast
path,
slow
path,
whether
to
send
to
control
plane
or
do
the
faster
processing.
It
seems
to
be
not
really
well
aligned
with
how
I
am
or
somewhere
methods
work.
D
D
Om
framework,
which
is
a
working
group
document,
talks
about
again
that
there
is
an
indication
of
om
take
it,
but
it
doesn't
say
what
we
impacted
is
actually
is
recently
adopted.
I
am
in
a
sage
document,
has
a
little
bit
more
about
IOM,
specific
relationship
with
a
bobeat,
and
the
reason
for
that
is
that.
D
D
Adrian
with
the
coffers,
they
have
very
good
observation
and
that
reflected
in
RFC,
okay,
so
I'm,
jumping
fixed-size
headers
so
in
the
beer
is
a
very
simple
beer
allocated
next
protocol
identify
for
OAM
and
it's
registered
in
Ayana,
so
om
attack.
If
that
follows
beer,
heather
identified
through
the
protocol
filled
the
excellent
GP
introduced
obit,
and
it
says
nothing
more
than
says
that
indicate
that
the
packet
is
oriented.
D
Please
note
that
all
the
protocols,
the
excellent
GP
GUI
genève
a
message
they
have
next
protocol
field.
So
let's
we'll
go
to
the
next
slide.
So
the
question
is
that
all
the
many
documents
talk
about
om
peg.
What
is
om
decade
is
a
packet
that,
where
the
OM
commands
and
information
included
as
metadata
in
a
header
or
om
commands
and
information
immediately
follow
the
header.
D
D
So
I
started
talking
about
this
RFC
83-93
earlier,
and
that
was
the
observation
made
by
address
and
coffers
that
next
protocol
nan
was
not
defined
and
next
protocol.
None
means
exactly
that
that
there
is
no
payload
following
the
header
NSA
shredder
in
that
case,
and
then
they
made
the
next
logical
observation.
That
is
the
whole
bit
set,
and
the
next
protocol
value
is
none.
D
D
It
provides
you
with
the
source
identifier,
if
you,
if
I
P,
underlay,
that
natively
provides
a
source
ID,
but
if
it's
non
IP
encapsulation
with
the
MPLS
data
plane,
so
the
source
ID
has
to
be
included
as
a
separate
information
from
there
om
command
and
data.
But
it's
it's
not
very
specific
to
end
your
3.
Ok.
Can
we
go
next.
D
D
B
D
I
B
B
D
Again,
I
try
to
make
my
recommendation
as
least
intrusive
as
possible.
So,
for
example,
we
have
probably
the
most
advanced
would
be
SF
CMS
age
for
an
SF
CMS
age.
Again
we
don't
have
much.
We
haven't
made
much
progress
on
OAM
work
and
framework.
Om
framework
is
still
being
worked
on,
so
my
proposal
will
not
require,
even
though
it's
yes,
it's
possible.
But
again
we
may
redefine
the
interpretation
of
a
bit
in
an
MSH
header
and
we
just
then
define
the
value
for
next
protocol
to
identify
active
who
I
am
so
I.
B
Okay,
so
if
I
could
encourage
folks
in
this
working
group
to
read
the
draft
and
probably
provide
feedback
on
the
routing
area
into
the
routing
area,
working
group
from
an
MBO
three
perspective,
I
think
I
think
that
would
be
the
way
to
do
it.
Okay,
thank
you.
Thank
you.
Thanks,
okay,
thanks!
That's
the
last
last
thought
we
had
blue
sheets.
If
you
have
a
blue
sheet,
could
you
bring
them
to
the
front,
please
and
I
think
that's
the
end
of
the
meeting.
Thank
you.