►
From YouTube: IETF101-NVO3-20180321-1520
Description
NVO3 meeting session at IETF101
2018/03/21 1520
https://datatracker.ietf.org/meeting/101/proceedings/
D
C
C
C
Alright
administrivia,
so
blue
sheets
are
going
around
apologies,
so
a
little
bit
late,
because
we
didn't
have
any
thanks:
Thank
You
Maya
to
invert
again
to
get
some
note
takers,
so
it
Lango
is
going
to
take
the
notes,
but
he
has
to
leave
at
some
Ignace
story.
It's
going
to
say
the
notes,
diversity,
if
you
don't
run
it
shouldn't.
C
C
So
thank
you
very
much
early
I
feel
your
guidance
and
support
and
help
with
getting
some
really
good
results
from
that.
The
working
group
in
your
encouragement
to
the
working
group,
so
thank
you
and
so
Martin
Figueroa,
is
now
taking
over
as
our
a
new
ad.
So
you
want
to
stand
up
so
welcome
Martin
and
good
luck.
C
C
We
will
be
looking
for
a
new
secretary
because
we
find
a
working
group
secretary
is
very,
very
useful.
So
if
you,
if
you're
interested
in
this
prestigious
role,
please
do
come
and
see
the
chairs
afterwards
or
drop
us
an
email.
We
would
very
much
appreciate
some
extra
help
with
running
the
working
group.
If
you
want
to
find
out
what
being
a
secretary
is
all
about,
there's
some
information
here
and
obviously
2418
and
there's
also
a
draft
which
I
think
is
expired
now.
But
there
was
a
draft
written
on
how
to
be
a
good
secretary.
C
Agenda.
Ok,
so
here
is
the
agenda.
A
lot
of
the
the
time
on
the
agenda
is
taken
up
in
sorting
out
some
of
the
issues
around
security
in
and
security
requirements
for
draft
genève.
So
go
big
slots
for
that.
That's
after
our
status
update
and
then
Greg
is
going
to
talk
a
bit
again
about
the
the
overlay
OEM
header,
which
was
one
of
the
outputs
of
the
routing
area.
Are
we
on
design
team?
C
C
C
C
But
we
would
very
much
appreciate
if
you
could
take
a
look
at
that
liaison
and
if
you're
interested-
and
you
want
to
review
the
PDP
document
from
the
I
Triple
E
come
and
see
us,
and
we
can
give
you
the
password
for
apps
at
the
URL
and
password
for
access
to
that
at
the
from
the
I
Triple
E
server
data
plain
encapsulation.
So
we
would
ideally
that's
draft
and
Eve
the
standards
track
one.
C
We
would
like
to
ideally
last
call
this
after
this
I
ETA
F
and
along
with
that
last
call
the
NV
o
three
and
Capo
draft,
which
was
the
output
of
the
design
team
that
shows
draft
Junaid,
either
at
the
same
time
or
straight
after
the
last
call
for
draft
Junaid.
It
is
somewhat
dependent
draft
Geneva
on
US
making
adopting
the
genève
security
requirements
document.
C
So
hopefully
we
can
resolve
the
outstanding
issues
with
that
at
this
of
this
meeting,
there
is
an
ongoing
poll
for
adoption
of
that
document,
so,
ideally
we'll
just
treat
those
any
comments,
errors
as
part
of
that
adoption
process,
so
that's
drafter
mg,
LT
and
vo
through
Geneva
security
of
comments.
So
please
take
a
look
at
that
one
and
comment
analyst.
C
E
E
C
F
C
So
that's
the
final
stage
of
balloting
for
the
draft,
so
it's
kind
of
similar
to
last
call
in
the
ITF,
I
suppose
and
I'd
appreciate
feedback
by
the
15th
of
May
this
year
from
n
vo
three
participants
on
this
draft,
and
so
please
see
the
chairs
for
details
of
how
to
access
the
document.
Do
you
want
anything
that.
G
Yeah
so
I'll
be
retiring,
but
we'll
send
a
message
to
the
list
with
the
names
of
the
editors
and
the
you
know,
2.1
task
group
chair:
that's
going
to
be
managing
this,
so
that
people
can
send
their
feedback
to
the
correct
email
addresses
and
we
would
really
appreciate
feedback
before
we
before
we
progress.
The
sponsor
ballot
is
the
final
state,
it's
roughly
equivalent
to
last
call
in
IETF,
so
getting
close
to
done.
C
C
So
I
think
next,
actually
we're
going
to
move
on
to
the
requirements,
security
requirements
document
for
draft
Junaid
and
a
way
that
we're
going
to
run.
This
is
that
Elango
is
going
to
do
a
remote
presentation
of
his
comments
on
the
document,
which
I
think
were
posted
to
the
list
and
then
Danielle
is
going
to
respond
as
editor
of
the
requirements.
Draft
security
of
Comus
draft,
with
an
update
on
the
status
of
that
and
how
he
proposes
to
resolve
those
comments.
So
I
know:
you're
you're
meet
okay,
I
think
I
need
to
push
there.
C
H
So
yeah
I'm
going
to
talk
about
the
you
know
the
comments
on
the
security
requirements.
Draft
and-
and
the
comment
says
you
know-
Matthew
said
that
it's
in
already
posted
to
the
mailing
list.
So
this
is
a
you
know.
I'll
have
a
summary
of
the
comments
that
I
presented.
I
don't
have
to
go
through
each
and
every
comment
in
detail,
but
the
team
of
the
comments
and
the
highlights
of
the
outstanding
issues
and
how
we
are
working
with
the
authors
to
resolve
this
as
we
move
forward
next
slide,
please:
okay,
yeah.
H
The
theme
of
the
comments
is
to
focus
on
the
potential
security
threats
and
in
the
requirements
to
migrate.
Those
tress
I
mean
threats
as
applicable
to
genève
deployments.
The
key
point
is
no.
Genève
can
be
deployed
in
multiple
different
environments.
Example
you
can
in
deploy
in
a
multi-tenancy
environment.
It
could
be
deployed
in
a
private
enterprise
to
provide
isolation
between
you
know,
multiple
departments
and
so
on,
and
it
could
also
be
you
know,
deployed
in
other.
You
know
telecommunications,
environment
as
well
as
for
providing
you
know,
isolation
and
you
know
threats.
H
You
know,
depending
upon
whether
you
are
in
a
multi-tenancy
environment
or
whether
you
are
in
you
know,
private
enterprise,
the
the
perceived
or
the
potential
threats
you
know
could
be
different
and
how
the
the
operator
try
to
resolve
those
threats
could
could
be
different.
The
document
itself,
you
know
the
security
requirement
documents
will
highlight,
you
know
the
different
potential
threats
that
are
possible
in
an
environment
and
then
the
requirements
also
could
be
generic,
but
then
the
user
can
can
choose.
H
So
these
are
some
of
the
outstanding
issues
that
are
being
resolved
I'm.
Currently,
as
we
speak,
so
the
the
number
one
is
actually
data
privacy,
the
data
privacy
can
be
offered
by
a
service
provider
or
a
tenant
could
bring
their
own.
You
know
data
privacy
policies,
the
reason
being
you
know
some
of
the
tenants
like
may
not
trust
the
underlyings.
You
know
service
provider
and
what
they
might
decide
to
do
is
to
bring
their
own.
You
know
policies
in
order
to
do
encryption,
and
this
could
be
done
out
there.
H
You
know
payloads
or
any
payload
that
they
puts
into
the
underlying
network
would
be
you
know
encrypted
even
before
it
reaches
the
network,
virtualization
endpoint,
so
that's
one
one
model.
The
other
model
is
like
the
customers
might
or
the
tenants
might
trust
the
service
provider
to
provide
data
privacy
as
a
service.
H
The
second
one
is,
you
know
some
of
the
stated
requirements
may
not
be
applicable
to
Geneva
transit
devices.
This
is
the
one
thing
that
we
noticed.
You
know
when
we
looked
at
the
Geneva
security
requirements
document.
There
was
some
misinterpretation
on
the
role
of
the
Geneva
transit
devices
and
Andy
and
how
the
transit
devices
plays
in
the
architecture.
So,
typically
these
transit
devices
are,
you
know
it
could
be
forwarding
elements
like
you
know,
switches
or
routers
that
forward.
H
You
know
the
Jenny
trans
genève
packets,
as
part
of
the
underlying
right,
so
so
easy
is
nothing
different
than
you
know:
transport
any
IP,
packets
on
on
the
network,
so
Jenny
was
just
going
to
be
layer,
1
one
layer
above
that,
so
there
are
some.
You
know
we
need
to
reconcile
some
of
the
requirements
in
the
document
to
be
consistent
with
the
Geneva
architecture.
We
have
already
reached
out
to
these
these
security
requirements,
draft
authors
and
we
are
working
to
reconcile
the
differences
and
also
some
of
these
requirements.
H
You
know
like
partial
encryption,
where
you
know
based
upon
that
interpretation.
You
know
those
requirements,
but
written
and
I
think
we
need
to
reconcile
those
ones
as
well.
We
believe
that
the
existing
mechanisms
that
are
already
available
could
be
could
be
used
in
order
to
address
those
threats
are
in
order
to
address
those
confidentiality
or
authentication
requirements.
And
the
next
point
is
the
requirements
related
to
performance.
Optimization.
We
saw
a
certain
you
know.
H
Certain
requirements
were
related
to
performance,
optimization
and
what
we
are
saying
is
now
the
requirements
related
to
performance
optimizations
are
necessarily
not
to
address
any
any
specific
threat,
and
so
which
means
that
those
are
more
of
a
nice
to
have,
and
not
necessarily
our
security
requirement
and
so
example
of
those
one
will
be
like
a
foe
based
Daniel
arity
and
the
other
one
is
like
in
our
partial
encryption.
So
those
are
the
things
that
you
know
we
need
to.
You
know
resolve
that
and
make
sure
that
some
of
these
performance
optimizations
are
not
necessarily.
H
You
know
something
that
is
an
absolute
requirement
in
terms
of
not
addressing
a
security
threat,
and
these
are
something
that
we
are
still
working
with
your
thoughts
on
the
other
one
is,
you
know,
there's
also
another
document
on
nvivo
3
security
requirement.
That
was
generic
security
requirement
that
addresses
control,
plane
security
as
well,
as
you
know,
data
plane
security,
and
that
document
also
has
a
multicast.
H
You
know
requirements
related
to
multicast
use
case,
and
so
what
we
were
saying
is
you
know:
Jenny
is
any
not
any
different
than
that,
and
so
why
not
use
you
know?
Why
do
we
have
to
repeat
that
in
in
this
document?
But
again
we
do
not
know
what
the
status
of
that
in
our
document
and
whether
we
decide
to
you
know
progress
that
or
not
so
there's.
H
Another
point
is
like
if
it
is
not
going
to
be
progressed
as
a
separate
document,
then
in
that
case
we
need
to,
you
know,
make
the
genève
security
requirements
as
self-contained
and
we
might
have
to
bring
in
those
requirement
here
and
the
other
point
we
want
to
say
in
terms
of
multicast
is
you
know
many
of
the
raw
data
center
deployments.
The
underlay
Network
doesn't
support
multi
cast,
for
example,
it
doesn't
support
IP
multicast.
In
such
a
scenario,
you
know
what
what
the
operators
do
is
they
offer.
H
You
know
unicast
tunnels
right,
so
they
use
unicast
tunnels
in
order
to
realize
you
know
multicast
over
these
underlying
network,
so
that's
also
a
possibility
in
such
a
scenario,
you
know
all
the
requirement
that
are
related
to
unicast
all's
I
equally
apply
for
the
multicast.
You
know
need
a
separate
multicast
requirement
and
that
needs
to
be
you
know
clearly,
you
know
separated
separately
documented
and
that's
pretty
much.
H
What
I
have
in
the
summary-
and
we
had
few
other
comments,
but
those
are,
you
know,
being
resolved
and
we
don't
have
any
outstanding
issues
and
so
as
a
next
step.
So
what
we
are
doing
is
we
are
working
with
the
authors
of
you
know
the
Jeni
security
requirements
document
and
then
we
are,
you
know,
trying
to
resolve
those
comments.
So
so,
after
the
meeting
we
have
some
more
work
to
do
and
then
we
will
go
and
address
that
and
and
Daniel
will.
A
Hi
everyone
so
basically
I'm
going
to
provide
the
the
author
view
as
a
response
to
a
longer
feedbags
and
how
we're
going
to
move
to
the
document
for
what
and
how
we
can
address
his
comments.
So
the
requirement
document
got
two
goals.
In
fact,
one
of
the
goal
is
to
list
any
possible
requirements
so
that,
if
you
want
to
design
a
generic
security
mechanism
for
genève,
we
can
address
any
kind
of
situations,
and
this
is
the
downside
is
that
we
came
up
into
some
somehow
complex
requirements.
A
So
the
reason
I'm
saying
it's
partly
addressed
is
that
we
already
provided
some
some
space
to
the
policies
what
you
really
want
to
achieve,
so
we
detailed
if
you
want
to
mitigate
these
kind
of
threats.
These
are
the
requirements
you
will
need
to
address,
but
in
a
generic
way,
I
mean
for
immigrants
so
that
you
can
fit
this.
You
can
address
the
mitigation
in
any
Geneva
deployment,
so
we
need
to
add
a
clarification
and
for
each
requirements
when
the
requirements
apply.
A
So
that's
what
we
really
have
to
work
because
deployments
have
additional
policy.
For
example,
do
you
really
need
to
have
a
power
flow
policies,
or
is
your
deployment
have
some
janay
of
transit
nodes
and
given
those
choice
and
those
architecture,
deployment
scenario,
you
need
to
be
really
sure
and
the
requirements
should
be
explicitly
provided
given
this
input,
so
the
next
iteration
of
the
document
is
going
to
be
specifying
for
each
requirements.
A
What
are
the
conditions
so
in
a
way
so
that
you
can
read
the
document
saying
I
have
this
deployment
which
or
the
condition
I'll
meet
and
in
this
case
yeah?
What
are
the
requirement
that
should
fulfill
to
use?
That
document
to
say
my
deployment
is
use
is
following
the
recommendation
of
RFC
yeah.
We
still
hope
it's
gonna
be
an
RFC.
A
One
point
I'd
like
to
mention
is
that
there
is
an
already
in
a
document
about
nvo
three
security
requirements
and
the
current
document
is
listing
a
list
of
security
requirements,
but
because
the
additions
are
integrated
into
the
requirements,
it's
always.
It's
often
ends
up
in
a
may
with
the
new.
Well,
how
we're
going
to
write
the
RFC,
we're
going
to
provide
the
conditions
and
given
the
conditions
may
might
become
a
mess?
It's
not
inconsistency.
It's
just
a
way
we
write.
So
this
is.
This
is
something
we
would
like
you
to
understand.
A
That's
a
fair
way
to
do,
and
it's
just
to
prevent
that
we
can.
We
will
be
somehow
back
hired
saying
there
are
you
can
set
in
inconsistency
between
the
two
during
dr.
grant?
Yes,
it's
because
it's
the
way
it
is
written
in
that
in
the
previous
document,
I
mean
the
entry
of
trade
security
requirements.
You
will
have
the
condition
expressed
above
or
below
the
requirement
and
then
the
requirement
express
that
with
an
a
because
the
conditions
are
not
always
applied.
A
In
our
case
the
condition
can
be
clearly
applied
and
then
we
might
end
up
in
another
terminology,
with
the
current
state
of
the
document
we
haven't
found
inconsistency,
so
I
think
where
we
work
almost
independently
and
then
we
match
those
requirements
and
we
found
that
with
overall,
we
agree
so
well.
The
questioner
I
will
have
maybe
is:
do
we
have
to
to
make
this
binding
within
the
document,
or
can
we
leave
this
document
independent
once
questions
so.
C
I'm
sorry
I
just
don't
know
the
points
about
a
relationship
to
the
the
old
NPI
three
security
requirements
document
that
was
that
was
written
quite
some
time
ago
and
the
authors
haven't
been
active
for
a
number
of
years
now
and
that's
been
expired
for
a
number
of
years.
So
I
really
wouldn't
tie
this
document
too
much
to
that
one,
because
it
was
never
really
progressed
beyond
adoption.
I
think
this.
This
one
needs
to
go
forward
independent.
They
have
that
one.
C
A
Right,
okay,
so
so
well,
the
important
message
is
that
we
will
not
specifically
focus
on
the
justification
and
and
rigor
regarding
the
previous
document,
but
there
is
no
major
inconsistency.
We
haven't
found
any
and
well
the
other
thing
we
had
some
cozy
some
question,
but
I
think
it
has
been
answered
is
that
some
of
the
requirements
are
not
specific
to
Geneva.
So
should
we
left
them
into
the
document,
but
since
the
documents
are
not
going
to
be
published,
my
understanding
is
that
we
should
integrate
that
into
the
current
document.
Yeah
yeah.
C
A
We
had
some
conversations
with
that.
You
like,
oh
so
we're
we're
gonna,
clearly
take
in
consideration
the
comments
and
we
admit
it.
Of
course
we
choose
the
to
meet
when
we
were
very,
very
different
time
zones,
but
still
it
happened,
and
we
really
know
understand
how
to
move
next
version
should
be
I
mean
in
my
case,
I
think
it
well.
There
will
be
part
of
the
process,
so
the
next
version
we
gonna
publish
is
going
to
be
integrated
into
conferencing.
So.
F
C
I
think
the
thing
to
do
is
to
probably
to
publish
a
new
individual
document
with
incorporating
them.
I
know
we
do
a
very
quick
table
from
both
of
that
new
one,
because
just
bear
in
mind
an
adoption
poll
is
really
just
saying.
Is
this
roughly
the
work
the
direction
of
working
group
wants
to
go
in?
Is
this
the
document
about
right
for
us,
and
is
this
something
we
want
to
work
on?
It's
not
saying
that
the
document
has
to
be
perfect
by
any
means.
C
I
I
I
I
Or
packet
or
activecollab
packet
can
be
encapsulated
in
the
same
manner
as
they
load
flow
so
that
we
ensure
that
it's
indent
and
then
I
can
draw
useful
conclusion
from
there
are
REM
results
or
status
change,
so
this
is
to
demonstrate
what
and
how
overlay
header
can
be
used.
So
if
the
next
protocol
unfilled
is
zero,
that
will
be
used
for
active,
om
encapsulation,
that
we
have
overlay,
om
control
message
and
obviously
it
so.
This
is
a
test
packet
that
being
injected
and
consumed
in
overlay
the
main.
I
But
if
we
use
next
protocol
field
that
points
to
the
type
of
your
payload,
then
it
will
look
like
this
example
and
their
payload
can
be
data.
So
this
is
more
like
a
hybrid
or
am
case
scenario,
so
insurance.
This
is
idea
behind
their
overlay
header
and
it's
used
in
overlay
networks
for
active
and
hybrid
om.
We
appreciate
your
comments,
suggestions
and
would
like
to
ask
our
working
group
in
chairs.
You
can
see.
There
are
working
group
reduction
to
adaption.
C
By
the
working
group,
I
think
thanks
Greg,
so
just
a
little
bit
of
history
on
this,
we
did
run
a
working
group
adoption
poll
a
while
ago
on
this
document.
At
the
time
we
had
really
very
little
very
few
people
very
few
participants
on
you
know
either
we
had
basically
a
very
few
proposing
the
adoption
and
very
few
opposing
the
adoption
on
the
list.
C
It
was
very
difficult
to
jaja
fellas,
really
energy
in
the
working
group
for
for
going
forward
with
this
approach,
given
the
lack
of
participation
on
the
list
for
that
you
know
for
were
against
it,
which
is
why
we
didn't
didn't
progress
it
at
the
time.
I
think
it
would
be
very
good
to
see
and
get
get.
C
Some
idea
of
people
have
now
read
this
document
and
if
they
think
we
should
go,
go
forward
with
this
approach,
if
you
don't
think
we
should
go
forward
this
approach,
one
of
the
issues
that
we've
got
is
there
haven't
been
any
other
recent
drafts
with
alternative
OEM
approaches,
and
we
do
need
to
start
considering
OEM
in
this
working
group.
So
you
know
we
can't
kind
of
just
sit
there
with
the
only
proposal
and
that's
currently
on
the
table
saying
we
don't
want
to
adopt
it.
If
there's
no
alternative
being
proposed.
J
Frankly,
it's
in
the
same
vein.
What
would
help
the
document
grakkus?
He
would,
if
he
would
add
a
applicability
section.
I
would
state
how
that
particular
adarand
might
be
just
a
couple
of
examples.
How
that
particular
header
would
be
slotted
in
with
say,
genève,
GRE
and
the
likes,
because
what
you
have
from
a
header
perspective
right
now
works
well
with
protocols
that
have
a
next
header
flagged
and
that
ACMA
next
header
pointer
is
8
bits.
J
If
the
next
header
pointer
is
an
either
type
like
16
bits
with
GRE,
it
doesn't
actually
apply
so
I
think
what
might
help
is
really
outlining
and
showing
how
it
fits
in
where
it
fits
and
where
it
does
not
fit
so
that
people
who
attract
it
like
this
solves
my
problem
or
it
doesn't
really
solve
my
problem
and
I.
Think
that
way.
I
think
you
get
more
appeal
to
people
to
care
about
it.
I
J
It
depends
on
where
you
want
to
go
with
this
I
think,
that's
the
question
on
applicability
right.
So,
if
you
have
GRE
then
well,
naturally,
the
next
thing
will
be
something
either
type
and
the
next
protocol
field.
There
would
be
a
16-bit
field,
but
I'm
just
wondering
so
how
does
it
apply?
Where
does
it
apply
and
outlining
that
in
the
document
with
a
couple
of
examples
how
it
fits
into
the
variety
of
overlays
that
we
have
out,
there
would
be
of
great
help.
Yeah.
I
Again,
I'll,
thank
you
for
a
comment
and
a
suggestion.
I
would
definitely
look
at
the
document,
but
our
original
goal
was
that
to
make
it
used
in
new
overlay
encapsulations
as
genève
beer
and
NS
age,
whether
it's
applicable
to
GRE,
is
it
required
to
be
applicable
and
jerry?
That's
something
that
definitely
we
should
discuss
well.
J
L
K
A
little
discussion
about
this
and
thank
you
for
pointing
out
the
draft
I've
read
through
it
now
I'm
just
curious
to
know
it
does
seem
to
be
an
inbound,
OAM
kind
of
method,
except
this
is
just
the
types
of
data
specified
as
the
time
stamp.
Only
I
was
wondering
if
you
could
characterize
me
how
this
is
just
functionally
different
than
the
IOM
working
tonight.
Pdf.
It's
not
quite
understand
I
hit
again
I.
I
Want
to
stress
that
in
bad,
behavior
of
om
is
the
function
of
encapsulation
layer.
Where
draws
they're
forwarding
the
decision.
Okay.
So
if
it
draws
only
from
the
encapsulation
information
not
from
the
payload,
then
any
type
of
om
will
be
in
bed,
whether
it's
hybrid
or
active,
and
that's
why
we
have
special
section
on
requirements
towards
encapsulation
that,
in
order
to
ensure
that
active
OAM
is
in
bed
with
the
data
flow
that
put
certain
restrictions
on
how
their
foreign
decision
should
be
drawn.
K
I
K
C
H
My
my
question
is:
you
know
the
om.
The
proposal
that
you
are
having
the
header
is
applicable
at
different
layers.
It
could
be
at
the
overlay
layer
and
also
it
could
be.
If
you
are
using
it
along
with
nsh,
then
it
is
actually
a
part
of
the
service
overlay
or
you
can
call
it
as
a
service
plane
right,
so
it's
possible
that
both
could
coexist
and
the
document
does
not
necessarily
give
enough
applicability.
You
know
information
are
you
know
how
it
will
be
used
when
you
know,
if
you
need
why
I
am
at
both
levels,.
I
H
Not
necessarily
true
right,
so,
for
example,
if
you
take
an
essay,
Genesis
could
be
transported
on
multiple
different
transports
and,
depending
upon
you
know
what
you
know,
what
is
the
underlay
Network
they
might
pick
certain
encapsulation
and
and
and
it
will
also
go
through
multiple
different
encapsulations
before
it
reaches
the
service
nodes.
So
in
this,
in
this
case,
the
om
as
part
of
the
nsh
header
is
independent
of
the
OEM
in
the
underlay
or
the
or
the
overlay
transport.
That
is
easy,
so
both
could
coexist
as
well
right.
I
I
agree,
but
I
think
that
will
be
interesting
helpful
to
get
some
operational
consideration,
whether
it's
plausible
scenario
and
use
that
one
packet
is
who
I
am
for
Anna
sage
and
underlay
transport.
At
the
same
time,
I
would
think
that
it
creates
some
complexity
for
for
localization
in
troubleshooting,
because
how
to
identify
where
the
fault
happened.
H
M
Our
busy
economy
usually
back
to
Frank's
question
on
applicability.
If
you
really
look
at
NS
H,
so
you
are
going
to
change
the
behavior
of
your
SFC
nodes
on
this,
or
this
is
just
meditator
that
sits
in
band.
That's
transparent.
You
have
a
service
function
under
hand.
Then
you
have
the
forwarding
node.
M
I
Actually,
it
should
be
again
there
if
we
talk
about
active
OAM
right,
so
we
have
multi
layer,
active
om,
individual
document
in
SFC
working
group,
so
the
scope
of
it
is
as
if
SFF
not
the
service
function.
So,
therefore,
the
forwarding
behavior
again
a
forwarding
behavior
is
is
based
on
SSB,
not
on
the
service
function.
Okay,.
M
I
F
I
Thank
you
if
the
working
group-
and
we
had
the
discussion
before
so
if
the
working
group
I
would
work
in
the
current
document
and
the
header.
Yes,
we
have
echo
requests
required
document
resulting
from
overlay
design
team
as
well,
but
there
are
like
the
tendency
between
Heather
and
this
work
and
if
both
documents
would
be
considered
by
this
in
the
or
three
working
group
and
adopted
our
will
pursue
as
a
common
solution.
But
if
not,
then
will
continue
with
the.
C
Of
hands
for
who's
read
latest
version
of
this
draw,
so
please
raise
your
hand
if
you
have
read
this
draft
okay,
so
it's
probably
ten
or
ten
or
twelve
of
those
who
have
read
it.
Who
think
raise
your
hand
if
you
think
the
general
approach
of
having
an
overlay,
OEM
header
in
so
draft
Ernie's?
It's
the
right
way
to
go
for
oh
yeah,.
C
N
Yes,
I'd,
like
to
reiterate
I,
mean
I'm
really
happy
to
see
the
discussion
actually
happening
on
om
here.
I
think
this
was
very
helpful.
This
is
something
that
the
working
group
supposed
to
work
on
over
four
years
ago.
It
was
something
that
needed
to
get
done
when
I
got
became
responsible
idiot
for
the
group.
So
please
we
need
this.
V
excellence
been
deployed
for
a
really
long
time
and
jean-yves
coming,
and
one
of
the
value
adds
that
the
IETF
is
supposed
to
do
his
management.
Let's
get
it
right.
Thank
you.
F
O
About
multiple
in
capture
relating
to
interconnection
in
worship
which
arise
overlay
Network,
this
is
the
first
presentation
and
the
job
is
primarily
so
you
can
interrupt
me
at
any
time
and
Trust
if
the
background,
as
we
know
that
we
have
many
overlay
technologies
such
as
bait,
we
excellent
cheeky-
you
need
a
meaty
REE,
et
cetera
and
different
vendor
may
use.
Technical
encapsulations
saw
the
proper
gains
for
a
virtual
network,
almost
lack
connect
to
the
same
virtual
network
and
want
to
communicate
to
each
other
required
to
have
the
same,
didn't
land
encapsulation.
O
So
we
want
to
support
micro,
micro,
encapsulation
interconnection.
We
suggest
to
introduce
a
new
component
in
architecture.
The
new
component
is,
we
call
it
just
just
from
our
gateway
and
generally
it
is
located
in
the
year.
So
we
also
create
transformer
and
the
E
and
T
emanating
at
revelation
and
that
he
has
been
a
highlight
in
weather,
with
the
rel
bloodsucker
tell
me
provide
a
great
function
for
the
to
amis.
That
may
not
show.
L
O
O
And
to
support
such
interconnection
and
control
control
message
also
some
have
some
requirements,
but
here
I
am
a
year.
It
didn't
need
to
modify
an
MA.
The
link
operations
is
the
pot
and
I
mean
into
ma
I
mean
I
mean
you
will
notify
the
adjacent
mapping
I
just
mapping
between
the
enemy
and
it's
attached.
Yes,
as
usual,
and
you
know
teaching
it.
We
also
need
to
notify
the
to
emanate
that
encapsulation,
the
MA
I
support
an
optional
and
I
mean
he
also
need
to
notify
and
maintain.
O
L
Hi
Kyle
arrows
I'm
curious
as
to
what
led
you
to
start
working
on
this
because
I've
been
reading
a
draft
today,
sort
of
far
off
about
it's
a
gateway
function
for
Network
slicing
which
I
haven't
finished
yet
so
if
I'm
misinterpreting
it.
But
it
sounds
like
it's
talking
about
a
similar
problem
where
you're
moving
between
different
administrative
domains
in
an
Fe
Network,
and
they
have
different
capabilities.
Different
underlays
things
like
that
and
there's
a
gateway
function.
That's
translating
between
now.
The
document
I'm
reading
is
much
higher
level.
L
O
P
P
O
P
I
J
Franco
verse,
11
I,
have
another
say
high
level
question:
where
do
you
want
to
go?
Take
that
work,
because,
right
now
it's
mostly
articulation
of
the
problem
domain.
It's
a
bit
of
a
framework
document
and
you
could
say
well
I
have
this
uber
thing
that
provides
for
mapping
and
the
likes,
and
that
might
be
OpenStack.
I
might
be
something
like.
So
where
do
you
want
to
go?
Take
that
do
you
want
to
go
and
specify
the
protocols
to
go
and
provide
for
these
addresses,
or
so
what's
the
next
step
that
you're
intending
with
this.
J
But
I
think
you
articulated
what
you
articulated
in
architecture.
You
have
a
system
that
has
two
terminal
types
arriving
at
that
worry
at
that
very
node
today.
Well,
I
have
a
vehicle
on
tome
coming
in
a
virgin,
eternal
leaving,
I
have
well
a
bridging
function.
That's
connecting
those
two
yeah,
that's
set
up
and
I
think
what
you're
articulating
is
that
someone
you
need
to
go
and
set
that
up
control
the
endpoints
and
are
you
intending
to
go
and
standardize
the
control
also
do
that
or
so
once
we
have
this,
what
is
the
next
step.
I
Gregg
nurses
tear
as
a
golfer
of
this
draft
I.
Yes,
Frank
is
right,
so
this
is
a
problem
statement
at
this
time.
So
what
we
are
looking
for,
the
feedback
of
the
working
group
and
discussion
of
whether
it's
a
problem
that
needs
to
be
solved,
how
that
will
be
what's
a
conclusion
whether
it's
like
adapt
as
adoption
of
this
document,
would
be
agreement
that
this
is
a
problem
that
needs
to
be
solved,
if
not
necessarily
that
this
document
will
be
the
document
that
will
provide
their
protocol
or
standard
part
of
solution.
I
But
in
a
document
we
point
to
their
areas
that
needs
to
be
solved
because
there
needs
to
be
some
negotiation
normalization
of
what's
different
protocol
capable
of
what
features
are
common
features
and
what
can
be
translated.
So,
yes,
there
will
be
some
protocol
or
some
negotiation
normalization
of
the
control
plane
in
order,
then,
to
be
able
to
work
on
a
data
plane,
layer
and.
C
L
C
I
L
R
R
So,
as
we
know,
the
congestion
is
a
pillar
of
the
network
performance,
so
are
the
two
kinds
of
congestion.
Seeing
the
data
center
network
is
a
network
congestion
and
endpoint
congestion.
So
here
we
want
to
so
we
want
to
discussing
in
network
congestion
that
which
is
the
caused
by
the
poor
traffic
screen,
so
paths
in
action
that
could
be
traded
as
a
node
that
balancing
issue,
and
currently
there
are
several
load
balancing
technologists
to
resolve
the
network.
Congestion
problem,
such
as
the
well-known
ecmp
flow
left
and
a
packet
rate.
R
R
First,
a
staff,
the
source
end
point-
will
spray
the
packets
on
the
different
parts,
and
here
it's
the
layer,
2
and
2
here
cross
network,
and
in
this
scenario
we
do
not
need
to
modify
the
span
switch
and
we
just
need
to
modify
the
leaf
switch.
Oh
and
here
in
this
draft
we
use
at
Geneva,
Geneva
and
2e
capsulate.
The
pact
is
sequence
number
and
the
on
the
second
step,
the
on
the
destination
endpoint,
and
we
will
do
the
reordering
and
either
of
the
list
then
switch
over
on
the
server.
R
So
for
those,
as
we
know,
that
would
TCP
has
provided
a
reordering
function,
but
for
those
out
an
operating
system
or
awesome
circumstances
were
not
used
a
TCP
reordering.
So
we
think
that
a
factory
ordering
is
still
needed
in
English.
In
our
rows
and
in
this
draft
we
proposed
the
practice
ring
format
over
Geneva
and
so
in
the
option
field
of
Geneva.
We
use
to
fill
one.
It's
a
flow
group
ID,
the
other
is
sick
number
and
each
has
were
useful,
bytes
and
separately
in
different
group
ID.
R
That
definition
of
that
is
that
we
we
identify
a
group
of
flows,
use
three
couple
between
a
source
destination
pair,
which
is
source,
address,
destination,
address
and
a
floating
ID,
and
we
use
the
next.
We
will
explain
more
about
this
field.
The
second
is
sequence
number,
which
is
its
well
known.
It
ranged
from
zero
to
and
twenty
thirty
to
power
of
two
minus
one,
and
if
we
do
the
practice
brief
function
on
the
saucepan.
R
R
At
destination
and
here
at
destination
point
we
were
do
the
reordering
in
Windows
three
couple
by
the
sequence
number,
and
but
here
that
we
want
to
mention
that
the
the
destination
should
notify
the
sauce.
Now
that
the
capability
of
the
reordering,
which
means
that
the
the
negotiation
of
the
capabilities
would
be
take
place,
and
so
the
control
that
ma
generic
control
plan
is
native
to
to
realize
this
function.
So.
R
When,
when
the
sauce
node
know
that
the
capability
of
the
destination,
so
they
need
to
in
tune
to
the
allocation
mechanism
of
the
floating
ID
and
if
the
fluid
ID
received
on
the
destination
exceeds
the
local
capability
here,
we
recommend
two
ways
to
move
forward.
The
first
one
it
just
discard
discard
of
the
Geneva
packet,
which
exceeded
the
local
capability.
The
second
adjust
to
remove
the
Geneva
II
capsulation
and
move
the
packet
to
higher
layer
to
do
the
reordering.
R
Here
just
share
the
the
performance
comparison
on
the
on
the
cactus
green
function
and
we
were
finished
than
the
rest
simulation
and
share
with
others
later
so
here
it's
a
tier,
3
tier
cross
and
topology,
and
we
use
the
the
three
call
switch
and
the
city
to
AB
switch
and
the
32
leaf
switch.
So
here
the
traffic
pattern
is
only
use
UDP
because
we
want
to
get
rid
of
the
influence
of
the
TCP
retransmission
and
in
the
future
we
may
simulate
the
new
TCP
traffic
as
well.
R
So
based
on
the
comparison
that
we
then
use
a
different
load
balancing
regularity,
we
could
we
use
the
parameter
n.
So
the
the
N
power
of
two
means
the
the
granularity
to
spread
to
spray
the
packet.
So
if
the
the
N
equals
two
label,
that
means
it's
a
packet
of
spray
as
a
narrow
if
N
equals
two
tell
it
close
to
to
easy
and
P.
We
compare
the
three
factors
through
hood
and
packet
drop
and
average
latency.
L
R
Performance
on
the
right
up,
I
refer
of
that,
and
when
we
do
the
practice
pre-prepared
that
the
the
traffic
that
a
packet
job
is
quite
low
and
when
we
do
the
CMP,
the
backdrops
increase
and
about
the
dam
origination
see,
and
we
could
see
that
easy
packs
berry
can
achieve
the
more
better
performance
than
the
DCM.
He.
R
Okay,
so
next
step
the
since
it's
a
quite
new
draft
and
we
want
to
see
wall
commenced
and
the
more
collaboration
in
the
future
work.
So
we
will
continue
the
simulation
and
share
with
their
emails
or
maybe
the
presentations
next
time
and
and
if,
in
the
same
time,
we
will
search
for
work
with
and
other
customers
and
to
run
a
test
on
a
real
test
bath.
That's
all.
L
L
He
should
put
entropy
into
the
source
part
of
the
you
sometimes
may
be
coming
to
talk
here,
I'm
just
so
when
you
build
the
genève
header
and
you
put
the
UDP
header
that
next
part
of
it
on
the
packet,
what
value
did
you
choose
with
a
source
port?
Was
it
fixed?
Was
it
based
on
the
flow
or
was
it
actually
something
essentially
random,
because
you're
allowing
reordering
within
the
network?
Yes,.
L
Guess
what
I'm
saying
it
would
be
nice
to
have
some
guidance
on
this
and
that
drops
because
if
you
make
it
equal
to
the
flow,
which
is
what
this
new
specification
says,
it
should
be
then
any
PAC.
You
know
if
all
the
packets
end
up
going
through
one
path
at
some
point
and
there's
congestion
there
they'll
only
ever
take
the
one
link,
but
if
you
make
it
essentially
random,
then
even
if
they
hit
the
same
same
device
in
the
network,
they
might
choose
multiple
decks
on
that
device.
L
R
P
P
P
I
R
P
R
K
Q
C
Right
so
the
last
thing
on
the
agenda
is
a
little
bit
of
time
on
next
steps
in
the
working
group
and
moving
forward,
so
so
I
think
we're
quite
close
to
it
to
working
group
a
school
with
genève
data,
plane
security
as
well
and
well
underway
now,
so
we
need
to
really
consider
what
what
documents
we
want
to
make
progress
on
next.
So
we
just
had
a
discussion
about
om
I.
C
Think
we've
identified
some
at
least
some
ways
to
improve
the
OEM
draft
and
that
Gregg
has
presented
the
Ani
VPN
for
our
distributed
control
plane.
As
we
mentioned,
we're
going
to
run
a
poll
for
adoption
for
the
EVP
on
applicability
draft
after
this
ITF,
so
that
really
leaves
leaves
open,
centralized
control,
plane
and
all
slash
and
management
plane.
C
We
did
have
a
young
model
draft
at
one
time
for
the
X
land,
but
we
also
need
really
need
a
young
model
for
genève
I
mean
do
more
general
kind
of
overall
young
model,
I
think
for
configuring.
The
various
elements
in
the
MVA
three
architecture,
so
so
we're
kind
of
thinking.
One
way
forward.
This
is
to
form
a
young
design
team
within
nvo,
three
personally,
having
been
on
on
these
young
design
teams
in
the
past
for
getting
young
models
done
they're,
quite
an
efficient
way
of
doing
it.
C
S
C
C
N
Sorry
I
just
like
to
face
everyone,
you
know.
So
what
are
you
all
interested
in
working
on?
Is
this
just
lets
get
Jenny
you've
done,
because
that's
a
great
piece,
but
we
do
need
some
other
chunks
along
and
we've
talked
about
doing
getting
model
stuff,
if
that's
not
the
right
management
or
or
central
orchestration
answer
for
what
you're
looking
for
what
is
are
the
things
that
we're
missing
the
Charter
for
nvo
3
is
fairly
old,
so
what's
missing,
obviously
you're
all
here,
hopefully
you're
watching
and
being
interested.
What
are
you
interested
in
working
on?
C
Any
any
comments,
specifically
I,
guess
that
you
know
thing
I
mean
we
know
that
we're
missing
young
models,
but
there's
there
anything
else.
That
needs
to
be
done
for
a
centralized
control.
Point
I
mean
there
is
work
going
on,
for
example,
in
LS
VR,
with
a
centralized
control
play
model
with
using
BGP
and
data
centers.
Is
that
relevant
here.
T
C
V
I
N
I
L
W
So
I
didn't
raise
my
hand
in
favor
of
yang,
not
only
because
I
didn't
want
to
get
volunteered
to
be
an
editor,
but
I
just
saw
one
document
that
discussed
the
potential
new
option
virgin
Eve,
headers
and
I
in
general.
I'm,
not
quite
sure
how
you
would
go
about
defining
a
standardized
option
if
we
didn't
continue
to
have
some
kind
of
effort
at
a
yang
model,
for
the
configuration
of
that
would
probably
be
a
very
useful
thing.
So
I
guess
I
am
sort
of
speaking
in
favor
of
seeing
something
done
for
centralized
configuration.
F
A
C
Or
yeah
this
isn't
this
isn't
as
soon
as
we
published
the
genève
RFC.
This
is
when
we've
completed
the
things
like
the
DOS
plane
security,
so
I
should
have
been
clearer
in
that
the
document
security
in
the
OEM.
For
for
that
I
mean
really.
The
question
is:
do
we
need
to
go
further
than
that
within
a
controller
management
play.
J
Yeah
Frank
Roberson.
There
is
multiple
aspects
to
om
right,
so
there
is
active
OEM.
There
is
the
in
situ
OEMs,
but
some
of
that
work
is
done
in
AI
ppm,
not
here,
but
I
would
definitely
think
that
it
makes
sense
to
go
and
at
least
create
the
big
nor
or
continuing
with
the
big-ticket
items,
to
make
it
a
complete
protocol
solution,
as
opposed
to
kind
of
give
up
halfway.
J
X
Just
ensuring
OSHA
with
regards
to
young
design
team
I,
was
highly
recommended
everyone.
Speaking
of
routing
chair,
we
had
routing
young
you
thank
you
for
three
years,
delivered
great
models,
we're
shutting
down.
Actually
this
ATF,
but
we've
done
all
the
work
we
needed
to,
and
it's
always
good
to
get.
People
of
the
main
understanding
as
well
as
he
understanding
so
I
was
highlight,
was
to
create
one.