►
From YouTube: CNF WG Meeting 2021-04-19
Description
CNF WG Meeting 2021-04-19
A
A
A
B
A
All
right,
it's
five
after
posted
the
meeting
notes
again
and
the
zoom
chat.
Please
add
your
name
and
any
agenda
topic
that
you'd
like
to
discuss
right
now.
It's
kind
of
blank
unless
we
get
into
the
pull
requests,
which
is
fine
and
we've
been
trying
to
leave
it
open
to
have
some
more
discussions
on
use
cases
or
anything
other
topic
that
someone
had
so
is
there
any
walk-in
topics
before
we
jump
into
any
of
the
pull
requests
or
anything.
C
Else,
can
I
ask
a
question,
maybe
about
the
agenda?
Does
it
look
like
we've
really
covered
all
the
all
the
bureaucratic
issues
with
voting
and
everything
I
kind
of
wanted
wanted
to
leave
the
agenda
open
to
to
finish
all
that
stuff,
so
we
can
dig
deeper.
A
A
And
then
we
can
cover
those
if
the
the
governance
items
that
are
currently
open
towards
the
end.
That's
how
we
put
it
in
here
because
they
were
taking
up
so
much
time
ever
every
time
and
some
of
them
needed
a
lot
more
discussion
so
rather
than
rush
them,
we
were
allowing
them
to
be
at
the
end,
but
those
are
there
and
if,
if
we
don't
have
anything
else
discussed,
then
we
can
get
into
this.
C
Okay,
I
think
I'm
not
quite
ready
today,
but
I
will
try
for
next
week,
maybe
to
create
an
agenda
item
that
can
move
us
forward.
A
bit
on
the
networking.
Orchestration
front
sounds
good.
A
Yeah
and
if
there's
any
specific
part
of
that
that
can
be
talked
about,
if
you're
not
ready
with
a
whole
lot
of
the
pieces,
then
we
can
focus
on
one
particular
area.
I
know
when
we
had
our
call
breaking
it
down.
There
was
a
lot
of
different
topics
that
could
be
discussed.
D
So
I
was
actually
kind
of
hoping
we
I
mean
we
don't
have
to
specifically
get
into
the
nuts
and
bolts
of
orchestration
itself,
but
like
I'd
like
to
I'd
like
at
least
half
of
this
call
to
not
be
about
bureaucracy
if
possible.
I'd
like
to
discuss
voke's
use
case
he's
not
on
yet,
though,
so
maybe
we
do
that
one.
Second
personally,
I
think
he's
got
multiple
use
cases
wrapped
up
into
his
first
pr
and
kind
of
like
to
discuss
as
a
group
on
like.
D
Maybe
we
spawn
other
use
cases
out
of
it.
There's
the
concept
of,
like
you,
know,
immutable
infrastructure
in
life
cycle
management
of
infrastructure,
which
I
think
is
the
core
of
his
use
case
and
then
like
what
we
think.
That
means
from
a
cnf
standpoint,
but
then
he's
got
things
around
testing
in
there
he's
got
some
devopsy
stuff
in
there
about
like
what
does
it
mean
between
the
different
actors
we
identified
at
the
beginning,
and
in
addition
to
that,
I
see
a
locus
on
here.
D
We've
got
tal
nikolai
some
other,
like
network
savvy
people.
I'd
like
to
talk
about
that
discussion,
and
maybe
this
kind
of
would
lead
into
what
your
follow-up
agenda
item
is
next
week,
tal
around
external
network
orchestration.
D
I
I
think,
like
just
reading
through
the
comments,
some
of
my
comments
and
stuff
like
there
is
a
lot
of
assumptions
that
I
think
all
of
us
make,
and
I
don't
think
we
tend
to
make
the
same
assumptions
all
the
time.
Unlike
what
an
existing
network
is,
you
know,
do
I
require
an
l2
domain
for
something
like
there's
just
all
these
things
where
I
feel
like
it'd
be
loud
talk
through
some
of
the
points
in
there,
so
that
way
we
can
kind
of
in
our
minds
collectively
kind
of
get
engaged.
C
So
I
added
a
link
in
the
chat
to
that
to
that
discussion
because
I
imagine
not
everybody
was
following
it.
So
there's
a
lot
there
yeah
I'm
kind
of
off
the
cuff
here,
but
yeah,
if
jeffrey.
If
you
want
to
present
it
in
some
way
that
we
can
discuss
it,
I
think
that
could
be
good.
D
D
A
I'm
happy
to
go
into
whatever
everyone's
wanting
to
discuss
and
I
agree
with
you
on
on
having
a
smaller
focus
on
the
governance
items.
So
we
have
those
at
the
end.
If
we
get
to
them
great
and
if
we
don't
today,
then
that's
okay,.
D
Cool
okay,
so
yeah
for
general
context,
eloque
put
up
a
wisconsin.
You
know
this
potential
use
case
for
kubernetes
external
network
orchestration.
He
goes
into
some
specifics
on,
like
some
of
the
things
that
he's
looking
for.
There's
talks
about
how
we
attach
network
interfaces
geargate
goes
into
some
of
the
encapsulation
techniques.
We
start
talking
about
dynamic
network
management.
D
Just
to
start,
though
I
want
to
just
pose
a
question:
is:
should
kate's
be
orchestrating
networks
external
to
itself,
and
so
for
some
clarity
and
I'm
not
like
putting
an
opinion
here.
I
just
want
us
to
think
about
this
right
because
we
start
talking
about
network
attachments,
in
fact
tal.
I
think
you're,
the
one
who
covers
that
somewhere
down
here
in
the
comments,
but
like
there's
the
overlay
networking
case
that
we
all
know.
We
all
know
that
we
have
to
deal
with
a
single
interface
with
pods.
D
We
know
that
we
have
to
deal
with.
You
know
natting
out
of
now
taking
on
the
source
ip
of
the
host.
That's
you
know
hosting
the
pods,
there's
like
all
these
quirks
right
and
then
there's
this
concept
of
like
the
network
that
sits
outside
of
that
overlay
that
we're
attaching
to
can
I
attach
to
multiple
networks.
So
just
first
question
I'd
like
to
like
propose
and
maybe
there's
multiple
answers
is
like
what
is
the
thought
on
like
should
kate's
be
continuing
to
take
on
more
and
more
and
more
with
things.
You
know.
D
B
Speaking
short,
I
came
with
a
little
bit
delay,
that's
actually
very
interesting
topic
and
I
I
feel
it's
something
we
need
to
explore.
But
on
the
other
side
it
reminds
me
actually
on
on
a
two
attempts
in
the
similar
direction
that
are
attempted
to
to
to
be
done
on
the
cni
level.
So
we
have
a
tungsten
fabric
or
this
juniper's
cni,
and
we
have
a
cisco,
aci
cni
which
actually
take
a
roll
of
something
that
speaks
to
an
sdn
layer
and
then
in
a
in
a
way
orchestrating
the
network.
B
But
here
I
think
jeffrey
you
are
talking
about
capability
outside
of
the
of
the
cni,
or
did
I
get
it
right
or
wrong.
D
No,
I
mean
you're
you're,
definitely
on
the
right
track
like
same
thing
with,
like
you
know
the
neutron,
plug-ins
and
stuff
right
like
I
can
get
like
this.
Really,
you
know
nifty
coupling
between
whatever
my
sdn
abstraction
is.
But
my
question
you
know
then,
like
you
said,
I'm
I'm
just
playing
devil's
advocate,
posing
questions
to
kind
of
what
the
group
thinks
is
like.
If
I
want
to
run
bare
metal,
you
know
what
does
that
look
like
do?
D
C
Maybe
that
I'll
try
maybe
to
break
down
a
three
aspect.
Well
I'll
limit
it
to
two
not
to
take
too
much
time
but
trying
to
understand
what
is
external?
Really,
I
think
that's
one
of
those
assumptions,
jeffrey
that
you
mentioned
that
people
make
what
is
external
and
what
is
internal
to
to
the
cnf
right.
Where,
where
is
that
line
drawn
exactly
a
lot
of
times?
You
know
to
deploy
something
you
do
need
to
configure.
For
example,
a
data
center
switch
like
a
top
of
the
rack,
switch
that's
sitting
there.
C
So
is
that
really
external
or
you
can
think
of
it
as
a
shared,
a
resource?
The
other
thing
you
know
jeffrey
you're
talking
about,
should
kubernetes
orchestrate
it
well.
C
What
is
kubernetes
here
right,
because
if
we're
talking
about
the
workload
running
on
kubernetes
right,
if
you're
running,
say
in
a
kubernetes
operator
or
some
kind
of
controller
or
something
else
that
will
say
talk
to
the
switch
or
talk
to
an
sdn
controller-
or
you
know
talk
to
a
network
acceleration
switch
sitting
inside
the
hardware
right
are
those
really
external
and
you
know
which
parts
of
kubernetes
will
really
do
that.
So
I
think,
rather
than
talking
about,
should
kubernetes
do
that
we
should
say:
should
the
network
function
do
that?
C
E
I
I
think
kubernetes
role
in
this
is
very
is
very
clearance
specific.
It
farms
it
out
to
cni
and
it
doesn't
as
long
as
you
give
it
an
ip
address.
It
doesn't
really
care
what
you
do
and
there
are
mechanisms
in
place
that
we
can
that
we
can
control
or
modify
the
pod,
but
in
general,
kubernetes
is
very
unopinionated
about
this
particular
space.
C
Okay,
but
here's
here's
where
it
gets
complicated
because
the
cni
plug-in
you
can
say:
okay,
that's
out
of
my
domain,
it
just
runs,
but
what,
if
your
workload
needs
to
interact
with
that
plug-in
right,
if
that
plug-in
is,
is
what
we
sometimes
call
a
thick
plug-in.
That
is
it's
a
service.
That's
actually
running
and
doing
things
you,
your
workload
might
have
to
have
something
to
do
with
that
configuration,
and
I
I
extended.
F
F
E
Yeah
and
and
that
that's
not
the
same
from
an
orchestrator,
it's
clear
that
the
or
that
something
has
to
orchestrate
this
is
in
this
scenario.
I
should
that
be
kubernetes.
I
don't
think
it
should
be,
but
it
should
interact
with
kubernetes
in
in
in
a
clearer
way.
Is
is
what
I'm
trying
to
say
like
but
saying
kubernetes
itself
as
the
as
the
orchestrator
should
be
the
thing
there.
There
needs
to
be
something
that
does
orchestrated,
but
it
probably
should
not
be
kubernetes
itself,
because
kubernetes
is
very
unopinionated
about
about
this
kind
of
work.
F
Don't
think
you
want
the
cnf
itself
doing
it
either,
because
the
goal
should
be
to
only
have
one
thing
actually
making
configuration
changes
on
those
on
those
switches,
for
example
right
and
if
you
allow
the
cnf
to
make
changes
in
the
switch,
and
you
have
a
northbound
orchestrator
making
changes
in
the
switch
because
of
physical
changes
in
the
topology
of
the
network.
You
now
have
too
many
actors
making
changes
to
the
same
resource
right.
The
goal
should
be
to
have
one
actor:
making
changes
to
a
resource,
not
multiples.
F
E
It
has
to
provide
metadata
such
as
what
is
my
payload
like
payload
could
be
ethernet
ip
vxlan
or
something
else,
and
what
is
my
mechanism
to
actually
communicate
with
the
outside
world,
where
the
mechanism
could
be
kernel,
interface,
vfio,
memif,
something
else,
and
so
what
you
do
is
you
provide
enough
information
to
the
orchestrator,
so
you
so
it
understands
and
says:
oh
I
need
to
wire
you
up.
It
helps
it
helps
with
like
you,
don't
want
to
pair
up
an
ip
with
an
ethernet
as
an
example,
because
then
there's
a
mismatch.
E
You
don't
want
to
pair
up
a
vfio
user
plane
with
a
memif
or
sorry
gfio
client,
with
a
with
a
memif
server
or
receiver.
Because
then
you
know
it's
not
going
to
work.
So
you
have
this.
It
gives
you
that
new
york's,
the
orchestrator,
the
thing
that's
actually
doing
the
orchestration,
whether
it's
an
sdn
or
something
else,
the
capability
to
to
check
across
all
of
these
particular
paths.
So
they're
clear.
D
Say
so
well,
it
depends,
though,
a
little
bit
right
like
yeah.
That's
just
that's
one
of
the
things
I
think
so
a
couple
of
things
for
one
operators,
that's
an
implementation
to
get
functionality
right,
so
I'd
like
I'd
like
us
to
first
continue
to
like
identify
our
challenges
here.
D
Right
like
I
would
propose-
and
I'm
actually
going
to
stitch-
invokes
use
case
here
right
book
use
case
is
the
concept
of
operational
life
cycle
management
of
the
infrastructure
right
when
we
we
always
get
right
into
like
the
low-level
plumbing
of
like
how
am
I
you
know
getting
these
two
pods
to
talk
to
each
other.
Is
it
mimiff?
D
Is
you
know,
there's
some
kind
of
kernel
interface
involved
this
and
that,
but
you
know
I
would
just
pose
that,
like
if
you're
dealing
with
like
cloud
native
infrastructure
in
addition
to
cloud
native
workloads,
then
the
assumption
is
is,
and
actually
let
me
bring
that
up.
Real.
Quick,
too,
is
this
concept
of
you
know.
The
infrastructure
itself
has
a
say.
D
Like
am
I
in
my
yeah,
go
ahead,
as
I
say,
this
was
so
like.
The
final
point
on
this
right
is,
if
I
have
some
type
of
you
know,
pipeline,
that's
involved
for
like
building
out
these
this
infrastructure
right,
like
I'm,
using
things
like
node
labels,
I'm
using
you
know
specialty
compute,
for
where
it
makes
sense.
I
mean,
because
do
I
put
an
fpga
in
every
single
like
compute
node,
I
don't
know,
maybe
the
cost
eventually
gets
to
that
point
or
do
I
use
you
know
concepts
like
availability
zones,
labels,
tags,
etc.
D
So
I
mean
they
said
we
always
come
in
with
these
assumptions,
and
I
would
you
know
propose,
like
I
like
tells.
You
know,
comment
that
it's
a
shared
network
potentially
or
whatever,
because
like
a
lot
of
times,
this
infrastructure
already
exists
and,
like
I
can
tell
you
from
personal
experience,
some
of
the
challenges
I
have
is:
okay,
we're
going
to
bring
kate's
in
and
now
kate
wants
to
control
the
world
versus
you
know,
kate's,
providing
an
interface
for
managing
containers,
pods,
etc.
D
You
know
what
would
the
cnf
interface
look
like,
like
with
the
assumption
that
I'm
not
just
handing
over
all
of
my
infrastructure,
because
I
would
say
that
if
we
just
like
hand
control
to
the
cnf
or
case
itself,
then
at
that
point
I'm
building
an
appliance
which
then
we
could
argue
and
debate
and
maybe
write
a
best.
You
know
practice,
that's
saying
an
appliance-based
approach
is
the
right
approach.
D
I
don't
know,
but
like
the
moment,
you
just
start
handing
everything
over
and
pulling
control
as
shane
was
talking
about
from
like
these
other
domain
controllers
that
are
specific
to
infrastructure
that
are
in
doing.
We
start
either
having
a
multiple
master
scenario
where
things
get
lost.
We
have
state
drift
or
we
start
building
purpose-built
appliances,
and
you
know
those
are
the
types
of
things
I
think
we
should
be
considering
when
we
start
like
talking
about
how
we
would
tackle
this
use
case
that
you
put
in
discussions
and
for
some.
E
Yeah-
and
I
think
the
the
framework
that
we
should
aim
for
from
best
practices
is
something
that
should
be
flexible
in
that
respect,
and
it
it
acknowledges
ideally,
would
acknowledge
that
kubernetes
is
very
good
at
a
very
specific
thing,
which
is
it's
good
at
orchestrating,
where
pods
should
should
run,
if
it's
good
at
monitoring
them,
restarting
them
canary
upgrades
and
so
on,
which
provide
a
tremendous
amount
of
functionality.
E
E
But
when
you
compare
it
to
the
long
tail
of
kubernetes,
we're
we're
a
small
fish
in
the
in
the
pond
and
they're
not
going
to
want
to
complicate
kubernetes
to
cover
our
use
cases
when
the
common
use
case
of
kubernetes
is
a
small
to
medium-sized
cluster
with
very
simple
patterns,
and
so
we
need
to
be
a
little
bit
careful
there.
We
have
room
to
play,
but
we
we
need
to
have.
E
We
need
to
make
sure
that
we
are
not
over
complicating
the
enterprise
side,
while
we
do
this,
because
otherwise
we'll
get
a
tremendous
quantity
of
pushback
and
not
get
through
the
things
that
we
that
we
need
when,
when
there
is
a
gap
that
kubernetes
seriously
doesn't
need
to
to
resolve.
So
we
want
to
be
careful
on
what
type
of
things
that
we
we
bubble
up,
as
as
as
that
process,
which
the
mindset
that
we
take
into
this
will
will
matter
a
lot.
A
Another
way
to
or
to
add
on
to
that
frederick
is
if
we
can
break
down
use
cases
and
find
areas
that
are
most
aligned
with
the
path
that
kubernetes
is
already
on.
Then
it's
more
likely
those
will
be
adopted
and
if
we
can
get
momentum
with
that,
then
you're
going
to
have
more
people
from
the
different
communities
looking
and
understanding
what's
going
on,
and
then
I
think
we
can
get
more
adoption
across.
E
And
here's
here's
a
question:
if,
if
I
were
to
implement
some
form
of
controller
or
orchestrator
that
interacts
with
a
cnf
and
or
rather
interacts
with
that
with
some
data
plane,
something
that
sits
on
the
data
plane.
So
this
thing,
let's
say
it's
a
database,
so
very
often
we
have
obs
dbe
or
similar,
but
at
the
end
of
the
day
I
would
argue
that
those
are
applications
which
their
applications
in
in
kubernetes.
E
So
there's
there's
not
a
huge
difference
between
something
like
ovsdb
versus
something
like
postgres
when
from
the
concept
of
kubernetes
itself,
and
that
there's
no
special
types
of
network
links
you
need
to
put
in
that.
Kubernetes
cannot
handle
today
as
part
of
its
as
part
of
its
path
and
so
there's.
E
I
think
we
we
also
need
to
to
highlight
some
of
the
best
practices
around.
That
space
is
like.
When
is
something
just
an
application,
and
yes,
it
may
be
part
of
a
of
a
cnf
or
maybe
part
of
a
it
may
be
composed
with
with
things
that
touch
the
data
plane.
But
at
the
same
time
is
there
is
there
anything
missing?
E
But
then,
when
you
start
looking
at
things
like
how
do
I
actually
touch
the
data
plane
and
do
bump
in
the
wire
firewall
or
set
up
a
5g
packet
core
or
similar,
then
what
are
the
best
practices
when
you
start
to
get
patterns
that
look
like
that
for
things
that
actually
have
to
touch
the
data
plane
to
ensure
that
you're
extracting
the
benefits
of
installing
those
kubernetes?
E
If,
if
you're,
if
you're
going
to
head
down
that
particular
path,
so
I
think
that
there's
a,
I
think,
there's
a
line
that
we
need
to
look
at,
and
sometimes
it's
okay
to
say:
hey,
look
best
practices
within
kubernetes
work,
just
fine,
there's
nothing
extra.
We
have
to
really
push
here,
but
here's
a
here's,
a
gap
or
or
here's
the
the
analysis
of
the
application
on
how
an
application
could
better
make
use
of
it.
That
is
consumable
by
this
particular
industry
and
could
be
tailored
to
them.
H
And
also,
I
would
like
to
add
to
the
discussion.
I
think
this
discussion
has
more
value
when
we're
talking
about
the
fabric
orchestration,
not
so
much
for
inside
the
cluster.
I
mean,
if
we're
inside
the
cluster
right
now
we
have
multus
and
we
have
dam
and
we
have
like
the
primary
networking
through
calico
and
all
those
stuff
are
working
fine,
but
or
lsm.
H
So
I
think
the
external
network
orchestration
here
is
more
about
how
we
can
be
sure
that
we
can
actually
deploy
our
applications
and
the
applications
are
gonna,
be
a
are
going
to
be
shared
correctly
from
a
networking
perspective
on
on
fabric.
So
that
means
that
if
an
application
needs
to
have
like
a
access
to
a
range
of
vlans
or
to
a
raise
a
range
of
vxlan
networks
on
the
fabric,
they
they
should,
they
should
be
able
to
do
this
on
the
fly.
H
G
And,
and
just
as
an
extension
to
to
dimitra's
your
comment,
I
think
we
mentioned
about
won't
use
case
that
is
related
to
the
infrastructure,
layer
and
life
cycle
of
that
infrastructure
object.
So
I
think
I
mean
I
would
classify
networks
here
into
like
host
network
and
the
tenant
networks
and
host
networks.
We
can
say
like
a
day,
zero
configuration
in
in
the
networking
domain
so
when
the
cluster
has
to
be
spun
up
and
all
the
interface
networking
that
has
to
be
done
on
the
day,
zero
configuration
during
the
life
cycle
of
the
cluster.
G
Let's
say
that
could
be
classified
into
into
that
domain
and
then
comes
the
tenant
networking
that
will
be
required
by
a
given
network
function
that
will
be
configured
on
demand
dynamically
and
that's
what
we
are
kind
of
targeting
with
this
external
network
operator,
and
I
agree
that
it
could
be
a
bit
hard
to
like
understand
the
external
networks
here
in
in
what
context
which
we
are
referring.
So
I
tried
to
simplify
and
try
to
explain
it.
F
G
G
So
the
the
top
layer
is
basically
which
feed
takes
the
inputs
from
let's
say
the
orchestration
layer
through
the
csar
packages
and
does
the
and
that
player
basically
responsible
for
the
model
to
model
translation,
because
that
that's
basically
has
a
different
nomenclature
and
it
follows
basically,
it
has
to
make
the
translation
that
kubernetes
can
understand.
So
those
crds
will
be
then
in
a
yaml
format.
Right
so,
and
that
goes
into
the
this
called
fabric
agnostic
operator
and
that
supports
the
pluggable
architecture
for
corresponding
fabric
that
we
wanted
to
orchestrate
through
enum
yeah,
see.
F
G
G
Yeah
so
for
the
network
separation
or
for
vpn
connectivity,
we
require,
and
we
have
requirements
on
on
cnfs
that
or
cnf
have
the
requirement
from
from
the
networking
point
of
view
to
have
multiple,
vlans
and
different
so
that
they
can
segregate
their
traffics
on
different
vpns
and
different
networks
right
and
that
has
to
be
configured
somehow
on
day
day.
Two
day,
three
activities
when
you
have
to
deploy
your
network
function
and
we
are
trying
to
orchestrate
that
through
yeah.
I
would
never.
F
C
F
C
F
So
if
I'm
talking
about
you
know,
contrail
right,
yeah,
there's
already
a
juno
space,
which
is
their
ems
instance
that
owns
the
state
of
contrail
right
and
I
don't
want
anything
making
changes
to
my
overlay
or
my
physical
network
unless
it's
going
through
my
contrail
controller,
so
that
plug-in
wouldn't
talk
directly
to
the
fabric,
it
would
talk
to
the
controller.
H
H
F
F
H
Sometimes
sometimes
somebody
needs
they
want
to
have
like
a
bare
metal
of
kubernetes
and
they
they
want
to
give
like
access
to
fabric
directly.
So
so
you
want
to
have
access
through
through
your
control
controller
and
not
talking
directly
to
the
fabric,
but
to
your
control.
F
H
H
C
C
D
So
I
want
to
interject
something
here
too,
because
I,
I
think
hey,
I
think
we
first
need
to
identify
the
use
cases
before
we
talk
about
like
the
best
way
to
solve
something
personally
but,
like
I
don't
think
we
all
agree
on.
Like
external
network
versus
internal
network,
you
keep
talking
about
host
level,
networking
which
you
know
like
we're,
throwing
around
a
lot
of
terms.
I
think
that
you
know
one
of
the
things
we
need
to
think
about
the
next
week
between
now
and
next.
D
Monday's
call
is
some
potential
terms
that
we
put
in
discussions
and
start
to
add
to
our
glossary,
because
I
mean
I'm
going
to
be
completely
honest.
I
don't
really
know
the
difference
when
you
talk
about
you
know
these
network
provisions
of
when
you're
actually
provisioning
a
network
in
the
sense
that
you're
creating
like
an
l2
domain
or
an
l3
domain
that
is
going
to
span
multiple
devices
and
this
and
that
versus
just
creating
an
interface
into
an
existing
one
right
like
shared
versus
shared
versus
external.
D
Like
are
we
just
creating
an
attachment
point
you
know
and
then
to
shane's
concerns
like
is
something
like
pre-establishing.
This
once
again,
two
do
we
talk
about
like
there's
this
concept
of
like
kubernetes,
which
is
an
orchestrator
versus
the
cnf,
and
we
keep
using
those
two
things
like
they're
interchangeable
and
to
me
they're
not
like
like?
Are
we
going
to
allow
end
workloads
to
make
requests
to
the
infrastructure
like
and
not
just
like
at
a
low
level?
D
Like
you
know,
I
want
like
a
kernel
interface
into
a
pod
type
thing,
but
also
like.
Are
we
going
to
allow
a
cnf
to
talk
to
neutron
or
nsx,
or
you
know
your
vpc
directly
and
request
new
subnets
new
vlans
this,
and
that
or
you
know,
do
we
have
something
like
on
the
outside?
Like
do
we
shove
it
all
into
case,
or
do
we
allow
like
the
get
ups
process
to
do
what
it
does
in
case?
It's
just
one
endpoint
with
one
interface,
you
know
managing
something
that
it's
good
at
like.
D
I
really
think
that
we
need
to
clear
up
some
of
the
terminology
start
defining
the
difference
between
just
attaching
to
a
network
versus
creating
a
network
and
then
explicitly
state
what
use
cases
we're
going
to
tackle
because
I'm
just
listening.
I
feel
like
we're
talking
past
each
other
on
a
bunch
of
different
topics.
I
think
some
people
are
talking
about
kernel
interfaces.
Some
people
are
talking
about
spinning
up
virtual
networks
in
their
vim.
We
keep
talking
about
them.
What
happens
when
we
touch
the
physical
fabric?
E
Yeah
to
muddy
it
as
well,
you
know
in
the
internal
and
external
approach.
So
what
if
I
spin
up
a
pod
that
has
either
ovs
or
vpp,
that
is
exposing
a
some
form
of
an
interface
or
network
which
it
then
terminates
and
then
loads
into
ipsec.
To
connect
to
some
extra
to
some
to
some
external
organization.
E
In
that
scenario,
is
that
is
that
pod,
that
is
hosting
ovs
or
vpp
an
internal
or
an
external
network
in
in
this
respect,
and
so
so,
I
think
that
the
the
terminal
terminology
that
we
have
here
is
is
not
well
defined
and
confusing,
and
if
we
could
get
started
on
some
form
of
a
glossary
that
that
would
be
just.
C
Agree
that
it's
a
great
idea,
I
think
that
for
you,
I
think
for
it's
a
little
bit
ironic,
that,
as
as
networking
people
or
self-proclaimed
networking
people,
we
we
keep
throwing
around
the
word
network
where
which
is
obviously
so
so
overloaded.
Here,
I
I
think
we
really
need
a
very
clearly
defined
glossary
that
we
can
all
agree
with
the
adjectives
that
we
associate
with
network.
I
personally
think
the
first
comment
I
meant
I
thought
external
was
not
a
very
useful
adjective,
but
we
can
find
more
precise
words.
C
We
need
a
lexicon
basically
for
for
networks,
so
so
when
we
say
it,
at
least
within
this
group,
we
know
what
what
we
mean
exactly.
C
G
G
Just
a
last
comment:
I
think
there
was
one
comment
made
by
somebody
about
like
okay,
we
can
revisit
this
figure
and
yeah
can
can
explain
more
precisely
and
comprehensively
where
we
actually
interface
and
what
are
the
different
interfaces
but
yeah
there
could
be
it's
it's
not
that
it.
H
Correct
and-
and
I
would
like
also-
I
look
sorry
for
that-
I
would
like
to
add
here
that
when
we
are
talking
about
fabric,
a
fabric
b
and
stuff,
we
can,
we
are
talking
like
in
a
production.
Environment.
H
Probably
is
a
controller
that
actually
controls
the
fabric,
so
the
fabric
plugin
actually
talks
to
the
controller
that
actually
controls
the
fabric.
But,
for
instance,
you
can
have
like
a
two
vms
that
actually
run
kubernetes
and
you
have
an
obvious
fabric
outside
of
those
vms
that
those
vms
are
connected
to,
and
this
is
just
a
dummy
fabric.
It's
it's
just
for
demo
purposes,
so
the
obvious
plugin
that
you
have
there.
It's
just
a
dummy,
reverse
plugin
that
actually
talks
to
the
obvious
dummy
fabric
that
you
have
that
actually
those
gems
are
connected.
C
Yeah,
well
even
the
word
fabric
has
to
be
unpacked
a
bit.
I
there
are
few
products
that
are
called
fabric
in
the
world
of
sdn,
but
we
might
be
talking
about
defective
fabrics
that
are
encapsulated
from
existing
physical
functions
with
some
sort
of
management.
That's
just
saying
that
that's
another
word
that
I
hope
we
really
all
are
talking
about.
The
same
thing
yeah
is,
is.
H
Yeah,
maybe
maybe
you
have
like
a
legacy,
switch
that
doesn't
have
any
api
and
you
need
just
to
directly
go
inside
the
switch
and
configure
it.
So
for
that
reason
you
need
a
plugin
to
go
directly
to
the
switch
ssh
the
switch
and
do
all
the
whole
configuration.
For
instance,
we
are
talking
about
these
kinds
of
use
cases.
Maybe
this
is
a
use
case
for
somebody,
maybe
not
for
us
not
for
not
for
big
companies,
but
for
somebody.
Maybe
it
is
a
use
case.
E
A
All
right,
I've
added
a
discussion,
a
github
discussion
for
the
the
lexicon
or
glossary,
so
we
can
start
putting
stuff
in
there
and
then
do
a
pr
into
the
repo
glossary.
As
as
we
have
enough
information,
please
try
to
provide
some
mapping
to
github
sorry
to
kubernetes
terms.
So
when
we're
saying
host
networking
that
has
a
specific
use,
well-known
use
across
kubernetes.
So
if
we're
saying
it's
common
somewhere
else,
that's
fine,
but
we
need
to.
We
need
to
match
those
up.
A
What
we're
talking
about,
so
that
the
two
communities
can
collaborate
and
then
we'll
once
we
have
that
we
can
get
it
into
the
global
global
glossary
and
then
it
can
be
used
in
the
different
use
cases.
G
D
I
think
maybe
one
other
thing
we
do
too
is
draw
like
a
generic
diagram.
We've
said
in
the
past:
we're
not
doing
reference
architectures,
it's
not
what
I'm
stating
but
like.
I
think
we
should
just
have
kind
of
like
a
legend
or
a
picture
that
we
associate
and
we
stick
and
get
that
just
shows
like
a
visual
representation
of
the
terms
that
we
come
up
with.
If
we
think
make
sense,
you
know
network
attachment,
point
external
network
host
network,
all
these
things
that
we
need
to
like
unpack.
D
I
think
that
that
might
help
too.
It
should
also
be
100
like
implementation,
agnostic,
like
it's,
not
an
architecture,
it's
not
anything
like
that.
It's
little
just
a
picture
that
shows
you
know:
here's
a
tenant
network,
here's
a
network
attachment!
You
know:
here's
inside
the
host,
whatever
I
think
that
that
might
be
useful
to
people
too,
especially
if
they're
not
in
these
earlier
discussions
to
play
like
catch
up
later.
I
don't
know
if
people
are.
A
Yes
and
starting,
we
should
try
to
always
start
with
or
end
up
with
a
neutral
point
of
view
and
then
going
neutral,
slash
general,
so
that
diagram
and
the
glossary
usage
and
the
same
thing
for
use
cases
and
best
practices.
Here's
the
ones
I
someone
earlier
said.
I
think
it
might
have
been
you
frederick.
A
A
lot
of
the
app
networking
applications
are
are
going
to
work
fine
as
any
other
kubernetes
application.
So
that's
the
general
best
practices
and
the
diagrams
should
be
similar
where
we
say:
here's
the
glossary
and
general
applicability,
and
now
here's
a
separate
diagram
that
shows
some
of
these
terms
that
are
more
specific,
would
be
good.
Otherwise
we're
going
to
end
up
with
a
a
one
diagram.
That's
a
monster.
A
All
right
so
there's
a
discussion
board
and
if
you
want
to
add
terms
or
start
working
on
diagrams,
then
please
do
that.
You
can
paste
the
diagrams
right
in
draw.
I
o
is
suggested
for
diagrams
it's.
You
can
create
the
svgs
export
to
pings
or
whatever,
and
share
the
link
and
collaborate
like
you
would
do
in
google
docs
versus
something
external
that
you
have
to
upload
the
like
a
source
file
for
some
other
drawing
program.
A
D
Yeah
I
was
about
to
just
yield
the
floor.
I
put
a
comment
in
a
loke's
discussion,
tagged
a
bunch
of
people,
so
just
kind
of
take
this
into
next
week
kind
of
think
about
some
things.
Think
about
glossary
terms.
You
think
we're
lacking.
We
can
continue
the
discussions
et
cetera,
but
I
think
we
we're
probably
good
for
this
week
and
now
it's
just
time
to
kind
of
like
let
stuff
stew
in
our
minds
for
a
bit.
A
D
A
A
I
opened
this
a
while
ago,
but
it
was
a
draft
this
renaming
anywhere,
where
it's
talking
about
conformance
over
to
best
practice
the
proposals,
but
also
just
the
wording
across
the
board.
It's
been
done,
updated
the
use
cases,
the
directories,
names
and
the
links
and
stuff
like
that.
I
don't
think.
E
A
So
this
is
about
the
relationship
between
a
best
practice
and
use
cases,
and
we
keep
saying
that
any
best
practice
proposed
needs
to
relate
back
to
a
use
case
and
what
we're
trying
to
move
to
is
best
practices
that
are
small
small
enough,
that
each
one
can
be
combined
with
others
and
build
up,
but
they
all
should
relate
back
to
use
cases
one
or
more,
I'm
good.
With
that
wording
reality
versus
sanity.
I
think
it's
either
way.
It's
I'll
just
take
that
okay.
So
let's
look
here.
A
A
A
A
E
Add
me
to
it,
frederick,.
A
Okay,
I'm
gonna,
merge
it
and
I've
already
merged.
I
think
that
was
with,
and
I
also
had
hers
in
here.
I
did
the
changes
she
wanted.
Okay,
cool,
let's
move
on
so
add
values
to
the
charter.
This
ended
up
getting
split
between
this
and
this
expanded
and
the
first
it
was
a
very
minimal
there.
We
go
this
very
minimal,
oh
well.
I
just
got
a
404.
A
Well,
you
could
see
here
this
very
minimal
update.
This
is
based
on
some
cn
cncf
projects,
kubernetes
projects
that
a
list
of
values.
This
would
go
in
with
the
mission
and
everything
else
in
the
charter,
and
then
there
was
a
request
to
do
a
lot
of
expansions.
A
So
the
first
is:
can
we
merge?
Is
there
a
agreement
to
merge
this
as
a
first
iteration?
A
Oh
and
it
looks
like
we
got
them,
so
we
got
a
bunch
of
so
we're
going
to
do
that
now,
I
didn't
know
got
those
okay.
So
now
here's
the
expanded
version
exclusive
is
better
than
exclusive
go
into.
This
evolution
is
better
than
stagnation.
These
are
actually,
in
the
last
commit
versus
improve
later
commit
first,
improve
later
so
trying
to
do
quick,
iterations
and
not
have
to
get
it
perfect,
the
first
time
which
could
take
a
long
time
pragmatism
over
politics.
This
is
somewhat
related
to
this.
I'm
going
more
into.
A
We
could
have
a
lot
of
different
ideas,
but
when
we
bring
a
best
practice
forward,
we're
not
putting
a
best
practice.
That
is
not
implementable.
It's
just
an
idea.
If
we
had
an
amazing
system,
of
course
it
can
be
put
forward.
But
what
we're
talking
about
is
adoption
of
best
practices
that
can
be
used
in
real
world
applications
and
use
cases,
focus
on
community
over
specific
products
or
companies,
so
putting
the
common
focus
or
value
as
the
whole
community
and
how
we
can
benefit
and
then
adherence
to
the
code
of
conduct.
A
Let's
see
what
we
already
have
and
it
looks
like
we
already
have
approval
so
enough
to
merge.
I'm
gonna
do
that.
A
A
I
A
A
I
Every
time
that
you
merge
something
I
have
to
release
it
because
yeah,
I
need
to
make
sure
that
it's
touching
everything.
A
A
A
This
ties
into
having
a
set
of
chairs
or
tech
leads
to
approve
things
before
they
get
merged,
and
this
is
related
to,
I
think,
a
github
discussion
that
I'd
put
forward
when
we
were
talking
months
ago,
ideas
on
how
we
would
do
this
and
we
had
simple
a
little
bit
more
approval
and
so
forth,
and
then
I
put
kind
of
iterating
on
on
those
ideas
and
what
we
were
trying
to
do
and
this
acceptance
process
and
then
delegation.
A
So
this
includes
both
the
pr
process
and
the
charter
or
governance
items
so
on
the
contributing
I've
expanded
on
it,
based
on
feedback
for
what
are
the
different
ways
to
do
things
so
we're
more
extensive
on
here's,
what
you're
going
to
do
to
create
a
pull
request.
So
this
is
specific
on
changes
with
pull
request.
A
There
could
be
changes
via
voting
somewhere
else,
but
this
is
pull
request,
stuff
and
then
having
some
number
of
reviewers
and
then
acceptance
of
the
pr.
And
then
there
was
questions
about
who
are
the
reviewers.
So
we
put
this
in
here
based
on
feedback
from
ian
and
a
few
other
people
that
anyone
in
the
community
can
be
a
reviewer,
and
we
want
to
encourage
everyone
to
do
reviews
and
be
able
to
do
that.
A
A
You
know
in
a
month
that
we
want
more
or
less
reviewers
and
then
the
items-
and
it
says,
except
for
the
items
so
except
for
the
items
that
are
in
this
governance-
additional
approved
item
list
and
that's
what
is
here
so
this
is
under
this
content
approval
section
and
this
additional
item
so
this
list,
so
the
the
the
items
needing
approval
the
list
adding
or
changing
this
the
actual
charter
itself
governance.
This
should
say
the
governance
document
is
what
this
is
pointing
to
the
link,
the
code
of
conduct.
A
A
A
So
once
it
gets
to
this
point-
and
this
may
be
a
status,
it
may
be.
If
it's
in
the
document
accounts,
it
may
be
that
we
say
your
status
is
now
you
could
think
production,
it's
production
ready.
We
agree,
there
could
be
an
earlier
list
of
best
practices
where
we
go.
These
are
non-approved
but
stuff
that
we're
considering.
A
A
So
please
take
a
look
at
these
two
and
what
we'd
like
to
know
is
which
direction
we
want
to
go
this
one's
more
defined,
and
if
we
want
to
do
that,
then
it
means
we
need
to
get
tech
leads
and
everything
else,
and
this
one
is
this
one's
more
focused
on
allowing
us
to
start
working
on
use
cases
now
and
unblocking
that,
but
please
take
a
look,
provide
some
feedback
in
the
in
these,
and
one
thing
that
we
need
to
know
is
which
direction
with
the
community
wants
to
go.