►
From YouTube: DASH Workgroup Community Meeting 20220420
Description
April 20, 2022 Community Call
B
A
B
C
B
So
most
of
the
test
framework
itself
is
auto
generated
and
the
auto
generation
needs
to
sort
of
take
place
at
every
sai
version.
After
releasing
the
new
version
of
psi,
we
have
the
implementation
for
these
wrapper
functions.
Automated
there
are
a
few
auto
generated
files
that
you
know
the
the
three
main
auto
generated
files.
B
B
B
We
might
want
variable
number
of
ports
two
to
four
ports
to
start
with,
so
that
is
the
main
effort
here
to
adapt
the
framework
to
us
to
take
as
input
the
number
of
ports
and
make
it
generic
enough.
So
it
couldn't
work
on
various
devices,
not
just
the
dash
device,
so
that
that
the
number
of
ports
is
not
confined
to
just
two
to
four
ports
for
dash
device.
B
D
Okay,
thank
you
hey.
I
want
questions
before
making
high
level
questions
so
with
the
is.
The
is
the
goal
that
you
know.
This
is
going
to
be
something
that
everyone
can
use
in
an
automated
manner.
You
know
versus
I'm
trying
to
draw
a
line
between
this
versus
what
keysight
is
trying
to
do
and
contributing.
B
Yeah,
so
this
is
the
sci-test
framework
itself,
which
is
auto-generated
and
it
can
work
on
any
back-end.
You
know,
so
it
is
generic
enough
for
everyone
to
use,
and
also
not
just
any
hardware
but
also
soft
switch
like
for
example,
bmw
would
have
a
thrift
listener
and
that
could
use
use
this
framework
also.
E
Suresh
this
is
christina
when
we
started
these
meetings
back
last
november
december.
Maybe
you
weren't
joining
at
that
time.
Keysight
had
written
a
five-stage
maturity
model
for
testing
and
one
of
the
models
I
believe,
was
model
three
incorporated
the
side.
Ptf
testing,
as
we
moved
through
the
maturity
of
testing,
is
that
right.
Chris,
the
background.
F
Yeah
that
some
of
the
context,
some
other
context,
I'd
like
to
add,
is
this-
builds
on
the
well-established
sonic
test
framework
and
part
of
that
is
not
just
the
scithrift
control
plane
to
configure
the
platform,
but
also
a
scappy-based
packet,
sender,
receiver
and-
and
you
know,
comparison,
logic
and
people
are
familiar
with
scappy.
It's
a
python
packet
generation
testing
framework,
that's
not
really
line
rate.
It's
it
sends
packets
out,
basically
an
ethernet
port
into
a
device
under
test
or
a
virtual
port,
it's
not
for
line
rate
work
or
connection
per
second
testing.
F
So
this
is
one
element
of
the
of
the
test
framework
and
it's
great
for
writing
kind
of
packet
at
a
time
tests.
But
if
you
want
to
test
something
that
tests
connections
per
second
for
stateful
connections,
you
really
need
a
hardware
tester
or
a
virtual
version
of
that
at
lower
rates
and
that's
an
entirely
different
type
of
test,
so,
for
example,
the
hero
test
that
we're
still
working
on
and
we'll
be
sharing
completely
with
the
community.
F
B
It
the
tests
themselves,
the
test
cases
and
those
implementations
still
need
to
be
added.
On
top
of
the
framework
itself,
and
as
I
mentioned,
we
have
lots
of
test
cases
that
we
can
use
at
the
moment,
but
I
think
keysight
and
intel
can
collaborate
to
add
the
overlay
use
cases.
Those
test
cases
that
are
not
there
at
the
moment.
D
A
A
So
the
main
requirements
were
taken
during
implementation,
our
new
approach,
so
a
modified
test
which
already
exists.
We
already
in
the
pdf,
have
lots
of
tests,
as
you
know
that
this
test
should
be
able
to
run
on
the
regular
switcher
as
well
as
support
the
new
one.
So
new
platforms,
introduction
of
this
new
approach
should
be
should
not
affect
existing
test
cases,
so
the
test
cases
should
not
fail
and
platform.
Specific
api
should
be
also
supported.
A
A
So
regroup
test
cases
which
require
the
same
amount
of
resources
in
our
cases,
tests
test
ports
allow
test
cases
to
be
implemented
on
its
own
configuration,
so
don't
be
strict
on
the
basic
configuration
and
depend
on
the
base
configuration
during
the
ptf
setup
and
to
add
the
mechanism
to
skip
the
test
if
there
are
no
available
ports,
so
some
changes
performed
it's
a
updated
si
ptf
proposal
document
itself
change.
It
helpers
api.
A
B
A
A
Let
me
just
describe
the
section
without
degeneration
based
on
the
images
and
after
that
the
picture
will
be
more
clear.
So,
on
the
left
side,
we
have
the
pds
test
server,
where
we
have,
for
example,
the
vlan
test
written
in
the
python
as
a
part
of
the
unit
testing,
which
uses
the
functionality
from
the
python
helper
classes,
which
already
exist
and
uses
the
psi
adapter.
A
A
A
Everything
is
performed
using
the
parallel
better
models
and
we
have
the
again
gen
psi.
Lpc.Pld
script,
which
uses
the
doxygen
to
generate
xml
files
which,
based
on
the
headers,
sorry
headers,
which
creates
a
so-called
saying
metadata,
and
this
metadata
is
stored
in
the
xml
files
and
and
based
on
this
xml
files
panel,
uses
this
libraries
and
create
the
insight
internal
objects
which
can
be
used
for
the
next
steps.
So
that's
the
first
part
of
the
generated
generation,
so
the
perl
script
uses
the
touch
engine
based
on
the
psi.
A
B
H
A
Okay,
so
let's
continue,
then,
let's
go
how
the
test
can
be
executed,
so
test
files
are
written
manually
in
a
python
and
they
call
functions
from
the
psi
adapter
pi
using
some
adapters,
some
additional
functionality
of
of
the
helpers
and
the
call
the
c-based
through
the
c-based
lpc
server.
They
call
the
c
functions
from
the
leap
sign
using
this
rift
and
serialization
the
serialization
mechanism.
So
it's
like
a
grpc,
but
it's
it
uses
a
little
bit
different
different
method.
A
A
A
I
will
stop
on
this
so
inside
the
basic
switch
configuration
is
created
like
like,
is
displayed
in
this
table,
so
we
have
24
parts
from
the
port
0
to
port
23,
which
are
configured
during
the
pdf
startup.
So
it's
a
setup
of
one
of
parent
helper
classes
and
during
this
phase
some
some
bridge
ports
are
created.
Ports
added
to
the
vlan,
tagged
and
tagged.
A
A
B
Just
to
add,
there
are
these
base
classes.
The
psi
helper
base
is
the
most
basic
switch
configuration
class
and
the
psi
helper
basically
will
derive.
What
is
that
in
the
scihalper
base,
and
it
will
allow
for
additional
configurations
and
inherits
from
the
psi
helper
base
class
where
changes
can
be
made.
A
H
A
Module
is
exactly
the
test
case
so
in
index
in
the
con
text
of
the
dash
and
to
support
smartnix.
We
have
introduced
two
new
methods,
so
they
set
up
in
the
lowercase
and
the
tier
down
in
case
which
do
not
perform
the
base,
switch
initialization
and
base
switch.
Configuration
like
it
was
described
in
the
table
above
yeah,
so
the
ports
are
not
configured
from
zero
to
24
and
in
this
case
we
are
able
to
perform
our
specific
setup,
which
is
exactly
needed
for
the
purpose
of
the
test
itself.
A
Okay,
to
reference,
the
physical
ports.
In
the
test
case,
we
use
a
port,
zero
port,
one
attributes
of
the
test
class
and,
if
and
additionally,
if
such
port
doesn't
exist.
So
if
we
don't
have,
for
example,
the
port
number
55
during
the
setup
or
the
run
test
and
procedure,
this
steps
will
be
skipped
and
the
tear
down
method
will
be
executed
to
perform
the
proper
cleanup
procedure.
A
A
A
And
this
one
okay:
here
I
have
the
tmox
a
couple
of
terminals
already
opened
and
the
ptf
itself,
where
we
have
the
basic
configuration
we
have
the
front
mat
dot
ini,
which
is
required.
I
have
some
binding
to
interfaces
and
the
test
group,
the
model
say
riff.pipe,
so
I'm
asking
the
pdf
to
run
the
test.
I
hope
my
setup
is
still
okay.
If
not,
I
already
created
some
screenshots
to
show
the
result.
A
A
The
second
test
should
be
skipped
because
of
leak
of
the
resources.
As
you
see
here,
the
first
has
been
passed.
It's
ipv4
fab,
lpm
test
this
exactly
the
second
one
has
been
skipped
because
of
not
enough
resources,
and
here
we
see
not
enough
resources
to
run
the
test
and
the
the
third
one
has
been
just
skipped
because
it
has
the
attribute
disabled
and
we
exactly
doing
market
not
to
be
run
at
all.
A
B
F
F
A
A
It
has
been
performed
very
easy
using
the
get
after
python
stuff,
so
we
are
just
checking
if
we
have
such
attribute
like
a
board
x,
which
is
already
described
in
the
documentation.
So
during
the
ptf
startup,
we
receive
the
information
from
the
switch
itself
about
the
amount
of
interfaces.
For
example,
we
go
to
16
and
we
will
get
we'll
get
attributes
in
our
base
class
from
the
port,
0
port
1
and
until
port
16..
So
if
we
don't
have
such
interface,
we
are
raising
the
skip
test
with
the
proper
message.
A
F
Can
I
make
a
comment
sure?
Okay,
thanks
for
the
presentation
and
thanks
intel
for
you
know
doing
all
this
enhancements.
It's
remember
we
asked
for
in
in
december
now
we
have
it
that's
great
and
I
think,
from
a
tactical
point
of
view,
this
might
first
have
importance
in
testing
the
underlay
portions
of
a
dash
platform
and
I'm
looking
for
you
know,
reactions
to
this
statement
because
we're
going
to
need
basic
setup
of
underlay
before
we
can
do
the
overlay
tests
and
the
overlay
tests
a
lot
of
them.
F
There'll
be
functional
ones,
but
we
also
have
things
like
the
hero
test
and
performance
tests
where
the
underlay
needs
to
be
in
place
before
we
even
start
the
overlay
testing
the
performance
testing.
So,
from
a
tactical
point
of
view,
it
might
make
sense
to
get
some
underlay
setup
tests
going
for
dash
and
then
and
then
the
overlay
tests
which
we're
working
on
sort
of
from
the
other
direction.
F
I
Crazy,
I'm
not
sure
what
you
want
to
test
in
the
underlay,
because
every
sdn
packet
is
being
is
working
from
underlying
point
of
view
in
the
hairpin
mode.
So
there
is
not
really
something
that
you
would
test
just
pack,
it
pack
it
and
pack
it
out
on
the
simple
and
then
you
have
packets
to
the
cpu,
which
is
like
bgp
and
other
stuff,
which
is
again
quite
simple,
just
based
on
some
criteria,
trapped
to
cpu
that
those
are
two
types
of
traffic
in
the
underlay.
B
So
the
way
I
look
at
it
is
that
we
have
the
base
set
of
psi
apis
right,
all
the
apis
that
we
have
in
the
list
today
that
we
have
looked
at
since
december
january
time
frame,
they
all
have
layer,
three
forwarding
apis
there,
the
subset
of
apis,
that
we
have
chosen
from
from
the
existing
psi
right
and
we
have
acculs.
We
have
other
useful
items
like
vxlan,
etc.
I
think
all
of
that
is
still
you
know.
B
Right,
I
I'm
still
looking
for
the
list,
but
I
think
I
will
find
it
very
soon,
but
definitely
we
are
not
going
to
be
using
all
the
test
cases
that
we
have,
which
are
massive
number
of
use
cases
and
test
cases
that
are
there
in
the
switch
side,
and
we
are
taking
only
those
subset
of
you
know,
features
that
we
will
work
on
based
on
based
on
the
dash
api
list.
Only.
I
I
So
is
there
an
expectation
from
this
framework
to
be
capable
of
doing
a
flow
based
testing
kind
of
like
doing
tcp,
handshake,
keeping
the
connection
all
the
stuff
and
maybe
having
some
obstructions
to
to
test
something
like
that
with
regards
to
connection
tracking
and
other
stuff,
or
is
it
more
considered
to
be
on
the
like?
The
test
case
is
just
one
package.
B
But
we
plan
to
do
that
to
add
connection
tracking
into
you
know
into
the
the
base
sciptf
framework.
What
we
have
right
now
is
the
is
the
base
framework
that
can
auto
generate
a
lot
of
things
for
us
to
not
have
to
worry
about
some
other
things
and
are
able
to
derive
from
the
base
classes
and
add
any
tests
that
we
want
using
this
framework,
and
it
goes
and
directly.
You
know,
interfaces
with
the
duty
takes
the
vendor
sdksi
itself
and
be
able
to
test
all
the
functionality
that
we
need.
B
So
that's
the
demo
for
what
we
have
at
this
time,
but
you
know
the
apis
or
what
psi
apis
that
we
want
to
test
is
up
to
us
and
then
what
we
can
add
more
test
cases
on
top
of
that
and
we
plan
to
basically
use
all
the
the
reporting
vxlan
article.
All
of
that
and
what
we
don't
have
right
now
is,
for
example,
ipsec.
B
Oh
yeah,
it
is
up
to
the
community
to
start
writing
tests.
Definitely,
and
we
can
come
up
with
all
the
different
categories
of
you
know
where
we,
whatever
marian
also
just
outlined.
We
can
have
them
as
well,
and
the
community
can
help
with
contribution
to
test
cases
in
all
the
areas
that
we
sort
of
come
up
with
together.
B
B
F
Yeah,
there's
there's
two
kind
of
two
prerequisites
in
order
to
write
test
cases
christina
one
is
we
have
a
stable
dash
overlay
api
right,
the
side
and
that,
if
that's
being
generated
from
the
p4
or
hand
generated
that
has
to
stabilize
right,
we
have
to
agree
on
that
final
interface
and
the
other
is
vendors
actually
having
a
side
library
on
their
device
or
a
software
version
of
it.
So
you
know
I
couldn't
sit
down
right
now
and
write
a
side
test.
F
You
know
for
an
overlay
test
case
because
I
have
neither
of
those
a
stable
known
psi
interface
or
a
device
that
can,
you
know,
implement
them.
So
there's
still
some
practical
things
to
consider,
but
we
could
certainly
plan
out
you
know
as
a
community
we
could
map
out.
Where
do
we
want
to
focus
our
test
efforts?
What
gives
us
the
most
important
stuff
first
and
do
the
planning
and
the
thinking.
F
G
No,
that's!
I
just
wanted
to
follow
up
on
what
marianne
mentioned.
You
know
it's
it's
something
you
know
marion
is
bringing
up
is
a
great.
You
know
insight
into
what
we
are
seeing
right
now,
especially
that
how
it
is
how
the
testing
of
dpu
is
different
than
the
testing
of
a
switch
right
and-
and
in
this
case
with
tpu,
we
have
these
flows,
and
then
we
have
these
connections.
G
B
Yeah,
that's
a
very
good
question.
It's
the
framework
itself
will
be
you
know,
available
and
auto
generated
based
on
the
psy
version
and
the
psi
version
that
we
use
we'll
have
all
these
new
apis
that
we
want
to
use,
and
it
will
completely
generate
the
framework
for
that
with
python
wrappers,
everything
that
we
need
and
we
only
need
to
add
the
test
cases
on
top
of
that
for
overlay
use
case,
for
example,.
J
Yeah,
I
think
we
will
have
it
at
the
end
of
a
project.
I
think
this
will
be
a
highly
interactive
process
in
which
we
use
the
test
to
to
fine
tune
the
model,
and
then
the
model
will
lead
back
the
test.
I
don't
see
how
how
else
we
can
do
it.
I
mean
the
tests
are
designed
to
verify
that
the
model
does.
What
is
supposed
to.
F
Do
understood,
I
guess
I
guess
we
have
to-
I
guess-
have
a
common
understanding
of
what
our
sort
of
checkpoints
you
know
where
to
say:
okay,
here's
here's
a
release,
an
internal
release
in
term
release
of
the
p4
behavior
model.
You
press
a
button
and
generates
psi
headers
nicely.
Thank
you
marion,
and
then
we
can
write
a
test
against
that.
That's
like
a
let's
say
a
cycle.
F
So
are
we
at
a
point
now
where
we
think
we
have
something
that
we
could
actually
write
a
test
for
if
there
was
a
libside
yeah,
you
know
do
we
want
to
have
like
there
is
no
website,
but
there's
headers
headers?
Okay.
So
how
shall
we
as
a
community
describe
or
version?
You
know
these
checkpoints,
because
once
someone
starts
writing
tests,
you
know
they
don't
want
to
have
the
rug
pulled
out
from
under
them
right.
We
want
to
have
sort
of
stable,
mini
internal
releases
or
something
so
maybe
that's
a
different
question.
I
Think
I
agree
with
silvano
here
because
it
will
be
a
feedback
loop,
so
tests
will
be
updated
based
on
science,
I
will
be
updated
based
on
tests,
but
the
version
that
is
that
has
been
uploaded
to
say
repository.
It
was
there
for
like
a
couple
of
months,
so
I
think
that's
enough
cadence
to
do
some
of
the
tests.
F
F
J
H
I
think
we
can
take
that
offline,
but
there
has
to
be
configuration
management.
We
we
need
to
release
a
strategy
so
that
people
can
say
they're
writing
tests
against
elite
block
right.
I
I
think
we
I
think
we
could
all
agree
on
that.
I
think
we
can
take
it
offline
and
figure
out
how
we're
going
to
do
that.
Okay,
I
have
a
question
for
you
marion
on.
I
H
H
That
should
solve
a
lot
of
problems
for
people,
because
most
people
who
are
writing
tests
don't
care
if
it's
running
real-time
or
not
they're,
just
writing
conformance
tests
and
that's
the
place
to
start,
and
then
it
will.
When
we
have
our
first
piece
of
hardware
that
actually
can
be
run
that's
great
too,
but
to
get
us
started.
It
would
be
awesome
if
you
could
do
that
for
next
week
and
I'll
give
a
little
people
more
confidence.
H
G
That's
great
yeah,
that's
great
yeah,
so
thanks
marian,
so
I,
if,
if
I
understanding
it
correct,
you
know,
the
goal
for
for
showing
next
week
is
what
we
just
discussed.
The
missing
piece,
which
is
the
lip
size.
So,
in
other
words,
what's
going
to
happen,
is
you
know
the
work
marian
that
you
are
describing
is
to
really
auto
generate
the
implementation
of
the
psi
apis,
which
eventually
is
going
to
be
making
those
p4
runtime
calls
to
to
to
to
match
the
the
p4
models
that
we
have
currently
okay,
good
yeah.
Thank
you.
E
That
was
a
wonderful
presentation,
reshma!
Thank
you!
So
much
and
ihorn
everybody.
We
have
six
minutes
left.
I
guess
I
will
let
you
know
that
we've
gone
ahead
and
created
a
high
availability
working
group
and
we've
met
one
time
to
define
you
know
the
agenda
and
the
requirements
for
aha
we're
changing
the
behavioral
model.
E
Working
group
meeting
to
a
weekly
call
cadence
just
to
have
a
touch
point
rather
than
over
email,
and
then
last
week
michael
miele
uploaded
the
presentation
from
michael
zigmuth,
the
the
json
file,
that's
in
a
draft
status,
that's
up
on
the
github
repos.
While
I
had
a
link
in
the
meeting
notes
from
last
time,
so
any
other
questions
or
we
can
release
five
minutes
early.
G
E
E
H
H
D
H
E
H
G
Anyone
for
10,
okay,
let's
take
it
offline,
christina,
but
because
we
moved
from
tuesday
was
11
and
when
it
moved
to
thursday,
we
assumed
it
will
be
at
the
same
time.
But
if
the
time
is
changing
along
with
the
date,
we
didn't
track
that
so
either.
If
we
could
write
an
am
and
see
if
somebody
comes
back,
then.