►
From YouTube: IETF103-SFC-20181108-1350
Description
SFC meeting session at IETF103
2018/11/08 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
No
I
thought
I
sent
it
to
your
Gmail,
how
PhD
I'm
holding
it.
Yes,
it
works,
so
we're
good.
We
just
need
to
switch
things
when
we're
done.
Okay,
folks,
it
is
now
four
minutes
late,
I'm.
Sorry,
you
are
in
the
SFC
working
group,
somebody
at
the
back
of
the
room,
please
close
the
door
truth.
Thank
you
and
welcome.
A
This
is
I'm.
Troll
Halpern
came
to
get
chard,
Tom
Mizrahi
note.
Well,
apparently,
my
note
well
doesn't
fit
well
on
the
slide.
This
is
the
note.
Well
and
actually
all
the
text
you
need
to
know
is
right
there
what's
missing
is
just
a
heading
that
says
note
well
so
there
you
have.
It
remember,
read
if
you
have
managed
to
get
this
far
into
IETF
week
and
have
not
read
the
note
well
I'm
impressed.
Please
go
read
it.
It
matters.
A
Streaming
jabber
with
the
agenda
first
working
group
status.
What
has
changed?
Rfc
84
59
has
been
published
as
an
RFC.
Congratulations
to
the
authors
and
the
working
group.
We
adopted
the
the
multi-layer
OEM
document.
My
thanks
to
the
authors
and
the
working
group
for
speaking
up
note
that
there
does
need
to
be
alignment
between
that
work
and
the
OEM
framework.
It's
not
like.
We
can
produce
two
incompatible
sets
of
OAM
information.
A
The
chairs
will
get
really
upset
if
the
working
group
members
try
to
do
that.
So
it's
up
to
the
working
group,
where
the
fixes
go,
how
you
get
the
alignment
to
emerge.
The
two
documents
do
we
have
to
fix
things
in
one
document
or
the
other,
but
we
have
to
end
up
with
consistent
descriptions.
It
is
not
acceptable
to
end
up
with
inconsistent
ones
and
they're,
both
now
working
group
documents.
The
working
group
owns
the
content,
so
that's
the
membership.
A
A
Well,
if
we
have
to
we
rearranged
the
agenda,
we
will
then
be
if
he
isn't
back,
then
Frank
will
go
first
with
the
I
would
be
in
situ.
L
am
work
that
he's
presenting
and
which
is
two
different
things:
the
in
situ
overall
and
the
proof
of
transit
and
I'd,
be
surprised
if
it
took
all
twenty
minutes
even
to
cover
both
of
them.
But
that's
how
much
time
we
had
then
Donald
will
be
talking
about
explicit
congestion
notification
and
then
Sammy
well,
I
think
Sammy
would
be
here.
A
Thank,
You,
Sammy,
yes,
we'll
be
talking
about
the
carriage
of
SFC
over
genève,
and
we
appreciate
their
work
on
making
that
an
available
transport
for
the
problem
and
then
ting
we'll
be
talking
about
path,
o
a.m.,
and
that
is
the
end
of
the
agenda.
Does
anybody
need
to
bash
the
agenda
hearing?
No
one,
we
will
proceed.
You
want
to
pull
up
Frank's
Frank.
C
C
So,
looking
at
the
encapsulation
draft
for
iom
data
fields
over
nsh,
there
weren't
a
load
of
comments
and
there's
not
really
been
changes
since
then,
which
is
why
we
didn't
update
the
draft.
So
since
I
wrote
this
slide,
I
got
a
few
Commons
and
saying:
well,
you
need
to
update
these
references
and
by
the
way
you
need
to
reduce
the
author
list
to
less
than
five.
So
they
we
need
to
move
the
authors
into
the
subsection.
That's
all
fine,
so
we're
gonna
go.
Do
that
in
an
o1
version.
C
We
had
a
prior
kind
of
individual
draft
for
a
very
same
thing
when
we
prior
to
adopting
the
whole
thing,
so
it's
been
pretty
stable
and
it's
sweet
and
short
because
basically,
what
we're
asking
for
is
a
KO
point,
and
so
I
just
want
to
go
and
get
a
sense
of
well.
What
else
do
we
need
to
go
and
put
in?
Please
speak
up,
because
otherwise
we
might
be
pretty
rapidly
progressing
to
working
group
last
call
because,
as
I
said,
it's
sweet
and
short
any
thoughts
on
that
for
Joel.
We
have
note
of
time.
A
Before
you
continue,
I
realized
I
had
missed
one
agenda
item
that
I
did
want
to
say
the
last
agenda
item.
There
are
actually
two
more
three
more
there's
a
subscriber
and
policy
identification
presentation
and
a
name
based
service
function,
forwarding
presentation
which
somehow
didn't
make
it
on
to
my
slides
for
the
chair,
but
those
will
be
presented
today,
so
I
just
didn't
want
to
ignore
it.
But
thank
you
actually.
A
C
C
I
can't
see
that
far
that
we
that
he
presented
at
the
Montreal
meeting
where
there
was
a
suggestion,
and
we
followed
that
suggestion
to
evolve
the
quadruple
s
approach
so
based
on
Shamir
secret
sharing
in
the
draft
to
include
an
option
that
was
proposed
first
on
the
list
and
then
again
in
the
working
group
meeting
to
provide
for
an
ordering
capability
with
proof
of
transit
using
shaniyah
c
for
cheering.
And
that
means
with
that
particular
option.
We
can
do
something
that
we
couldn't
be
do
before.
C
Ie
smear
secret,
sharing,
using
proof
of
transit
with
ordering
preservation.
Something
was
prior
only
possible
with
massive
encryption,
and
so
the
key
change
is
that
particular
thing.
So
color
stone
come
across
really
beautifully,
but
the
main
idea
behind
that
is
that,
in
addition
to
the
shares
of
the
frequent
a
secret
that
we
communicate
typically
to
the
individual
nodes
like
share
one,
to
share
two
three
and
so
forth
of
a
secret.
We
also
populate
two
neighboring
nodes
that
are
part
of
a
service
chain.
C
Well,
what
has
been
documented
in
the
draft
to
hash
the
conglomerate
out
of
the
individual
random
number
that
uniquely
identifies
the
packet
and
the
cumulative
secret
that
we
are
computing
along
the
path,
so
we
hash
it,
and
then
we
do
the
anti
symmetric
operation
on
the
Associated
node,
so
that
we
have
a
clear
association
of
the
two.
It's
only
The
Associated
note
that
we
will
be
able
to
decipher
that
conglomerate
out
of
random
number
and
CML
and
then
do
the
the
regular
proof
of
transit
operation.
C
So
that's
a
simple
extension
of
the
the
Shamir
secret
sharing
scheme
a--
to
make
sure
that
only
the
associated
note,
ie,
the
next
hop
in
the
service
chain
is
able
to
do
the
proof
of
transit
operation,
as
opposed
to
any
other
random
note
in
that
change
in
that
chain.
So
that's
the
addition
that
went
into
a
draft.
There
is
a
dedicated
section
on
that
and
the
overall
graph
had
been
restructured
to
saying.
Okay,
we
have
two
methods
and
these
two
methods
now
each
have
an
ordering
preservation
capability
and
there
are
pretty
much
on
par.
C
We
have
two
mechanisms
that
do
exactly
the
same
thing
and
their
computational
capabilities
are
slightly
different
and
that's
also
what
the
graph
outlines,
because
well
shimmy
your
secret
sharing
is
quote-unquote
relatively
simple
when
it
comes
to
the
computational
effort
that
you
need,
because
it
requires
two
additions:
one
multiplication
and
one
modulo
crime
division
on
a
per
hop
basis,
whereas
if
you
do
nested
encryption,
it's
relatively
quote-unquote
expensive.
If
you
have
a
chipset
that
has
advanced
security
extractions,
that's
not
big
of
a
deal.
C
If
you
don't
have
that
big
of
a
deal,
so
we
have
an
option
by
now
to
eventually
choose
between
these
two
algorithms.
Historically,
we
decided
not
to
do
that,
because
massive
encryption
allowed
us
to
do
order,
preservation,
quadruple
s,
didn't
do
that.
So
we
kept
both
and
said.
Well,
you
have
one
that
is
cheap,
but
can't
do
everything
and
there
you
have
another
one
that
was
a
bit
more
expensive
but
can
do
both.
C
D
C
C
C
So
that's
what
I'm
saying
right.
So,
let's
see
whether
there's
more
people
that
care
about
the
whole
thing
because
seems
that
I
think
we
have
both
cams
represent
two
choosing,
not
choosing.
So
it
doesn't
really
make
sense
to
ask
for
if
we
choose
which
one
to
choose
and
let's
take
it
to
the
list
and
well,
the
first
one
I
said
is:
will
go
and
clean
up
things
a
little
bit.
The
second
one
will
take
it
to
the
list
and
see
whether
we
can
arrive
at
a
single
approach
on
V
I'm.
E
Okay,
Frank
can't
Leon
questions
I.
Think
for
me
also
the
hard
because
I
guess
have
to
figure
out.
What's
the
value
of
being
in
order,
I
think
that's
the
key
distinguish
between
the
number
one
and
number
two
right
verifying
that
you
went
through
all
of
them
or
went
through
in
the
sequence
that
you
want
right.
So
I
guess!
Well,
it
wasn't
clear
is
that
you
know
how
much
value
is
like
it's
option.
Two
I
guess
so.
C
C
I
I
screwed
up
badly,
so
with
Pro
Triple
S,
you
can
do
both.
You
don't
have
to
do.
Auto
preservation,
you
don't
have
to
go
through
this
additional
step
of
hashing
cumulative
and
random
and
then
do
the
reverse
operation
at
every
single
hope.
You
don't
have
to
do
better,
it's
an
option
and
if
you
use
nested
encryption,
you
naturally
do
get
order.
Preservation,
quote-unquote
for
free
with
photo
bless.
You
have
this
as
an
option.
C
C
D
D
D
Short
on
defining
and
it
was
an
agreement,
we
tried
not
to
go
to
expand
it
for
the
sake
of
the
progress
in
the
document,
and
it
said
that
obit
sending
this
obit
indicates
the
Orion
packet
without
going
into
details,
what
our
is
only
a
packet
and
what
is
considered
to
be
OEM
packet
for
their
effort
of
active
om
for
the
sacred
or
actively
a.m.
we
are
proposing
change
this
and
extend
this
definition
so
that
setting
this
old
it
indicates
that
there
is
om
command
or
data
in
the
nsh
context,
header
or
packet
payload.
D
F
No,
that's
pretty!
That's,
basically
that,
because
this
is
on
the
update.
Okay,
if
you've
reached
in
that's
great
Adrian,
Farrell,
sorry
I,
there
are
two
error
conditions
aren't
there's
hope
it
is
clear,
but
I've
put
in
a
next
protocol.
That
is
one
of
the
OEM
types
and
as
öbut
is
set
and
I've
put
in
a
chrome
text,
header
which
is
OEM
and
I
put
in
a
type
that
says
that
the
payload
is
I
am.
D
F
D
F
B
G
F
C
Just
one
really
observation
or
a
question,
so
if
the
next
protocol
header
already
tells
you
that
the
next
protocol
would
be
Oh
a
I'm
thinking
of
IOM,
for
instance,
what
would
be
the
value
of
setting
the
obit
or
not
because
then
I
think
as
a
lookup
engine
I
need
to
look
at
two
fields
instead
of
one.
You
know
you
can
already
make
the
decision
based
on
the
lookup
of
one
okay,.
A
The
way
we
have
specified
things
SFF
I'm
not
expected
to
look
at
the
next
header
field.
So
if
we
for
things
where
you
don't
care,
if
it
doesn't
get
noticed
and
if
somebody
notices,
then
they
want
them
to
act
on
it.
That
may
be
sufficient.
But
if
you
want
to
force
the
SFF
to
check
carefully
for
things,
it
needs
to
do
that's
what
the
obit
is
for.
Okay,
that's
at
least
that's
what
I
understand.
We
wrote.
Okay,.
C
A
C
A
D
Right
to
the
chase,
so
originally
we
were
advocating
to
allocate
two-bit
field
Marc
flag
to
be
used
by
alternate
marking
method.
But
since
we
were
developing-
and
there
is
a
draft
that
tell
champions
on
compressed
alternate
marking
the
same
quality
of
measurements
can
be
achieved
by
using
a
single
flag.
So
here
ends
their
update.
We
are
proposing
to
use
previously
deprecated
space
in
the
header,
so
single
flag,
single
bid
for
the
marking
field
and
here's
a
little
bit
history.
D
So
the
single
mark
method
can
help
us
to
do
good
loss
measurement,
but
the
accuracy
of
delay
measurement
with
a
single
mark
is
not
that
perfect.
For
the
higher
quality
of
delay
measurement.
We
can
recommend
multiplexed
marking
that
basically
combines
and
inverts
on
the
same
bit
there.
It
puts
some
restrictions
about
the
time
period
of
the
batch
that
has
to
be
used
so
that
everything
can
switch
over
and
recognize
that
there
is
a
change.
But
given
that
so
everything
can
work,
and
this
proposal
on
compressed
alternate
marking
method
is
anchored
at
I
ppm
working
group.
D
D
D
In
h,
TS
domain,
so
the
ingress
says
the
trigger
condition
and
generates
HTS
follow-up
packet.
The
follow-up
packet
has
the
same
encapsulation
as
a
trigger
packet,
so
to
ensure
that
it
follows
the
same
service
path,
the
trigger
packet
received
by
the
transit
nodes
and
they
take
the
measurements
and
then
wait
for
their
follow-up
packet
to
put
their
measurements.
D
There
could
be
a
condition
in
the
network
that
we
are
collecting
amount
of
information
that
doesn't
fit
in
a
single
follow-up
packet.
It's
not
a
problem
for
HTS,
because
the
transit
HTS
know
that
recognizes
that
it
cannot
add
this
information
to
their
HTS
follow-up
packet
generates
a
new
one
with
the
same
encapsulation,
so
we
have
a
sequence
of
follow-up
packets.
D
D
So
thus,
because
we
disconnect
the
measurement
itself
from
the
collection,
the
follower
packet
can
use
integrity,
protection
confidentiality.
There
is
no
restrictions.
At
the
same
time,
measurements
can
be
taken
in
real
time
when
the
packet
is
received
and
when
the
packet
is
transmitted,
the
trigger
packet,
the
follower
packet
will
have
very
minimal
sim.
J
D
D
K
Hi
there
I'm
donald
Eastlake
with
huawei.
I
talked
about
explicit
congestion,
notification,
congestion
feedback
and
the
network
service
header
using
IP
fix
so
I
presented
most
of
this
the
mechanism
here
last
time,
so
I'm
gonna
go
over
it
pretty
quickly.
It's
a
way
to
collect
congestion.
Information
in
a
service
function
changing
domains,
a
packet
goes
along
with
minimum
packet
drops
and
it
also
integrates
well
with
a
subtotal
path:
congestion,
notification
mechanism
from
the
origin
before
the
service
function,
tuning
domain
to
the
ultimate
destination
afterwards,
and
the
information
in
the
service
function.
K
Training
domain
is
communicated
back
to
the
classifier
so
that
it
might
take
some
action
to
alleviate
the
congestion
incipient
congestion.
Then
Justin
you're,
trying
to
avoid
so
it
seizes
some
bits
in
the
network
service,
header
and
it,
and
this
graft
communities
case
the
condition
information
back
to
the
classifier,
using
slice
tension
to
IP
fix,
and
there
was
one
comment
on
that
at
the
last
working
group
meeting
and
my
response,
which
is
somebody
said
they
didn't
want
to
implement,
IP
fix
and
response
to.
That-
is
that
this
is
a
standard
which
lets
you
communicate.
K
You
know
congestion,
information
back
to
the
classifier.
You
need
to
standardize
some
mechanism.
Somebody
wishes
to
propose
some
alternative
standardized
mechanism
that
can
be
used,
so
you
can
have
interoperability.
It's
fine,
but
I
haven't
heard
an
alternative.
So
this
is
a
diagram
showing
the
the
color
associated
area
in
the
center
of
the
service
function,
training,
domain
and
condition
feedback
there
and
also
shows
the
overall
and
and
congestion
feedback
which
that
can
be
part
of.
K
So
the
idea
is
to
use
a
couple
bits
who
doesn't
matter
which
two
bits
but
seems
can
me
into
their
adjacent
and
they're
used
using
the
stand,
ecn
marking,
which
is
defined
for
IP
and
a
number
of
other
protocols
in
the
upward
direction.
There
is
they
draft
on
how
to
indicate
congestion
feedback
by
giving
statistics
on
the
ecn
settings
easy
and
is
somewhat
of
a
statistical
thing
and
a
lot
of
ways
which
the
packets
have
been
marked
in
the
e
CN
field
for
different
combinations
and
also
a
total
of
packet
count.
K
Byte
counts
and
things
like
that,
and
the
key
statistics
communicate
it
back
and
I
think
our
cumulative.
So
if
you
happen
to
lose
a
packet
of
them,
it's
okay,
and
here
does
some
things
you
might
do
with
the
classifier.
You
can
throttle
traffic.
You
can
communicate
congestion
information,
perhaps
in
some
specific
way,
if
you
know
how
to
do
it
well
to
sum
up
stream
node
and
you
can
also
redirect
traffic.
K
Of
course,
you
have
to
be
very
careful
not
to
get
oscillations
or
things
like
that,
but
if
you
have
so
long
live
flows,
which
is
what
you
might
have
if
the
flow
is
defined
by
say
a
customer
and
customers
come
on
and
do
things
and
then
go
away.
Then
you
could
certainly
redirect
how
you
what
the
server's
change
that
you
use
for
newly
arriving
flows
that
start
up
and
that
something
like
that
seems
very
unlikely
to
cause
any
sort
of
the
oscillation
or
bad
behavior.
So
all
this
works
much
better.
K
If
you
have
easy
any
minute
throughout
the
service
function
changing
domain,
the
draft
goes
into.
You
know
what
to
do.
If
there
is
things
that
are
not
implemented,
but
basically,
if
you
have
any
place
where
you
might
have
congestion
that
could
cause
packets
to
be
discarded.
If
it
gets
bad
enough,
if
you
don't
have
ECM
at
that
congenital
congestion
point-
and
you
have
some
unmanaged
congestion-
and
you
know
the
performance
for
avoiding
congestion
will
not
be
as
well.
K
K
What
can
at
least
the
output
q
from
it
where
you
might
have
congestion,
so
some
others,
some
other
methods
for
detecting
congestion
were
suggested
at
the
last
working
group
meeting
particularly
will
insulate
it
to
telemetry
and
there's
that
those
mechanisms
there
are
possible
mechanisms,
but
there
are
problems
if
you
want
to
use
delay,
try
to
detect
the
beginning
of
some
delay
or
increased
jitter
at
the
delay.
You
have
to
have
time
synchronization
for
delay
or
jitter.
There's
the
problem
that
when
this
stuff
is
working
properly,
you
have
very
low
delays.
K
This
lot
of
tests
have
shown
that
this
ECM
ECM
mechanisms
are
really
very
effective
at
avoiding
any
kind
of
buffer,
bloat
or
problems
like
that.
You
know
so
you
really
have
a
situation
where
the
amount
of
delay
caused
by
congestion
to
the
beginning
of
congestion
is
small,
but
there
are
also
very
small
delays
of
the
same
order
of
magnitude
due
to
all
kinds
of
other
things
and
noise
and
the
amount
of
calculation
you're
doing
at
various
nodes
and
so
on
and
so
forth.
K
So
you
really
need
some
kind
of
filtering
and
stuff
to
try
to
isolate,
delay
or
jitter
due
to
congestion
from
other
forms
of
delay,
other
causes
for
delay
or
jitter
and
I.
Really
it's
pretty
complicated
and
this
that
stuff
you're
doing
it
doesn't
really
integrate
very
well
with
the
end-to-end
congestion
accumulation
using
ECM
within
the
service
function.
Changing
domain
integrates
very
well
with
end-to-end
ecn
markings.
K
This
standard
ecn
methods
to
mark
when
you
enter
a
domain
from
whatever
marking
you
have
from
the
previous
processing
of
the
packet
and
the
way
you
can
integrate
the
marking
you
do
inside
the
service
function
in
changing
domain
at
the
egress
from
that
domain
and
feed
it
out.
They
are
all
very
well
documented
and
so
forth.
So
I
think
that
these
other
methods,
while
possible
methods,
are
missed
inferior
to
using
the
explicit
congestion
notification.
L
I
Good
evening
my
name
is
Sammy
Boutros
from
VMware
I'm
going
to
be
presenting
today.
This
draft,
it's
about
applicability
of
Junaid
to
SFC
or
you
know,
Junaid
is
actually
in
cap
used
by
enviously.
So
you
possibly
can
read
the
draft
as
applicability
or
how
and
vo3
will
support
service
function,
training,
so
service
function
chaining
in
and
enviously
domain.
How
would
that
be
done
so
that
that
was
presented
in
the
grocery
working
group,
the
history
of
the
draft?
I
We
presented
the
draft
a
year
back
and
since
then
we
made
few
changes
to
the
draft
to
align
it
more
to
the
SSE
architecture
and
not
to
alter
anything
with
NHIN
cap.
So
we'll
go
through
the
details
in
the
next
slide,
so
it's
I
guess
it's
well
understood
that
as
I've
seen,
the
Manta
service,
topology
wall
and
vo3
implement
a
network.
Virtualization
topology
right
so
or
and
V
or
C
domain
is
a
network
virtualization
domain
as
I've
seen
comenta
service
topology.
I
So
when
we
wanna
implement
the
service
topology
over
the
network,
virtualization
those
will
be,
you
can
think
about
it
as
to
overlay
layers,
one
for
the
service
or
two
layers.
One
called
service
apology,
underneath
we
have
the
overlay
or
the
NGO
three
domain
so
to
implement
the
service
topology
as
presence
of
C
architecture,
you
would
need
to
resolve
the
SPI
answer.
Sites
SPI,
stand
for
the
service
pass
index
and
si
the
service
index
within
that
service
patch
to
the
actual
service
functions
that
you
need
to
deliver
the
package.
I
So
if
we
are
talking
about
a
network,
virtualization
domain
was
an
V's
zan
as
a
control.
Plane
here
need
to
set
up
the
service,
topology
forwarding
tables
on
all
the
nve's
that
has
s
ffs,
get
a
new
set
or
does
some
sophisticated
calculation
to
calculate,
expand
and
figure
out
which-
and
we
need
to
know
about
which
SV
is
I-
that
map
to
s
FF
that
possibly
are
hosted
on
that
MV.
So
so
so
you
need
to
build
those
service.
I
Topology
on
all
the
nve's
was
in
the
enviously
domain,
and
this
will
be
again
like
another
layer
on
top
of
the
overlay.
So
so,
let's
say
it's
a
service
function
that
a
given
SV
is
I
would
resolve
two
moves.
Then
you
need
as
well
to
track
that
movement
and
and
program
as
SV
is
I
two-way
at,
for
example,
that
service
function
has
moved
you
or
where
its
associated
now
is
another
MV,
so
that
of
course
we
require
will
will
have
some
impact
on
convergence
and
so
on.
I
Right
I
saw
Li
one
one
one
thing
I
forgot
to
mention
is
that
you
resolve
at
the
service
layer
the
spi
and
si
to
the
SFF.
Sorry,
it
is
a
service
function
on
the
SFF
and
Asaf
here
will
be
the
nd
as
well,
and
then
in
the
network,
virtualization
overlay
layer.
You
resolve
that
service
function
to
the
action
and
ve
that's
connected
to
sorry
yeah
and
let
me
I'll
go
through
through
that
diagram
first
and
then
we
can
go
back
to
slides.
I
So
if
you
look
here
at
the
picture,
we
have
an
NGO
C
domain
consisting
of
three
Indies
with
an
English
and
V
as
well.
So
so
for
Envy's,
each
and
ve
from
SFC
terminology
can
be
thought
as
a
service
function
for
order.
The
English
and
V
can
be
sought
as
a
class
apart
so
yeah
so
Sousa
class
apart,
classify
figure
out
which
service
fast.
The
package
should
be
delivered
on
and
then
deliver
the
pack
to
the
first
service
function.
So
so,
basically,
the
first
service
function.
It's
gonna.
I
If
it's
reachable
by
a
network
virtualization
overlay
domain,
then
we
need
to
have
two
resolution
can
think
about
it
as
a
recursive.
Dissolution.
One
resolution
is
that
figure
out
from
a
given
SPI
and
the
soy.
What
is
the
service
function
and
zanza
other
recursive
dissolution,
which
is
that
service
function
is
reachable
via
which
and
we
or
by
which
detail?
So
2d
solution
has
to
happen
at
to
layer
the
service
topology
and
is
a
network
virtualization
overlay
to
Paulo,
so
so,
what's
being
proposed
in
that
draft
is
to
option
to
implement
the
service
support.
I
I
How
to
reach
that
Isetta
and
the
other
options
as
being
proposed
is
an
optimization
to
implement
the
service
topology
by
attaching
to
the
genie
which
is
in
Capel's
enviously.
What
we
call
an
SFL
list.
So
a
given
service
pass,
as
we
said,
is
a
set
of
service
functions
that
you
have
to
go
through.
So
so
we'll
include
in
that
SFL
list.
The
different
service
functions
that
we
have
to
go
through
adds
an
ingress
right
or
as
a
classifier.
I
So
now
we
don't
need
to
program
on
all
the
NDEs,
the
SPI
aside,
Asafa,
because
that's
known
as
the
ingress
or
will
be
carried
along
with
the
packet
as
we
are
traversing
the
service
path.
So
now,
when,
when
we
need
as
well
to
converge,
we
only
need
to
converge
the
network
virtualization
overlay
layer.
There
is
no
need
to
converge
the
other
recursive
layer
on
top
of
the
net
realization
if
let's
say
that
this
function
for
that
move,
get
reinstated,
get
started
instead
created
on
other
and
Vees
or
whatever
Susan
B's,
a
hypervisor,
for
example.
I
So
so
those
are
the
two
control
option
we
are
talking
about.
That,
of
course,
is
straightforward:
how
to
carry
an
SH,
so
the
anesthetic
app
is
kept
intact.
It
has
its
own
spi
MSI.
It
has
on
me
today
that
has
its
own
option
and
nsh
by
itself
is
a
layer
2
protocol
so
engineer
as
any
cat
can
carry
any
type
any
layer,
2
protocol
type.
I
So
so
we
can
carry
engineer
next
protocol,
the
type
of
course,
then
SH
protocol
as
well
carry
inside
as
an
SH
has
a
protocol
field
as
well
and
can
set
the
inner
packet
protocol,
which
could
be
easier,
not,
for
example,
to
implement
that
s
afoul
of
the
service
function
list,
which
is
the
other
way
of
implementing
as
a
service
topology.
In
the
data
path,
we
defined
a
new
G
name:
option
TLV
here
it's
it's
a
very
similar
to
a
segment
routing
extension
header
for
v6,
for
example.
I
But
is
that
good
thing
about
Geneva's
that
we
can
have
that
as
a
file
for
both
ipv4
and
ipv6,
as
this
is
again
going
by
the
encapsulation?
And
how
that
you
know
it's
just
a
reminder
of
the
different
of
the
Genevan
cabs
and
a
section
cap
and
so
on,
and
and
in
this
slide
it's
describing
by
dl
what
is
going
to
happen?
I
I
think
I
went
over
that,
but
I
can
go
quickly,
one
more
time
exactly
so
far
classify
this
is
again
with
there's
a
control
plane
option
of
the
service
topology
of
limitation
option
to
have
an
SFL
or
a
service
function
list
so
that
go
so
far.
Identify
service
pass
include
the
set
of
service
functions
that
you
have
to
go
to
as
an
option
here
in
jannat
sends
a
packet
to
the
person
de
because
he
can
resolve
the
first
service
function
to
the
correct
and
V
sorvita
as
any
passing
to
the
service
function.
I
I
Would
he
can
based
on
zest
behind
signs
and
a
search
header
find
the
state
that
he
created
and
then
figured
out
how
to
reach
that
a
second
service
function
by
doing
the
double
recursion
of
findings
that
service
function
to,
for
example,
is
each
table
watch
and
be
until
we
reach
the
egress
and
V,
and
in
that
case
we
are
removing
even
the
a
message,
header
and
leveling,
the
packet
to
the
destination
cement
the
destination
to
the
back,
so
I
think
with
that
yeah.
Actually,
it's
an
acknowledgment
to
Jim
I.
I
E
Kentley
Oh
Archie,
sorry
I,
haven't
read
your
draft,
but
it
actually
park
my
interest
here.
So
you
mentioned
there's
two
options
here:
i1
is
basically
you're
in
the
first
acting
as
a
SFF,
basically
right
and
the
second
one
was
the
whole
SFL.
This
is
that
correct
I
mean
maybe
you
can
show
the
two
options:
ice,
not
clarify:
okay,
yes,
the
two
control
plane
right,
so
the
first
one
you
said
that
basically
it's
acting
as
SF
a5
being
able
to
handle
the
SBI
and
si.
G
I
I
I
I
If
you
are
implementing
a
service
topology,
so
the
service,
as
we
are
trying
to
bear
to
implement
the
service
apology
in
an
interview
see
domain,
so
you
have
the
network
virtualization
layer,
and
you
have
the
service
apology
later
right.
So
if
you
want
to
implement
the
service
topology,
what
SFC
architecture
cooling
for
is
that
a
given
spi
on
the
side
will
point
a
given
service
function,
correct
standard,
yeah,
very
good,
so
how
to
implement
that
yeah?
I
You
know
on
service
function
for
order
or
Envy's,
because
the
same
and
ve
is
a
service
function
for
order
and
ve
for
enviously.
Sf
f
is
for
SSE
okay.
So
what
is
a
way
to
implement
it
is
that
you
go
to
every
SFO
and
programs.
Spi
is
a
point
to
the
service
function.
Okay
and
after
you
do
that
that
service
function
is
let's
say,
connected
to
a
given
hypervisor.
I
If
you
are
talking
about
enviously,
then
you
need
to
figure
out
how
am
I
gonna
reach
the
service
function,
so
you
do
two
level
of
the
carriage
okay,
so
that
means
that
I
have
to
distribute
the
SPI
saw,
mapping
to
SFF
to
all
or
to
a
good
set
up
our
pipe
advisors
or
of
nve's.
What
you
know
to
figure
out
how
they
can
reach
the
service
on
check
for
them.
It's
the
service
function.
Sorry,
the
second
option
is
sign.
I
don't
I
can.
I
can
assume
that
I
don't
want
to
do
that.
I
You
know
I'm,
not
gonna
program
as
SPI
sigh
on
all
those
envies.
What
I'm
gonna
do
is
that
the
service
pass
that
has
a
set
of
service
function.
I'm
gonna
have
an
option
TLV
that
has
the
service
function
as
a
classifier
and
in
data
plane
as
the
packet
traverses,
the
NVE
is
gonna
cash
as
he
passes.
The
packet
service
function,
za
s,
bi
SI,
toos
a
Sahab,
so
the
packet
comes
back
from
the
service
function.
He
can
figure
out
the
next
and
ve
to
good
okay.
A
Really
it's
a
classic
version
of
the
trade
off.
We
see
all
the
time
between
state
and
the
network
device
and
state
in
the
packet
you
can
set
up
the
state
in
the
network
devices
or
you
can
put
the
state
in
all
the
packets
and
I'll.
Let
n
vo
3
do
the
analysis
as
to
which
way
makes
the
most
sense
or
whether
to
support
both
from
an
SFC
perspective.
The
SS,
the
NS,
a
cheddar
is
always
there.
The
NS,
a
cheddar
is
always
available.
A
E
Okay,
okay,
I
guess
on
to
the
second
part
right,
so
the
first
part
I
totally
understand
in
terms
it
was
to
me
a
standard.
Ssc
writes,
okay,
write
the
number
1
number
2
like
so
I
get
the
idea
that
you're
carrying
basically
hop-by-hop
information-
yes,
alright,
but
when
it
hits
that
technically,
like
you
said,
you
don't
have
to
use
see,
is
I
right
and
so
and
that's
what
I'm
trying
to
think
was
here.
A
I
M
M
Let
me
introduce
the
CEO
and
principal
first
and
from
this
diagram
we
can
see
that
in
sa
o,
SF,
f
fo
and
once
it
received
a
CEO
M
request
message,
it
will
take
two
actions
to
forward
the
CEO
M
request
message
to
its
nest.
Sff
and
another
action
action
is
that
the
SFF
we
are
standing,
our
comm
reprime
message
back.
The
La
Silla
means
repair
message:
contain
the
service
function
and
connected
to
these
services,
s
FF,
o
so
from
which
connecting
connecting
the
same
reply
message
and
reply,
repair
message:
one
we
practically
press
really
prefer.
M
And
folders
Co
Co
a
message
we
paste
the
web
based
on
the
chapter
module,
a
o
and
own.
It's
a
request
message
in
the
reply
message
and
based
on
that.
On
that
massive
image,
we
define
a
self
information
securely
in
the
Salem
repair
message
and
in
the
in
this
receptor
will
we
defined
as
as
as
the
SPI
and
the
SPI
is
identifier
or
the
SFP
to
which
order
as
the
F
in
this
subdial
belong
and
there's
a
SAF
type
to
indicate
the
type
of
subs
function
and
there
is
a
SF
IP
type.
M
Okay,
this
chapter
has
been
present
in
an
ITF
between
101
and
there
is
we
received
some
comments.
While
the
comments
is
to
just
ask
to
consider
the
scenario
in
road
balance
of
Mattie
post
functions
for
multiples
of
some
system
service
functions
for
load
balance.
That
means
the
particular
traffic
flow
chance
if
only
one
service
function.
So
these
these
multiple
service
functions
and
should
have
in
the
same
service
function,
type
and
subservice
index.
So
for
this
case
we
suggest
that
Co
absalom
request
message
should
contain
a
fro
IP
list.
M
M
Okay
and
another,
the
second,
the
second
chapter
is
about
the
specified,
return
pass
in
service
function,
om
and
this
lead.
This
chapter
is
also
based
on
the
Mac
layer.
Over
am
met
messageformat
in
this
english
chapter,
with,
with
the
best
way
define
a
new
TR
v,
replace
the
with
function
past.
Here
we
in
echo
request
to
engage
to
indicate
the
specified
return
return.
M
Sfc
in
this
year
we
and
to
significant
fielder
is
defined.
Y
is
replying,
SFP
IP
is
the
identifier
of
the
reverse,
SF
key
and
another
is
servicing
tags.
It
is
used
in
greebles
as
a
key
for
forwarding
and
post
reply,
as
the
P
IP
and
the
servicing
text
will
be
encapsulated
in
the
inertia
in
the
reverse
reverse
as
a
P.
In
another
case,
if
the
return
SMP
cannot
be
found,
then
the
echo
repair
should
include
the
repairs
of
peak
and
was
not
found
in
linear
encoder.
M
M
N
Okay,
that's
what
I
do
so?
The
first
slides
you
see,
you
see
the
typing
okay,
so
this
is
a
draft.
We
have
finis
submitted
again
that
doing
a
lot
of
changes
based
on
a
lot
of
previews
we
have
received,
and
now
we
want
to
ask
for
the
option
of
this
draft
and
it's
more
or
less
on
policy
identification.
How
for
a
special
service
of
a
special
subscriber,
the
the
information
required
to
provide
the
service
best
in
SFC
can
be
handled
the
next
slide.
You
see
the
agenda,
so
first
I
want
to
go
on
the
problem.
N
What
we
have
in
mind
and,
of
course
we
try
to
provide
solution
for
this
and
then
some
details
about
the
updates.
We
have
the
previous
draft,
which
was
now
I,
think
it
was
presented
two
years
ago
more
and
sir
version
7
already
available.
Then,
okay,
the
questions
how
to
proceed
next
and
on
the
next
slide.
We
have
some
comments
on
policies.
What
do
you
think
so?
Generally
we
what
we
want
to
deploy,
especially
performance
service
provider
or
operator,
point
of
view.
N
It's
not
best
effort
services,
perhaps
with
special
requirements
and
for
dedicated
customers
buying
for
special
policies
and
how
to
enforce
these
policies
on
the
function
path.
In
SFC
speech,
we
need
to
identify
that
is
yeah.
It
is
the
correct
subscriber
who
gets
granted
this
service
with
with
a
promised
performance
right
and
and
of
course,
there
may
be
different
services.
N
Of
course,
this
policies
may
be
first
only
on
foster
one
service
function
or
multiple
service
functions.
Perhaps,
on
each
of
these
functions
in
half-
and
yes,
of
course,
within
this
virtual
environment,
these
first
functions
may
be
located
anywhere
within
this
domain
and
because
we
are
talking
here
only
a
single
then
about
single
man
and
which
kind
of
policies
how
many
and
how
this
looks
like
and
how
to
enforce
them.
This,
we
think,
should
be
deployment
specific.
You
just
want
to
prior
right
mechanism
how
to
or
to
include
this
okay
on
the
next
slide.
N
That's
what
how
we
want
to
solve.
The
problem
now
know
it
first
is
the
problem
that
the
service
function,
which
is
in
question
to
enforce
some
policies,
may
may
not
have
access
to
the
information
available,
perhaps
to
the
subs
provider
or
anywhere
else,
which
is
how
do
I
identify
the
subscriber.
Why
I
make
address
via
the
line,
ID
and
fixed
network,
and
so
on
and
yeah
in
the
service
function,
has
difficulties
to
address.
N
This
information,
which
one
they
are
true,
especially
if
their
service
function,
is
upstream
path.
So
what
we
think
what
is
not
reliable
here
to
use
is
transport
coordinates
because
they
may
change
it's
one
thing
being
translated
in
the
meantime
or
because
also,
if
we
take
an
IP
address,
the
Sun
may
be
dynamic,
especially
of
ability.
N
So
the
question:
what
comes
up
is
how
to
reliably
and
flexibly
pass
this
information
to
all
the
service
functions
on
the
path
to
where
to
to
enforce
that,
to
ensure
that
the
policy
is
enforced
and
or
passed.
But
of
course,
we
don't
want
to
get
a
problem
if
the
information
some
of
the
information
changes
and
therefore
we
thought
the
next
slide.
N
That's
the
kind
of
identification
data,
how
we
call
it
and
which
have
to
be
consumed
by
the
service
functions,
to
provide
the
correct
service
performance
should
be
included
in
a
kind
of
a
context,
object
kind
of
metadata,
which
would
be
part
of
the
NSA
Chara.
And,
of
course,
it's
compliant
with
the
RSC
76
65.
Where
there's
a
section
on
sharing
metadata
and
what
we
have
done
is
we
have
tried
to
specify
two
different
contexts
that
as
well
as
on
identifying
the
subscriber
and
the
other,
is
on
the
special
policy
which
is
process.
N
Baba
has
been
assigned
by
the
service
provider
and
they
can
both
be
the
same
in
its
age,
of
course,
and
what
we
thought
here
is
that
we
defined
them
without
specific
structure,
just
as
opaque
data,
because
the
structure
may
be
deployments
the
PC
issue
and
also
the
more
you
define
on
the
structure
and
beforehand,
the
more.
Perhaps
it's
opens
up
for
privacy,
leaks
or
tweaks.
So
this
shouldn't
be
just
opaque
data,
but
we
proposed
and
now
to
see
what
way
to
change
compared
to
the
prior
draft.
N
So
there
have
been
a
lot
of
comments
in
the
list
of
the
draft
and
we
think
we
have
addressed
all
these
comments
during
the
new
version.
Then
we
simplified
slate
considerably
this
design,
because
we
had
in
mind
much
more
before
so
we
only
have
two
TLB
sunscribe
and
policy,
and
we
have
not
included
some
structure
for
this
theories.
N
A
A
H
Hello,
everybody
I'm
Debashish,
and
this
is
a
I'm
representing
name
based
surface
function,
forwarder
component
within
the
SFC
framework
on
behalf
of
my
co-authors,
in
terms
of
the
earlier
versions
of
the
draft.
These
name
based
service
function
for
order
is
kind
of
illustrated
through
the
5g
service
based
architecture
use
case
where
in
distributed,
data,
centers
service,
endpoints
are
created
and
recreated,
which
requires
the
subsea
framework
to
configure
the
existing
chain
and
reconfiguration.
Using
information
of
the
new
relationships
cause
overhead
in
many
components,
and
such
one
of
them
is
the
orchestrator.
H
Now
in
terms
of
the
architecture,
is
a
which
is
very
much
similar
or
in
line
with
the
existing
SFC
architecture.
With
the
extensions
shown
there
as
n
SFF
and
also
the
NR
now
in
terms
of
the
extended
concepts
that
n
SF
b
or
the
net,
is
basically
the
extended
service
function,
path
which
includes
this
name
based
interaction.
The
name
based
network
locator
map
includes
next
top
name.
This
next
hop,
and
also
there
is
another
functionality
called
NR
or
name
resolver,
which
is
capable
of
identifying
the
execution
end
points
where
a
named
service
function
is
running.
H
H
Now
this
shows
some
of
the
deployment
or
trial
examples.
One
of
the
most
recent
one
was
the
demonstration
at
the
of
the
5g
service
based
architecture
use
case
at
the
ng
MN
from
April
2018,
which
was
jointly
done
with
Deutsche
Telekom,
and
it
shows
the
control
plane
executed
as
HTTP
based
services.
And,
besides
that,
we
are
also
doing
the
flame
platform,
validation
through
urban
scale
trials
and
experiments
and
which
focuses
on
media
scenarios
such
as
VR
AR.
H
Now,
in
this
portion
of
the
draft,
the
what
has
been
updated
or
included
is
the
detailed
descriptions
of
the
operations
in
the
n
SFF.
Also,
the
operations
between
n,
SFF
and
n
n
are.
We
have
to
forward
to
a
remote
service
function,
and
these
operations
are
described
in
details
specifically
considering
how
to
avoid
delay
in
forwarding
by
saving
the
forwarding
information
and
also
how
to
avoid
stillness
of
these
forwarding
information
by
periodically
updating
the
safety
information.
So.
A
H
H
Yet
the
nests
of
f4
remote
service
function
whose
father
ID
has
been
updated
now
in
terms
of
some
of
the
more
details,
our
steps
that
needs
to
be
described
are
defining
of
a
transport
protocol
between
n
SFF,
between
n
SFF
and
also
in
s
FF
n.
Our
handling
of
HTTP
responses,
the
security
and
some
of
the
I
think
edits
are
editorial
that
all
that
has
been
identified
in
the
list.
H
So
in
terms
of
I
think
that
does
a
main
part
and
in
terms
of
the
next
step,
we
really
want
to
see
collect
feedback
from
the
working
group,
specifically
the
general
validity
of
this
extension
of
this
FZ.
That
is,
the
the
name
based
handling
of
the
service
function
so
and
you
scope
within
the
SFC
and
also
on
the
solution,
and
we
also
plan
to
work
on
aligning
the
solutions
which
has
been
deployed
for
trials
for
liberty.
Struct
continue
contributing
towards
the
work
in
the
ng
MN
service,
based
architecture,
working
group
on
the
performance
evaluation.