►
From YouTube: IETF102-SFC-20180719-1550
Description
SFC meeting session at IETF102
2018/07/19 1550
https://datatracker.ietf.org/meeting/102/proceedings/
A
B
Good
afternoon
everybody
as
usual,
though
well
slide
I'm
not
gonna,
go
through
it,
but
lots
of
good
information
there
so
pay
attention
to
that
brief
agenda.
We're
going
to
look
at
some
of
the
in
situ,
om
and
proof
of
transit,
where
we're
at
with
that
get
some
updates.
We've
got
a
section
on
looking
at
the
applicability
of
segment
route
into
service
chaining,
some
congestion
control
work,
that's
being
done
some
more
stuff
on
the
overlay,
om.
B
Name
based
service
function
forward
in
and
then
some
multi-domain
SFC
without
a
more
detailed
agenda
here,
I'm
not
going
to
go
through
that
in
terms
of
working
group
progress
since
ITF
100
we've
got
the
new
RFC
which
is
operating
the
network
service
header
with
next
protocol.
None
that's
been
published.
B
We've
adopted
the
proof
of
transit
document
which
were
here
or
an
update
on
shortly,
and
also
the
hierarchical
SFC
document
as
well
was
approved
by
the
iesg
for
publication.
As
an
RFC,
we
still
have
a
lot
of
work
to
do
in
certain
areas.
I
think
the
main
ones
from
the
chairs
perspective
are
some
more
work
on
the
tlvs.
We've
had
a
lot
of
feedback
in
terms
of
operators.
B
C
D
C
A
C
One
is
the
next
header
approach,
which
is
more
hardware
friendly
because
we're
doing
less
he'll
be
nesting.
The
other
one
would
be
to
use
a
more
metadata
type
2,
which
is
less
efficient
and
tense.
Well,
we
went
for
the
more
efficient
approach
within
the
current
draft.
There
is
a
little
bit
of
a
discussion
in
there
under
the
consideration
section
or
section
4.
We
could
go
and
clean
that
section
up
and
just
say:
well
let
us
be
agreed
approach
going
forward
so
that
we
are
not
really
presenting
all
these
options
on
par.
C
It's
something
that
we
can
go
do.
Let
me
know
what
people
feel.
We
can
also
keep
it
the
way.
It
is
right
now
any
thoughts,
if
not
immediate,
just
send
it
to
the
list
other
than
that.
Well,
as
I
said,
the
document
is
very
simple.
Hence
I
don't
expect
that
we
need
to
go
and
go
through
a
load
of
iterations,
so
if
it's
stable,
maybe
we
can
even
go
to
working
through
blast
call
in
the
next
meeting.
C
Let's
get
to
the
more
fun
thing,
which
is
proof
of
transit
Joel,
if
you
just
fast
forward
to
the
next
quote,
unquote
presentation,
which
is
another
single
slide,
because
I'm
just
preparing
the
stage
for
Diego.
So
the
other
document,
as
Jim
was
saying
earlier
on,
that
we
adopted
is
the
SFC
proof
of
transit
draft
and
again,
there's
been
no
content
changes
other
than
editorial
and
as
we
all
remember,
that
particular
draft
offers
two
distinct
algorithmic
approaches
to
solving
the
problem.
C
One
is
based
some
Shamir
secret
sharing,
which,
in
the
current
version
in
the
draft,
does
not
offer
the
the
option
to
preserve
the
order
or
check
the
order
that
a
particular
chain
has
been
traversed
in
order.
So
you
can
check
that
the
particular
set
of
nodes
has
been
visited,
but
not
whether
they
have
been
visited
in
a
particular
order.
The
other
approach
which
uses
nested
encryption
has
that
particular
capability
at
the
expense
that
you're
using
nested
encryption,
which
typically
is
more
compute
intense
or
you
require
specific
Hartwood.
C
That
Diego
is
going
to
go
talk
about
in
the
middle
minute.
On
top.
So
maybe
we
can
just
pause
here,
half
Diego
present
and
then
come
back
to
that
particular
discussion
as
part
of
Diego's
session,
because
that
would
mean
we
can
go
and
clean
up.
The
document
streamline
it
quite
a
bit
with
these
additions.
Llego.
Why
don't
you
just
swing
by.
F
Okay,
so
since
France
nice
introduction,
I
think
that
everything-
almost
everything
is
said
but
anyway,
just
for
you
to
to
have
an
EVs
is
a
basic
proposal
that
we
static
works
working
some
time
ago
and
that
we
share
with
his
team
then
with
the
shares,
then,
with
all
of
you
just
to
have
an
idea.
Basically,
it
is
to
support
that
pottery
solder,
which
is,
we
believe,
is
a
strong
requirement
in
many
cases,
and
this
is
something
that
is
also
being
acknowledged
in
the
document
right
now.
F
We
have
tried
precisely
because
of
this,
to
build
this
as
an
extension.
So
the
idea
is
that
in
principle,
looking
at
how
what
we
propose,
we
should
be
able
to
make
it
the
use
of
ordered
pot
or
another
pot.
A
part
of
the
level
of
assurance
that
and
the
operator
of
the
network
wants
to
keep
on
the
on
the
deployment
and
well
something
that
comes
came
to
our
minds
when
thinking
about.
That.
Is
that,
for
example,
if
we
managed
to
build
these
and
to
have
a.
G
F
The
report,
something
that
can
be
achieve
as
well
to
some
extent,
is
that
basically,
at
the
station
of
the
topology,
you
can
verify
the
certain
properties
about
the
topology
that
the
packets
in
the
packets
are
following
a
particular
path
in
the
network,
and
you
can
verify
that
you
can
imply
that
there
are
some.
You
can
attest
to
some
extent
that
the
topology
that
you
intended
to
have
is
a
easing
in
force.
F
So,
basically,
the
method.
What
you
have
in
the
upper
part
is
essentially
what
is
right
now
in
the
pot
draft.
The
idea
that,
at
each
link
between
two
every
two
nodes,
we
are
change
the
CML
and
the
random
value
and
at
the
end
they
verify
what
the
verifier
does
is
to
verify
that
the
CML
that
it
has
received
is
equal
to
this
to
the
addition
of
the
secret.
It
has
plus
the
random
value.
F
Basically,
so
you
would
at
each
hop
the
each
node
is
having
to
the
to
the
the
header
of
the
packet,
the
combination
of
the
the
combination
of
the
results
of
the
calculations
of
the
poly
neem
polynomial
coefficients.
This
has
passed
the
random
value
that
also
regionally
inserted
by
the
the
ingress
point.
Simply
what
we
propose
is
that,
at
the
same
time
that
we
are
the
controller's
distributing
these
polynomial
coefficients
to
the
different
nodes
it
provides.
F
Additionally,
what
we
call
a
mask
and
that
mask
is
used
to
is
use
to
that
mask,
is
assigned
to
each
link
not
to
each
note
which
link
connecting
two
nodes
and
whenever
one
node
is
receiving
a
packet.
It
uses
the
ingress
mask
at
this
node
to
put
in
clear
the
the
coefficient,
but
the
the
polynomial
value,
plus
the
random
value,
make
the
calculations
and
beef
sending
it
down
string.
F
It
uses
the
egress
mask
to
build
to
build
the
value
of
this
and
they
be
sending
out
that
way
whatever
when
at
the
end
of
the
of
the
chain
or
at
the
end
of
the
path.
The
very
file
makes
a
professor
modification.
It
performs
exactly
the
same
verification.
There
is
no
change
on
the
on
the
computations
that
are
made
at
each
node.
F
It
can
verify
that
if
the
Equality
holds
is
because
the
over
of
the
links
have
been
has
in
the
intended,
because
otherwise
the
the
application
of
the
link
mask
would
have
failed
and
they
and
the
values
of
the
CML
at
any
and
at
each
point
and
the
random
value
book
that
being
altered,
we
call
it
a
mask.
Originally,
we
started
calling
it
a
key,
but
we
decided
to
call
it
a
mask,
because
we
wanted
to
remark
the
fact
that
these
are
a
very
simple
computational,
computationally,
simple
mechanism.
F
What
we
are
proposing
in
the
current
text
we
have
is
to
use
so
so
modest
a
has
seen,
for
example,
a
proposal
that
Jack
of
Shine
has
shared
with
me
of
an
idea.
He
was
thinking
about
about
using
a
product
product,
mod
modulus,
the
D
Prime.
There
are
other
potential
operations
the
via
the
basic
idea
is
to
have
this
operation.
Computationally,
simple
and
lemon
zest
is
that
all
calculations
at
all
nodes
and
on
the
and
the
final
verification
are
kept
without
any
change.
Well,
next
steps.
Our
idea
is
to
incorporate
this.
F
This
change
in
the
in
the
puff
Draft
likely
as
a
new
version
of
section
the
current
section,
3
5,
that
is
about
other
pot
and
for
sure
that
we
need
to
have
to
update
the
security
considerations,
because,
if
you
start
playing
with
this,
you
need
additional
thing
about
how
you
manage
the
masks
about
which
is
the
most
adequate
masking
operation
while
making.
Why
not.
So
as
a
mask,
for
example,
and
ideas
about
the
discussions
are
promoting.
That
probably
would
need
to
be
updated
whatever.
F
H
C
Just
the
association
of
note,
n
to
n
plus
1
right,
because
what
ethica
effectively
happens
is
what
we
didn't
have
so
far
is
an
association
of
no
10
and
oh
no
10,
plus
1.
What
are
you
doing
is
at
no
10
you're
distorting
CML
so
that
only
the
node
n
plus
one
who
can
reverse
the
distortion
in
a
symmetric
operation
can
make
sense
out
of
CM
suck.
Yes,
exactly
so
you're
just
providing
a
means
to
go
and
associate
these
two
elements
with
each
other,
so
there
is
no
necessity
of
a
link
or
anything
between
that.
C
C
A
F
C
Can
we
get
maybe
ascends
in
the
room
whether
people
like
that
approach
and
whether
we
should
go
and
really
consider
I
think
there's
two
things
that
we
can
go?
Do
we
can
first
of
all
obviously
fold
that
into
the
draft
and
then
carry
on
with
the
two
options
that
we
have?
Maybe
that's
the
first
interim
step
and
then
on
top
of
that
in
the
next
meeting,
decide
whether
we
really
want
to
go
in.
We.
A
Don't
even
have
to
wait
for
the
next
meeting.
It's
probably
sensible
to
just
put
it
in
the
draft
as
a
first
step
so
that
we
cried
trace
the
breadcrumbs,
but
as
soon
as
you've
done
that
I
think
we
can
reasonably
ask
the
working
group.
Can
we
now
make
this
the
only
option
for
addressing
that
problem?
We
don't
need
to
wait
for
the
net
for
November,
okay,.
A
C
But
then,
on
top
of
that,
we
can
go
and
see
whether
people
have
a
feeling
towards
one
or
the
other,
whether
we
really
want
to
go
and
with
one
option,
which
would
be
my
preference
and
then
maybe
we
have
another
revision
and
can
go
and
settle
the
overall
argument
in
the
next
meeting.
Wonderful,
thank
you.
Thank
you.
I.
I
I
So
we
thought
that
it
might
be
interesting
for
you
to
to
hear
about
this
proposal,
and
maybe
you
can
you
can
provide
us
some
feedback
and
also
this
is
not
a
comparison
between
an
SH
and
segment
ro
team
and
I'm,
not
going
to
argue
about
which
one
is
the
best
for
service
training.
I
believe
that
both
proposals,
both
architectures,
have
their
values
and
they
just
have
different
use
cases
in
my
opinion,
anyway.
I
So
the
context,
this
draft
is
based
on
on
two
other
drugs
that
have
been
around
for
some
time
now,
and
these
are
the
segmenting
architectural
draft.
They
both
mentioned
that
a
segment
can
be
associated
to
any
type
of
instructions
that
can
be
topological
or
service
based
and
while
the
topological
instruction
has
been
quite
studied
and
they
are
well
defined
and
well
understood.
Now
there
I've
been,
there
has
been
little
walk
on
the
service
instructions.
I
I
The
service
itself
is
also
a
pack
to
the
head
and
the
intermediate
nodes,
and
what
does
that
mean?
That
means
that
what
the
hidden
and
all
the
nodes
actually
see
is
a
segment,
and
they
only
have
to
know
how
to
forward
the
packet
based
on
this
segment.
They
no
need
to
know
what
is
the
actual
service
associated
to
the
segment.
That
is
a
local
knowledge
of
the
node
that
instantiate
the
segment
and
the
controller
or
the
entity
that
computes
the
path
and
builds
the
seedless.
I
This
service
segments
can
be
as
a
4s,
MPLS
and
4-h
services
for
s
MPLS
the
service.
It
is
simply
an
MPLS
label
like
any
other
sip,
and
it
is
allocated
on
an
MPLS
router
that
will
receive
the
packet
but
the
label
and
then
either
transmit
the
packet
to
the
service,
with
the
label
stack
still
on
top
of
it.
If
the
service
is
MPLS
capable
o,
it
will
apply
a
proxy
function
and
first
remove
the
MPLS
label
stack
before
sending
the
packet
to
the
service
and
then
reapply
the
label
stock.
When
the
packet
comes
back.
I
Okay,
that
seed
can
be
either
taken
from
the
global
block
on
the
local
label
block
that
really
depends
on
the
depend
on
the
use
case.
If
it's
taken
from
the
global
block,
then
the
service
it
can
be
reachable
from
any
node
in
the
MPLS
domain.
If
it's
local,
then
you
need
a
previous
segment
that
will
static
traffic
up
to
the
node,
where
on
the
local
segment
is
instantiated,
but
that
is
the
same
for
any
other
type
of
segments.
I
I
Then,
in
terms
of
metadata,
there
are
several
ways
to
carry
the
metadata
and
it
really
depends
what
kind
of
metadata
were
talking
about.
If
we're
talking
about
simply
a
tenant
ID,
then
we
can
use
the
VPN
segment,
and
that
is
an
MPLS
label
or
national
basis.
If
that
is
at
the
end
of
the
segment
list
and
identifies
the
tenant.
I
If
we
need
to
do
some
group
based
policy
type
of,
if
we
need
some
group
based
policy
type
of
metadata,
then
the
segment
routing
header
tag
field
would
be
the
place
to
put
that
information
and
for
other
types
of
metadata
that
could
not
be
represented
as
a
segment
or
would
not
fit
in
the
tag
field.
We
have
in
the
same,
addressing
header
tlvs
that
we
can
use
for
for
carrying
metadata.
A
J
I
J
K
Hi,
this
is
mantra
from
Siena
I
just
wanted
to
respond
to
Greg's,
or
maybe
ask
for
a
better
clarification
on
what
he's
asking.
So
as
far
as
I
know-
and
you
know,
as
far
as
this
drop
is
concerned,
you
have
a
set
of
seed
lists.
Some
of
them
represents
the
services,
so
it's
in
terms
of
doing
an
OEM
at
different
planes,
whether
it
is
for
the
transport
or
whether
it
is
for
the
service.
It
is
all
the
matter
of
what
seed
list
you
are,
including
for
that
OAM
packets.
K
A
You
want
to
use
the
same
service
chaining,
but
since
most
applications
don't
really
know
what
to
do
with
OAM
packets
because
there
are
applications
with
a
job
to
do.
It
is
helpful
to
be
able
to
tell
oh.
This
is
an
OEM
packet
and
that's
the
link
to
the
service.
So
I
cannot
do
that
or
do
something
different
over
it
and
that's
harder
if
everything's
just
a
label.
Now
that
doesn't
mean
you
can't
make
it
work,
it
just
means
there
seem
to
be
some
complexities
that
I
think
Gregg
is
asking
about
yeah.
J
I
This
om
aspects
will
require
some
work
and
it
may
be
most
probably
it's
more
difficult,
with
asan
pls
than
as
services,
but
for
a
research,
what
we
have
defined
is
an
OEM
beat
in
the
segment
rating
header
that
allows
us
to
identify
om
packets
and
form
the
service
segments.
We
would
steep
the
service
processing
when
we
see
a
packet
with
the
OMB
set,
and
we
would
do
some
some
other
processing
instead,
some
oil
and
related
processing
instead,
one.
K
One
more
comment
and
I
want
to
preempt
one
his
so
I
think
the
point
is
going
to
make
I
that
that
train
has
left
the
station,
because
there
are
any
other
drops
with
where
the
the
service,
the
MPLS
labels
are
being
used
or
the
labels
themselves
are
used
as
a
service
identify.
There
are
two
other
drafts.
Actually
that
talked
about
this,
and
this
is
the
third
one
in
the
service
chain.
So
I
know
your
last.
L
Greg's
comment
and
roodaka
rakia
and
Greg
Greg's
command
points
to
the
stuff.
Fundamentally,
we
trade
of
here
for
a
simplicity
of
implementation.
We
trade
of
some
of
the
functionality
of
a
you,
know,
isolated,
a
message
by
service
implementation
and
I
think
it
would
be
beneficial
for
everybody
if
we
start
putting
into
the
draft
certain
acknowledgement
of
those
trade-offs,
because
there
are
things
that
we
like
trade-offs.
There
is
nothing
for
free,
so
some
things
will
not
be
possible
and
it
will
be
very.
It
should
be
very
obvious
to
the
reader
of
the
draft
what's
possible.
L
What's
not
and
those
are
good.
You
know
in
many
cases
this
will
be
a
good
trade-off
to
do
in
other
cases
it
may
not
and
will
make
certain
problems
out
of
scope,
because
we
just
admit
those
are
the
limitations
and
I
think
that's
what
we
need
to
make
it
clear.
We
need
to
make
it
clear
that
this
is
a
trade
of
simplicity
versus
flexibility
vernissage,
because
we
do
tie
it
back
to
transport
which
not
necessarily
is
desired.
In
some
cases,
yeah.
B
So
the
basic
intention
of
the
draft
we
described
to
application
scenarios
there
are
more
than
two
but
I
think
these
two
really
highlight
the
the
applicability
of
where
the
network
service,
header
and
segment
routing
can
be
deployed
together
to
support
the
SFC
use
cases
in
a
in
a
manner
that's
efficient,
but
also
maintains
the
separation
of
the
service
and
the
transport
planes,
which
was
the
original
intention
of
the
SFC
architecture
that
we
documented
in
RC,
76,
65,
so
scenario.
One
looks
at
simply
using
segment
routing
as
the
transport
technology
between
s,
ffs
and
NS.
B
H
is
carried
beneath
segment
routing
to
do
the
service
chain
in
peace
and
then
the
second
scenario
looks
at
integrating
the
NS
h
with
segment
routing,
whereby
we
actually
use
the
segment
list
of
very
similar
to
what
Francois
Rhodes
talked
about
in
his
draft,
but
instead
of
using
a
service
sid,
the
sid
basically
says
oh
there's
n
sh.
That
follows.
I
need
to
pop
this
segment:
routing
stack
and
I'm
going
to
use
n
sh
in
the
service
plane
and
I'll
show
you
some
pictures.
B
This
is
just
an
example.
There
are
plenty
of
other
examples,
but
it
highlights
the
point
and
then
across
the
Metro.
Maybe
you
want
to
do
some
kind
of
traffic
steering
to
get
the
the
requirements
that
you
need
in
the
in
the
forward
end.
So
this
simply
is
just
carrying
n
SH.
Underneath
the
transport,
the
transport
happens,
to
be
segment
routing
rather
than
GRE
or
IPSec,
or
any
of
the
other
Inc
transport
encapsulations
that
are
available
to
us,
pretty
straightforward,
I.
Think
if
you
read
the
draft,
it's
it's
reasonably
clear
in
the
draft.
B
B
The
clear
advantage
of
this
is
that
it
gets
rid
of
all
of
the
complexity
of
having
to
have
VLANs
between
the
services
and
the
and
the
s
ffs,
the
n
sh
path
identification
gives
you
a
very
nice
way
of
of
removing
all
of
that
complexity
and
the
other.
Obviously
these
are
the
stated
benefits.
I'm
not
going
to
bore
you
all
with
this.
You
can
read
the
draft,
but
it
just
goes
through.
What
we
see
is
some
of
the
stated
benefits
of
that
second
scenario.
B
Encapsulating
details
are
in
the
draft
and
I'm
going
to
bother
going
through
this,
but
it's
simply,
we
carry
ns8
under
the
segment
round
in
stack,
whether
it
be
SR
MPLS
under
the
label
stack
or
whether
it
be
sr
v6
under
the
ipv6
encapsulation
so
conclusions.
The
purpose
of
the
draft
is
really
to
show
that
the
the
two
technologies
are
complementary
is
not
to
try
and
say:
nsh
is
much
better
than
segment
routing
or
segment.
Rounding
is
much
better
than
nsh.
B
The
other
reason
for
this
was
that
the
SR
based
SFC
has
several
options,
each
of
which
has
pros
and
cons
again
I'm
not
going
to
go
into
all
of
those
I'll
be
happy
to
have
a
conversation
with
anybody
that
wants
to
have
that
conversation.
It's
very
clear
on
and
on
SR
MPLS,
there's
a
lot
of
things
that
it
simply
cannot
do,
especially
in
the
metadata
fields
and
with
SR
v6.
You
know
the
main
issue:
there
is
the
length
of
time
we
have
to
wait
to
actually
get
something
that
we
can
deploy.
B
D
Gara
Darlington
I
have
a
question
on
that
slide,
which
you
had
about
the
stripping
of
the
SR
header,
which
slide
sorry
this
one,
this
one
so
you're,
defining
a
new
behavior
by
stripping
the
side
header
when
you
send
it
to
the
service,
and
then
it
comes
back.
So
it's
on
a
standard
track
or
informational.
The.
B
The
only
behavior
is
that-
and
this
is
something
we'd
have
to
discuss
our
guests
through
the
mailing
list,
but
the
the
behavior
required
is
that
you
need
to
put
when
you
receive
the
NS
h
packet
back
from
the
service.
It
needs
to
understand
for
that
particular
path.
Identifier,
it's
not
gonna,
do
a
look
up
on
the
NS
agent
and
and
the
the
path
ID
and
the
index
to
do
the
forward
in
it's
simply
gonna.
B
Look
at
that
path
and
say
this
needs
to
have
a
segment
routing
stack,
pushed
onto
the
packet
and
forwarded
based
on
the
segment
routing
stack.
So
there
is
a
there
there
isn't.
There
is
a
an
implication
there
that
we
need
to
certainly
talk
through
so.
D
In
any
environment,
you
have
either
some
kind
of
transport
which
is
already
set,
whether
it's
MPLS
or
IP,
or
something
right,
I'm
trying
to
figure
out
in
which
scenarios
we
would
have
a
situation
where
you
have
nsh
deployed
right,
but
the
transport
is
constant
yeah
and
you
also
need
segment
routing
for
traffic
engineering
yeah,
which
is
a
scenario
where
we
need
two
headers
right:
NSS
header
and
a
segment
ordering
header.
It's
not
clear
to
me
just
oh.
B
Okay,
so
this
picture
would
basically
shows
it
so
in
this
case,
where
you
want
in
to
do
segment
routing
between
data
centers,
for
example,
to
maintain
some
kind
of
SLA.
In
this
case,
what
you're
doing
is
you're
carrying
nsh
under
the
segment
routing,
because
the
other
data
center
wants
to
continue
the
chain
in
the
data
center
itself.
So
in
this
picture,
you've
got
a
service
chain
where
you've
got
service
one
in
data
center
one
and
then
service
two
is
in
another
data
center.
B
D
Picture
makes
sense
sorry
this
is.
This
is
fine
what
I'm
trying
to
understand,
because
you
started
this
presentation
saying
there
are
scenarios
where
it
could
be
different
kind
of
transports.
Yes,
right
in
this
situation,
you
have
a
transport
which
says
MPL
in
the
MPLS,
in
the
data
center
or
or
maybe
IP
in
the
data
center
MPLS
between
the
data
centers
and
you
have
IP
again
in
the
data
center.
Your
transports
are
constant.
I
already
have
a
segment
routing,
which
is
there,
which
is
doing
a
traffic
engineering
with
my
entries,
DC
traffic
and
within
the
DC.
D
B
And
it
maybe
would
have
been
easier
in
this
picture
in
the
red
transport
fighter
set
VX
LAN.
That
would
have
been
the
simplest
way
to
put
it.
So
I
could
change
that
picture.
So
what
we're
really
saying
is
in
the
data
centers
in
this
case,
where
there
is
no
segment
routing
at
this
point,
that's
not
to
say
there
might
not
be
in
the
future.
Maybe
there
is
maybe
there
isn't
some,
maybe
some,
maybe
not
in
this
case
I-
don't
have
any
segment
routing
capability
in
these
data.
Centers
they're,
simply
V
X
LAN.
N
Can't
Leo
I
sure
I
want
to
I
mean
I.
Think
I
think
this
is
a
good
example
actually
of
where
you
have
different
types
of
transport
domains
by
a
QB,
MPLS
or
image
via
clan,
ipv4
or
IMEI
said
I.
Think
this
hypothetical
example,
but
this
kind
of
justify
why
we're
having
the
two
layers
being
split
right
so
so,
of
course,
I
think
this
approach
is
very
favorable
to
Innis
aging
by
being
able
to
maintain
that
alright,
so
yeah
five
things
a
good
idea.
Thank
you.
H
L
O
H
O
H
H
P
Jim
Rajeev.
Oh
sorry,
so
there's
a
merit,
of
course
in
in
having
to
have
both
SR
and
NS
h
coexist,
but
the
the
perceived
challenge
would
be
the
SFF
one
as
an
example
which,
instead
of
having
to
deal
with
an
SH
table,
lookup
independently
an
SR
table
lookup
now
we
may
have
to
interchange
them
so
I
do
an
NS,
h,
lookup
I
gotta
get
an
SR
outgoing
set
list,
or
vice
versa.
That
means
more
state
that
gets
created,
which
is
a
lot
more
intricate
and
and
related.
P
Then
then
it
should
be
so
perhaps
one
thought
process
that
you
could
consider
the
carry
the
Assam
stack,
which
is
incoming
in
maybe
the
metadata
which,
when
it
comes
back,
SFF,
doesn't
need
to
do
a
lookup
in
NSS.
He
just
does
the
look
up
in
that
metadata
used
that
to
do
a
lookup
back
in
the
SR.
So
from
the
forwarding
looker
point
of
view,
nothing
really
changes.
Yep.
B
Yeah
it's
another
option:
I
I
mean
I
should
say:
I
I
mean
I'm
I'm,
not
one
of
the
people
that
buys
this
argument
about
state
I.
Think
it's
a
bogus
argument.
Frankly,
and
but
but
that's
okay,
yeah,
so
I
I
don't
see
an
issue
with
the
amount
of
state
and
and
if
I
did
I
wouldn't
be
advocating
nsh
because
there
is
state.
The
question
is:
is
that
actually
a
problem?
I?
Don't
think
so?
But
you
know
I
may
be
smarter
minds
than
me.
B
H
Q
N
I
actually
want
to
say
this
earlier.
I
forgot
much
I
thought
the
other
thing
that
wasn't
mentioned
here
with
the
OEM
aspect
right
in
some
ways,
this
links
in
there.
Well,
what
is
this
thing
is
that's
the
OEM
alright,
so
that
was
brought
up
earlier
as
far
how
to
oh
em,
for
it's,
our
Sigma,
yes
and
pls
was
not
put
up
with
stuff
right,
so
so
I
think
this
actually
now,
if
this
well,
so
it's
just
an
hour
and
a
good
example
if
I
to
fit
in
the
job
as
well.
Yep.
Thank.
L
Dog,
another
Kaos,
yes
standard
for
sure
this
picture
exactly
shows
that
Vantage
of
a
message
separated
from
the
segment
routing.
So
we
should
focus
on
that.
Quite
a
bit
shows
flexibility
that
the
other
will
not
give
us
but
will
give
us
simpler
implementation
and
om
yeah.
It
will
work
so
they
last
comment:
I
hope
we're
gonna
progress
both
of
those
in
the
same
forum
yep,
because
it
it
will
help
both
thanks.
G
This
is
a
draft
that
are
presented
earlier
in
the
week
in
the
mpls
working
group
and
we
expect
that
the
work
will
primarily
be
done
in
the
endless
working
group
I'm
just
presenting
it
here
for
the
information
of
the
SFC
working
group.
I,
don't
expect
to
be
presenting
it
here
again,
but
we
will
be
keeping
the
SSE
working
group
appraised
to
the
progress
and
you
know
it
will
copy
all
the
major
stuff
to
both
MPLS
and
sse
lists
as
it
comes
up.
G
G
So
this
is
the
encapsulation
details
in
order
to
carry
the
network
service
header
over
MPLS,
in
essence,
is
actually
very
simple.
In
green,
you
see
the
nsh
header
and
payload
exactly
as
defined
by
RFC
8300,
and
then
on
top
of
that
we
put
a
label
for
the
SFF
label,
and
then
we
have
transport
labels
over
that.
This
looks
very
simple,
very,
very
similar
to
an
MPLS
VPN
label
and
the
SSF
label
identifies
a
particular
SFF
instance
at
the
downstream
LSR
or
receiving
node.
This
allows
you
to
have
more
than
SFF
instance
at
the
downstream
LSR.
G
The
SSF
labels
are
advertised
by
the
downstream
LSR
to
an
upstream
LSR,
which
uses
an
s
FF.
So
that's
the
sending
s
FF.
It
uses
standard
MPLS
label
advertisement
in
the
control
plane
and
that
control
plane
could
include
LBP
or
RSVP
or
yang
BGP.
P,
SEP
and
I
have
a
later
slide
that
goes
into
this,
but
it's
basically
standard
MPLS
and
because
there
can
be
multiple
transport
labels
above
the
SSF
label.
G
G
There
are
some
ecmp
considerations
that
that
come
up
whenever
you
send
anything
to
an
MPLS
infrastructure,
because
ecmp
forwarding,
through
an
MPLS
infrastructure,
may
or
may
not
be
desirable
for
a
particular
SSE
flow,
and
that
really
is
a
decision
to
be
made
on
a
flow
by
flow
basis.
You
know
some
flows
when
it
will
require
in
order
delivery
and
others
not,
and
so
ecmp
may
be
desirable
for
some
and
not
for
others.
G
As
we
know,
the
NS
h
was
carefully
constructed
so
that
the
first
nibble
of
the
NS
h
book
provides
protection
to
prevent
unintended
ecmp
by
never
being
equal
to
either
4
or
6.
If
ecmp
is
desired,
MPLS
does
have
two
native
mechanisms
that
are
available
to
provide
entropy.
One
is
the
entropy
label
and
the
others.
The
flow
aware
transport
label
and
the
co-authors
are
still
talking
amongst
ourselves
as
to
making
a
recommendation
between
one
of
the
other.
We
do
not
yet
have
one
they're,
also
OEM
considerations
Gregg
if
you're
listening.
This
slide
is
for
you.
G
G
I've
been
asked
to
compare
this
draft
with
two
other
particular
drafts.
So
the
first
of
the
two
is
a
similar
named,
but
extremely
different
draft.
That's
ready
a
draft
in
the
MPLS
working
group
draft
by
ATF
and
pls
SFC.
So
the
draft
I'm
talking
about
right
here,
work
for
the
SSC
encapsulation
transports,
SSE
packets,
with
the
network
service
header
between
SS
s
over
an
MPLS
infrastructure,
and
it
supports
all
SSC
and
features
and,
most
importantly,
it
supports
per
packet
metadata
because
we
have
the
NS
a
cheddar.
G
G
There
is
the
possibility
of
doing
per
flow
metadata,
and
that
requires
either
control
plant
extensions
or
a
new
MPLS
special
purpose
label
that
is
defined
in
that
draft
and
it
also
encodes
the
SSD
service
path,
indicator
and
service
index,
as
labels
which
I
put
in
quotes
in
the
label
stack
and
the
reason
I
put.
Those
in
quotes
is
that
they
require
processing
different
from
standard
and
pls
labels.
G
I've
also
been
asked
to
compare
this
with
draft
shoe
clad,
which
we
heard
the
two
drafts
ago,
and
so,
as
I
said
before.
My
draft
transports
FCC
packets,
with
the
NS
h
between
SS
FS,
supports
both
traditional
label
swapping
and
SRM
pls
when
you
use
label
swapping,
there's
all
the
usual
MPLS
stuff,
including
states
such
as
the
lib
in
every
LSR
along
the
way,
and
it's
really
intended
for
SSC
infrastructure's,
where
the
SSC
nsh
is
present
in
every
packet.
Drow
shoe
clad,
rather
is
intended
a
more
generalized
service
programming
in
domains.
G
Services
are
supported
with
associated
with
SIDS,
as
we
saw
it's
it's.
That
draft
is
somewhat
more
general
than
SSC
and
the
services
could
be
more
than
just
service
functions
as
we
define
here
in
this
working
group.
It
works
with
both
SR
MPLS
and
SR
v6.
It
says
some,
it
does
not
support
MPLS
label
swapping.
So
that's
one
difference
there,
because
there's
no
MPLS
State
in
the
routers
for
that
draft
and
the
NSA
is
available
using
a
TL
v.
The
NS
h
carrier
TL
v.
G
If
you
do
want
to
use
dr
xu
cloud
with
standard
SS
e
defined
SS.
So
the
next
steps
for
this
draft
are
to
progress.
The
for
future
study
items
right
now.
Those
are
the
ecmp
recommendation
and
work
on
the
control
plane
and
since
I
wrote,
this
draft
we've
actually
had
more
progress
on
the
control
plane.
G
The
authors
of
this
draft
have
sat
down
with
the
authors
of
draft
IETF
bests
and
si
it's
bgp
control
plane
and
we've
actually
determined
that
there's
already
the
mechanisms
that
we
need
in
that
draft
to
support
our
draft
here
and
we
may
have
other
control
options
going
of
here
going
forward
as
well.
But
certainly
the
best
draft
for
the
BGP
control
plan
is
one
that
we've
heard
a
lot
of
of
interest
about
and
we'll
be
working
towards
adoption,
as
I
said
before
in
the
n+
working
group,
so
I
see
at
least
one
car
one.
G
R
G
O
O
G
S
So
I'm
Donald
Eastlake
with
Huawei,
and
talk
about
the
explicit
congestion,
notification
and
condition
feedback
using
the
network
service,
header
and
IP
fix.
So
the
goal
is
to
be
able
to
collect
congestion.
Information
within
a
service
function,
changing
domain
long
paths
through
that
domain,
without
having
to
do
that
by
detecting
drops
packets,
except
in
the
extreme
cases,
and
to
communicate
condition,
information
back
to
the
classifier
or
the
ingress
so
that
it
can
take
action
to
reduce
congestion.
S
So
it's
communicated
downstream
through
use
of
explicit
congestion
notification,
which
is
defined
for
IP
and
3168,
typically
uses
two
bits.
We
use
the
same
sort
of
thing
with
those
two
bits
but
bits
in
the
network,
service,
header
and
nishan
communication
is
communicated.
Information
is
communicated
back
using
IP
fix,
which
is
defined
in
RFC
71,
there's
an
a
graph
that
extends
it
for
this
purpose.
S
So
here's
kind
of
a
diagram
of
what's
going
on.
You
only
have
an
original
sender
and
a
final
receiver
and
somewhere
along
that
path.
There
is
this
SFC
domain
with
ingress
and
egress
classifier,
and
s
FF
s
and
SS.
This
is
a
somewhat
simplified
diagram.
Obviously,
it
could
have
proxies,
it
could
have
other
things,
and
what
you
want
to
do
is
measure
the
congestion
across
that
it
could
be
that
you're
measuring
congestion
across
the
entire
path,
also,
which
is
fine,
but
you
might
not.
S
So
the
idea
is
to
use
a
couple
bits
in
the
sh
doesn't
matter
which
bits
they
are
actually
sort
of
nice
if
they're
contiguous.
But
the
idea
is
that
these
are
marked.
If
there
is
ZERO
clear,
which
is
you
know
what
you
have
currently,
that
indicates
that
there's
deep
well
in
general,
when
you're
doing
ecn.
If
the
bits
are
clear,
it
indicates
the
transport
is
not
easy
and
capable,
and
then
markings
in
those
bits
indicate
the
that
congestion
has
been
experienced
along
the
path.
Well,
actually
it's.
S
S
S
I'm
not
talking
about
trying
to
instantaneously,
go
for
less
congested
routes,
but
rather
sort
of
a
longer
term
thing
where
perhaps
you
have
long
lived
user
sessions
or
customer
sessions,
and
these
pritiiata
CLE
start
up
and
terminate.
If
you
have
a
new
customer
session
coming
along,
it's
gonna
last
for
a
while.
You
know
that
sort
of
thing
you'll
be
reasonable
to
take
some
account
of
how
congested
things
currently
appear
to
be
when
you
figure
out
what
paths
assuming
you
have,
of
course,
we're
done
two
paths
that
can
offer
the
same
sets
of
services.
S
One
thing
it
there's
a
bunch
of
details
about
how
ACN
works
and
generally
the
way
ecn
works.
If
you
have
a
a
path
you
want
to
do
easy
and
over
that
path
say
between
2's
ffs
or
something
like
that.
You
need
to
know
whether
the
end
of
that
path
can
properly
D
capsulate
and
take
into
account
and
the
ecn
marking
of
congestion
in
the
outer
transport
header,
because
if
it
can't
then
you're
basically
making
things
worse
by
assuming
easy
and
marking
along
that
path.
S
This
graph
recommends
course
doing
e
to
the
N
SH,
because
my
feeling
is
you've
tried
to
do
this
in
parallel
in
the
outer
transport
header,
you're
sort
of
writing
on
the
froth
above
this,
and
you
have
to
assume
that
every
thing
along
the
way,
including
any
IP
or
label
routers
or
whatever
label,
switching
routers
and
everything
all
faithfully
forwards.
Then
takes
care
of
this
easy
end
information,
even
though,
presumably
at
the
boxes,
along
the
way,
it
logically
discards,
the
outer
transport
header
on
the
input
and
then
adds
a
new
outer
transport
header.
S
This
seems
like
a
very
non
robust,
fragile
way
to
do
it.
On
the
other
hand,
trying
to
market
in
the
inner
payload
transport
header
is
will
only
work
if
you
are
also
doing
complete.
End-To-End
congestion
control
and
the
original
sender
is
marking
it
as
ECM
capable.
If
that's
not
true,
then
you
have
other
problems
so
there's
because
of
this,
you
do
need
to
add
a
bit
of
the
configuration.
S
So
when
you
come
in
and
you're
looking
at
the
path
and
the
index
figure
out
where
to
go,
you
need
one
bit
indicate
whether
or
not
that
hop
that
index
hop
is
going
to
be
easy
and
capable,
or
not
so,
I
guess
in
any
way
this.
What
will
work
better
if
you
have
easy
end
implemented
everywhere,
big
surprise,
you
do
have
to
have
ecn
at
the
all
the
ingress
and
egress
nodes,
but
you
can
incrementally
deploy
it
in
the
middle.
P
O
S
S
B
S
J
J
We
have
individual
draft
on
application
of
alternate
marking
method
in
an
SF
CMS
age,
so
that
allows
to
come
to
measure
on
each
note.
Cumulative
packet
delay
delay
variation
package
us
and
residential
time,
so
this
metrics
and
then
again
you
don't
need
to
export
each
and
every
measurement
these
measurements
can
be
accumulated
and
exported
theoretically
over
course,
of
either
time
interval
or
number
of
packets,
measured.
S
Sure,
well
this
this
sends
statistics
upstream
and
although
this
is
written
from
the
point
of
view
of
that
those
statistics
coming
from
the
egress
to
the
ingress,
the
if
you
see
what
the
change
is
in
e
CN
across
any
sub
interval
inside,
including
like
an
s
FF
monitoring,
the
EC
n
marking
changes
through
a
EC
and
enabled
a
service
function
or
whatever
you
can
certainly
get
other
measurements
internal
to
the
SFC
domain.
It
seemed
like
the
most
common
application
would
be
this
sort
of
overall
consideration,
but
others
can
be
supported
by
the
same
ecn
mechanism.
S
U
Stewart
Brian,
so
I
think
there's
been
some
valid
points
made
here.
I
mean
I,
remember,
Yakov
Stein
was
always
explaining
to
me
that
I'm
looking
at
delay
variation
was
a
really
good
precursor
indication
to
to
to
congestion
and
given
that
we've
got
more
powerful,
telemetry
mechanisms
we're
not
trying
to
get
it
all
down
into
one
bit
stolen
from
the
packet
I.
Think
it's
worth
looking
at
some
of
these,
because
I
think
we
could
do
better
than
EC
n
and
that'll
be
a
positive
thing
to
do
sure.
S
I
believe
the
hope
is,
that
least
with
l4s,
and
some
of
the
more
advanced
he's
en
masse
methodologies
that
he
trying
to
look
at
the
delay
shouldn't
be
very
useful,
because
there
should
be
very
little
because
it's
he
doing
active
queue
management
management
to
solve
your
congestion
problem.
So
you
have
to
allow
it
to
be
congested
enough
to
get
delays,
to
use
delay
to
measure
congestion.
U
Whatever
mean
clearly,
if
you
can
stay
out
of
congestion,
then
you're,
probably
not
going
to
measure
anything
but
I,
think
we
should
look
at
look
at
taking
advantage
of
the
more
sophisticated
telemetry
and
see
if
it
helps
any
more
than
just
using
the
one
bit
mechanism.
It
was
two
bits
for
that
today.
Yes,.
J
B
B
M
J
J
J
We
have
at
least
I'm
aware
at
IDF
of
three
hybrid
Orion
methods
that
are
alternate
marking
method.
It
triggers
measurement
in
situ
OAM,
combines
triggering
the
measurement
and
collecting
and
transporting
measurement
results
or
network
or
and
network
state
information,
which
is
a
telemetry
information,
referred
to
in
the
packet
itself
and
hybrid
two-step
method,
which
is
method
to
collect
and
transport
telemetry
information
on
path
in
a
generated
for,
though,
a
packet
which
protocols
are
looked
at
so
I
separate,
classified
them
into
groups.
Encapsulations
that
support
optional,
metadata
variable
sized
headers.
J
These
are
genève
as
if
c
NS,
h,
GUI
and
encapsulations,
that
don't
support
optional
metadata,
and
thus
I
could
refer
to
them
as
a
fixed
size
headers.
These
are
beer
and
the
excellent
GP
next
slide.
Please
engineer
so
Oh
beat
identifies
that
presence
of
OM
packet
and
gives
us
explanation
what
happens
with
that,
but
does
not
define
what
Orion
tacit
is
in
GUI.
The
mechanism
is
different.
The
GUI
uses
C
bit
to
indicate
whether
protocol
command
field
and
interpretation
of
the
protocol
command
field.
J
So,
if
CG
is
set,
then
this
field
creates
a
new
namespace
and
intended
to
be
used
among
other
protocols
by
oh
yeah.
I
want
to
note
that
if
the
idea
is
that
C
beat
means
that
this
packet
is
bunted
to
control,
plane
may
not
necessarily
well
work
with
the
Orion
methods
that
are
implemented
in
the
data
plane
and
especially
in
some
cases,
with
a
hardware
assist
because
things
like
dmg
and
performance
measurement
protocols.
J
J
I
am
and
SH
extends
some
in
regard
to
I
am
but
again
it
does
not
address
active
OAM
case
next
slide
for
the
fixed
size.
We
have
beer
RFC.
Eighty
to
ninety,
six
and
beer
took
approach,
I
believe
very
pragmatic.
If
you
this
next
protocol
filled
and
om
protocol
is
recorded
in
Ayane
registry,
the
excellent
GP,
even
though
this
does
not
support.
J
So
in
cases
where
we
have
all
beat
or
om
bit
and
next
protocol
I
see
that
there
is
a
issue
with
Bureau
am
identification
again,
I
couldn't
find
there's
very
strict
definition
of
or
en
packet
in
all
the
specifications.
So
what
I
am
tagging
is
and
that
especially
important
for
applications
that
allow
metadata.
So
is
it
om
commands
and
information
in
header
as
metadata
or
om
commands
and
information
that
immediately
follow
the
header.
J
Rfc
83
993,
which
specifies
use
of
next
protocol.
None
for
SFC
nsh
suggested
that
if
all
bits
said
and
the
next
protocol
value
is
none,
then
that
can
be
used
as
active
area
which
I
absolutely
agree
with.
The
only
problem
would
be
is
that
length
of
metadata
in
a
message
is
limited
to
512
octaves
and
in
Geneva
it's
even
more
limited.
If
we
extend
this
notion
of
non
protocol
into
Geneva
encapsulation,
its
hundred
28
bytes.
J
So
that
will
then
use
usability
of
this
approach
for
active
om
as
a
synthetic
threat
traffic
generator,
because
we
can
be
able
only
to
generate
packets
up
to
that
length
and
again
so
how
we
identify
that
or
am
command
or
information
follows
header,
which
the
most
case
usual
case
for
generating
om
test
packets
for
activate
next
slide.
Please.
J
J
So
it's
to
own
path,
om,
which
is
whether
it's
alternate
marking
method
in
situ
or
hybrid
to
step,
and
the
next
slide
is
the
the
finalizing
slide.
So
there
is
some
work
that
I'll
be
doing
with
this
draft
to
update
it
on
the
GUI,
because
current
content
is
not
AG.
I
appreciate,
Tom's,
comment
and
explanation
of
how
GUI
plans
to
do.
J
J
V
Hello,
everybody
so
I'm,
Debashish,
precast
and
I'll,
be
presenting
on
behalf
of
the
co-authors,
especially
Dirk,
was
supposed
to
present
and
he's
unable
to
be
here
today.
So
so
this
is
basically
in
an
earlier
draft.
Gg's
mentioned
there,
a
new
service
function
called
srr
was
described
and
it
was
the
function
was
to
handle
dynamic,
chaining
and
acting
at
the
level
of
named
transactions
and
in
that
function
forwarding
decisions
were
made
when
a
service
request
is
received,
using
name
based
identification
of
service
endpoints.
V
One
is
this:
extending
the
service
function
path
to
include
name
based
interactions,
we
define
something
called
NSF
B,
then
the
second
one
is
extend
Network
locator
map
to
include
name
based
next
hop,
which
is
the
definition
of
n
in
LM,
and
extend
service
function,
forwarder
to
act
on
such
name
based
information,
and
it
is
defined
as
n
SFF
operation,
and
with
that,
we
we
kept
wanted
to
keep
it
as
a
backward
compatible
to
the
car
SFC
architecture.
That
means
no
changes
to
the
functionalities
of
SFC
nodes
and
nsh
protocol.
V
So
the
first
extension
is
this
name
based
service
function
path.
So
the
realization
of
this
name
based
service
function
path
is
through
extend
through
the
extended
SFF.
Operations
is
kind
of
illustrated
in
the
draft.
Using
HTTP
transactions
where
you
are
eyes
are
being
used
to
name
a
service
function
along
the
NSF
P,
and
this
operation
is
not
just
restricted
to
HTTP
as
the
protocol
or
the
URI.
V
The
second
extension
is
in
the
network
locator
map,
and
it's
called
name
based
network
locator
map,
and
this
look
at
this
map
is
extended
with
the
ability
to
consider
name
relations
again,
since
we
use
HTTP
as
an
example.
Your
eyes
are
used
there
as
a
as
well
as
any
high-level
transport
protocol
such
as
HTTP
for
packet
forwarding,
and
the
third
extension
is
about
the
whole
operation
or
the
name
based
service
function.
A
forwarder
is
illustrated
in
this
picture
here,
so
this
shows
how
the
the
the
packets
that
are
basically
handled.
V
So,
for
example,
the
first
step
shows
that
the
packet
comes
from
an
classifier
to
NSF
f1,
which
process
the
nsh
header
to
identify
the
next
SF
by
mapping
the
nsh
information
to
appropriate
entry
in
the
name
based
locator
map,
and
it
identifies
in
the
name
based
locator
map,
as
identified
with
the
name
as
food
comm.
And
then
it
forwards
to
s
f1.
V
And
then
the
service
function,
one
processes
that
and
sends
it
n
SFF
one
again,
and
then
it
retrieves
the
next
up
information
from
the
same
network
locator
map
and
sees
that
it's
a
foo
to
calm.
But
since
the
service
function
is
not
being
locally
available,
so
NSF
on
consults
the
name
resolver
to
determine
the
suitable
for
learning
information
and
forward
this
to
the
next
n
SFF,
which
is
the
NSF
f2.
So
the
packet
from
NSF
f1
at
NSF
f2,
which
is
processed
in
a
very
similar
way
and
it
participate
processes.
V
The
NS
h
header,
to
identify
the
next
SF
mapping
and
identifies
that
it's
a
foo
to
calm,
which
eventually
identifies
it's
a
local
function
and
for
ours
it
to
the
service
function.
So
so
I
think
those
are
the
three
extensions
that
are
described
as
part
of
this
name
base
service
function
for
order.
So
the
next
step
we
are
again
want
to
hear
from
the
working
group
about
the
kind
of
the
validity
of
this
extension,
or
is
this
others,
or
is
it
in
the
scope
of
the
service
function,
worker
and
go?
R
F
F
V
F
F
Probably
would
break
the
idea
of
the
having
the
overlay
completely
independent
from
the
underling.
It
I'm
not
clearly
following
the
question.
Maybe
if
you're
resolving
the
VNS
you're
using
the
DNS
to
resolve,
they
show
how
the
next
hop
you're,
not
taking
the
decision
at
the
service
function,
level
and
notes
and
the
it's
not
a
mother
for
the
classifier.
So
you
are
you're
humping,
jumping
from
our
different
positions
in
the
yeah.
V
A
Just
gonna
run
through
a
number
of
issues
that
I
had
asked
you
to
address
in
your
presentation
when
we
discussed
this.
That
I
do
not
see
in
here,
so
the
working
group
can
keep
those
in
mind
and
considering
what
they
want
to
do
with
this.
If
anything,
having
name
lookups
in
packet,
fast
path,
processing
is
problematic
for
most
of
the
use
cases.
Sfc
is
interested
in
the
dynamics.
You
specifically
say
that
the
whole
point
of
this
is
to
be
able
to
support
things
which
move
around
where
instances
are
created
and
deleted.
B
W
A
Before
you
continue,
I
just
want
to
make
clear
to
everybody
in
the
room
and
anybody
else
listening
currently
multi-domain
support
is
outside
of
scope
for
the
working
group
and
control
plane.
Support
is
outside
of
the
scope
for
the
working
group
will
let
you
present
cuz.
It's
still.
We
have
enough
time
I'd
like
to
see
your
material,
but
people
need
to
be
aware
while
interesting.
This
is
outside
of
scope,
I.
W
W
A
W
Might
be
fermentation,
that's
not
wrong
having
a
difference.
Operators
focus
it
to
a
specific
region,
and
the
technology
fermentation
representing
our
body
needs
internally
for
an
operator.
In
addition
to
technology,
don't
mind,
there
are
other
reason
for
having
different
of
my
breaching
an
operator
such
as
different
geographies
different
performance
characteristics,
scalability
policy
sitter
next
slide,
please
so
increased
context.
W
Another
initiative
is,
for
example,
this
X
reporter
described
difference
in
a
Philemon
architectural
approach
with
use
case
related
to
network
services
provider
using
multi
play
administrative
domain,
its
life
of
the
research
group
research
project.
Several
architectural
models
are
integrating
an
FLV
management
on
Sdn
control
capabilities,
whether
the
challenges,
the
world
flexibility
and
on-demand
service
chaining,
for
example,
if
I
DX
and
the
project
and
for
my
projects
are
integrating
multiplet
administrative
domains
and
technology
through
the
collaboration
between
operator
in
the
context
of
IP
network
X
likely.
W
So
it
can
be
seen
that
at
yellow
between
potential
demise
could
be
beneficial
from
more
effective
use
of
resource
and
services
and
increasing
the
multi
domain
said
it
will
change
a
performance.
So
the
Alta
protocol
provides
a
strong
Network
information
in
full
of
map
services
that
can
be
consumed
by
application.
In
order
to
be
counted
or
aware
and
take
optimizing
decisions
regarding
traffic
loads
presently,
for
example,
D
Alto
working
group
is
discussing
the
use
of
the
alto
as
an
information
model
for
representing
Network
social
service
in
multi
domain
status.
W
For
example,
the
local
assisting
architecture
propose
a
broker
playing
working
as
a
coordinator
between
a
set
of
top-level
control,
plane
for
multi
domain
orchestration
in
4G
networks
and
the
unique
or
draft
present
the
source
or
capitation
framework.
Our
results
are
capitation
framework
for
multi
domain.
Here
this
new
boutique,
that's
analytics
both
proposal,
resourcing
Alto
as
an
information
model
to
support
results.
W
That
is
an
topology
discovery
across
different
domain,
an
aldohn
futures
and
the
bases
tension
can
be
used
to
affair,
for
example,
an
Alta
property
map
series
to
get
a
clear
global
view
of
other
potential
candidate
domains.
An
angle
to--'cause
map
services
to
compute,
inter
the
mincer
diffusion
path.
Next
slide,
please.
W
Some
I
create
a
new
page.
We
are
using
a
property
that
keep
echo
in
the
cavity
logical,
multi-domain,
sir,
if
you
change
angle
document,
this
architecture
use
a
ferry
from
chang-chang
plataform
to
release
in
terms
of
my
communication
between
top-level
control
planes,
so
in
AHA
in
a
high
level,
the
scope
of
this
changuk,
a
platter
for
content
to
tax,
providing
invisibility
and
information
from
different
than
mine
and
computing
to
the
main
service
for
some
cuts
to
sell
that
service
function,
location
from
multiple
candidate
demands.
W
In
this
context,
this
area
function
Chang
a
chain
platter
for
cap,
take
advantage
of
the
alto
services,
don't
think
in
terms
of
my
information
to
guide
the
selection
process
so
that
there's
no
mine
or
candidate
of
mine
can
be
selected.
X
life,
sweet
Oh,
the
hybrid
electrical
tell
you
would
contain,
combines
is
to
vote
and
centralize
it
contracting
in
your
use
case.
Scenarios
base
it
on
this
intelligent
approach.
W
W
So
here
we
have
on
a
specific
example,
figure
on
the
Left
shows
a
refugium
which
a
platter
for
connected
three
different
domains.
Yes,
Wang
is
2
is
3,
it's
probably
to
the
may,
provide
different
service
culture,
so
we,
for
example,
years
once
I
will
finish
on
one
edge
is
2
7
2
to
3
is
3
solution
to
each
high
level.
Control
playing
in
each
domain
can
provide
inter
domain
information
from
this
information.
The
service
function
chain.
W
A
chain
platform
creates
a
hierarchical
database
containing,
inter
the
Magna
formation,
which
information
source
is
used
by
the
anther
server
to
create
differing
Alto
Alto
web
services.
For
example,
we
property
map
in
preview
and
Arai
includes
a
property
value,
a
grouper
by
autonomous
system,
for
example.
This
value
contains
support
a
network
function.
However,
additional
properties
could
be
considered,
such
as
Network
function,
type
such
as
availability,
CPU
memory,
storage,
Exeter
and,
and
also
several
Kangol,
to
provide
cuts,
mapped
in
space.
W
The
anthikad
map
defying
a
patch
vector
as
an
array
of
autonomous
system,
represent
in
the
AES
level,
the
political
distance
for
our
giving
service
future
change
request.
They
requested
this
example.
Gopro
Service
function,
one
to
set
inclusion,
two
to
save
inclusion
tree
and
the
interdimensional
function.
Part
response
contain
a
list
of
potential
domains
to
which
other
set
to
deliberate
such
services.
In
this
guide,
we
obtained
two
different
said
function.
Pads
next
slide,
please.
W
So
from
initial
discussions,
I'll
review
identified
some
question
and
issue
that
need
funded.
This
question,
for
example,
does
as
the
I
was
mentioned
before
the
current
setting
funchal
chain
working
group.
Is
these
copies
to
one
single
and
initiative
the?
Even
for
the
hierarchical
sorry,
fortunate
that
the
assumed
mission
is
d?
W
Another
point
is
to
go
over
the
security
and
privacy
consideration
X
like
this
and
that
it
basically
at
let's
test
the
request
is,
for
the
whole
people
to
provide
a
feedback
with
of
our
review
from
Mohammed
el-kheir,
and
we
will
address
the
comments
in
the
next
version.
Do
you
have
any
comment
of
these?
We
really
appreciated,
or
you
can
do
that
on
on
the
mailing
list.
Thank.
X
This
truth
from
who
are
we
without
commenting
on
the
rest
of
the
presentation?
I
just
wanted
to
give
an
input
that
there
is
some
work
in
East,
which
is
called
SF,
aware
topologies,
which
exposes
both
the
topology
as
well
as
SF
information.
Why
are
the
yang
models?
So
you
can
also
see
like
compare
between
whether
the
auto
extensions
is
giving
you
a
better
approach
or
using
a
yang
model
to
expose
the
information
from
domain
to
the
exchange
thing
that
you
have
on
the
top
just
a
input
for
something
further
to
analyze.
Thank
you.
W
H
W
D
A
This
is
interesting,
while
our
charter
isn't
as
clear
as
it
used
to
be
Jim
just
went
and
looked.
The
NFH
was
approved
very
specifically
on
single
domain,
so
you
know
I
appreciate
particularly
Danny
you're
raising
before
we
do
work
on
multi
domain.
Here
are
the
questions.
It
would
I'm
not
sure
we're
in
the
ietf
to
entertain
those
questions,
but
there
are
very
good
questions
and
it
would
be
interesting
to
see
them
discussed
further
if
people
have
thoughts
talk
to
Danny
by
email
or
send
them
to
the
list
as
a
whole.
A
We
don't
slap
people
for
sending
things
that
are
interesting,
but
only
on
the
edge
of
our
work
to
the
list.
We'd
love
to
see
more
engagement
on
the
list.
Frankly,
the
other
thing
is
I
can
see
one
of
the
blue
sheets.
I,
don't
see
the
other
one
so
wherever
it
is,
it
needs
to
come
forward.
Oh
okay,
there.
It
is
thank
you,
but
thank
you
very.