►
From YouTube: Network Plumbing WG Meeting 2018-05-10
Description
Kubernetes Network Plumbing Working Group meeting 2018-05-10
A
All
right,
recording
is
on
welcome
to
the
network,
plumbing
working
group
meeting
for
Thursday
May,
10th
2018,
and
the
first
item
on
the
agenda
is
the
updated
specification,
format
and
organization
I'm,
not
sure
if
people
have
been
tracking
what
I've
been
trying
to
do
with
this
document
for
the
past
day
or
so,
but
I
had
I
went
through
and
I
kind
of
created
an
outline
for
the
document
and,
let's
see,
let
me
share
my
screen
really
quick,
just
to
show
you
kind
of
what
I
was
doing
with
that.
So,
hopefully
you
can
see
my
screen.
A
The
document
and
I
am
most
of
the
way
through
the
only
things
left
are
some
specification
around
the
cluster
wide
default
network,
as
well
as
what
the
runtime
some
considerations
for
the
runtime
stuff
I've
kept
the
original
text
below,
because
I'm
pulling
mostly
from
that,
but
at
the
end
of
this
I
intend
to
delete
most
of
that
text.
I
will
go
through
the
comments
on
that
old
text
and
try
to
resolve
them,
or
at
least
comment
on
them,
so
other
than
that.
A
Obviously,
people
probably
have
not
been
able
to
read
fully
through
this,
which
is
fine.
What
I'm
looking
for
is.
Does
this
look
like
the
right
direction
to
go?
Does
this
seem
more
readable
and
more
organized,
and
are
there
any
other
suggestions
for
format
of
this
new
format,
for
the
specification
that
anybody
has
so
I'll
just
open
it
up
to
the
floor
for
comments.
B
Okay,
I'm
afraid
I've
only
just
started
looking
at
it.
It
looks
good
so
far.
There's
one
thing
we
talked
about
that
I
haven't
noticed
yet,
which
is
a
distinction
between
stuff.
We
are
really
trying
to
specify
and
stuff
where
this
more
of
a
tactical
or
roadmap
issue,
so
I
think
we
intend
to
support
the
idea
that
this
specification
is
something
that
can
be
dynamically
updated
and
that
those
dynamic
update
those
updates
dynamically
tracked,
but
right
now
there
is
language
in
here
about
you
know
it
being
done
with
a
shim
plugin,
which
I
was.
B
B
I
know
say:
take
it
out,
I'm
just
saying
make
a
distinction
market.
Somehow,
as
you
know,
I
mean
move
move
with
your
separate
section
somehow,
but
probably
that
would
be
that
that
might
be
the
best
to
put
in
a
separate
section
to
say:
here's
spec
and
then
here's
our
expectation
about
our
roadmap
say
we
Gordon.
We
start
experimenting
with
a
shim
plugin,
but
we
want
to
be
able
to
go
further
to
support
dynamic
updates.
Okay,.
A
Yeah
and
what
I
was
thinking
of
doing
there
was
I
mean
I
still
would
remove
the
shim
language
from
the
section
to
one
the
definition
of
the
meta
plug-in
and
just
keep
that
generic,
but
then
perhaps
add
a
section
below
that
does
what
you're
suggesting,
which
is
here's,
what
we
think
stage.
One
of
this
should
be
here's
what
we
think
stage
two
could
be.
Does
that
sound
reasonable
I
think
you
said:
remove
the
meta
plug-in
from
section
page,
no
in
section
2.1,
it
currently
reads
the
shim
C&I
plug-in
that
implements
the
specification.
A
B
A
B
A
Does
this
look
like
a
good
direction
to
go
with
cleaning
up
the
language
in
the
format
of
the
specification?
I
was
attempting
to
add
concrete
labels
and
sections
to
it
so
that
implementations
could
refer
to
those
sections
or
that
we
could
be
more
precise
in
referring
to
those
sections.
When
we
do
that
in
the
future,
all
right
Mike
agrees,
yay.
A
There
have
been
quite
a
few
over
the
last
couple
of
meetings.
That's
great.
Let's
keep
going,
hopefully
once
we
have
once
the
spec
is
completed,
or
at
least
once
I've
completed
the
rewrite,
and
once
we've
had
a
couple
more
comments
and
some
time
to
look
over
it
I'd
say
maybe
until
the
next
meeting
the
next
meeting
here,
we
should
close
out
as
many
of
the
remaining
issues
as
we
can
and
try
to
progress
towards
a
v1
release
of
the
specification.
A
With
that
I
guess
we'll
move
on
to
the
next
agenda
item,
which
was
updated
on
multiple
attachments
in
C
and
I.
In
the
cni
maintainer
meeting
yesterday,
we
discussed
multiple
attachments
again
and
decided
that
Mike's
proposal
for
updating
the
uniqueness
tuple
to
include
the
interface
name
was
acceptable.
A
A
So
we
can
depend
on
that
in
our
specification
here
for
providing
multiple
attachments
that
still
means
that
the
actual
C&I
plugins
themselves,
like
you
know,
if
you
develop
a
plug-in
calico
OpenShift
whatever
those
plugins,
would
need
to
be
updated
to
consider
the
interface
name
as
part
of
their
uniqueness
for
an
attachment
if
they
want
to
advertise
conformance
to
the
cni
0
4
0
specification,
but
we
felt
like
most
plugins.
That
would
not
be
a
huge
hill
to
climb
and
should
be
fairly
minimal.
B
A
On
that,
what
do
you
mean
by
stale
to
begin
with?
Are
you
referencing
the
lack
of
a
revenger
right
into
the
plugins
yeah,
so
I
did
a
patch
or
a
PR
for
CNI
to
fix
up
all
the
test
cases
that
you
had
pointed
out
that
got
merged
yesterday
as
well
great.
So,
basically,
all
we
need
now
is
to
actually
do
the
revenger,
which
shouldn't
be
that
hard.
If
you
want
to
do
a
PR
for
that,
that's
fine!
A
A
I
know
Doug
and
Tomo,
or
one
of
one
of
you
had
added
a
section
for
that
and
I
think
I
cleaned
up
a
little
bit
of
that,
but
we
probably
need
to
take
a
another
look
at
that
with
respect
to
CNI
and
the
changes
there.
We
also
do
not
anymore
need
to
have
wording
around
the
work
around
that
Suresh
was
talking
about
a
couple
months
ago
for
this,
so
we
can
probably
remove
that
from
the
old
document
as
well.
A
The
last
thing
I
had
was
when
cleaning
up
the
spec
I
was
wondering
if
it
was
useful
that
attachments
that
don't
return
to
CNI
results
should
still
be
represented
in
the
status
map
for
the
annotation,
the
status
annotation
and
the
issue
there
is
that
CNI
does
not
require
that
plugins
return
a
useful
result.
They
can
either
return
an
error
or
they
can
return
an
empty
result.
It
does
not
mandate
that
you
return
an
IP
address
or
that
you
return.
A
So
the
question
there
is
given
that
which
I
think
is
sort
of
reasonable
should
a
network
that
does
not
return
a
result
be
represented
in
the
status
map.
I
thought
it
should,
and
it
probably
should
just
get
an
entry
with
its
name
and
that's
it.
It
doesn't
need
to
populate
the
IP
address,
MAC
address
or
anything
like
that,
but
I
felt
like
it
was
useful
to
have
the
existence
of
that
attachment,
be
represented,
not
the
direct
details.
Right.
A
B
We're
talking
about
the
multi
network
stuff
now
right
yep.
If
one
of
them
fails
the
others,
don't
I
would
kind
of
expect
that
I
mean
I.
Don't
remember.
Did
we
discuss
this?
I
would
have
expected
that
you
know
the
ones
that
succeed,
succeed
and
the
ones
that
failed
have
their
failure
recorded
and
that's
that.
A
Maybe
we
didn't
discuss
that,
but
I
guess
I
would
have
the
opposite
expectation
that
if
one
of
the
networks
that
is
specified
is
not
able
to
be
attached,
if
the
pilot
is
not
able
to
be
attached
to
one
of
the
specified
networks
that
the
pod
would
fail
to
start.
Given
that
the
user
requested
attachment
I
seem
to
recall,
maybe
thinking
at
one
point
a
couple
months
ago,
that
you
could
annotate
the
the
network.
A
Selection
annotation
I
mean
that
that
sounds
odd,
but
that
we
could
modify
the
network
selection
annotation
to
include
some
kind
of
special
symbol
or
something
else
like
that
to
say
hey.
This
is
an
optional
network.
It
would
be
great,
but
I,
think
I
discarded.
That
idea,
because
I
wanted
to
try
to
keep
this
specification
simple
mmm-hmm
just
trying
to
get
a
v1
pass
well.
B
B
B
C
B
B
C
B
A
A
A
C
This
is
more
of
just
an
announcement.
We
are
going
to
do
the
demo
itself
presentation
plus
a
your
live
demo
in
the
next
Signet
work
meeting.
That's
next
Thursday
so
make
sure
you
attend
I
think
it
would
be
interesting
demo,
okay,
just
for
the
record,
what
exactly
is
getting
demoed,
so
this
will
be
a
demo
of
the
actual
spec
itself.
C
We're
going
to
talk
about
the
spec.
We
are
going
to
talk
about
a
reference
implementation.
That's
done
in
motifs
that
has
part
of
the
spec.
It's
you
know
everything
we
specify
as
far
as
what
networks
do
we
want
to
plug
in
for
the
parts,
but
not
the
result,
object
for
example,
so
we
will
have
a
feature
list
as
defined
in
you
know.
We
call
phase
one
and
potentially
we
can
have
another
further
demo,
depending
on
the
feedback.
C
A
Yeah,
so
I
would
hope
that
this
document
is
at
least
a
basis
for
whatever
upstreaming
ends
up
happening
or
I
mean
as
a
basis.
I
mean
great.
You
know
if
the
stuff
that
we're
specifying
here
finds
its
way
substantially
unchanged
into
cube.
That's
fine,
but
if
not
that
at
least
the
lessons
that
we've
learned
from
the
various
pocs
that
we've
been
doing
and
from
developing
the
specification
and
the
use
cases
that
we've
been
looking
at
for
this
specification,
those
would
hugely
inform
whatever
solution
actually
does
end
up
being
up
streamed.
A
A
The
up
streaming
work
kind
of
got
put
on
hold
I
guess,
while
we
were
doing
this
because
some
of
it
was
a
little
contentious
and
there
were
a
lot
of
things
around
API
that
were
undecided
and
bike
shedding,
and
so
there's
a
lot
of
work
to
do.
There's
really,
this
opens
a
lot
of.
It
does
not
answer
them.
C
A
Yeah
and
that's
a
good
question,
I
mean
I
think
to
some
degree
that
depends
on
upstream
and
how
upstream
comes
around
or
does
not
come
around
to
multiple
network
use
cases.
I
think
I
was
hoping
that
it
would
eventually
end
up
being
a
large
component
of
whatever
got
done
upstream,
but
it
may
just
end
up
informing
the
upstream
discussion
and
helping
us
come
to
a
consensus
that
may
or
may
not
look
like
this
specification.
So
that's
kind
of
a
vague
answer
to
the
question,
but
yeah.
B
A
Sure
so
and
I
think
the
discussion
around
device,
plug-in
and
resource
management
to
some
degree
will
also
shape
that
any
upstream
discussion,
because
we
know
that
at
some
point
in
the
future
we're
going
to
think
about
scheduling
and
resource
management,
and
so
that's
gonna
be
a
probably
a
critical
component
of
whatever
gets
done
upstream
and
given
that
we
haven't-
and
we
aren't
addressing
that
in
this
proposal,
you
know
whatever
form
upstreaming
does
take-
will
obviously
be
somewhat
different
from
what
we've
got
here
but
I.
Think
again.
C
Excellent,
oh
so,
just
regarding
that
that
topic
I
wanted
to
just
talk
a
little
bit
about
the
device
plug-in
as
well.
So
there
is
a
effort
to
to
a
SRV
device,
plug-in
demo
PLC
demo,
that
involves
you
know
introducing
this
idea
of
having
device
plug-in
as
part
of
network
story,
because
you
know
I
think
it
does
naturally
make
sense
to
to
use
that.
For
you
know
s
already
used
pieces
and
I
think
that
introduces
some
interesting
possibility,
I
think
going
forward,
for
you
know
everything
else
as
well
right.
C
A
B
Okay,
sorry,
to
put
you
on
the
spot,
yeah
well
I
did
write
up
a
trip
report.
I
have
to
do
as
soon
as
I
res
will
start
to
forget.
So
I
guess,
I'll
say
the
topics
that
I
noticed
just
in
general
as
a
cube
con
were
the
hottest
things
I
would
say,
were
there's
a
lot
of
emphasis
on
moving
up
the
stack
server.
Those
kind
of
a
lot
of
attention,
machine
learning
did
security
got
a
lot
of
attention.
B
Get-Ups
got
some
love
api,
scots
coupe
based
api's
got
some
love
and
some
older
topics
continued
to
have
continued
to
get
love
service
meshes
a
vm
still
got
some
attention.
Fdi,
oh
they're.
Still
there,
let's
see
so
the
point
about
moving
up
the
stack
is
that
the
claim
is
the
kubernetes
is
really
becoming
the
dominant
way
to
manage
containers.
B
It
really
seems
to
be
starting
to
win
over
all
the
competitors
and
the
good
news
there
is
that
when
you
have,
you
know
wide
agreement
on
something,
then
that
makes
it
easier
provides
a
bigger
community
for
a
work
farther
up
the
stack.
So
it
really
fosters
growth
further
up
the
stack-
and
there
was
a
lot
of
stuff
talked
along
that
theme
along
the
theme,
for
example
those
enthusing
about
coop
flow,
which
is
doing
a
compendium
of
libraries
for
machine
learning
based
on
standard
kubernetes
interfaces.
B
There
was
a
guy
who
was
pointing
out
that
every
innovation
in
the
compute
abstraction
led
to
innovations
higher
stack
so
as
we
move
from
physical
machines
to
virtual
machines,
from
virtual
machines
to
containers
and
from
catered
taste.
Well,
that's
the
historical
part.
Each
one
of
those
moves
engendered
changes
higher
up
the
stack.
So,
for
example,
he
was
saying
well,
DevOps
is
the
practice,
that's
appropriate
for
containers,
so
serverless
being
the
next
iteration.
B
B
B
B
Right
like
we
just
when
you
want
host
networking,
you
often
want
also
to
be
worrying
to
it
with
hosts.
But
when
you
do
want
good
isolation,
the
thinking
was
well.
There
are
a
lot
of
different
techniques
out
there.
Now
we're,
probably
not
going
to
converge
on
one.
So
we
need
an
API
which
probably
common
API,
to
which
you
can
say.
Do
you
want
isolation
and,
if
so,
which
kind
again,
there's
just
kind
of
a
thought?
People
are
just
trying
to
get
together
on
that
and
again
in
another
similar
way.
B
But
API
is
again,
you
could
worrying
an
API
crew
based
API
is
for
describing
clusters.
There
are
several
systems
out
there.
Now
that
will
create
the
cluster
based
on
again
a
Kubb
resource
that
describes
what
the
cluster
should
look
like.
Then
again,
the
question
is
arising:
should
we
get
together
and
have
a
common
way
of
defining
a
cluster?
Interestingly
they're
running
into
a
problem
that
I
see
us
heading
into
which
is
there's
a
resource
called
cluster
in
the
cluster
Federation,
and
then
there
are
other
resources
called
cluster.
B
A
A
D
A
That's
actually
a
good
point.
You
know
our
specification
doesn't
say
anything
about
metrics
and
logging,
but
I've
found
that
to
be
really
helpful
in
most
of
the
pieces
of
cube
that
I
work
on,
and
so
any
implementation
of
this
specification
should
probably
think
hard
about
what
kind
of
metrics
and
logging
it
wants
to
do,
because
there's
a
lot
of
opportunity
aspect
for
it.
Is
that
really
the
the
an
issue
for
this
spec
or
is
a
properly
delegated
to
the
C&I
plugins
I?
A
It's
delegated
the
cni
plug-ins
at
this
point,
I,
don't
think
we
should
address
it.
I'm,
just
saying
like
in
general.
Anybody
who
implements
the
spectrum
probably
also
think
about
what
kind
of
metrics
they
want
to
add.
For
example,
how
long
does
it
take
to
run
each
of
the
delegates
or
each
of
the
sub
networks?
How
long
does
it
take
to
run
each
Network
attachment?
That's
usable
information
to
know
so
the
amount
of
time
each
plug
in
and
figure
out?
A
You
know:
is
this
one
taking
five
seconds
and
what's
the
with
it,
why's
it
doing
that
right,
you
know,
cube
already
has
metrics
for
the
entire
pod
network
operation,
which
would
be
in
this
specification
the
aggregate
of
all
of
the
networks
right.
But
you
know
it's
it's
useful
for
operations,
people
to
break
that
down
further
right,
diagnose
things
and
figure
out.
What's
going
on
in
the
cluster
right.
B
In
fact,
along
those
lines
we're
digressing
here,
but
it's
a
fun
one,
all
right,
one
of
the
ones
they're
really
concerns
me
is
something
I,
don't
quite
see
an
easy
way
to
get
in
regular
operations,
which
is
the
latency
from
the
point
in
the
user.
You
know,
does
something
in
the
API
to
win.
The
network
attachments
are
fully
functional
right,
so
not
only
has
the
scene
I
plug
and
run,
but
in
the
cases
of
stuff
like
over
yes,
which
have
to
distribute
information
throughout
the
system
and
get
updates
done
remotely.
B
So
there
might
be
some
I
think
it
might
be
interesting
to
think
about.
Even
if
it's
not
part
of
regular
operations,
we
might
have
some
regular.
We
do
some
regular
testing
and
that
testing
framework
might
take
some
additional
measurements.
So
we
could
start
to
address
this
kind
of
questions,
I.
Think
in
our
regular
testing,
yeah.
B
Regarding
api's
right,
I
mentioned
several
things
that
are
talking
about
new
API,
so
they're
done
with
Kubb
API
resources
and
I'm
interested
in
that
it's
a
general
system
bid,
look
building
technology
and
the
the
API
machinery
sig
is
also,
and
they
got
up
and
said
something
about
that
on.
In
fact,
I
noticed
earlier,
a
eBay
was
going
to
get
up
and
talk
about.
The
schedule
said
that
evening
was
going
to
talk
about
work.
They
did
along
those
lines,
but
I
never
actually
saw
it.
It's
not
in
the
schedule
anymore.
B
The
interesting
thing
is
right:
you
can
the
more
traditional
way
to
bill
things
like
this
with
you
cobble
together
some
databases
and
some
message
buses,
but
you
can't
do
an
asset
transaction.
Then
it
falls
both
the
database
and
message
bus,
whereas
with
Kubb
api
machinery.
Because
of
the
way
the
informers
work
and
informers,
I
would
say
right
when
you
do
a
transaction
with
the
API
machinery.
There's
a
reliability
story
all
the
way
into
the
controllers
and
I
think
that
inputs,
the
general
state
orientation,
is
just
a
superior
way
to
build
systems
in
general.
B
I
also
wanted
to
say
something
a
little
bit
about
FDI,
oh
I,
missed
in
Austin
the
FT
that
I
was
somewhat
but
I
got
to
it
last
week
and
it
seems
interesting,
it's
like
something
we
ought
to
consider
or
or
maybe
it's
just
matter,
they
don't
promote
themselves
better
I
think
they
said
they
have
a
CNI
plug-in
that's
of
generic
usefulness
and
performs
much
better
than
say
OBS.
So
it
seems
like
something
interesting
and
they're,
also
working
on
additional
work
to
more
deeply
and
natively
plug
into
kubernetes.
E
So
I've
got
one
thing:
it's
a
very
high-level
thing
which
is
I
was
impressed
at
the
extent
to
which
kubernetes
and
some
of
the
other
CN
CF
projects,
particularly
Prometheus,
just
become
dominant
they've,
become
the
standard
everybody's
using
them.
They
just
flatten.
The
opposition.
Prometheus
was
interesting.
E
There
are
several
competing
vendors
there
who
are
pretty
much
all
saying,
and
this
is
how
we
integrate
Prometheus
into
our
pieces
now,
and
so
that
level
of
dominance
is
a
big
change
from
a
couple
years
ago,
and
that's
one
of
the
things
that
seem
to
be
driving
the
way
that
kubernetes
is
maturing
very
nicely.
I
mean
a
couple
years
ago.
It
was
just
nothing
like
its
materia
that
mr.
E
Foggs
restored
cases,
and
it
feels
like
it's
very,
very
rapidly,
becoming
much
much
more
stable,
much
more
functional,
just
producing
all
the
stuff
that
makes
it
production
ready.
A
secret
I
mean
I,
know
it's
production-ready
already,
but
you
wouldn't
have
any
hesitation
putting
into
pro
where's
a
couple
years
ago.
It
would
be
very
a
little
bit
scary
and
a
year
ago
you
be
a
little
nervous
now.
E
No
one
would
bat
an
eyelid
and
I
think
from
from
our
point
of
view,
as
a
vendor
selling
to
companies
who
are
deployed
deploying
mostly
OpenStack,
and
things
like
that
at
the
moment,
but
are
looking
at
kubernetes
as
they
go
forward.
I
think
kubernetes
is
just
gonna
to
take
over
the
world
at
this
rate,
and
you
know
that
was
obviously
one
of
the
themes
with
coop
con
everyone's
very
happy
and
excited
about
that.
But
it
does,
it
does
seem.
The
hype
is
true.
As
far
as
I
can
tell.
A
E
B
D
A
D
A
A
A
Two
specs
we're
talking
about
the
first
one,
is
the
custom
research
definition
de-facto
standard,
which
is
how
we
propose
to
implement
multiple
secondary
or
sidecar
networks
within
the
current
kubernetes
infrastructure
and
framework.
So
this
would
be
a
adding
additional
interfaces
into
a
pod
to
enable
fast
data
path
or
secondary
network
storage
networks
or
more
performant
networks
or
isolation
potentially
as
well.
The
other
suspect
that
you
might
have
been
referring
to
as
a
CNI
specification
itself
and
this
specification
uses
CNI,
and
so
it
necessarily
refers
back
to
various
bits
of
the
CNI
specification.
D
A
So
and
I
assume
you're
talking
about
CNI,
specifically
right
now.
The
way
CNI
works
is
that
we
don't
actually
bump
the
spec
version
until
we
commit
code
or
commit
those
changes
to
the
spec.
So
there
are
a
couple
of
outstanding
pull
requests
that
do
modify
the
cns
specification,
but
those
have
not
been
merged
yet
since
they're
going
through
a
couple
of
iterations,
so
once
one
of
those
does
get
merged
that
makes
material
changes
to
the
spec.
The
spec
version
will
get
bumped.
Cni
follows
semantic
versioning.
A
So
it's
not
like
we
pile
changes
into
the
existing
spec
and
then
at
one
point
flip
the
version
we
might
do
that
if
the
changes
that
go
in
are
very
close
together,
like
you
know,
if
they
go
in
a
day
after
another
one
just
so
that
we
don't
have
huge
version
inflation.
But
you
know
right
now
that
the
spec
has
not
actually
changed
that
much
since
the
last
version.
A
But
again
there
are
some
outstanding
PRS
that
will
change
it
fairly
significantly
and
one
of
those
is
the
get
PR
which
I
think
is
like
number
75
or
175.
Something
like
that.
It
should
be
pretty
easy
to
see
in
the
cni
repo
pull
requests
where
it
is,
but
that's
the
one
of
the
only
changes
that
I'm
thinking
of
right
off
the
top
of
my
head.
D
A
So
the
way
that
works
is
there
was
a
bandwidth
shaping
plugin
or
traffic,
shaping
plugin
added
to
the
reference
plugin
set
recently,
and
that
does
not
specifically
depend
on
a
revision
of
the
specification.
So
there's
the
cni
specification
and
there's
a
set
of
recommendations
or
conventions,
I
should
say,
and
the
conventions
are
things
that
they're
essentially.
A
Bits
of
data
that
a
runtime
can
pass
to
the
cni
plugins
that
get
run
and
the
bandwidth
shaping
stuff
falls
under
those
conventions.
So
those
don't
require
a
bump
of
the
specification.
At
least
we
haven't
decided
that
they
do
at
this
point
in
the
cni
maintainer
z'
meetings,
so
the
traffic
shaping
plugin
is
there
already
I
think
it
was
part
of
the
like
0.7
plugins
release,
so
that
should
be
usable
now
for
those
setups
where
it's
where
it
works,
it's
not
a
I
mean.
A
Obviously
it's
not
going
to
allow
shaping
if
you
use
something
like
open,
V
switch
or
something
else.
But
if
you
use
fairly
standard
Linux
kernel
interfaces
for
your
networking,
then
it
should
implement
that
shaping
feeling.
The
last
thing
I'll
say
about
that
is
that
the
conventions
document
that
talks
about
some
of
the
things
that
a
runtime
could
send
to
a
shaping
plugin,
that's
not
tied
to
a
specific
implementation.
A
So
you
could
write
your
own
shaping
plugin
that
follows
those
conventions
and
accepts
the
same.
Shaping
data
like
you
know,
bandwidth
data
or
whatever,
from
the
runtime
as
the
reference
plug-in,
and
then
you
could
utilize.
You
know
you
wouldn't
have
to
do
any
other
work.
You
wouldn't
have
to
get
runtimes
to
conform
to
that
either
you
could
just
kind
of
replace
the
shaping
plugin
with
your
own
if
you
wanted
and
everything
would
sort
of
work.
So
that's
some
of
the
background
behind
that.