►
From YouTube: Multi-Network community sync for 20230927
Description
Multi-Network community sync for 20230927
A
Got
it
all
right,
welcome
everyone
at
the
multi-network
community
sync
and
today
September
27th.
We
have
few
items
on
the
agenda.
The
first
link
I
ran
the
doc
our
initial
discussion
of
that
with
Tim
Hawkins
and
have
some
initial
feedback
from
him
on
that.
A
A
A
Not
only
the
few
few
of
us
in
this
meeting,
so
the
general
kind
of
feedback
is
to
ensure
that
whatever
we
add,
is
very
simple
and
it's
not
complex,
or
we
have
to
have
a
really
good
argumentation
behind
it
right,
that's
kind
of
the
main
gist
of
the
discussion.
So
in
that
note,
the
first
thing
was
was
said
about
the
additional
I
think
the
Pod
Network
attachment-
and
maybe
let
me
start
from
that
is
in
in
the
conception
of
itself-
is
quite
simple,
but
it.
Why
would
we
need
it
right?
A
Network
attachment
right
so
I
try
to
create
a
kind
of
come
up
with
use
cases
where,
where,
where
we
want
to
use
it
and
how
and
it's
something
that
I
think
I
would
need
as
well
help
from
from
this
group
to
argument
a
little
better
than
what
I
currently
have
even
in
the
dark
and
then
everywhere
else
so
I'm
seeking
for
help
from
from
here
to
kind
of
start
looking
and
and
if
you
could
look
at
the
dock
where
I'm
I
describing
this
object
and
why
we
need
it
even
here
in
this
in
this
beginning,
to
read
through
it
and
help
me
enhance
it
as
this
stand,
this
might
be
hard
hard
bullet
to
sell
to
add
this
additional
object
into
the
core
together
with
code
Network,
and
so
that's
that's
one
thing
that
I'm
asking
this
group
as
well
to
kind
of
review
the
this
Doc
in
sections
where
we
mentioned
about
Network
attachment
and
help
me
argument
its
existence
better
because,
as
it
stands,
we
might
be
having
a
hard
time
selling
this
and
pushing
it
through.
A
So
that's
that's!
That's
one
comment.
The
other
comment
was
about
the
ipam
stuff
that
basically
I
think
I've
been
mostly
pushing,
as
we
said
below
that
the
kubernetes
type
of
ipam,
then
this
is
the
node
icon.
That
would
be
there.
It
will
not
be
implemented
by
this
cap.
A
A
A
valid
use
case
for
us
to
have
it
here
as
an
as
an
additional
option,
because
we
mostly
would
use
the
non-type
the
ability
to
not
specify
MIP
for
the
radio,
because,
as
we,
we
called,
we
have
a
team
at
the
radio.
The
radio
use
case,
basically
SRV
with
vfio
right
is
that
popular
enough
use
case
in
kubernetes
globally
and,
let's
find
I
know
we
did
within
this
group.
It's
like
one
of
the
main
use
cases,
but
now
think
about
this
globally
across
kubernetes.
A
What's
what
percentage
of
users
would
you
really
use
this
right
and
then,
whether
that
entitles
to
have
this
field?
If
we
were
to
remove
this
then
and
kubernetes
is
not
implemented
and
the
other
feedback
was
to
don't
introduce
something
that
maybe
sometimes
in
the
future
is
going
to
be
implemented.
If
that's
the
case,
then,
let's
add
it
with
that
cap.
So
basically
definitely
just
remove
the
kubernetes
element
questions
about
non-type.
A
So
then
we
end
up
with
just
one
item:
what's
the
point
of
them,
having
keeping
at
least
at
this
stage,
those
two
Fields
right
and
the
the
current
proposal
is
to
get
rid
of
this
and
keep
it
simple
and
sure
we
just
only
always
do
external
ipump
and
then,
on
the
other
hand,
thing
we
need
to
think
about
what
to
do
with
the
non-type.
A
So
this
is
something
that
was
another
another
feedback
on
this.
Considering
that
we
don't
implement
the
kubernetes
piece
option,
something
that
probably
would
come
in
later
phase
and
when
we
do
that,
then
probably
we
can
revisit
this
adding
that
field
into
this.
A
This
object,
but
currently
to
in
the
in
the
sense
of
keeping
it
simple.
Just
maybe
we
can
remove
that
any
comments
on
that.
B
A
All
right,
so
there
is
that
the
next
item
was
the
list
of
the
parameters
ref.
It's
not
it's
unusual.
Maybe
that
was
the
comment.
It's
not
that
it's
it's
a
bad
thing,
but
nobody
really
does
this,
and
why
would
you
want
to
have
this?
The
main
concern?
What
was
with
user
experience
and
in
this
sense?
What?
If
what
do
we
have
this
one
right
here?
What
because
then
we
are
assuming
the
implementation
handles
a
list
right
ensures
there
is
a
enough
elements
of
it.
A
C
I
I'm
just
trying
to
understand
the
so
it's
that
it
puts
pressure
on
the
implementation.
Yes,
do
you
think.
A
Imagine
imagine
my
implementation
I
just
use
this
one
parameters
right.
This
only
object
of
this
parameters.
This
parameter
CRT
that
I
created
not
only
that
one
right.
Okay,
so
you
have
to
reference.
Then
this
is
a
list.
So
now
what?
If
you
implement?
What,
if
you
provide
two
of
them?
What
if
you
provide
something
else
than
my
object?
So
this
is
the
pressure
I'm
saying
referring
to
where
that
implementation.
If
they
want
to
be
really
robust,
they
would
have
to
ensure
that
this
list
at
least
only
one
element
and
always
my
right.
A
Where
you
know
we
we
put
pressure
on
implementation
to
ensure
that
when
you
add
this,
ensure
that
now
you
cover
all
the
corner
cases
right
where
there
can
be
multiple
of
those
there
can
be
different
types,
so
ensure
your
you
have
a
web
hook
or
what's
not
to
to
to
kind
of
limit
this.
Otherwise
you
know
you
open
users
to
failure
in
some
ways
or
confusion
right,
because
someone
created
oh
I,
listed
all
those
and
I
saw
someone
else
while
doing
this,
and
it
worked
for
them.
Why
doesn't
work
it
here
and
then?
A
A
We
probably
because
this
is
something
that
will
be
fully
owned
by
the
implementation
right
this
this
field
is
not.
We,
the
car,
won't
touch
it
right.
So
so
so
that's
that's
the
feedback
right.
B
A
B
A
True
I
agree
with
you
right,
but
then
it's
just
one
object
right
and-
and
this
is
maybe
maybe
this
is
Niche
and
maybe
team
is
exaggerating
right.
Maybe
that's
not
a
big
deal
right
and
let's
I'm
just
trying
to
to
pass
the
feedback.
You
write
that
at
least
you
have
to
validate.
Is
that
the
object
that
you
support
the
type
of
it
right?
But
then
that's
the
only
check
the
other
check.
Then
you
have
to
specify
that
this
is
not
the
list.
This
is.
A
It
doesn't
have
more
elements
than
what
you
support
or
if
you
do,
support
multiple
then
ensure
that
they
are
the
right
type,
I
think
yeah,
that's
something
that
basically
does
the
the
the
pressure
that
we
would
put
on
the
implementation
to
have
that,
and
maybe
that's
that's
neglect
negligible.
C
C
The
initial
feedback
like
we
got
to
keep
it
simple,
I
I,
think
that's
really
good,
so
I
mean
at
least
from
my
standpoint,
which
is
okay,
so
in
a
pod
Network
having
the
parameter
rafts
it
to
me
makes
a
lot
of
sense
from
coming
from
the
multis
standpoint,
where
I'm,
like
I,
have
an
existing
crd
and
I
kind
of
want
to
group
these
together.
C
So
it
is
the
I
I
could
live.
I
think
that
I
could
live
with
this.
Being
a
a
single
item
is
that
the
like
is
that
the
feedback
that
it
should
be
a
single
item
and
not
a
list,
maybe.
A
It's
is
maybe
the
the
other.
The
feedback
would
be
as
I
mentioned
before,
right,
it
just
adds.
Complexity
and
and
I
even
wrote,
maybe
add
examples
in
the
appendix
right.
Maybe
how
this
would
be
used.
Maybe
I
need
more,
better
argumentation
behind
it
to
have
it
right
because
it
wasn't
like.
Oh
let's
not,
no,
no,
it's
it.
It
can
be
there,
but
let's
maybe
have
better
argumentation
behind
it
to
to
to
introduce
it.
A
That's
one
piece
and
the
other
piece
would
be
to
no,
that
might
be
the
other.
The
the
one
the
one
problem
would
this
be
would
would
be,
will
be
the
ux
right,
but
I
think,
let's
just
maybe
I
would
I
would
keep
it,
as
is
it
just.
Maybe
helped
me
with
better,
maybe
just
add,
use
cases
of
what
I
I
come
up
with
the
here.
D
B
A
D
A
Because
that
was
as
well
feedback
right,
let's
have
if,
because
maybe
I
couldn't
sell
it
right
in
terms
of
of
use
cases,
so
it
also
help
me
with
defining
the
use
cases
here,
because
it
wasn't
like
I
completely
no
right,
because
that's
that's
that's
not
the
case.
It's
just
matter
of
not,
let's
have
a
better
use
cases
defined
that
let's
have
our
better
argumentation
for
it.
That's.
D
A
Was
going
through
the
dock?
No,
the
the
representation
that
I
have
there
we're
gonna
go
to
it.
I
don't
want
to
go
over
it
I'm
just
going
to
mention
that
it's
there
today,
but
I
want
to
go
go
over
tomorrow
at
the
Sig
networking.
So
so
definitely
that's
something
that
I'm
creating
to
kind
of
show
to
the
Sig
Network
first
and
then
the
other
six
later
down
the
road.
So
that's
my
that's
my
kind
of
rule,
but
I
don't
want
to
kind
of.
Let's
I
will
get
there
in
a
second.
A
Does
this
sound
good,
then?
Let's,
let's
have
some
better.
E
I
think
for
me,
I
agree.
My
second
I
should
work
on
the
examples,
probably
right
to
justify,
because
you
I
mean
there's
multiple
ways
on
the
implementation
that
you
can
use
it.
There
is
one
is:
do
you
support
it,
but
you
could
also
say:
okay.
If
someone
referenced
it
then
I
ignore
the
parameters
that
I
don't
support
and
I
give
a
warning
or
something
I.
I
do
agree
that
there's
more
work
in
the
implementation,
but
the-
and
this
gives
more
flexibility
right,
which
is
right.
That's
the
trade-off,
yeah
and.
A
All
right
all
right:
let's,
let's
move
on
then
conditions,
the
the
same,
the
Inus
flag,
Team
brought
up
a
case
for
race
that
this
flag
will
never
cannot
be
a
hundred
percent
trusted
and
the
the
example
would
be
if,
because
we
have
the
dependency
on
on
the
other,
no
this
is
in
use
for
pods
right.
So
basically
I
am
referencing
is
is,
are
you
do
you
exist?
A
Are
you
used
sorry,
I
apologies,
so
I
would
I
would
check
this
flag,
whether
you
exist
or
not,
but
what?
If,
in
the
same
time
a
pod
is
being
created
right,
so
there
might
be
a
raise,
because
this
is
not
sequential,
there
might
be
a
race
where,
basically,
this
will
be
a
lie
right
in
terms
of
oh,
this,
like
that's
not
there,
but
pods
is
about
to
be
created
and
getting
ready
right.
A
So
that's
why
this
will
there
will
be
races
and
instead
of
just
doing
this,
The
Proposal
is
just
to
your
other
components
would
look
at
if
they
need
to
see
whether
there
are
pods
using
it.
Just
do
the
check
right
just
do
the
listing
and
do
that
check
with
yourself.
So
I'm
thinking
of
that's
kind
of
true,
because
we
will
never
be
what
I
want
to
say
this.
A
This
is
race
the
in
use
flag
and
it
will
not
be
100
valid
to
kind
of
to
trust,
because
you
might
check
it,
but
then
you
might
run
into
a
case
where
it's
not
really
true,
and
then
you
would
have
to
do
your
check
again
because
it's
flake
right
and
flakiness
that's
something
that
we
should
not
introduce.
So
that
proposal
is
to
get
rid
of
it
and
then,
if
you
want
to
check
if
if
a
a
thing
is
in
use,
then
do
the
check
yourself
and
this
will
be
as
well.
A
So
the
functionality
will
still
be
there
that
this
this
flag
was
introducing
and
what
I
mean
by
that
is.
This
object
will
have
a
finalizer
and
basically
the
financial
will
only
be
removed
when
there
are
no
pods
using
it.
That
aspect
will
not
change
and
it
will
be
still
there,
but
the
thing
here
the
indicator
will
not,
because
it's
not
100
reflective
of,
what's
really
happening.
A
A
A
We
had
a
shorter
meeting
and
we
didn't,
like
I,
think,
went
through
100
of
it,
but
I
think
that's
that
the
gist
of
the
feedback
that
I
have
the
the
I
think
the
one
major
one
would
be
about
the
the
the
existence
of
what
network,
because
that's
something
that
we
did
talk
through
as
well
as
I
mentioned
from
the
beginning,
so
I
need
better
argumentation,
for
it.
Team
was
matching,
maybe
instead
of
using
this
object.
What?
A
If
and
that's
something
I
think
we
even
were
thinking
what,
if
we
were
to
propose
here,
a
reference
to
custom
object
inside
the
Pod
spec
directly
instead
of
having
this
indirection
right?
That
was
maybe
some
idea
that
that
he
was
thinking
to
maybe
do
instead,
but
I
think
this
one
is
cleaner.
That's
the
indirection
is
better
because
then
you
really
have
a
clear
object
at
our
core
that
you
don't
have
to
kind
of
deal
with.
So
I
prefer
this
approach.
So,
let's
try
I
I,
want
you.
A
What
I
want
to
do
is
I
want
to
go
with
this
in
the
cap
in
the
pr,
but
I
need
your
help
in
terms
of
argumentation,
of
need,
the
need
for
the
Pod
Network
attachment,
because
that's
that's
another
thing
right.
If
we
want
to
have
it
when
you
describe
it
on
a
paper,
maybe
the
picture,
maybe
at
top,
is
a
bit
confusing
here
with
this
refer
this
this
list
of
kind
of
dependencies
and
how
and
who
can
and
how
many
times
can
reference
it.
A
Maybe
that's
too
confusing,
but
still
when
you
just
simplify
that
how
it
references
and
how
it
works.
It's
just
basically
free
objects
that
they
can
reference
each
other
and
basically
that's
it
where
it
ends.
A
So
maybe
I
need
help
from
you
on
getting
better
argumentation
on
why
to
keep
the
Pod
Network
attachment
I,
don't
want
to
have
it
as
well.
So
let's
maybe
let's
work
on
a
better
argumentation
of
why
we
would
need
that
pod
Network
attachment-
and
this
is
basically
AI
to
you
folks
as
well-
to
help
me
with
reviewing
this
this
pieces.
A
A
If
not,
then,
let's,
let's
move
on
so
the
next
thing
was
the
I've
kicked
off
the
the
presentation,
for-
let
me
just
maybe
share
this.
This
is
the
slides
I
created
for
the
six
kind
of
for
the
six
right.
So
I
want
to
go
and
say
that
we
want
to
introduce
this
Define
more
or
less
what
we
are
doing,
where
we
are,
what
sort
of
use
cases
we
want
to
cover,
what
objects
we
want
to
introduce.
What
changes
in
this
first
phase
right!
So
please
review
this.
A
We
I'm
gonna
have
probably
at
least
initial
feedback
tomorrow,
I'm
planning
to
refine
this
today
and
and
then
we're
gonna
present.
This
I
want
to
present
this
tomorrow.
I
have
an
agenda
item
for
tomorrow,
Sig
networking
meeting
to
present
this,
so
that
will
give
us
initial
feedback
from
the
team
what
they
think
about
the
whole
idea
not
generally
about
the
presentation
itself,
but
about
the
the
general
idea.
So
then
I
can
probably
further
refine
this,
but
then
we
can
see
what
how
the
community
feels
about
our
our
plants
in
general
anyway.
A
Please
review
this.
If
you
could,
if
there's
anything
other
items,
I'm
missing
that
I
should
have
here,
please
let
me
know:
I
will
I
will
add
that.
So
there
is
this
guy,
any
other
comments
or
questions
on
this
is.
A
With
we
are
working
with
the
Doug
on
that
one
separately
now
this
is
maybe
we're
gonna
pull
something
from
here:
I'm,
not
sure,
we'll
see
with
dark.
What's
valid.
What's
not,
but
no.
This
is
just
this
might
be
some
source
for
something
I'm
gonna,
maybe
refine
this
even
further.
No,
but
this
is
just
for
six
six.
A
This
is
because
the
difference
between
the
kubecon
and
and
and
here
I
want
to
go
for
the
six
I
want
to
go
in
more
into
details,
and
this
is
just
strictly
kind
of
targeted
towards
the
implementation
of
what
we
want
to
do.
What
we
want
to
change
right-
and
this
is
not
I-
think
discussion
for
cube.
What's
going
to
change
as
much
right,
at
least
in
that
level
of
details,.
A
F
Yes,
yes,
that's
me
thank
you,
so
so
I
would
have
liked
to
have
prepared
more.
This
is
the
first
I
I
spoke
with
you
guys
a
couple
months
ago.
F
This
is
the
first
meeting
that
I've
been
able
to
attend
since
then,
because
the
times
have
all
been
wrong,
but
you
know
we
are
working
with
the
Gateway,
API,
Group
and
I
think
it
would
be
good
for
us
to
coordinate
how
we
look
at
multiple
Networks,
both
inside
the
cluster
and
outside
and
how
it
interacts
with
the
Gateway.
Api
and
I
have
some
thoughts
on
it
that
I'd
like
to
share
and
get
some
feedback
so
can
I
share
for
a
second,
oh.
F
So
I
I
would
have
liked
to
generalize
this
drawing
a
little
bit
more,
but
I
think
it
helps
to
kind
of
illustrate
sort
of
the
the
issue.
So
we
have
a
product
called
spk,
which
is
a
really
a
Gateway.
F
It's
a
a
path
in
and
out
of
kubernetes
and
one
of
the
sort
of
one
of
the
things
that
we're
trying
to
solve
and
that
we've
identified,
particularly
for
for
telcos,
but
also
for
other
types
of
users,
is
that
the
Ingress
path
and
the
egress
pass
for
data
is
completely
separate
in
kubernetes,
and
that
causes
a
lot
of
problems.
And
so
you
know
we
are
actively
trying
to
work
on
having
this
Gateway
API
via
path
in
and
out
of
kubernetes
sort
of
a
unified
path,
so
that
you
can
then
also
apply.
F
You
know
different
kinds
of
policies,
firewalls
application,
firewalls,
whatever
else
on
top
of
that
Source
Network
address
translation,
whatever
kinds
of
of
policies
you
need,
and
one
of
the
issues
is
that
in
this
environment
there
are
multiple
external
networks,
Network
domains
that
are
intentionally
segmented.
F
They
are
intentionally
kept
separate,
so
here
I've,
I've
shown
sort
of
highlighted
what
I
call
a
Services
Network,
which
is
where
they're
above
service
based
Communications
or
HTTP
Services
defined
by
you
know
in
that
are
used
for
setting
up
5G
calls,
and
you
have
traffic
between
consumers
and
producers,
essentially
clients
and
the
servers
for
doing
5G.
But
but
you
have
all
these
other
external
networks
over
on
the
left.
F
You
have
like
operations,
Administration
and
maintenance,
a
radio
Access,
Network,
Etc,
and
so
having
this
Gateway
able
to
connect
to
multiple
networks
is
useful
while
talking
to
customers.
They
are
also
asking
about
having
multiple
internal
networks.
Multiple
pod
networks,
right
and
I-
didn't
add
this
to
the
drawing
and
I
I,
but
essentially
I.
Think
it's
some
of
the
use
cases
that
you
just
had
up
on
those
slides
right
like
having
a
separate.
F
You
know,
VLAN
for
control
plane
having
separate
vlans
to
isolate
different
vendor
applications
from
each
other,
so
that
you
could
have
a
pod
or
an
overlay
Network.
That
would
connect,
say
you
know
the
the
pods
inside
of
the
consumer
or
producer
or
maybe
with
other.
You
know
vendor
applications,
but
would
be
more
isolated
from
the
other
applications
in
the
network.
And
so
what
I'm
suggesting
is
that
there
are
sort
of
two
multi-network
aspects.
F
There's
having
multiple
external
networks
which
I
represent
here
with
the
Services
Network,
IMS
oam
and
ran,
and
then
there's
having
multiple
internal
networks
right
connecting
pods
and
the
the
the
proposal
for
the
Gateway
API
for.
B
F
So
that
we
can
sort
of
create
a
single
data
path
in
and
out
of,
kubernetes
is
to
have
the
Gateway
to
have
gateways.
When
the
Gateway
class
is
installed
by
the
infrastructure
provider
that
they
would
configure
what
external
networks
there
are
and
then
the
gateways
themselves
would
be
gateways
to
a
single
external
network,
and
then
application
developers
would
request
routes
against
those
gateways.
F
And
this
is
sort
of
how
you
would
control
the
traffic
in
and
out
north
south
and
I'm
wondering
how
this
aligns
with
and-
and
you
know,
maybe
the
gateways
themselves
would
use-
would
leverage
some
of
the
multi-network
stuff
that
you
guys
are
working
on
to
configure
what
external
networks
look
like
and
then
cnis
would
use
the
sort
of
internal
networks
to
create
different
pod
and
overlay
networks
and
I'm
wondering
what
what
your
take
is
on
that.
A
So,
keep
in
mind
that
the
name
is
POD
Network
right.
So
wherever
we
Define
here
is
for
the
parts
we
shouldn't
be
creating
a
pod
Network
object
for
something
that's
external
and
then
pod
should
not.
That
pod
will
never
attach
to
that's.
That's
not
the
point
of
the
Pod
Network
right
so
right
on
that
manner,
I,
don't
think
we
can
describe
what's
external
to
your
to
your
to
your
in
your
infrastructure
right.
So
that's
something
that
this
definitely
care
doesn't
fit.
A
The
one
thing
that
I
do
like
about
what
you
showing
here
is
the
single
Network
I
think
this
is
where
recently
we
have
Dave
protozovsky
came
here:
I'm,
not
sure
you
he
he's
working
with
Gateway
routability
as
well.
I'm,
not
sure
you
saw
that
proposal,
but
he
was
talking
about
a
private
public
Gateway
right.
A
He
wants
to
kind
of
provide
that
kind
of
aspect
and
and
some
of
the
folks
in
the
in
the
in
the
Gateway
discussion,
kind
of
tell
them
or
go
to
multi
Network,
because
that
sounds
sounds
somehow
similar
and
basically,
what
we
are
stating
is
what
you
have
it
in
the
middle
right:
the
single
Network.
This
is
what
we
are
trying
to
kind
of
settle,
and
maybe
that's
gonna
change,
but
I
think
because
we
are
not
at
this
point
of
the
of
our
designs
on
how
we
really
want
to
kind
of
support
services,
Gateway
syngots.
A
What's
that
but
I
think
the
the
kind
of
division
for
that
at
least
mine
would
be
that
Gateway
belongs
to
a
network.
What
I
want
to
ensure
that
Gateway
is
not
a
router
all
right.
It's
not
a
Gateway,
doesn't
a
route
between
multiple
networks,
and
you
can
pick
and
choose.
No
Gateway
is
assigned
to
a
network,
and
Gateway
is
a
gateway
within
that
Network
in
that
in.
If
we
keep
it
in
the
atoms.
This
is
very
simple
because
we
just
keep
the
same
functionality.
A
What
we
have
for
Gateway
today,
but
with
indifferent
vlans
right
so
I
have
I
want
to
attract
traffic
to
this
Gateway.
Do
something
about
it
in
that
different
VLAN
right
or,
as
you
showed
in
in
a
Gateway
class
right.
So
this
is
something
that
where,
where
you
Gateway
class
assigning
to
an
external
network,
doesn't
kind
of
work
for
me,
because
unless
it
can
be
the
same
and
think
about
it,
Philip,
because
maybe
that
can
be
the
same,
where,
if
I
indicating
Gateway
class
to
a
specific
VLAN
and
basically
all
pods
connect
to
that
VLAN.
A
Can
the
internal
external
be
the
same.
That's
the
question
to
you
right,
I,
don't
have
to
answer
now
me,
but
but
think
about
that
right.
Does
it
really
have
to
be
because
otherwise,
if
it
is
the
different,
then
you
make
a
Gateway
a
router
right,
you
route,
the
external
to
internal
which
that
I
I
don't
think
we
would
want
to
introduce
routing
into
into.
We
want
to
keep
it
simple
to
ensure
this
is
just
networks
that
provides
you
like.
B
F
F
I
think
some
level
of
routing
is
necessary
if
you're
going
to
have
a
pod
Network.
That
is
separate
from
your
external
Networks.
A
And
what
we
are
want
to
say
is
that's
up
to
you,
whether
you
interconnect
that
network
with
some
other
networks,
with
your
default,
for
example-
and
that's
everything
is
done
externally
and
it's
up
to
you
what
we
ensure
is-
and
we
want
to
be
so
so
today,
the
the
main
rule
of
Tamp-
sorry
dark.
Let
me
I
will
give
you
voice.
Give
me
a
sec.
A
The
rule
of
time
for
today's
Network,
the
default
network
is
all
the
pods
have
connectivity
within
the
cluster,
all
right,
assuming
we
have
only
one
network
and
that
works
right
when
we
start
introducing
additional
networks.
Let's,
let's
just
do
the
same.
All
the
pods
within
that
network
has
to
have
connectivity.
This
is
one
of
our
requirements
right
and-
and
we
just
want
to
keep
it,
keep
it
that
level
simple.
We
don't
want
to
introduce
capability
of
routing,
because
that's
that
just
basically
brings
up
open
step
openstack
back
here
and
that's
just
too
complex.
A
C
Yeah,
thank
you.
I
I
think
that
I
understand
a
little
bit
better
from
what
matcha
is
talking
about
with
with
the
Gateway
not
being
a
router,
but
yeah.
It's
to
me
and
Philip
correct
me
if
I'm
wrong,
but
what
this
sounds
like
is
that
it's
a
way
to
kind
of
orchestrate
what
the
attachment
to
a
network
will
be
at
more
of
this,
like
cluster
admin,
infrastructure
provider
level,
so
that
you
could
say,
like
this
class
of
PODS,
connects
via
this
infrastructure
provider
network.
F
Yeah
yeah,
okay
yeah.
So
if
you
kind
of,
if
you
go
back
to
this
drawing,
there
are
certain
applications
that
can
connect
to
the
Services
Network.
C
Application:
okay,
that's
helpful
and
I
get
it
and
one
so
I
guess.
One
thing
that
I
would
say
is
so
I.
I
think
that
this
is
interesting
and
compelling.
C
But
one
of
my
experiences
with
the
group,
the
network
Plumbing
working
group
that
came
up
with
Network
attachment
definition,
was
some
one
of
the
major
challenges
that
we
kind
of
tabled
early
on
was
to
answer
the
question
of
which
network
you're
attached
to
so
I.
Think
that
this
is
compelling
in
terms
of
adding
some
some
semantics
to
say
like
okay,
we
know
something
about
you
as
a
pod
or
a
group
of
PODS
and
we're
going
to
connect
you
to
this
particular
Network.
C
C
This
is
traditionally
also
been
kind
of
a
challenge
with
network
attachment
definition
and
the
way
that
it's
typically
implemented
with
a
meta
plug-in
is
that
routing
is
a
challenge,
and
it
often
requires
a
little
bit
more
of
like
babying,
like
that.
You've
gotta
specifically
set
your
routes
or
use.
Something
like
that,
like
like
one
particular
solution
from
like
meta
plug-in
standpoint,
would
be
to
use
something
that
overrides
your
routes
and
you
set
them
statically.
C
But
I
also
think
that
this
would
be
interesting
from
an
implementation
standpoint
where,
if
you
have
some
type
of
orchestration,
that
is
smarter
about
this,
like
Gateway
class
Gateway
level
like
you're,
representing
here,
to
be
able
to
say,
have
that
control
over
over
the
pods.
To
say,
like
hey,
your
routing
is
going
this
way,
or
this
is
the
Gateway
that
you're
using
and
to
have
your
implementation
handle.
That
is
also
interesting
but
similar
to
my
last
comment.
C
I'm
I'm
not
particularly
sure
that
that
I
I
think
that
some
of
the
things
that
we've
sort
of
addressed
here,
at
least
in
our
use
cases
like,
for
example,
like
like
the
idea
of
like
Dynamic
attachments
or
like
a
hot
plug
functionality,
I
mean
you
could
kind
of
read
that
as
like
an
opportunity
to
like
modify
the
like
networking
properties
of
a
given
interface
or
pod
network
attachment
to
a
pod
I
think
could
be
good
implementation
wise,
but
I'm
not
sure
that,
at
this
phase
of
the
game
that
I
in
our
like
apis
specification
that
we're
looking
at
that
we'd
wanna
necessarily
say
like
hey.
C
C
A
Yeah
I,
what
I
would
add
to
this
is:
let's
remember
this
is
ingress
and
egress.
So
this
is
basically
just
a
kind
of
that's
called
steering
cover
traffic
right
within
Gloucester.
It's
not
about
physical
connectivity
to
a
pod.
What
I'm
kind
of
saying
what
what
the
Gateway
here
phone
functions
as
here
and
Philip
I,
think
this.
This
will
work,
but
the
Gateway
class
side.
It's
something
that
basically
your
implementation
Handles
in
full.
A
It
can
be
somehow
standardized,
but
this
will
be
something
separate
to
what
we
are
doing
here,
because
what
I
would
want
you
to
definitely
to
preserve
and
and
if
we
could
kind
of
agree
on
that,
that
Gateway
belongs
to
a
network
internal
Network
right.
So
basically,
I
can
route
those
and
attract
those
traffic,
Ingress
or
egress
only
within
the
specific
pod
Network
right
and
then
how
because
and
then
the
Gateway
class
itself
can
then
indicate
what
is
the
external
stuff,
but
that
that
can
be
completely
implementation
specific.
A
It
is,
but
since
it's
external
yeah-
and
you
don't
have
to
do
anything
special
for
maybe
you
would
because
of
what
a
dark
set
in
terms
of
those
routes.
Extra
routes,
if
anything,
so
maybe
you
would
have
to
your
implementation
of
the
Pod
Network
itself.
First,
the
internal
Network
would
have
to
support
how
I,
then,
if
okay,
if
I,
have
this
Gateway
class
from
external
going
to
this
internal
internal
guy,
I,
maybe
have
to
tweak
some
routes
on
that
internal
pod
Network,
to
ensure
that
the
traffic
can
return
right
and
and
be
replied.
A
That's
something
that
you
would
have
to
kind
of
combine
the
two.
So
this
is
where
I
think
would
be
one
of
the
problems,
but
if
we
keep
the
Pod
Network
as
a
part
of
the
Gateway
and
the
service
right,
where
basically
Gateway
is
within
the
specific
internal,
as
you
call
it
networks
I
think
then
then
we
we
we
could
coexist
right,
because
the
external
piece
is
kind
of
implementation,
specific,
the
Gateway
class
kind
of
attached
to
external
things
and
how
it's
being
implemented.
That's
completely
outside
of
a
cni
scope.
A
Right,
because
this
is
keep
in
mind.
We
are
looking
at
pod.
Network
means
an
in
the
indentification
of
what
I'm
doing
on
the
cni
level
on
the
Pod
level
attached
to
physically
right
to
the
Pod
and
you're,
not
in
that
business
you're
going
into
a
business
into
how
do
I
do
an
Ingress
attract
the
traffic
into
the
cluster
right
from
where
to
where
right.
That's
that's
what
you
want
to
achieve,
that
is,
that
isn't.
F
That
great
and
and
how
it
goes
out,
this
is
the
this
is
the
primary
to
me.
The
primary
failing
of
okay
of
kubernetes
networking
is
that
Ingress
and
egress
are
handled
completely
separately
and
don't
have
any
unified
controls.
Yes,
because
it
means
that
you
have
to
treat
each
kubernetes
level
service
kind
of
separately
versus
treating
an
application
together
right,
yeah.
A
I
hear
you
so
I
think
man
in
that
in
that
terms,
that
that
still
should
be
fine
right,
because
this
is
this
still
would
be
content
to
a
specific
Network
right.
So,
basically,
because
imagine
a
situation
where
you
have
called
in
there
can
be
put
into
one
of
the
two
cases
right.
Either
report
has
multiple
interfaces.
A
And
and
basically
then,
if
you
want
to
let's
say
this,
this
the
case
where
you
have
a
single
interface
in
a
pod,
but
it's
a
non-default
network
right
that
Gateway
now,
if,
if
you
want
to
touch
and
and
put
Ingress
into
that
port
or
capture
an
egress
from
that
pod,
you
have
to
select
the
specific
interface
of
that
pod
right.
So
basically,
you
need
to
select
that
non-default
pod
Network
to
which
I
apply
and
then
then
I
have
at
least
the
internal
piece
covered
right.
A
A
How
do
I
ensure
that
what
I
want
to
say
that
the
traffic
going
out
from
that
pod
can
properly
reach
out
to
that
external
network
right?
You.
E
B
A
F
Yeah-
and
this
is
the
thing
like
right
now,
our
product,
our
implementation,
is
dealing
with
pods
with
a
single
interface.
B
F
And
we
are
just
releasing
what
I
call
multis
capture,
which
is
a
fancy
way
of
saying
if
you're,
if
you
also
are
using
maltes
to
do
like
a
Mac,
VLAN
or
ipv
land
type
interface,
you
know
we
can
redirect
that
traffic,
also
through
the
through
through
the
Gateway
right.
So
you
can
apply
again
consistent
policies
for
Ingress
and
egress
traffic,
even
if
somebody's
using
like
mac
VLAN
or
something
right
with
the
work
you
guys
are
doing.
There
could
be
a
whole
bunch
of
pod
Networks.
C
F
Right
and
I
guess
the
question
is:
if
somebody
is
egressing
like
if
somebody's
going
ordinarily
in
a
pod,
you
just
say:
hey
I'm,
going
to
this
destination
right
and
how
are
you
dealing
with,
if
you
have
say
three
pod
overlays,
three
pod
networks
connected
to
that
which
interface
or
how
that
packet
leads
to
the
external
point
is
I
guess
my
my
question.
A
A
How
that's
configured
I
did
in
my
cap,
I
I,
do
want
to
kind
of
indicate
through
some
flags
and
notion
of
a
default,
a
default
interface
within
the
nodes
right
and
that's
and
that's
depending
on
how
you
implement
your
cnis,
because,
on
the
other
hand,
something
nice
will
dictate
that
for
you,
you
cannot
control
it.
That's
that's
hard
coded
in
the
cni
conf
state
stated
where
okay,
this
cni
configuration
is
the
default.
So
basically
you
cannot
pick
and
choose,
but
I
want
to
kind
of
have
an
implementation.
Where
I
can
we
can
choose?
A
I
have
multiple
pod
networks
with
the
same
level
of
capabilities
each
one
of
them
can
be
default
and
I
want
to
pick
and
choose
right
for
this
bot.
A
second
network
is
going
to
be
the
default
for
the
other
pod.
The
third
one
will
be
the
default
right,
so
I
want
to
pick
and
choose.
So
we
have
the
capability
to
indicate
which
one
is
the
default
and,
and
that
will
boil
down
to
some
sort
of
implementation.
A
That
will
say
okay
for
this
Paul,
this
guy
is
the
default
gateway,
or
you
want
to
do
something
else.
You
want
to
create
an
svr,
for
example
right
or
leverage
SBR,
so
you
just
want
to
exit
for
that
pod
when
the
traffic
comes
come
from
that
from
that
interface
right.
So
you
you
just
deal
with
the
replies
and
it's
basically
in
this
case
failure
to
answer
your
question.
It
boils
down
to
the
implementation,
that's
what
I
want
to
kind
of
get
to
it's,
not
something
that
we
impose.
A
A
What's
a
network
for
their
case
is
right,
so
that's
why
it
will
boil
down
to
how
the
implementation
does
it
and
what
they
cons,
kind
of
consider
as
a
network
right
and
then
based
on
that
how
the
implementation
handles
like
when
multiple
interfaces,
how
they
deal
with
routes
and
what's
that
right
or
they
do
something
else.
So
to
answer
your
questions,
we
don't
specify
that
and
it's
up
to
the
implementation
on
how
they
handle
the
multiple
interfaces
right.
B
A
F
So,
just
to
summarize,
this
group
is
really
looking
only
at
multiple
pod
networks,
not
multiple
networks.
More
generally,
like
external
networks,.
A
F
You
don't
have
you're
not
defined
if,
if
a
cni
has
multiple
interfaces
is
using
multiple
pod
Networks,
there
isn't
a
specification.
There
isn't
a
requirement
for
how
egressing
traffic
specifically
would
flow
in
terms
of
between
those
and
while
I
think
I
heard
General
approval
of
having
the
Statewide
concept
of
having
a
separate
Gateway
for
each
external
network.
It
doesn't
necessarily
touch
on
the
work
that
you
guys
are
doing.
A
B
A
B
A
So
that's
good,
that's
you
you
bringing
this
up.
This
is
where
you
can
at
least
I
would
Envision,
and
this
is
I
have
slightly
because
in
Google
we
are
kind
of
looking
into
some
of
this
already
in
our
site.
But
if
you
were
to
look
at
service
itself,
let's,
let's
step
back
on
the
service
itself,
can
I
really
create
a
load
balancer
type
service
in
front
of
probably
we
could
in
front
of
a
pods
that
have
multiple
interfaces
right.
Is
there
a
point
of
that?
A
If
I
have
a
service
pointing
to
a
a
part
that
has
multiple
interfaces
and
I
select
all
those
interfaces,
what
will
that
mean?
I
have
one
VIP.
I
cannot
announce
the
same
VIP
on
multiple,
let's
say:
vedance
right,
that
will
be,
it
probably
could,
but
that's
kind
of
kind
of
tricky
and
then
debugging
that
that's
that's,
probably
a
nightmare
too
kind
of
to
pinpoint
okay
from
which
network
is
clearly
arrives,
and,
what's
that
so
and
and
that
introduces.
A
A
That
I
would
I
would
that's
that's,
that's
that's
what
I
would
hope
to
eventually
get
to?
Yes,
if
you
don't
specify
it
you,
you
are
within
the
default
Network
right,
so
the
one
that
you
do
today,
but
if
you
want
to
assign
to
one
of
the
other
interfaces,
then
you
specify
that
that
Network,
in
which
you
want
to
do
otherwise
and
let's.
B
A
Have
this
right
if
I
have
a
server
if
I
have
a
pod
with
the
single
interface
which
is
non-default
and
my
I
created
a
service
for
that
code,
but
I
created
a
service
in
a
default
Network.
That
service
has
no
back-ends,
because
that
part
has
no
back-ends
in
that
default.
Network
endpoints
in
that
Network
right!
So
that's
that's!
That
will
be
the
consequence
of
this
right.
So
basically
you
would
have
to
create
a
service
in
that
non-default
Network
as
well,
and
then
okay
now
I
know
it's
in
that
Network.
A
That
means
I
mean
that
VLAN,
which
already
has
some
its
own
defined
set
of
VIPs,
that
I
will
assign
to
that
service.
My
load
balancer
understands
the
multi-network
concept,
set
the
VIP
to
that
service,
and
then
everything
works
within
that
VLAN
right.
That's
at
least
keeps
it
simple,
as
you
think
and
think
of
it,
because
if
we
were
to
do
more
elaborate,
that
will
make
it
so
complex
and
so
difficult
to
handle
that
probably
nobody
would
want
to
have
that,
because
you
see
I
know
the
possibilities.
A
You
and
that's
another
thing:
I
agree
with
you
and
and
we'll
see
where,
where
that
goes,
and
as
I
said,
this
is
our
phase
three.
If
you
look
at
our
requirements
doc,
we
kind
of
phased
out
all
the
requirements
right
now
we
want
to
just
Define
the
API
and
we'll
see
how
that
goes.
Second
phase,
it
doesn't
even
touch
on
that
on
the
services
on
integration
with
other
services.
Yet
so
second
phase
will
be
just
hardening
some
of
that
apis
and
doing
dealing
with
some
nodes
and
then
yes,
how.
A
That's
I
agree
with
you,
but
I
think
the
services
eventually.
This
is
where,
where
I
I
think
the
answer
for
this
is
because
we
cannot
do
everything
at
once
and
that's
going
to
just
blow
up
the
scope
and
we
just
we
would
we
would
never
move.
We
have
to
do
and
make
small
steps,
because
there
is
so
much
more
things
to
this,
then
that
so
that
we
can,
you
know,
talk
about
everything
right
right
away
from
the
get-go.
That's
just
we
would
never
move.
A
That
will
be
the
issue
here.
We
want
to
have
something
solid
and
move
with
phases
so
that
we
can
then
eventually
get
there
and
then
that's
why
we
don't
want
to
make
this
whole
API
a
ga
right
away.
It's
gonna
be,
unfortunately,
probably
better
Alpha
for
a
longer
time
when,
when
we
have
all
the
all
the
ducks
in
a
row,
everything
is
aligned.
Everything
is
set
in
stone.
We
don't
need
to
change
any
apis.
Okay,
then
that's
good!
A
F
All
right,
I
mean
we've
run
out
of
time,
I
I,
guess
the
main
thing
is
I.
F
This
point
we
probably
don't
need
to
say
a
whole
bunch
do
a
whole
bunch
of
coordinating
between
the
Gateway
API,
with
egress
and
and
your
work
with
the
multiple
pod
Networks.
F
A
Right
right
and
Philip,
this
is
one
thing
just
keep
in
mind
to
what
we
want
to
do
in
pod,
Network
I
think
I
gave
you
more
of
a
more
or
less
like
a
gist.
What
what
we
are
heading
with
the
Pod
Network.
So
from
from
your
point
of
view,
what
you're
gonna
propose,
the
one
thing
I
would
ask
from
you
is
to
keep.
He
keep
keep
us
in
the
loop.
A
If
you
want
to
do
some
some
changes
or
keeping
them
in
mind
what
we
are
trying
to
do
with
pod
Network
to
what
you
want
to
do
so
that
we
don't
have
to
then
compete
on
on
on
you
know
in
how
it
has
has
to
be
kind
of
defined
in
the
future
between
each
other.