►
From YouTube: IETF100-SFC-20171114-0930
Description
SFC meeting session at IETF100
2017/11/14 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
Okay,
it
now,
as
far
as
I
can
tell
being
9:30
and
a
decent
number
of
you
being
prompt.
Thank
you
for
coming.
This
is
the
SFC
working
group
at
IETF,
100,
I'm,
Joel
Halpern.
One
of
your
two
working
group
chairs,
Jimmy
shard,
is
the
other
one.
He
got
called
away
at
the
last
minute
and
will
be
joining
us
in
about
a
half
hour,
but
he'll
be
here
as
promptly
as
possible.
Tom
Mizrahi
is
our
working
group
secretary
kal.
Can
you
come
get
the
blue
sheets
and
circulate
those.
A
Please
do
sign
into
the
blue
sheet.
This
is
the
note.
Well,
you've
probably
already
seen
it
more
times
than
you
like,
and
you
will
see
it
a
lot
more
times.
Yes,
it's
procedure,
but
it's
important.
You
have
to
abide
by
this.
It's
it's
what
we
need
in
order
to
function
as
a
community.
So
please
remember:
we
have
rules
you're,
making
your
material
available.
You
will
be
disclosed
your
IPR
in
a
timely
fashion.
All
of
the
other
things
that
are
described
in
the
various
BCPs.
Please
abide
by
them.
A
Understand
them
if
you're
not
familiar
with
them,
go.
Look
at
the
BCPs!
Thank
you.
Oh
I'll
go
going
through
the
agenda,
so
people
know
what
order
things
will
be
coming
up
in
the
the
Roth
grouping
we'll
be
having
a
just
over
an
hour
on
Oh
am
material
will
then
be
talking
about
some
forwarding
mechanisms,
proposals
that
people
have
sent
in
and
a
group
of
topics
that
I
can
only
describe
as
interesting
but
miscellaneous
they're
useful
things,
but
there
are
general
category
and
then
we're
scheduled
to
close.
A
If
we
are
ahead
of
schedule,
as
I
said
on
the
mailing
list,
I
will
present
the
initial
thoughts
and
all
they
are
is
initial
thoughts
by
your
chairs
and
IDs
to
get
things
started
for
what
might
go
in
reach
our
during
because
we've
completed
nsh.
Congratulations
to
everybody,
it
is
in
the
hands
of
the
RSC
editor.
It
will
be
published
and
my
thanks
to
all
of
the
authors
and
particularly
to
Carlos,
who
took
the
pen
during
a
very
difficult
time
and
carried
the
work
forward.
So
congratulations
to
everybody
and
thank
you
and
that's.
A
Why
we'll
be
doing
reach
our
Turing
so
to
look
at
the
agenda
in
more
detail,
the
OAM
material
you
can
see,
there's
a
list
of
them.
Greg
and
ting
will
be
presenting
that
material
in
about
65
minutes
and
I'll,
be
going
through
the
slides
two
notes.
Two
presenters.
Please
stand
in
the
pink
box.
There
is
a
camera.
It's
focused
there.
So
if
you're
there,
people
can
see
you
and
I.
Am
your
clicker
tell
me
when
to
advance
pages,
because
my
laptop
and
be
nice
remote
control
do
not
get
along,
so
I
will
advance.
A
Slides
I
will
advance
to
the
next
presentation
if
there
are
several
related
just
work
with
me
on
it,
we'll
get
through
things
in
a
timely
fashion.
So
we
can
talk
about
multi-layer,
OAM,
some
more
some
different
OAM
behavioral
issues,
performance
measurement
and
in
situ
OAM,
all
in
the
OEM
blocks,
so
the
65
minutes
has
to
include
time
for
Frank,
so
Greg
and
ting
you
have
about
50
minutes
for
yours
will
then
do
about
30
minutes
on
forwarding
mechanisms,
MPLS
based
forwarding
plane
from
Adrian
and
a
unified
presentation
using
unified
I
wish.
A
This
thing
didn't
display
that
bar,
but
I
can't
make
it
go
away
there.
It
is
using
unified
source
routing
instructions
from
xiao-shu
will
then
have
under
the
miscellaneous
category
some
discussion
of
the
time
stamp
empty
one
proposal,
alternative
handling
of
dynamic
chaining
and
service
interaction
and
optimized
service
function.
Chaining
then,
will
close
and,
as
I
said,
if
time
permits,
we
will
do
dis,
cut
charter
discussion
because
I'd
love
to
get
some
discussion
in
the
room
of
what
we
have.
C
Good
morning,
anyone
everyone
so
formally,
this
is
updated
to
the
document
that
we
work
on,
but
at
the
same
time
there
are
a
lot
of
new
content,
and
one
of
the
main
contents
is
that
you
can
notice
that
we
scope
on
active
a.m.
and
active
I
am
in
a
interpretation
of
RFC
77
99
that
we
only
look
at
the
use
of
specifically
constructed
test
packet
that
being
injected
in
the
network,
in
this
case
in
SFC
network,
to
monitor
or
do
measurements
next
slide.
Please.
C
C
C
C
D
C
C
So
this
is
a
proposal.
One
proposal
two
is
the
question
of
how
to
do
multiplex
various
active
om
protocols,
because
we
can
imagine
that
we'll
have
a
set
of
active
om
protocols
in
SFC
to
monitor
continuity,
to
do
our
on-demand
troubleshooting
and
failure
localization,
it's
a
functionality
like
ping
and
traceroute,
and
to
do
performance
measurement.
So
with
the
multiplicity
of
OM
protocols,
we
want
to
do
multiplex
that
usually
in
IP
networks
and
in
MPLS
we
use
the
same
method
is
to
use
well-known,
UDP
port,
but
that
requires
UDP
encapsulation.
F
C
No,
no,
no,
no!
No,
yes,
I
I
think
I
jumped
over
because
I
assume
sorry
and
thank
you
for
pointing
it.
No
UDP
encapsulation
is
under
nsh.
That's
how
we
do
it
in
MPLS
in
so
destination
address.
We
use
120,
7/8
and
comparable
address
in
ipv6,
so
that
it's
Martian
address
and
then
inside
this
encapsulation.
C
We
use
UDP
port
well
known
UDP
port,
and
this
is
well
known
method
that
how
what
we
use
in
LSP
ping
and
what
we
use
in
BFD
over
MPLS
LSP
to
use
IP
encapsulation,
and
we
use
this
destination
port
number
as
demultiplexing
for
the
active
or
AM
protocol.
So
that's
one
of
the
options
for
SFC.
But
again
we
need
to
consider
the
tax
of
extra
encapsulation.
C
C
C
F
G
H
C
C
F
C
We
think
that
we
need
well-known
port
and
the
document
has
request
for
Ayana
to
assign
UDP
port
for
echo
reply,
but
that's
assuming
that
we
don't
need
UDP
port
for
echo
request,
because
in
NSA
encapsulation
our
assumption
in
our
proposal
is
not
to
use
IP
UDP
encapsulation
overhead,
but
to
use
SF
coem
header
next
one,
please
so
we're
open
for
comments.
We
have
a
lot
of
assumptions,
we've
done
with
this
format,
and
we
would
like
to
hear
your
comments,
feedback
and
participation.
J
C
C
C
J
Adrian
Adrian
Farrell
thanks
Greg.
This
is
a
really
good
walk
around
the
block
and
I
think
it's
it's
helpful
for
us
to
get
the
options
on
the
table,
but
of
course,
options
are
evil
and
it
would
be
really
nice
if
we
can
take
this
and
start
throwing
out
some
of
the
options
so
that
we
end
up
with
with
probably
one
way
of
doing,
an
encapsulating,
om
whichever
it
is
and
I'm
sure
lots
of
people
have
different
favorites,
but
putting
them
all
on
the
table.
To
start
with
is
is
the
right
thing
to
do.
Thank.
K
K
This
is
little
serie.
A
basic
theory
of
OC
Salem
is
to
check
the
SFP
consistency
every
as
every
SFF
received
seorim
request.
It
have
two
actions.
One
is
to
forward
the
Salem
request
you
to
is
next
hope.
Another
action
is
true
reply:
Nancy,
repair
serum
with
the
SF
with
the
service
function
formation
in
the
reply
message,
whilst
wearing
all
the
comm
reply
message
and
the
whole
the
whole
SF
s,
FC
pass
will
be
confirmed.
K
K
F
Similar
question:
what
if
there's
multiple
choices
for
a
service
function
right
so
doing
low,
balancing
or
something
like
that?
Do
you
represent
that
low
balancing
group
as
a
single
service
function,
send
one
reply,
or
do
you
choose
one
of
the
service
functions
to
indicate
backwards,
or
do
you
do
it
for
all
of
them?
I'm.
F
I
think
what
Joel
is
saying
is
what,
if
you
have
you
know
two
hops
in
the
chain
or
served
by
the
same
service
function:
forwarder
right,
like
service
function,
one
in
service
function
or
each
doing
different
things
performing
different
functions
and
yeah
yeah.
You.
You
said
that
you
send
one
reply
back
for
each
service
function,
correct
what
if.
C
So
there
is
a
difference
because,
because
this
specific
is
thought
of
effectively
tracing
RSP
okay,
so
what
you're
asking
is?
You
are
asking
about
a
little
bit
different
functionality
when
you're,
saying
okay,
how
many
of
that
kind
you
have?
Okay,
so
I
think
it's
very
useful
option
and
we
can
talk
about
how
that
would
work
and
what
could
be
effect.
But
this
particular
proposal
is
more
about
mapping
SSP.
M
A
C
Again,
that
is
little
bit
different
angle
and
if
you
can
help
us
to
understand
what
needs
to
be
tested,
let's
work
together
off
because
it's
not
what
we
intended
with
this
proposal.
As
Joe
pointed
out,
we
are
taking
SFP
and
we're
mapping
RSP
of
that
SSP,
because
so
spi
characterizes
SFP,
but
it's
not
necessarily
one-to-one
mapping
to
RSP
so
trying
to
find
how
it's
balanced
and
there
might
be
some
other
proposal,
and
there
is
a
proposal
that
thing
will
present
of
basically
what
identifies
RSP
with
an
SSP.
A
There
is
one
other
implication
in
what
oh
sorry
go
ahead:
okay,
there's
one
other
implication
what
you
just
said,
Greg
and
in
what
you
said.
King
you
said:
you're
tracing
the
RSP.
We
do
allow
in
the
architecture
that
there
may
be
multiple
next
s,
ffs
from
a
given
SF.
So
if
s
FF
one
might
have
two
different
necks
for
different
flows.
C
That
something
that
basically
led
us
to
one
presentation
that
ting
will
have,
because
really
the
question
is
yes:
there
are
architecture,
states
that
SPI
characterizes
SFP,
not
RSP,
so
basically
working
on
this,
we
realized
that
we
don't
have
a
method
of
identifying
RSP
without
within
SF
key,
and
there
will
be
some
proposal
again.
It
might
be
not
the
way.
We
all
agree
how
to
do
it,
but
at
least
yes
you're
absolutely
right.
There
is
a
problem
of
okay.
There
is
a
question
of
how
we
identify
RSP
the
flow
within
SP.
L
So
that's
also
on
the
comment
earlier.
It's
I
was
thinking
before.
Maybe
your
response
there
is.
That
might
be
good
to
have
a
section
to
clarify
kind
of
load,
balancing
aspect
right,
because
I
think
the
question
that
was
raised
earlier
was
that
you
know
if
there
are
multiple
instances.
You
know
that
SFF
can
reach
for
the
same
SFP
right.
L
Then
you
know
which
one
do
you
respond
with
as
the
identifier
right
so
I
think
I
mean
there
are
different
cases
right
and
in
the
case
of
stateless
youth,
there's
a
hash
function,
so
there's
some
way
of
selecting
which
one
and
that
could
be
the
one
that's
returned
as
the
path
indication
and
the
other
ones
that
stay
for
right.
If
s
FF
at
you,
if
they
fell,
then
you
wouldn't
know
which
one
despite
the
fact
there
could
be
multiple
SF
instances
in
the
past,
anyways
might
be
good.
Does
this
have
a
session
recovered?
K
Yes,
thank
you
and
the
job
has
been
present
in
the
last
meeting
and
the
way
according
to.
According
to
the
comments
from
the
last
meeting,
we
update
the
draft
and
we
already
have
s.
Fcm
natalie
is
in
the
market,
motley
om
and
the
way
mcclure
update
according
to
lease
chopped
and
now
the
job
is,
is
like
attention:
Oh
SFC
echo
request
and
reply,
and
the
Donna
to
introduce
new
SF
ID
registry.
K
We
prefer
to
virtual
section
section,
10.5
new
service,
hyper
rejection
of
message,
BGP
contra
plan
chapter
and
we
add
some
security
consideration
section
and
the
security
consideration
in
this
chapter
is
also
based
on
the
message
after
security
consideration.
In
addition,
sales
service
functions
activate
discloses
information
about
the
SP,
the
prod
say,
om
request
package
may
be
used
to
obtain
Network
information,
so
it
is
recommended
that
implementations
provides
means
of
checking
sauce
address
of
CRM
request
message.
K
C
Yes,
actually
thank
you,
because
I
miss
to
mention
that,
in
my
presentation
that
if
we
not
use
IP
UDP
encapsulation
of
hacker
request
reply,
so
we
need
to
have
source
TLV
to
know
where
to
return
the
reply
right.
So
basically,
that's
what
Tinh
said
is
reference
to
this
missing
part
that
M
is
to
say
it's.
It's
my
take.
C
F
C
F
K
Listen
Isla,
second
slice
about
the
SF
Salem.
It's
about
how
to
specify
a
return
path
of
echo
reply
in
English
after
we
suggested
to
use
the
reply.
Service
function.
Past
TR
v
in
conjunction
with
replay
mode
field,
said
to
reply,
while
specified
pass
in
echo,
request
to
control
the
tempest
of
a
contract,
control
message
and
okay.
K
Listen
list
raft
is
also
have
Haslem
update.
According
to
the
comments
received
from
last
meeting
as
I've
see,
echo
requester
has
been
introduced
in
multi
layer
way.
This
chapter
will
give
some
modification
according
to
the
to
the
to
that
chapter
and
as
the
same
we
add
some
security
considerations,
section
nest
same
with
the
last
of
slides.
The
security
consideration
from
such
a
also
applied
to
this
tool
is
job
chapter
and,
in
addition,
the
SF
return
passed.
Exchanging
defied
English
document
may
be
used
for
potential
proxy
attacks.
K
So,
in
order
to
prevent
using
SF
SFC
return
return
the
Templars
extension
for
proxying
any
possible
attacks.
The
return
pass,
SF
key
should
have
destination
of
the
center
of
the
occult
cast
to
add
to
identify
a
savory
sauce.
Here
we,
the
receiver,
may
jobs
the
require
request
when
it
cannot
read
determine
whether
the
return
pass
as
if
he
has
the
destination
Tula
initiator.
That
means,
when
sending
a
cure
request
where
sender,
the
sender
should
choose
a
proper
sausage
according
to
Las
best
firing,
tempis
SP
to
help
ERISA
virtru
make
it
a
decision.
A
This
seems
not
quite
to
add
up
if
the
the
entity
that
is
generating
the
reply
already
knows
who
the
source
of
the
SFP
is
supposed
to
be,
so
it
can
validate
the
source
TLV.
Then
it
doesn't
need
another
validation
to
compare
those
two,
because
it's
like
okay
check
that
the
reply
is
going
to
the
correct
source.
So
it's
and
if
you're
not
validating
against
the
external
information,
then
I'll
simply
lie
in
both
who
I
want
you
to
send
a
reply
to
and
who
I
claim.
A
C
C
A
K
Sfc
scooby-dee
is
capability
of
SFC
that
is
resilient
to
scare
out
or
skiing
in
horizontally
or
vertically,
and
this
is
the
terms
way
we
can
find
and
wait
if
we
describe
four
scenarios
of
scalability
in
a
job.
The
first
scenario
is
join,
join
means
SF
can
be
added
into
an
existing
as
I've
seen
so
that
SF
seek
has
more
service
function
and
the
second
scenario
is
about
redundancy
redundancy
means
one
or
more.
Sf's
are
added
into
the
SMC
to
meet
the
protection
or
load
balance
requirements.
K
Now
certain
error
is
about
bypassed.
That
means
some
SF
bypassed
seems
no
need
service
function
anymore.
So
the
SF
is
it's
not
the
traffic.
We
are
not
tremors.
This
SF
and
the
last
scenario
is
about
fare
over,
and
that
means
some
SF's
are
removed
because
of
failure
is
removed,
removed
from
the
SF.
Because
of
Union.
We
identified
these
for
snare
scenarios
into
four
categories
for
Joe
for
join
cases
and
redundant
redundancy
cases
we
need
the
SFC
has
been
scaled
out
and
for
bypass
all
forever.
We
say
the
SMC
is
scared
in
nest.
K
This
is
a
some
detail
about
SF
redundancy.
We
think
that
SFO
needs
a
redundancy
has
ensued.
It
contains
two
cases.
Why
is
SF
redundancy
SF's
redundancy
means
that
one
or
more
SF's
are
added
into
the
SFC
to
meet
the
redundancy
or
load
balance
requirement
for
some
certain
for
some
certain
as
SF,
but
for
SFP
redundancy.
K
K
According
to
last
person
area
we
just
presented,
there
are
some
requirements.
Why
is
the
above?
The
data,
parent
requirements
and
this
requirements
is,
is
based
on
load,
balance
scenario
for
load
balance
or
active,
active
protection
protection.
Fro
ID
is
needed
to
differentiate
the
SMP,
you
know
as
the
SFC,
so
we
have
two
options
to
add
such
fro
ID.
Why
is
to
add
at
the
fro
ID
into
the
service
past
header?
Another
is
to
add
another
is
to
add
the
froggie
into
our
metadata.
K
The
magnitude
tab
should
be
true
nest
and
the
way
also
has
some
requirements
in
Contra
plan
in
Contra,
plain
Java,
the
there
are,
four
interfaces
has
been
defined
and
the
enlist
in
list
last.
We
have
some
some
requirements
about
the
c1
and
c2
interface,
see
wise'
is
an
interface
between
control,
plane
and
the
classifier
and
c1
c2
is
the
interface
between
controller
and
s,
FF
Fausta,
to
interface.
We
suggest
other
to
messages.
K
Why
is
regis
message
to
SF
to
notify
that
SF
is
going
to
be
joined
and
then
installing
new
and
chest
england's
FP
forwarding
policy
table?
The
message
contains
indication
that
the
SF
is
joined
as
a
new
SF
or
as
a
group,
and
the
for
the
reduced
message
to
SF
is
to
notify
that
SF
is
going
to
be
removed
from
SF
C,
and
the
message
should
also
contain
some
indication
that
it
is
removed
from
SF
or
from
a
group.
Let.
A
Me
ask
a
couple
of
clarifying
questions
here:
first,
the
c1,
c2,
etc.
Terminology
is
no
longer
part
of
the
working
group
of
terminology,
so
we
should
probably
avoid
using
it.
The
document
that
brought
those
forward
is
not
any
longer
a
document
we're
working
on
for
that
with
the
conclusion
of
the
working
group.
Therefore,
we
can't
use
those
I
want
to
point
out
on
this
slide.
The
NS
h
document
has
gone
to
the
RFC
editor.
We
are
not
going
to
change
the
NS
h
encapsulation
the
base
without
a
dramatic
reason.
If
somebody
finds
it
don't
work.
A
If
we
broke
it,
we'll
we'll
fix
it,
that's
the
way
the
IETF
works,
but
having
gone
through
working
group
last
call
IETF
last
call
and
very
long
iesg
discussion
I'm,
not
touching
that
without
a
very
strong
reason.
Please
now
having
said
that,
these
two
dot
things
you
described
under
c2,
look
to
me
just
like
whatever
it
is
going
to
be
used
to
configure
an
SFF
stable
for
forwarding
to
SF's
those
are
not
we're,
not
defining
those
messages
or
they
may
they
will
appear
in
the
yang
as
messages
that
already
need
to
exist.
A
F
Two
comments
so
both
related
to
what
you're
talking
about
so
respect
to
choosing
between
the
N
SH
extension
or
a
piece
of
metadata
to
add
the
flow
identifier.
I.
Definitely
prefer
I
mean,
aside
from
the
fact
that
we
don't
want
to
reopen
n
SH.
The
the
metadata
version
of
the
flow
ID
is
32
bits
and
I.
Don't
the
other
version
is
only
8
bits
and
I,
don't
think
it's
carries
enough
entropy
to
effectively
low
balance,
I
mean
if
you
have
more
than
256
candidates
for
a
specific
load.
F
Balancing
group
you
just
can't
do
it
and
that's
really
limiting
so
I
really
strongly
suggest
that
we
go
with
whatever
solution
allows
us
to
have
more
than
8
bits
of
flow
ID,
and
the
second
thing
was
related
to
this
requirements
may
be
what
we
want
to
talk
about.
With
respect
to
joining
and
leaving
the
forwarding
plane
is
what
it
means
to
effectively
to
join
with
minimal
impact
right.
So
you
know
we
can
add
a
new
service
function
to
to
an
s
FF.
But
how
can
you
do
that
with
minimal
impact?
F
A
C
C
C
So
that's
something
that
we
asked
a
SFC
working
group
to
consider
allocating
mark
field
off
to
bit
positions
so
here
for
the
residence
time
the
residence
time
can
be
measured
at
SFP
and
to
end.
At
the
same
time,
a
residence
time
can
be
measured
as
a
node
o
on
s
FF
and
the
residence
time
can
be
measured.
Sab
know,
though,
there
SF
an
advantage
of
using
alternate
marking
method
that
the
measurement
of
and
calculation
of
all
performance,
metrics
related
to
the
residence.
C
So
basically,
we
have
a
different
measurement
points
where
they
were
doing
an
odo
or
sub
nodal
measurement.
But
the
advantage
is
that
because,
and
if
we
have
the
mark
field
in
nsh
header,
then
we
can
acquire
alternate
marking
method
to
create,
with
one
bit
with
us
bit
at
a
batch
of
contiguous
packets
mark
the
same
way
and
then
use
a
delay
flag
to
signify
their
packet,
that
we
want
to
do
our
residence
time
measurement
and
then
can
be
in
addition
to
measuring
delay
characteristics
along
the
path
as
well
an
advantage
of
again.
C
The
general
advantage
alternate
marking
method
that
this
packets.
This
measurement
points
can
be
enabled
on
a
fly
at
any
node
any
element
in
s.
Fc
s
appear,
but
more
likely
it
will
be
SF's
next
way.
So
I'm
thinking
that
with
good
within
10
minutes,
questions
comments
and
we
appreciate
the
consideration
of
working
group.
Adoption.
A
A
D
All
right
so
next
slide,
so
this
is
about
inventor,
William
or
sorry
in
situ,
OEM
in
nsh.
So
just
quick
reminder
on
what
I
OEM
is
IO
am:
is
a
mecha
method
to
go
and
carry
within
the
user
packet
itself
metadata
to
help
with
OEM
operations,
which
is
well
information
like
node,
ID,
ingress
interface,
egress
interface,
timestamp,
information
on
when
a
particular
packet
visited
a
node
and
so
forth.
The
overall
work
is
progressing
as
part
of
IPP
and
working
group
to
go
and
define
in
a
transport
encapsulation
independent
way.
D
A
variety
of
these
pieces
of
metadata
or
data
fields
that
are
accumulated
and
assembled
and
collected
as
the
packet
progresses
through
the
network,
and
if
you
go
with
the
classification
and
then
77
99,
its
hybrid
type,
100
am
so.
As
I
said,
we've
been
doing
that
work
in
IP
p.m.
we
are
specifying
the
other
fields.
The
documents
are
getting
stable,
but
we
need
to
go
and
carry
these
data
fields
and
NSA,
just
one
obvious
contender
for
carrying
these
data
fields.
D
We
are
here
to
go
and
do
the
shopping
with
nsh
next
one,
so
we
came
up
with
a
proposal
and
you
just
flip
there,
okay,
so
0
0
version
of
the
document
has
a
proposal
in
there
on
how
to
encapsulate
iom
metadata
into
nsh,
and
there
is,
if
you
read
through
the
VIP
PM
document,
there
is
a
variety
of
REM
types
for
IOM:
one
is
edge
to
edge
another
one
is
for
prove
of
transit
and
another
one
is
for
hop-by-hop.
Try
saying
that
then
define
individual
T
of
these.
D
D
That's
a
flatterer
approach,
then
using
metadata
type
2,
but
those
are
two
alternatives
exists
and
well
we're
happy
to
go
and
discuss
what
the
best
approach
for
that
is.
But
here
is
an
example.
How
now
trace
data
would
be
encapsulated?
It
could
well
be
if
there
is
proof
of
transit
there
as
well.
You'd
have
another
next
error
for
that.
If
you
flip
to
the
next
slide,
I
think
it
it
starts
to
this
is
really
masked.
So
what
happened?
We.
D
F
F
D
C
O
D
There's
I
think
that
the
two
things
that
are
pretty
obvious
here
is
we
try
to
not
nest
heal
these
unless
we
have
to,
which
is
why
we
ended
up
with
the
approach
to
have
basically
three
main
cones
edge
to
edge
proof
of
transit
and
try,
saying
and
then
do
the
T
least
they
are
within.
We
could
have
done
metadata
type
to
which
leads
to
a
further
level
of
nesting
and
I.
Try
to
already
to
pick
that
with
this
kind
of
little
bit
of
a
graphic
on
the
right
hand,
side.
D
The
funny
thing
is
we
have
the
original
implementation
that
we
first
build
and
VBP
use
this
actually
metadata
type
to
in
software,
not
that
big
of
a
problem
in
hardware.
It
leads
to
an
iterative
lookup
and
an
iterative,
lookup
and
hardware
is
relatively
expensive.
So
that's
one
problem.
The
other
problem
is
and
that's
the
very
point
that
you're
raising
Gregg
and
that
well
I
post
at
the
draft
and
I
think
five
minutes
later.
D
I
first
saw
the
first
reply
from
from
Jim
and
then
another
five
minutes
later
I
saw
the
second
reply
from
Joe
so
said:
what
is
the
orbit
for
if
you
read
through
the
architecture
document,
so
that's
seventy
six,
sixty
five
right!
It
does
this
clear
distinction
between
OAM
traffic
and
user
traffic.
Now
our
assumption
is
that
we
tagged
with
IO
am
virtually
all
user
traffic.
So
are
we
use
a
traffic
now
or
om
traffic
I,
don't
know.
D
The
funny
thing
is
that
an
S
FF
will
only
look
at
myself
at
my
metadata
if
I
set
the
öbut,
so
I
need
to
go
and
classify
myself
as
I
am
traffic
and
eventually,
if
you
have
an
operator
that
is
just
interested
in
so
say,
prove
of
transit
and
verifying
that
your
path
is
correct.
You'd
classify
all
user
traffic
as
OEM
traffic.
Do
you
want
that?
Maybe
you
do
because
your
SFF
is
really
capable
of
doing
that.
C
C
If
you
have
your
iom,
when
you
put
IOM
in
nsh,
then
where
the
payload
will
be
signified,
the
idea
mind,
understanding
of
obut
and
actually
I
was
very
much
for
just
dropping
orbit,
releasing
it
to
the
reserved
unused
field,
because
I
think
it
complicates,
but
as
it
is,
their
interpretation
should
be.
Is
that
they're
in
combination
with
some
protocol,
then
there
is
some
data
go
in
the
method,
data
and.
D
D
The
next
version
will
have
an
explanation
of
that
and
I
don't
have
a
problem
with
setting
the
orbit,
but
I
think
we
need
some
guidance
that
exactly
what
you're
saying
right.
If
you
set
the
öbut
that
it
doesn't
mean.
Oh,
this
is
a
packet
that
you
are
safe
to
go
and
process
in
the
pump
path.
I
think
that
interpretation
should
never
ever
happen
and
if
we're
exhausted.
C
C
D
C
L
I
A
D
C
A
That
there
are
issues
with
this,
for
example,
if
you
use
this
kind
of
next
protocol
identification,
it
means
you
have
to
have
made
sure
that
any
SFF
that
has
to
look
at
the
underlying
packet
understand
try
to
skip
this
and
that
any
SF
in
the
chain,
because
SS
have
to
look
at
packets
or
understands
how
to
skip
that.
That
may
be
an
acceptable
constraint,
but
we
should
make
sure
we
call
it
out
in
the
document
you're.
D
C
D
O
D
P
The
mic
yeah
I,
wanted
to
point
out
a
couple
things
about
the
obits
Oh.
What
was
already
mentioned
was
this
question
of
that
context
and
people
associate
with
the
obit,
but
if
you
look
at
what's
actually
written
in
the
document,
one
issue
I
have
is
that
the
default
behavior,
if
you
do
not
support
any
OAM
if
the
obit
is
set,
is
to
drop
them
to
drop
it.
That's
not
really
the
behavior
that
we
want
here
and
because
of
that,
I'm
wondering
whether
it
might
make
sense
to
use
one
of
the
undefined
bits.
P
A
A
They
had
to
look
at
the
payload
and
then
they
might
get
confused.
But
we
that's
a
good
discussion
for
the
list
it
did.
We
do
have
other
reserved
bits.
We
don't
have
lots,
but
this
is
an
important.
If
this
is
an
important
use
case,
we
could
assign
a
second
bit
to
the
specific
use.
I,
don't
think
that
has
a
big
effect
on
whether
it
gets
punted
or
not.
I
understand
your
concern.
It's.
P
D
I
have
two
more
slides,
my
leery.
We
give
them
a
chance
again
under
fully
messed
up.
D
So
what
about
security
and
well
maybe
tell
you,
want
to
go
and
bring
that
up,
but
what
I
learned
is
that
security
is
still
something
that
SFC
is
supposed
to
work
on
as
a
working
group,
and
that
was
one
of
the
Commons,
the
main
document,
while
back
we
presented
proof
of
transit,
also
SFC.
What
is
the
mechanism?
We
basically
take
a
secret.
We
split
the
secret.
We
give
every
single
hop
that
needs
to
be
verified,
a
piece
of
the
secret
and
that's
the
packet
traverses
through
the
chain.
D
D
They
could
be
both
used
depending
on
the
requirements
that
that
SFC
has
within
this
very
context.
So
it's
kind
of
tied
to
well.
We
carry
the
metadata,
but
we
can
also
carry
improve
marry
data
somewhere
else,
so
it
can
be
really
orthogonal
to
to
IOM
Percy,
but
it's
there
and
it
solves
a
particular
problem
that
has
been
pointed
at
by
isg
in
the
review.
If
you
go
to
the
next
slide,
it
basically
captures
where
we
are.
As
I
said,
the
data
fields
are
being
defined
and
it's
pretty
stable.
By
now
and
I
ppm.
D
We
need
to
go
and
a
capsulate
we're
on
this
shopping
trip
and
ice
ages.
Here,
there's
other
working
group
talk,
other
documents
being
proposed
to
other
working
groups,
they're
listed
up
here
and
well.
We
already
received
some
feedback.
What
we
want
to
go
and
stabilize
the
current
proposal
and
see
what
the
main
line
of
consensus
from
an
endcap
perspective
would
be.
The
other
question
is:
do
we
want
to
go
and
adopt
proof
of
transit
here
in
order
to
solve
the
security
problem?
That.
C
D
C
No
just
the
thing
is
that
I
think
that
it
might
be
good
to
understand
that
in
encapsulations
that
have
a
flexible
or
extensible
headers
metadata
TLV
is
an
option,
and
in
some
other
networks
it's
not
an
option.
So
it
might
be
one
of
the
reasons
to
think
that
do
we
want
to
have
consistent
mechanism
across
different
networks,
which
might
be
a
good
thing
absolutely.
D
O
D
O
J
J
Some
that
work
will
need
specific
MPLS
tweaking,
but
it
doesn't,
in
our
opinion,
change
the
SFC
architecture
at
all
and
we
are
fairly
agnostic
as
to
where
that
work
gets
done
and
hope
that
the
MPLS
and
SFC
chairs
and
ADEs
will
will
work
on
that.
I
have
an
opinion,
but
don't
really
mind
so
I
have
a
cron.
No,
you
don't
all
right.
So
this
is
a
joint
set
of
slides
that
I'm
using
an
MPLS
as
well.
If
this
architecture
picture
surprises
you
either
I'm
wrong
or
you've
been
asleep
next
slide,
so
objectives
and
non
objectives.
J
J
What
we
are
doing
is
looking
at
an
environment
where
MPLS
reuters
that
are
already
deployed
can
serve
as
SF
FS,
without
changing
their
forwarding
plane
and
be
able
to
forward
packets
at
line
speed,
so
not
throwing
those
packets
out
into
some
piece
of
software
that
that
interprets
the
nsh.
What
that
really
means
is
that
this
is
a
technology,
an
approach
that
allows
you
to
migrate.
Okay,
it
allows
you
to
put
service
function,
training
into
the
field.
Now,
while
people
are
working
on
nsh,
it's
not
an
attack
on
an
SH.
J
What
we're
doing
this
draft
is
support
both
modes
of
MPLS
forwarding,
so
that's
labeled,
swapping
and
label
stacking,
otherwise
known
as
segment
routing
and
actually
there's
an
advance
function
in
there.
That
allows
us
to
mix
and
match
swapping
and
stacking,
which
has
some
specific
use
cases,
but
principally
we're
trying
to
look
at
how
you
can
achieve
service
function,
training
using
swapping
or
stacking
and
trying
to
do
that
in
a
common
way.
Go
ahead
and
interrupt
me.
B
Carla
pina
taro,
Cisco,
Adriene
I,
understand
what
you're,
saying
and
I
think
is.
You
know
super
important
to
be
able
to
run
sri
function,
chaining
on
an
existing
MPLS
data
plane.
Have
you
considered
running
an
SH
over
MPLS
and
compare
and
contrast
that
to
these
other
methods
and
see
which
one
has
more
strength
so.
J
Yes,
it
did
consider
it
but
didn't
really
compare
and
control.
So
the
consideration
is
that
if
you
run
n
sh
over
MPLS,
then
really
you're
you're
using
MPLS
purely
as
a
tunneling
mechanism.
So
when
you
arrive
at
the
SFF,
you
are
stripping
off
the
MPLS
and
going
oh
I
have
an
N
sh
and
something
has
to
process
that
n
sh.
J
If
your
box
is
a
dedicated,
MPLS,
router
already
to
process
the
n
sh
you're
going
to
have
to
throw
that
to
to
software,
that's
that
the
step
I
want
to
avoid.
Now,
of
course,
you
can
do
that
that
in
that
implementation,
you
can
do
that
using
the
existing
n
sh
spec,
no
changes
to
anything
knock
yourself
out.
B
J
The
first
resolution
they
said
one
is
a
problem
right
that
the
format,
the
format
so
I
I
want
to
be
able
to
do
service
function,
training
using
an
existing
MPLS
router
as
an
SFF.
Thank
you
so
the
fourth
point
here
then
we
we
want
to
get
as
much
SFC
functionality
as
possible,
but
we
are
aware
that
there
may
be
some
sacrifices
and
trade-offs
because
the
nsh
was
developed
in
order
to
achieve
the
full
SFC
functionality
and
it's
in
the
NSA
choose
not
MPLS,
so
there's
clearly
potential
for
mismatch.
J
J
A
control
plane
for
the
NS,
h,
variant
of
of
SFC-
and
it
turns
out
in
in
our
opinion
that
that
control,
plane
mechanism
will
also
work
for
this
MPLS
encoding
and
we're
not
touching
it.
So
yes,
thank
you.
The
overview
of
the
solution.
The
overview
of
the
solution
is,
basically,
everything
is
built
on
a
on
a
label
pair
a
to
label
stack
entry
pair.
J
Obviously,
the
labels
cannot
be
in
the
0
to
15
range,
but
apart
from
that,
we
have
the
full
2
to
the
20
available
and
with
this
unit,
which
is
a
context
label
and
a
function
label,
we're
able
to
achieve
both
the
swapping
and
the
stacking
approach,
but
there's
a
slightly
different
interpretation
so
for
swapping
we
use
the
two
labels,
one
as
the
SPI
and
the
second
one
as
the
SI.
So
that's
essentially
it
looks
just
like
the
NS
h,
but
it's
achieved
using
to
label
entries,
and
that
gives
us
a
TTL
in
there
as
well.
J
There
are
some
little
limitations
that
show
up,
because
we
only
have
20
bits
to
play
with
the
SPI
in
the
NS.
H
is
more
than
20
bits,
so
we
have
a
constraint
but
I.
Think
that's!
Okay!
If
you
know
what
network
you're
managing
it
might
be
a
problem,
if
you
were
trying
to
do
nsh
halfway
across
the
networker,
then
flip
into
MPLS.
B
Opinion
that'll,
Cisco
and
I
apologize
because
I
didn't
have
time.
I
wanted
to
read
this
in
detail.
I
didn't
have
time
so
I'm.
You
know
working
through
the
method,
in
this
case
Adrienne
you're,
neither
doing
swap
nor
doing
pop
you're
doing
a
combination
of
both
right,
because
you
need
to
pop
everything:
save
it
somewhere
process
the
payload
and
then
push
push
right.
So
you're,
not
it's!
You
know
one
of
the
know
so
far.
J
B
J
You
have
a
known,
SFC,
aware:
SF,
today,
you've
put
a
proxy
in
and
the
proxy
has
to
strip
off
the
NS
h,
store
it
and
reimpose
it
and
modify
it.
No
change,
okay!
So
yes,
future
SF's
will
be
SFC
aware
and
handle
NS
h's,
but
we're
not
in
the
future
yet,
and
this
is
trying
to
handle
what
we
have
now
today.
So
yes,
FF
e
Sanders
have
Brock's
essentially
as
well.
Oh
you
put
a
proxy
in
a
separate
box.
J
J
J
J
H
J
J
J
So
you
can
forward
again
slide
yeah.
What
about
metadata?
Obviously
metadata
is
important.
I
worry
about
the
insertion
of
an
arbitrary
amount
of
metadata
between
the
mpls
packet
header
and
the
data,
the
payload
data.
What
we've
done
to
circumvent
this
issue
is:
allow
you
to
put
in
a
label
that
says
this
is
an
index
to
some
metadata
that
has
already
been
passed,
and
that
index
is
a
store
which
may
have
been
populated
from
a
control
plane
from
an
out-of-band
management
plane
or
as
described
on
the
next
slide
in
in
in
band.
J
This
works
really
nicely
for
per
SFP
metadata.
It
works
nicely
for
per-flow
metadata,
where
there's
multiple
flows
in
an
SFP.
It
doesn't
work
well
for
per
packet
metadata
so,
depending
on
our
use
cases
for
metadata
that
this
may
or
may
not
be
perfect
next
slide.
So
how
do
we
push
metadata
in
band?
This
is
very,
very
similar
to
to
the
next
proto
is
none
in
nsh.
J
So
essentially,
what
that's
saying
is:
send
your
metadata
interspersed
with
your
user
data
rather
than
in
the
same
packet.
That's
right!
So
where
are
we
going?
We
we
can
always
punish
the
draft
and
and
no
doubt,
there's
quite
a
lot
to
be
done,
but
actually
we
think
we've
got
to
a
fairly
stable
position
with
the
support
for
both
swapping
and
stacking,
which
took
us
a
little
bit
of
head-banging
to
come
up
with
a
consistent
approach.
It
fits
as
I
say
with
the
control
plane.
J
We
think
it's
pretty
obvious
as
this
transition
technology
and
we
think
that
probably
it
goes
in
the
MPLS
charter
because
we're
defining
special
purpose
labels
and
that
working
group
would
probably
freak
out
if
anybody
else
touched
them.
But
it
obviously
needs
discussion
here,
because
it's
service
function,
training.
A
R
R
J
So,
just
as
a
proxy
in
nsh
has
to
rip
off
the
entirety
of
the
illness
of
the
SFC
encapsulation,
the
same
would
be
true
in
a
stacking
or
the
swapping
case
that
a
whole
lot
has
to
come
off
and
in
a
stacking
case.
Yes,
that
is
a
more
complicated
action,
because
you've
got
to
work
out
how
much
to
strip
off.
I
This
is
offer
regarding
the
work
which
working
group
I
think
this
work
should
start
here,
because
what
you
go
in
terms
of
the
special
label
and
all
those
things
really
depends
on
the
need
for
it
is
not
going
to
be
defined
just
the
color
sake
of
defining
it
and
the
only
working
group
that
can
comment
really
well
about
need
for
these
things.
Is
this
working
group,
so
that
would
be
my
comment
to
chairs
that
we
should
start
work
here.
A
A
L
L
I
A
A
A
S
My
name
is
Sherwin
from
juniper
on
behalf
of
all
the
callers.
Actually,
we
proposed
this
unified
asset
multivitamin
for
network
service
hider,
so
it's
a
function
chaining
somehow.
So.
Basically,
we
proposed
this
similar
idea
for
the
unified,
a
second
row
team,
which
is
soft
space,
routing
which
can
ban
the
benefit
or
for
NP
RS
and
Anita
no
in
between.
So
previously
the
work
working
on
this
service
Cheney
proposed
in
2014,
but
the
work
not
her
while
adopt
by
the
MPS
working
group
because
of
for
at
that
time
a
service
function.
S
Cheney
is
not
a
major
use
case
for
several.
You
know
somehow
and
also
some
background
on
the
SFC
and
him
at
that
time
they
are
working
on
focus
on
the
edge
hider
somehow,
but
this
time
we
propose
this
one.
Sorry
and
please
go
back.
We
propose
this
new
idea.
Somehow
you
know
October
2016
because
of
all
we
believe
the
services
function.
Pass
will
be
better
benefited
by
this
combined
IP
and
mpls
function,
which
is
in
between
any
router.
S
Any
switch
which
can
handle
UDP
can
handle
MPLS
can
help
with
this
ourselves
function
pass
somehow,
then
the
next
farm.
So
this
one
is
fully
defined.
Whatever
pass
the
service
provider
want
to
working
on
the
Talco
cloud,
the
mini
disinterred
distribute
the
center,
then
they
can
chain
the
function
together
here
and
next,
please.
So
the
proposal
here
is
kena,
for
you
may
have
a
multi-party
center
multiple
functions
here
after
the
PNG
after
the
peak
it
weighs.
S
Somehow
you
have
the
search
function,
classify
classify
here,
but
we
do
not
as
kind
of
a
try
to
differentiate
between
the
SF
and
the
SFF,
so
we
assign
the
label
for
careful
doesn't
matter.
The
label
can
be
one
standing
folder
as
as
far
as
have
or
as
I
said,
for
folder
and
in
the
middle.
If
there's
something
some
boxes
cannot
support,
MPs
centrality
know
somehow
we
also
can
support
by
the
UDP
tunnel
to
pass
through
somehow
then.
S
In
the
meantime,
we
not
kind
of
or
try
to
compete
with
networks
of
header
message,
which
we
think
is
very
good
for
the
metadata
container.
Somehow
so
we
pick
the
pass
as
service
function
pass
and
put
into
the
NPS
label
stack
together
with
unified,
stand
routing
and
with
UDP
GRE
tunnel
in
between,
but
a
metadata
will
keep
internally
in
the
network
services
hider
here.
S
Then
they
saw
the
label
the
for
the
next
I
said
folder,
which
is
not
a
the
MPLS
based
interface,
the
best
path,
maybe
the
UDP
one.
So
there's
a
will
be.
There
will
be
a
liberal
mapping
between
the
label
to
the
UDP
tunnel
in
between
here.
So
next
please,
so
we
actually
highly
appreciate
all
the
work
in
the
sft
working
group
here,
the
so,
but
will
propose
to
keep
an
edge
either
as
a
metadata
metadata
container
here.
S
So
then
we
also
can
a
proposal
message
to
working
between
the
network
service,
hider
and
also
the
unified
is
a
crowding
here.
So
the
spi
function
we
suggest
they
will
be
handled
by
and
the
so
called
unified.
Npr's,
which
is
come
working
with
any
router,
any
switch
almost
then
with
very
high
processing
performance
library
forwarding,
so
the
transportation
only
taking
care
about
vanilla
pass,
then
the
NSS
header
part.
S
You
also
can
contain
all
those
information
and
for
metadata
the
then
you
also
can
combine
that
you,
let
the
usage
of
Si
and
the
SPI
to
get
all
the
label
stack
and
so
on.
So
if
you
go
next
okay,
so
this
is
the
information
here,
one
one
for
the
processing
here.
We
know
that
the
source
function
here
might
be
some
kind
of
a
tweetable
interface,
somehow
or
maybe
for
analyzer.
You
only
need
to
through
the
traffic
to
the
source
function
here.
S
So
this
time
we
actually
simulate
one
function,
which
you
need
to
put
all
the
label
information
and
such
header
information
from
SC
then
go
all
the
way
to
the
SF
for
the
router
here
now
on
this
router,
because,
as
SF
might
not
be
understanding
the
technology
at
all.
So
in
that
case,
not
a
sec,
routine
labor
will
be
set
up.
Somehow
so,
SFF
will
assign
the
label
for
the
function
the
wave
somehow
function,
but
when
we
sending
the
traffic
to
the
folder
for
further
processing,
we
actually
get
rid
of
all
the
second
routine
pass
information.
S
S
Sorry!
This
is
a
old
version
somehow,
but
we
actually
try
to
highlight
the
to
combine
the
benefit
of
opposed
technology
and
the
network
service
hider
to
help
the
search
function
chaining
here.
So
there
will
be
all
the
benefit
leverage,
the
existing
router
switch
to
carry
to
define
a
pass
and
all
the
metadata
or
the
subscriber
information
or
the
user
information
will
be
kept
in
the
edge
header
here
then
bill
down
for
MPLS
and
UDP,
or
the
capability
here.
C
G
C
C
S
Extensions
yeah,
so
we
actually
have
a
two
idea
on
this
one.
The
first
one
we
actually
try
to
leverage
is
some
kind
of
a
protocol
to
so
from
SF
have
one
here
to
assign
the
label
like
a
attached,
prefix,
somehow
and
another
one
may
be
a
layer
to
function,
because
some
function
may
be
not
fully
leery
that
one.
We
kind
of
a
consider
right
now,
so
there's
a
certain
method
to
do
to
assign
the
label
for
leader
three
function
and
a
little
true
function.
Another
one
is
kind
of
all.
S
T
F
T
It's
good,
in
fact,
we
could
directly
use
MPs
same
routing
for
searching
but
to
meet
the
transport
in
dependency
requirement,
which
is
listed
in
the
SFC
architecture,
dropped
with
better
to
spot
multiple
underlays
in
our
unified
source,
routing
Magnum
that
is
MPs
or
IP.
The
IP
could
be
ipv4
or
ipv6.
In
this
case,
it's
meet
the
transporting
pendency
requirement
in
a
world.
You
could
use
MPs,
Emirati
or
MPs
the
multi-award
IP,
okay,.
R
S
R
S
J
You
have
more
slides,
or
are
you
done
with
the
presentation?
Okay,
can
you
go
back
a
picture
that
one
lovely
I'm
I'm,
trying
to
I'm
slightly,
comparing
this
with
the
previous
thing
and
trying
to
understand
the
role
of
the
nsh
in
this
figure,
so
I
understand
nsh
as
a
metadata
encoding?
What
happens
in
this?
In
this
scenario,
what
happens
to
the
other
fields
in
the
nsh?
Do
they
get
updated
as
well?
Do
they
have
meaning?
Does
the
SPI
and
si
in
the
nsh
have
meaning.
S
Basically,
this
can
be
discussed.
Basically,
we
do
not
request
the
every
harp
to
process
a
message.
That's
a
benefit
of
this
proposal
then,
but
uncertain
node.
If
the
SH
can
be
understand
by
some
of
which
were
so
far
out
or
via
somehow,
then
they
can
be
processed,
but
otherwise,
so
we
have
no
requirement
for
to
process
the
internal
search
either.
That
one
is
the
baton
that
controller
or
whatever
they
negotiated.
The
policy
which
know
the
to
change
right.
S
U
Sorry
Robert
so
I'm
watching
these
slides
and
also
Audrey
on
slides
and
it's
great
to
actually,
you
know,
do
SF
C
for
let's
say
MPLS
networks,
but
why
are
we
actually
always
focusing
on
putting
five
labels
in
the
data
plane
when
you
can
achieve
all
the
puff
steering
with
contra
plane
I
mean
proposals
are
already
deployed,
l3
PN,
with
Artie,
import/export
or
BGP,
vector
routing,
achieves
the
puff
steering
for
the
network.
Puran
leak
on
the
plane
and
the
packet
can
still
have
an
SH
header
to
pass
it
to
a
SF.
S
A
V
V
So
what
is
the
time
stamp
useful
for
the
draft
has
a
few
use
cases
and
we've
discussed
these
in
the
past,
so
I'm
only
going
to
mention
a
couple
of
them.
One
obvious
use
case
is
to
measure
delay.
So
when
the
packet
reaches
the
classifier,
it
adds
a
timestamp
T
1.
So
then
every
other
note
I
can
SF
in
this
diagram
can
receive
the
packet
it's
time,
T,
2
and
measure
the
one-way
delay,
assuming
they're
synchronized
now
go
back.
Please.
Another
possible
use
case
is
obviously
for
a
flow
monitoring
like
IP
fix
or
s
flow.
V
V
So
this
is
the
time
stamp
allocation
format.
So
one
field
we
have
here
is
the
time
stamp.
Obviously,
it's
64
bits
in
the
format
of
I,
Triple,
E,
1588,
truncated
format,
there's
also
a
source
interface
identifier
and
the
sequence
number,
which
can
be
used
for
detecting
out
of
order,
delivery,
detecting
duplicates
and
it
can
help
in
detecting
loops
next
please.
V
V
Another
observation
is
that
obviously
mdtech
1
is
not
as
flexible
as
MD
type
2
so
and
we
tied
to
has
a
type
field
and
the
type
1
doesn't
have
a
built-in
tie
field.
So
that
means
that
typically
in
an
SMC
domain,
you'll
only
use
a
specific
and
D
type
1
allocation
and,
having
said
that,
we
still
believe
there's
a
use
case
for
more
than
one
MD
type
1
allocation.
V
So,
for
example,
we
believe
there's
a
good
use
case
for
the
data
center
allocation,
which
has
an
optional
timestamp
field,
which
is
a
32-bit
timestamp
field,
and
we
also
believe
the
use
cases
that
may
benefit
from
the
allocation
that
we
discussed
here,
which
has
a
64-bit
time
step.
It
has
a
higher
resolution,
higher
granularity
and
probably
there
may
be
other
use
cases
for
other
locations
as
well.
So
as
an
as
the
next
steps,
we
like
some
more
feedback
and
we'd,
be
happy
to
proceed
to
a
call
for
working
group.
Adoption
comments.
C
Yes,
Greg
demske
City,
one
thing
and
I
think
that
Ben
talked
is
that
I
suggest
to
allow
support
of
ntp
format
as
well,
because
the
1588-
probably
it's
more
advantage
for
the
hardware
timestamps.
If
you
are
in
the
software,
then
more
likely
that
you
are
dealing
with
ntp
that
ntp
times
time
format
will
be
a
native
timestamp
format.
But
bigger
question
is
why
not
to
use
our
site
marketing
methods
because
I
think
that
automate
our
marketing
method
can
help
you
1.
C
Do
the
problem
and
challenges
of
unidirectional
measurements
of
time
is
that
you
require
a
clock
synchronization
in
your
domain?
So
that's
not
the
case,
for
example,
when
you're
doing
it
on
alternate
marking
method,
you're
doing
on
a
note,
for
example
the
residence
time
measurement,
you
don't
need
to
have
clock
synchronization
between
your
entities,
because
you
are
doing
just
residence
time,
which
is
a
delay
introduced
by
the
node
right.
V
L
V
W
This
is
Linda
from
Maui.
This
question,
like
speaking
of
the
synchronization.
Well,
this
kind
of
time
stamp
measurement
are
you
intending
for,
like
a
Jason
knows
always
like
across
the
network.
Like
does
that
mean
you
have
to
have
time
synchronization
for
all
the
nodes
to
be
able
to
make
it
accurate?
Well,.
V
We're
talking
about
an
SFC
domain,
so
it's
yeah.
The
idea
is
that
when
use
time
stamps,
you
assume
there's
kind
some
kind
of
a
synchronization
mechanism
between
the
SFC
at
least
classifiers,
and
possibly
s
FF
s
not
necessarily
depends
on
how
you
use
the
timestamps.
But
yes,
the
assumption
is
that
they're
synchronized
also.
V
G
Hello,
hello,
good
morning,
everybody
I'm
the
Russian
super
caster
and,
on
behalf
of
all
the
listed
authors,
I
am
presenting
this
update
to
the
draft.
So
in
the
last
meeting
in
this
draft,
we
described
the
problem
of
service
indirection
in
the
context
of
SFC,
so
service
in
Direction
means
dynamic
and
fast
switching
of
service
path
between
service
functions.
The
SRR
service
function
was
introduced
in
the
last
meeting
which
handles
this
dynamic
indirection.
And
what
would
this
function
includes?
It
decouples
service,
consumers
and
service
providers.
G
A
service
consumer
may
be
connected
to
multiple
service
providers
through
these
SLR
service
function
and
the
classification
may
not
be
required
and
it
switches
the
traffic
flow
to
any
service
that,
based
on
this
instantaneous
situation
and
policy,
next
slide,
please.
So
in
order
to
in
this
draft,
we
go
into
some
of
the
details
of
this
SLR
service
function
that
was
introduced.
So,
to
start
with,
we
introduced
a
concept
of
HTTP
based
transport
within
the
context
of
SFC
framework.
Here
we
described
how
urls
can
be
used
as
an
addressing
scheme
where
we
create
service
function.
G
Paths
as
shown
with
using
that
URL
as
the
naming
of
the
service
functions
and
this
named
based
relationship
allows
us
are
basically,
we
see
them
to
be
realized
through
replicated
instances.
So
us
so
a
service
consumer
now
can
be
connected
to
multiple
providers,
and
these
are
the
replications
that
can
use
these
different
names
and
then,
in
turn,
their
routed
towards.
The
specific
instance
is
realized
by
this
function.
G
Now,
during
this
notion
of
HTTP
based
transport
within
the
SFC
architectural
framework
in
terms
of
high
level
operation,
so
the
classifier
function
may
now
interact
with
this
srr
to
obtain
a
what
we
call
a
service
encapsulation.
So
we
will
get
into
the
details
about
the
service
encapsulation
in
the
next
slide,
but
so
the
classifier
function,
when
looking
to
a
network,
look
at
a
map
and
determines
that
the
next
service
function
is
this
URL.
G
That
is
the
name
that
is
described
there,
and
this
information
is
provided
to
the
SLR
to
obtain
the
next
hop
information
and
then
srr
returns.
The
service
encapsulation
next
like
this.
So
here
is
the
details
of
this
SL
function,
which
is
broken
down
into
the
different
functions.
The
first
function
is
the
NAP
at
the
ingress,
which
terminates
the
client
side
layer
protocols.
G
Identifier
and
this
path,
identifier,
is
utilized
for
any
future
request
for
a
given
URL
based
service
function,
and
this
is
very
delivered
to
the
inverse
map.
Next
slide,
please.
So
here
we
describe
the
function
of
this
transport
derived
SF,
f
or
TS
FF.
It
is
basically
it
it
is
in
the
communication,
with
the
communication
between
ingress
and
egress
maps,
as
well
as
snaps
to
PCE,
is
realized
through
this
transport
derived
SMS
and
this
transport
board
s
FF.
There
are
three
possibilities
that
are
described
here,
which
is
basically
one.
Is
this
Sdn
based
approach?
G
A
G
If
we
remember
we
are
when
I
started
like
we
I
said
that
if
there
is
a
possibility
that
I
can
have
this
service
producers,
I
can
have
multiple
instances
of
the
service
producer
which
are
can
be
connected
to
a
single
consumer.
So
in
that
case,
I
can
use
this
beer
multi
castings
mechanism
and
and
then
we
utilize
a
flow
aggregation
approach
which
is
called
edge.
Switch
classification
next
slide,
please.
So
in
terms
we
see
there
are
some
of
the
new
protocol
considerations
that
may
be
required.
G
The
first
one
is
nap
tune,
a
protocol
for
HTTP
HTTP
based
messages,
the
exchange
between
client
and
server
naps,
there's,
maybe
a
protocol
for
nap
to
pce
for
path,
computation
and
obtaining
routing
information.
There
may
be
a
requirement
for
overlay
transport
protocol
used
for
transport
level,
exchange
registration
protocol
used
to
register
fqdn
surveys,
endpoints
and
I.
Think
the
last,
but
not
the
least.
The
most
important
is
content
certificate
distribution
protocol
to
enable
HTTPS
support
next
slide,
please
so
yeah.
So
this
is
the
last
slide
again.
G
The
intention
is
to
collect
a
feedback
and
the
use
case
that
was
described
earlier
and
the
details.
Whether
looks
reasonable
or
we
can,
we
are
open
to
suggestions
and
also
just
to
make
everybody
aware.
We
are
working
on
this
solution,
engage
2020
flame
project
with
experience
planned
for
early
2018
and
beyond.
So
that's
the
end
of
the
presentation.
Any
questions
please
hi.
F
F
F
G
F
A
G
F
E
Hi,
so
this
is
the
last
presentation
before
the
lunch
so
I
try
to
make
it
fast
to
not.
You
know,
hold
you
back
from
your
deserve
lunch,
so
there's
a
common
work
with
some
with
our
colleagues
from
interdigital.
My
name
is
Otto
hacker
I'm,
actually
presenting
on
behalf
of
Raman,
who
is
the
first
also,
but
could
not
come
so.
This
comment
work
of
Debashish,
which
has
presented
the
slides
and
Dirk
and
Akbar,
and
also
Zoran
and
Raman.
So
the
point
is
here:
the
point
is
here
to
somehow
extend
or
discuss
the
notion
of
this
T.
E
E
O
E
So
because
of
that,
essentially,
what
we
tried
to
do
we
try
to
produce
an
aggregated
transport
over
directly
over
is
the
end,
so
be
nice.
The
advantage
of
Sdn
in
this
sense
here
is
that
you
can,
of
course,
have
a
completely
different
naming
scheme,
and
that
is
what
is
being
proposed.
We're
essentially
network
at
the
end
acts
as
a
fabric,
just
interconnecting
the
edge
nodes,
so
you
have
a
minimum.
E
The
algorithm
that
is
presented
in
a
paper
that
we
have
written
on
that
behalf
in
this
regard
essentially
achieves
the
following
goal:
I'm,
giving
that
you
have
been
a
touched
number
of
devices
to
and
as
jiendo
main
let's
say,
the
number
of
rules
within
the
Sdn
network
is
minimum
okay,
so
this
is
an
algorithm.
I
will
not
go
in
all
details
of
that
you
can
read
the
paper.
We
can
discuss
it
offline,
it's
not
a
problem,
but
the
point
is
that
we
can
have
a
special
naming
that
is
of
no
big
deal.
E
We
specially
named
the
edge
devices
such
that
essentially,
we
can
aggregate
them
perfectly
in
the
switches
sides
of
the
number
of
forces
which
is
as
minimum
now
what
we
do.
We
very
simply
misuse
that
so
to
say
or
abuse
this
mechanism
to
enable
SFC.
So
what
exactly
we
do
is
we
essentially
defines
the
s
ffs
as
being
the
edge
knowledge.
So
the
idea
behind
that
was
the
driving.
E
Let's
say
motivation
behind,
that
is
to
say
that
n
SFF
may
be
some
kind
of
ingress
router
to
let's
say
data
center,
where
several
many
of
those
SF's
can
reside
and
therefore,
from
the
transport
network,
point
of
view
and
SFF
would
be
somehow
an
edge
node.
Okay.
So
essentially
we
give
an
incoming
request.
We
need
to
you
know,
route,
this
incoming
request,
which
has
been
classified
to
the
SFF
and
from
there
on
the
SFF
will
figure
out,
which
SF's
are
you
know
responsible
for
that
and
so
on
it
goes
so.
E
E
Ff,
okay
and
this
is
being
essentially
assigned
because
we
still
here,
try
not
to
use
the
NSA
Chadha
again,
not
because
we
do
not
like
it,
but
simply
because,
for
example,
open-floor
cannot
really
use
this
right
away
and
the
switches
and
the
transport
domain
is
independent
of
that.
So
we
assign,
in
the
classifier
that
type
of
ID
kind
of
consisting
of
three
distinct
identifies,
and
this
is
essentially
chaining
them
through.
E
First
through
the
to
the
s
FF
s
and
the
SFF
looks
at
the
next
byte
or
whatever
is
necessary
in
terms
of
lengths,
depending
on
how
many
SF's
are
residing
within
one
s,
FF
defines
which
is
the
SF.
Then
it
comes
back
and
so
on.
It
goes
right
and
this
ID
change
information.
If
it's
not
available.
The
point
is
the
following:
if
we
have
several
chains,
starting
for
example,
in
some
service
function,
s
f1,
if
this
exists,
then
we
have
you
know
in
the
transport
network.
E
We
need
to
have
different
identifies
for
that,
such
that
we
can
distinguish
them.
So
if
this
is
not
possible
to
have
a
specific
ID
for
the
chain
as
such,
because
maybe
the
architecture
disagrees
with
that,
then
what
we
can
do
is
we
can
define
a
fixed
node.
Well,
let's
say
as
a
prime,
which
is
you
know
just
another
identifier
for
s
f1
as
a
fun
prime
sorry-
and
this
would
then
just
as
well
work
so
there's
an
alternative
addressing
for
that.
E
The
next
slide,
please,
so
this
now
just
very
simply
explains
more
or
less
what
I
tried
to
explain
right.
So
once
you
classified
you,
give
this
hierarchical
addressing
through
this
hierarchical.
Addressing
now
the
transport
network,
just
used
as
a
fabric
can
of
course
delivers
a
message
to
Z
s,
FF
1,
in
this
case
the
s
FF
one
would
then
essentially
deliver
it.
Looking
at
the
next
in
the
next
bit
filled
to
the
right,
SF
d,
SF
would
always
reply
back
very
simply
right
where
the
SFF
one
now
would
use.
E
Essentially
the
mapping
information
as
pre-installed
by
the
transport
pre-configuration
again
we
use
a
fabric.
A
fabric
means
that
essentially,
all
the
edge
nodes
have
already
pre-configured
passes,
so
we
can
skip.
Maybe
this
slide
and
the
next
one,
but
just
explain
how
it
works:
yeah
next,
one
next
one
yeah
this
is
this
alternative,
advancing
that
they
just
explained.
We
can
also
speak
that
next
slide:
okay
and
that
now
integrates
essentially
with
the
SRR
in
the
sand.
E
E
So
essentially
the
chaining
becomes
some
kind
of
chaining
of
let's
say
URLs,
which
needs
to
need
to
be
translated
every
time
to
add
the
advances,
and
these
IP
addresses
would
need
to
be
resolved
somehow
to
map
them
to
the
layer
to
pass
right,
and
for
this
we
can
essentially
use
exactly
this
as
the
N
typical
transport,
as
the
bussers
explained
before
next
slide.
Please
yeah
I
can
skip
this
one,
because
this
essentially
just
explains
that
we
can
work
with
several
domains
and
now
the
pre-warming.
E
E
What
happens
is
that,
of
course,
the
the
ready
communication
was,
for
example,
a
PCE
or
in
Sdn
based
transport,
probably
was
a
controller
which
has
to
define
the
past
and
find
it
find
it
passed
through
all
that,
and
this
can
be
essentially
shortened
down
by
pre-warming.
It
means
that
the
those
na
piece
from
the
SRO
drop
before
they
can
essentially
subscribe
for
this
preforming
service
and
very
simply
get
all
the
possible
change
that
will
you
know
that
are
likely
to
go
through
them.
E
That's
the
idea
behind
that,
and
then
we
have
the
next
slide,
which
describes
how
it
could
be
done,
which
kind
of
concludes
my
talk
next
slide,
please
so
the
triggers
for
this
pre-warming
and
what
what
chains
have
to
be
pre
want,
where
that
can
be
essentially
defined
from
the
orchestration,
which
means
that
from
the
allocation
of
the
basic
idea
of
the
s,
FG
chains
right
and
then
essentially
it
can
get
to
the
PCE
to
get
this
notes
yeah.
That's
it
next
slide.
E
Yes,
so
what
we
try
to
do
here
is
to
say
that
we
can
use
the
transport
directly
so
specifically
not
looking
at
the
nsh
others.
But
again
we
do
not
mind.
The
inhalation
has
done
exactly
the
opposite
will
like
them,
but
we
just
try
to
show
that
and
as
the
end
transport
can
be
used
effectively
and
efficiently
to
transport
a
lot
of
different
chains.
Alright,
now
we
did
not
yet
address
just
as
a
first
submission
I
think
there's
a
lot
of
work
necessary
to
advance
this
work.
F
Hey
Carlos
and
I
had
a
question
about
the
SF
ID
and
whether
or
not
that
concept
supports
a
service
function
being
visited
multiple
times
in
one
chain.
Did
you
talk
with
a
virtual
SF
I
do
I
I
was
thinking
about
last
night,
but
I
don't
quite
follow
my
reason
anymore
and
it
seemed
like
it
might
not.
I
was
a
little
concerned
about
that
in.
E
Principle,
it
can
work
with
any
ID
because
again
and
if
you
look
exactly
at
what
we
did,
we
kind
of
concentrate
on
the
transfer
domain
only
which
essentially
ends
at
the
SFF.
Then
it's
a
matter
of
SFF
internal
considerations.
If
s
FF
has
thousands
of
different
SS
and
handles
on
a
specific
way,
it
can
use
exactly
this.
The
nice
part
of
it
is
that
you
don't
have
to
delve
into
this
because
it
can
be.
You
know
relevant
to
what
Evers
is,
as
if
F
considers
correct.
A
So
your
chairs
sat
down
with
the
ad
and
tried
to
put
together
a
list
of
things
we
at
least
know
people
have
been
wanting
to
work
on
that
seemed
to
fit
within
the
scope
of
what
we
think
the
working
group
is
trying
to
do
that
are
at
work
that
belongs
in
other
working
groups
and
that
sort
of
thing.
So
these
two
slides
are
my
effort
to
capture
that
discussion.
This
is
very,
very
preliminary,
but
in
courtesy
to
the
working
group,
we're
sharing
it
anyway.
Really
it's
up
to
you
guys
what
ends
up
in
the
Charter.
A
So
with
that
I'll
try
to
walk
quickly
through
the
sets
of
bullets.
Here,
there's
probably
too
many
bullets
for
a
charter.
Even
we
can't
quite
do
everything
all
at
once.
It
doesn't
work,
but
these
are
all
things
we've
seen
interest
in.
So
the
top
line
item
was
Frank's
proof
of
transit
work.
We
know
that
he's
been
working
on
it
and
be
the
security
reviews
raised
this
issue
repeatedly.
A
A
What
can
we
do
to
talk
about
securing
metadata
when
we
need
to
when
we
need
to
provide
integrity,
protection,
authentication
or
confidentiality,
above
just
obscuring
it
by
interaction
in
directions?
Very
nice,
but
it's
not
powerful.
So
we
have
to
look
at
what
we
need
to
do
for
that
we'd
like
to
deal
with
the
question
of
transport
considerations.
A
For
example,
how
does
the
transport
have
to
react
to
congestion?
How
does
transport
have
to
react
to
other
common
issues
when
we
try
to
list?
What
would
we
be
talking
about?
We
came
up
with
an
unfortunately
long
list
of
four
different
things
that
are
all
simple.
These
are
just
the
simple
cases
we
know
there
are
more,
and
this
is
why
we're
all
we're
a
little
concerned
about
how
to
scope
this
work
item.
A
A
Network
management-
you
know
stuff-
has
to
be
manageable,
we've
sort
of
implied,
as
you
can
see
in
the
NS
H
draft.
It
talks
about
certain
configuration
information
being
provided,
whether
you
actually
configure
it
with
yang
or
not
whether
you
actually
configure
it
with
Netcom
for
reskin
for
something
else.
It
is
the
common
way
for
capturing.
You
need
to
be
able
to
configure
this
information
in
the
IETF
other
places.
One
might
use
other
ways,
but
that's
how
the
IETF
talks
about
it.
So
we
need
to
do
that.
A
There's
ongoing
control,
plain
work,
Adrienne
referred
to
the
best
work,
there's
also
work
going
on
in
the
PCE
working
group.
We
need
to
coordinate
with
that
work.
To
make
sure
it's
doing
what's
needed,
we're
not
going
to
undertake
defining
control
protocols
here
there
are
good
working
groups
for
doing
that.
If
somebody
has
a
I
need
a
brand
new
protocol
and
I
can
prove
that
we
really
need
it.
We
could
have
that
discussion,
but
that's
a
pretty
high
bar
to
meet
because
there
are
working
groups
for
doing
control
protocols.
A
One
of
the
aspects
of
this
that
comes
up
is
making
sure
we
represent
in
the
control
the
operations
way
to
work
with
already
deployed
things
that
we
know
are
doing
service
Jenny
I
mean
it's
all
well
and
good.
To
say
here:
do
this
brand-new
wonderful
thing,
service
chaining
is
not
new,
we're
not
under
a
pretense
that
we
invented
the
underlying
problem.
Operators
had
the
problem.
Vendors
were
solving
the
problem
so
working
out
how
the
various
control
mechanisms
was.
A
It's
the
yang
models
or
the
control
protocols
can
represent
the
interworking
with
other
mechanisms
so
that
people
can
add
this
to
their
network
and
get
working
systems
is
probably
important.
The
question
of
actually
supporting
defining
leggett
pre-existing
mechanisms
is
a
much
harder
problem.
Don't
want
to
get
into
that
metadata
type
codes
for
the
MD
to
promote
finishing
the
MD
1
documents.
These
seem
to
be
things.
People
want.
We
just
had
a
presentation
on
one
of
them
where
there
is
overlapping
areas
of
concern
where
other
working
groups
are
working
on
other
solutions
to
service
chaining.
A
We
need
to
coordinate
with
them.
We
need
to
talk
with
them.
Help
make
sure
the
problems
addressed,
that
the
solutions
address
the
requirements.
We
don't
get
to
tell
other
people.
No,
you
can't
work
on
things
we
do
get
to
say.
These
are
important
things
you
need
to
consider
in
working
on
such
things.
Other
things
that
come
up
there's
either
hierarchical,
work
that
David
Dolson
and
Mohammed
Buccaneer,
and
a
number
of
other
people
have
done
that
seems
to
still
fit
within
the
scope.
It's
intradomain
there's
there
various
ideas
for
how
that
should
work.
A
That
would
be
a
working
group
item
if
people
start
actually
deploying
nsh,
we'd
love
to
be
hearing
about
it
getting
feedback
on
woops.
This
was
a
problem.
This
was
wonderful,
I'd,
love
to
hear
that,
of
course,
but
we
need
to
hear
about
actual
deployments
and
if
we
need
to
write
a
guideline
on
having
tried
this,
we
found
you
need
to
keep
these
things
in
mind.
Maybe
that's
a
useful
thing.
We
can
produce
real
experience.
Real
world
is
critical,
may
need
some
applicability
documents.
People
keep
wondering.
A
N
A
N
Are
a
lot
of
use
cases
where
segments
routing
has
to
be
deployed
along
with
a
message?
So
there
are
two
proposals
like
we
presented
saw
that
you
know
Sigma,
noting
with
MPLS
data
plane
and
SH
Sigma,
noting
with
ipv6
data
plane
and
SH.
These
are
the
real
deployment
considerations
where
both
are
needed,
so
we
might
have
to
add
explicit
chart
right
where
and
SH
and
traffic
engineering,
some
sort
of
tracking,
which
is
Sigma,
not
isn't
one
way
of
doing
traffic
engineering.
L
A
A
L
T
A
R
Rigs,
sorry,
not
here,
I
think
the
transport
one
is
a
very
important
one
in
my
view,
because
we
have
been
trying
to
do
interoperability
between
multiple
as
of
F's
with
different
vendors
and
today,
because
there
is
no
real
draft,
it
is
hardly
impossible
to
agree
I.
You
actually
have
to
agree
between
the
different
members
and
I
think
it
would
be
very
good
to
actually
have
some
drafts,
and
maybe
one
transport
protocol
will
not
be
sufficient,
because
you
see
clearly
and
people
moving
MPLS.
R
There
is
a
number
of
proposals,
but
most
likely
we
also
need
something
for
data
center.
We
do
DP
or
I,
have
Geneva
/vx,
LAN
GP,
or
something
like
that
as
well,
because
that's
where
you
see
most
of
the
demands
from
at
least
from
my
perspective,
so
what
for
me,
the
transport
part
is
very
important,
in
my
view,
I've
mainly
for
interoperability
purposes.
From
my
own
experience.
E
At
Riga,
who
are
we
so
yes
I?
Second,
that
I
would
say
that
indeed
we
should
look
into
different
transferred,
may
be
going
to
some
kind
of
BCP
like
document,
which
explains
how
different
transport
can
should
be
used
with
which
encapsulations
not
only
for
the
NIH
head
of
Russia,
but
also
for
the
you
know
for
the
content
for
the
chains
and
probably
with
branching
possibilities
with
dynamic
aspects.
That
would
be
I.
Think,
because
if
you
read
it
now,
somehow
it's
missing,
you
can
guess
and
aha,
maybe
it's
IP
IP
or
maybe
it's
something
else.
D
From
our
self
more
of
a
general
question,
so
all
of
this
is
useful
good
stuff.
So
how
do
you
prioritize?
Should
we
go
and
do
something
like
a
Condorcet
Paul
in
the
overall
working
group
and
understand
where
people
are
kind
of
congregating
so
that
we
pick
the
topics
that
people
both
consider
important
and
want
to
work
on
first
and
then
get
off
dates,
timelines
defined
for
those
because
I
very
much
second
than
II,
that
we
go
and
reach
other
and
get
the
new
stuff
in,
but
I.
D
A
W
X
A
We're
not
talking
about
transport
om,
we're
talking
about
SF
Co
am
beyond
that.
The
debate
between
IO
and
the
various
IO
am
encapsulations
Gregg
Mercy's
proposals
on
om
headers,
other
people's
proposals
for
om
tlvs.
That's
for
the
working
group
to
decide.
If
we
have
the
work
item
and
I
sure
hope
we
have
the
work
item.
The
Charter
is
not
going
to
specify
the
solution.
The
Charter
is
going
to
specify
the
problems.
W
H
Atlas
right,
so
the
question
is
we
can
do
we
can
return
her
to
a
lot
of
things.
What
do
you
need
to
get
this
stuff
deployed?
What
do
we
need
to
have
it
be
operationally
useful
in
people's
networks
and
that's
what
needs
to
be
in
the
Charter?
That's
what
you
nest?
What's
what
you
need
and
what
you
care
about,
so
that
you
will
be
coming
and
doing
the
work
rapidly
to
solve
the
real
problems.
H
I
heard
a
lot
of
interest
in
the
transport
I
hear
folks,
working
on
L
AM
we've
been
working
on
om
for
five
years.
Is
there
what
are
the
operational?
How
do
we
get
this
piece
done?
Is
there
there's
the
work
on
intradomain
hierarchical?
Is
that
let's
keep
augmenting
or
is
it
something
people
operationally
need
right
at
the
working
group
has
been
stalled
for
a
while
working
on
getting
nsh
done.
It's
done!
H
Okay,
and
now
you
can
do
the
work
that
you
passionately
care
about,
that
you
need
for
deployments
and
to
have
a
complete
solution,
but
to
make
that
happen
it
requires
we
say
yes,
I
want
to
do
this
and
put
the
time
and
energy
into
writing
and
reviewing
the
documents
and
getting
stuff
moving.
I
don't
want
to
put
stuff
in
the
Charter
where
there
isn't
that
energy.