►
From YouTube: Intro + Deep Dive: Cloud Native Network Function (CNF) Testbed - Taylor Carpenter & Denver Williams
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro + Deep Dive: Cloud Native Network Function (CNF) Testbed - Taylor Carpenter & Denver Williams, Vulk Coop
The Cloud Native Network Function (CNF) Testbed is a CNCF initiative to provide a neutral space for exploring and evaluating open source networking technologies and their interoperability. The initiative fosters cross-community collaboration and includes contributors from FD.io CSIT, Network Service Mesh and OpenStack among others. This intro + deep dive session will walk through how users can provision the hardware and cluster infrastructure on Packet bare-metal machines as well as the deployment of various telecom-focused use cases onto those clusters. There will be time for Q/A as well as looking at the implementation for some components of the CNF Testbed. Attendees should leave this session with an understanding of how to deploy the CNF Testbed with their own Packet accounts and to contribute to the CNF Testbed initiative.
https://sched.co/UakA
A
Good,
all
right,
okay,
sorry
about
that
yeah!
We
may
have
to
get
a
new
laptop
when
I
get
back.
It
will
not
to
see
the
external
display,
so
we
may
flip
between
these.
So
there
would
be
a
little
delay.
That's
what
we're
figuring
out
here
for
a
portion
get
started,
though
I'm
Taylor
carpenter.
This
is
Denver
Williams
and
we're
here
to
talk
to
you
about
the
cloud
native
network
function,
testbed.
A
Introduce
the
team
some
of
the
people
have
been
contributing,
give
a
little
intro
and
background
on
the
testbed.
Why
in
severe
go
through
the
different
parts
and
look
at
how
you
could
recreate
what
we
have,
including
workstation
setup
and
the
different
portions,
including
hardware,
provisioning
and
the
workload
infra
kubernetes
open
sack
as
well
as
examples
and
have
a
little
Q&A?
A
So,
ideally,
with
this
and
following
documentation,
that's
published
on
the
scene
of
testbed,
you
can
set
up
a
workstation
that
can
run
the
code
that
we
have
run
the
examples,
provision,
hardware,
packet
and
provision
clusters,
as
well
as
adding
extensions
for
doing
different
things
on
the
workload
is
my
Auto
audio
vacuum,
echoing
maybe
at
is
mic?
Okay,
just
me.
So
here's
the
link
to
these
slides
I
think
there
may
be
a
few
updates,
we'll
upload
upload
that
this
is
on
sketch.
A
So
a
little
bit
about
us
and
at
least
myself
and
Denver.
Well,
cooperative
we've
been
around
six
years
and
Austin
based
software
cooperative.
We
do
have
folks
that
are
all
around
the
world,
including
Denver,
and
we're
helping
with
scene
of
testbed
and
other
things.
We
do
run
a
monthly
software
meetup,
as
well
as
a
open-source
access
where
we
do
x-ray
and
hang
out
in
Austin.
So
if
you're
there
reach
out
to
us,
so
this
particular
presentation
the
examples
that
were
showing
here.
So
here's
some
folks
that
helped
put
this
together.
A
Michael
Peterson
wasn't
able
to
make
it
at
this
time
to
the
conference.
Nicolai
from
network
service
meshes
helped
out
a
lot
and
Lucina
is
out
here
also
with
about
cooperative.
So
we
have
quite
a
few
contributors
from
different
projects,
including
FDIC
set
for
testing
VPP
software
network
service,
mesh
folks,
people
that
work
on
open,
sac
and
many
other
projects.
A
So
where
did
this
come
from?
This
is
a
initiative
from
CN
CF,
Open,
Source
Initiative
and
the
telecom
user
group,
which
is
formed
since
the
CNF
test,
but
started
we're
collaborating
with
what's
coming
out
of
that
specifications,
white
papers
and
it's
supposed
to
provide
the
capability
to
explore
the
different
technologies
that
are
coming
out
and
look
at
how
they
could
work.
You
may
use
them
for
your
networking
needs
or
telco
specific
needs
and
potentially
and
it's
more
on
the
early
adopters
side
of
things.
A
But
we
are
working
with
other
groups
to
try
to
take
ideas
and
pass
them
on
that,
maybe
for
brownfield
deployments,
also
taking
tooling
and
best
practices
that
are
already
out
there.
This
is
redeploy
able
on
packet
as
the
primary
target
and
it
supports
both
their
on-demand
servers,
as
well
as
reserved
we've
also
used
custom
instances.
A
A
We
right
now
for
the
workload
infrastructure,
support
kubernetes,
which
is
vanilla,
kubernetes
and
a
vanilla,
open
sack
and
I'm
not
going
to
really
get
into
upset
right.
Now.
It's
the
chef
based
installer,
but
that's
there
as
well
and
we're
on
slack
and
CNF
testbed
and
there's
it's
not
listed,
but
there's
a
scene
at
testbed,
dev
channel
we're
also
attend
the
telco
music
group
and
a
lot
of
other
projects.
A
So
this
all
started
back
at
ons
2018
in
Los
Angeles,
looking
at
an
own
app
demo,
which
is
also
available
on
github
and
has
a
lot
of
different
use
cases.
And
we
were
looking
at
how
you
could
take
some
of
those
and
maybe
either
have
it
running
on
kubernetes
or
take
maybe
parts
of
it
and
started
working
through
there.
And
as
part
of
that,
we
saw
that
the
layers
and
stuff
didn't
really
fit
with
breaking
it
down
and
making
it
maybe
compatible
with
different
infrastructures.
A
Since
then,
we've
been
moving
towards
making
it
more
usable
beyond
the
initial
stages
and
we've
been
able
to
reproduce
some
of
this
with
different
people,
including
does
show
Telkom
weave.
Adding
new
use
cases
started
looking
at
a
network
service
mesh
support,
adding
different
helm
based
deployments
of
the
use
cases
as
we're
trying
to
figure
out.
How
do
we
make
this
easier
for
folks
to
contribute
and
maintain
and.
A
Looking
back
at
the
goals,
so
there's
all
these
different
technologies
that
are
coming
out
and
we
want
to
make
it
possible
for
people
to
reuse
those
different
ones.
There's
there's
projects
and
initiatives
that
are
trying
to
build
entire
platforms
that
you
could
use
or
a
set
of
examples
that
are
focused
on
one
project.
A
A
So
here's
kind
of
where
we
are
from
that
first
version
into
the
new
version
we've
pulled
more
stuff
in
band
instead
of
doing
more
of
the
Play
Books
and
scripts
and
other
things
that
we
started
with
and
a
lot
of
the
initial
implementations
were
stuff
like
a
host
based
V
switch
similar
to
what
you
would
have
with
OBS,
or
a
VPP
networking
on
OpenStack
and
doing
something
similar
in
kubernetes.
And
how
would
we
do
deployments
and
testing
so
moving
to
support
helm,
cube
kettle?
A
One
of
the
recent
things
that
we're
shifting
away
from
is
on
the
on
the
provisioning
of
your
infrastructure.
We
were
using
something
from
a
CNC
FCI
project,
the
cross
club,
provisioner
and
splitting
that
up
to
have
two
stages
and
for
the
kubernetes
side
it's
based
around
cube
spray.
It's
called
Kate's
and
fret,
but
it's
based
around
cube
spray.
So
that's
upstream,
like
cig
testing
from
kubernetes
and
more
kubernetes
native
implementations
for
parts
that
may
have
been
out
of
band
either
custom
scripts
and
ansible
play
books
or
whatever
else,
and
then
continuing
to
add
examples.
A
So
I
was
mentioning
that
we're
service
mesh,
but
also
Dan,
am
Malta's
SRV
until
device
plug-in
and
other
things
like
that.
We
have
some
other
examples
that
are
kind
of
on
the
roadmap,
like
a
hybrid
use
case
and
and
other
things.
One
of
the
other
key
points
was
the
examples
of
workload
configs
so
saying
that
you
want
a
kubernetes
cluster
that
has
network
service,
mesh
support
and
maybe
Malta's
and
some
other
add-ons
that
extend
the
functionality.
A
So
here's
some
just
a
little
bit
of
a
read
map
to
see
kind
of
where
we're
going
from
here,
keeping
adding
some
new
things,
we're
looking
at
a
5g
demo,
potentially
for
Mobile
World
Congress
next
year
that
we're
targeting
and
working
with
various
projects.
To
make
that
happen.
If
we
can
get
some
support,
we'll
like
to
add
a
hybrid
use
case
where
we
have
kubernetes
and
open
sacks
so
you're,
looking
at
maybe
running
a
existing
workload
on
OpenStack
and
you
have
a
kubernetes
cluster
and
you're
starting
to
run.
A
Maybe
there's
some
network
functions
either
built
inside
or
a
vendor,
and
you
want
to
connect
those
and
have
service
change
running
across
we'd
like
to
get
some
help
on
the
open
sex
side
for
maintenance.
We've
had
quite
a
bit
of
work
on
that
over
the
past
year
and
most
of
that
shifted
to
kubernetes,
but
and
then
we
have
a
lot
of
other
cases.
I
will
probably
be
adding
the
some
Numa
zone,
isolation
and
other
stuff
with
regard
to
managers
that
can
handle
handle
stuff
at
the
the
CPU
level,
for
benchmarking
and
other
reasons.
A
So,
let's
see
an
overview
of
the
components
and
stages.
So
I
talked
a
little
bit
about
these
already,
but
we've
moving
towards
fully
splitting
the
hardware
provisioning
from
the
workload
infrastructure.
That's
kubernetes
OpenStack,
as
well
as
all
the
pieces
that
are
there
and
then
we
have
the
examples
and
use
cases.
Any
network
functions
most
of
these
right
now
or
external.
We
pull
them
in.
A
So
if
someone
publishes
a
container
network
service
mesh
has
several
we
have
a
few,
and
we
want
to
be
able
to
support
more
of
this
and
then
testing
tools
in
a
fee
bench
which
is
a
be
an
Opie
NFV
project
and
other
tooling,
some
of
its
internal,
some
of
its
external
here's
a
little
view
of
some
of
the
components.
This
isn't
the
environment
every
time.
This
is
just
showing
a
snapshot
of
what
could
be
running
on
different
notes.
A
You
have
VPP
running.
This
is
showing,
if
you're
running,
that
for
doing
l2
connections,
there's
other
ways
that
we
could
have
access
to
the
devices
I
mentioned
that
Intel
SRV
device
plug-in
there's
other
ways
that
we're
going
to
show,
but
this
shows
a
little
bit
of
that
the
traffic
generator
with
nfe
bench.
A
So
workstations
set
up
we're
not
going
to
walk
through
all
of
this
right
now,
but
give
you
a
little
bit
of
an
idea.
So
the
main
thing
is
the
CNF
testbed
repo
is,
if,
if
you
clone
that
most
of
the
tooling
and
documentation
is
right
there
and
you
can
run
the
software
that
we
have
based
on.
What's
in
the
repository,
so
the
parts
that
are
outside
of
that
would
be
if
you're
going
to
use
packet
for
doing
your
testing
and
you'd
create
a
packet
account.
A
A
You'd
want
to
create
SSH,
key
and
upload
that
to
your
account,
specifically
if
you're
going
to
use
a
workstation,
but
also,
if
you're,
using
the
workload,
infrastructure,
provisioning
and
cube
spray
uses
it's
based
on
ansible
playbooks
and
some
other
things
and
uses
SSH
to
connect.
So
you'll
need
that
in
place.
But
if
you
have
an
SSH
key,
then
you
get
all
of
this
so
most
of
the
workstation
tooling,
to
get
started
as
pretty
straightforward.
If
you're
already
doing
kubernetes
development,
you
probably
have
this
docker
cue
pedal
and
that
sort
of
things
you
clone
the
repo.
A
A
What
we
had
and
where
we're
going
so
the
v1
was
all
in
one
if
you
do
a
provisioning
of
a
cluster
you're,
doing
the
hardware
and
you're
doing
the
kubernetes
or
OpenStack
or
whatever
all
in
one
go
and
we're
splitting
that
up,
and
for
that,
let's
see
a
couple
of
portions
on
this
before
we
dive
into
the
split
the
ansible
piece.
There
are
some
parts
that
we
are
not
really
possible
until
potentially
cluster
api
has
support
for
talking
to
packet
and
configuring
the
network
and
some
other
things
like
that.
A
So
for
VLAN
configuration
on
packet,
they
have
an
api
and
we
can
talk
to
that
assigned
VLANs
to
ports
on
the
network
card
of
a
worker.
Node,
there's
other
things
that
we
can
do,
and
so
we
do
have
some
ansible
code.
That's
still
useful
at
this
time
for
the
host
the
network,
other
items,
and
for
that,
if
you
don't
have
ansible,
don't
want
to
set
it
up.
We
do
have
a
a
container
image,
CNF
deploy
tools
and
we
try
to
publish
that
whenever
we
make
changes
to
it.
A
But
you
can
either
build
it
yourself
or
download
the
image
and
use
that
to
run
the
different
play
books
and
we
have
other
tooling
and
stuff
for
doing
similar
things
as
far
as
the
deployment
I
think
I'm
gonna
hand
it
over
to
Denver
and
he's
gonna
dive
in
a
little
bit
to
the
difference,
hardware
and
workload
in
four
cluster
provisioning.
Okay,.
B
A
C
Right,
hey
everyone,
I'm,
Denver
and
I've
been
working
on
the
CNF
to
spared
initiative,
since
it
first
started
and
most
of
my
background
and
work
on
the
project
has
been
around.
The
Cuban
Eddie
saw
the
OpenStack
site
and
the
automation
tooling
around
those
projects,
so
I'm
gonna
dive
into
how
the
hardware
and
cluster
provisioning
works
on
the
CNF
testbed.
C
So,
as
Taylor
mentioned
before,
we
were
originally
using
approach
called
cross
cloud
and
what
that
was
doing
is
it
was
provisioning,
the
hardware
and
Kuban.
It
is
at
the
same
time
and
one
swoop
and
we've
been
wanting
to
split
that
out.
So
we
have
two
composable
pieces
and
that
allows
us
to
do
things
like
configure
underlying
network
and
cleaner
stages.
C
So
an
overview
of
this
stage
is
we
have
this
repository
called
in
for
provisioning,
and
this
is
actually
repository.
That's
used
upstream
at
CNCs
CI
project
as
well,
and
what
this
consists
of
is
some
generic
terraform
code,
that's
composable
and
reusable,
and
this
is
what's
used
to
request
the
packet
service
and
it
has
the
ability
to
use
both
reserved
servers
and
on-demand
service
there
and
then
also
at
this
stage,
we'll
use
ansible
to
provision
any
hardware
level
configurations.
C
So
once
you
have
these,
you
can
see
these
environment
variables
and
then
once
those
are
set,
you're
all
set
to
run
the
provisioning.
So
from
the
tools
directory,
you
can
run
the
hardware
provisioning
script
and
that
will
go
through
and
provision
a
set
of
packets
service
based
on
the
configuration
you
had
and
it
will
also
Outlook
output,
a
file
under
the
tools
directory
called
nodes
env.
C
And
what
this
is
is
it's
a
inventory
to
inventory
file
a
collection
of
the
nodes
that
are
provisioned
and
then
this
can
be
being
given
to
a
tool
like
cube
spray
or
some
other
provisioning
device.
That
will
then
take
those
servers
and
provision
our
workload
infrastructure,
so
stage
2.
This
is
where
the
second
stage
comes
in
Emily
provision,
a
cluster,
whether
it
be
open,
stack
or
queue
manatees.
C
So
the
other
things
that
happen
at
this
stage,
complimentary
services,
there's
additional,
tooling
and
infrastructure
just
off
to
the
side
of
cuba,
Nittis
and
OpenStack
like
in
sm,
danam,
vultus
or
installing
a
BPPV
switch
directly,
and
then
we
can
also
do
configuration
at
this
last
may
be
VLANs
this
or
SRV
devices
and
the
I
own.
Here
that
does
the
kubernetes
provisioning
is
called
Cades
infra.
C
And
what
this
is
is
it's
a
wraparound
cube
spray,
because,
whilst
cube
spray
is
fairly
straightforward
to
use
when
you're
wanting
to
use
particular
versions,
it
can
get
a
little
annoying
and
there's
lots
of
configuration
options.
So
we
decided
to
create
a
a
simple
declarative
wrapper
around
it,
which
provides
a
CLI
interface
and
integrates
with
the
testbed
as
well,
and
then
also
as
mentioned
before,
we
can
use
an
x'
of
all
four
out
of
bound
host
configuration
for
networking
or
additional
configuration
services
at
the
cuban
ities
level.
C
So
these
are
things
like
palm
charts
for
network
service
Maradona
and
if
you
want
to
use
this
tool
to
provision
a
Cuban,
it
is
cluster,
then,
from
the
tools
directory
you'll
be
able
to
run
Cades
infra
generate
config
and
pass
it.
Some
configuration
flags.
So
the
first
one
we've
got
here
is
the
release
type.
C
So
this
can
be
sets
ahead,
which
will
then
go
fetch
whatever
the
current
head
version
of
cuban
editors
and
deploy
that
version
or
it
can
be
set
to
stable,
which
will
take
whatever
the
current
stable
version
of
cuba,
notices
and
then
there's
this
next
sitting
Harrah's
host
file-
and
this
is
the
file
that
was
outputted
to
tools
before
and
the
hardware
provisioning
stage.
And
then
the
oh
flag
is
to
output.
This
configuration
to
a
directory
and
once
you've
got
this
configuration
and
it
specifies
what
nodes
should
be
provisioned.
C
A
Hardware,
provisioning
or
the
case
I
guess
one
one
thing
I
could
point
out
is
this
is
one
way
to
do
like
the
generation
we
support
passing
IP.
So
if
you
didn't
use
the
hardware
provisioner,
but
you
already
had
a
machine
setup,
you
can
specify
the
worker
nodes.
We
have
flags
for
that,
so
you
can
specify
the
worker
nodes
and
the
master
nodes
and
it'll
generate
the
needed
configuration
that
keeps
your
own.
A
A
A
We
in
the
past,
we
had
one
script
for
doing
to
deploy
before
you
would
run
any
use
cases,
and
that
would
be
fine
to
essentially
run
one
and
it
feeds
the
other.
This
specifically
is
so
that
we
can
run
it
and
then
feed
that
versus.
If
someone
said
I
already
have
my
machines
and
I
just
want
to
get
kubernetes
on
this
we're
using
cube
spray.
One
reason
Riis
keep
spray
is
because
it
supports
doing
a
reset.
A
So
if
you
had
a
set
of
machines
that
you
want
to
bring
back
to
the
the
base
state
with,
just
though
s,
then
the
cube
spray
supports
that
and
that's
something
we're
going
to
be
having
in
here
to
run
again
and
again.
But
if
you
wanted
to
do
more
like
a
workflow,
where
it's
doing
all
of
it
once
that
would
be
something
pretty
easy
to
chain
based
on
what
we've
done.
A
D
Yeah
they
will
have
like
different
time
like
hardware
requirement
like,
as
you
know,
like
network
functions,
can
be
very
like
the
requirement
can
be
very
hardware
specific.
So
how
are
you
handling
that
like
it,
because,
like
the
way,
I
understand
it,
it's
a
common
infrastructure,
you
are
building
and
like,
and
you
will
be
bringing
in
any
kind
of
network
function.
Id.
That's
that's
the
general
purpose
for
this
right
sure.
A
So
I
work
there
isn't
anything
right
now,
that's
gonna
be
generic
enough
to
say
it's
generic
and
it
supports
everything
specifically
so
we're
adding
support
as
we
go
and
right
now
the
example
would
be
on
packet.
They
have
machines
that
have
Mellanox
Network
hearts
and
then
they
have
machines
that
have
Intel
and
then
the
the
setup
and
configuration
of
those
specifically
if
you're
going
to
have
accelerated
access
is
different.
So
we've
built
support
originally
with
all
the
ansible
playbooks
and
stuff,
like
that.
We've
moved
as
much
of
that
as
possible
out.
A
So
it's
a
slimmer,
later
layer
and
trying
to
use
software
that
can
support
both
DP
DK
is
you
know
they
have
a
focus
on
trying
to
be
able
to
do
acceleration
for
different
devices.
And
then,
if
you
look
at
stuff
like
a
project
like
network
service
mesh,
the
idea
would
be
from
there
and
it's
an
example
of
an
idea
that
you
would
have
a
node.
That's
saying:
here's
what
I
have
to
offer
and
then
you
a
service
saying
I
would
like
this
type
of
accelerated
access,
and
ideally
those
come
together
right
now.
A
A
So
a
generic
solution,
I,
would
say,
is
not
fully
there
yet,
but
we're
trying
out
the
different
pieces
to
kind
of
move
towards
that
and
the
other
part
would
be
separating
say
as
much
as
possible
of
a
use
case,
or
at
least
the
components
that
you
can
from
the
parts
that
know
about
accelerated
access.
So,
ideally,
you
can
build
most
of
say
a
service
chain
and
you
make
it
up
to
one
one
portion
that
knows
more
about
the
specific
devices.
A
Okay,
so
I
guess
working
a
little
bit
backwards.
The
first
part
would
be
everything
is
on
packet
and
the
machine
information
is
publicly
available
and
we're
trying
to
make
sure
that,
if
we're
whatever
type
of
test
that
we're
running
the
results
from
those
that
we
specify
the
instance
type
and
the
the
hardware
and
stuff
that
was
used.
A
So
if
you
know
that
you
should
be
able
to
test
anywhere
and
then
more
specifically
for
getting
access
so
a
little
bit
further
on
in
the
slides,
there's
a
packet
comm,
slash
CNF,
you
could
get
access
to
credit
and
go
create
your
own
account
on
packet,
there's
also
the
CN
CF
community
lab
infrastructure
lab
and
that's
also
run
on
packets.
So
if
you
get
there
sans
CF,
particularly
with
open
source
projects,
then
you
can
get
acts
that
way
and
the
CNF
test
bed
right
now.
A
With
the
caveat
that
there's
a
new
instance
called
the
n2,
as
in
like
network
to
extra
large,
that
one
has
Intel
quad
port
NICs,
we
helped
get
packet
to
add
this.
We
had
initial
access,
probably
six
to
eight
months
before
it
was
publicly
available
that
one
is
now
publicly
available,
so
we
may
have
some
type
of
early
access,
but
everything
that
we're
doing
we're
trying
to
say.
Okay.
This
looks
good,
please
get
a
public
version
of
this
and
you
should
be
able
to
find
it
and
use
it.
A
A
It's
R,
so
the
tooling
has
primarily
been
a
it's
we've
iterated
on
what
we
have
so
I
mentioned
the
the
CNF
testbed
tool
image,
and
that
has
a
lot
of
different
pieces
in
it,
including
the
ansible
portions
and
other
upstream
support
from
different
tools.
So
it
it
kind
of
helps.
You
do
many
different
things.
One
of
the
big
changes
that
still
in
process
has
been
in
a
folder
that
you
can
find
on
the
repo
called
the
comparison
folder,
and
this
is
where
we
had
the
aunt
all
of
the
ansible
playbook
still
live
there.
A
They
haven't
been
moved
over,
but
the
other
thing
would
be
the
actual
test
cases
and
examples
where
a
lot
of
these
were
custom
scripts.
They
still
some
of
them
still
work
perfectly
fine,
but
we're
not
maintaining
those
who
mainly
been
rewriting
these
in
the
new
structure
and
that's
under
this
examples
folder
if
you're
looking
at
the
top
level
and.
A
That
area
is
the
main
portion
where
we're
focused
on
and
that's
where
it
has.
If
we,
if
you
look
at
that
in
the
repository
there's
three
main
areas,
there's
the
network
functions
which
is
actually
empty
because
so
far,
everything
is
either
upstream
with
other
projects
and
we
pull
in
the
publish
images
or
we
have
a
image.
A
We
want
more
in
band
support.
We
talked
about
that
earlier,
along
with
that
string
tolling
we're
trend
also
use
upstream
helm
charts
if
a
project
has
it
so
as
much
as
possible
network
service
mesh
as
now
starting
to
publish
the
helm
charts
as
their
releases
are
moving
forward
and
any
type
of
manifest
for
installers
we'd
like
to
use
the
upstream,
and
if
we
want
to
modify
something
similar.
A
What
we've
done
with
cube
spray
most
of
these
things,
you
can
override
pieces
where
we
wrap
an
additional
component
and
extend
what
what's
there
and
that
goes
along
with
minimal
wrapper,
so
that
we
have
some
type
of
consistency
between
examples
and
use
cases
where
we
can,
while
not
totally
rewriting
or
changing
what
upstream
projects
and
initiatives
already
doing
so.
This
first
example,
we
have
three
here
that
we're
showing
this
one
is
based
on
a
benchmarking
test
case
that
we
have
we've
been
working
on
for
quite
a
while
FDA
FCS.
A
It's
run
this
and
we've
had
folks
from
that
team
contribute
a
lot
on
the
playbooks
and
the
original
stuff
doing
a
lot
of
tuning
of
the
the
network
functions,
the
v
switch
other
pieces.
So
what
we
wanted
to
do
is
take
that
and
make
it
usable
with
the
new
structure.
So
this
particular
one
it
has
a
V
switch,
that's
based
on
VPP,
and
you
can
run
this
either
in
a
privileged
container
or
you
can
run
it
on
the
host
directly
and
you
have
some
number
of
art.
A
The
network
function
that
we're
looking
here
is
very
simple:
it's
just
a
IP,
fort
or
ipv4
or
ipv6
packets
and
those
go
through
the
V
switch
into
the
first
Network
function
and
pass
through
and
loop
back
to
the
next
network
function,
making
a
chain
and
that's
ideal
with
the
snake,
and
you
could
have
different
depths
at
this
particular
example.
If
you
go
there,
this
is
using
three
chains
with
two
network
function
in
each
chain,
and
this
is
based
on.
A
So
this
one
is
hell
based
you
for
the
test.
You
would
have
some
packet
generator
machine.
We
have
ansible
code
and
other
pieces
for
setting
up
a
machine
that
can
run
in
a
fee
bench
and
generate
the
traffic.
That's
going
to
point
at
the
worker
node
that
you're
going
to
be
testing,
there's
specific
things.
This
ties
back
into
the
hardware
question
where
you
need
to
know
the
configuration
like
PCI
devices
or
you
may
need
to
know
PCI
devices
you
may
need
to
know.
A
Mac
addresses
other
things
potentially
for
some
of
these
tests
on
this
one
we're
using
in
a
fee
bench
that
is
using
MAC
addresses
for
how
it's
sending
traffic-
and
this
just
happens
to
be
the
configuration
that
we
had
before
and
we're
pulling
it
over
there's
different
ways
of
using
that,
but
that's
set
up
here.
We
have
extracted
it
from
being
static
within
the
network,
functions
and
other
parts.
You
can
pass
them
as
values.
A
This
will
probably
be
pulled
further
out,
ideally
where
maybe
you're
able
to
talk
to
the
the
node
and
find
some
of
this
out,
pass
it
in
or
test
information
and
then
otherwise,
when
you're
wanting
to
run
this,
you
have
your
packet
generator
machine
and
we're
just
have
a
little
wrapper
script
around
this.
But
it's
essentially,
if
you
run
an
EFI
bench,
you
have
a
configuration
file
that
specifies
the
size
of
packets
and
the
length
of
time
and
a
bunch
of
other
things
that
you're
going
to
pass
in
and
when
you
run
run
the
script.
A
C
A
C
Right
so
we're
starting
from
the
CNF
disappeared
repo
and
from
here
assuming
that
you've
already
run
the
workload.
Provisioning,
provisioning
stage
got
a
humanities
cluster
and
it
would
have
helped
outputted
a
Cuban,
a
DS
configuration
file.
So
if
you
sit
that
we
should
now
have
a
Cuban,
a
t's
cluster
up
nodes
available
and.
C
No
pods
so
I'm
going
to
start
with
a
snake
case
that
Taylor
just
explained
so
first
step
is:
we
actually
need
to
make
sure
we've
got
a
V
switch
up
and
running
on
the
host,
so
we
start
that
and
then
the
next
step
is
to
install
it.
So
under
the
current
directory
of
the
CNF
test
page,
you
have
examples,
use
cases,
then
you
have
the
3
C
2
in
CSC.
C
And
what
these
are
the
MAC
addresses
for
the
package
generator
and
the
package
generator
is
a
server
that
we
have
the
code
for
sitting
up
and
it's
the
documentation
there.
But
it's
already
set
up
for
this
use
case
and
you
want
to
enter
the
MAC
addresses
of
that
server
and
want
that
once
that's
up
and
running,
you
can
do
a
helm,
install
of
the
use
case
and.
C
We
want
to
wait
for
now,
as
for
the
use
case
to
be
up
and
running,
and
it
looks
like
it
is
so.
The
last
step
is
to
test
this.
We
want
to
switch
to
the
packet
generator
server
and
we
have
a
run
test
or
shell,
and
what
this
is
is
a
wrapper
around
in
a
fee
bench
and
it
will
go
and
send
data
to
the
CNS
we
just
deployed
and
doing
it
in
a
snake
a
so
it's
going
into
each
CNF
and
then
down
to
the
host
V
switch
and
back
out.
A
Get
a
another
minute
or
something
there:
we're
planning
on
working
with
FDIC
sit
and
a
couple
other
folks
on
picking
some
of
the
use
cases
like
this
one
and
then
running
tests
on
those
sets
on
a
regular
basis
and
publishing
the
results,
along
with
the
machine,
information
and
other
stuff.
That's
happens
constantly
on
that
and
the
Linux
Foundation
labs,
specifically
around
VPP
and
we'd,
like
to
do
that
here
and
similar
we'll
probably
end
up
with
some
test
results
for
functional
use
cases.
All.
A
C
A
A
A
Whenever
reason,
oh
so
I'm
sure
in
the
snake
case
of
the
V
switch
actually
has
privileged
access,
which
we
can
say
what
cores
it
can
see
or
not,
but
the
we
also
have
a
what
we're
not
showing
as
a
pipeline
use
case
where
they
connect
the
MAF
and
it
would
be
similar
so
we're
passing
that
information
so
that
the
image
has
it
and
here's
the
course
available
to
it.
And
what
we
would
like
to
do
is
once
we've
added
the
C
people
or
as
a
in
for
a
level
who
can
you
get
it
back
down?
A
All
right,
okay,
so
example,
two
and
which
all
of
these
have,
by
the
way
I
get
a
blank.
So
if
you
get
on
the
slides
or
you
can
go
right
to
get
up
and
they're
all
under
the
ones
that
we're
talking
about
or
under
the
new
structure
under
the
examples
example,
two
is
a
very
minimal
example:
I
wouldn't
call
it
a
use
case.
This
is
more
of
how
to
use
something.
A
So
it
has
two
pieces
and
and
that's
why
it's
split
here,
there's
actually
two
links,
so
one
of
them
is
the
workload
and
for
set
up,
and
this
is
where
we're
adding
the
SRV
device
plug
in
and
to
kubernetes.
And
then,
after
that,
now
you
have
access
to
be
able
to
add
support
into
a
pot.
So
this
example
is
saying
once
you
have
that
in
the
workload
infra
then
do
you
have
X
Canyon?
Can
you
see
it
in
a
pod?
So
it's
a
very
simple
way
of
showing
that
that
works.
A
But
again
this
is
to
try
to
help
people
that
are
exploring
these
technologies.
What
we
don't
have
on
the
slides
here,
but
we
do
have
if
you
go
in
the
examples
directory,
is
an
example
showing
Malta's
plus
this
device
plug
in
so
the
simple
device
plug
in
example,
and
then
we
have
another
example
multiply
so
device
plug
in
that
actually
shows
how
that
would
work
for
querying
and
accessing,
and
that's
where
we'd
like
to
put
extend
on
say,
maybe
the
last
example
for
accessing
the
device
using
multi
sand,
the
device
plugin.
A
What's
next
this
a
little
bit
of
what
I
was
saying,
so
we're
going
to
take
these
simple
one
and
we
have
the
multi
already
and
we're
picking
out
a
couple
of
different
use
cases,
probably
the
next
one
that
I'm
showing
maybe
where
we
want
to
do
this,
but
having
using
multi
as
an
example
of
getting
access
to
the
hardware
and
then
passing
it
to
a
particular
network
function.
So
with
that
here's,
the
third
example,
which
is
also
available
in
that
same
folder,
this
one,
don't
really
know
what
we
want
to
call
the
name.
A
A
We're
showing
different
access
from
the
clients
and
we're
also
showing
this
is
a
network
service
mesh
example.
So
we
have
you're
seeing
a
kernel
interface
as
well
as
min
my
F
interface.
For
this
particular
example.
It
uses
with
network
service
mesh.
This
allows
us
to
connect,
provide
all
the
connections
between
both
the
client
is
I
gonna
go,
it's
still
loading,
okay,
all
right
so,
and
so
the
network
service
mesh
is
allowing
us
just
describe
the
connections
between
these.
A
So
some
of
the
other
ones
were
creating
the
connections
by
specifying
the
the
pods
of
containers
that
we're
going
to
be
running
and
and
then
manually,
creating
those
connections,
bypassing
the
interfaces
or
it's
going
to
connect
to
the
V
switcher
various
things
with
network
service
mesh
you're,
actually
using
it
to
provide
the
connections
between
the
different
services.
So
in
this
one
we
have
a
packet
filter
that
we
can.
A
If
say,
this
could
build
on
to
the
hybrid
use
case
I
mentioned
earlier,
where
the
external
access
may
end
up
being
a
vehicle
in
connection
to
OpenStack,
or
maybe
you
have
multiple
clusters
or
it
could
be
different
things,
but
the
idea
is
you're
going
to
exit
the
kubernetes
cluster
and
you're,
not
using
the
regular
built
in
a
network
path.
The
kubernetes
gives
you
we're.
Gonna
provide
a
different
network
path,
another
way
of
looking
this
would
be.
A
Maybe
you
have
a
segmentation
of
traffic
where
one
org
can
go
down
one
service
chain,
but
they
shouldn't
they
should
be
split
and
segmented
out.
This
isn't
a
physical
separation.
This
isn't
software,
but
there's
different
things
that
we
can
build
off
through
this,
and
this
external
gateway
is
also
showing
us
physical
access
from
the
network
function.
So
how
do
we
do
that?
And
so
this
a
little
bit
about?
We
talked
about,
we
have
helm,
network
service
mesh
and
the
external
endpoint.
This
could
be
anything
right
now.
A
It's
a
simple
Ingenix
server
or
whatever
you
want,
but
it
could
also
be
another
cluster.
You
could
look
at
other
things,
and
this
has
the
workload
info
right
now.
It's
the
network
service
submission
kubernetes
in
the
future.
It
may
be
network
service
and
Malta's
the
device
plug-in.
We
could
add
other
things
on
there.
The
CPU
puller
there's
many
different
things
that
you
could
add.
This
is
what
we
have
right
now
and
again.
A
You
can
pass
in
different
things
to
how
for
setting
access
to
devices
and
other
pieces
and
in
this
one
we're
not
doing
a
benchmarking,
so
we're
not
using
in
a
fee
bench,
but
that
would
be
fine.
These
are
in
mix-and-match
the
different
pieces.
This
is
simply
doing
a
connectivity
like
a
ping
check
between
the
two
clients
and
that
external
machines
and
I
think
we
can
go
ahead
and
try
this
one
yep
all
right.
C
All
right
so
before
we
run
this
use
case,
we
do
have
to
do
a
little
bit
of
cleanup
to
get
rid
of
the
last
one
we
just
did
so
helmsley
purge
CSC
will
flush
out
the
snake
case.
We
just
ran
and
we
also
need
to
re
disable.
The
vvvv
switch,
because
for
this
use
case
we
aren't
using
it
we're
using
innocent.
C
A
A
One
of
the
things
that
we're
looking
at
doing
is
and
trying
to
make
the
workload
in
for
where
you
can
do
some
of
the
chaining
that
we
were
talking
about
for
like
hardware
and
other
pieces,
but
the
workload
in
forest.
Specifically,
if
we
use
helm
and
for
building
these
and
ideally
you
can
do
dependencies
and
you
could
specify
so
they're
like
a
blueprint
of
what
you
want,
your
infer
to
look
like
and
that
can
be
pretty
minimal
and
then
pull
in
all
the
pieces.
A
C
Right
so
we
have
NSM
up
and
running
now,
so
the
last
stage
for
this
is
to
deploy
the
use
case.
So
this
use
case
is
under
the
NSM
comb,
XD
PF
directory,
and
this
one
doesn't
require
any
additional
configuration.
It's
all
enclosed
within
the
Hound
configuration
itself,
so
we
can
run
Hellmann's
tool
and
once
again
we
have
this
wonderful
problem,
but
at
least
is
easy
to
fix.
C
F
Right
not
specific
to
example3,
but
just
wanted
to
know
what
kind
of
CNS
you
used
for
your
test
so
far.
Well,
there
could
be
a
variety
of
signals
that
is
available
already
all
right.
One
more
thing
is
when
I
come
from
a
telecom
world
and
I'm
trying
to
come
up
with
a
Phi
G
use
case
with
kubernetes,
and
you
know,
try
to
deploy
it
and
I
use
n
CN
Fe,
it's
again
a
fee
for
deployment,
so
I
want
to
know.
F
A
Right
well,
the
most
of
them
that
were
well
I'll,
say
that
two
main
ones
that
we're
using
are
a
VPP
based
somewhat
generic
container
that
we
can
use
it's
an
image
that
we
can
configure
for
multiple
things
like
the
IP
for
tur
and
you
can
make
it
do
different
things.
The
V
switch
is
based
on
that
because
you
can
set
up
VPP,
and
that
makes
things
pretty
easy.
A
We
do
have
some
images
in
there
that
were
from
the
own
app
demo
that
use
some
other
software,
but
they're
all
pretty
minimal
on
the
subset
of
software
and
the
other
one
that
we
are
using,
which
is
actually
being
used
in
this
as
well
as
innocent
calls.
It
Universal
CNF.
It's
an
example.
It's
and
it's
also
has
part
of
its
based
on
VPP,
but
it
has
some
other
stuff
in
there,
like
the
Innes,
VPP
agent
and
other
pieces
for
doing
various
things.
So
these
are
kind
of
generic
examples
that
can
be
configured
to
emulate.
A
Maybe
a
network
function
that
you'd
be
using
and
different
functionality
that
you
want
to
see
and
we're
interested
in
testing
others.
Most
of
the
problems
been
around
open-source.
Getting
something
if,
if
there
was
an
example,
we
don't
particularly
need
it
added,
but
if
there's
an
example
that
can
use
something,
that's
available
like
a
published
image.
A
Happy
to
do
that,
especially
if
the
capabilities
are
are
there,
but
those
are
the
main
ones
and
will
probably
be
adding
some
others
that
won't
use
VPP,
specifically
like
some
firewalling
and
some
stuff
that
we're
looking
that
that's
in
the
onap
demo.
That
I
was
mentioning
for
the
5g
we're
looking
at
several
different
things,
but
the
open
air
interface
project
was
used,
in
fact,
in
the
keynote
5
G
demo
and
the
proof-of-concept.
That
was
shown
on
the
keynote
of
the
day,
and
we
were
looking
at
using
that.
A
So
that's
that's
one
of
the
components
and
there's
several
other
potential
examples,
and
what
we
really
again
are
looking
at
is
what's
available,
that
we
can
make
readily
reusable
and
so
there's
definitely
gonna
be
devices
out
there
that
we're
not
going
to
have
software
access
to
or
if
we
get
it,
it's
going
to
be
working
with
someone.
So
if
someone
contributes
it
we're
happy
to
have
it
happy
to
have
the
specification.
The
main
focus
for
everyone
that's
been
involved,
though,
is:
does
everyone
have
open
access
to
it?
D
Adding
on
to
that
question,
so
are
you
also
talking?
Do
you
talk
the
word
open-source?
Are
you
also
talking
to
like
CNF
vendors
out
there,
because
this
is
a
this?
Is
a
legacy
enough
test
but
and
by
CN
CF
right
so
yeah,
are
you
involving
any
like
major
vendors
to
bring
their
legacy
nf2
on
this
test
bench.
A
So
not
on
the
network
functions
himself,
but
adding
I
guess
the
functionality
for
running
them,
maybe
where
we
are
talking
with
them
running,
getting
a
vendor
to
contribute
something
there.
That's
I
think
something
that
we'll
look
at
getting
to.
How
are
we
gonna?
Do
that
and
I
think
some
of
the
earlier
slides
was
talking
about
it
where
if
we
can
make
it
where
we
can
deploy
the
platform
and
anyone
can
deploy
it,
then,
ideally
a
vendor.
A
Whoever
could
create
their
own
account
and
deploy
that
set
it
up
and
then
deploy
the
software
that
they
want
without
say
handing
it
over
to
us
or
anything
else,
and
so
figuring
out.
The
interfaces
and
and
those
gaps
would
be
probably
the
first
thing
and
we
are
in
contact
with
the
vendors,
so
I
think
once
we
get
the
infrastructure
matching
what's
nades,
then
it'll
be
okay,
they're
testing
it
and
what's
missing
to
actually
test
those
type
of
things
and
operators
as
well.
So
we
have
folks
from
different
telecoms.
F
See
if
you
take
an
example
like
a
VP,
see
CNF
like
a
complex
enough,
which
involves
multiple
Williams
within
it,
which
is
I,
mean
I,
come
from
a
OpenStack
world
where
I
can
actually
deploy
a
complex,
be
enough
and
tie
them
into
a
network
service,
and
it
has
multiple
VMs,
maybe
high
available
ones.
For
me,
the
challenges
like
with
kubernetes
and
a
lot
of
encapsulation.
You
know
there
is
like
external
networks
that
needs
to
be
connected
for
these
CNF
per
se,
and
then
there
is
like
internally
all
these,
the
VMS
within
this
CNF.
F
Probably
you
need
to
set
the
traffic
for
that
as
well
right.
So
there's
like
multiple
levels
of
networking
involved
and
what
kind
of
plugins
you
suggest
from
kubernetes
world
for
us,
like
four
people
from
telecom
world
who,
once
you
use
communities
for
that
I
mean
have
you
had
experience
using
it?
I
saw
some
presentations
already
like
see
and
I,
and
you
know
Malta's
and
all
so,
what's
the
best
plug-in
that
we
should
probably
look
out
for
and
then
set
it
up
in
our
deployments
and
try
it
out.
You
know
that's.
A
A
Some
set
of
extensions
for
functionality
like
the
scene,
I
plugins
for
kubernetes
that
would
allow
you
to
I,
don't
want
to
exactly
say,
emulate,
but
recreate,
maybe
something
that's
similar
to
what
you
have
enough
at
SEC
I,
don't
think
it's
going
to
be
an
exact
match,
but
you
can
get
close
and
the
more
complex
may
be.
The
less
close.
A
This
service,
chaining
benchmark
example
that
we
were
looking
at.
That
was
literally
one
that
we
took
originally
from
using
VMs,
and
that
was
you
could
do
it
with
OVS
or
whatever,
but
we
specifically
were
using
VPP
networking
in
open
sac
and
on
a
worker,
node
and
kubernetes.
There's
no
real
reason
to
have
a
V
switch
in
place
for
that
particular
setup,
because
you
could,
instead
of
going
through
a
V
switch,
you
can
chain
them
directly
with
MIM
Ioffe
interfaces
and
it's
going
to
be
much
higher
speed.
A
A
You
should
look
at
the
principles
behind
what
cloud
native
mains
and
process,
and
that
would
be
similar
to
it
say,
network
service
mesh
is
doing
and
what
I'm
saying
with
like
the
mem
AF
connections,
we
go.
What
do
we
actually
want
to
do
when
we
create
these
chains,
and
there
may
be
a
totally
different
way
to
do
that
and
you
can
get
other
benefits
and
there's
just
many
other
things
where
the
ideas
around
how
you're
gonna
build
the
services
which
are
sets
of
network
functionality
like
larger
applications,
which
this
with?
A
Where
do
these
would
be
like
a
cloud
native
application
that
happens
to
be
focused
on
networking
and
that's
going
to
be
a
set
of
many
different
things.
So
when
it
talks
about
micro
services
and
other
things
you're,
it's
not
that
you
want
the
check
mark
all
the
buzzwords
that
you
want
to
use
these
specific
technologists
ideas.
A
If
we
can
simplify
these
services
and
let
the
application
do
what
it
does
best,
but
to
let
the
infrastructure
do
what
it
knows,
then
you're
going
to
be
better
off.
Building
these
things
and
most
of
that's
around
the
principles
and
stuff
it.
It
didn't
come
from
kubernetes,
kubernetes
and
implementation.
So.
E
I
guess
it,
except
in
the
examples
that
you've
given
like
if
you're
using,
for
example,
like
CPU,
pinning
and
chaining
all
these
things
or
you
is
when
you
run
those
benchmarks
as
the
bottlenecks
start
becoming
on
packet,
like
the
network
throughput
or
a
CPU
usage,
or
like
kind
of
like.
What's
the
performance
when
you're
kind
of
running
these
things.
A
Will
the
most
of
the
benchmark
eNOS
we've
kept
it
minimal
on
the
examples,
so
that,
if,
if
you're
benchmarking,
something
that's
also
doing
like
a
DHCP
request
that
other
things,
those
are
gonna,
be
your
bottlenecks
immediately.
So
these
examples
are
very
minimal,
IP
forwarding
inside
and
for
network
bandwidth.
You
can
limit
the
number
of
packets
and
other
things.
A
If
you're
saying
what
is
the
maximum
throughput
for
a
network
function,
then
that's
not
something
that
for
a
particular
implementation,
that's
not
something
you're
gonna
do
if
it's
needing
to
travel
outside
of
the
worker
node
in
a
network
where
you
have
a
limited
bandwidth.
So
these
particular
examples
we
can
max
out
the
bandwidth
on
packet.
So
we
limit
the
traffic
output,
which
you
can.
This
is
n
Fe
benches
set
for
doing
this.
How
are
you
gonna?
A
Do
it
so
that
you
can
get
results
that
are
meaningful,
yeah,
we're
just
not
testing
that,
but
Linux
Foundation
they
have
laps
with.
They
have
40
gig
50
get
a
counter.
Gig
necks,
I
I
know
that
they're
testing
other
things,
so
you
could
do
that
as
well.
We
just
don't
have
access
to
a
packet.
I
mean
initially
loved.
C
Yeah,
it's
good
going
so
here
where
we
left
it.
The
Harmon
store
it's
finished
and
there
should
be
some
new
resources
there,
packet
filtering
and
then
a
few
config
maps.
So
if
we
jump
over
to
here
and
look
upon,
we
can
see
that
there's
a
gateway
left
and
right
that
will
deploy
it
as
well
as
a
packet
filter,
a
sample
client,
so
we're
ready
to
run
the
tests
now.
So
we
switch
to
this
directory.
We
have
we
deployed
it
from.
A
So
one
thing
I
think
that
we're
gonna
want
to
add
beyond
this.
A
lot
of
this
is
like
developer,
oriented
and
console.
Of
course,
we're
gonna
have
the
results
that
I
mentioned
earlier
benchmark
results
as
well
as
like
test
functionality,
if
folks
are
have
particular
tools
for
like
visualizing
the
chains
and
stuff,
specifically
that
are
more
minimal.
A
So
I
know
that
you
have
tools
like
going
up
and
other
things
for
creating
and
building
the
visualization
of
how
these
look
or
I'm
talking
about
more
as
showing
these
these
type
of
examples
of
what's
running
and
the
type
of
traffic.
But
if
there's
things
that
you
like
and
would
like,
you
recommend
and
please
let
us
know
we're
looking
at
some
different
ones,
but
be
open
on
that
or
any
other
pieces.
A
G
G
F
When
they
gave
a
keynote
around
the
Phi
Z
demo
yesterday
morning,
there
was
a
challenge
that
was
mentioned
around
the
CN
of
descriptors,
specifying
various
properties
for
each
of
these.
So
you
know
ports
or
anything
that
is
related
to
the
CNF
right.
So
my
question
is
around
the
bit
rate
requirements.
If
I
have
to
pass
from
a
user
perspective,
I
want
to
set
the
bit
rate
for
the
interfaces
that
are
configured
with
this
synapse.
F
A
That's
not
something
supported,
and
in
any
of
these
examples,
but
I
don't
see
a
problem
with
that.
It
sounds
like
in
my
mind.
You
would
have
something
that
can
analyze
the
traffic
of
course,
and
then
the
network
function
should
provide
that
that
functionality,
the
ones
that
were
using
I,
could
definitely
see
an
example
created
with
that.
So
VPP
has
the
capability
of
restricting
and
there
would
be
different
ways
of
doing
this.