►
From YouTube: IETF101-SFC-20180321-0930
Description
SFC meeting session at IETF101
2018/03/21 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
Or
unable
to
make
it
to
London,
so
here's
the
brief
agenda,
we're
going
to
briefly
go
over
some
in
see
too
OE
M.
We
Frank
some
work
on
om
for
path,
consistency.
We're
then
going
to
look
at
an
alternative
handling
for
dynamic,
chaining
and
service
in
direction,
and
then
an
update
on
the
SFC
in
fog
environments.
A
A
We
worked
on
a
new
working
group
charter,
so
thanks
for
everybody
that
helped
us
to
do
that,
so
that
we
that
recharter
and
has
now
happened
and
approved
Adrian's
SFC
convent
draft
as
a
proof
of
publication.
So
that's
another
piece
of
work
as
well
as
the
higher
arc
OSF
see
submitted
to
our
the
iesg
for
publication
as
well.
A
We've
adopted
a
few
new
documents
into
the
working
group,
primarily
the
type
1
metadata
documents,
one
for
de
the
center
one
for
broadband
allocation
and
also
the
type
2
which
is
the
the
tio
V's
document
that
we
talked
about
a
lot
of
times.
And
then
we
started
to
make
a
little
bit
of
progress
on
the
OEM
framework
updated
when
we
think
it's
supposed
to
a
working
group.
Last
call
so
encourage
people
to
go
and
look
at
that
and
provide
comments.
C
They
can
kept
track
first,
yep
doing
it
there.
It
is.
This
is
actually
a
nice
focus.
Ooh,
sorry,
ed
money
to
a
screen
is
a
nice
thing
that
they're
doing
these
days.
Okay,
so
quick
update
on
what
has
changed
from
the
zero
zero
to
the
zero
one
version
of
the
nshn
cap
draft
for
IOM
just
next
slide.
So
the
main
change
that
we've
done
is
reflect
the
changes
that
happen
in
the
data
draft.
C
So
in
an
SH
we
might
be
able
to
ask
for
three
Co
points,
maybe
or
even
four
point
echo
points
for
individual
types
that
we're
gonna
go
carry
in
IOM.
In
other
cases,
it
is
a
mandatory
thing,
and
so,
if
we're
encapsulating,
for
instance,
into
GRE,
you
need
an
either
type
and
the
triply
we'll
only
if
it
was
one.
C
The
other
thing
that
we
had
and
we
had
that
discussion
back
in
Singapore
was,
should
my
OEM
mean
that
the
traffic
needs
to
be
kind
of
flag
with
the
öbut
and
look
at
looking
at
8300.
It's
very
clear
on
that.
Customer
traffic
must
not
must
not
set
the
öbut
and
well
just
by
adding
the
IOM
metadata
to
the
customer
traffic.
We
don't
make
the
customer
traffic
suddenly
something
else.
Then
custom
traffic
ie.
We
cannot
set
the
obit
for
that.
C
I
probably
evolves
into
discussion
whether
we
want
to
go
and
do
something
to
go
and
help
a
SFF
to
eventually
then
still
look
at.
Is
there
anything
else
for
me?
Do
we
need
another
bit?
Well,
I
think
that's
an
open
discussion!
Okay!
That's
where
we
stand
so
two
more
points
can
I
just
go
through
this
and
then
yeah,
but
we're
doing
it.
D
D
C
That
I'm
not
interested
in
the
obit.
What
I'm
saying
is
that
IOM
does
not
change
what
the
meaning
of
the
obit
is
ie.
If
we're
tagging
I,
if
you're
tagging
traffic
with
IOM
and
its
customer
traffic,
the
obut
must
not
be
sad.
If
there
is
om
traffic.
That
would
also
be
tagged
with
IO
am
the
obit
would
be
set
for
anyway.
D
C
C
A
C
It's
a
fair
question
to
the
working
group
right:
why
do
we
have
the
obut
I
think
you
you
raised
that
question
it's
been
raised
a
year
ago.
It
wasn't
really
resolved
yeah.
So
the
only
thing
that
I'm
saying
is
we're
not
you're
not
using
we're,
not
changing
the
meaning
of
the
obit.
If
there
is
traffic
with
öbut,
it's
gonna
be
set.
If
there
is
traffic
without
öbut,
it's
not
gonna
be
set
next
one,
so
that
just
the
next
slide
just
shows
what
the
header
format
looks
like
with
the
new
IOM
type.
C
That's
been
defined
in
the
data
draft.
That
means
we
have
an
IOM
type
header
length
and
then
just
max
protocol.
So
it's
a
very
clean
shim
by
now,
and
we
are
only
asking
different
from
what
the
original
version
was
we're
only
asking
for
a
single
code
point
one
thing
that
well
I
wanted
to
go
bring
up
again.
We
had
that
discussion,
not
really,
but
briefly,
the
draft
still
discusses
that
there's
two
options
that
we
can
go
do
in
ons
H
one
way
is
to
capsulate
I
metadata
into
Mbita.
C
Apparently,
that's
also
what
the
early
implementation
in
VPP
is
doing
as
open
source
from
an
efficiency
perspective.
The
many
Hardware
people
that
we
have
supporting
this
graph
and
that
are
implementing
the
thing
like
the
next
set
of
approach.
Why?
Because
it
doesn't
really
mean
that
unity
won't
go
through
all
the
various
TVs
that
you
might
have
in
the
NSX
header,
because
there
is
no
ordering
there
is
no
priorities
of
individual
metadata
in
there.
So
the
next
set
of
approaches
cleaner
and
simpler
for
Harper
to
progress,
because
we
want
a
flat
structure
as
much
as
possible.
C
So
that's
a
concern,
but
I
wanted
to
go
and
race
that
question
again,
because
well
there
can
be
devices
that
well
are
more
easily
going
with
metadata
type.
They
can
just
skip
that.
They
might
not
be
that
easy
on
skipping,
something
that
is
in
the
next
header.
Tell
so
I
wanted
to
go
race
that
question
again
and
get
kind
of
feedback
from
the
room
on
that
particular
one.
Before.
B
We
contributor
the
the
I'll
important,
somewhat
subtle,
but
very
important
point
about
this:
the
difference
between
using
next
header
and
using
TLV
the
important
there's
two
kinds
of
differences.
One
is
the
efficiency
which
you've
correctly
pointed
out,
but
particularly
for
hardware,
but
even
for
software,
it's
more
efficient
to
process.
Io
am
if
it's
next
header.
I
don't
disagree
with
your
assertion
there
that
matches
my
understanding,
but
there's
a
compatibility
drawback.
B
If
you
have
existing
deployed
SF
FS
that
need
to
do
ecmp
and
so
are
looking
for
the
pocket
they're
not
currently
expecting
to
go
skipping
they're
going
next
header
packet
right
and,
more
importantly,
if
you
have
existing
service
functions,
they're
expecting
the
next
Tanner
to
be
the
packet
they
work
with
when
they
get
next
Tedder.
They
have
to
look
at
it.
There
are
only
there
are
two
possible
behaviors.
B
If
they
haven't
been
pretty
to
do
this,
they
might
not
have
realized,
they
can
get
multiple
kinds
and
they
would
get
to
just
completely
the
wrong
thing
or
they
did
properly
understand.
They
could
get
multiple
kinds.
They
would
not
understand
this
and
they
will
promptly
drop
the
packets
on
the
floor,
causing
us
to
drop
user
packets
and
having
existing
service
functions,
drop
user
packets
for
a
feature
that
we
want
to
be
able
to
incrementally
deploy
yeah
for
a
Greenfield
financial.
B
That's
going
to
install
this
everywhere
and
make
sure
everything
does
this
because
it
matters,
but
even
for
the
financials
you
describe
me,
they
only
need
to
actually
check
some
of
this
stuff
at
a
couple
of
places.
If
you
use
next
header
existing
functions,
they
need,
as
far
as
I
can
tell,
will
break
and
I
think
that's
very
important.
So
I
wanted
to
make
clear
the
trade
off
and
now
I
want
to
hear
from
the
room,
yeah
and
anybody
else
wants
to
speak
up.
Okay,.
D
B
D
We
have
individual
draft
multi
layer,
active
om
for
a
subsea
networks
that
proposes
for
active
om
to
use
what
we
refer
as
a
header,
which
can
be
it
set
as
a
shim
for
a
message.
I
think
that
there
is
a
reason
to
try
to
converge
these
two
encapsulations
for
OEM,
so
that
there
will
be
a
single
type
of
encapsulation
that
can
be
shared
by
epithelium
and
hybrid.
D
At
the
same
time,
I
pull
into
the
earlier
work
of
overlay,
om
design,
team
that
produced
the
OEM
header
work,
and
this
will
be
presented
later
in
in
their
three
group
and
called
for
adoption.
So
again,
I
think
that
there
is
not
much
difference
between
active,
om
and
hybrid
to
em,
and
it's
worth
effort
to
try
to
come
up
with
a
cinco
encapsulation
for
om
can
be
used
by
hybrid
and
active
I
am
in
overlay
networks
in
general.
E
Kyle
eros
and
vine,
so
I
mean
you
could
just
have
the
next
protocol
being
incompatible
with
a
network,
be
a
control
plane.
Is
he
right?
If
no,
if
everything
doesn't
advertise,
it
supports
this
next
protocol?
Don't
add
the
I/o
am
kind
of
sucks,
but
speaking
about
compatibility,
it's
already
an
implantation
of
an
in
in
the
metadata.
Is
it
crazy
to
support
both
for
networks
which
haven't
been
updated
to
support
the
next
protocol?
E
F
C
B
B
D
B
D
B
B
D
C
D
B
G
D
H
It's
the
home
from
Hawaii
I'm,
just
a
little
bit
confused
in
this
h
itself
is
not
a
transport
protocol
and
so
wow,
it's
already
been
defined
many
ways
to
encapsulate
same
header
into
different
transport
protocols.
So
is
this
some
duplication
effort
or
this
om
Heather
is
a
mean
to
be
consumed
and
processed
by
the
service
functions.
C
B
B
Is
ask
the
minute
taker
to
minute
that
we
need
to
continue
the
discussion
of
next
header
versus
t.l,
v4
IO
am
and
o
am
so
that
we
don't
reprieve
reprieve
this.
Thank
you.
Dhruv
I
see
you
nodding,
so
it's
in
the
minute,
so
it
will
remind
Jim
and
me
that
we
need
to
make
sure
this
discussion
gets
taken
to
the
list
and
we
drive
clarity
quickly.
We
do
not
there's
no
point
in
dragging
this
one
out,
but
we're
gonna
have
to
continue
around
the
list
anyway.
We're
not
gonna
resolve
it
in
the
room
right
now.
B
B
C
B
So
we're
just
this
is
a
home
for
preference
for
something
like
if,
when
carrying
information
like
OEM
information,
do
we
want
first
prom
will
be,
do
you
want
to
carry
it
as
a
TLD
it'll,
be
a
single
md2
type
TLV
we're
not
talking
about
disassembling
there
OEM
stuff?
No,
no,
it
would
be
a
single
blob
just
in
the
Elvie
and
then
the
second
of
the
alternative
will
be.
Would
you
like
it
carried
us
in
next?
Ten?
Would
those
who
would
like
to
see
it
carried
as
a
TLV
hum
now?
Please.
C
B
C
So
next
thing
was
really
I.
Think
it's
discussing
one
of
the
use
cases
for
IOM
and
well.
We
have
it
here
and
we've
looked
at
proof
of
concept
for
a
couple
of
times.
Let
me
just
quickly
recap
the
concept
and
well
then
discuss
what
we
changed
from
an
overall
an
obscure
perspective.
Next
slide,
I
think.
C
C
Traffic
needs
to
go
through
ABC.
That
means
it's
compliant.
If
it
bypasses
B,
it
would
be
not
compliant
and
the
responsibility
person
would
have
trouble.
So
how
do
we
do
that
from
a
concept
perspective?
Next
slide,
we
take
a
secret.
We
split
the
secret
into
multiple
portions.
We
get
every
single
node
a
piece
of
the
secret
and
then,
as
the
packet
progresses
through
the
network,
it
picks
up
pieces
of
the
secret
and
they'll
Iran.
C
If
you
look
at
the
draft
next
slide,
there
is
two
options
in
there
from
a
algorithm
perspective,
one
users
shimu
secret,
sharing
it's
very
light
on
computational
effort,
so
it
all
stone
from
a
verifier
perspective
or
a
perspective
to
two
additions,
one
multiplication
and
one
modular
prime
operation.
There
is
another
mechanism
that
it
sort
of
preserving
but
requires
nested
encryption,
and
so
the
chip
needs
to
go
and
support
something
like
a
es.
We
have
the
two
options:
one
cheap,
but
not
all
the
preserving
the
other
one
more
expensive,
but
order
preserving
in
the
draft.
C
C
Those
guys
would
well
apply
or
update
the
the
proof
of
transit
metadata
that
we
have
there
in
order
to
well
tell
you
that
the
particular
packet
visited
the
particular
note
there
is
so
the
service
functions
themselves
would
take
care
would
participate
in
in
P
ot.
They
would
also
receive
the
secrets,
update
the
secrets
and
alikes
from
a
controller,
the
results
in
another
mode
that
you
can
go
and
think
of
which
is
harder
to
implement
but
possible.
C
If
you
go
to
the
next
slide,
where
a
service
function,
folder
or
well,
somebody
else
in
the
chain
would
go
and
work
on
behalf
of
a
service
function
that
does
not
yet
implement,
prove
transit,
a
little
bit
of
an
art
operation,
because
well
you
got
to
go
prove
that
it
makes
it
through
a
service
function.
Why
should
somebody
else?
Do
it
on
your
behalf?
Well,
maybe
you
have
a
trusted
entity.
C
That
is
a
bit
of
a
difficult
operation,
because
it
would
mean
that
we
would
need
to
go
and
cache
the
traffic
though,
and
and
well.
We
would
need
to
cache
the
Quixote
metadata
for
the
time
that
the
traffic
traverses
the
SF
and
comes
back
and
then
reapply
it.
It's
been
doable,
we've
done,
IOM.
Caching
and
again,
there
is
open
source
code
on
that
for
another
use
case.
C
Where
we
hand
the
packet
to
the
application
when
it
comes
back,
we'll
reapply
that
metadata,
but
well
it's
a
use
case
and
we
can
go
and
document
that
as
part
of
the
draft.
So
next
slide.
So
what
has
changed
well,
what
has
changed
is
the
scope
and
the
working
group
Charter
so
that
well,
the
working
group
by
now
is
to
go
and
also
focus
on
privacy
aspects
and
security
aspects
and
proof
of
transit
is
definitely
one
and
it's
been
even
outlined.
C
If
you
go
to
the
next
slide
and
RC
8300,
there's
been
a
hidden
trove
of
transit
already
and
as
part
of
the
review
comments
that
we
received
when
8,300
was
progressed
to
to
RFC,
there
was
a
notion
of
well,
you
guys
need
to
go
and
fix
security.
That
is
a
portion
of
the
puzzle.
It's
obviously
not
an
our
entire
and
comprehensive
solution,
Jim
what
you
might
go
on
to
the
next
slide
hello.
C
So
we've
done
this
thing
now
a
couple
of
times,
so
everything
everybody
should
be
familiar
with
the
concept.
8300
references,
P,
ot
security
privacy,
are
part
of
the
Charter.
So
question
is:
can
we
adopt
that?
What
we
can
do
we
have
these
two
slides?
We
can
add
a
deployment
section
and
just
say
well,
this
is
how
would
you
use
it
and
that
would
answer
the
question
that
was
earlier
race
on
the
floor.
What
do
you
do
with
this?
A
C
B
G
Sorry
right,
I
haven't
read
this
one,
but
since
your
thought
about
the
use
cases
I
think
there's
value
here
right
to
to
have
this
verification.
I
guess
the
thing
I
didn't
see
is
that
this
works.
If
it
goes
through
all
the
services,
basically
in
the
service
chain
right
in
either
direction,
you
can
verify
what
happens
for
the
traffic
that
is
mid
path
basically
and
goes
back
the
other
direction.
I'm
the
same.
How
can
you
verify
I,
guess
or
differentiate
the
two
different
types
of
traffic?
I
G
C
G
See
I
got
that,
but
maybe
we're
gonna
take
offline,
but
I
guess.
My
point
is
that
in
the
case
where
I
guess
it's
the
mid
path,
the
case
right
chocolate
goes
to
a
service
change,
my
service
function
and
then
we're
passing
it
back.
So
now
the
packet
go
see.
The
direct
and
service
functions
are
2,
&
1,
so
now
you're
verifying
that
direction.
You
don't
have
two
parts
of
the
so-called
secret,
then
you
know
it's
a
legitimate
is
the
not
legitimate
I
just
I
mean
maybe
something's
discus
well,
did.
C
G
C
I
I
agree:
it's
a
mess
and
you
need
to
go
and
keep
session
state.
You
need
to
cash
that
information
and
if
you
running
this
whole
thing
at
tens
of
gigabits,
you
better
have
a
pretty
large
state
table,
not
nice.
What
do
you
do
if
the
thing
drops,
if
you
need
a
row,
go
recover
state,
there's
loads
of
questions
with
that?
Ok,.
G
That's
I'm
only
thinking
about
that
specific
case.
I
was
actually
thinking
more.
The
Pazzi
case,
were
you
know
like
a
PCP,
foxy.
Ok,
so
ok
I
mean
we're
working.
Oh
we're
chance
to
uncheck.
Basically
a
birth
verify
that
so
but,
like
you
said,
there
are
different
cases
too
right.
You
know
I
just
wondering
that
when
a
transits
out
right
now
I
know
what
we're
doing
is
verifying
that
it
went
through,
but
the
key
side,
sometimes
we
may
not
have
so
I,
just
want
to
make
sure
we're
covering
some
of
these.
J
K
D
K
Illya,
sorry,
oh
yeah
Alice
I'm
very
happy
to
see
this
work
coming
back.
We
did
we
charter,
because
security
and
privacy,
and
specifically
this
particular
work,
is
critical
to
the
functionality,
deployment
and
security
right
for
the
technology
that
this
group
is
developing
as
such
I
hope
that
it's
possible
to
have
it
mature
enough
and
gain
enough
consensus
that
we
do
end
up
with
a
standard
track
solution.
K
It
doesn't
have
to
be
this
one
drug,
but
we
need
one
and
also
to
the
previous
hum
and
such
I
mean
we
need
to
get
agreement
and
consensus
towards
one
approach
right
it.
We
can't
keep
trying
to
do
multiple
things
for
some
of
this
stuff.
It
just
increases
the
complexity
of
the
solution
and
there's
already
so
many
choices
there
that
I
think
hooks.
You
really
think
how
about
consensus
in
the
meaning
of
it
and
there's
the
technical
objections
of
things
we
just
can't
live
without.
You
know,
if
there's
a
serious
problem
with
something.
K
F
C
C
I
Samandriel
from
fi,
just
picking
up
on
what
came
to
us
saying
it
just
occurred
to
me
in
many
of
the
higher-order
services,
there
is
no
correlation
between
packets
services
rendered,
so
that
means
I
might
get
back
at
one
two
three
and
produce
a
completely
different
packet
because
of
transformations
right.
So
if
the
verification
process
acts,
let
me,
let
me
say
a
TCP
tu.
I
A
handshake
is
a
perfect
example
where,
if
flow
is
kind
of
broken
so
that
some
packets
can
be
aggregated
and
then
new
packets
can
be
produced,
but
it's
not
breaking
anything
as
far
as
the
graph
is
concerned,
or
services
or
arranger.
So
it's
just
wondering
I,
don't
have
any
objection
or
anything
I
don't
know,
but
it
might.
We
might
have
to
look
at
that.
How
this
verification
process
work,
because
not
all
the
packets
are
actually
going
to
end
up
through
the
firewall
farl
is
a
bad
example
in
some
ways,
because
viral
is
typically
packet.
I
E
G
Says
well
speculating
here,
yeah,
so
I
think
we
could
take
alkaline
because
I
think
they're
a
different
cases,
but
when
there's
epoxy
and
wants
a
little
balance,
there
epoxy
different
things
but
I
think
certain
cases.
You
still
go
through
the
entire
service
change,
even
though,
if
the
it's
been
partially
on
both
ends
right
so
I
think.
C
When
you
take
offline
and
maybe
work
out
some
more
deep,
yeah
and
I
think
in
certain
cases
and
as
I
said,
the
audio
here
is
not
what
you
hear,
but
if
you
low
balance,
there
is
nothing
stopping
you.
If
you
have
a
sequence
of
service
functions,
they're
all
implementing
the
same
thing
to
go
and
share
the
secret
across
these
service
functions
so
that
well,
if
the
ask,
is
you
go
through
a
firewall
that
does
this
particular
task?
B
But
one
of
our
points
is
we're
going
to
want
to
move
this
forward
now,
assuming
that
the
working
group
is
interested
in
moving
this
forward
in
order
to
fairly
ask
the
working
group
for
adoption,
I
think
we
need
some
sense
of
what
the
working
group
wants
in
terms
of
one
versus
two
solution
and
which
one
the
I
do
not
want
to
get
us
into
a
situation
where
everybody
agrees.
We
need
one
answer.
What
we
don't
agree
on,
which
one
that's
I've,
seen
that
I've
done,
that,
let's
not
make
that
mistake.
B
So
I
want
to
ask
a
three
branched
question
and
not
a
four
branched
question
right
now:
I
just
I
want
hums,
we
will
be
taking
it
to
the
list
for
discussion.
People
can
put
elaborations
unwise
and
all
that
which
we
need,
because
the
reasons
matter
more
in
many
senses
than
the
preference,
but
we're
looking
for
a
sense
of
preference
I'm
going
to
ask.
B
B
A
B
L
L
But
in
case
you-
and
this
is
the
first
time
to
view
this
structure
so
I'd
like
to
introduce
the
civil
and
first
and
the
sea
Salem-
is
the
past
consistency
check
om
so
for
every
SFF,
England's
SFC,
and
once
it
received
a
request
message,
it
will
take
two
actions.
Why
is
to
send
it
back
say
reply
with
the
service
function,
information
in
this
repair
message
and
anon
action
is
chosen
as
request
to
its
nest.
Sff.
L
L
From
last
meeting,
we
received
some
comments
of
this
chapter.
Thank
you
for
all
the
comments
and
the
most
important
documents
is
how
does
SF
with
multiple
SF
SSX
respond
to
Salem
request,
so
we
update
the
chapter
in
two
parts.
Why
is
to
update
the
formation
of
a
service
function,
information
sub
theory
in
an
insecure
way?
We
add
a
service
path,
identifier
field
in
this
field
to
indicate
which
service
function
has
the
serum
is
checking
and
we
reorganize
the
location
of
other
fields
in
SF
identify
our
fields.
L
L
We
are
to
scenario
English
situation.
Why
is
magic?
Multiple
service
functions
as
hopes
of
SF
key,
and
that
means
these
multiple
service
functions
attach
to
one,
as
there
are
several
hopes
of
this
SF
key.
So
the
service
intent
of
this
F
is
they
are
different
and
service
function
types
of
this
service
function.
Heads
of
these
service
functions
may
be,
may
be
different.
So
all
these
service
functioning
information
included
in
one
cell
and
message,
Siem
Reap
a
message:
every
SF
information
should
be
listed
as
separate
F
information,
sub
tourists
in
sale
and
reply
message.
L
L
L
B
Before
you
go
on
to
the
next
slide,
can
you
clarify
something
on
this
slide?
Because
there
are
two
different
ways:
load
balancing
can
be
done
at
least,
and
there
probably
are
more
because
we
allow
a
fair
bit
of
implementations
like
flexibility.
It
may
be
that
the
service
function,
forwarder
is
aware
of
the
multiple
instances
and
doing
load
balancing
or
it
may
be,
that
all
he
sees
is
something
he
thinks
is
a
service
function,
but
which
is
actually
a
load
balancer
talking
to
multiple
instances
using
any
number
of
instancing
technologies.
B
D
B
G
Cattleya
my
understanding
after
hearing
this
is
that
yeah,
you
know
either
Joey
you
bought
two
cases.
I
want.
Is
s
FF,
slow,
balancing
to
a
bunch
of
s,
FS,
right
and
I
think
this
is
trying
to
say
here
the
SSF
instances.
You
know
it's
responses
where,
if
it's
a
little
bouncer
as
an
SF
happens
to
be
a
little
balancer,
that's
a
little
balancing
other!
That's
to
me
s
FF
perspective.
It's
only
just
the
SF
right,
so.
K
G
Do
have
a
question
myself,
though,
just
to
clarify
this
I
guess
what
I'm
not
quite
clear:
it's
been
a
while,
as
in
this
message,
does
it
have
to
flow
information
as
well,
because
in
the
SFF
load-balancing
case
right,
if
it's
a
for
a
particular
flow,
maybe
the
OEM
aspect,
maybe
I
want
to
know
which
one
you
hash
the
to
alright,
for
example.
So
there
might
be
two
cases
I
once
I,
I
dunno,
you
know
what
are
the
SS
instance.
G
B
D
The
idea
is
that,
as
a
point
that
in
a
previous
diagram
that
each
SFF
responds
to
the
query,
so
if
we
have
a
hundred
s
affairs,
then
the
responses
will
come
not
aggregated
in
a
single
response,
but
rather
in
a
hundred
responses.
But
that's
what
that's
only
assuming
that
all
this
s,
ffs
are
honest,
SFP!
E
E
D
L
And
since
the
load
balance
scenario
is
a
little
complex,
so
we
have
some
issues
and
open
to
discuss
in
in
working
group.
Why
is
I
said
I
identify
our
type
and
follow
the
panel
scenario
and
the
scene,
or
at
least
this
function
have
seen,
have
seen
service
service
functioning
identifier
type
in
current
in
current
job
we
assumed
they
are
the
same.
So
all
the
service
so
is
functioning.
Identify
our
lives
to
share
the
same
service
from
service
function,
identify
back.
L
B
Well,
so
the
point
is:
if
you
want
to
measure
the
RSP,
you
have
to
have
the
flow
identifying
information
in
the
packet,
because
the
RSP
is
what
path
would
this
packet
take
and
if
you
want
to
identify
that
you
have
to
have
the
information
that
the
SF
FS
need
to
make.
That
decision
now,
sometimes
in
some
implementations,
SFPs
and
our
SPS
are
always
1
1.
Well,
then,
then,
the
question
isn't
meaningful,
but
when
they're
not
1
1,
it
is
specifically
because
some
of
the
SF
FS
are
paying
attention
to
the
flow.
B
Identifying
portions
of
the
packet
header
and
you
need
to
include
that
we're
not
going
to
get
I
would
hope.
You're
not
going
to
get
into
those
cases
where
reclassify
errs,
look
at
metadata
produced
by
other
service
functions
and
then
choose
to
put
you
on
different
SFP,
and
you
want
to
cause
this
check
to
actually
check
that
consistency
case.
I'm
sorry
that
makes
my
head
explode
at
least,
but
if
you
have
to
decide
what
you
want
to
accomplish
and
if
you
want
to
check
the
RSP,
you
need
the
flow
identifying
information.
L
B
A
Put
me
in
full-screen
casaya.
J
Yeah,
okay,
thank
you,
I'm,
going
to
just
give
a
quick
update
on
this
on
this
draft
version.
Zero.
Two
on
the
F
of
my
quarters
next
slide,
please!
So
just
a
recap:
in
this
draft
we
introduced
as
a
function
service
function
called
SLR
to
handle
what
we
call
dynamic
chaining,
it
decouples
the
service,
consumer
and
the
service
provider,
and
it
basically
creates
a
chain
when
the
service
is
requested,
using
name
based
identification
of
service
endpoints,
and
this
function
also
uses
and
I
would
say.
J
This
is
just
in
one
of
the
example
which,
where
it
uses
HTTP
as
an
application
layer
transport
to
realize
the
name
based
identification,
so
it
is
based
what
it
what
it
describes
an
extension
to
the
SFC
framework
where
URL
based
addressing
scheme
is
used
and
yessir
are
uses.
This
name
based
relationship
to
route
for
specific
instances
of
service
function.
J
B
Is
excuse
me
I,
understand
all
two
networks.
We
do
allow
transfer
net
as
a
transport
for
NS
h,
that's
l2
networks.
As
I
understand
it,
people
use
them
no
argument.
What
is
path
forwarding.
That's
not
a
term
I've
heard
in
the
IETF
or
I
Triple,
E
mm-hm,
so
you're
referencing
it
as
a
way
of
doing
something,
but
there's
no
there's
no
reference
for
it.
Okay,.
J
So
in
this
update,
we
introduced
another
use
case,
which
is
basically
they
use
the
deployment
of
third-party
cloud
service
providers
and
also
the
deployment
of
micro
data.
Centers,
specifically,
we
see
at
the
edge
of
the
network
and
that
reiterates
the
need
for
flexible
and
dynamic
chaining,
and
also
some
clarification
on
flexible
and
dynamic.
Changing
has
been
also
added
there.
So
what
is
basically
what
what
why
do
we
need
this?
J
Some
of
the
triggers
can
be
load,
balancing
and
user,
or
service
mobility,
or
also
optimization
due
to
network
and
conditions,
and
also
this
flexible
and
dynamic
chaining
is
can
be
viewed
as
as
as
a
late
binding
compared
to
the
static
binding
of
service
function
chain
and
third,
clarification
is
about
this
HTTP
as
a
transport
and
how
it
helps
in
achieving
flexible
and
late
binding
of
service
function
chain.
If
we
go
to.
J
Slide
please
so
in
the
just
to
give
a
brief
snapshot
of
the
use
case.
The
use
case
that
we
described
here
is
is
mainly
specific.
Localized
use
cases
more
at
the
edge
of
the
network,
which
requires
on-site
data
centers,
and
this
is
due
to
emergence
of
new
of
real
estate
owners
who
are
willing
to
deploy
edge
clout
resources
and
basically,
they
are
turning
towards
deployment
of
micro
data
centers
at
the
edge
and
these
data
centers
are
typically
deployed
at
multiple
internet
point
of
presence
and
what
is
happening
due
to
this
multiple
point
of
presence
deployment.
J
Now
there
is
a
trend
of
composition
of
service
and
at
the
edge,
which
is
basically
composed
out
of
this
multiple
data
centers,
and
this
kind
of
implies
that
there
will
be
data
exchange
and
collaboration
is
expected
among
these
micro
data
centers.
We
go
to
the
next
slide,
please
so
so
continuing
from
the
previous
slide.
J
As
we
see
like
this
service
composition
over
many
micro
data,
centers
is
basically
may
be
impacted
and
we
do
to
various
conditions
in
the
network,
and
some
of
the
examples
are
like
load
variation
in
the
networks
and
service
and
points
been
migrated
mobility
of
users.
So,
in
order
to
maintain
the
same
level
of
service
continuity
for
end-users
SFC
can
support
this.
J
What
we
call
also
as
flexible,
chaining
so
chains
instead
of
defining
statically
at
the
time
of
service
ability
to
create
chain
at
runtime,
is
desirable
and
also
dynamic,
chaining
as
Network
condition
changes,
user
location
changes.
This
bindings
needs
to
be
redefined
frequently.
If
we
go
to
the
next.
K
J
Please
so
now
the
clarification
that
has
been
added
as
what
is
being
meant
by
HTTP
as
a
transport,
so
I
think
the
first
bullet
is
just
a
is
an
existent
disclaimer
saying
that
it
is
being
it's
an
example
of
a
named
service
and
the
solution
can
be
applied
for
other
name
service.
Also
given
IP
and
when
you
say
HTTP
is
a
transport,
we
just
basically
say
that
we
are
kind
of
abstracting
and
using
HTTP
as
a
common
transport,
or
name
based
URI
and
end-to-end
communications
and
in
the
context
of
SFC
and
service
function.
J
What
we
have
done
is
we
have
used
our
abstracted,
the
HTTP
request
and
response
as
service
request,
and
we
are
basically
trying
to
do
this.
Routing
and
in
directions
of
this
service
request
are
nothing
but
are
abstracted
at
the
HTTP
level.
If
we
go
to
the
next
slide,
please
so,
and
then
how
it
helps
in
realizing
this
flexible
and
dynamic
chaining.
J
So
this
HTTP
request,
such
as
get
put
in
post
now,
are
routed
based
on
the
URI
associated
with
the
request,
and
these
URIs
are
I
are
basically
the
name
of
a
resource
or
the
invocation
point.
Now,
if
service
functions
could
be
identified
using
URI
or
this
name,
so
the
HTTP
request
to
an
service
function
would
be
routed
or
directed
used,
using
name
based,
routing
and
HTTP
becomes
an
application
layer,
transport
service
and
by
updating
this
naming
relationship,
service
requests
can
be
redirected
easily
and
as
and
when
required.
J
Next
like
this,
so
okay,
so
I
think
that's
the
that's
the
kind
of
the
summary
of
the
updates
in
this,
and
so
the
question
is:
does
this
kind
of
is
in
the
scope
of
this
working
group,
and
is
it
something
you
know
to
be
can
be
considered
like
and
also
the
next?
Is
this
an
ongoing
work
that
we
are
involved
and
we
expect
some
more
experiments
on
this
h,
2020
flame
project?
So
that's
the
end
of
it.
So.
I
Sumantra
away,
I
did
not
read
this
drop.
So
sorry,
if
I
am
asking
question
which
is
obviously
explained
so
bear
with
me
so
in
Jam.
Some
observation
first
in
general,
I
am
personally
opposed
to
seeing
yet
another
resolution
point
in
network
it.
Look
like
you
are
saying,
is
er
can
be
replaced
by
DNS.
If
that
can
be
done
by
DNS,
I
would
prefer
to
be
DNS.
It's
just
yet.
Another
component
in
the
network
never
really
works.
I
Secondly,
you're.
One
of
the
example
said
the
URI
best
cut,
based
on
your
I
figure
out
the
path,
I
guess
right,
so
so
typically
e
something
called
page
routing.
It
has
been
done
before
page
routing
used
to
be
used
by
Facebook.
It
is
still
use
it.
They
used
to
use
third
party
devices.
Now
they
have
written
their
own
and
the
other
way
to
solve.
I
Would
it
be
if
each
node
is
actually
a
classifier,
then
every
node
can
make
its
own
decision
and
point
to
the
next
graph,
which
is
similar
to
programmatic
graph,
so
I'm
kind
of
confused.
Exactly
are
you
just
providing
an
alternative,
or
one
should
expect
to
use
it,
because
it
had
certain
advantages
over
other
approaches,.
J
E
So
when
you
say
we're
trying
to
resolve
hops
with
you
our
eyes,
are
you
saying
that
in
the
control
plane
we
say
that
this
SF
has
reached
at
this
URI
and
then
the
SFF
is
responsible
for
mapping
that
URI
to
an
actual
layer,
2
or
layer
3
address
than
40
dan
nsh
packet
to
it,
or
are
we
seeing
that
we're
encapsulating
out
of
states
within
HTTP
and
in
40
HTTP
packets
through
web
servers
like
it
wasn't,
I
wasn't
quite
clear
on
that.
Could
you
elaborate
yeah.
J
So
I
would
say
like,
as
its
mentioned,
about
the
control
plane
handling
like
so
we
can
encapsulate
as
we
as
I
say
as
I
as
I
say.
The
service
request,
which
is
in
this
case
HTTP
request,
is
a
service
request
and
we
can
encapsulate
it
within
the
nsh
and
based
on
that
naming
we
decide
the
next.
You
know
service
endpoint,
yes,.
A
Am
I
understanding
code
when
I
read
it
was
and
I
could
be
completely
wrong,
but
my
understanding
was
instead
of
you
program
in
the
SFF
with
path
ID
index
equals
next-hop.
You
would
program
the
SFF
to
say,
path,
path,
ID
index
equals
name
and
then
somehow
you
would
resolve
the
name
to
a
next
hop
through
this
HTTP
mechanism.
Well,.
B
A
B
Slide
where
you
said
no,
but
we
have
an
alternative
name
resolution
and
then
in
your
slide
that
says
HTTP
transport.
You
induced
Kyle's
question
because
you
seem
in
that
slide
to
describe
the
case
where
the
underlying
original
packet
is
HTTP
and
the
routing
is
based
on
the
name,
the
URL
in
the
HTTP.
Well,
we're
not
doing
an
application
specific
protocol,
yeah.
J
B
We're
not
going
to
be
specific,
we're
not
gonna.
Do
things
specific
to
applications
which
run
on
names,
ICN
or
HTTP.
That's
our
problem.
Space
is
supporting
user
packets,
we're
not
supporting
user
applications
for
the
problem.
Space
NSH
is
working
on.
So,
let's,
let's
try
to
keep
ourselves
focused
on
problem.
The
question
of
what
are
the
entries
in
an
SFF
point
to
is
a
question
we
can
discuss.
Yeah
I
have
trouble
getting
my
head
around.
Why
I'd
want
a
name
there,
but
that's
a
different
question
from
what
applications
it's
got
to
be
generic
to
the
application.
B
E
J
Yeah,
if
I
can
say
that
so
in
the
SFF,
it
will
be
like
say.
Basically,
as
we
say
it
right
on,
the
change
will
be
based
on
those
names
so
say.
For
example,
example.com
2
goes
to
example,
one
common
example
2.5.
So
now
what
the
SFF
or,
if
we
think,
is
a
that
is
an
extension
of
SLR,
so
that
will
be
resolved
within
that.
What
is
example,
one
comm
means
there,
so
so
that
will
be
resolved
in
this
are
are
what
example
one.com.
E
Mean
and
based
on
that
so
I
think
part
of
my
confusions
coming
from
the
introduction
of
almost
an
entirely
new
architecture
on
top
of
SOC,
like
I've
seen
many
many
many
terms
that
are
similar
to,
but
slightly
different
from
the
terms
in
SFC,
and
it's
making
them
very
hard
for
me
to
understand
the
document.
So
if
we
could
just
describe
discuss
a
document
in
terms
of
s
of
C
would
make
this
working
group
understand
it
much
more
easily.
E
So
again,
instead
of
talking
about
an
SR
R,
what
is
the
SFF
doing
is
when
a
can
a
team
just
describe
how
a
packet
flows
through
the
SFF
in
terms
of
SFC
functionality,
it
would
be
like
it
would
be
great.
The
packet
arrives,
you
look
up
in
the
forwarding
table,
you
know
the
the
SPI
and
the
si,
and
what
does
that
result
in?
How
does
the
SFF
actually
map
that
packet
to
the
next
hop
it?
Does
it
do
a
DNS
lookup?
E
A
E
For
like
a
specific
s
of
P,
referring
to
addresses,
you
know,
there's
a
you
could
easily
refer
to
names,
and
this
is
really
just
a
property
of
your
control
plane
and
how
you
tell
your
SFF
about
the
service
functions
and
how
that
s,
FF
is
required
to
map
those
service
functions
to
actual
physical
devices.
I
tend.
E
Know
I
mean
like
if
the
control
planes
talk,
I
mean
you:
can
you
can
optimize
these
things
right,
like
you,
you,
you
update
them
once
a
second
or
something
and
have
that
do
anyways,
but
so
I
think
if
we're
talking
about
defining
any
control
plane.
That
is,
you
know
a
standard.
You
know
you
maybe
there's
a
yang
model
that
describes
how
to
use
you
our
eyes
to
represent
service
functions,
and
then
we
talked
about
how
to
render
those
down
into
SF's.
E
Maybe
that's
useful,
but
I
don't
like
this
idea
of
it
doesn't
seem
like
we're
doing
something:
that's
not
that's
incompatible
with
SFC
or
even
really
an
extension
of
SSE.
It
just
seems
like
it's
a
specific
implementation
of
SFC
like
it
really
feels
like
that
to
me
and
I'm
struggling
to
understand
how
it
is
something
unique,
uniquely
distinct
from
SFC
such
that
it
requires
all
this
new
terminology
and
it's
it.
H
H
So
that's
probably
reason
that
that
costs
the
confusion
we
outsource
all
of
these
functionalities
and
the
dedicated
SRR,
which
creates
quite
a
bit
of
the
confusion,
part
I,
think
the
discussion
goes
in
the
right
direction
to
be
more
a
little
bit
more
integrative
with
the
ideas
that,
as
I've
said,
describe
what
we're
doing
as
either
an
extension
or
if
it
just
boils
down
to
a
particular
implementation
of
SFF,
then
that's
probably
it
right.
The
background
to
that
is
an
explanation
is
not
an
excuse.
H
An
explanation
is
that
a
realization,
as
an
external
function
came
out
of
the
work
where
this,
the
the
project
work
that
Debbie
she's
referencing
in
the
last
bullet
item
where
this
work
comes
from.
So
the
first
realization
we
had
done
is
to
be
completely
outsource
the
behavior
into
into
this
SOR
and
that's
the
one
we
are
describing
and
a
craft,
but
I
think
the
discussion
is
initiated
through
your
email
and
at
the
the
meeting
here
really
points
us
towards
thinking
much
more
integrative
in
the
you
know.
H
How
could
it
work
with
the
SFF
as
it
is
at
the
moment
and
what's
the
required
extension?
If
any
or
is
it
just
implementation
specific?
Do
we
just
have
a
very
good
asset
that
that
could
well
be
there?
You
know
that
could
well
be
true,
but
that's
just
it.
The
SFF
that
we're
creating
is
just
particularly
good
compared
to
others,
but
so
that's
kind
of
it
does
help
to
actually
scope
it
down.
So
it
wasn't
a
question
with
just
a
common
and
that's
appreciate
it.
Thanks,
okay,.
G
Can't
say:
I'm
I
think
that
kind
of
hid.
A
lot
of
my
points
to
you
know
I
think
it
has.
This
has
a
bunch
of
things
in
the
job.
Sorry
I
haven't
read
it
to
you
know
it
has
a
palm
statement.
It
has
the
whole
srr
architecture
and
whole
explanation,
which
is
good
for
background.
I
thought
you,
after
you
presented
I,
can't
get
where
you're
trying
to
get
that
right.
So
the
whole
dynamic,
flexible,
I,
would
say,
servers
abstraction,
it's
kind
of
what
you're
searching
for
that.
G
You
know
in
line
so
so
I
get
the
idea,
but
I
think
how
we
achieve
it.
I
agree
with
the
earlier
point
achievers.
You
know
you
can
come
out
straight
out
what
you
guys
are
even
talking
about,
and
you
know,
and
we
can
pretty
much
I
in
my
head
I
think
we
can
pretty
much
implement
okay,
it
is
today,
but
you
have
the
general
abstraction,
as
are
two
dynamic
resolution,
basically
right,
which
is
the
way
you're
really
at
it,
trying
to
write
each
hop.
G
How
do
I
resolve
it
and
the
the
key
question
I
have
here?
Is
that
and
there's
a
fundamental
assumption
here
that
your
SFF
has
to
be
staple
to
be
able
to
ensure
this
works
properly,
because
you
know
once
you
resolve,
but
you
have
to
pin
basically
what
you
resolve
to
and
maintain
that
service
path
with
which
it
will
ends
up
being
the
RSP
at
the
end
of
day
that
you've
resolved
everything
along
the
way.
Right.
G
N
Okay,
I'm
Carlos
Barnardo's
and
presenting
this
on
behalf
of
my
cold
sores.
So
this
presentation
is
mostly
kind
of
prana
statement,
one.
Basically,
we
we
are
exploring
how
to
discover
service
functions
in
in
a
cog
environment,
so
I
will
basically
describe
what
I
mean
by
fog
environment,
the
motivation
for
that
kind
of
discovery,
and
then
some
potential
ideas
of
how
to
do
this
or
how
to
perform
that
discovery.
Next
slide,
please.
N
So
the
motivation
is
basically
that
we
are
now
seeing
that
the
visualization
is
becoming
or
is
getting
closer
to
the
final
user.
So
we
are
not
just
restricted
to
the
data
center
model,
but
we
have
resources
that
are
very
close
to
the
user
or
even
are
at
the
user
devices.
So
don't
resources
may
be
mobile
may
belong
to
different
stakeholders.
N
So
this
is
what
we
mean
as
the
tallgrass
the
edge
or
as
a
smart
at
this
kind
of
terminology,
so
basically
sources
that
are
more
volatile
monetary
unions
and
are
closer
to
the
to
the
final
user.
So
the
idea
is
that,
in
this
environment,
the
user
can
benefit
from,
or
a
device
may
benefit
from,
using
those
resources
or
functions
running
on
those
resources
that
are
close
to
the
final
user,
but
is
a
much
dynamic
environment
that
the
classical
data
center
we
entered
in
mark.
N
So
in
this
environment
we
need
that
discovery
of
what
is
available
and
not
only
the
Escorial
borås
available,
but
also
the
characteristics
of
those
things
that
are
available,
because
this
is
the
same
thing.
This
coordinate
function
that
is
meant
to
be
like
more
static
than
being
something
that
is
gonna,
be
wallet.
There's
gonna
be
gone
in
a
few
minutes
or
in
a
few
hours.
So
this.
Basically,
the
idea
of
the
motivation
from
this
can.
B
I
ask
you
to
verify
who
you
intend
the
discovery
to
be
used
by,
because
in
the
deployments
we
talked
about
for
SFC,
the
end
terminal
simply
addresses
his
packet
to
the
end
service
he
wants
to
reach.
He
doesn't
worry
about
these.
It
is
all
about
transparency
and
services.
So
can
you
clarify
because
the
way
the
bullets
are
structured,
it
looks
like
the
mobile
terminal
is
discovering
the
services
and
I
had
trouble,
putting
that
in
SFC
context.
They.
N
N
B
N
Yeah
please
next
slide.
So
basically,
this
picture
tried
to
to
show
that
scenario.
So
we
are
kind
of
we
have
this
continuum
from
the
data
center
to
the
final
use,
end
user
device
and
the
fog
is
this
continuum
where
we
have
resources,
even
at
the
run
or
at
the
end,
user
device
and
DNS
functions
in
general
can
be
run
on
any
of
these
devices
and
in
the
next
slide,
please.
Basically,
we
go
into
your
point
so
I'm,
a
while
terminal
in
this
environment
can
benefit.
So
it's
a
mobile
terminal.
N
We
play
in
that
role
of
of
discovery
in
the
desert
service
functions
to
enhance
the
the
assisting
applications
and
the
performance
of
the
applications
of
some
examples
is
the
terminal
getting
some
function
for
doing
video
transcoding
or
to
do
prevent
previous
engagements
or
to
do
locker
breakout.
This
kind
of
things
by
the
end
terminal
discovering
those
functions
and
doing
the
whole
service
function
say
so,
and
this
is
useful
for
many
different
reasons.
That's
what
is
covered
in
the
second
part
of
the
slide.
N
That
is,
this
may
allow
the
device
to
increase
the
battery
life
or
the
mobile
terminal.
So
we
are
really
looking
to
a
mobile
terminal,
centric
scenario,
to
the
reduce
to
reduce
the
communication
latency
from
the
the
mobile
device
by
using
local
backup
servers
or
gateways
that
are
available
close
to
the
use,
the
device
to
benefit
from
functions
that
require
a
benefit
from
information
that
is
local
at
the
at
the
access.
N
So
there
may
be
some
functions
that
require
information
from
the
radio
access
part
to
to
perform
the
function
right
did
they
intend
to
do
so
benefit
to
benefit
also
from
context
information
that
is
only
available
at
the
at
the
very
local
access.
So
these
are
examples
of
opportunities
brought
by
using
these
functions
close
to
the
end
user
device
next
slide,
please.
N
So
what
we
are
trying
to
look
into
mechanisms
that
allow
to
discover
these
satisfactions
so,
basically
the
characteristics
of
the
function
which
pssc
aware
or
not
the
type,
the
IP
address
of
those
service
functions,
but
not
only
to
discover
the
functions
as
I
said
at
the
beginning,
but
also
to
discover
the
characteristics
Association
associated
to
the
resources
hosting
those
functions.
So,
for
example,
the
mobility
if
the
functions
are
very
battery
power
or
not.
N
If
the
functions
are
meant
to
be
more
volatile
or
not
the
price,
if
there
is
any
associated
to
using
that
function,
the
migration
capabilities
of
those
functions,
if
we
can
move
those
functions
to
an
area
to
a
different
place,
if
the
user
is
moving,
all
these
kind
of
things
that
allow
the
mobile
terminal
to
decide
where
to
use
or
not
unavailable
service
function
next
slide.
Please.
N
Okay,
so
this
figure
basically
represent
a
couple
of
use
case
examples,
so
basically,
in
the
first
one
on
the
determined
of
the
slide,
we
we
have
a
terminal
that
is
attaching
to
the
network
and
in
the
network
there
are
service
functions
available
and
the
terminal
basically
requires
some
mechanisms
to
discover
those
service
functions.
So
there's
a
very
simple
diagram,
basically
based
on
a
request
or
basic,
on
very
big
advertisements,
from
the
network
to
the
devices
that
are
connected.
N
But
in
our
scenarios
it's
not
only
based
on
having
a
fix
or
an
available
infrastructure,
were
they
device
connect,
but
also
between
mobiles.
We
may
have
like
a
vehicular
scenario
or
other
types
of
scenarios
in
which
different
devices
interconnect
and
those
devices
have
service
functions
available
that
can
be
used
by
other
devices
that
are
nearby.
So
that's
the
the
diagram
that
we
have
at
the
bottom
of
the
figure
next
slide,
please.
So,
as
I
mentioned,
this
is
basically
more
like
a
pronestyl
main
kind
of
slide
or
presentation.
N
So
we
want
to
to
first
understand
if
the
working
group
is
interested
in
looking
into
these
kind
of
use.
Cases
as
assumed
very
well
mention
at
the
beginning
is
a
different
use
case
from
what
has
been
addressing
necessity
so
far,
and
if
so,
we
will
continue
working
on
describing
actual
solutions.
Here
we
are
just
describing
the
the
overall
picture,
and
that's
that's
it.
If
you
have
any
comment,
please
that
will
be
very
appreciative.
Hi.
E
Carlos
and
vine:
this
is
pretty
cool
and
I
just
had
a
couple
thoughts,
so
I
think
you're,
George
and
Mike
ever
who
exactly
it
was
touched
on
this
earlier.
So
is
the
terminal
actually
acting
as
the
classifier
here,
so
inserting
the
sh
encapsulation
yep?
Have
you
considered
maybe
moving
that
into
the
access
point
and
just
having
the
negotiation
of
which
serious
functions
you
want
applied,
communicated
somehow
or
the
control
plane,
or
do
you
think
that
it'll
be
too
challenging
for
the
classifier
to
actually
identify
the
particular
chain?
You
want
to
go
on.
That's.
N
That's
a
pretty
good
point:
we
we
are
now
open,
I
mean
we
are
spoiling
the
solution,
space,
that's
a
potential
solution.
It
also
depends
on
the
day
Dynamis
City,
whether
the
the
suction
access
point
is
going
to
be
always
the
same
or
we
are
changing.
So
that's
the
panels
on
the
on
the
particularly
say
that
it's
a
very
good
point,
that's
something
that
we
could
explore.
Some.
E
Other
thoughts,
okay,
really
just
had
one
other
side,
have
you
thought
about
the
multiple
uplink
case
may
be
using
pvd's
or
something
to
discover
the
information
I
know
it
doesn't
give
it
gives
you
information
about
gear
up
like
bit
unnecessary
about
yourself
to
the
wider
network,
but
that
might
be
something
to
consider
I
know.
A
lot
of
people
have
been
thinking
about
what
happens
when
you
have
multiple
ways
of
accessing
the
network.
N
That's
also
a
very
good
point
related
to
this.
It's
not
exactly
the
same
thing,
but
something
we
we
are
so
exploring
is,
but
it's
maybe
not
for
SFC,
but
in
general,
for
these
environments
to
actually
when
you
have
multiple
points
of
attachment
where
you
can
connect
to
deciding
on
which
connect
based
on
the
availability
of
the
functions
that
that
point
of
attachment
brings.
So
this
is
something
that
we
are
considering
as
well.
Maybe
it's
not
for
a
subsea
volcano,
but
is
so
so
in
this
code
and.
E
B
M
I
just
say
to
the
the
working
group
that
there's
this
MPLS
SFC
draft
that
you
may
have
noticed:
I
mean
I'm
here.
If
you
want
to
throw
vegetables
at
me,
Stewart
is
going
to
be
presenting
it
in
MPLS
tomorrow
to
try
to
level
set.
What
we're
trying
to
do
that.
The
message
and
I
have
presented
it
to
the
working
group
before
yeah.
My
message,
the
working
group
is,
we
are
not
trying
to
piss
on
n
Sh.
Okay,
n
sh
exists,
good,
go
for
it,
work
on
it
hard.