►
From YouTube: IETF104-SFC-20190328-1610
Description
SFC meeting session at IETF104
2019/03/28 1610
https://datatracker.ietf.org/meeting/104/proceedings/
B
Okay,
can
somebody
at
the
back
close
the
door
for
us
and
we
will
start
the
session.
Thank
you.
We
at
least
have
all
I
think
we
have
all
the
presenters
here,
I
hope,
so
we
will
begin
with
the
chairs
overview
note.
Well,
this
is
the
note.
Well
can
one
of
the
people
in
the
conversation
at
the
back
to
us,
the
favor
of
closing
the
dollar.
B
B
We
will
go
over
the
agenda,
which
is
listed
very
briefly
here,
but
in
more
detail
on
the
next
slide
and
then
a
couple
of
summary
slides
from
the
chairs,
and
we
will
then
let
people
present.
We
have
a
fairly
loose
schedule.
So,
although
I
will
watch
time,
I'm
not
going
to
be
really
hard
with
presenters,
but
if
people
are
repeating
themselves
or
whatever
I
will
ask
to
move
on.
B
Following
that
we
have
a
presentation
on
active
OAM
from
Greg
mirskiy
on
the
based
on
the
working
group
draft
on
multi-layer,
OAM
and
then
Frank
will
be
talking
to
us
about
the
working
group.
Draft
on
IO
am
in
bandeau
a.m.
and
then
again
on
his
proof
of
transit
work,
which
we
had
an
extensive
discussion.
Last
time
and
I
hope
we
have
reached
agreement
on.
What's
in
there
and
I.
Think
I
told
that
the
authors
that
we
had
agreement,
then
our
ting
will
be
presenting
two
other
drafts
on
I.
B
So
status
first
things
to
note
that
DC
allocation
is
a
working
group
draft.
We
could
request
informational
publication,
but
I
haven't
seen
any
working
group
interest
and
in
the
absence
of
interest
we
can't
request
working
group
publication.
If
nobody
does
anything.
If
nobody
says
if
there
aren't
enough
people
who
say
they
want
to
see
interest,
we're
just
gonna
have
to
let
it
die
it's
okay,
we
can
do
that.
We
can
mark
it
dead,
but
it
was
a
working
group
draft
for
the
information
of
this
community.
B
B
There
was
enough
presentation
just
now.
No
there
was
this
was
different,
so
we
had.
There
has
been
presentation
in
the
past
on
draft
assured
spring
nsh,
which
has
been
presented
and
is
likely
to
be
adopted
in
the
ANA
in
the
spring
working
group
just
again,
something
that
will
be
liaised
with
us
advanced
in
a
different
working
group.
B
B
B
We
have
a
slide
that
talks
about
it
in
one
narrow
context
on
the
next
slide,
that
was
when
Mohammad
Baqir
but
and
we
have
Frank's
work
on
proof
of
transit,
which
is
a
little
piece
of
the
security
puzzle.
Nice
little
piece,
it's
an
elegant,
little
piece,
but
it's
a
little
piece
of
the
puzzle.
We
really
need
to
address
this.
We
need
some
people
to
step
forward
to
address
this.
This
is
not
a
case
where
the
chairs
can
just
throw
out
a
draft
it'll.
All
work
out
right:
no,
we
really.
B
B
B
Some
med
was
wondering
reasonably
should
he
be
addressing
the
integrity
protection
in
the
context
of
his
specific
TL
fees,
and
if
we
don't
have
a
working
group
approach
that
it
crosses
tlvs
and
protects
multiple
pieces
of
metadata,
then
we
have
to
go
and
look
at
protection
for
each
individual
TL
v
instead,
and
that
seems
to
me
to
be
a
very
painful
path
to
go
down,
but
he
asked
us
to
bring
up
up
this
issue
to
the
working
group
I
gathered.
He
couldn't
be
here
even
though
we're
in
Europe
this
time
and
he's
in
France.
B
We
all
have
trouble
travelling
even
short
distances
periodically,
so
we
wanted
to
call
attention.
He
is
asking
for
feedback
from
the
working
group
on
this
particular
topic
and
that
this
is
a
subtopic
of
a
much
bigger
topic
for
the
working
group
as
a
whole.
Does
anybody
want
to
comment
on
this
either
the
general
or
the
specific.
C
So
you
know
basically
there
aren't
that
many
that's
available,
so
you
just
pick
a
couple
of
them.
Of
course,
if
you
have
sufficiently
strange
things
happen,
then
certain
bursts
of
congestion
and
so
forth.
It
is
still
possible
that
packets
will
get
dropped
in
severe
cases,
but
normally
they'll.
That
will
not
happen.
C
So
the
reason
to
specify
a
method
for
sending
this
condition.
Information
back
to
the
classifier
is
so
that
if
you
have
extender
or
sort
of
function
changing
domain,
you
can
still
do
that.
That's
why
it's
a
standardized
method
suggested
that
you
certainly
some
particular
implementation.
If
it's
all
you
know
from
some
other
vendor
or
whatever
could
use
a
different
method,
there
is
a
draft
in
the
DSP
WG
on
tunnel
congestion
feedback,
which
provides
a
mechanism
for
doing
this.
So
basically
the
suggestion
is:
did
you
use
that?
C
Then
this
questions
is
it
been
brought
up
about
exactly
what
actions
the
classifier
could
possibly
take
so
there's.
This
is
simply
taken
from
the
current
draft
and
I
think
a
little
more
discussion
of
this
on
the
list
would
been
called
for.
It
would
be
reasonable.
You
need
to
be
very
careful
about
this.
To
avoid
undesirable
interactions
between
actions
you
might
be
taking
within
the
service
function,
changing
domain
and
actions
you
might
be
taking
in
the
overall
path
from
the
original
source
to
the
final
and
so
I.
C
Don't
know
if
I
want
to
talk
too
much
more
about
that
I
think
there
has
been
some
commenting
on
the
list
which
could
take
a
look
at
if
you
haven't
already,
and
probably
some
of
these
could
be
reduced
at
some
additional
caveats
may
need
to
be
added
there
to
be
sufficiently
cautious
about
things.
You
could
do
to
make
sure
you
don't
have
any
undesirable
interactions
with
overall
now
half
the
feedback,
because
all
this
stuff
works
better.
C
If
the
PSF
doesn't
recognize
the
network
service
header
at
all,
but
at
the
extent
that
you
don't
have
it
implemented
at
some
place,
which
could
be
a
bottleneck,
whether
it's
in
a
service
function
or
SFF
for
just
a
router
between
s,
FS
or
anything
like
any
place
that
there
could
be
a
bottleneck,
if
that
particular
bottleneck
doesn't
implement
ECM,
then
that
congestion
won't
be
managed
by
the
ECM
mechanism.
So
it's
on
the
ideal
case.
You
would
have
it
at
any
place.
D
E
F
F
Is
Oh
protocols,
then
it's
erroneous
situation
and
that's
what
we
discussed
with
Edwin.
B
F
F
B
The
list
do
we,
the
obvious
question
I
think
is
in
the
affirmative,
but
I
want
to
check.
Are
we
reasonably
confident
that
if
we
get
a
mouth
for
an
echo
request,
we
can't
parse
that
it
really
is
an
echo
request
and
we
really
know
who
should
we
should
cal
about
it?
It's
this
error
code,
one
malformed
echo
request.
D
B
F
F
F
B
Any
questions
comments,
we're
gonna
end
way
ahead
of
schedule:
okay,
next,
okay,
Frank
and
Frank,
while
you're
coming
up
I'm
going
to
make
one
comment
about
this
draft.
This
was
something
I,
probably
told
you
guys
quite
a
long
time
ago,
but
since
we're
almost
done
with
it,
you
need
to
address
the
number
of
authors.
We
are
not
going
to
request
publication
with
ten
front
page
authors.
B
B
G
Going
to
go
and
create
an
author's
section
and
then
do
the
editor
thing
or
whatever.
Okay,
so
we're
a
really
quick
update,
so
we're
gonna
go
and
further
get
a
hand.
Now,
if
you
get
out
of
Shatila
I,
believe
quick
update
on
the
nsh
draft,
there
is
not
real
real
update
on
that
document.
Other
than
Carlos
did
a
bunch
of
clean
up.
The
references
make
it
kind
of
the
most
recent
references
one
little
bit
of
an
alignment
on
the
header
so
that
it's
fully
in
sync
with
8,300.
G
There
was
a
tie
kind
of
a
Miss
reference
earlier
on.
That's
pretty
much
it
along
with
the
need
to
go
and
consolidate
the
author
list,
so
not
sure
whether
anybody
else
sees
anything
else
that
we
needed
won't
get
done
in
this
particular
document
would
be
nice
to
go,
get
some
sense
from
the
people
in
the
room
if
we
could
call
it
done.
Assuming
we
clean
up
the
author
list.
G
G
Okay,
the
next
one
is
the
the
prove
of
transit
draft
that
received
a
fair
amount
of
conversation
on
the
list
and
Joe
to
his
earlier
points.
Summarized
it
like
yeah.
Well,
we've
seen
some
discussion
thing
happening
and
you
well
concluded
that
we
should
go
and
consolidate
the
number
of
options
in
the
draft
to
just
using
for
ordered
proof
of
transit,
to
use
a
single
mechanism
instead
of
documenting.
G
That's
what
we've
done
so
the
one
section
and
was
just
a
few
lines
that
was
talking
about
nested
encryption
just
appeared.
That's
the
major
change
in
the
document
from
a
Content
perspective,
and
that
is
what
we
discussed
on
the
list
and
also
at
at
RIT,
F
and
Bangkok.
The
other
live
one
is
and
I
have
to
really.
Thank
you
tell
for
a
really
detailed
walk
through
the
document
and
coming
up
was
saying.
Well,
we
need
this
net
fix
this
net
fixed
and
this
net
fixed,
and
so
he
made
me
sit
down.
G
We
right
before
the
deadline
and
fix
all
these
little
nets
that
he
found,
which
I
believe
is
really
good
because
it
provided
for
another
level
of
clarity,
kind
of
cross,
francis,
as
references
within
the
document
where,
where
questions
can
be
asked
by
answered
by
really
looking
at
the
yang
model
that
we
have
in
the
document
around
kind
of
what
units
do
you
use?
What
ranges
of
values
do
you
expect?
All
of
that
is
nicely
articulated
by
the
yang
model,
so
we
don't
need
a
additional
text
for
that.
B
Actually
raises
an
interesting
question
because
I
would
like
to
get
this
document
out
the
door,
but
I'm
not
sure
we
want
a
free-standing.
Io
am
SF,
SFF
or
they're
they're,
probably
pieces
to
deal
with
all.
Do
we
well
doesn't
matter
what
I
want?
Do
we,
as
a
working
group,
want
a
separate,
mid
mid
module
just
for
IO
am
for
proof
of
transit
specifically
or
should
do
it?
Do
we
need
to
somehow
integrate
it
in
the
non-existent
yang
model
which
would
slow
us
down?
F
B
G
We
can
go
time,
we
could
go
and
I
think
the
probably
the
easier
way
is
to
found
that
if
you
really
want
that,
we
can
farm
it
out
and
to
dedicate
a
document
cuz
well.
Some
of
that
is
pretty
much
also
implemented
as
a
standalone
document
as
a
standalone
yang
model,
and
no
do
that's
almost
used
one-to-one
or
what
is
in
audio
as
running
code,
so,
which
is
why
I
have
some
sympathy
for
keeping
it
as
a
dedicated
model.
B
G
B
Think
simple:
can
you
send
an
email
to
the
list,
noting
that
you've
got
a
yang
model
for
this
proof
of
transit
work
in
the
document
and
asking
the
list
whether
they're
comfortable,
with
keeping
that
keeping
that
yang
model
in
this
doctrine,
because
I
would
actually,
if
the
working
group
is
comfortable
with
it,
they
can
advance
it
that
way.
Okay,.
G
G
H
Okay,
good
afternoon,
everyone
I'm
King
from
Zeki.
This
presentation
is
about
2cm
wishes
to
introduce
the
which
is
used
to
check
the
consistency
of
the
SFC
parts,
I'd
like
to
introduce
the
CM
first
in
case
you
are
the.
This
is
your
first
time
to
read
this
draft
from
these
diagrams.
You
can
see
that
once
as
f
SF
FF
your
received
comm
request
message,
it
will
take
two
actions.
H
One
is
true
for
wordless
eorum
request
message
to
his
nest:
s
FF
and
the
another
action
is
that
the
SS,
the
SFF,
will
stand
back
serum
repair
message
with
the
information
of
the
SF
and
that
attached
to
this
s,
FF,
and
so
with
correcting
all
the
say
or
M
reply
message.
We
can
get
the
pass
of
lists,
so
a
service
function
chain
and
the
orders
of
the
service
functions
can
be
checked
as
well.
H
This
job
has
been
presented
several
times,
and
so
this
time
I
will
present
the
modification
from
zero
straight
version
and
English.
In
the
in
this
modification,
we
mainly
focused
on
the
consideration
of
load
balance
with
medical
as
service
functions,
and
first
we
change
SF
information
here
we
to
s
FF
information
recorded
here
way
and
so
that
s
FF
can
increase
the
information
about
service
functions
into
this.
H
And
and
to
make
the
procedure
to
be
clearly,
so
we
also
provide
two
examples
are
two
examples.
My
example
is
that
much
more
service
functions
as
host
our
as
happy
in
SF
F.
In
this
case,
the
information
about
each
s,
service
functions,
I
must
be
listed
as
separate
SF
information,
sub
theories
in
the
serum
replay
message
and
another
example-
is
that
multiple
service
service
functions
in
attached
to
our
SF
f
is
for
load
balance.
H
That's
all
we
are
in
our
modification
and
I
want
to
see
that
this
draft
has
been
presented
four
times
in
previous
meetings
and
we
have
updated
the
chapter
for
many
times.
According
to
the
comments
in
meeting
and
the
discussion
in
the
mail
list,
I
think
I
think
the
chapter
is
ready
for
working
group,
adoption
and
always
I
hope
everyone
could
review,
least
draft
and
give
us
comments
and
support.
B
H
The
motive
of
this
work
is
that
SFC
young
model
is
a
master
in
our
charter,
so
it's
also
a
Rick
is
also
required
in
our
SMC
working
group
and
I
want
to
say
that
this
young
model
is
based
on
FC,
six,
seven,
six,
six,
five
and
FC
8300
and
I
want
to
make
make
it
clear.
That
least,
yamato
is
mainly
focused
on
configuration
of
SFF
and
the
state
information
of
SF
for
crossfire
yamato.
I.
Think
that
will
be
our
work
in
later.
H
This
slide
shows
the
design
chain
of
the
SF
in
configuration.
Unless
desciption,
you
can
see
that
we
can
confirm
configures
the
SF
give
configured
as
iff,
we'll
identify
our
name
and
the
SLP
that
the
SF
f
belongs
and
the
in
SFP
configuration.
We
also
have
as
a
key
ID
as
a
si
service
index,
a
magic
next
hope
and
last
s
FF
and
the
SSP
idea
and
SFO
is
Lucky's.
H
A
la
kiss
of
the
SF
he
and
in
the
next
next
hope
there
are
types
to
indicate
is
NASA
hope,
is
a
s
FF
or
are
specific
SF,
and
there
is
a
transport
type.
As
we
currently
English
Yamada,
we
only
support
excellent
GP
interface
and
is
netting
fees
and
Elise
lies
like
well.
The
diagram
shows
the
as
a
state
information,
and
currently
only
configuration
information
can
be,
can
be
read
English
in
this
state
information,
and
we
also
saw
that
your
comments
are
or
your
contribution
about
the
app
at
least
part
a.
H
Next
time,
next
steps,
we
got
some
very
important
comments.
We
really
appreciate
that
and
according
to
this
very
useful
comments,
we
plan
to
update
the
chapter
in
the
following
four
aspects:
wines,
to
actual
supports
the
configuration
for
the
SF
list
to
support
the
other
for
multiple
SF
f
instance:
anomaly:
the
to
actually
provide
the
interface
list.
H
I
I
have
a
comment:
I
seem
to
remember
that
Ronaldo
Pino
wrote
a
SFC
yang
draft.
That's
expired
quite
some
time
ago,
but
it
was
based
off
of
the
VPP
implementation.
So
my
question
is
whether
you
actually
cross-referenced
on
that
and
have
you
know,
I,
don't
think
he's
working
in
this
area
anymore,
but
what's
important
is
that
that
yang
model
came
from
the
actual
implementation,
so
it
might
be
worth
at
least
looking
at
to
make
sure
that
it
kind
of
aligns
with
that.
You
haven't
missed
anything
in
the
yang
model
that
you've
defined
here.
I
H
I
G
Can
eat
the
mic?
Maybe
so
the
other
thing
that
you
might
want
to
go
and
consider
is
looking
at
all
the
SST
models
that
exist
in
open
daylight.
There
is
quite
a
few
and
that's
a
fairly
extensive
project
that
well,
it's
maybe
a
little
past
the
pipe,
but
it's
still
progressing
and
OPN.
If
he,
for
instance,
continues
to
leverage
that
so
it
might
be
worthwhile
to
look
at
the
young
models
that
are
defined
here
as
well.