►
From YouTube: IETF99-SFC-20170717-1550
Description
SFC meeting session at IETF99
2017/07/17 1550
https://datatracker.ietf.org/meeting/99/proceedings/
B
A
D
B
E
Can
tweet
you
hello
folks?
It
is
now
five
minutes
after
more
than
five
minutes
after
these
scheduled
start
time.
So
we
are
beginning
the
session
I'm
Joel
Halperin.
This
is
Jim
discharge,
where
the
chairs
are
thanks
to
Thomas
rahi,
who
will
be
officially
our
secretary,
but
it's
been
taking
notes,
eggnog
nerves,
who's,
also
taking
notes.
I,
sorry
I'm,
probably
mangled
your
last
name
again,
Ignasi
bad
at
that
and
welcome
everyone.
E
We
have
a
bunch
of
items
to
present
and
then,
as
we
said
on
the
list
time
for
open
discussion
of
what
the
thing
is,
people
believe
the
working
group
needs
to
work
on,
because
nsh
is
going
to
go
to
our
ad
very
shortly.
There's
like
one
more
item
to
fix
on
that.
The
note
well
is
here:
you
should
know
the
note
well
note
it
well
everything's
a
contribution.
E
Well,
we'll
go
through
the
agenda.
Sfc
OAM
got
a
series
of
presentations.
Carlos
is
gonna
start
by
giving
us
an
overview
of
where
the
framework
document
stands,
and
then
there
are
a
number
of
other
documents.
Adrian
will
then
talk
to
us
about
the
next
protocol,
nun
or
convent
draft.
There's
a
presentation
on
dynamic
service
chain
in
direction
and
then
we'll
be
on
the
reach,
our
Turing
and
other.
E
Maybe
topics
that
are
already
in
the
Charter,
but
we
haven't
done
whatever
you
guys
feel
needs
to
be
done
on
what
we'll
probably
do
is
use
the
left
hand
mic
to
introduce
topics,
no
my
right
hand,
mic
your
left
hand
mic
and
the
other
mic
for
any
follow-ups
on
a
topic
that
somebody
wants
to
bring
up
so
that
we
make
sure
we
discuss
one
before
we
move
on
to
the
next
agenda
comments.
Will
we
move
on
there's
the
agenda
in
more
detail.
F
Hello,
carlos
pignataro
Cisco
Systems
I'm,
going
to
talk
briefly
about
SFC,
OAM
and
essentially
were
we
being
where
we
are
on
the
forward-looking
plan
on
what
we
intend
to
do
with
Om
om
in
this
working
group
has
been
a
topic
that
was
interesting
because
of
because
of
two
somewhat
opposing
forces.
The
first
force
was
that
there's
a
lot
of
people
in
customer
requirements
that
are
fairly
fundamental
on
OAM
and
what
it
really
means
to
have
om
on
an
SF
see.
We
had
a
lot
of
early
discussions.
F
We
said
you
know
going
all
the
way
up
to
the
application
is
out
of
scope.
We
need
to
actually
test
and
do
various
OEM
functions
on
the
service
function
path
themselves.
On
the
other
hand,
side
there
has
not
been
too
much
of
a
deliberate
focus
on
it.
So,
even
though
we
said
as
a
working
group,
this
is
something
important
critical.
F
We
spend
our
time
and
cycles
on
the
architecture
then
follow
along
with
the
NSA,
and
a
number
of
odd
John
documents
like
Joe
was
describing
we're
at
the
point
in
which
the
NSA
chwe
document
is
getting
ready
to
be
sent
to
alia
and
because
of
that
or
in
preparation
of
that
nature
said.
Okay,
so,
let's
be
intentional
about
looking
at
OAM
again,
so
we
looked
at
the
landscape
of
different
OAM
documents
and
functions,
and
we
had
one
document
which
is
the
OEM
framework.
F
At
the
time
we
adopted
the
documents,
a
working
group
and
the
main
reason
for
that
was
because
we
wanted,
without
necessarily
have
the
destruction
of
a
lot
of
protocol
specifics
and
bits
and
bytes.
We
wanted
to
have
a
single
place
that
consolidate
the
overall.
Oh
I
am
thinking
before
diving
into
okay,
we're
going
to
do
these
for
performance
management.
We're
gonna
do
this
for
trace
frog.
F
We're
gonna
do
this
for
whatever
else,
so
the
time
has
come
now
to
actually
look
at
that
document
again
and
that's
something
that
we
did
in
the
past
month
and
a
half
order
about.
We
consolidated
that
document
was
actually
started
by
some
Aldrin,
some
Aldrin
on
the
very
very
initial
version
of
draft
Aldrin,
SFC
OEM
framework.
He
laid
out
exactly
that.
The
framework
of
you
know
copying
the
architecture
and
the
different
orientations
that
need
to
happen.
We
took
on
that
same
document.
F
We
did
all
the
editorial
updates
that
were
needed,
but
we
also
added
in
a
new
section,
which
is
you
know
the
main
topic
that
I
wanted
to
talk
today
and
that
main
section
is
actually
a
listing
of
the
currently
existing
or
or
within
scope.
Or
you
know
that
were
looking
at
om
tools
within
SFC
and
I'm,
not
sure
I
know
people
are
looking
there,
but
I
don't
have
any
slides,
so
I
wasn't
sure
if
there
was
something
interesting
being
projected
I
know
so
so
anyway,
be
the.
The
idea.
F
Right
now
is
to
take
that
at
the
anchor
point
for
the
OEM
conversation,
we
have
the
framework
the
functions
and
then
the
protocols
that
we're
evaluating
all
of
those
are,
you
know,
listed
and
in
particular
we
all
saw
these
at
the
very
bottom
of
the
document.
A
table
mapping
om
functions
to
AM
protocols
right,
so
we
have
a
section
on
the
functions
that
are
important.
We
have
a
section
on
the
protocols
and
we
have
a
matrix
that
is
essentially
correlating
one
to
the
other.
The
document
is
being
restarted.
F
Right
now
is
in
revision
tool
after
being
dormant
for
some
time,
so
they
they
plea.
The
request
is
for
people
to
look
at
it,
not
only
the
differences
from
the
previous
version,
but
rather
look
at
it
as
a
whole,
because
the
forward-looking
plan
is
to
use
that
as
a
anchor
point
for
om
and
from
there
potentially
how
we
do
some
additional
protocol
specifics.
That
document
is
not
defined
in
protocol
is
laying
out
the
framework
on
SFC
the
functions
unavailable
existing
protocols.
So
with
that
I'll
take
questions.
Okay,.
G
E
G
Greg
Mirsky,
is
it
e
I
have
one
concern
about
their
turn.
This
document
is
taking
the
document
in
scope,
states
that
specific
protocols
and
mechanisms
are
outside
of
the
scope
of
this
document,
and
even
though
it's
already
been
agreed
by
the
working
group
of
the
scope
of
the
document,
we
now
have
some
discussion
of
specific
protocols
getting
into
the
document.
So
I
think
that
the
gap
analysis
section
and
the
new
section
should
be
removed
from
the
document.
F
G
There
is
immediate
need
to
give
a
clear
definition
of
what
am
packet
is,
and
what
am
packet
is
not
so
I
think
that
if
we
extend
the
scope
of
the
document,
that
will
take
us
much
longer
to
get
this
definition
that
we
can
standardize
and
agree
on
and
keep
on
working,
so
I
would
encourage
keep
the
scope
as
being
originally
defined
and
concentrate
on
solving
immediate
need
of
the
working
group
so
and
keep
the
discussion
of
benefits.
Of
these.
Are
that
specific
protocol
and
mechanism
outside
of
this
document?
Thank.
F
You
for
the
comment
so
two
quick
follow-ups
to
that.
The
first
one
is
that
Greg,
when
you
talk
about
an
oem
packet
you're,
making
a
set
of
assumptions-
and
you
know
part
of
the
assumption-
is
that
there's
a
new
OEM
packet
for
SFC
when
you're
talking
on
the
second
part
of
your
comment
about
focusing
on
what
we
need,
we
time-to-market
and
I'm
paraphrasing.
F
G
G
H
Waldron,
if
we
don't
refer,
what
exactly
is
there
and
how
we
going
to
use
it?
It's
there
is
no
way
you
can
actually
reference
and
show
that.
Okay,
things
are
what
exactly
being
asked,
and
we
have
to
do
that.
Whether
we
are
not
prescribing
a
solution
here,
you're
just
describing
saying
that
what
is
out
there
and
if
at
all,
we
need
a
new
definition
of
an
OEM
or
packet,
feel
free
to
propose
a
solution.
If
you
don't
need
it,
that's.
H
F
E
G
G
G
Echo
request
echo
reply
and
when
we
look
at
it
is
that
we
look
at
that,
it
must
have
certain
information
included,
one
of
them
it
has
to
have
SFC
source
TV,
so
the
identity
of
their
note
that
generated
their
echo
request
so
that
echo
reply
can
be
properly
send
and
there
needs
to
be
allocated
a
unity
port
for
the
sender
are
to
listen
to
and
receive
the
echo
replies.
So
that's
a
two
updates
being
added
to
the
document
with
appropriate
Ayana
consideration.
G
C
F
E
C
I
Okay,
thank
you
and
Ana
for
affording
two
slices
about
her
SFC
pass
in
SF
c
om
and
the
first
is
return
pass
in
a
subsea
I
know
we
are
discussed.
We
are
discussing
about
sfk
direction
in
Minister
right
now,
but
in
this
science
we
are
assuming
that
as
a
key.
I
as
a
PID
is
the
direction
next,
as
we
know
that
om
has
foremost
to
control
the
parts
of
echo
reply.
I
I
Tooth
to
specify
our
reverse
direct
and
reverse
pass
in,
as
I
said,
wemmick
reply,
we
define
a
new
TR
v.
We
need
to
reply
service
function
here.
We,
the
theory,
is
in
echo,
request,
indicates
the
specified
return.
Sfp
and
the
following
part
are:
foreign
figure?
Is
the
permit
of
the
Uglies
theory
and
the
Tioga
contains
the
reply.
Past
reprise
service
function
pass
when
one
part
of
it
is
the
prior
service
past
identifier
and
the
other
is
services
servicing
in
death,
and
both
of
them
is
used
for
reverse
reverse
the
echo
reply
fording
next.
I
Here's
the
operation
of
the
SFC
OEM
with
specified,
return
pass.
First,
we
should
set
the
value
of
replay
mode
to
the
repair,
wow
specified
past
and
include
SFC
reply.
Past
year,
we
that
is
read
defied
English
charge
in
the
echo
request
message:
the
SF
key
ID
England
reply
past.
Here
we
should
build,
identify
our
return
pass
and
the
Nestor
once
the
once
the
I
want
to
reply.
The
echo
reply
and
the
echo
reply
should
be
used
as
a
PID
and
si
as
it
a
message,
a
header
and
you
will
return
as
a
P
count.
I
Find
company
find
the
alcohol
reply.
Shouldn't
include
replies
of
key
and
as
not
be
found
in
written
code,
and
if
the
repair
path
theory
is
not
provided
in
echo,
request
with
the
repair
well
specified
past
and
echo
reply
should
include.
The
repository
is
missing
in
occur
in
the
a
career
applying
written
code.
Yes,
and
that's
the
main
content
of
the
slides,
any
comments
and
questions
are
welcome.
I
I
I
This
is
the
comm
messages
we
defined
in
Java,
and
there
are
two
kinds
of
chapter:
why
is
the
say?
Om
request
and
and
eonni
is
z1
reply
and
comm
request
is
in
the
SFP
consistency,
echo
request.
It
should
be
sent
from
the
ingress
of
the
SLP
and
forwarded
by
every
ingredient
as
ffo
and
therefore
at
seorim
reply,
SFP,
consistent,
accurate,
prepare
every
SFF
for
is
receiving
and
see.
One
request
should
not
not
only
well
for
what
the
comm
request
but
on,
but
also
stand
back
on.
I
Comm
reply,
the
serum,
the
serum
reply
message
contains
the
information
of
SFO
that
is
connected,
the
true
the
SFF
and
just
last
night.
Previously,
yes,
and
the
figure
in
this
class
is
about
the
formation
of
the
sub
heavy
as
SF
a
SF
information,
and
there
are
some
information
about
SF
such
as
a
self
or
type
as
therefore
as
service
index
and
as
I
have
I.
I
did
hyper,
for
example,
ipv4
or
ipv6,
or
marriages
etc,
and
the
last
is
as
having
identifiers
used
to
identify
each
each
SF.
Next.
I
Here's
the
seorim
operation
from
this
video.
We
can
see
that
once
once
the
ingress
of
the
SS
he
sent
out
our
comm
or
request
every
intermediate
SF
in
this
as
a
key
should
forward
the
seolin
request
forward.
To
is
next
s
FF
and
in
addition
to
that
action
it
or
it
also
shouldn't-
send
out
serum
reply
to
send
out
a
serum
repair.
Back
serum
replying
contains
the
SF
information
letter
the
SF
are
connecting
from
this
figure.
I
I
G
So
what
we're
proposing
we
are
proposing
we're
describing
how
our
alternate
marking
method
can
be
used
to
measure
packet,
loss,
delay
and
delay
variation
and
mean
to
mean
delay
in
SFC
proposal
is
to
allocate
two
of
reserve
bits
in
a
nsh
basic
header
and
refer
to
them
as
a
mark
field,
and
one
of
the
bit
flags
will
be
used
for
single
mark
method.
Another
won't
be
used
for
double
mark
method.
We
can
go
next.
So
just
briefly,
single
mark
method
is
based
on
creating
a
batches
of
similarly
marked
packets.
G
D
G
Say
that
this
batch
has
a
color,
so
we're
switching
colors,
let's
say
red
and
balloon,
and
in
between
red
or
blue,
will
signify,
we'll
just
identify
the
packet.
That
will
be
very
easy
to
do
our
timing
and
then
our
this
information
can
be
collected
of
out-of-band
from
the
nodes
to
correlation
and
then
calculation
of
very
precise,
inaccurate
delay
and
delay
variation.
G
G
G
J
G
J
E
I
First,
the
way
I
want
to
state
my
questions
about
the
SSC
at
present.
Sfc
is
based
on.
They
are
transmitted
over
an
overlay
network.
We
can
see
that
in
NSS
chapter
section
7,
but
we
take
Geneva
as
an
example.
U.S.
FF
and
the
only
are
correlated
I
mean
he
knows
how
to
encapsulate
the
message
packet
with
an
overlay
header
and
the
forward
to
forward
it
shouldn't,
read
and
Vee.
So
that's
it
there's
no
problem
at
all,
but
if
the
full
situation
of
SF
and
MBE,
these
two
functions
are
splitted.
I
I
I
So
for
this
problem,
we
propose
to
our
message
that
first
specify
how
to
add
a
message
for
an
original
package
which
is
not
specified
in
each
chapter
right
now,
when
a
header
how
to
encapsulate
the
original
packet,
including
IP
header
or,
is
not
had.
This
is
suitable
for
SFF
and
a
mean-spirited,
and
next
one
we
propose
is
well
as
ff5.
The
next
next
hope
in
SFC
issued
fabulous
hope,
adjust
according
to
it
as
a
PID
in
sfz
header
of
the
packet
and
then
for
replace
the
destination
destination.
I
G
Well,
that's
basically
in
the
first
presentation
in
our
multi
model.
Is
that
OAM
again,
here's
the
question
is:
what
do
we
understand
is
Orion
tech?
If
we
understand
or
am
packet
as
77
99,
the
packet
is
specifically
constructed
for
the
test
purposes
and
generated
in
the
sec
domain
and
consumed
an
SMC,
the
main,
then
our
proposal
is
that
end-to-end
om
in
SF
c
is
done
on
SFP,
so
classifier
and
SFX.
G
G
H
G
Know
it
in
touch
itself,
as
it
can
basically
they're
active
om.
That
goes
as
a
vom
doesn't
have
to
touch
a
cell
because
you
can
go
SFX
and
if
you
have
requests
for
information,
as
indicated
in
the
presentation
that
thing
done
on
consistency.
So
this
information
can
be
obtained
from
a
set
by
SFF
and
reported
back
to
their
sensei.
G
G
E
J
Of
repeat
the
question:
I
had
before
you've
got
only
a
few
bits
and
you
seem
to
be
only
using
one
Oh
at
doing
one
OAM
measurement
in
a
packet.
If
you
made
it
any
numerator
one,
two,
three,
four,
five,
six,
seven,
you
would
be
less
likely
to
run
out
of
bits
than
having
one
bit
of
function.
It's
just
as
hardware
friendly.
No
again.
G
L
Deployment
SFC,
we
think
the
management
is,
can
be
divided
into
three
parts
and
the
underlay
network,
or
management
and
application
monitor
and
the
layer
many
mate.
So
in
the
front
two
parts
we
have
many
choose
to
manager
the
these
two
parts,
but
in
the
SFF
management
we
have
no
our
few
tools
to
manage.
So
we
think
it's
very
important
to
discuss
the
sfm
and
mentoring
group.
L
G
K
Wow
so
following
up
Sam's
question-
and
please
tell
me,
I
wasn't
listening
if
I
miss
something
here,
it
sounded
like
the
proposal
was
that
we
would
trace,
through
an
SF
c
s,
FF
by
s
FF
and
not
traced,
to
see
whether
a
specific
SF
had
been
called
in,
and
that
worries
me
when
SF's
can
be
remote
from
s
FF
s.
So
if
there
tunnel
attached
that.
E
K
G
Okay,
yes,
it's
it's
a
variant
question
and
in
a
consistency
or
a.m.
draft.
What
we
proposing
is
that
our
the
query,
the
echo
request
that
comes
to
SF
f
triggers
some
mechanism
to
query
SF
f,
the
query
mapped
SF
that
belongs
to
this
SF
c
and
then
report
it
to
the
query.
But
it's
not
necessarily
the
same
packet
that
has
to
traverse
as
a
theft
yourself.
So.
E
Jim
just
pointed
out
to
me:
the
other
path
is
the
in
ban
in
situ
o
a.m.
approach,
which
does
go
through
these
the
service
functions,
but
that's
a
those
are
a
different
set
of
tools.
These.
These
are
a
set
of
tools.
They
are
suggesting
not
the
only
tools
that
we
that
we
as
a
working
group
are
allowed
to
consider.
In
fact,
one
of
the
things
have
to
here
in
just
a
few
minutes,
but
we
got
two
more
presentations.
First
is
what
other
L
AM
work?
M
I'm
actually
just
I
had
one
comment,
but
I
want
to
answer
that
one
so
I
think
there's
also
the
interface
between
FFF
and
SF.
In
this
case
there
might
be
issue
with
low
balancing
right.
You
may
have
multiple
SF
instances
right
that
you
have
to
deal
with
so
the
whole
om
of
confirming
your
service
path
or
as
I've
see
in
this
case.
Fights
have
to
take
that
into
account
as
well.
But
else
is
more
of
a
comment.
Anyways
I
came
for
a
different
question
was
for
Kings
presentation.
M
E
E
By
the
issue
and
the
nvd
network,
virtual
overlaying
issue
is
a
somewhat
more
complicated
issue
and
since
you've
asked,
let
me
comment
that
the
real
key
there
is
the
service.
The
SFF
sees
is
an
Ethernet
service.
It's
going
to
address
things
from
the
Ethernet
perspective.
That's
all
we
as
an
SF,
see
working
group
can
deal
with
the
question
of
how
and
nve
delivers
and
receives
an
Ethernet
frame
delivers
an
Ethernet
frame.
That's
the
network,
virtualization
overlays
problem,
not
that's,
delivering
an
Ethernet
service,
not
necess
aproblem.
E
So
from
SF
C's
perspective,
the
service,
the
transport
that
the
SFF
sees
is
whatever
service
the
overlay
provides.
When
the
overlay
is
co-located,
then
the
SFF
may
be
aware
of
the
of
the
overlay
and
be
working
more
closely
with
it,
but
otherwise
it
just
uses
the
overlay
as
every
other
entity,
the
overlay
and
that
works.
It
creates
more
layers
of
overlay,
but
it
still
works.
So
there's
different
kinds
of
assumptions.
E
People
make
some
people
assume
the
SFF
will
be
closely
coupled
with
the
NVE,
in
which
case
you
can
get
one
kind
of
behavior
and,
as
you
validly
point
out,
it
does
not
have
to
be
closely
coupled,
in
which
case
the
SFF
simply
works
in
terms
of
whatever
the
service
provided
by
the
overlay
is,
which
may
be
an
Ethernet
service.
And
it
then
it's
C
NS
H
over
Ethernet
right.
M
I
want
to
get
too
long
into
it,
but
I
thought
things
point
if
I
was
trying
to
understand
it
too,
but
if
it's
going
over
native
IP
I
think
that's
maybe
an
issue
right
so
because
we,
like
you,
said
we're
going
over
any
overlay
right.
If
it's
your
year,
NSHE
p,
vs,
9
GP
year
or
Ethernet,
that's
all
supported
by
thing
going
over
a
native
IP
I.
Don't
think
we
support
that
and
I'm,
not
sure
that
was
your
point.
But
anyways
I
can
pick
that
offline.
K
K
So,
what's
going
on,
what
we
know
about
metadata
is
its
carried
in
the
N
SH
and
that
we
insert
the
NS
h
between
the
forwarding
header
and
the
payload
packet.
So
metadata
can
be
sent
whenever
there
is
user
data,
traffic
and-
and
the
question
I
was
asking
myself
is
what
happens
if
there
is
currently
no
user
data
packet
in
hand?
In
other
words,
there
is
no
packet
going
down
the
SFC,
but
I
want
to
push
metadata
I
want
to
program
if
you
like
the
SFC,
what's
the
metadata.
K
K
So
our
proposal
here
is
to
say:
let's
use
zero
to
mean
none
and
it's
protocol
is
none.
It
means
there
is
an
NS
H,
but
there
is
no
user
data
following
the
NS
H,
and
this
gives
us
the
opportunity
to
send
packets
containing
metadata,
but
no
user
data.
So
we
can
push
metadata
around
the
network
without
having
to
wait
for
a
packet
and
it's
slided.
K
K
If
I
could
dance
I
would
at
this
point
just
to
keep
you
entertained.
I
could
sell
you
a
book
of
fairy
stories
and
about
that
right.
Use
cases.
Use
cases,
of
course,
are
not
limited
to
my
imaginations
there.
Anything
you
want
to
do,
but
I
think
there
are
a
couple
of
things.
Metadata
may
apply,
apply
to
a
whole
SFC.
So
it's
something
you
push
through
and
say
any
packet
on
this
SFC
now
here
is
the
metadata.
All
you
might
push
it
through
for
a
flow.
K
So
today
you
would
say:
I
wait
for
a
packet
and
user
data
packet
and
I'll
I'll
attach
the
metadata.
What
this
allows
you
to
do
is
just
send
it
when
you're
ready
to
send
it-
and
this
is
similar
to
some
proposed
and
I-
think
meds
control
plain
draft
talks
about
this,
where
you
would
install
metadata
out-of-band
using
some
management
protocol
or
on
Netcom
for
or
whatever
to
push
metadata.
So
this
is
pushing
it
horizontally
rather
than
pushing
it
from
a
controller.
K
It
also
allows
you
to
communicate
between
SF
is
so
they
can
coordinate
with
each
other,
which
I
think
quite
often
they
need
to
do,
especially
in
the
security
world,
or
it
allows
you
to
build
a
control
and
management
channel
through
your
service
function,
overlay
and
obviously,
if
I
mention
our
a.m.
then
we
can
all
start
throwing
food.
So
I
won't
mention
OAM
at
all,
not
even
slightly
what
is
specifically
not
a
use
case.
K
I
believe
is
per
packet
metadata
and
by
that
I
mean
metadata,
that
it
might
be
computed
on
a
packet
somewhere
in
the
network
applies
to
that
packet.
Only
and
then
the
next
packet
along
uses
different
metadata,
so,
for
example,
a
hash
it
falls
into
that
category
and
that
if
you
had
a
set
of
pre-installed
metadata's
like
a
whole
field
at
the
table,
then
you
could.
You
could
use
this
approach
with
by
by
putting
an
index
in,
but
personally
I
wouldn't
go
there
and
it
slide.
I
will
come.
K
K
So
what
we
think
is
s
FF
s
forward
packets,
even
if
they
don't
understand
what
the
next
protocol
is,
because
they
don't
look
into
those
fields.
Sfc
proxies
are
responsible
for
only
delivering
packets
that
there
I
serve
eyes
know
how
to
handle
so
they
would
drop
the
packets
if
they
don't
understand
the
next
protocol
and
SFI.
Is
that
our
SFC
aware
would
be?
Would
it
fall
into
the
same
category
except
possibly
you
could
configure
them
to
say.
K
If
you
don't
know
what
the
next
protocol
means
just
return,
the
packet
to
the
SFF
but
I
think
that's
unwise,
especially
in
Security
implementation,
so
I
would
expect
them
to
drop
the
packets
reclassify,
as
similarly
I
would
expect
them
to
drop
packets,
because
reclassification
is
about
knowing
about
the
payload.
And
if
you
don't
understand
the
next
protocol,
you
don't
understand
the
payload
right,
discuss,
I'm,
not
gonna,
stand
up
here
when
you
discuss
it
so.
C
K
G
K
E
F
Sisqó,
could
you
please
go
but
I
think
it's
one
slide
here
to
a
use
cases.
So
first
I
find
this
very
useful.
I
have
a
question
on
the
first
bullet
Adrienne
when
you
say
press
FCM,
per-flow,
metadata,
I'm,
not
sure
you
understand
what
you
mean
by
per
flow,
you
could
potentially
have
multiple
payload
level
flows
so.
K
A
payload:
where
are
you
getting
flow
right
so
so
the
question
could
be
how
do
I
understand
which
flow
this
metadata
applies
to
when
it's
coming
along
without
news
of
data
and
the
answer
is
you
need
to
put
some
information
in
the
packet
that
indicates
it?
Okay,
so
there's
a
no
AM
packet,
it's
drop
method,
so
there's
some
metadata
packet.
It's
got
metadata
in
its
intended
to
apply
just
to
a
sub
flow
on
the
SFC.
You
had
better
put
the
identification
of
that
sub.
Oh
you.
F
K
C
O
K
And
when
I
first
wrote
this
document,
there
was
a
hope
that
the
NS
h
Draft
would
pop
out
soon
and
I
believe
they
still
I
hope
that
the
NS
hjf
will
pop
out
soon
and
I.
Don't
want
that
discussion
just
to
slow
down
the
NS
age,
but
you
needs
to
be
documented,
so
I
don't
mind
where
it's
documented.
Yes,
it
should
be
documented,
yeah
s
what
I'm.
K
G
M
Know
my
name
is
hard
to
spell
that
L,
eun-ji
and
spell
it
out.
So
my
question
here
is
passion
of
flow
metadata.
Is
that
how
would
the
SFF
you
know
today?
You
have
multiple
instance
set
at
a
hot,
possibly
right,
so
we
can
low
balance
it
right
through
based
on
a
flow
information
right,
which
is
the
user
data.
In
this
case,
there's
no,
you
Lydia,
there's
only
metadata
nsh
metadata,
which
is
bypassed
by
your
s,
FF
right.
Basically,
so
I
don't
quite
understand
the
details
of
how
you
support
per
flow
metadata.
In
this
case.
C
K
M
K
M
E
Mentioned
two
things:
right:
I
put
it
differently:
okay,
the
way
the
use
cases
will
use
the
the
next
protocol.
None
will
have
to
be
documented
in
individual
drafts.
It
isn't
nothing.
This
document
isn't
going
to
tell
you
how
to
send
metadata
to
everybody
that
will
automatically
be
understood
because
until
you're
describing
the
use
of
it
and
what
you're
gonna
ship
there's
no
point.
So
the
use
cases
are
illustrative,
they're
not
fully
specified
and
let's
not
get
hung
up
on
trying
to
elaborate
on
all
of
the
things.
E
K
M
M
E
H
Hello,
everybody,
I'm,
Debashish,
podcaster
and
I
will
go
through
this
use
case
so
before
starting
the
motivation.
So,
as
we
see
today
like
a
lot
of
this
5g
applications
and
with
them
comes
the
low
latency
requirements
are
forcing
a
lot
of
this
service
providers
to
push
functions
as
well
as
network
functions
towards
the
edge
of
the
network,
for
example
mobile
edge
computing.
So
with
this,
this
handling
of
user
mobility
and
also
the
non-deterministic
availability
of
compute
and
storage
resources
is
extremely
challenging
at
the
edge
of
the
network
as
well
as
within
the
network.
H
So
what
it
requires
is
a
very
dynamic
and
fast
switching
of
service
path
between
service
functions,
which
is
also
known
as
this
service
in
direction.
If
we
move
on
to
the
next
slide,
please
so
in
SFC,
the
way
service
indirection
is
handled
is
using
this
nsh
control
plane
protocol,
where
we
have
the
service
path,
identifier
and
their
service
index.
So
basically,
by
changing
this
service
path,
identifier
and
the
service
index
service
in
direction
or
service
like
the
path
is
changed
and
typically
at
a
particular
node
as
a
packet
arrives,
the
policy
manager
is
contacted.
H
The
current
classification
is
validated
and
if
it
is
not
valid,
it
is
called.
The
process
is
called
true
declassification
which
goes
ahead
and
changes
the
SPI,
and
then
it
is
forwarded
back
to
the
forwarder
SFF.
If
we
go
to
the
next
slide,
please
now,
in
order
to
improve
this
indirection
function
like
we
agree
that
this
indirection
mechanism
in
SFC,
through
this
classification,
definitely
can
handle,
but
it
may
not
be
suitable
for
this
dynamic
indirection.
H
So
this
in
this
use
case,
the
proposed
SLR
service
form
it
kind
of
provides
an
additional
method
to
handle
dynamic
in
direction
of
service
request
without
completely
relying
on
the
reclassification
mechanism.
So
we
see
it
like
initially,
those
two
techniques
can
be
combined,
but
as
well
as
this
whole
SLR
function
can
also
act
independently
to
provide
dynamic
service
in
direction.
H
So
this
proposes
our
function.
What
it
does
is
typically
decouples
the
service
consumer
and
the
service
endpoint,
and
some
of
the
desired
features
in
terms
of
like
very
fast
switching
from
the
consumer
to
the
service
endpoint,
and
it
not
only
relies
on
layer,
3
protocols
or
layer,
2
approaches
like
DNS.
You
also
can
use
direct
path,
mobility,
avoiding
the
use
of
anchor
points,
as
we
see
today,
and
also
in
direct
service
requests
directly
at
the
network
level
and
new
methods
for
forwarding
such
as
path
based
forwarding
and
direct
path
routing.
H
So
this
is
the
the
proposed
s,
error
function,
which
is
inserted
between
the
consumer
and
the
service
provider,
which
tries
to
decouple
the
the
service
forwarding
and
which,
which
basically
provides
the
complete
flexibility,
and
it
also
shows
the
case
where
a
cerrar
is
basic
is
acting
independently
between
the
consumer
and
the
service
provider.
If
we
go
to
the
next
slide,
please
so
just
to
get
into
little
bit
details
about
this.
This
kind
of
deployment
where
the
asari
is
acting
individually.
H
So
we
have
a
scenario
where
a
service
consumer
is
basically
is,
and
the
service
provider
SC
and
SP,
and
we
have
our
single
SC
being
serviced
by,
for
example,
multiple
or
more
than
one
service
providers
or
say
n
virtual
instances.
So
we
are
assuming
that
a
service,
consumer
or
SC
is
changed
to
a
service
provider
one
first
and
then,
if
we
need
to
explicitly
reclassify
towards
SP
n
with
some
out-of-band
decision
about
which
end
to
pick
now
with
the
introduction
of
SR
as
we
decouples
the
consumer
and
the
provider.
H
Now
single
se
can
be
connected
to
multiple
service
provider
and
what
we
see
that,
with
this
kind
of
the
requirements,
we
assume
that
it
may
not
require
a
little
ossification
and
based
on
instantaneous
decision.
It
can
switch
the
traffic
flow
to
any
of
the
airspace
next
slide.
Please.
So
so
that's
the
kind
of
the
use
case,
but
we
we
proposed
here.
H
H
E
Ok,
so
now
it's
discussion,
sorry
now
it's
up.
It's
working
group
members
bringing
up
items
that
they
would
like
to
see.
The
working
group
discuss
and
yes
Greg
you
can
bring
up
whatever
L
am
issues
you
want,
but
you're,
not
the
only
one
but
I'd
like
to
do
is
each
topic
gets
brought
up
and
then
there's
discussion
of
the
topic.
So
Carlos
you
don't
bring
up
a
topic
over
there
because
otherwise
we'll
get
really
confused.
They
don't
want
people
shuffling
a
line
so
go
ahead.
Tom.
N
Thomas
rahimova,
so
I
want
to
bring
up
the
issue
of
M
D
type
1.
Originally,
the
way
n
SH
was
defined
was
with
empty
type
1,
as
kind
of
an
opaque
metadata
that
can
be
used
for
anything,
and
then
a
few
drafts
came
up
that
defined
different
formats
from
D
type
one.
Some
of
them
have
expired
and
actually
I
don't
know.
What's
going
on
with
those,
some
of
them
are
still
there
on
the
documents
page
of
SF
c.
N
So
one
way
to
go
would
be
to
not
to
adopt
any
of
these.
These
documents
just
to
leave
MD
type
one
up
to
the
operator
or
up
to
the
vendor
or
whatever
another
way,
would
be
to
choose
a
subset
of
these
MD
type
one
formats
and
to
say:
okay,
we're
going
to
adopt
these
other
solutions,
maybe
up
to
the
operator
or
up
to
the
vendors
or
whatever
and
another
way
would
be
to
say.
N
Okay,
we
have
we're
going
to
have
a
single
document
that
is
going
to
define
all
the
MD
type
one
formats
that
we're
going
to
support
and
other
MD
type
one
formats
are
currently
not
supported.
So
I
don't
know
the
I
think
these
are
all
the
possible
options.
Maybe
there
are
intermediate
options,
but
I
think
it's
important
to
decide
which,
where
we're
going,
because
right
now,
it's
not
very
clear
what
is
going
on
with
these
different
proposals,
whether
they
will
ever
be
adopted
or
whatever
you're.
C
C
N
I
think
that's
we.
We
have
discussed
this
point
during
the
last
ITI
interim
meeting
and
the
at
least
the
consensus
we
reached
among
the
participant
of
the
entry
meeting
that
it
is
valuable
to
document
the
MD
type
one
as
informational
RFC
and
the
authors
of
the
document
are
invited
to
come
to
the
working
group
and
proceed
easily
with
the
adoption,
so
that
we
can
facilitate
that
implementers
are
aware
of
the
specification,
so
I
think
that's
it.
N
C
N
Exactly
not
only
for
that,
but
also
because
yeah
it's
it
helped
from
pre
matters.
If
you
want
interoperability
and
if
we
don't
really
exact
specifications,
I
think
there's
some
problems
that
we
will
be
out
there.
So
it's
I
think
it's
it's
harmless
to
need
to
leave
it
as
it
is
today,
but
it's
I
think
we
have
a
value
to
document
it.
This
is
for
indie
type,
one
for
any
type
to
it's
another
story:
Tina's.
E
F
We,
we
spend
significant
amount
of
time,
revamping
the
document
to
get
it
to
revision.
14
there's
been
many
many
comments
on
the
list
on
the
thirteen
and
in
particular
many
things
to
human
for
the
very
comprehensive
review
that
held
the
document
a
lot
from
where
I
saw
things.
As
of
this
morning.
The
document
was
ready.
Joel
reminded
me
that
there's
one
additional
question
for
the
working
group
in
regards
to
allowing
explicitly
disallow
in
permitting
etc
hybrid
MD
types
within
an
SSP,
meaning
NSF
receiving
MD
type
one
and
send
him
an
MD
type
to
our.
F
C
N
I
do
think
there
can
be
this
currently
stable
compared
to
previous
versions.
I
think
there
is
a
good
work
that
has
been
done
on
this
sound
specifications
but
back
to
the
Adrienne
question
like
if
there
are
some
void,
ASCII
data
are
still
in
in
the
specification,
so
I
would
just
give
an
example
if
we
dig
deeper
session
from
Adrienne
about
the
specification
of
the
null
value
for
us.
For
me,
if
you
are
in
a
normal
world,
I
would
take
the
text
from
the
Adrienne
Draft
and
put
it
in
D
in
a
safe
document.
N
This
is
the
normal
I
would
proceed,
but
it's
up
to
us
as
a
working
to
decide
whether
this
will
delay
the
initial
specification
or
not
and
another
that
we
are
in
I,
don't
know
if
we
delay
the
sending
the
document
really
by
two
or
three
weeks
in
order
to
handle,
for
instance,
the
integration
of
the
null
null
value
in
Indonesia's
document
at
I
would
I
would
prefer
that
path.
There
is
another
item
which
is
not
can't
Francis.
N
If
you
go
to
the
document,
you
will
see
that
the
value
0
are
reserved,
but
there
is
no
justification.
Why
these
values
for
us
are
reserved
there
and
what
will
be
the
behavior
of
the
implementation
if
this
kind
of
value
shows
up
this
kind
of
stuff,
I
I
think
that's
their
only
manual,
but
I
think
that
it's
really
worth
to
go
through
the
document
and
to
say
if
there
are
a
value
which
is
not
specified
on
the
document.
What
will
be
the
behavior
of
the
implementation?
N
I
already
seen
the
pointer
in
the
mailing
list
too,
to
remind
that.
This
is
an
open
issue
that
we
have
since
the
interim
meeting.
It's
up
to
us
to
decide
whether
we
enjoy
it
or
not.
But
I
didn't
heard
an
answer
from
your
side.
So
so
it's
just
filed
baby.
If
you
want
to
proceed
and
to
progress,
the
document
but
I
think
it's
just
pity
to
to
not
wait
for
one
or
two
weeks
to
fix
for
us
identification
of
the
Adrienne
text
in
the
intogen
attached
and
this
kind
of
final
check.
But
it's.
F
C
C
So
don't
we
don't
want
to
go
round
around
in
circles
any
longer?
It's
been
long
enough,
but
I
do
think
and
and
I
know,
Joel
agrees
with
me.
If
you
can
provide
specific
text
for
Adrienne's
points
that
he
made
in
his
presentation.
I
would
agree
that
makes
sense
to
add
that
to
the
document
and
with
the
editor,
but
we
want
to
see
specific
text
and
we
want
to
see
it
like
soon,
because
this
document
is
being
going
for
way
too
long.
Yes,.
N
F
E
Had
a
bit
of
oh
I,
just
thought
of
another
issue:
oh
I,
just
thought
of
another
issue.
Well,
I
know
through
lots
and
lots
of
documents,
you
can
always
think
of
another
issue
in
almost
every
document.
I've
turned
out
so
but
well.
If
we
can
get
it
quickly,
we'll
put
it
in
Kent.
Now
your
next
next
topic,
yeah.
M
New
topics-
I'll
bring
up
beans,
there's
been
a
lot
of
email
discussions
on
Ronaldo's.
You
know
reverse
packet
generation,
so
you
know
I've
been
trying
to
collect.
You
know
basically
and
get
some
rough
consensus,
because
I
think
we
should
revise
that.
You
know
with
a
Sanders
approach
that
everybody
can
start
implementing.
You
know
interoperable,
so
I
think
probably
most
people
have
seen
some
of
the
emails,
but
I
think
we're
down
to
these
two
options
are
the
initial
four
that
was
in
the
draft
and
I'm
I.
M
Don't
want
to
rehash
all
the
discussions
here
to
obviously
I
think
people
understand
the
trade-offs.
Basically,
one
option
is
using.
You
know
awesome
right
so
for
people
here
I
what
this
call
it.
One
option
is
using
SBI
and
as
I,
basically
as
a
way
of
showing
both
directions,
your
flows
or
two
flows
for
a
connections
example,
and
the
second
option
is
basically
SBI
in
the
case.
M
Basically,
the
flow
Y
was
the
direction
each
one
for
each
direction
of
the
connection
right,
so
we're
basically
down
to
those
two
and
basically
you
know,
discussion
seems
like
I,
see
more
meaning
tour,
though
second
one
second
option
they
say
right
now:
I,
don't
know
what.
How
should
we
get
some
kind
of
so
I
think
right.
Let's.
C
G
G
Active
I
am
in
hybrid
I
am
so
the
active
I
am
is
then,
when
we
generate
a
Content,
a
packet
message
and
we
send
it
down
to
the
SFC,
and
this
packet
is
generated
in
the
domain
and
terminating
to
me
in
a
hybrid
om,
we
add
on
or
insert
some
information
into
NSH
or
into
the
packet
that
has
om
use,
that
that
will
be
hybrid
or
am
so.
The
question
from
my
side
to
me
is
that
what
oh---but
is
signifies
when
the
obit
is
set?
Does
it
signify
active
forum?
E
What
we've
written
in
the
document
and
what
the
working
group
worked
over
very
extensively
and
reached
agreement
on
is
that
the
öbut
being
set
means
there
is
a
a.m.
significance
here
that
is
Meos
relative
to
nsh.
It
doesn't
tell
you
where
to
find
it,
it
doesn't
tell
you
what
the
processing
is.
It
tells
you.
This
is
gonna
need
special
processing.
If
you're
not
prepared
to
do
some
special
processing,
then
you
probably
better
drop
this
on
the
floor,
because
you're
not
going
to
do
the
right
thing.
E
E
Do
we
want
to
have
two
mechanisms
or
one
mechanism
for
how
we
represent
some
of
this
stuff
or
three
mechanisms
or
seven
I
mean
we
can
make
up
lots
we're
good
at
that,
or
should
we
say
there's
only
one,
and
that
is
a
topic
for
the
OAM
framework
document
that
is
being
worked
on,
not
to
mandate
the
mechanism,
but
to
talk
about.
Do
we
need
there
to
be
a
single
one,
or
do
we
need
multiple,
that's
something
we
can't.
E
The
framework
document
can
very
well
address,
but
all
that
the
nsh
document
is
telling
you
is
there.
So--But
says
this
packet
needs
OAM,
processing,
this
nsh
packet.
This
thing
you
are
getting
after
that.
You
need
to
know
something
else
to
know
how
to
do
it.
It
doesn't
tell
you
how,
because
we're
not
going
to
mandate
and
nsh
a
debate
that
is
clearly
going
to
take
many
months
before
it
converges.
Well,
it
is
our
job
as
chairs
to
drive
it
to
convergence,
but
it's
not
going
to
happen
quickly
right.
G
Okay
Joe.
Thank
you
for
helping
me
to
state
the
question
more
clearly
so
again
from
point
of
active
om.
There
are
two
options:
one
option
is
to
include
it
in
a
payload.
Another
option
is
to
use
our
protocol.
None
that's
protocol,
none
and
then
include
metadata.
The
hybrid
om
is
clearly
goes
in
the
metadata,
so
in
both
cases,
if
actually,
if
all
three
cases
are
signified
by
single
or
M
bit,
mm-hmm.
E
E
If
we
agree
on
the
mechanisms,
if
we
agree,
there's
one
or
we
agree,
there's
three:
it
doesn't
matter.
If
we
agree
on
the
mechanisms,
then
hardware
which
supports
the
mechanisms
will
be
able
to
be
triggered
by
the
presence
of
the
öbut,
even
if
there's
multiple
mechanisms,
if
there,
if
we
agree
on
there
being
only
one,
then
the
hardware
triggers
only
one
from
the
open
with
the
obut
is
not
the
full
solution.
We
understand
that
it
is
not
a
full
answer.
E
You
cannot
build
hardware
which
will
do
OAM
from
just
the
obit,
because
you
have
no
idea
what
to
do.
All
you
can
do
is
put
a
hook
in
your
hardware
that
says
I
better
design
it
something
can
kill
it.
I
can't
get
around
that
because
we
haven't
got
agreement.
I
can't
just
magically
declare.
Here's
where
you
put
it
in
the
hardware.
Neither.