►
From YouTube: 2021-09-30 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
C
B
B
It
feels
like
I've
got
three
rack
mounted
switches
in
my
office
here.
No,
it's
it's
a
mix
of
I
share
internet
with
my
neighbor.
Our
house
is
made
of
it's
technically
wood,
but
it's
got
concrete
in
the
walls,
so
we
need
wi-fi
access
points
in
literally
every
room
because
they
will
not
propagate
to
other
rooms,
even
on
full
blast,
and
now
we've
got
iptv
in
addition
to
our
fiber
connection
and
the
iptv
only
works
on
the
isp's
router,
which
is
a
piece
of
junk
otherwise.
B
So
I
basically
have
the
fiber
connection
coming
into
a
switch
just
three
ports
on
that
switch
that
are
sort
of
separated
from
the
rest.
That
then
goes
out
to
my
router
and
the
isps
router
and
they're
on
different
vlans
one's
just
for
tv.
It's
this
whole
thing.
B
And
I
get
25
gig
e
inside
most
of
the
network,
so
it's
quick.
B
B
B
B
I
mentioned
to
the
the
gc
and
I
talked
to
sergey,
so
it
sounds
like
basically
once
we
submit
the
doc
the
tc
technical
committee
created
this
group
and
asked
us
for
a
recommendation.
They
are
just
going
to
defer
to
us
for
the
recommend
for
the
final
recommendation,
so
the
tc
will
review
it
sure.
But
our
recommendation
is
the
recommendation
for
the
project.
I
mentioned
that
to
the
governor's
committee.
They
agreed
wholeheartedly
that
that
is
fine.
D
I
think,
can
you
hear
me,
okay,
yeah.
C
D
I
think
the
we
have
a
skeleton
document
that
I
think
we
agree
on
on
all
the
points
there
I
mean
you
raised
a
good
point
on.
You
know
a
discussion
point
on
naming
and
kind
of
whether
kind
of
how
do
other
evpf
collectors
fit
into
into
the
open,
telemetry
vision.
D
D
If,
if
we've
agreed
on
all
the
salient
points,
I
think
we
should.
You
know,
let's,
let's,
let's
move
on
and
start
getting
user
impact
kind
of,
moving
into
open,
telemetry,
saying
kind
of
get
getting
more
users
onto
the
platform
and
getting
more
feedback.
So
I
I
would
love
to
see
that
if
we
can.
A
Yeah
and
by
the
way
I
do
like,
I
think
the
doc
was
like
the
details
and
everything
do
look
really
good.
I
think
it's
just
like
we're.
We've
got
this
working
groupie
bpf,
like
I
think.
Probably
it
would
be
good
to
have
a
road
map
long
term
of
like
what
other
things
are
going
to
be
coming
in
just
like
how
do
we
want
to
make
it
plugable
and
kind
of
future
proof?
A
For
you
know,
as
we
continue
on,
I
mean
abpf
is
just
going
to
keep
like
this
is
not
going
to
be
the
last
one
right,
so
we
can
kind
of
like
take
a
leadership
role
here
and
kind
of
say:
hey.
We
want
to
actually
set
out
a
bit
of
a
road
map
and
kind
of
future-proof
this
stuff
and
kind
of
have
the
modular
approach,
or
maybe
its
naming
or
whatever.
However,
we
want
to
go
about
it.
C
Yeah,
after
omits
comments,
I
also
came
to.
I
have
another
broader
question.
I
think
which
we
may
need
to
address.
You
know
if
anyone
comes
in
with
another
bppf
agents,
you
know
what
is
our
strategy?
Should
we
be
expecting
them
to
become
a
part
of
the
existing
agent
or
is
there
a
path
for
them
to?
You
know,
use
the
collector
with
the
fundamentals
that
we
discussed
here.
Maybe
we
can
give
them
like
hey.
This
is
how
we
this
is.
You
know
these
are
like
the
big
things
that
you
need
to
cover.
C
Maybe
we
can
also
address
that,
like
maybe
it's
a
very
long-term
thing
to
think
about,
but
it
may
help.
I
think
the
technical
committee.
A
Yeah,
I
kind
of
see
two
pro
I
mean.
I
don't
know
if
it
was
clear
from
my
con,
but
I
kind
of
see
two
approaches
here.
I
think
we
could
either
kind
of
go
one
route,
which
is
to
say
like
name
this
a
little
bit
more
more
specifically
and
then
as
new
ebpf
technologies
come
in
we'll
just
be
completely
independent
collectors
and
just
plug
in
through
kind
of
different
interfaces,
or
we
could
kind
of
have
like
a
bigger
just
like
keep.
A
But
I
think
we
should
make
a
call
on
that
like
how
we
want
to
position
ourselves
for
the
future
right.
Both
I
think
are,
could
be
good
options,
but
we
should
probably
think
a
little
bit
about
the
trade-offs
and
what
we
think
is
a
little
bit
more
kind
of
scalable,
as
we
try
to
maintain
all
this
stuff.
D
When,
when
we're
discussing
these
new
data
sources,
are
we
talking
about
adding?
Were
you
thinking
about
adding
more
functionality
with
the
existing
platform
or
are
kind
of?
Is
there
a
use
case
where
there's
a
completely
different
collection
architecture
that
you'd
want
to
use
I'm
asking
kind
of
yeah?
Are
you
talking
about
like
bringing
in
like
something
like
the
like
the
pixie
agent,
with
its
own
kind
of
maybe
golang
layer
of
collecting?
Or
do
you
want
to
bring
in
cpu
memory
and
io
to
this
platform?
So.
A
All
of
the
above,
like,
I
think
we
should
have
like
think
it
through,
so
that
I
was
thinking
both
like
because
you
mentioned
at
the
end
of
the
document
like
okay.
There
are
c
like
there's
plans
for
cpu
memory,
io
stuff,
like
that's,
that's
a
wealth
of
information,
that's
great
right
and
we
can
collect
it
at
really
low
overhead
from
ebpf,
and
it
sounds
like
you
guys
are
already
down
that
road,
which
is
great,
but
do
we
kind
of
put
that
into
the
same
framework?
A
Because
then,
how
is
it
does?
How
will
it
look
if,
like
that
stuff
kind
of
put
in
with
the
rest
of
the
flo
mill
npm
stuff?
And
then
maybe
we
do
want
to
plug
in
a
pixie
thing
later,
or
maybe
there's
some
other
new
thing
about?
I
mean
like
I
said.
I
think
this
is
we're
like
we're
the
core
group
here
and
we're
really
early
on,
but
we
all
see
it
right,
ebps
just
going
to
keep
expanding
like
the
sort
of
stuff
that
people
do
and
for
monitoring
in
particular.
A
B
Very
much
and
to
that
point,
like
I
think,
you're
you're,
advocating
that
we
keep
this
group
around.
I
think
we
should
yeah.
I
think
that
you
should
there
there's
no
other
group
that
meets
in
open
plummetry
regularly.
That's
going
to
discuss
this
specifically
like
the
only
the
only
other
home
for
these
discussions.
That
would
make
any
amount
of
sense
at
all
would
be
the
the
main
collector
group,
but
they
have
a
ton
of
topics
that
they're
going
on.
B
A
total
distraction
for
them
and
they
would
not
appreciate
us
to
talking
about
ebps
for
half
an
hour
a
week
in
their
calls.
So
we
should
probably
keep
this
keep
this
here
and
keep
it
going.
Weekly
yeah.
A
I
mean
coming
to
the
question
of
like
the
architecture
I
mean,
I
think,
it'll
be
a
little
bit
more
work
to
kind
of
try
to
fit
everything
under
one
umbrella,
but
if
we
do
it
right,
it
can
be.
It
can
be
nice.
B
Right,
it's
also
the
pattern
we
followed
so
much
else
of
open
telemetry
is
to
do
a
thing
once
the
right
way
consistently.
Instead
of
like
we
have
one
java
sdk.
Instead
of
like
projects
like
zipkin
that
had
three
or
four
right,
I
I
generally
my
preference
would
be
that's
similar
for
ebpf,
like
keep
it
under
one
roof.
A
Yeah
and
then
we
just
have
to
future,
like
the
challenger
of
course,
is
like
we're
thinking
today
of
like
npm
kind
of
stuff,
cpu
cpu
kind
of
memory
io,
those
are
kind
of
straightforward,
but
it's
like
what
happens
when
we
start
expanding
that
out,
because
we
should
plan
ahead
for
that
and
inevitably
some
things
are
going
to
get
pushed.
You
know
the
boundaries
are
going
to
get
pushed
and
stuff
and
we'll
you
know,
adapt,
but
as
much
as
we
can
prepare
for
that
to
kind
of
lessen
the
pain
when
new
things
come
in.
A
C
We
can
also,
you
know,
pick
essentials.
Like
you
know,
evp
is
a
large
space.
I
mean
the
entire
mechanism
exists
because
it's
so
flexible,
it's
something
you
know
very
flexible
needed
to.
You
know
be
the
solution,
but
you
know
we
can
pick
some
of
the
essentials.
For
example,
like
the
other
question
I
would
have
like,
should
we
allow
people
to
you
know
what
type
of
configuration
should
we
allow
enabling
and
disabling?
C
For
example,
network
collection
is
one
thing,
but
what
you
want
to
collect
in
the
network
is
the
other
thing
like
all
of
those
things
you
know
doesn't
have
to
be
maybe
addressed
by
this
particular
agent,
but
we,
I
think,
need
to
kind
of
like
express
what
we
want
to
ex.
You
know
what
type
of
like
flexibility
we're
going
to
be
providing
for
every
other.
You
know
more
advanced
use
case.
You
can
still
bring
your
you
know.
Custom
agent
produce
the
data.
C
Similarly,
that
might
also,
I
think,
help
the
technical
committee
to
be
able
to
you
know.
Just
you
know,
draw
the
line
or
where
we
want
to
draw
the
line
like
expressing.
That
would
be
useful.
D
Yeah-
and
I
think
that
the
document
touches
on
that
a
little
bit
where
and
and
if
you
agree
with
that,
I
think
that
could
be.
You
know
I
think
we
under
might
have.
We
can
put
more
emphasis
about
it
in
the
document
where,
as
as
right
now,
the
collector
doesn't
have
much
configuration,
as
you
know,
collect
more
collect,
less
or
collect
in
this
way
or
another
way
it
does
what
it
does.
D
It's
always
on
collects
kind
of
everything
with
low
overhead
but,
as
you
add,
maybe
more
expensive,
more
expensive
instrumentation
in
there
and
you
don't
want
the
deluge
of
downstream
processing
of
the
data
and
the
cost
of
downstream
processing
data
that
you
don't
need
is
that
the
users
users
should
be
able
to
configure
the
the
evps
agent
from
open
telemetry
collector
configuration
as
a
receiver
configuration
and
kind
of
the
initial
thought
we
gave
this.
D
As
you
know,
the
initial
thought
was
we
would
build
kind
of
a
configuration
server,
that
a
receiver
would
connect
to
pull
configuration
and
then
push
push
telemetry
in.
So
there
would
be
this,
so
this
is
definitely.
D
C
Configuration
the
it's
it's
covered
in
the
document,
but
I
think.
D
C
Not
covered,
is
you
know
what
am
I
bringing
as
in
configuration?
Can
I
bring
an
ebpf
program?
I
don't
think
it's
it's
our
target
right
for
this
project.
We
will
never
think
about.
You
know
providing
that
level
of
flexibility,
but
there
will
be
you
know,
programs
that
we
already
like
you
know,
are
targeting
for
certain
things
to
be
collected
and
we
will
be
enabling
and
disabling
those
things.
So
that's
sort
of,
like
I
think
where
I
was
coming
from.
Maybe
I'm
just
you
know,
taking
the
discussion
to
another
place,
but
yeah.
D
D
D
So
amid
for
for
the
so
configuration
is
one
thing
you
mentioned
kind
of
architecturally,
enabling
other
types
of
collection
in
the
collector.
I
think
the
collector
is
built
in
a
you
know.
D
Arguably
modular
right,
it's
in
a
way,
that's
easy
to
change
and
and
where
you
can
write
your
collector
in
a
class
and
then
it's
not
modular
in
the
sense
that
there's
like
one
place
where
you
register
the
class.
But
you
have
to
kind
of
instantiate
it
in
this.
There's
the
kernel
collector
class
and
then
you
instantiate
a
new
member
of
that
class,
which
is
maybe
your
trace
collector
or
your
cpu
mio
collector
and
then
there's
a
place
in
in
in
the
initialization.
D
Where
you
add
it
like
paul
right,
paul,
the
paul
pull
the
sorry,
not
paul,
but
instrument
instrument
and
and
there's
all
the
infrastructure
to
compile
programs
and
load
them.
And
then
so
it
is.
The
collector
is
modular.
If
you
want
to
build
another
component
into
that
same
framework-
and
I
think
we
have
you
know-
the
team
has
put
in
very
substantial
effort
in
in
in
making
the
low-level
collection
kind
of
just
getting
events
out
of
the
operating
system.
D
You
know
getting
the
instrumentation
out
getting
the
events
out
of
the
operating
system
scanning
the
existing
state
of
the
operating
system.
If
you
need
it
made
that
very,
very
high
performance
so
that
you
can
reuse
that
over
and
over,
and
I
hope
that
that
infrastructure
is
something
that
people
I'm
hoping
that
that
everybody
would
be
able
to
reuse
it.
If
there's
other
collection,
if
you
want
to
have
something
like
the
pixie
agent
connect,
then
can
we
need
to.
We
kind
of
we
haven't
designed
that
yet,
but.
D
A
Right
now,
right,
obviously
right,
so
that's
not
kind
of
I
mean
I
just
want
to
be
able
to
leave
the
door
open
to
these
serious
things
so
that
we
have
so
I
mean
it
sounds
good
that
you
have
a
modular
design,
but
whatever
proposal
we
take
to
the
tc,
I
think
we
should
just
stress
you
know
and
say
look.
We
do
have
pluggable
kind
of
modules
that
we
plan
on
we've
thought
a
little
bit
about.
A
You
know
how
we
want
to
move
forward
and
if
new
things
come
in
an
ebpf,
I
mean
again,
it's
not
just
pxe
right.
I
mean
cpu
memory,
io
stats.
Who
knows
what
else
comes
down
down
the
pike
right
we
have
in
pixie,
we
have
like
full
body
tracing
that
could
be
of
interest.
We
have
profiling
stuff,
we
do
that
could
be
of
interest.
All
this
stuff
is
ebtf-based
right.
A
A
C
A
That
we
do
plan
to
be
able
to
put
these
in
and,
if
maybe
in
a
future
session,
what
would
actually
be
interesting?
Is
we
use
this
as
an
exercise
to
see
like,
for
example,
how
would
the
pixie,
because
that's
the
one
I'm
most
familiar
with,
so
I'm
just
going
to
pick
on
that
one
right,
it's
like
how,
if
we
wanted
to
theoretically
put
in
one
of
the
modules
pixie
also
has
a
concept
of
like
modules
like
we
have
plugable
evpf
different
like
different
ebps
sources.
C
A
Don't
get
me
wrong,
I'm
not
saying
like
we
should
design
like
a
fully
like
reusable
like
just
like
anyone
can
come
and
do
whatever
it's
like.
Do
we
have
a
road
map
for
kind
of
like
expanding
out
new
things
into
it
or
not,
and
again
the
alternative
could
be
that
we
just
say
no,
it's
going
to
be
too
difficult,
like
we
don't
think
that's
a
good
strategy,
and
so
we
just
plan
to
have
different
ebpf
collectors
for
different
things
in
in
the
in
the
future
right.
That
is
also
like
coming
back
to
morgan's
thing.
A
Case
right
and
like
what
happens
when
an
evpf
profiler
come,
you
know,
comes
with
comes
in
or
what,
if
an
avpf
tracer
of
some
sort
comes
in
like
what
do
we
do
with
the
naming
and
things
like
that.
D
Yeah,
I
think
if
we
can
I've
actually
in
the
evp
summit,
I
I
don't
know
if
I
alluded
to
it
or
not
in
the
talk,
but
I
think
there
is
a
lot
of
infrastructure
that
you
can
reuse
between
different
ebpf
collection
data
types
and
so
when,
when
you're
collecting
profiling
data,
you
probably
want
it
to
be
in
the
same
context
as
your
npm
instrumentation
and
your
cpu
and
I
o
instrumentation
and
your
container
instrumentation,
and
when
you
build
when
you
build
io
profiling,
maybe
kind
of
how
long
does
it
take
to
read
blocks
from
disk?
D
You
can
do
you
can
add
a
module
there?
You
want
to
be
in
the
same
context.
You
want
to
have
like
the
I
o
delays
and
your
your
profiling
delays
in
the
same
framework.
So
you
know
I,
I
think
what
the
you
know.
The
best
experience
that
our
users
could
have
is
if
we
integrate
everything-
and
you
know
technically,
I
don't
see
a
reason
why
why
we
should
build
different
collectors,
and
you
know
duplicate
effort
in
in
the
you
know.
D
But
if
that
is
the
case,
then
maybe
we
should
separate
them,
but
it
you
know
the
way
I
would
hope
things
would
work
is
that
you
could
roof
them
under
and
and
and
the
infrastructure
is
built
that
way,
and
I
think,
like,
like
the
the
team
of
developers
working
on
on
like
the
on
that
have
been
working
on
this
framework
have
been
building
it
in
a
way
that
is
extensible
and
would
love
to
to
con
to
collaborate
to
get
more
functionality.
And
if
that's.
C
A
A
I,
like,
I,
don't
know
the
details,
how
you
do
it,
but
in
pixi
like
we
want
to
share
context,
we
inject
the
context
in
so
there's
something
that
is
collecting
the
context
and
then
that
gets
injected
into
our
different,
like
we
have
different
ebpf
modules
and
the
context
can
get
injected
in
so
they're
all
working
with
the
same
context
right,
but
that's
the
sort
of
things
that
we
should
kind
of
those
might
be
differences
in
like
how
we
have
drawn
our
interfaces,
and
maybe
we
want
to
think
about
that
a
little
bit
and
like
I'm
saying
I'm
not
saying
we
have
to
do
it
today.
A
I
know
I
know
we
want
to
get
this
through
the
tc,
and
you
know
I'm
all
for
that
right,
but
I
think
we
can
there's
a
difference
between
saying
like
we
need
to
have
this
done
right
now
and
just
saying
on
the
roadmap
we
want
to
like.
We
want
to
kind
of
have
a
plugable
architecture
and
we
do
have
the
vision
of
being
able
to
push
in
different
sources.
A
A
I
think
when
the
when
the
rubber
hits
the
road
we're
probably
going
to
be
in
a
world
of
pain,
when
we
realize
that
things
don't
actually
line
up
completely
exactly
right
right,
but
I
think
that's
where,
like
giving
thought
to
kind
of
interfaces
and
stuff
a
little
bit
and
and
hashing
a
little
bit
of
that
out
again
in
a
future
session,
might
be
useful.
A
A
A
Like
that
and
say,
hey
we've,
given
this
some
thought
we
do
want
to
keep
this
open.
We
want
to
kind
of
have
future
things
coming
in
good
examples
are
cpu
memory,
io,
pixie
stuff,
who
knows
what
else
down
the
pike
right
and
really?
This
is
meant
to
be
broad
and
kind
of
it's.
You
know
we
are.
We
have
given
thought
to
the
future
right.
B
All
right,
so
it
sounds
like
I
think,
jonathan
you're
gonna
work
on
the
doc.
Everyone
else
you'll
have
a
chance
to
review
it
and
then.
C
Do
do
you
need
any
help,
jonathan
reading,
some
of
the
sections?
Yes.
C
C
Be
the
outline
you
know
should
it
should
should
the
outline
would
be
more
like
you
know
what
we're
building.
C
I
think
what
we
went
through
is
is
really
good,
like
you
know,
as
a
overall,
like
you
know,
starting
with
this
section,
what
is
the
overall
vision
and
what
is
going
to
be
the
like,
the
the
current
and
like
maybe
potentially
future
things
that
we
we're
gonna,
add
and
then
maybe
some
architectural
section
where
we
present
these
are
the
couple
of
you
know,
topologies
that
you
can,
you
know,
deploy
and
then
you
know
going
through.
C
C
A
Yeah
and
if
you
want
to
help
with
the
I
mean
the
details
of
kind
of
where
you
go
into
the
more
specific
side,
you
know
you're
you're,
probably
sitting
on
that,
but
if,
on
the
kind
of
the
overview
section
and
architecture
stuff,
if
you
want
me
to
take
a
pass
at
it
too,
like
like,
you,
can
draft
it
up,
and
if
you
want
me
to
review
it,
let
me
know
I'll
I'll
be
happy
to
take
a
look
at
that.
Stuff
too,
add
comments
great.
D
A
It
yeah
no
go
for
it.
Jonathan,
you
know,
go
for
the
first
draft
and
then
I'll
take
a
look
after
and
if
I
have
any
comments-
or
I
can
just
edit
in
line-
and
we
can
kind
of
iterate
over
that
quickly
and
I
don't
think
we'll
have
to
iterate
too
many
times,
yeah.
C
And
I
can
like
help
with
you
know
the
the
the
topics.
You
know
you
have
the
skeleton
already,
but
you
know
if
any
rewrite
or
anything,
I
think
I
guess
we
still
need
to.
You
know
rewrite
pieces
of
it
maybe
get
more
context
and
so
on.
So
let
let
me
know.
D
Cool
all
right,
all
right
awesome,
so
I
I
think
I'm
I'm
really
happy
with
where
we
we
got
to
kind
of.
I
think
we
you
know,
I
don't
know
if
it's
time
to
to
to
summarize,
but
you
just
you
know
it
in
you
know
we're
not
done
yet
but
like
in
the
interim.
Thank
you
for
for
all
the
the
fruitful
discussion.
I
don't
know
if
michael
will
watch
the
recording
I'll
I'll.
Thank
him
to
you
know.
Thank
you.
Thank
you.
So
far
for
the
yeah.