►
From YouTube: IETF103-NVO3-20181107-1350
Description
NVO3 meeting session at IETF103
2018/11/07 1350
https://datatracker.ietf.org/meeting/103/proceedings/
C
C
B
B
B
B
working
group
first
of
all,
but
we
also
need
to
have
a
discussion
on
where
those
really,
but
he
said
this
might
be
the
mo
or
mvo
three
things
I'm
going
to
go
through
the
new
draft
on
overlay,
something
architecture
and
then
so
many
Scott-
and
this
is
a
new
addition
to
the
agenda.
It's
going
to
give
us
an
update
on
the
Geneva
pick
ability
for
SFC
any
comments
on
the
agenda.
B
Thank
you
very
much,
okay
milestone,
so
we
said
we
would
update
these
after
the
last
ITF
and
we've
now
finally
done
so,
but
of
course,
because
we
left
it
so
long,
they're
out
of
date
again,
I
think
so.
We've
we've
removed
a
couple
of
a
couple
of
the
existing
milestones
around
control.
The
installation
and
trial
plan
requirements,
because
not
a
lot
of
progress
was
being
made
on
those
and
added
a
couple
master
days
milestones
on
security
requirements
and
solutions,
since
I
saw
a
significant
focus
it
to
working
in
the
group.
B
B
That's
on
the
agenda
today,
the
design
team
draft,
which
has
draft
IETF
and
vo3
endcap-
that's
currently
expired.
We
were
taught
to
the
authors
about
that,
but
would
I'd
see
that
revised
or
revived
after
draft
Geneva's
has
gone
to
the
ASG
because,
as
we
discussed
in
the
past,
the
idea
was
to
propose
to
publish
the
DT
out
design
team
output
after
Geneva
gone
through.
B
B
B
B
The
authors
have
been
in
discussion
with
those
reviewers,
but
we
don't
really
have
an
updated
draft
yet,
and
some
of
the
comments
seem
to
require
updates
to
the
draft
and
then
some
shuttling
back
to
thee
to
the
reviewers
to
try
and
get
consensus
there
other
any
of
the
authors
of
the
EMM
ability
protocol
in
the
room.
If
they
they
could
give
us
an
update
on
on
what
they
plan
to
do.
B
Okay,
well
we'll
follow
up
with
the
authors
anyway.
I
might
try
make
some
progress,
sir,
and
since
the
last
ITF
we
have
a
adopts
a
new
working
group
draft,
which
is
the
evpn
applicability
draft
for
genève.
So
this
is
basically
an
ability
statement
and
there's
a
corresponding
draft
in
the
best
working
group
which
other
protocol
extensions
required
for
for
you
to
engine
even
evie.
D
B
E
So
two
security
requirements
where
we
are
so
we
had
a
few
discussion,
Manila
gaze
under
Mike
okay,
so
we
had
a
few
discussions
on
them
on
the
mailing
list
and
my
intention
here
is
to
not
to
go
through
all
the
requirements.
It's
probably
something
that
needs
to
be
discussed
during
an
interim
meeting.
But
what
I'd
like
to
you
understand
is
if
we
have
a
good
way
of
working
and
if
we
have
a
common
understanding
of
how
to
read
the
requirements
and
what
the
requirements
are
expected
to
fulfill.
E
E
E
E
So
the
purpose
of
the
well
is
next
slide.
If
you
want
to
security
check,
how
secure
is
your
deployment?
You
have
to
match
any
of
the
requirements
and
you
have
to
pass
through
all
these
requirements,
but
a
lot
of
them
have
some
conditions.
So
in
a
lot,
maybe
in
in
most
of
the
cases
some
of
the
requirements
don't
apply,
in
which
case
we
consider
that
you
pass
the
requirement.
So
it's
not
that
you
have
to
to
to
set
a
lot
of
properties
that
you're
not
taking
advantage
of
for
your
deployment
as
a
typical
example.
E
If
you
want
to
secure
with
TLS
in
some
case,
you
might
feel
all
the
requirements,
because
that's
sufficient
for
your
your
specific
deployment.
On
the
other
hand,
if
you
want
to
use
I'm
just
taking
as
an
example
TLS
as
a
generic
jean-yves
specific
mechanisms,
then
you
have
to
to
match
all
the
requirements
and
in
some
cases
it
seems
hard
that
TLS
fits
all
these
requirements,
but
something
we
have
to
evaluate
later.
E
So
that's
basically
how
the
set
of
requirements
is
built
so
now
I,
don't
know
how
much
time
I
have
we
can't
we
make
start
to
go
through
some
of
the
requirements.
Do
to
evaluate
or
I
can
take
the
feedback
or
I.
Don't
is
there
anything?
Do
you
think
the
the
two
sets
of
requirements
are
valid
or
there
is
one
we
should
remove
or
if
you
want
to
the
requirements
to
address
another
type
of
question
or
what
is
the
feeling
of
the
room,
the
working
group
so.
E
E
So
we
could,
we
can
sleep,
just
requirements
into
a
different
drafts,
I'm
fine
with
that
we
can
have
one
draft
with
a
threat,
description
and
otherwise
the
operational
requirements
and
another
one
for
the
genie
of
security
mechanism
requirement.
I'm
fine
doing
this
way,
but
I
have
the
impression
that
I'm,
not
sure
I
mean
it's
three
document
instead
of
one
so
I,
don't
know
how
it's
gonna
be
the
overhead
or
and
the
the
commitment
to
you.
D
D
D
You
know
transport
encapsulation
protocols,
so
why
that
you
know
we
have
to
go
into
this
level
of
details
and
in
fact
it
gets
into
implementation
details
as
well
in
in
some
of
the
areas
which
is
burdensome
for
the
operator
and
it's
also
burdensome
for
the
implementer
and
which
is
not
necessarily
needed
for
enough
securing
Geneva
I
mean
take
any
any
product
column
and
replace
genève
with
any
other
protocol.
Like
you
know,
Lisp
or
you
take
a
protocol
like
MPLS
over
UDP
or
IP
over
IP.
D
None
of
those
protocols
you
know,
have
to
go
through
all
of
these.
You
know
such
kind
of
requirements,
but
they
are
still.
You
know
able
to
people,
are
able
to
securely
deploy
those
protocols
and
successfully
operate
it
as
well
and
as
that's
the
fundamental
disconnect
here
and
so
I
think
we
need
to
address
that
one
first.
Otherwise,
we
have
been
going
in
circles
for
the
last
two
or
three
iterations
we
can
always.
You
know
once
this
result
that
we
can
always
go
back
and
you
know
fix
some
of
the
individual.
D
You
know
requirements
and
that's
basically
my
my
common.
If
you
want
you
know
you
can
go
through
some
of
those.
You
know
examples
and
then
show
it
to
the
rest
of
the
working
group.
I'm,
not
sure
how
many
of
the
working
group
members
have
already
gone
through
this
draft
in
detail,
but
I
think
it
will
be
good
if
you
can
get
more
input
from
people
who
are
you
know
in
the
operational
experience
or
the
people
who
have
you
know,
protocol
implementation,
experience
and
that'll
be
really
good.
So
that's
basically
my
my
comment.
B
D
Because
concern
is
for
for
both
cases.
So
if
you
look
at
you
know,
individual
requirements,
I
think
some
of
the
examples.
If
you
go
through
the
go
through,
you
know,
subsequent
slides,
you
will
see
that
where
the
document
talks
about
multiple
different
requirements
and
not
and
then
also
claims
that
you
know
you
need
to
have
a
Jenny,
specific
or
a
security
mechanism,
and
then
all
of
these
requirements
need
to
be
met.
D
A
D
D
I
think
we
need
to
first
address.
How
do
we
frame
the
problem
and
that's
basically
the
whole
challenge?
I
mean
what
is
the
documents
objective?
Is
it
to
go
and
give
guidance
to
the
deployers
that
you
know
these
are
the
possible
or
potential
risks
in
an
environment?
And
if
you
have
to
address
you
know
risk
number
a
then
you
need
to
be
able
you
need
to
fulfill.
You
know
these
two
or
three
requirements
in
order
for
you
to
deploy
in
a
secure
manner
and
that's
how
it
needs
to
be
approached.
D
Rather
than
saying
that
you
know
you
need
to
you
need
to,
if
you
prescribe
like
ten
requirements
and
say
that
all
these
ten
requirements
have
to
be
met
in
order
to
call
that
this
is
a
genuine
appointment,
and
that's
that
that
will
that
is
unnecessary
and
other
people
might
start
to
ignore
it.
Because
people
who
you
know
we
really
wanted
to
give
guidance
to
operators
not
to
over,
prescribe
something
that
you
know.
Operators
may
not
really
use
it
or
care.
E
E
E
You
consider
is
applied,
is
a
match
so,
for
example,
I'm
taking
a
well
the
first,
the
first
one
I'm
saying
that
by
default
you
should
encrypt
the
inner
payload,
but
I'm
also
saying
that
you
may
disable
this
capacity,
if
you
believe
so
so
or
if
you
don't
believe
the
risk
is
too
high.
So
in
that
case
well
my
intention
was
to
say:
well,
if
you
don't
know
your
encrypt,
but
if
your
carefully
evaluate
that
the
risk
is
sufficiently
low,
then
you
can
disable
this
these
mechanisms.
H
Great
mercy,
City
I,
just
wonder:
how
can
we
get
their
input
from
operators
themselves
and
not
speak
on
their
behalf?
So
might
be
some
blind
Paul
and
ask
them
to
evaluate
because
otherwise
we'll
be
just.
You
know
my
opinion,
your
opinion.
We
need
to
some
objective
information,
not
that
what
we
think
that
operators
will
do
or
not
do,
and
then
we
can
just
make
it
practical,
realistic,
something
that
helps
operators
and
set
certain
requirements.
Yes,
there
will
be
requirements.
There
will
be
certain
things
that
you
need
to
do
you
like
it
or
not.
A
Sam
speaking
as
a
new
deal,
I
think,
if
I
understand
even
a
little
comment
this
in
line
with
what
you
say
is
we
provide
the
necessary
guidance
and
let
the
operator
choose
and
to
elaborate
on
your
question.
It
is
not
just
a
new
orthis
problem,
it
is
pretty
much
IDF's
problem.
Their
operators
have
to
really
provide
feedback,
and
it
is
very
hard
to
get
first
of
all
and
second
of
all
like
how
actively
we
can
actually
pursue
operators
to
forward
the
feedback.
So
this
is
a.
E
So
but
the
feedbacks
are,
of
course
modern
welcome,
but
the
thing
is
that
the
cut
the
requirements
came
from
an
analysis
from
the
threats
related
to
the
Geneva
Protocol
and
its
deployment.
So
we
are
not
going
into
operational
deployments
that
are
not
related
to
Geneva,
so
I
guess
at
that
point
the
security
analysis
might
be
sufficient
to
to
provide
I
mean
a
complete
set
of
requirements.
E
E
I
Frank
LaRose
I
have
a
more
fundamental
question.
How
are
you
expecting
that
somebody
reads
this
document,
given
that
it's
informational
is
it
just
like
you
want
to
use
this
document
to
self
assess
yourself
to
understand
whether
your
genève
deployment
is
considered
quote,
unquote,
secure
and
what
security
means,
or
do
you
expect
that
an
implementer
would
follow
this
seven,
so
I'm
a
little
puzzled
on
what
the
document
Akane's.
C
I
B
E
Okay,
so
to
answer
it
briefly,
do
your
personal
requirements
are?
If
you
have
a
deployment,
do
you
need,
and
you
want
to
check
how
secure
you
are
or
if
you're,
a
secure
or
not,
it
provides
you
guidance
and
aspect
to
loop
that
whatever,
however,
you
deploy
it
for
the
what
I
call
the
security
jean-yves
mechanisms
requirements,
those
are
intended
for
architect
or
protocol
designer
and
to
to
elaborate
what
we
called
genie
of
security
mechanisms,
which
means
it's
a
mechanisms
that
can
secure
any
genève
deployment.
E
So
this
so
the
next
the
category
the
latest
set
of
requirements
will
be
used
to
define.
How
can
we
define
like
genève
security
options
or
a
way
to
secure
any
genève
deployment,
which
means
that
if
you
implement
this
one,
you
don't
have
to
look
at
alternate
solutions
or
well.
You
may
use
those
patan
I.
B
J
Sorry,
I
I'm
I'm
having
a
problem
with
my
feet.
Can
you
hear
me?
Okay,
yes,
yeah
so
I
have
similar
comments
as
Ellen
goes
there
that
again
it
starts
from
the
basic
as
to
how
to
actually
frame
the
requirements
and
also
in
terms
of
the
all-or-nothing
approach.
So
we
do
want
more
people
to
read
the
draft
and
comment
on
the
list.
Whether
this
is
you
know
the
direction
that
we
want
to
go
on.
Thanks,
okay,.
B
We've
been
talking
about
having
a
maybe
a
virtual
interim
meeting
to
just
on
security,
to
try
and
resolve
some
of
these
issues.
But
if
you
could
read
the
draft,
if
you
have
concerns
or
comments
on
that
person
to
the
list,
but
we
will
send
a
notice
for
interim
meeting
I
think
some
points
in
the
next
month
or
two
thank.
D
Yes,
I
able
to
hear
me
yes,
good,
so
I'm
gonna
give
a
an
update
on
the
progress
of
the
working
group.
Last
call
so
I'd
also
like
to
thank
Shearer,
who
had
been
working
with
me
and
in
hand
in
order
to
you
know,
do
the
responses
as
well
as
analyzing
the
comments
on
the
list.
So
please
go
on
to
the
next
slide.
D
So
draft
Jenny
was
updated
on
October
7th
for
the
working
group
last
call
and
in
in
this
version
we
addressed
the
comments
that
we
received
mainly
on
the
security
consideration
section
and
and
and
based
on
this.
The
chair
call
for
the
working
group
last
call
on
October
9
to
26.
We
received
comments
during
the
last
call
and
responded
to
those
comments
with
the
proposed
text,
and
this
was
all
in
the
mailing
list,
and
the
chair
also
requested
for
an
early
review
by
the
security
Directorate,
and
we
also
got
feedback
from
that
review.
D
The
audio
review
and
the
feedback
was
positive
and
to
give
a
code
like
the
document
is
written
in
a
clear
manner
with
the
security,
thorough
security
consideration
section.
But
in
addition
to
that
you
know
there
were
few
comments
actually
to
be
precise,
about
three
comments
on
from
that
review,
and
then
we
also
proposed
text
to
address
those
comments
as
well,
and
then
there
was
also
a
request
for
an
early
review
by
the
Transport
Directorate,
and
then
we
did
not
get
any
any
response
or
comments
from
that
early
review.
D
But
that
might
be,
you
know,
still
open
and
moving
on
to
the
next
slide.
This
is
regarding
I
mean
this
goes
through.
The
working
group
lascall
comments
that
that
we're
that
we
received
on
the
reflector
and
the-
and
we
have
not
we're
not
going
to
go
through
each
and
every
comments
pretty
much.
All
of
those
were
discussed
on
the
mailing
list,
so
you
you
can
go
and
see
the
details,
but
what
I'm
presenting
here
is
the
team.
D
You
know
the
team
of
comments
that
received
and
pretty
much
we
are
covering
all
the
categories
of
the
comments
that
we
received
so
number
one
is
the
guidance
on
the
TTL
handling.
There
was
a
request
for
guidance
on
the
TTL
handling
and
what
we
said
is
RFC
2003,
which
is
the
IP
and
IP.
You
know
protocol
and
that
provides
guidance
on
the
handling
of
TTL
and
this
model
is
applicable
to
chain
even
and
and
that's
being
recommended
for
use
with
Geneva,
and
we
also
put
out
a
proposed
text
to
the
satisfaction
of
the
common
term.
D
That
was
an
OOP
gun
wani,
and
then
we
also
provided
reference
to
RFC
80
to
93.
This
is
the
new
RFC
that
came
out
of
this
working
group
that
gives
the
multicast
framework,
and
this
is
an
informative
reference
and
we
also
updated
reference
in
the
Ayane
section
to
RFC
81
26,
and
then
there
was
also
a
suggestion
on
option
class
assignment,
and
we
did
clarify
that.
We
have
arranged
for
result
for
IETF
review
and
we
also
have
a
range
with
lenient
policy.
D
That's
based
on
first
come
first
serve
policy,
and
then
there
was
also
a
request
on
the
clarification
of
the
orbit
usage,
and
we
also
proposed
text
to
clarify
this
bit
is
used
to
indicate
control
message
between
nve's
and
also
we
proposed
to
remove
reference
to
om
and
rename
that
bit
as
a
control
bit
and
so
on.
Om
bit,
and
that's
just
regarding
the
theme
on
this
slide
and
I
can
go
to
the
next
slide.
D
Yeah
here
we
further
have
you
know,
clarification
on
options,
processing
and
checking
there.
There
were
few
comments
from
you
know:
multiple
different
commenters
on
option
processing
and
how
it
is
it
needs
to
be
handled,
and
so
we
added
our.
We
proposed
clarifying
text
in
order
to
address
those
comments
as
well,
and
there
was
also
a
comment
on
the
interpretation
of
option
by
the
transit
devices.
You
know
whether
you
know
how
is
it
being?
D
Devices
in
in
both
cases
are
an
option,
generation
and
termination
versus,
and
also
we
propose
text
for
the
security
consideration
section
as
well
to
clarify
this,
and
there
were
a
bunch
of
comments,
and
this
came
in
from
Daniel
himself,
and
so
we
did
propose
text
to
clarifying
those
statements
as
well
and
also
to
remove
any
redundant
text
for
better
readability,
and
we
also
had
some
comment
on
the
resort
built.
This
came
in
from
the
early.
You
know
secondary
review,
and
so
we
did
propose
comments.
D
This
is
more
of
a
minor
clarification
in
order
to
fix
that,
and
they
also
had
a
you
know,
comment
on
the
options
which
kind
of
very
similar
to
very
similar.
To
you
know,
the
Daniel's
comments
are
on
oops
comments
and
we
addressed
that
one
or
a
proposed
text,
or
does
that
one
as
well-
and
there
are
few
other
editorial
comments
that
was
from
Innokin
1e,
as
well
as
from
Danielle
McCall,
that
we
we
will
address
that
as
well
and
moving
on
to
the
next
slide.
So
we
will
be
ready
to
publish
an
updated
draft.
D
H
Appreciate
that
your
consideration
with
my
comment
on
orbit
couple
notes
to
what
you
explained
in
details,
I
I
liked
that
you
decided
to
remove
for
reference
to
OEM
a
little
bit.
I
think
confusing
that
it's
now
indicates
the
control
between
envies.
Is
it
implying
that
there
is
a
in
band
control
protocol
between
envies
in
Geneva?
H
H
D
C
D
Then,
where
is
the
bit
that
you
talked
about?
The
C
bit
is
actually
critical
options
bit.
That
indicates
that
you
know
the
you
know
the
the
Jenny
actually
carries
no
critical
options.
That's
basically
the
intent
of
that
one.
So
that
way-
and
there
is
also
a
special
you
know-
there's
also
a
description
on
what
it
means
by
critical
options,
and
how
do
you
handle
that?
That's
been
clearly
described
in
the
draft
as
well.
C
H
Agree,
but
there
is,
since
we
have
a
product
called
field.
I
absolutely
agree
with
you
comment.
Since
we
have
a
protocol
field,
the
protocol
can
define
associated
channel
and
there
is
no
apparent
reason
to
have
another
mechanism
to
indicate
that
this
is
associated
channel
message.
Okay,
so
the
associate
the
channel
sufficiently
identified
by
the
protocol
type.
D
It
need
not
be
a
separate
control
protocol
right,
so
it's
basically,
the
next
protocol
could
be
the
same
right.
For
example,
next
protocol
could
be
Ethernet
and
your
control
message
could
also
be
an
Ethernet,
so
this
Flags
that
you
know
it.
Second,
you
know
it's
a
control,
a
control
packet
and
then
it
needs
to
be
handled
through
the
exception
path
in
our
slower
path
and
that's
what
how
it's
being
used,
and
so
so
that's
the
reason
why
we
have
this
bit
again.
H
I
think
that
we're
doing
in
circles,
because
we
already
have
with
Jessi
this
discussion,
what's
the
purpose
of
using
Ethernet
encapsulation
for
env2
in
ve
messages,
they
can
have
just
their
control
message,
format
identified
by
next
protocol
and
then
similar
identifies
the
type
of
the
message.
So
you
can
decode
it
easily
again.
H
D
H
If
we
say
that
we
identify
associate
the
channel
associate
the
channel
easily
identified
by
the
next
protocol,
next
protocol
can
say:
okay,
this
is
associate
the
channel.
You
have
a
shim
layer
that
identifies
the
time
of
the
message
and
associated
channel
as
we
do
in
pseudo
wire,
VCC
V,
our
MPLS
LSP
and
again,
there
is
no
apparent
need
for
the
flag
while
make
it
several
ways.
This
way.
In
that
way,
it
creates
a
problem
with
interoperability,
implementation,
so
good.
B
The
case
and
pseudo
okay,
so
you
think
about
IP
pseudo
wise
in
your
own,
a
night.
If
you're
running
VCC
V
with
IP
encapsulation
in
the
pseudo
wire,
then
you
have
both
the
bits
indication.
This
is
a
packet
on
the
VCC
V
channel,
not
it
that
creates
the
exception.
That
then
gives
you
that
you
then
look
in
CSI.
It's
an
ipv4
packets,
and
that
tells
you
then
maybe
it's
a
VC,
CV
ping
ping
message.
You.
B
H
H
I
B
K
One
of
the
drafts
is
led
led
by
Frank
Bruckner's
and
the
other
is
led
by
Brian
Weiss.
Next,
please
so
just
a
few
words
of
background
about
our
IO
am
in
general.
So
what
we
want
to
do
is
we
want
to
be
able
to
send
telemetry
related
metadata,
which
is
piggybacked
on
to
data
packets,
and
this
information
should
be
carried
either
between
endpoints
or
on
a
hop
by
hop
basis.
K
This
is
called
hybrid
type,
1,
om
and
basically,
the
way
IOM
is
defined.
It's
defined
it's
in
a
generic
way,
which
means
it
can
be
transported
over
various
types
of
encapsulations,
ipv6,
sr,
v6
and
a
sage,
and
the
metadata
we're
talking
about
can
be,
for
example,
timestamps,
node,
IDs,
transit
delay
and
other
types
of
metadata,
and
the
base
document
is
a
working
group
document
in
IEEE
ppm,
and
what
we're
going
to
focus
on
right
now
is
how
IOM
is
transported
over
Geneva.
K
So
this
draft,
which
was
submitted
to
IPP
M,
describes
how
IOM
can
be
transported
over
Geneva
and
the
idea
is
that
we
use
tunnel
options.
So
here
we
see
the
Geneva
header
and
then
there
is
a
tunnel
option
and
the
option
class
specifies
that
we
have
an
IOM
option.
Ok,
so
inside
the
option
we
have
the
IOM
data
and
metadata
header
and
metadata,
and
the
idea
here
is
that
if
you
have
a
node
which
is
not
IOM
capable,
it
can
just
skip
over
the
tunnel
option.
K
Now,
assuming
we
have
a
dedicated
ether
type
for
IOM,
this
is
still
not
the
case,
but
if
the
future
will
have
one,
then
in
Geneva
the
protocol
type
can
be
that
ether
type
and
then
it
can
say:
okay,
the
next
header
is
actually
IOM.
So
after
the
genève
header,
we're
going
to
have
I
owe
em
header
than
IOM
metadata,
and
then
it's
going
to
be
followed
by
the
next
four
calls.
K
So
that's
another
way
to
go,
and
so
we
have
two
drafts
and
they
define
two
different
things,
but
at
the
end
of
the
day,
when
we
ask
the
question,
how
do
we
see
IOM
transported
over
Geneva?
These
are
two
possible
use
cases
of
doing
that.
So
why
are
we
here
and
why
are
we
presenting
this?
First
of
all,
these
two
drafts
are
both
have
both
been
submitted
to
I
ppm
in
general.
K
Unless,
in
some
cases,
some
working
groups
will
prefer
to
adopt
some
of
these
documents.
So,
for
example,
SFC
has
adopted
the
iom
over
n
sh
and
the
peyote
draft,
so
these
two
are
NSF
see
most
of
the
rest
of
these
drafts
have
been
presented
in
AI
ppm
in
some
cases,
also
in
other
working
groups,
and
the
reason
we're
here
is
first
of
all,
we'd
like
to
get
your
feedbacks
and
we'd
be
happy
to
hear
any
comment
and
Greg
you're
the
first
one.
Okay,
thank.
H
K
H
K
H
K
H
Another
question
is
so
I
understand
that
now
the
proposal
is
to
use
next
protocol
code
point
to
identify
I
am
payload
and
place
it
after
their
Geneva
header,
ahead
of
payload
protocol
data.
What
happens
if
their
node
doesn't
understand
is
not
upgraded
to
support
I?
Am
it
will
drop
the
data
right
right?
So
again
we.
K
H
It's
limited,
especially,
if
you
add
a
H
Mac
on
top
of
it
16
bytes.
So
what
left
and
couple
notes?
Okay,
so
basically
you'll
feel
with
H
max
and
overhead
for
Tod.
My
question
is
so
why
not
to
transfer,
collect
and
transport
data
separately
of
the
data
packet,
so
you
can
hit
with
IOM
data
measurement,
but
then
collect
data
in
a
separate
follow-up
packet.
I
Well,
I
saw
one
for
mostly
from
a
genève
perspective.
If
we
use
genève
right
and
we
use
our
own
traffic
laws,
there
we'd
be
as
much
protected
as
any
other
Tod
in
the
Gini
Feder
from
an
integrity
and
security
protection
right.
So
we
basically
leverage
what
the
base
protocol
gives
us.
So
there's
nothing
specific,
so
I
think
the
request,
then,
is
it
really
comes
down
to
yeah?
We
want
a
code
point
for
genève
to
go
and
carry
iom
data.
I
I
think
that's
the
real
base
request
to
the
relief
working
group,
the
the
other
option,
so
the
kind
of
carry
its
side
by
side
or
along
with
carry
the
IOM
data
along
if
the
genève
header
that's
almost
like
in
parallel
right,
and
it
is
something
that
people
could
go
and
implement,
but
it
is
not
specific
to
Geneva.
It's
just
genève
happens
to
use
in
either
type
and
well
picture.
People
can
go
and
sequence
the
header
in
as
they
could
do
with
other
protocols,
say
GRE
whatever
so
I
think
from
a
discussion
focused
perspective.
I
I'd
appreciate
thoughts
on
whether
people
see
that
as
useful.
Yet
the
earlier
common
that
yeah
there
is
a
restriction,
because
the
length
field
is
just
five
bits.
So
128
is
relative,
restrictive!
That's
sad,
I've
not
seen
deployments
with
genève
so
far,
especially
in
overlays
that
have
a
load
of
hops
right.
So
two
three
four
hops
might
be
completely
feasible.
Any
other
thoughts.
G
K
K
B
D
Regarding
the
length
of
the
options
this
was
already
discussed
and
I
know
there
wasn't
a
consensus
to
make
that
change,
and
also
there
are
you
know,
as
it
was
shown
right.
So
there
are
already
two
different
mechanism.
So
if
some
something
that
can
fit
you,
it's
not
just
the
way,
a
message
alone
right.
D
You
are
to
carry
other
options
as
well
and
that's
the
reason
for
the
whole
tlvs
just
not
to
carry
one
option
and-
and
so
you
also
have
an
alternate
mechanism,
if
you
wanted
to
have
you
know
length
larger
than
you
know,
128
bytes,
as
it
was
shown
here,
so
so
as
appropriate.
Based
on
the
usage
models,
you
know
you
can
always
come
up
with
different
mechanisms
to
far
away
in
purposes.
L
L
D
L
But
I
think
we're
kind
of
forced
to
trade-off
abilities
right
from
one
end.
We
will
not
allow
device,
doesn't
support,
IOM
to
be
able
to
parse
and
potentially
because
today,
the
packet
on
the
other
end,
when
we
implement
it
using
tlvs,
we
are
currently
restricted
with
128
bytes,
which
could
be
sufficient
for
some
species
fathers
it
may
not.
So
if
we
can,
you
know,
combine
the
benefits
and
have
larger
TLV
space.
Maybe
it's
a
good
solution.
D
H
Actually,
I
Gregg
nurse
Keegan
I,
probably
use
a
stronger
language
that
Barak
introduction
of
I
am
in
a
heterogeneous
system,
will
break
the
services
because
packets
will
get
dropped.
It's
not
that
only
the
node
that
is
not
supporting
I
am
in
this
manner
with
a
dedicated,
even
my
type
remote
process.
I
am
it
would
drop
the
data
packet
and
that
definitely
should
not
happen
so
it.
We
need
to
understand
that
this
proposal
requires
the
system
be
homogeneous.
The
whole
domain
has
support
RM.
K
H
K
Okay,
I
think
as
peroxide.
It's
kind
of
it's,
the
other
alternative
I
mean
since
we
don't
want
to
limit
only
to
up
to
128
bytes
or
presenting
two
options
and
I.
Think
it's
it's
a
bit
of
a
broader
question,
not
just
in
this
scope,
but
in
general,
or
do
we
think
there
are
other
use
cases
that
will
require
more
than
128
bytes.
No,
this
was
asked
in
the
past,
but
maybe
it
needs
revisiting
I.
L
H
L
B
Good,
thank
you.
So
one
of
the
discussions
the
chairs
are
having
at
the
moment
with
the
authors,
is
where,
where
this
work
resides
and
be
interesting
to
see,
if
you
could
raise
your
hands,
if
you'll
be
interested
in
in
reviewing
these
drafts
with
in
MVA
3.
Ok,
let's
give
this
fair
number
of
people
interesting.
This
work
here
right.
Thank
you.
Thanks.
C
So
why
do
we
need
to
support
subnet
in
the
ITF
101
meeting?
There
is
a
topic
about
networks
rising
well.
The
draft
I
mentioned
that
we
used
to
support
a
subnet
in
connection,
and
it
mentioned
that
there
are
several
possible
reasons
to
spread
an
end-to-end
nanoscience
for
management,
including
to
cross
administrative
domain
boundaries
to
interconnect
parts
deployed
over
different
infrastructure
technologies
and
to
spread
a
slice
system
into
smaller
sections
for
sharing
reusing,
scaring
or
facilitating
management.
C
And
furthermore,
as
this
described
in
encapsulation
Java
in
chemistry,
working
group
and
several
several
overlay
technologists,
such
as
excellent
heat,
new
QE
Accenture
has
nonsense
and,
as
we
know
that
every
technology
has
its
a
customer
and
but
for
an
end-to-end.
The
connection
aversion
network
customers
from
customers
may
use
different
technologies
on
a
year,
especially
when
the
mie
own.
We
switch.
C
So
here
I
mentioned
this
subnet.
We
need
to
extend
the
a
memory
architecture
to
close
the
poll.
The
subnet,
the
subnet,
is
a
little
different
with
the
virtual
version
network.
It
cannot
be
activated
in
isolation.
It
must
be
interconnected
with
other
subnets,
to
form
a
virtual
network
or
to
form
an
end-to-end
connection
to
support
the
subnet.
C
C
So,
in
a
memory
architecture
we
propose
to
introduce
a
new
component
to
us,
support
the
stitching
operation
and
the
new
component
temporarily
may
be
on
and
the
e.
So
we
call
it
stage
MN
GSM
a
year.
The
stage
and
AE
is
worked
as
a
station
gateway
for
sadness,
its
seat.
Then
it's
the
mate
husk
of
the
SMAS
is
to
stitch
the
tunnels
to
form
an
end-to-end
tunnel.
C
To
stop
in
order
to
support
of
stitching
operation
as
SME
should
have
have
such
referring
functions.
It
showed
us
the
court,
several
technologies,
if
needed
and
as
any
issue
the
S&E
can
can
identify
the
customers
traffic
it
should
to
making
four
subnets
and
to
translation
for
a
between
between
panels
and
SME
in
same
ways
at
the
components
in
the
architecture
is
that
it
should
be
too
fought
and
the
performance
monitoring
for
underlay
and
overlay
Network.
C
Okay,
okay
in
this
diagram,
is
a
reference
model
of
SME.
In
this
room,
we
can
see
that
SME
and
meu
one
belongs
to
subnet
one
and
SME
and
then
Sammy
to
belongs
to
a
subnet
to
so.
If
we
want
to
establish
the
connection
between
v1
and
v2,
we
need
a
SME
to
do
the
staging
operation.
The
SME
provides
the
interconnection
between
step,
not
one
instead
of
two
like
gateway.
It
connected
way,
AP
whining
only
one
and
the
way
P
whining
amateur,
so
that
it
can
stage
that
tunnel.
C
One
cannot
rule
and
SME
is
also
different
ways
and
they
eat,
because
the
SME
only
follows
the
traffic
in
the
watch
network
and
it's
never
terminate
it
in
abortion
network.
Yes,
okay,
let's
hit
any
comments
and
the
questions
are
also
welcome
and
the
way
we
refine
our
draft.
According
to
the
comments
after
meeting.
Thank
you.
M
To
as
well
make
few
changes
to
mechanisms
used
and
so
on,
so
so
we
go
over
that
in
the
next
slide.
So
next
slide,
please
so
as
a
background
for
SFC
service
function,
chaining
architecture
have
a
service
function,
training
group
have
defined,
and
in
cap,
which
is
network
service,
header
or
the
NSA
ching
cap,
and
that
in
cap
is
used
to
in
cap
package
that
has
to
travel
sewer
service
function
chain.
M
M
This
function,
this
function
chain
will
be
identified
as
I
mentioned
again,
with
service
pass
index
and
service
index
will
tell
us
which
hub
or
which
service
function
the
packet
would
be
inspected
by
as
it
traverses
a
service
function,
shape
that
calls
for
having
that
service
topology,
which
is
consisting
of
the
service
function
programmed
to
the
data
path
such
that
the
functionality
will
be
achieved.
So
in
here
in
the
Geneva
applicability.
M
We
are
talking
about
two
options
or
to
control:
do
control,
plane,
options
set
of
the
data
path,
so
the
first
option
is
simply
using
what
service
function.
Chain.
Architecture
would
call
for
sorry,
I
mean
little
option.
I
would
say,
are
both
compliant
to
the
service
function,
chain
architecture.
So
there's
no
divergence
here
to
the
service
functions
in
architecture,
so
it
can
be
done
with
easier
way
to
achieve
the
service
topology.
So
the
first
option
is
to
go
over
the
service
function.
M
Xin
pass
all
the
nodes
along
the
service
function,
chain
and
program,
the
SPI
and
the
SI
to
map
to
the
service
function,
so
that
that
means
that
if
I
have
multiple
service
function
for
order
connected
to
the
service
function,
I
have
to
go
to
every
service
function,
forwarder
and
programs.
Spi
SSI
and
programs
are
mapping
ORS
SPI
inside
to
the
service
function,
so
it
can
be
resolved
to
the
service
functions
and
being
forward
to
the
service
function
as
a
packet
traverse.
M
The
other
option
which
is
mentioned
in
the
draft
is
to
have
the
service
topology
information
programmed
only
at
the
English
spot,
where
you
have
the
policy,
for
example.
So,
typically
use
a
service
function
chain.
The
reason
you
are
doing
at
you
are:
you
have
a
policy
that
identify
certain
type
of
traffic
and
then
direct
that
type
of
traffic
to
the
service
function
shape.
So
so
we
are
saying
how
can
you
program
service
topology,
so
how
I
can
improve
that
policy
along
with
a
service
function?
M
Chain?
Information
at
the
ingress
point.
So
to
do
that
we
need,
at
the
ingress
point
to
identify
the
Horde
service
function,
meaning
have
the
list
of
service
function
IPS
that
we
need
to
go
su
as
that
over
the
a
packet
traverse.
The
service
function
shape.
So
this
is
as
an
option.
So
we
have
two
option.
One
option
is
to
go
over
every
single
hub.
M
Every
single
service
function
for
order
programs
are
mapping,
object,
spi,
identifying
service
on
Shan,
Shan
cell
viscosity
index
is
school
and
there
sigh
to
the
service
function
or
have
a
list
of
the
service
functions
that
we
have
to
set
the
packet.
The
customer
act.
Overlay
packet
has
to
traverse
adds
the
ingots
right.
So
those
are
the
two
option
mentioned
here
and
we
we
are
carrying
an
SH.
M
So
so
the
ink
app
is
going
to
be
carried
as
defined
by
the
SFC
goo
as
n
sh,
and
this
is
where
we
have
the
alignment
I
was
mentioning
about-
is
that
the
n
sh
did
I
have
the
SPI
on
CSI.
It
has
as
well
the
metadata
different
options.
Emitter
is
all
that
is
going
to
be
carried,
and
the
good
thing
is
the
Geneva
allows
that
to
happen,
because
in
Geneva
we
have
the
next
protocol
and
n
sh
has
already
have
defined
for
itself
and
ISA
any
subtype.
M
So
the
next
protocol
on
the
journey
would
be
the
NSHE
subtype
and
the
n
sh
protocol,
which
is
in
as
an
SH
header,
will
be
the
inner
packet
protocol,
which
could
be
Ethernet
an
Ethernet
packet
as
genève,
carries
and
that
packet
today.
So
next
slide
please.
So
this
is
mechanics.
You
know
we
are
talking
about
defining
a
new
option
TLB,
who
the
control
clean
option,
the
second
control
h
or
access
second
control,
clean
options
that
we
talked
about
on
the
fear
slide
on
which
we
are
putting
the
list
of
service
functions
that
we
have.
M
The
packet
has
to
traverse
okay,
so
this
is
only
explaining
the
mechanic
then
going
going
to
the
next
slide.
So
this
is
a
encapsulation
again.
It's
talking
about
how
the
genève
header
is
gonna,
have
the
next
record
and
as
an
accession
cap
which
has
a
base
header
set
of
Espace
header
and
the
context
headers.
So
this
is
how
the
cap
would
look
like
so
next
slide.
M
So
this
is,
you
are
taking
it
in
action
now,
so
how
are
we
gonna
do
it,
and
this
is
taking
in
action
with
what
we
described
at
the
beginning
as
the
control
plane
option,
two
in
which
we
have
that
SFL
or
service
function
list,
which
is
simply
an
option
TLB
with
the
IP
addresses
of
the
service
function?
So,
of
course,
with
that
option
we
are
only
programming.
The
SFL
adds
an
ingress
point
where
we
are
installing
the
policy
for
the
entry
to
the
service
function
shape.
M
So
so,
if
we
show
here
in
the
topology,
we
have
three
and
V
each
and
B
from
SFC
prospective
H
and
B
is,
is
identified
as
a
service
function
for
order
right,
but
of
course,
in
enviously,
those
are
nve's
or
network
virtualization
elements
so
H
and
V.
Here
we
have
C
and
V.
So
we
are
talking
about
service
function.
Shane
was
three
service
function:
okay
between
Xen
ve.
We
are
gonna,
be
using
genève
tunnels.
M
So
the
idea
here
is
that
the
policy
will
come
to
the
ingress
and
B,
which
can
act
as
a
classified
as
well
as
as
described
in
the
service
is
SFC
architecture
and
the
policy
will
say:
okay,
hey
you.
Are
you
a
packet
identified
by
that
classification
should
groove
our
service
function,
change
that
consists
of
the
three
service
function,
service
function,
one
and
two
and
three
so
what's
happening-
is
that
at
English
and
v
he
applies
a
policy
and
resolve.
M
What's
gonna
happen
is
that
he
is
going
to
remove
Zenith,
headed
and
he's
gonna
cash
or
create
a
stateful
state
mapping
the
SPI
where's,
the
current
si
on
on
the
packet
from
the
NS
a
cheddar
choose.
The
SFL
was
a
service
function
list,
so
it
can
be
sort
of
as
if
this
is
a
far
rule
state
or
a
stateful
caching,
of
a
mapping
between
an
SPI
like
a
contract
between
the
SPI
and
the
SF
al
or
the
service
function
list.
M
Then
he
of
course
he
is
like
regular
network
virtualization
work,
remove
the
network,
virtualization
header
or
the
genève
header,
and
sends
a
packet
where's.
The
NS
edge
header,
Tuesday
service
function.
Packet
will
come
back
with
an
edge
specifically
if
the
service
function
is
innocent.
She
where
there
are
as
an
option,
if
it's
not
an
asset
sure,
but
but
there
is
no
point
going
over
that
now.
M
So
since
the
pack
is
a
service
function,
when
the
packet
comes
back,
it
will
come
back
with
the
NS
h-has
in
having
the
SPI
and
having
their
size
so
and
firing
through
Zuzu's
SPI,
via
whatever
it
cashed
in
its
own
cache,
is
their
SFL.
So
it
can
regenerate
the
generate
tunnel
header
and
this
wall
can
find
the
next
service
function.
M
Test
was
who
now
the
packet
resolves
that,
via
the
network
virtualization
for
light,
sends
that
to
the
next
and
V,
who
is
gonna,
be
repeating
the
same
thing
until
we
each
the
egress
Envy
and
in
there
of
course,
whole
header
has
been
network.
Virtualization
is
gonna,
be
removed,
and
we
know
this
is
the
last
half,
and
now
we
can
deliver
the
packet
to
to
the
customer.
So
the
benefit
of
doing
that
is
many
things.
M
They
need
to
program
the
surface
topology
mapping
of
SPI
si
to
service
function
on
all
you
know
all
the
network
virtualization
domain
and
we
are
limiting
it
on
the
at
the
ingress
where
we
are
doing
the
classification
or
have
the
policy.
So
this
is
the
main
benefit.
Objet
approach,
as
I
mentioned,
that,
to
conclude
mean
approach
could
exist,
is
programming
the
service,
topology,
forwarding
tables
on
all
hops,
or
only
limiting
heir
to
the
English
point
so
going
to
the
next
slide.
M
H
M
M
We
have
that's
a
good
question,
that's
a
good
question
it
can.
It
can
resist
you
know,
depending
on
your
implementation
right.
So
here
we
are
talking
about
an
implementation
that
you
can
choose
to
optimize,
so
so
yeah
for
the
implementation.
You
could
could
have
it
resist
for
a
while
right.
You
know
it's
it's
as
if
you're
you
know,
if
you
have
the
implemented
power
rule
before
right.
So
so
you
create
some
flow
State
and
you
keep
the
flow
State.
M
M
H
H
I
H
M
C
J
H
B
H
M
H
I
B
I
Simple
question:
so
you
have
another
option:
class
defined
and
you
have
within
that
option,
option
class
the
ability
to
go
into
sub
T
obeys,
one
of
your
sub
T
or
visas,
H
mag,
and
that
sub
T
of
e.
Think
of
I.
Look
at
it
the
right
way.
It's
already
consuming
something
like
40
bits,
40
bytes
right
so
is
128
yeah
enough
of
a
length
for
you
or
do
we
have
another
use
case
where
kind
of
things.