►
From YouTube: The State of the Cloud Native Network: Deep-dive from TAG-Network - Ed Warnicke & Lee Calcote
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
The State of the Cloud Native Network: Deep-dive from TAG-Network - Ed Warnicke, Cisco & Lee Calcote, Layer5
Speakers: Ed Warnicke, Lee Calcote
Every application needs to communicate.
That communication happens over the network.
Cloud Native, at its most basic, is an evolution of how to better meet application developers needs in a world that has moved beyond the mental model of the underlying infrastructure. The Network is also evolving with new, more powerful, more flexible ways to allow applications to communicate with each other.
Cloud Native Networking is vast, encompassing CNI, CoreDNS, Envoy, gRPC, Linkerd, NATs, Network Service Mesh, BFE, Contour, Kuma, Service Mesh Interface, Chaos Mesh, Open Service Mesh, Emissary, k8gb, Service Mesh Performance, Submariner, Cilium, Meshery, Fab Edge, Istio, Nighthawk, Aeraki, and FabEdge. The vastness can be daunting.
Come learn about the big picture in Cloud Native Networking in the CNCF from basic L3 Connectivity up to the latest in Service Mesh and how to put it all in a context you can use.
A
A
A
So
when
you
look
at
the
state
of
the
cloud
native
networking,
Cloud
native
as
a
secular
movement,
has
largely
been
about
dropping
the
representations
of
the
physical
world
that
we
all
dealt
with
in
Cloud
1.0
right.
So
we
no
longer
build
virtual
interfaces
and
virtual
routers
and
virtual
load.
You
know
everything
we're
no
longer
reconstructing
the
physical
artifacts,
just
slapping
a
v
in
front
of
them.
A
Okay,
all
right,
so
some
of
you
are
just
pulling
my
leg.
I
see
that
no
I
don't
expect
this
to
be
clear
for
anyone.
This
is
a
giant
collection
of
logos
of
projects
in
the
cloud
native
networking
space
as
an
amorphous
jumble.
You
should
be
confused
by
this,
but
confusion
is
actually
not
something
you're
seeking
in
a
cloud
native
environment.
What
are
the
central
maxims
of
cloud
native
is
minimal,
toil
and
minimal.
Toil
is
not
just
the
amount
of
work
that
you
have
to
do
to
get
what
you
want.
A
A
A
And
so,
when
you
look
at
this,
you
step
back
okay,
so
we
we
start
with
workloads
and
then
we
sort
of
step
back
to
kubernetes
clusters.
This
is
probably
the
thing
that
you're
most
familiar
with,
and
this
is
where
we
can
meet
sort
of
the
first
project
in
our
collection
here,
which
is
cni
and
cni,
is
the
S,
the
SPI
that
plugins
must
meet
in
order
to
provide
networking
to
a
kubernetes
cluster.
Now
it
turns
out
that
there
are
some
interesting
things
about
cni
that
are
not
true
of
the
it's.
A
It's
close
Brethren
like
CSI,
the
container
storage
interface
or
CRI.
The
container
runtime
interface,
so
I
can
have
multiple
CSI
interfaces.
Css
CSI
providers
in
the
same
cluster
I
could
have
multiple
CRI
providers
in
the
same
cluster
and
sort
of
attach
these
things
based
upon
what
workloads
and
what
things
I'm
attaching
to
storage.
But
I
can
only
have
one
cni
interface
in
my
cluster.
A
A
A
A
A
So
the
first
thing
that
you
get
from
cni
in
your
intra
cluster
networking
is
every
pod
can
reach
every
other
pod
via
L3
VIP
without
not,
and
if
any
of
you
have
ever
suffered
through
trying
to
do
this
through
Nat.
You
understand
what
a
profoundly
wonderful
thing
this
is,
or
if
any
of
you
have
had
The
Misfortune
of
having
to
muck
around
with
subnets
or
all
kinds
of
other
things
that
involve
L2
structure
in
Cloud
environments.
It
usually
ends
up
being
a
lot
of
work
for
not
a
lot
of
payoff
for
most
purposes.
A
That's
sort
of
the
base
layer
of
what
you
get
in
for
cluster
networking
and
the
next
layer.
Up
that
you
get
is
isolation
and
isolation
in
kubernetes
is
typically
done
with
Network
policies
and
what
they
allow
you
to
do
is
to
specify
via
selection,
not
enumeration.
This
is
a
common
theme,
but
selection
based
upon
labels,
certain
pods
that
are
going
to
be
isolated.
No
one's
allowed
to
talk
to
them
unless
they're
selected
by
the
allow
list
for
the
particular
Network
policy
that
you're
dealing
with
now
there
are
some
other
things
about
Ingress
in
Ingress.
A
Ips
I
won't
go
into
here,
because
they're
a
little
bit,
but
that's
the
basic,
the
next
basic
layer
and
isolation
is
effectively
a
security
feature
within
the
networking
that
you're
dealing
with
and
then
the
final
one.
That's
actually
part
of
kubernetes
proper
is
services,
and
this
deals
with
service,
Discovery
and
routing
in
the
most
basic
sense.
A
Your
service
has
a
selector
that
allows
it
to
select
endpoints
that
can
provide
that
service,
and
so,
when
you
ask
for
that
thing
by
name,
you
actually
get
run
to
a
virtual
IP,
usually
by
not,
but
it
doesn't
have
to
be
that
way
so
that
you
can
actually
address
things
as
services
which
actually
brings
us
to
the
next
project.
We'll
mention
an
unsung
hero
of
kubernetes.
A
So
for
many
folks,
particularly
when
there
are
any
own
cluster
core
DNS
is
actually
providing
the
DNS
inside
that
cluster,
so
that
your
pods
have
DNS
names.
You
can
refer
to
so
that
your
services
have
DNS
names.
You
can
refer
to
quick
show
of
hands
how
many
folks
actually
enjoy
addressing
things
by
IP
address
directly
yeah.
Almost
no
one
does
it's
miserable.
A
And
that
brings
us
to
sort
of
the
next
piece
we've
been
talking
about
what
happens
inside
the
cluster.
There
are
a
few
things
in
kubernetes
that
involve
what
happens
at
the
edge
of
the
cluster
and
at
the
edge
of
the
cluster.
You
typically
have
load
balancers
and
Ingress
controllers,
and
we
have
a
few
of
the
projects
that
I
had
on
that
slide
here
in
the
cncf
that
actually
provide
these
so
KGB
and
BFE.
They
provide
load
balancers
that
you
might
select.
These
are
things
that
deal
with
traffic.
A
That's
coming
in
that's
being
treated
primarily
at
layer,
four
of
the
transport
layer,
so
they
take
incoming
TCP
or
UDP
streams.
They
load
balance
them
to
some
service
inside
your
cluster
and
then,
if
you
lift
this
up
to
layer,
seven
up
to
being
able
to
Route
things
on
HTTP,
you
typically
are
dealing
with
Ingress
controllers,
and
a
couple
of
examples
of
this
would
be
Contour
or
Emissary
Ingress.
A
Now
what
you'll
note
about
this
is
this
entire
model?
That's
kubernetes
Centric
is
highly
focused
on
a
cluster
and
that
will
come
up
again
later
because,
while
it's
wonderful
to
do
things
in
a
cluster,
how
many
folks
live
in
a
single
cluster
everything
they
do
lives
in
a
single
cluster,
yeah
I
thought
so
how
many
folks
live
in
a
single
cloud
provider
with
their
clusters?
Okay,
a
few
how
many
people
live
entirely
on-prem
with
their
clusters?
You
may
have
more
than
one
cluster
but
they're
entirely
on-prem.
Are
they
in
the
same
Data
Center?
A
Now
right
we
intrinsically
live
in
a
world,
that's
increasingly
hybrid
and
multi-cloud,
because,
quite
frankly,
you've
got
many
of
the
same
problems
across
data
centers
that
you
would
have
in
a
multi-cloud
environment
in
terms
of
setting
up
your
network.
If
you've
got
good
networking
people
they're
less,
but
even
even
so,
there
are
challenges.
A
Mostly
it
reasons
at
layer,
seven
https,
and
it
will
allow
you
to
do
more
sophisticated
things
with
service,
Discovery
and
routing.
You
could
have
selectors
that
are
more
than
just
on
labels
that
are
more
involved
in
terms
of
what's
Happening,
you
can
segregate
traffic
further
down
your
URLs,
it's
not
just
living
at
L4
with
TCP
ports.
A
It
gives
you
interesting
features
like
circuit
breakers
that
you
sort
of
decide
this
service
is
over.
This
thing
is
overwhelmed.
We
aren't
going
to
talk
to
it
for
a
while.
It
will
often
allow
you
to
offload
things
that
you
don't
necessarily
want
to
make
the
problem
of
your
application.
Authors
like
Mutual,
TLS
and
Identity,
or,
for
example,
also
things
like
injecting
tracing
spans,
there's
a
whole
host
of
features
that
people
bring
up,
but
mostly
at
layer
7.
A
You
know
otherwise
known
as
a
proxy
into
each
of
the
pods
that
are
participating,
and
then
they
are
controlled
from
a
central
controller
that
simply
pushes
down
rules
to
tell
them
how
to
route
the
traffic.
So
if
I'm
an
application
in
a
pod,
that's
using
service
mesh
I,
don't
actually
ever
really
talk
to
the
outside
world.
When
I
attempt
to
talk
to
the
outside
world
that
traffic
gets
hijacked
and
fed
through
the
proxy
running
the
Sidecar,
and
no
one
from
the
outside
world
ever
really
talks
to
me.
A
If
they
try
and
reach
me
that
gets
terminated
on
the
proxy
and
the
proxy
then
will
talk
to
me.
Having
done
whatever
munging
of
the
HTTP
messages
is
going
to
do
whatever
decisions
it's
going
to
make
about
whether
or
not
I
should
even
receive
it
or
where
it
should
go,
and
so
this
is
quite
different,
and
this
is
really.
A
Way
up
to
L7,
so
a
very
good
way
to
think
about.
It
is
to
think
about
yeah,
you're,
routing
and
switching
on
layer.
Seven,
because,
for
example,
if
I
DNS
resolved
the
domain
name,
that
I'm
talking
to
there's
no
reason
that,
intrinsically
that
the
IP
address
I
get
back,
has
any
relationship
to
where
that
HTTP
message
is
going,
because
it's
being
routed
on
the
HTTP
information,
not
on
the
IP
information,
no
but
effectively,
because
you're
terminating
on
your
local
proxy.
It
may
then
go
to
whatever
IP
address
it's
going
to.
A
So
you
get
you're
you're
a
great
straight
man
you're,
getting
to
some
of
the
stuff
we're
going
to
talk
about
later,
with
some
of
the
things
that
do
get
done.
That
are
interesting
about
providing
layer
threes,
because
part
of
why
this
is
very
simple,
with
service
meshes
is
because
you
already
have
the
guarantee
in
a
single
cluster.
That
kubernetes
gives
you
that
you're
riding
on
a
single
flat
layer,
three.
That
makes
it
much
more
tractable
as
a
problem.
A
A
A
A
Uh-Huh,
but
your
Calico
Calico
is
great
for
advertising
routes
to
your
local
network,
but
if
your
local
network
is
a
private
IP
space
and
you're
trying
to
reach
something,
that's
outside
of
that
private
ISP
space,
then
it
only
gets
you
as
far
as
the
Calico
advertisements
of
your
local
network
at
you.
So
you
can
absolutely
do
great
things
with
making
the
flat
IP
space
bigger
than
your
cluster.
A
A
A
You're,
a
great
straight
man,
you
you're
about
two
slides
ahead
of
me.
No
we'll
talk
about
envelope
here
in
a
second
awesome
perfect,
so
this
gets
us
to
a
whole
bunch
of
other
things
that
I
showed
you
on
that
big
eyesore
slide
at
the
beginning,
because
it
turns
out
there
are
a
lot
of
service
meshes.
In
fact,
there
are
quite
a
few
more
than
this
looks
like
because
the
fact
that
there
are
a
very
large
number
of
service
meshes
built
on
top
of
istio,
but
you,
you
sort
of
start
with
the
granddaddy
of
them
all.
A
A
It's
definitely
the
most
well
marketed
of
the
service
meshes.
So
it's
usually
the
one
that
folks
think
about
and
hear
about.
You
have
others
like
Kuma,
which
is
coming
out
of
the
Kong
folks.
They
have
a
lot
of
experience
with
API
gateways
and
how
to
string
things
together
between
different
zones,
open
service
mesh,
which
is
another
approach
to
service
mesh
and
curamesh
as
well
and
they're
even
more
than
this.
This
is
just
sort
of
the
ones
that
are
most
closely
aligned
with
the
cncf.
It's
a
very
busy
space.
A
But
then
we've
got
things
that
are
server
special
adjacent
in
the
ecosystem,
so
you've
got
things
like
SMI,
which
was
an
attempt
to
come
up
with
a
generic
interface
that
you
could
use
across
multiple
service
meshes
so
that
you
could
address
an
API
that
was
common
I've,
seen
lots
of
places
where
people
will
come
into
projects
that
are
built
on
top
of
a
service
mesh
and
they
would
like
to
use
a
different
service
mesh
under
the
covers.
If
the
project
is
consuming
a
service
mesh
via
SMI.
A
That's
a
conceivable
thing:
if
it's
consuming
for
Via
a
bespoke
API,
that's
a
big
lift,
then
you
get
things
like
measuring.
So
it
turns
out
that
when
you
have
service
meshes,
you've
got
the
the
data
plane,
which
is
the
sidecars.
The
L7
proxies
and
you've
got
the
control
playing,
which
is
the
thing
that
takes
your
intent
and
translates
it
into
the
things
that
get
pushed
down
to
those
data
planes.
A
You
can
think
of
it
as
pushing
the
routes
out
if
you
will,
but
the
world
gets
to
be
even
more
complicated
on
top
of
this,
and
so
you
will
often
write
up
with
what
people
call
a
management
plane
on
top
of
service
meshes
meshery
is
a
multi-management
plane.
It
will
actually
give
you
a
management
plan
across
many
different
service
meshes,
so
you
can
get
a
consistent
management
plane
experience
and
it
has
an
entire
library
of
service
mesh
patterns
that
you
may
wish
to
deploy
and
templating
that
actually
eases
the
deployment
of
them.
A
So
you
can
think
of
it
as
up
leveling.
Some
of
the
things
that
you
might
want
to
do
with
service
meshes
related
to
that.
You've
also
got
things
like
s
p,
which
is
the
service
mesh
performance
platform
meshery
as
part
of
the
work
that
it
does
actually
has
a
whole
battery
of
performance
tests
that
it
can
run
that
are
compliant
with
s
p.
A
So
if
you're
wondering
for
your
particular
use
pattern
is
service
mesh,
a
or
service
mesh
B
going
to
give
you
the
performance
you
need
or
going
to
perform
better
or
consume
fewer
resources
measure
where
you
can
help.
You
understand
that
problem
and
then
Nighthawk,
which
is
a
distributed
service,
mesh
testing
tool
you
can
sort
of
think
of
as
a
distributed
packet
Blaster
of
some
sort
of
you,
if
you,
if
you
will
or
sort
of
a
much
more
sophisticated
approach
to
iperf,
do
folks
have
questions
on
these
so
far
because
we're
about
to
leave
yes.
A
A
A
A
So
Envoy
is
the
all-singing,
all
dancing
HTTP
proxy
of
Doom.
It
just
kicks
ass.
In
fact,
he
kicked
so
much
ass
that
it
is
in
fact
the
proxy
that
is
used
in
the
sidecar
for
istio
Kuma
Akira
mesh,
open
service
mesh
and
for
the
Ingress
side
it's
used
for
the
L7
Ingress
for
Emissary,
Ingress
and
contour,
and
it
also
gets
used
in
a
whole
bunch
of
places.
You
would
use
L7
proxies
that
have
nothing
to
do
with
Cloud
native
networking.
It
does
all
kinds
of
cool
things.
It
has
a
very
nice
plug-in
model.
A
A
A
How
is
Envoy
connected
to
the
cni?
Well,
so
it
there
are
two
ways
of
looking
at
this.
You
have
some
service
meshes
that
will
have
a
cni
plug-in
that
will
inject
the
envoys
an
Envoy
Sidecar,
but
in
that
sense
it's
just
setting
the
envoy
up.
Envoy
doesn't
really
understand
that
it's
running
in
kubernetes
per
se.
A
It
understands
that
somebody
connected
to
it
who's
authorized
to
do
so
and
told
it
that
when
it,
it
should
listen
for
incoming
HTTP
messages
on
a
couple
of
ports
and
when
they
come
in
it
should
treat
them
in
particular
ways
and
that's
more
or
less
all
it
knows
about
the
world,
which
is
actually
just
good
modularity.
If
Envoy
had
to
know
deep
things
about
cni
plugins
it
would,
it
would
not
be
nearly
as
handy
cool.
A
So
then
we
get
to
sort
of
the
questions,
some
of
the
questions
about
cluster
to
Cluster
and
L3.
So
we
had
some
folks
who
had
mentioned
that
you
do
have
situations
if
you
control
a
larger
blob
of
networking
where
certain
cni
plugins
like
Calico,
will
let
you
advertise
into
that.
But
for
many
people
like
quick,
quick
show
of
hands
how
many
of
you
are
using
public
IP
addresses
in
your
data
centers
for
every
single
pod.
A
A
So
one
approach
to
do
that
is
with
a
project
called
Submariner
or
Submariner.
I,
always
get
that
confused
and
with
new
Marvel
movies.
Coming
up
I
keep
wanting
to
say:
Submariner
I
call
it
cluster
to
Cluster
networking.
It
basically
strings
a
tunnel
from
a
router
in
each
cluster
to
each
other
cluster.
If
it
has
to
it
will
provide
Nat
for
you
and
it
gives
you
the
ability
to
export
services
from
a
cluster
to
the
group
and
to
import
them
from
a
cluster.
A
From
the
group
so
I
could
have
a
service
in
cluster
one
and
I
could
consume
it
in
cluster
two,
it's
kind
of
trying
to
find
a
way
to
Federate
in
some
sense
between
clusters,
but
because
there
are
scalability
issues
with
Federation
and
the
generic
it's
trying
to
take
a
more
intelligent
approach
to
that.
But
at
the
end
of
the
day,
it's
reasoning
at
the
level
of
clusters
and
services,
not
at
the
level
of
giving
sort
of
end-to-end
connectivity
and
not
at
the
level
of
individual
workloads.
A
That's
exactly
how
I
think
of
it
as
a
legacy:
networking
guy,
no
you're
thinking
about
it
exactly
the
right
way.
So
one
of
the
fun
things
about
these
conversations
by
the
way
you
know
Cloud
Network
people,
Cloud
native
people,
who
often
don't
even
want
to
know
that
IP
addresses
exist.
And
then
you
have
people
who
are
deeper
on
the
networking
side
who
are
trying
to
reconcile
it
with
what
they
know
and
understand
and
for
networking
people.
We
talk
about
east
west
traffic,
all
the
time
so
think
of
it
as
East-West
traffic
between
clusters.
A
A
It
does
handle
natting
I
am
not
as
familiar
with
the
ins
and
outs
of
it,
but
my
suspicion-
and
this
is
again
based
upon
how
I
know,
networks,
work
and
the
available
possible
state
of
solutions
is
it's
primarily
in
the
business
of
exporting
and
importing
services
so
and
a
service
that
have
been
exported
from
one
cluster
to
another
cluster.
If
I
were
doing
it,
I
would
be
using
Nat
to
export
a
VIP
into
the
second
cluster,
and
so
it
doesn't
really
matter
that
I'm
nodding.
A
Psyllium
so
psyllium
keeps
moving
across
things.
Primarily
psyllium
is
a
is
a
cni
plug-in
they've.
The
iso
valent
folks
have
recently
also
started
playing
in
service
mesh
I,
don't
know
if
they
are
branding
their
service.
Mesh
efforts
under
the
psyllium
moniker
as
well,
but
psyllium
tends
to
be
a
cni
plug-in
and
they
have
done
a
huge
number
of
interesting
experimental
things
with
ebpf
over
time.
A
But
structurally,
you
know
it's
in
a
similar
vein.
It's
just
a
question
of
what
the
underlying
tool
you're
using
is
so
Calico,
for
example,
does
some
very
cool
L3
things,
but
it's
fundamentally
just
using
enter.
You
know:
V
interface
pairs
on
the
box,
psyllium
would
shove
different
kinds
of
things
into
ebpf
programs.
So
it's
more
of
a
data
playing
difference
than
a
structural
difference.
A
Yeah
I
I
have
not
looked
as
closely
at
that,
but
that
doesn't
mesh
with
my
understanding
of
the
limitations
of
what
you
can
manage
in
ebpf
and
the
few
explanations
I've
heard
involve
various
programs
manipulating
things
in
user
space
and
once
you've
got
a
programming
user
space.
That's
manipulating
things.
You
have
a
sidecar,
it's
just
parts
of
your
sidecar
you're
shoving
off
to
the
kernel
for
processing,
so
I
mean
I.
I
know
the
marketing
I
haven't
been
able
to
square
it.
With
my
understanding
of
reality,
doesn't
mean
it's
not
true.
A
A
A
All
right
this
brings
us
to
the
last
one
on
our
list:
network
service
mesh,
so
network
service,
mesh
sort
of
thinks
quite
a
bit
differently
about
all
this,
because
you'll
notice
that
almost
everything
that
we've
talked
about
so
far
is
welded
pretty
tightly
to
your
cluster.
Remember
how
I
said
at
the
beginning
that
in
your
cluster
you
get
exactly
one
cni
plugin,
which
means:
if
I
want
the
bgp
goodness
of
calico,
then
I
can
choose
Calico,
but
that
means
I,
then
can't
fall
back
and
choose
some
other
cni.
A
That
gives
me
some
other
piece
that
I
want
effectively
within
your
cluster.
If
you're
a
pod
and
you're
talking
about
everything,
we've
talked
about
so
far,
you
get
exactly
one
flavor
of
networking.
It's
the
one
that
comes
with
your
cluster
and
you
can
twist
some
knobs
on
it
for
isolation
like
Network
policies
and
services,
and
maybe
you
can
run
something
like
a
service
mesh
on
top
but
everybody's,
getting
the
same
thing
sort
of
going
to
the
Henry
Ford
joke
you
could
have
whatever
color
car
you
want.
A
A
So
why
are
we
tightly
coupling
our
networking
to
our
runtime?
That
seems
awfully
weird.
So
what
network
service
mesh
basically
does?
Is
it
looks
at
the
situation?
It
says,
look
leave
cni
alone,
whoever
decided
what
cni
to
run.
They
had
a
reason.
We
don't
need
to
know
what
that
reason
is,
and
you
don't
want
to
break
how
clusters
work
intra
cluster
but
allow
individual
pods
individual
workloads
to
ask
for
by
name
zero
or
more
additional
Network
Services.
A
So,
for
example,
here
we
have
an
example
where
we've
got
a
network
service
at
the
top
that
we
call
a
database
replication
domain
right
picture,
a
case
where
I
have
a
giant
Oracle
database,
on-prem
I'd
like
to
keep
read
replicas
in
my
clusters:
they're
not
doing
anything,
fancy
of
HTTP
you're,
probably
using
one
of
oracle's
protocols
like
TNS.
It
needs
basic
L3
connectivity,
maybe
a
little
bit
of
DNS.
A
You
know
I
may
want
to
stick
something
Security
in
there.
That's
bespoke
to
what
I'm
doing
in
that
regard,
but
I
I
want
a
very
specific
network
service
for
those
participants.
Network
service
mesh
will
let
the
individual
pods
in
different
clusters
running
in
different
clouds
in
different
Cloud
providers
and
on-prem
connect
to
this
logical
network
service,
as
well
as
allowing
bare
metal
servers
and
VMS,
and
so
you
can
get
this
fine-grained
segmentation
of
what
kind
of
treatment
you
need
for
your
workload.
A
You
get
the
networking
you
need
for
the
thing
that
you're
doing
not
the
networking
you
inherit
from
your
cluster
infrastructure's
choices
and
as
it
sort
of
shows
here
below
you
see
one
below
that
talks
about
an
istio
network
service
picture
that
as
another
flat
private
VPN.
We
call
them
vl3s
with
a
single
istio
instance
running
on
top
of
it.
So
you
no
longer
have
a
crazy
quilt
of
L7
gateways
with
all
the
debugability
problems,
latency
Etc,
that
introduces
from
the
point
of
view
of
the
SEO
control
plane,
it's
a
flat,
IP
space.
A
A
So
how
many
of
you
know
what
an
sriov
VF
is
virtual
function,
pretty
good,
so
I
maintain
that
literally
no
one
and
I
mean
literally
no
one
and
I'll
prove
it
to
you
once
an
SRI
of
evf.
So
how
many
of
you
don't
believe
me
excellent
I,
love,
doubters,
here's
why
I
maintain
that?
What
you
want
is
a
network
service
from
your
physical
Network
and
if
I
could
give
you
a
technology,
I
call
donkey
on
that
gave
you
twice
as
much
throughput.
You
would
drop
SRI
ovf
in
a
heartbeat.
Is
that
true?
A
A
That
has
the
capabilities
you
want,
like
100,
Gig,
10,
gig,
Etc
right
and
it
handles
it
dynamically.
So
you
don't
have
to
statically
provision
these
at
no
time
you
can
get
this
dynamically
as
people's
needs
as
the
needs
changes
across
the
system.
Apologies
to
the
non-networking
Geeks
in
the
room.
We
I
think
we've
probably
concluded
that
portion
of
this.
Unless
there
are
questions,
do
we
have
questions.
A
A
And
there
are
a
certain
set
of
low
latency
cases
that
I
could
see
in
certain
Enterprises
spaces,
which
would
also
need
it,
because,
when
you're
sweating
microseconds
every
bit
counts
so
most
people?
No,
you
don't
need
it,
but
you
also
don't
get
it.
No,
your
network
service
mesh,
unless
the
thing
you
ask
for
so
I
just
wandered
off
a
little
bit
into
there
are
some
new
Strokes
that
were
suspicious
were
in
the
room,
wanted
to
make
sure
they
understood
what
was
possible.
Other
questions.
A
A
I
believe
not
at
all,
except
potentially
with
some
of
the
things
like
the
egress
stuff
and
part
of
it,
is
that
Network
policy.
Primarily,
if
you
put
aside
the
IP
base,
Ingress
and
egress
IPS
Network
policy
is
about
telling
you
which
pods
are
isolated
from
each
other
and
then
you
get
services
that
actually
sort
of
often
will
go
past.
A
A
A
Oh,
no
you're,
absolutely
right!
So
let
me
let
me
back
up
a
few
pieces.
One
of
the
things
I
didn't
go
into
because
of
time
limitations
is
the
fact
that
there
are
things
like
spiffy
that
entry
that
will
give
cryptographically
verifiable
identities
to
your
workloads.
Now
network
service
mesh
primarily
operates
at
layer
three,
so
it's
actually
arranging
a
virtual
wire
for
you,
not
an
mtls
tunnel.
A
It
just
so
happens
if
you
have
sidecars
as
part
of
your
network
service,
which
we
have
some
examples
that
do
that,
then
you
would
have
an
Envoy
and
we're
still
using
spiffy
ID's
end-to-end
for
the
entire
system
for
both
the
L3
and
the
L7.
So
you
actually
get
visibility
for
the
same
ID.
All
the
way
through
the
system
for
all
three
up.
A
A
So
I'm
not
as
familiar
with
how
with
things
games,
people
may
be
playing
with
cnis
and
dpus
from
network
service
mesh's
point
of
view.
Your
dpu
is
just
providing
a
network
service,
and
so
your
your
workload
doesn't
have
to
be
any
wiser.
It
gets
handled
in
the
plumbing
and
Away
you
go
and
it
turns
out.
If
you
look
at
a
lot
of
dpus.
A
Many
do
folks
know
what
a
TPU
is:
data
processing
unit,
many
of
them
actually,
when
you
drill
into
them,
are
little
tiny
servers
in
a
nick,
and
many
of
them
will
run
something
that
looks
a
lot
like
I
mean
there
are
some
that
burning,
okay,
I'm
being
told
to
stop
I'm
perfectly
delighted
to
talk
with
folks
after
this
you've
been
a
wonderful
audience.
Thank
you
for
all
the
questions
and
interaction.