►
From YouTube: DASH Workgroup Community Meeting 20220511 (May 11, 2022)
Description
May 11, 2022 Community Call
Discussed HLD updates, link to SONiC HLD, YouTube Channel, SONiC on DPU.
A
So
I
wanted
to
let
everybody
know:
I
heard
your
feedback
around
in
the
the
difficulty
in
accessing
the
meetings
etc
and
having
to
do
permissions
one
by
one.
So
I
worked
over
the
weekend
to
create
this
dash
desegregated
api
for
sonic
host.
Can
you
see
my
screen
by
the
way?
Yeah?
Okay?
So
I
worked
to
create
this
channel
and
this
channel
I've
gone
ahead
and
uploaded
there.
A
A
A
A
Okay,
no
child,
so
another
thing,
michael
miele
and
I
have
gone
ahead
and
revamped
the
high
level
design
and
we
did
put
in
a
pr
for
it,
and
so,
if
you,
but
basically
it's
held
in
the
general
folder
in
the
design
section
and
it's
called
a
high
level
design
here
and
so
we've
gone
and
added
more
to
each
section.
This
is
just
the
table
of
contents
here,
if
you
scroll
down,
though
we
do
the
introduction
flush
out,
why
we're
doing
dash
the
objectives?
A
And
if
you
read
through
here,
we
we
talk
about
the
different
scenarios
and
you
know
try
to
do
some
some
drawings
to
further
explain
what
we're
doing
and
then
all
of
the
different
pieces
of
our
project,
whether
it's
testing
sdn,
the
the
switch
nos
you
know,
the
sonic
switchnos
p4
scenarios
testing.
So
if
anyone
wants
to
have
a
look
at
this,
I
put
this
in
the
notes
last
week,
but
it
is
quite
a
bit
more
fleshed
out
christina.
D
I
I
haven't
followed
completely
everything,
but
I
think
one
of
the
piece
that
is
missing
here
is
a
sort
of
road
map
and
faces.
You
know
we
for
the
moment.
The
attempt
has
been
to
broad
this
dash
api
as
much
as
possible
to
cover
everything
that
come
up
to
our
mind,
but
I
think
if
we
want
to
be
successful
in
delivering
something
we
need
to
face
this
feature
in
the
sort
of
road
map
in
which
we
say.
D
Okay,
you
know
we
have
a
release
1.0,
but
as
we
score,
we
have
a
release
2.0
with
the
swiss
goal,
and
then
we
have
a
release
3.0.
But
that's
that
other
goal
I
don't
personally
but
willing
to
listen
to
all
the
other
on
the
core.
I
don't
think
that
is
realistic
to
put
in
release
1.0
or
we
are
all
what
we
have
discussed
up
to
now.
D
A
B
B
E
E
So
if
the
point
is
a
well
taken,
probably
we
need
to
have
a
brainstorming
session
like
chris
is
suggesting
perhaps
when
he
created
pr
about
it,
creating
a
roadmap
for
the
various
possible
release,
so
the
community
can
participate
in
defining
because
you
guys
know
better
the
details,
how
the
things
are
going
to
ship
up.
I
agree
with
that,
and
this
probably
will
go
very
well
along
with
this
high-level
design
document
that
tries
to
define
the
context
in
which
all
these
things
are
happening
so
yeah.
I
agree
with
yeah.
D
E
D
A
D
You
know
if
we
prioritize
the
serious
appliances,
it
seems
to
be
the
case
in
the
documents
of
course,
and
if
the
serious
appliance
as
a
a
processor,
complex,
plus
a
bunch
of
gpu,
I
don't
think
we
had
enough
enough
of
a
discussion
on
what
goes
on
the
processor
complex
or
what
goes
on
the
dpu,
what
kind
of
functional
release
and
if
we
are
unsung,
how
are
we
going
to
run?
I
assume
we're
on
sony,
but
how
are
we
going
to
run
it.
D
F
A
D
F
D
And
that's
great:
we
just
need
to
understand
how.
Now
now
the
question
of
financial
partitioning
really
becomes
very
important,
because
if
we
have
a
single
interface
from
the
outside
and
we
need
to
propagate
to
a
different
gpu,
we
really
need
to
understand
the
functional
partitioning
between
the
maze
view.
H
H
D
F
So
I
think
this
is
the
case
of
a
smart
switch
device
right
so
there
in
that
it
will
have
like
one
sonic
running
on
smart
switch
and
internally
it
manages
all
the
associated
dpus.
But
if
the
dpu
itself
is
an
appliance,
then
sonic
will
be
running
as
an
instance
in
that,
and
then
the
controller
or
the
northbound
can
be
used
for
program
that
dpo,
so
it
it
depends
on
how
we
are.
E
Christina,
but
talking
about
phrases,
if
you
go
up
one
more
one,
one
dpu
diagram,
one
dp,
just
one
dpu
yeah
without
plans,
without
nothing,
just
one
dp
this
one.
So
is
this
the
case
that
the
phase
zero
phase
one
offers
whatever
you
want
to
call
where
we
have
to
prove
that
we
can
talk
to
the
dpu
one
dp,
not
nothing
in
between
one
dp
on
the
car.
So
this
will
flush
out,
probably
some
of
the
basic
you
know
mechanism.
Then
then
there
is
a
the
complete
the
com
more
complex.
E
You
know
of
configurations
where,
with
the
switch
smart
switch
and
the
appliance,
that's
we
will
have
another
phase
like
silvan
is
saying
so
would
be
more
appropriate
to
start
fleshing
out
the
the
first
part.
If
we
put
this
diagram,
there
means
that
we
need
to
implement
this
and
and
see
how
we
can
you
know,
have
a
sonic
running
on
the
pew
on
one
dpu,
my
understanding,
my.
D
A
F
A
Thanks,
martin
yeah,
that's
that's
what
microsoft
is
working
on
right
now,
what
other
companies
are
doing?
I'm
not
sure.
But
when
I
joined
the
team,
the
appliance
was
the
first
priority
with
smart
switch.
You
know,
really
the
focus
is
more
it'll
be
towards
smart
switch
in
the
future.
When
the
technology
suppliers
can
create
these
devices.
A
A
The
appliance
is
an
appliance,
it's
just.
You
know
two
servers
in
a
rack
with
dpus
and
then
a
regular
sonic
tour
acting
as
the
t0.
That's
it's
not
all
combined
a
smart
switch.
It
would
all
be
combined
into
the
same,
fixed
form,
chassis
or
not,
chassis,
fixed
form,
module,
3ru,
2ru
kind
of
unit.
That's.
A
F
A
C
A
A
E
Christina
suggested,
so
let's
use
this
high-level
design
documents,
including
the
sonic
integration
document,
obviously
to
flesh
out
to
the
faces.
If
it's
possible,
that's
an
idea
and
nothing
should
go
this
way.
So
they
may
answer
the
question
that
silvan
is
asking,
because
the
main
reason
for
having
this
document
this
just
to
create
the
context
and
give
space
to
this
kind
of
discussions.
E
If
we
don't
have
anything
in
front
of
our
eyes
and
diagrams,
they
may
be
not
correct,
but
those
diagrams
will
define
the
boundaries
in
which
we
are
listening.
So
this
could
be
a
way
to
start
moving
forward
and
we
create
a
pr
that
also
included
the
various
phases
that
we
are
thinking.
That
may
happen
and
with
the
discussion
about
you
know,
smart
switch,
one
dpu,
multiple
gpu
appliance
and
all
that,
so
that
we
can
put
more
information
in
this
kind
of
documents
linking
with
two
faces.
E
A
I
D
F
D
A
Yeah,
we're
developing,
you
know
sonic
for
the
dpu
and
we're
developing
the
pipeline,
and
you
know
the
the
hope
is
to
have
it
completed
by
the
time.
Smartswitch
comes
around,
you
know
in
possibly
december
2022.
That
was
the
target,
because
you
can
you
can
port
the
feature?
Development
or
I
mean
the
dpus
can
go
in
an
appliance.
They
can
go
on
a
smart
switch.
They
can.
You
know
we
can
move
those
around.
So
no
not.
A
I
think
we
are
going
to
need
to
have
gerald
come
and
talk
to
that
because
we
did
meet
on
this
this
week,
and
you
know
we.
I
think
just
said
that
before
no
sonic's
gonna
run
whether
it's
on
this,
the
switch
cpu
or
the
dpu
itself,
and
then
the
containers
that
we
use
within
sonic
are
what
can
be
chosen
selected
or
moved
around.
G
A
A
So
this
this
section
of
the
document
here,
where
we
talk
about
fast,
pass,
slow
path.
You
know
inbound,
outbound,
etc
we're
working
on
improving
this
drawing
and
we're
probably
going
to
integrate
our
changes
probably
later
today,
and
so
each
of
these
boxes
within
the
path
will
be
filled
out
with
more
information.
A
E
A
Right
right
so
up
here
in
the
descriptions
is
where
we
talk
about.
Okay,
you
know:
once
we
get
a
packet,
then
we
need
to
determine
direction
match
the
e,
and
I
you
know
here,
decap
it
if
it
came
from
slb,
do
the
gre
key,
so
we're
probably
going
to
move
those
fast
pass,
slow
path
with
each
piece
in
each
box,
probably
up
here
in
this
area,
so
that
it
can
be
a
little
bit
more
tied
to
the
description.
A
A
And
the
we
also
went
over
the
smart
switch
rfi
answers
yesterday
and
sourcing
will
be
working
on,
including
everyone
for
a
response,
for
if
there
are
more
questions
with
respect
to
schedule
or
anything
else,
they
want
to
know
so
each
guy
should
be
expecting
some
kind
of
response
from
sourcing
within
the
next
week
or
so.
I
would
think.
A
K
Okay,
yep,
sorry
about
that.
I
was
saying,
like
I
completely
agree
with
silvano
in
terms
of
like
understand
the
phasing
of
like
what
comes
first,
do
we
need
to
support
appliance
and
smart,
switch
or
or
just
smart
switch?
Also
like
one
of
the
concerns
I
have
and
I've
seen
this
a
little
bit
throughout
this
process.
K
Is
that
when
you
focus
on
one
thing
like
say
v-net
to
v-net,
you
know
we
can
come
up
with
an
implementation
for
being
a
divine,
but
if
we
don't
have
the
full
understanding
of
nat,
if
we
don't
have
the
full
understanding
of
h
a
like
we'll
come
up
with
an
implementation,
that's
great
at
veena
tovina,
and
then
it's
not
like
an
incremental
thing
to
add
h.a.
It
may
be
that
we
have
to
completely
design
redesign
the
way
v-net
to
v-net
works.
K
That
was
my
understanding
and
the
smart
switch.
This
sdn
controller
sees
like
one
instance
of
sonic,
and
then
that
instance
of
sonic,
you
know,
has
some
kind
of
like
southbound
apis
to
the
individual
dpus,
which
themselves
are
running
like
a
thin
version
of
sonic.
You
know
like
a
lighter
weight
version
of
sonic.
K
I
just
wanted
to
make
sure
that
my
understanding
of
that
is
correct.
It
would
be
nice
from
my
perspective
if
the
appliance
kind
of
had
the
exact
same
in
terms
of
of
sonic.
You
know
meaning
like
that.
There
would
be
a
management
cpu
that
would
have
that
same
kind
of
southbound
interface
of
the
dpu.
It
seems
like
there's
a
burden
like
a
development
burden
to
be
able
to
support
kind
of
like
two
different
variants
of
sonic
on
the
dpu,
depending
on
whether
it
goes
in
an
appliance
and
or
in
a
smart
switch.
A
You
know
what
what
kind
of
usage
the
memory
for
example-
and
you
know,
will
we
need
to
make
a
change
and
move
around
the
containers
in
the
future,
so
yeah
I
get
what
you're
saying
and
it's
still
kind
of
under
review
under
development.
If
you
will
okay,
because
we
have
to
see
you
know
how
that
impacts,
the
performance
you
know
of
the
the
hardware,
you
know
it's
still
a
little
bit
up
in
the
air.
That's
what
I
got
from
our
last
meeting.
A
L
K
I'm
not
sure
how
you
determine
that.
I
mean.
Obviously,
some
of
that
memory
is
for
sonic
and
for
databases
and
different
things
that
are
in
sonic
itself,
but
of
course,
there's
a
lot
of
memory
that
that's
dedicated
to
the
data
plane
for
the
flow
table,
for
example,
and
I
think
that
the
size
of
the
flow
table
may
be
very
vendor
specific,
I
mean
some
vendors
might
be
able
to
store
flows
more
efficiently
in
their
data
plan
than
others.
L
L
You
allocate
out
connections
per
second
bandwidth
and
memory
use
and
you
kind
of
want
them
all
to
to
be
sized
to
each
other,
and
so
you're
you're
exactly
right
in
saying
that,
there's
going
to
be
some
variance
in
the
memory
usage,
but
at
least
at
least
once
we
get
to
the
sonic
os
sizing,
we
can
get
a
little
bit
more
specific
for
you.
Folks.
B
I
want
to
make
a
suggestion.
I
think,
when
we
come
up
with
some
representative
test
cases,
you
know
keysight's
working
on
some
performance
test
cases
right
now
scale
testing
and
I
think,
maybe
besides
just
providing
figures
of
merit
for
connections
per
second
etc.
Packets
per
second,
we
probably
ought
to
as
a
community
agree
on
a
few.
B
B
Microsoft
can
look
at
how
much
it
eats
up
in
sonic
database
etcetera,
and
we
can
have
some
figures
of
merit.
Maybe
that
could
be
a
you
know:
a
secondary,
a
secondary
and
then
we'll
have
agreed
upon.
You
know
a
table.
Here's
the
configuration
one
through
x
and
people
can
do
their
internal
and
external
measurements.
L
L
It
would
certainly
help
folks
real,
have
a
have
a
reference
point
to
what
something
looks
like
and
kind
of
within
the
the
same
idea.
There's
a
bounds.
The
idea
of
trying
to
box
this
by
establishing
like
a
min
and
max
footprint,
and
so
those
are
also
things
we're
looking
at.
But
that's
that
is
a
great
suggestion.
L
A
And
if
we've
closed
on
that
in
in
other
news,
you
know
marion
gave
us
a
fantastic
demo
last
week,
if
you
weren't
able
to
join
the
call,
maybe
take
a
peek
at
the
video,
so
that
happened,
we're
still
working
in
the
high
availability
working
group
towards
you
know
the
requirements,
definitions
and
quite
a
few
of
you
have
joined
that.
So
thank
you
for
that,
and
we're
also
still
moving
forward
with
behavioral
model
work
items
and
we'll
have
that
meeting
this
thursday,
so
other
than
that.
A
G
The
site
pdf
now
that
the
behavioral
model
is
there,
we
will
start
integrating
that
with
help
from
chris,
and
then
we
have
to
start
upstreaming
some
of
that
code,
that
we
are
developing
for
the
dash
side
and
integrate
that
and
with
the
behavioral
model,
and
do
that
demo.
That
date
specifically
has
no
not
yet
been
planned.
G
A
Okay
and
that's
all
the
notes
I
had
for
this
week,
we
do
have
the
translation
of
the
json
to
sonic
gang
over
in
engineering's,
hands
right
now,
sdn
engineering's
hands
and
we're
hoping
to
have
a
review
that
help
possibly
by
next
week.
So
thank
you
prince
for
doing
that
work
and
unless
anyone
has
anything
else,
I
can
stop
the
recording
and
we
can
close
for
the
week.
B
F
F
B
That's
great
just
as
a
reminder
to
people
there
they've
been
earlier
discussions
about
this
kind
of
a
test,
maturity
stages
and
one
of
the
one
of
the
one
of
the
ideas
that
we
proposed
was.
We
have
a
single
way
to
represent
the
configuration
that
we
can
use
to
configure
the
data
plane
through
different
apis
up
the
stack.
You
know:
psi
interface,
cyretis,
eventually
gmi
and
the
same.
B
All.
The
interfaces
should
be
able
to
be
driven
by
a
common
representation
of
test
cases
or
test
vectors,
and
then
some
translator
would
turn
into
the
right
interface.
So
we
don't
have
to
keep
rewriting
every
test
at
every
level.
So
that's
a
goal.
So
this
this
json
format
is
key
to
that
kind
of
the
rosetta
stone.
D
B
Well,
just
sort
of
in
high
level
terms.
If
I
want
to
configure
a
mapping
or
a
acl
rule,
I
should
be
able
to
you
know
in
english.
I
can
say:
here's
the
ip
address,
1.2.3.4
right,
you
can
put
that
in
json
and
then
a
python
script
or
a
wrapper
or
a
translator
can
say
I'm
going
to
turn
that
into
a
gnmi
message.
I'm
going
to
turn
that
into
a
psi:
thrift,
configuration,
etc.
B
The
mappings
pretty
straightforward
right,
there's
not
a
lot
of
transformations,
it's
really
just
reformatting
almost,
and
so
that
should
be
a
mechanical
process.
That's
the
goal
versus
writing
completely
separate
siloed
sets
of
tests
that
are
all
ninety
percent,
same
content,
but
different
details,
and
then
these
test
cases
all
drift
and
get
maintained
separately
and
there's
no
correspondence.
That's
that's
something
I'd
like
to
avoid.
So
my
my
understanding.
B
B
B
M
A
Sonic
adds
value
a
couple
of
different
ways:
microsoft
in
our
cloud,
we
don't
have
the
resources
to
support
multiple
command
line,
api,
etc.
You
know
when
we're
in
an
operations
phase,
and
so
what
sonic
gives
us
is
the
one
mechanism
for
our
engineers
and
our
duty
responsible
individuals
and
the
people
troubleshooting
to
they
have
one
way
to
access
and
troubleshoot.
B
A
B
Just
because
our
test
cases
are
going
to
be
easy
to
write
in
this
one
case,
because
the
dash
api
is
on
transparent
almost
through
all
the
stack.
You
know,
the
data
objects
are
the
same.
That
doesn't
mean
sonic
in
general.
Isn't
an
appropriate
approach
right
for
all
these
other
100
reasons.
So
this
is
just.
A
Switch
perspective,
you
know,
we've
got
cisco,
we've
got
arista,
we
got
sonic
on
celestica,
for
example,
in
our
our
network,
engineers
and
our
people
have
to
know
all
the
commands
for
the
different
operating
systems
etc,
and
so
you
know
it
we,
we
can't
consume
more
than
a
certain
number
of
operating
systems
into
our
infrastructure
and
still
support
it,
and
so
that's
kind
of
likening
it
to
the
switch
area.
Except
for
now
we're
in
the
dpu
area
go
ahead.
Mario,
I'm
sorry,
I
didn't
mean
to
cut
you
off.
M
M
D
A
Well
again,
we're
working
through
that
now,
as
we
understand
the
resources
that
are
consumed
when
we
have
sonic
on
the
npu
versus
the
dpu
and
what
we
talked
about
with
james.
So
I
think,
as
we
move
forward
and
understand,
you
know
how
the
resources
are
consumed,
we'll
know
more,
but
right
now
we
I
don't
know
that
we
have
the
exact
answer.
D
D
D
A
Yeah
yeah,
definitely
we
have
to
balance
that
with
our
operations
as
well,
though
you
know,
we
have
to
be
able
to
see
in
and
control
the
dpu
from
a
single
point
so
that
we're
not
running
multiple
operating
systems
to
support
in
the
azure
infrastructure.
We
have
millions
of
nodes,
millions
and
it's
just
not
scalable.
F
I
think
I
I
agree
with
christina
here.
So
the
point
is
we
want
kind
of
a
standardized.
You
know
os
for
managing
the
dpu.
The
other
thing
is
we
totally
understand
about
the
performance
part,
so
that
will
be
one
of
the
main
priority.
For
you
know,
running
sonic
on
the
dpu
and
considering
the
scaling
and
performance
will
be
a
priority.
Yes,.
H
A
A
A
A
Okay,
everyone
can
go,
get
a
cup
of
coffee
or
a
drink
before
their
next
meeting.
So
I
want
to
thank
you
for
your
time
and
please
ping
me
offline
or
in
email.
Whatever
anything
you
think.
I
need
to
be
like,
for
example,
this
this
schedule,
anything
that
you
want
to
see
happen,
I'm
happy
to
take
it
in.