►
From YouTube: CNCF SIG Network 2020-11-05
Description
CNCF SIG Network 2020-11-05
A
B
C
A
C
E
C
Oh
good
deal
folks,
we
are
a
couple
of
minutes
in
I'm
gonna
put
a
link
to
the
meeting
minutes
in
the
chat
these.
These
are
community
meeting
minutes
and
it's
a
community
call.
It
is
a
cncf
call,
so
we
do
record
the
meeting
and
post
it
to
youtube,
but
the
participation
in
the
meeting
and
participation
in
the
meeting
minutes
open
to
everyone.
C
You
don't
need
to
be
a
member
of
the
cncf
or
be
representing
a
particular
project
to
have
an
active
voice
and
bring
up
topics,
and
things
like
that.
So
so
please
don't
be
shy
and
if
your
name
isn't
in
the
meeting
minutes,
please
drop
it
in
a
couple,
we'll
probably
lollygag
for
another
minute
or
two,
but
it
now
is
a
good
time
to
make
a
call
for
agenda
call
for
topics.
C
C
You're,
do
you
know,
I
hope,
hopefully
there's
some
flattery
involved
in
your
topic
and
your
kind
of
your
area
of
focus
being
of
such
interest
that
we're
asking
for
an
encore
from
your
envoy
con.
Yes,
there
is
thank
you
very
much
good
deal
good
deal
yeah,
you
were
the
that
was
if
we
go
back
into
the
meeting
minutes
that
was
kind
of
a
subject
of
discussion.
C
We
we
sort
of
meandered
last
time
that
we
spoke,
but
but
that
ends
up
being
a
good
thing,
because
then
we've
we
stumble
into
topics
like
the
one
that
you're
focused
on
so
given
that
it
is
five
after
and
we've
got
some
a
small
collection
of
folks,
it's
it's.
Probably
it's
probably
time
to
get
going.
Taylor,
I'm
gonna
toss
on
maybe
another
like
we've
got,
maybe
a
couple
of
other
topics.
I
don't
know
if
how
much
either
time
or
how
much
desire.
F
Can
you
see
my
slides,
or
do
you
see
my
your
slides,
nice
and
okay
perfect?
So
then
that
means
it
works
properly.
So
I
guess
hi
everyone.
My
name
is
florian
korres,
I'm
a
cisco
technical
lead,
also
a
fido
vpp
project
maintainer,
and
the
point
with
today's
talk
is
that
would
be
to
give
you
a
high
level
overview
of
the
benefits
of
using
vpp
as
on
voice
network
stack.
F
F
Vup
is
an
lt2l7
networking
stack
which,
at
its
core
leverages
to
important
ideas,
vectorized
packet
processing
and
the
modeling
of
the
forwarding
as
a
directed
graph
of
nodes.
Now,
when
these
are
done
correctly,
they
ensure
really
efficient
use
of
a
cpu's
caching
hierarchy
and
consequently
a
minimal
overhead
per
packet
when
doing
software
forwarding
now.
Another
really
important
aspect
of
this
approach
is
composability.
F
F
It
has
a
session
layer
or
a
socket
layer.
Now
this
one
provides
a
number
of
features,
but
perhaps
the
most
important
for
the
context
of
the
stock
is
the
shared
memory
infrastructure
that
can
be
used
to
exchange
io
and
control
events
with
external
applications
using
per
worker
message,
cues
or
what's
depicted
here
as
mqs
finally
to
simplify
interoperability
with
applications.
Vbp
provides
a
communications,
library
or
vcl,
which
exposes
a
posix
slide,
apis
northbound
towards
the
applications.
F
So
I
guess
that
by
this
point
some
of
you
may
be
asking
a
danish
people
question
or
maybe
not
why
yet
another
host
app
and
you'd
be
right
to
do
so
because
from
a
functional
perspective,
linux
is
obviously
the
one
stack
to
use.
However,
because
linux's
networking
stack
was
designed
around
the
single
pass
warranty,
completion
model
per
packet
performance
is
limited,
and
this
is
especially
noticeable
when
hardware
acceleration
cannot
be
leveraged,
but
in
addition
to
the
speed
that
could
be
provided
by
a
faster
transport
or
a
faster,
socket
layer.
F
The
fact
that
the
stack
is
in
user
space
could
be
leveraged
to
optimize
integration
and
perhaps
even
minimize
the
amount
of
data
copies
that
happen
between
the
application
and
and
the
stack
also
because
the
whole
protocol
stack
is
packaged
with
the
application
it
could
potentially
be
customized
or
extended
in
certain
situations.
One
can
certainly
imagine
scenarios
where,
for
instance,
the
socket
provides
more
context,
data
to
to
the
underlying
layers.
F
F
F
So
obviously,
this
was
not
exactly
glamorous
work.
Most
of
the
changes
were
not
features.
They
were
more
focused
on
refactoring.
Still
out
of
the
set
of
changes
that
have
gone
in
perhaps
the
most
notable
are
the
fact
that,
as
a
community,
we
decided
as
a
core
rule.
We
now
must
avoid
using
raw
file
descriptors
anywhere
in
the
code.
F
F
An
interesting
consequence
of
the
first
point
is
the
fact
that
file
event
creation
is
now
delegated
to
the
I
o
handle
implementations,
so
the
desired
side
effect
of
this
is
that
the
socket
layer
that
provides
io
handles
is
the
one
that
decides
how
the
events
for
this
io
handles
are
created.
In
other
words,
we
now
socket
events
are
are
no
longer
tightly
coupled
with
lib
event.
F
Some
coupling
still
needs
to
exist
and
I'll
go
over
that
in
a
second,
but
now
that
one
is
not
implicit
anymore
and
finally,
perhaps
an
interesting
scenario
that
might
serve
as
an
example
for
the
community
going
forward
was
tls,
which
mainly
for
convenience
reasons,
relied
on
bios
that
needed
explicit
access
to
the
file
descriptor,
but
it
eventually
turned
out
that
writing
a
custom
bio
that
uses
the
I
o
handle
as
opposed
to
the
file.
Descriptor
is
relatively
straightforward,
so
we
we
actually
switch
to
that.
F
F
Now
the
solution
to
this
problem
is
to
leave
control
to
a
lib
event
and
to
register
the
event
fd
associated
to
a
vcl
workers.
Message
queue
with
limit.
Now,
if
you
recall,
since
I'm
relying
now
on
you
remembering
my
previous
slides
the
message
queues
are
used
by
vpp,
to
convey
io
and
control
events
to
the
application.
F
Now
these
are
just
the
stepping
stones
for
the
envoy,
vcl
integration
and
as
first
next
steps,
the
plan
is
to
further
optimize
the
performance.
Now
the
lowest
hanging
fruit.
There
are
the
read
operations,
as
vcl
could
pass
pointers
to
socket
data
in
the
shape
of
buffer
fragments,
instead
of
doing
a
full
map
copy.
F
So
there's
still
some
work
to
be
done
that,
but
speaking
about
performance
to
evaluate
the
potential
benefits
of
this
integration,
I
used
the
following:
topology
wherein
wrk
connects
through
vcl
and
envoy,
which
performs
http
routing
to
a
back-end
nginx.
Now
this
type
of
scenario
might
not
be
relevant
in
practice
and,
in
fact,
I'd
be
delighted
to
learn
from
you
or
any
anybody
else
who
is
using
envoy
in
practice
or
deploying
a
way
in
practice.
F
F
Performance
is
seems
to
be
very
good,
20
to
40
20,
to
40
percent
better
and
to
scale
pretty
well
the
story
in
the
margin
there
is
that
other
certain
point
about
four
to
five
workers
performance
does
not
scale
linearly
anymore,
and
it
behaves
somewhat
worse
for
larger
payloads.
Although
it
should
be
noted
here
that,
for
this
test
in
particular,
tso4
vpp
was
not
enabled
so
backing
up
or,
as
a
summary
results
are
really
encouraging
from
from
our
perspective.
F
But
there
are
still
some
things
that
need
further
investigation
for
for
a
better
understanding,
so
we're
clearly
faster
than
the
kernel,
but
we
need
to
understand
if
the
scaling
of
the
performance
has
to
do
with
my
test.
Bed
has
to
do
with
vpp
vpp
vcl
into
vpp,
sorry,
envoy,
integration,
or
maybe
the
the
problem
could
lie
in
enough
voice,
so
we
wish
we
might
need
to
to
further
optimize
some
code
there.
F
With
that,
should
you
be
interested
in
further
exploring
the
zomboid
vbp
integration?
Please
give
the
code
a
try.
You
have
a
link
now
there
to
to
my
github,
it's
a
bit
stale,
maybe
a
month
old.
I
still
need
to
upload
the
zero
copy
version
of
the
code
and
in
case
I
won't
be
able
to
answer
all
of
your
questions
here
feel
free
to
email
me
or
drop
me
on
on
voice
slack
with
that.
Thank
you
very
much
and
do
let
me
know
if
you
have
any
questions.
C
F
D
D
F
Let's
look
at
several
things
here.
First
of
all,
could
you
use
vpp
within
with
kubernetes,
and
the
answer
would
be
yes
and,
as
I
mentioned,
and
in
case
you
I'll
pass
over
the
slides
there's,
even
a
talk
now
happening
at
kubecon
with
respect
to
the
calico
pvp
integration,
so
calgo
can
use
vpp
as
a
data
plane
coming
back
here
right.
F
So
what
sort
of
integration
should
we
expect
or
what
sort
of
integration
would
be
possible
for
for
our
envoy
with
calico
vpp
and
then
subsequently
with
the
applications
and
now
there's
several
modes
of
operation?
Yes,
you
could
deploy
envoy
as
a
sidecar
and
then
have
that
attached
to
vpp
and
you
can
have
several
instances
of
those
envoys.
F
So
not
only
one.
The
question
afterwards
is:
how
do
you
connect
the
applications
to
your
envoy
and
what
I'm
depicting
here
is
the
general
case,
which
probably
is
the
safest
case
as
well,
and
maybe
we
should
dive
into
that
a
bit
remember
here.
The
integration
is
shared
memory,
so,
but
what's
happening
here
right
now
is
here
remember
it
will
not
offer
you
the
same
sort
of
security
that
the
kernel
offers
you
today.
F
F
Now
it's
well
known
that
envoy
does
not
support
name
spacing
at
this
point
and
there
there
have
been
efforts
from
others
in
this
direction.
There
have
not
been
upstream.
So
if,
if
we
want
to
do
something
like
that,
probably
we
will
need
to
to
change
envoy
and
finally,
the
most
efficient
way
of
doing
this
within
kubernetes
would
be
to
not
leverage
tap
interfaces,
but
actually
leverage
something
that
we
call
cut
through
sessions.
F
And
let
me
explain
so
if
two
applications
attach
via
vcl
to
a
vbp
instance
where
that
vpp
instance,
what
it
offers
is
the
socket
layer,
functionality
the
whole
stack
functionality,
but
if
both
of
those
applications
attach
to
the
same
vbp
instance
that
socket
functionality
is
actually
not
required,
the
kernel
is
known
to
be
inefficient
in
that
you,
whenever
two
applications
attached
to
it
say
using
tcp,
the
kernel
will
actually
go
through
the
tcp
layer
implementation.
So
it
does
a
lot
of
extra
work
that
it
should
not
do
well
with
vpp.
F
We
support
what
we
call
cut-throughs,
meaning
pvp
detects
that
both
envoy
and
the
application
are
attached
to
the
same
pvp
instance,
and
it
uses
pure
shared
memory
buffers
to
to
exchange
data.
This
go
now.
This
comes
with
a
caveat,
as
I
mentioned
before.
This
is
shared
memory,
so
one
we
haven't
put
that
much
effort
into
securing
properly
securing
this,
and
that
was
a
very
long
answer.
I
hope
it
clarified.
At
least
some
of
your
your.
D
D
Okay,
my
second
question,
and
that
will
be
the
last
because
I
saw
that
taylor
already
added
the
cnf
initiative
that
they
started.
One
of
the
things
that
that
actually
folks
and
other
groups
are
trying
to
actually
bring
into
the
cloud
native
world
is:
are
these
cns
or
cloud
native
networking
functions?
And
if
we,
if
we
see
this
envoy
as
a
networking
function,
I
don't
know
if
you
have
thought
about
it.
I
understand
that
it's
a
kind
of
an
experimental
but
a
question
and
maybe
an
advice.
D
Would
this
be
possible
to
actually
actively
figure
out
if
there
is
vpp
available
or
not
so
that
you
can
actually
deploy
it
in
a
public
cloud
infrastructure,
the
same,
let's
say
a
container
envoy
and
then,
if
there's
no
vpp
to
just
do
whatever
like
use
the
standard
kernel
interfaces
or
is
it?
Is
it
so
heavily
modified
that
it
can
only
function
with
vpp
or.
E
D
No,
no!
No!
No!
No!
No!
I'm
sorry
from
android
point
of
view,
assuming
that
I
want
to
deploy
only
envoy
in
a
container
not
as
a
sidecar,
not
as
anything.
I
consider
that
invoice.
My
function
that
I
want
to
deploy
my
my
application,
the
version
that
you
have
in
your
tree
and
essentially
I
don't
know
how
this
is
going
to
go
forward.
But
let's
say
that
I
want
to
use
this
version.
Is
it
so
heavily
modified
that
it
cannot
function
with
the
standard
sockets
or
I
mean?
F
F
You
can
then
based
on
nonvery
specific
mechanisms
in
particular,
for
instance,
addresses
can
can
request
either
default
processing
or
an
address
could
come
with
a
hint
that
says,
please
does
address,
use
it
on
on
vcl
socket
and
then
avoid
make
make
sure
to
to
open
the
the
right
socket
for
you
or
through
the
right,
socket
interface.
So
sure
answer
to
your
question:
yes,
we
can
switch.
So
you
envoy,
you
can
bring
gumboy
up
with
the
default
kernel
interface
and
then
you
can.
You
can
load
this
additional
module.
F
So
I
have
not
tried
to
push
this
upstream
now,
my
com.
In
my
conversations
with
matt,
we
we
sort
of
decided
that,
if
there's
enough
interest
in
having
this
upstream,
we
could
upstream
it
and
and
then
make
sure
that
everything
is
built
together
and
then
you
will
have
at
runtime
just
some
switches
that
you
can
flip
and
then
you
can
use
either
the
kernel
or
or
vcl.
G
F
F
If
you
configure
that
resolver
to
always
default
to
to
assigning
vcl
as
an
interface,
you
actually
do
not
care.
So
basically,
this
will
be
a
configuration
that
you
can
inject
at
runtime
and
say:
oh
whenever
you
open
the
new
connection
to
a
backend,
for
instance,
or
or
something
like
that,
make
sure
to
use
the
vcl
interface,
not
not
the
kernel
interface,
and
you
can
do
that
explicitly
if
you
just
if
you
are
just
worried
about
default
behavior,
then
you
can
detect
when
vpp.
G
G
F
If
you
deploy,
if
you
deploy
vpp
with
say
with
without
dpdk,
and
now
it
will
depend
a
lot
on
what
sort
of
drivers
you
try
to
use,
sriov,
avf
or
anything
else,
you
will
need
just
the
dependencies
for
those,
but
normally
it
should
work
with
with
all
current
well
with
all
modern
kernels,
let's
at
least
stipulate
that,
if
you're
thinking
about
kernel
modules
that
might
be
needed
and
are
not
typically
provided,
I'm
guessing
you're
thinking
about
something
like
vfio,
pci
or
stuff,
like
that.
Those
are
typically
needed
for
dpdk.
G
Okay,
gotcha
I've
seen
more
problems
on
the
the
physical
host
side
like
are
certain
things
turned
on
in
the
bios
more
than
it
does
the
kernel
work
and
then
you
get
into
stuff
on
like
privileged
mode.
If
you're
doing,
how
are
you
going
to
access?
If
you
use,
say
memif
devices
to
talk
between
containers.
D
G
E
C
F
Just
enough,
I'm
sorry
for
interrupting.
We
know
so
vpp
can
be
deployed
in
pc2
and
has
been
deployed,
but,
as
you
said,
first
with
specific
functions,
I've
never
tried
doing
this,
for
instance
with
envoy
we've
done
it
with
ipsec,
for
instance,
and
just
to
see
how
how
fast
the
implementation
would
be
and
with
dvdk
it
seems
to
be
working.
Fine.
F
A
very,
very
good
point,
separate
effort,
but
as
far
as
as
far
as
we
can
tell,
and
when
I
say
we
I
mean
the
community-
the
opposition,
then
not
talking
in
the
name
of
my
employer,
but
the
community
we've
managed
to
get
this
to
to
work
in
those.
Are
those
type
of
scenarios
and
performance
used
to
be
pretty
good,
maybe
better
than
the
other
that
you've
mentioned.
C
Another
another
quick
question
it
might
have
that.
I
heard
this
out
of
context,
or
I
didn't
hear
the
right
is
there
was
part
of
your
discussion
was
about,
was
about
an
envoy
per
node
and
and
some
caveats
around
that
and
I
didn't
quite
catch
the
the
use
case
or
the
need
for
for
that
architectural
model.
F
Very
good
question,
actually
so
the
problem
that
I've
heard
now
that
I've
in
practice
was
that
envoy
communication
to
the
upper
layers
say
to
istio
becomes
the
ball
net
when
you
have
too
many
envoy
instances
deployed.
So,
for
instance,
you
you
end
up
into
large
or
moderate
deployments,
end
up
needing
hundreds
of
megabits
to
gigabits
per
second
of
control
traffic
when
in
case
of
a
restart
event,
massive
restart
event.
Let's
say
so.
F
The
idea
was
the
the
the
solution
to
to
that
problem
was
to
well,
let's
have
one
of
them
for
a
node
and
have
that
be
multi-tenant,
as
opposed
to
having
multiple
small
instances
of
envoys
that
we
load
that
sidecars,
I
think
psyllium
I've
been
working
on
that.
I
don't
know
exactly
how
far
they've
gotten
with
it.
C
C
Flooring
this
this
has
been
nice.
This
is
it's
a
special
treat,
I
think,
for
some
of
us.
We,
I
think
we
kind
of
switch
between
doing
project
reviews
to
meandering
between
a
bunch
of
topics
to
receiving
presentations
like
this,
and
I
have
to
say
that
the
nerd
in
me
appreciates
a
good
set
of
diagrams.
So
so
thank
you
very
much.
Yeah.
F
H
C
C
C
It's
worth
noting
that
we
had
been
hosting
those
discussions
kind
of
those
set
those
sessions
at
this
time
kind
of
using
this
time
to
advance
some
of
those
initiatives.
A
couple
of
the
initiatives
within
there
are
people
are
requesting
more
time
to
discuss
and
advance.
Smi
conformance
is
one
and
the
other
one
is
smp.
C
This
initiative
is
well
actually,
since,
since
taylor
is
on
I'll
use,
a
common
analogy
that
that
is
used
for
cnf
conformance
and
it's
to
say
that
smi
is
a
specification.
There
are,
I
think,
seven
service
meshes
that
signal
compatibility
with
the
spec
and
that's
great.
The
last
couple
of
major
service
mesh
announcements
of
new
meshes
coming
into
the
ecosystem
were
smi
compliant,
actually,
the
last
three
four,
maybe,
and
so
as
there
is
a
sona
boyd
to
kubernetes,
to
the
90-something
distributions
of
kubernetes,
there's
kind
of
a
there's,
a.
C
C
This
week
we
were
meeting
with
envoys
load,
generator
called
nighthawk
meeting
with
their
maintainers
and
discussing
a
number
of
things,
but
one
of
those
things
is
in
some
respects
to
what
florin
had
said
earlier
about
different.
So
envoy
has
different
distributions
and
there's
a
project
that
assists
with
that.
C
G
G
G
So
this
is
would
tie
into
what
you
see
on
these
definitions,
and
most
of
these
would
be
agreed
by
most
people
trying
to
keep
it
more
generic
and
not
kubernetes
specific.
But
the
this
is
to
lead
up
to
these
other
set
of
papers
so
starting
out
with
a
clot
breaking
down.
What
do
we
mean
by
cloud
native
and
going
into
each
of
the
concepts?
I
think
I
just
clicked
on
the
wrong
one.
G
This
one
was
the
one
I'm
at
these
actually
start
breaking
down
all
of
this
individual
concepts
and
you'll
have
an
area
here,
that's
more
english
and
then
it's
talking
about
how
it
ties
together
with
references.
So
that's
the
big
thing.
This
isn't
just
coming
from
the
people
that
have
been
involved,
people
that
are
creating
software's
telco
service
providers
was
a
lot
of
the
focus
on
hearing
networking
folks.
G
But
these
references
are
a
lot
of
different
people.
Doing
things
in
devops,
networking
in
general,
in
cloud
native
and
the
whole
set
of
papers
is
building
through
to
eventually
what
it
gets
to
this
area.
So
what
do
we
mean
when
we
say
cloud
native
networking
and
going
down
and
trying
to
answer
different
questions,
and
then
it
actually
breaks
those
down
into
further
pieces,
so
you
have
stuff
talking
about
what
do
we
mean
by
microservices
immutable
infrastructure
and
then
getting
into
the
osi?
G
G
They
are
leveraged
by
several
different
communities
and
there's
been
a
lot
of
you
know,
collaboration
from
people
on
them
and
as
cntt.
I
don't
know
if
anyone's
aware
of
that
the
lfn
community
they
they
point
to
some
of
these.
But
it's
at
this
point.
It's
something
where
there's
a
lot
more
people
within
I'd
say
cncf
in
general
that
are
wanting
to
have
more
of
this
well-defined,
and
so
that's
the
effort,
so
we'd
be
happy
to
get
more
eyes
on
that.
C
But
but
his
vision
was
to
define
much
of
that
pattern
like
cloud
native
patterns
for
all
the
things
of
which
it
was
hard
to
fathom
that
landing
or
be
or
like
ever
congealing.
But
so
of
the
just
to
clarify
that
I
guess
the
question
is
the
cloud
native
networking
principles.
Those
are
the
deepest
set
of
papers
thus
far.
Is
that
accurate
or
are
there
are
there
some
lengthy
papers
on
what
it
means
to
be
a
micro
service
or
to
be
loosely
coupled
or
to
easily.
G
I
don't
think
there's
been
anything
that
pulls
it
all
together,
that's
as
extensive
as
these
sets
right
here
and
really.
What
we're
saying
is
these
four?
So
this
one
is
a
build
up,
but
it
has.
You
can
see
a
ton
of
references,
these
all
go
into
lots
of
lots
of
different
books
and
people
that
have
been
doing
this.
They
don't
all
say
cloud
native,
but
you
know
this
managing
servers
in
the
cloud
you
know,
but
that
goes
all
over.
G
G
But
what
we've
found
specifically
in
which,
on
the
the
next
is
the
cnf
conformance
when
we're
looking
into
telco
and
how
to
try
to
help
bring
some
of
these
things
where
the
philosophies
from
like
devops,
where
ci
cd
is
just
a
norm
for
enterprise
and
everything
else,
and
try
to
bring
a
lot
of
the
philosophies
and
methodologies
that
are
already
commonplace.
You
have
to
go
further
back,
it
just
doesn't
work
unless
you
have
those
concepts
well
defined,
and
I
I
think
that's
why.
G
I'm
happy
to
chat
more
if
people
want
on
that.
I
would
like
to
at
least
just
mention
the
cnf
conformance
program,
and
you
can
check
out
the
presentation
that
happened
this
week
to
the
tfc
and
it
was
primarily
about
a
new
working
group,
but
that
I'm
going
to
actually
go
over
into
it's
probably
easier.
G
G
The
way
the
kubernetes
conformance
program
breaks
down,
underneath,
as
you
have
the
conformance
working
group,
sig
architecture,
sig
testing
and
they're
all
handling
different
aspects
within
the
cnf
conformance
program.
We
have
the
cnf
conformance
test
suite
project,
so
that
would
be
equivalent
to
what
sig
testing
is
doing.
G
But,
as
I
think
lee
you
might
have
mentioned
said
something
about
this
with
sauna
boy
earlier
we've.
Actually
that's.
This
project
has
created
the
test
suite
to
look
a
little
bit
more
like
sauna
boy,
as
far
as
like
configuration
and
other
stuff,
but
it
then
it
actually
has
tests
within
it
that
are
actually
there
versus
sauna.
Boy
has
a
plug-in
to
run
the
external
test,
which
you
could
have
run
directly
using
the
framework
in
the
kubernetes
cv,
but
so
that's
where
the
the
mechanics
and
the
actual
tests
are
implemented.
G
G
With
regards
to
cloud
native
best
practices
for
cns-
and
you
know,
one
of
the
things
that
we're
pointing
out
is
data
plane
cns.
So
I
think
the
stuff
that
we
were
talking
about
today
with
vpp
and
on
buoyant
stuff
is
very
important
for
these.
When
you
look
at
a
cnf
or
an
application
providing
network
functionality,
that's
at
a
non-data,
plane
layer.
It's.
G
It
may
be
a
lot
easier
to
talk
about
its
behavior
and
best
practices,
because
it's
going
to
look
more
equivalent
to
stuff
that's
already
in
agreement
or
sig
app
delivery
is
already
saying:
here's
some
best
practices,
but
when
you
get
down
to
data
plane,
cns
and
other
ones,
maybe
operators
and
stuff
that
are
tied
in
it
starts
to
get
a
little
bit
different
on.
What
does
that
look
like
on
best
practices?
G
So
this
working
group
is
going
to
be
focused
on
that
as
far
as
the
initial
scope
and
the
process
like
what
is
the
process
just
like
kubernetes,
you
walk
through
a
certain
stage.
You
run
sauna
boy,
you
have
pull
requests,
there's
a
bunch
of
things,
so
it'll
do
all
that
decisions
and
then,
as
I
said,
the
tesla
project
will
be
separate.
G
C
C
I
think
the
the
structure
as
it
is
now
with
with
sigs
is
that
they
may
end
up
spawning
any
any
number
of
working
groups
within
the
sigs.
So
so
I
guess
in
part
what
I'm
trying
to
say
is
that
I
think
the
life
cycle
of
a
cig
sort
of
operates
like
in
context.
I'm
sorry,
the
life
cycle
of
a
working
group
operates
in
context
of
a
sig
and
so
yeah.
Getting
a
landing
spot
in
a
sig
makes
makes
a
lot
of
sense
as
kind
of
a
home
base.
C
There's
an
example
of
a
we're
just
talking
about
the
service
mesh
working
group,
but
another
one
within
cncf
sig
network
is
the
ud
udp,
the
universal
data
plane,
api
working
group
or
udpa,
which
is
an
envoy
onward
api
more
or
formed
around
the
envoy
api.
The
any
feedback
from
sig
app
delivery
from
your
presentation.
G
Yesterday
I
mean
they're
they're,
all
interested,
they
have
a
there's,
a
air
gap
working
group.
That's
the
one,
telco
focused
working
group
that
was
in
sick,
app
delivery
because
most
of
it's
non
non-networking,
telco
type
apps
and
that
one
cigar
sorry
air
gap
is,
is
a
more
of
an
edge
type
of
focus.
So
it
doesn't
match
up
to.
G
G
Yeah,
so
for
as
far
as
conformance
goes,
then
it's
trying
to
provide
something
for
this
right.
Now
it's
for
the
telco
space
I
mean
there's
some
of
the
service
providers
have
said.
Telco
is
a
subset
of
the
networking
domain.
So
then
it
becomes
broader
as
far
as
that
goes,
but
the
the
idea
right
now
is
to
help
telcos
and
actually
becoming
more
cloud
native
and
and
right
now,
it's
saying,
let's
focus
on
the
applications
that
are
deployed
on
their
kubernetes
based
platforms
or
distros,
whatever
you
want
to
say.