►
From YouTube: Intro and Deep Dive to the CNF Working Group - Ian Wells, Jeffrey Saelens, Taylor Carpenter
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Intro and Deep Dive to the CNF Working Group - Ian Wells, Cisco; Jeffrey Saelens, Charter Communications; Taylor Carpenter, Vulk Coop
Speakers: Ian Wells, Jeffrey Saelens, Taylor Carpenter
The Cloud Native Network Function (CNF) Working Group’s task is to recommend best practices for networking applications (aka CNFs) that run on Kubernetes. Our goal is to enable operators and creators of CNFs to take advantage of Kubernetes application development benefits. This session will cover an introduction to the working group, how we work, and what we produce. We will explore an example use case and a set of best practices for networking applications. Finally, we will provide an overview of some of the areas currently in discussion, and how you can participate, or even contribute.
A
Hello,
everybody
and
welcome
to
this
session,
which
is
about
the
cnf
working
group.
I'll
just
make
some
quick
introductions.
There
are
three
of
us
co-chairs
and
we're
all
going
to
have
a
little
chat
with
you
today,
my
name's
ian
wells.
I
work
for
cisco.
I
build
cnfs,
my
co-chair
there
from
charter
is
jeff
salence.
He
runs
cnfs
and
taylor.
Carpenter
is
how
many
in
the
community
who
makes
sure
that
they
all
work
on
kubernetes.
A
So
a
quick
intro
to
the
group
itself.
We
were
formed
at
kubecon
about
a
year
ago.
At
this
point,
it
was
a
collaboration
between
a
bunch
of
us
service
providers.
Telcos
need
to
actually
run
cnfs
as
vendors
need
to
make
cnfs
and
again,
as
I
say,
we
need
to
make
it
so
it's
possible
to
create
these
things.
A
A
cnf
for
those
of
you
aren't
quite
aware
on
that
is
a
cloud
native
network
function,
so
we're
not
just
looking
for
containerized
but
actually
cloud
native
that
influence
or
facilitates
network
functionality.
So
it
might
be
moving
individual
network
packets
around
or
it
might
be
something
that
supervises
or
controls
or
transfers
information
about
where
those
packets
go.
So
we
include
actual
things
like
routers,
but
we
also
include
things
like
reflectors
bgp,
and
you
know
this
crosses
the
board
into
other
areas
of
networking.
Like
mobile
networks.
A
We
obviously
want
to
design.
At
least
we
want
to
enable
design
of
those
cnfs
as
microservices
as
well
structured
applications
using
the
best
practices
that
we
already
know
from
the
kubernetes
world,
with
immutable
infrastructure
with
declarative,
apis
and,
of
course,
repeatable
deployment.
But
we
also
need
to
deal
with
the
things
where
cnfs
are
a
little
bit
different
and
special,
so
our
problems
basically
amount
to
the
difficulty
in
making
these
things.
Work
cns
are
hard
to
develop
and
operate,
and
we
want
to
simplify
that.
A
We
want
to
make
it
so
that
developing
a
cnf
is
not
something
that
you
you
spend
so
long,
trying
to
figure
out
how
even
that
works.
We
want
to
make
sure
that
you
follow
the
best
practices
for
building
cnfs.
We
don't
want
you
to
go
and
fall
into
the
pitfalls
that
other
people
have
found
previously,
and
we
want
to
make
sure
that
cnfs
actually
are
consistent.
So
you
use
them
consistently
the
your
experiences
with
one
cnf
transfer
to
the
next
one
and
the
next
one.
A
So
our
goals
here
are
to
identify
the
best
practices
for
running
cns
and
kubernetes,
so
that
kubernetes
developers
and
operators
can
both
adopt
them
to
work
out
which
of
those
practices
allow
specifically
networking
applications
to
use
kubernetes
properly,
and
we
also
obviously
don't
want
to
reinvent
the
wheel.
So
we
talk
to
other
groups
in
the
cncf
who
do
related
topics
that
we're
interested
in
and
we
take
their
advice.
A
So
we
have
to
remember
at
the
moment,
cnfs
are
relatively
in
the
early
phases.
It's
not
that
they
don't
exist,
but
there
aren't
all
that
many
out
of
the
of
them
out
there
and
they're
not
completely
consistent
in
how
you
use
them
and
how
they
behave.
So
what
we
want
to
do
here
is
basically
meet
people
doing
this
in
the
state
that
they're
currently
in
and
then
walk
them
forward.
A
So
we
learn
from
what
they're
operating
and
we
take
what
their
experiences
are
and
make
them
best
practices
and
write
them
and
share
them
with
people
and
then,
as
we
find
out
new
things,
we
share
those
as
well,
and
a
best
practice
is
not
a
perfect
target.
A
best
practice
improves
over
time.
As
you
learn
more
and
more,
we
work
with
these
four
design
ideals,
portability,
flexibility,
extensibility
and
automatability,
and
why
do
we
talk
about
these
well
to
begin
with
portability,
we're
looking
for
applications
that
run
on
kubernetes,
but
kubernetes
is
not
one
thing.
A
A
For
you
know
their
personal
preferred
reasons.
Flexibility
and
extensibility
is
about
making
sure
that
we're
getting
the
benefits
of
being
part
of
the
kubernetes
community.
We
don't
want
to
lock
ourselves
down
to
doing
things
in
one
precise
way
forever.
As
an
example,
kubernetes
obviously
does
orchestrate
containers
to
an
extent
it
will
run
a
certain
set
of
containers
for
you
and
try
and
keep
the
count
to
a
certain
number.
A
But
on
the
other
hand,
we
then
moved
on
to
using
helm
to
describe
that
because
it
made
things
a
little
easier
and
then
because
we
worked
out
that
it
wasn't
always
suitable.
We
went
and
we
started
writing
operators
to
run
specific
microservices,
because
sometimes
you
need
orchestration,
that's
more
complex,
but
more
functional
than
helm
provides
and
that's
a
perfectly
natural
evolution.
The
world
moves
on
and
we
learn
better
ways
of
doing
things.
We
want
to
be
a
part
of
that
learning.
We
want
to
be
able
to
adopt
what
comes
along.
A
So
it's
important
that
we
don't
end
up
in
a
rigid
place
where
we
can't
change
and
finally,
automatability
humans
are
flawed.
I
think
that's
a
fairly
safe
thing
to
say:
if
you
ask
them
to
do
something
twice,
or
indeed,
even
once
follow
a
set
of
instructions,
they
can't
always
do
it
the
same
or
right.
A
If
we
look
at
5g
networks,
where
we're
trying
to
build
radio
access
networks,
we're
actually
looking
at
them
orchestrating
thousands
of
applications
and
thousands
of
clouds
around
the
network,
if
we're
asking
them
to
hand,
deploy
a
thousand
clouds,
you're
going
to
get
a
thousand
different
clouds
out
of
that,
it's
not
going
to
work.
Similarly,
if
we
ask
them
to
hand
deploy
a
thousand
applications,
then
you're
going
to
get
a
thousand
different
deployments
that
don't
behave
the
same
the
more
we
can
automate
the
fewer
problems
we
have
and
the
more
consistently
everything
works.
A
B
You
ian
so,
as
you
mentioned
earlier,
I'm
jeff
salens.
I
work
with
charter
communications.
I
come
from
the
operator
paradigm
and
you
know
one
of
the
main
reasons
I
contribute
and
I'm
active
in
the
cnf
working
group
is
so
that
I
can
share
my
views,
but
then
also
try
to
understand
ian's
and
tailors
and
like
the
groups
that
they
represent,
so
we're
going
to
walk
through
a
little
bit
deeper
on
the
challenges
through
the
different
paradigms.
B
So,
first
we're
going
to
take
a
look
at
developers
and
one
of
the
first
questions.
You
know
that
we
ask
is:
do
you
write
cnf
and
if
the
answer
is
yes,
what
challenges
are
you
facing
some
common
answers?
Are
you
know
what
are
the
defined
patterns
like
what
are
the
best
ways
to
add
a
second
interface
into
a
pod?
How
do
I
deliver
network
services
that
a
consumer
actually
wants?
Will
the
provider
of
the
infrastructure
give
me
what
I
need?
Will
my
cnf
be
able
to
run
there?
B
You
know,
if
not,
is
it
okay
for
me
to
package
my
own
kubernetes
distribution?
How
do
I
innovate?
You
know
like
it's
really
hard
to
gain
adoption
right
now,
because
there's
so
many
different
views,
people
want
to
get
out
there
and
prove
that
they're
pushing
the
bleeding
edge
and
bringing
value,
but
sometimes
it's
tough
to
show
that
your
way
actually
is
best
and
then
finally,
how
do
you
support
your
product?
It's
stuff
in
a
multi-cnf
world,
that's
heterogeneous
when
the
provider
is
the
one
controlling
the
platform
and
you
start
to
lose.
B
If,
yes,
you
know
what
does
life
beyond
nfv
look
like
what
lessons
can
we
learn?
You
know:
do
you
get
to
run
your
own
upstream
kubernetes?
This
is
always
a
point
of
contention.
Why?
Because
of
that
supportability
conversation
can
I
run
a
standardized
platform
throughout
my
private
and
public
cloud
instantiations
and
expect
cnf
developers
to
provide
me
software
that
I
can
run
on
it.
You
know
what's
wrong
with
my
cni
like:
why
do
I
have
to
use
a
proprietary
cni
and
you
know
ultimately,
can
I
put
this
into
my
software
apparatus?
B
B
B
B
You
know,
find
ways
to
overcome
the
challenges
that
are
being
listed
and
drive
towards
use
cases
that
are
sorry
best
practices
that
we
can
then
publish
and
start
to
help
define
some
of
those
established
patterns
so
that
you
know
starting
off
at
like
a
more
high
layer.
Esoteric
view
of
things
is
a
combined
user
story
for
like
developers
and
operators
and
that's
how
do
I
get
cnfs
into
someone's
infrastructure
and
then
how
do
they
maintain
and
run
that
so
first,
you
got
to
get
the
cnf
into
the
telcos
infrastructure.
B
Typically,
this
is
a
private
cloud,
maybe
even
a
hybrid
cloud
scenario,
where
they're
using
both
public
services-
and
you
know
first
party
services
from
a
cloud
infrastructure
standpoint
you
know.
Is
there
a
means
for
them
to
watch
repos
and
pull
them
in
continuously
into
their
pipelines?
Can
we
treat
cns
like
we
would
other
software,
despite
some
of
the
quirks
that
they
present
from
a
software
and
management
standpoint?
Are
there
feedback
loops
to
present
data
from
our
continuous
testing
back
to
the
cnf
developers?
B
Are
we
being
good
citizens
and
giving
them
the
information
that
we're
finding
as
we're
running
this?
Are
there
defined
requirements
things
like
air
gap
installations?
Do
I
have
to
go
to
the
internet?
What,
if
I
don't
allow
internet
access
from
my
private
data
centers?
Can
I
pull
in
all
of
this
and
build
from
scratch
within
my
own
environments?
B
B
Conversely,
if
I'm
a
cnf
developer,
how
do
I
ensure
that
I
can
handle
the
constant?
You
know,
upswing
of
kubernetes
releases,
if
I
have
a
customer
that
is
agile
and
is
constantly
maintaining
and
updating
their
infrastructure
and
versioning
will
I
be
able
to
keep
pace
with
them?
What
does
that
agreement
look
like
and
then,
finally,
how
does
the
cncf
community
stitch
it
all
together
and
help
us
bridge
these
worlds?
B
B
How
do
I
program
this
transparent
firewall
to
have
the
right
axles
in
place?
How
do
I
ensure
that
it's
performing
the
way
I
want?
How
am
I
collecting
metrics
on
it?
So
then,
ultimately,
we
looked
at
the
design
ideals
and
we
start
going
apart.
This
use
case
and
figuring
out
what
are
the
actual
best
practices
once
again
meeting
the
user
where
they
at
what
technology
exists
now
and
where
do
we
need
to
try
to
push
the
envelope,
because
it's
not
all
trivial
right?
B
Everything
in
kubernetes
like,
if
you
look
at
the
base
requirements-
it's
you
know,
player
three
reachability
between
pods
between
nodes,
etc.
What
if
I
need
a
layer,
two
interface
which
is
at
that
ethernet
layer?
It
doesn't
work
with
packets
and
it
doesn't
work
with
ip
addresses.
Can
we
achieve
this
in
kubernetes?
B
B
It
is,
you
know,
an
application
comprised
of
many
applications,
and
so
ultimately,
we
need
to
figure
out
how
we
support
people
trying
to
deploy
packet
core
in
kubernetes
now.
But
we
need
to
make
sure
that
we
don't
repeat
this
past
mistakes
of
the
nfv
evolution
where
we
virtualize
things,
but
we
didn't
really
design
the
software
to
run
in
a
virtualized
world.
We
treated
them
like
appliances
and
we
didn't
really
get
that
cloudish
type
experience
that
we
were
ultimately
hoping
for.
B
B
Can
cnf's
expect
that
the
infrastructure
itself
is
declarative
and
make
requests
without
potentially
breaking
you
know
privileged
boundaries,
and
things
like
that
was
the
cnf
or
the
infrastructure
designed
for
automation.
You
know:
am
I
going
to
get
the
portability,
the
compatibility
that
I
need.
How
do
I
manage
state
when
I
have
stateful
applications?
B
Next,
we
look
at
security.
Security
itself
can
be
broken
off
into
multiple
different
subcategories
security
is
not
a
unique
concern
to
cnfs.
The
reason
why
we
do
look
at
it
specifically,
though,
is
because
cnfs
tend
to
be
very
greedy
when
it
comes
to
things
like
privileges,
talking
to
the
colonel
requesting
elevated
access
to
the
underlying
infrastructure,
that
a
lot
of
you
know
more
traditional
applications
would
not
so
diving
a
little
bit
deeper
in
the
security
bucket.
We
could
look
at
something
say
specifically,
like
least
privilege.
B
What
are
some
of
the
best
practices
that
you
know
come
from
the
least
privileged
bucket,
and
that's
things
like
not
running
your
containers
as
root.
If
you
don't
have
to
you
know
ensuring
that,
like
privilege,
equals
false,
is
the
default
setting
that
is
deployed
over
and
over
and
over
again,
if
I
have
something
that's
privileged,
when
it's
done
doing,
what
it
needs
to
do
and
execution
is
complete,
does
it
relinquish
those
privileges
and
then,
finally,
am
I
implementing
our
back
through
all
the
different
layers
of
this
stack,
the
platform,
the
pod,
the
container
etc?
B
So,
finally,
where
are
we
going
with
best
practices?
Why
are
we
pulling
apart
all
these
use
cases
and
digging
into
the
weeds
to
figure
out
what
we're
trying
to
accomplish
and
that's
because
there's
a
lot
of
new
areas
to
explore
and
areas
that
are
unique
to
both
cnf
and
kubernetes,
just
because
of
what
the
two
in
you
know,
pieces
of
technology
are
trying
to
accomplish.
So
what
is
the
best
way
to
do
multiple
interfaces
into
pod?
This
is
something
that's
being
explored.
B
You
know
how
do
I
leverage
node
labels
and
the
metadata
available
to
me
to
get
the
kubernetes
scheduler
to
put
the
right
workload
on
the
right
piece
of
hardware
without
breaking
cloud
native
paradigms
and
declarative
approaches?
Can
I
move
packets
quickly?
You
know.
Is
it
a
microservice
if
my
data
plane,
acceleration
is
four
million
lines
of
code
you
know
like?
Are
we
gonna
have
to
rewrite
software
at
some
point,
while
still
taking
advantage
of
what's
available
there
today
and
then?
B
Finally,
at
what
point
have
I
turned
so
many
knobs
that
I'm
actually
starting
to
diminish
the
value
of
cloud
native
approaches
in
itself?
If
I've
made
something,
that's
so
bespoke
and
you
know
broken
all
the
immutable
infrastructure
like
mantras
that
are
preached
then
have
I
started
to
like
erase
the
value
that
I
got
from
going
into
kubernetes
and
taking
on
cloud
native
approaches
in
the
first
place,
and
so
lastly,
the
thing
that
you
need
to
know
is:
how
do
you
get
involved
and
with
that
I'm
going
to
hand
it
over
to
taylor.
C
So,
as
of
this
recording,
there's
27
organizations
and
individuals,
who've
are
actively
participating
and
express
interest
in
the
work
that
we're
doing
in
the
cnf
working
group.
If
you're
a
service
provider
or
you're
creating
network
functions,
we
invite
you
to
join
these
other
organizations
and
sharing
your
real
world
use
cases
and
experiences.
C
If
you
are
part
of
the
cncf
project
community
or
working
on
a
project
specifically,
please
come
and
talk
with
us
about
where
your
experiences
with
those
projects
could
help.
This
could
be
in
use
cases
how
the
technology
is
used.
The
best
practices
that
you've
learned
we've
seen
a
lot
of
stuff
from
projects
like
falco
and
opa
and
tuff
for
the
security
area,
there's
also
projects
and
focused
in
all
the
different
areas
that
I
think
we
care
about
configuration
deployment,
life
cycle,
there's
argo
and
flux
and
harbor.
C
Orange
france
has
a
network
of
the
future
seminar,
we'll
be
talking
with
folks
from
there
we'd
love
to
hear
from
people
from
the
open
networking
foundation,
and
maybe
those
working
on
the
omec
project,
telecom
infrastructure,
project
or
tip
so,
if
you're
out
there
in
another
organization
or
project-
and
you
think,
there's
some
ideas
you'd
like
to
share.
Maybe
you
see
some
stuff
that
we're
doing
that
you'd
like
for
us
to
come
talk
please
reach
out
to
us.
C
If
you
do
want
to
contribute
within
this
working
group,
whether
that's
adding
to
existing,
creating
new
content,
we're
helping
to
improve
across
the
board
and
docs,
whether
that's
spelling
small
clarification,
adding
new
references,
we'd
love
to
invite
you
to
come
in
on
that
there's
a
lot
of
places
where
you
can
get
started
and
we've
made
it
possible
to
come
in
in
different
areas.
Like
the
github
repo
itself,
we
have
a
discussion
board.
We
can
come
and
add
your
ideas.
C
If
you
want
something
more
permanent
so
that
we
can
take
the
content
and
maybe
add
it
into
use
cases,
we
have
a
google
drive,
that's
open
with
content
we've
been
putting
in
there.
We
can
collaborate
in
in
documents
there
if
you're
prefer
markdown.
We
also
have
a
hack,
md
space.
There's
that
give
discussions.
As
I
mentioned,
you
can
add
issues,
put
comments
and
pull
requests.
We
have
a
lot
of
places
where
you
can
collaborate.
C
If
you're
interested
in
actually
writing
tests
around
these
best
practices
and
helping
to
validate
the
software,
we
do
have
an
initiative
called
the
cnf
test
suite
with
a
set
of
tests,
focus
on
doing
just
that,
it's
you
can
check
it
out
on
the
cnf
test,
suite
repo.
There
is
a
contributor
meeting
for
that
on
thursdays,
there's
also
a
public
slack
channel
on
cmcs
slack
and
a
mailing
list.