►
From YouTube: DASH Workgroup Community Meeting 20220525 (May 25, 2022)
Description
May 25, 2022
Q&A re: last week's demo
SAI PTF update
A
With
our
discussion
from
last
week's
meeting,
if
someone
can
give
me
a
yes
or
a
no,
yes,
you
can
see
it.
Yes,
oh
okay,
great
great,
and
so
last
week
we
had
marion
presenting
on
the
the
demo
for
us
and
we
we
didn't
get
a
lot
of
time
for
q
a
at
the
end.
I
was
wondering
if
you
guys
wanted
to
spend
a
little
bit
of
time
on
q
a
for
this
today.
C
B
C
B
C
So
goes
on
top
of
that.
No,
I
understand,
but
let
me
restate
the
existing
test
case
in
your
pull
request.
Just
has
a
simple
c
binding
test
that
verifies.
You
could
send
a
message
over
p4,
runtime,
etc.
It's
just
a
simple
test
case
with
no
scithrift
just
psi.
Do
you
plan
on
adding
more
cases
to
that,
or
is
that
the
end
of
your
work
in
this
effort.
B
C
Okay,
so
in
order
to
get
to
this
software
testing
model
with
the
scithrift
there's
an
effort
to
create
a
workflow
and
or
build
infrastructure
to
tie
it
into
the
cythrift
and
then
write
test
cases.
On
top
of
that
is
that
correct?
Then,
if
we
want
to
go
through
this
bmv2
behavioral
model,
you
know
and
have
test
suites
for
that
against
the
law.
Okay,
just
wanna
get
it
out
there,
there's
now
kind
of
another
whole
phase
to
be
done.
D
D
Maybe
we
can
collaborate
even
more
and
keysight
can
also
add
chris,
as
chris
was
mentioning
overlay
test
cases
as
well
into
the
framework,
and
we
will
also
start
up
streaming
some
of
the
score
once
we
review
into
the
sci
repo
dash
repo
and-
and
these
are
the
things
we
can
also
conclude
in
those
sessions
as
to
where
the
site
ptf
for
dash
will
reside
with
repo
and
also
the
psy
apis.
The
list
of
psy
apis
that
are
going
to
be
part
of
dash
which
are
taken
from
the
sonic.
D
Sci
apis
right,
the
list
of
the
sonic's
apis
that
we
have
if
we
can
have
a
list
of
what
are
those
apis
that
will
pertain
to
dash.
That
kind
of
you
know
detailed
conclusion
on
each
of
these
ips
will
be
good
to
have
a
full
list
of
those
apis
that
we
need
for
dash,
and
then
we
can
implement
all
of
those
inside
pdf
as
well,
and
to
have
that
as
a
future
reference
for
what
are
all
the
dash
apis.
You
know
it's.
D
Sure
I
have
one
of
the
previous
old
draft
lists
from
november
december
time
frame.
I
had
sent
an
email
to
you,
maybe
a
few
weeks
ago
when
there
was
a
question
of
whether
some
of
these
test
cases
pertain
to
dash
or
not
so
yeah.
If
we
can
go
through
that
list,
one
more
time
we
can
have
a
we
can
all
meet
together
in
a
different
sub-community
meeting
and
then
conclude
on
that
that'd
be
great.
A
Kind
of
how
this
group
started
or
began
as
the
dash
testing
work
group-
and
we
you
know,
shifted
it
to
overall
dash
because
the
testing
questions
kind
of
exposed,
the
the
engineering
questions
we
needed
to
answer.
So
we
could
go
back
to
you'd
like
to
set
up
my
weekly
format.
Like
that
sure
I
agree.
I
agree.
C
Oh
yeah,
sorry,
I
was
basically
echoing
what
reshma
said.
It's
probably
time
to
start
doing
that
and
probably
needs
to
be
a
small
focus
group
to
begin
with,
because
I
think
part
of
it's
just
getting
the
infrastructure
and
kind
of
the
hello
world
on
thrift
working
you
know
and
then
and
then,
when
we
start
getting
some
infrastructure
in
place,
probably
more
people
be
interested.
C
There's
kind
of,
I
think,
there's
two
ways
of
handling
this
and
then
maybe
they're
both
going
to
be
used.
One
is
an
explicit
semantic
version
of
the
api.
If
you
want
to
call
that-
and
maybe
that's
maybe
that
semantic
version
is
related
to
the
version
of
the
p4
model
itself
and
there's
also
just
github
has
all
the
built-in
you
know
commit
level
tracking,
you
can
pin
things
to
certain
versions
so
that
when
you
run
a
test,
you
know
all
the
component
versions
that
were
involved.
C
So
that's
probably
something
we
just
need
to
decide
together.
I
brought
up
this
configuration
management
question
sort
of
rhetorically
several
months
ago.
Yeah
you
did
yeah
so
yeah
we'll
need
to
come
up
with
some
mechanism,
that's
kind
of
baked
in
baked
into
the
whole
process.
That's
a
good
point.
Lisa.
F
Yeah
on
the
same
subject
guys,
you
know
one
thing
that
I
noticed
when
we
started
out
this
journey.
We
saw
that
the
psi
folder
on
github
had
you
know
two
subfolders
one
was
overlay
and
one
was
underlay
right,
so
those
are
already
pre-generated
apis
that
actually
you
know
it
had,
and
in
the
underlay
it
had
the
older
set
of
apis
that
basically
we
used
in
sonic
right
so,
but
it
was
a
subset
of
those
under
the
apis.
F
Now,
with
the
introduction
of
you
know,
auto
generation
of
these
overlay
si
apis.
We
have
really,
you
know,
removed
those
underlay
api's
subfolder
from
there
now
you
know.
Could
we
bring
those
things
back
so
that
we
know
that?
Okay,
these
are
the
only
underly
api
that
pertains
to
dash,
and
then
we
just
you
know,
have
them
be
there
because
they
are
predefined
apis,
not
auto
generated.
B
B
We
took
a
subset
of
that
and
the
list
of
attributes
that
require
that
are
required
to
be
supported
in
dash
are
listed
in
sonic
dash
design,
and
let
me
post
a
link
to
it
in
a
moment,
so
they
are
in
the
repository.
They
are
just
not
as
header
files,
because
it's
harder
to
maintain
the
list
that
way
and
those
header
files
won't
be
used.
Anyways.
We
will
be
using
the
full
header
files,
just
not
all,
of
the
attributes.
F
Okay,
yeah,
that's
good
yeah,
that's
good
at
least
have
some
sort
of
a
reference
to
it
to
say:
okay,
these
are
the
ones
that
we
believe
as
of
now
pertains
to
it,
and
that
could
change
as
we
move
and
then
people
can
refer
to
it
for
the
most
latest
one
into
their.
You
know
psi
repository
itself
right.
The
ocps
psi
repository.
C
F
B
C
B
C
B
So
this
is
the
list
that
we
think
will
be,
and
it's
up
to
a
change
that
we
think
will
be
actually
used
by
dash
sonic
for
the
underlay
like,
for
example,
if
you
want
to
create
a
board
which
will
be
done
on
any
device.
If
you
want
to
create
a
host
interface,
if
you
want
to
assign
speed
to
a
port
stuff
like
that
general
management.
B
D
Underlay
routing
right,
yeah,
underlay
routing,
is
a
must,
without
which
we
can't
really
use
overlay
so
yeah.
I
will
go
through
this
list
because
now
we
are
talking
about
one
use
case
at
the
moment
and
then
you
know
we
will
need
as
an
edge
device,
ankles
and
lag
and
other
things
that
might
you
know
require
for
regular
functioning
of
the
smartnik
device
that
should
also
be
included
under
dash.
C
D
A
If,
once
we
go
through
it
and
we
decide,
we
like
it,
we'll
move
it
into
the
main
diagram,
but
we're
doing
more
of
like
a
flowchart
view
for
here,
like
packet
direction,
flow
and
transform.
We
start
we
look
for
the
direction
we
we're
trying
to
figure
out
if
we're
inbound
or
outbound
based
on
the
destination,
mac
or
the
source
smack
blah
blah.
You
know,
are
we
on
the
fast
path
or
not?
And
then
we
have
a
set
of
actions
that
happen
afterwards
and
where
you
know,
of
course
you
decap
it.
A
You
know
if
you
come
from
slb
or
whatever
try
and
find
a
match
in
the
flow
table.
These
are
the
inbound
and
outbound
fast
path
and
then
we're
also
working
on
fleshing
out
the
the
slow
path
here,
trying
to
make
it
more
readable
for
you
guys
and
for
everybody,
so
we're
working
on
this
and
then
I'm
also
working
on
I'm
going
to
stop
sharing
my
screen.
A
A
A
Let
me
do
40
there
and
you
know
possibly
if
we're
trying
to
force
traffic
through
an
nva.
I
don't
have
this
all
finished,
but
the
different
you
know
the
different
destinations
that
we
can
have
here,
and
so
I'm
working
on
this
and
I
hope
to
insert
it
into
the
routing
document
you
know
v-net
to
v-net
would
be
the
first
one
I
do
once
I
get
this
template
done
where
we,
you
know
kind
of
insert
the
appliance
and
then
we
do
the
communication
between
the
boxes.
A
Oh,
thank
you
thanks,
yeah
we're
working
on
making
them
better
in
the
background
and
trying
to
flush
out
each
piece.
So
thanks
also
in
other
news,
we've
been
having
the
the
behavioral
model
and
the
high
availability
smaller
working
group
meetings
and
trying
to
make
progress
in
those
meetings
as
well.
So
those
happen
on
tuesdays
and
thursdays,
so
we're
moving
forward
with
high
availability.
A
Oh
a
question
for
you
guys
next
week
is
memorial
day
on
monday,
and
I
didn't
know
you
know
the
community
meetings
on
wednesday
and
I
didn't
know
if
people
would
be
out
of
office
next
week
or
the
majority
would
be
out
or
you
know,
people
at
microsoft
sometimes
tend
to
take
the
week
if
they
have
kids
or
they
take
that
monday
and
then
they'll
take
the
rest
of
the
week.
But
I
wasn't
sure
what
you
guys
were
thinking
for
this
meeting.
A
A
A
G
Chime
in
if
I've
missed
anything
critical,
basically,
my
understanding
is
roop
is
looking
at
implementing
some
of
the
pna.
Things,
for
example,
data,
plane,
add-on,
miss
into
table
entries
for
useful
for
dash
and
other
features,
and
when
he
wants
to
implement
this
on,
the
bmv2
software
switch
an
open
source
software
switch.
That
puts
them
around
for
several
years.
G
We're
discussing
basically
an
alternate
extern
function,
api
that
basically
includes
the
condition
as
a
parameter,
and
so
we
were
discussing
what
that
type.
That
parameter
should
be
and
whether
it
supports
expressions
in
the
language
and
whether
the
bmv2
open
source
compiler
already
supports
that
or
not,
and
I've
been
working
through
some
example.
Programs
that,
I
believe
demonstrates
that
it
does
already
support
that
and
so
working
towards
an
implementation
of
these
things
in
the
bmp2
open
source
software
switch.
H
H
Implemented
a
version
of
the
api
we
proposed
for
connection
tracking
and
but
we're
trying
to
go
through
in
the
meeting
with
the
rest
of
the
community,
the
pna
community
pros
and
cons
of
various
approaches
and,
and
so
forth,
so,
like,
like
andy,
said
so
yeah.
It's
it's
to
basically
do
the
connection
tracking
use
case
that
many
of
you
are
familiar
with.
A
H
A
Yeah
yeah,
it's
been
been
a
busy
spring
for
sure,
and
especially
with
the
p4
workshop
and
all
the
presentations,
and
you
know,
I've
really
enjoyed
attending
and
learning
more
about
these
different
things,
and
you
know
so
thanks
for
inviting
me
to
all
of
those
so
stop
the
recording
and
send
out
the
notes
as
usual.
I
appreciate
your
time
and
have
a
good
rest
of
the
week.
Everyone.