►
From YouTube: DASH Workgroup Community Meeting 20211215
Description
December 15, 2021 Community Call
B
So
so
what
we
did
up
to
now,
we
have
a
working
model
on
top
of
v1
model
like
vmv2,
v1
mode
and
the
reason
we
started
with
v1
but
they're,
not
because
it's
a
good
idea,
or
it
is
a
good
model
representing
anyone.
Hardwell
it's
more
like
this
is
what
exists,
and
this
is
what's
currently
working,
and
this
is
what
people
are
using
in
order
to
make
a
compilable
and
a
model
in
which
you
can
simul.
We
can.
D
B
B
Just
about
just
a
minute,
this
is
something
we
can
share
with
the
community.
It's
not
it's,
it's
not
a
problem.
We
have.
We
have
a
working
model
in
which
we
can
share
the
code
and
we
will
share
the
code.
It's
not
something
that
is
private
to
nvidia.
It
is
not
something
which
is
nvidia
target
architecture.
Is
the
v1
model,
modify
to
add
the
needed
capability
for
dash.
E
B
No,
it's
not
it's
not
about
the
psa.
It's
the
it's
around.
It's
not
around
the
psa
specification.
It's
not
about
the
pna
specification!
It's
around
that
specification.
This
is
what
we
would
like
to
do,
and
the
question
is
what
we
are
looking
for.
We
are
looking
for
a
dust
simulator
and
the
right
tool
to
simulate
dash
and
and,
on
the
other
end,
to
be
quite
expressive
like
to
describe
dash
pipeline.
B
This
is
what
we
are
looking
for,
so
as
a
community
right
and
and
and
so
so
currently,
the
best
available
model
that
we
we
find,
who
found
was
v1
model
as
a
target
architecture
in
pmv2
as
a
baseline,
and
we
modified
modified
vmv2
in
order
for
that
to
compile
and
run
our
pi4
dash
code,
and
we
are
going
to
extend
it.
Furthermore,
in
order
to
support
stateful
operation
like
our
connection
tracking
table
and
so
on,.
B
Not
what
yet
we
do
somalia.
Currently,
what
we
have
is
a
code
that
can
run
without
the
connection
tracking
tables
without
the
faithful
ones
we
are
going
to.
Actually
we
have
an
extension
that
already
works
with
the
stateful
operation
that
look
like
connection
so
so
that
can
implement
connecting
tracking
it
is
under
work.
It's
currently
not
working,
but
this
is
the
plan.
E
B
F
B
B
D
A
D
B
Again,
let
me
let
me
again:
we
we
have
the
same
time.
We
have
a
shared
target.
Our
target
is
to
have
a
simulator
for
the
dash,
so
if
there
is
an
available
one
just
a
minute,
let
me
finish
if
there
is
a
one
that
available
that
we
can
run
in
a
time
frame
of
a
month,
fully
functional
pna
model,
simulator
and
pna
assuming
pna
is
defined
in
a
way
that
actually
it
can
implement
dash,
which
is,
but
by
the
way,
not
not
the
current
situation,
then
fine,
but
I
don't
believe
this
is
the
case.
A
Because
guys
we
have
hardware
today
that
can
be
tested.
We
need
a
simulator
today
so
that
we
can
start
making
that
testing
easier.
We
can
move
over
time
to
maybe
even
a
more
standard
simulator,
but
right
now
we
already
have
hardware
that
we
can
be
simulating
again
so
to
help
that
we
want
to
have
software
simulators
so
that
we
can
build
those
test
cases
quickly.
We
don't
want
to
be
waiting
at
all
for
that.
A
A
C
B
C
B
Go
get
back
to
connecting
tracking
in
a
minute.
What
we
have
is
a
working
simulator
based
on
bmv2
and
the
current
before
code,
which
is
part
of
the
dash
and
currently
the
simulator
is
we
are
using
p4
runtime
in
order
to
configure
the
simulator
rules,
not
sign
in
addition
to
that
we
have
in
in
in
compiler
or
font
in
compiler
that
can
translate
the
p4
code
into
auto-generated
api.
B
Now
this
is
this
current
status.
Now
the
power
plan
is
first
to
do
the
first
like
to
do
the
following
things.
First
is
and
then
those
those
I'm
saying
them
in
the
in
the
priority
that
you
would
like
to
address
them,
and
actually
it's
more
called.
It's
called
for
action,
assuming
we
are
geary
on
the
on
on
on
the
plan
yeah,
so
the
first
is
to
create
a
side
to
peef
random
weapon.
G
H
H
So
they
are
auto
generated
from
the
p4.
You
know
p4
models
that
the
depth
are
written
right
now,
right,
right,
okay,
so
so
so,
and
then
you
also
mentioned
that
there
is
going
to
be
a
mapping
between
psi
to
p4
runtime
right
and
then
you
were
mentioning
that
you
for
both
underlay
and
overlay.
However,
currently
underlay
apis
are
not
auto
generated,
they
are
for
basically
you
know,
and
there
is
no
p4
model
for
those
underlay
api.
So
are
you?
What
are
you
saying
in
terms
of
from
the
p4
runtime,
for
both
underlay
and
overlay.
H
Yeah
yeah
yeah
sorry.
So
what
I
was
saying
is
that
you
know
you
said
that
there
will
be
a
p4
runtime
mapping
from
psi
for
both
overlay
and
underlay
apis.
However,
today
the
underlay
apis
there
is
no
p4
model
for
it
right.
They
are
defined,
you
know
outside
of
it.
So
how
do
you
plan
to
do
this
right.
B
I
H
B
Actually,
it
is
all
around
the
dash,
so
we
are
not
going
to
use
again
specifically
on
that,
so
it's
not
related
to
the
fact
that
we
cannot.
We
can
express
the
legacy
sonic
routing
tabling
before
and
use
that
as
well,
but
orthogonal
to
that.
The
current
overlay
api
in
dash
are
pure
dash
api.
We
are
not
using
a
legacy
psi
in
order
to
configure
the
overlay.
J
C
G
Just
a
quick
comment
thanks
chris
was
that
definitely
you
know,
as
I
mentioned
last
week
as
well,
that
currently
we
need
a
simulator
and
matty
and
marianne,
and
I
think
mario
will
be
adding
more
on
top
of
this.
That's
what
I
learned
last
week
is
really
important.
I
agree
with
that
with
pna.
P4,
you
know,
if
you
use
p4dpdk
dpdk
performance
is
definitely
better.
G
One
thing
I
want
to
mention
is
that
we
have
an
interface.
You
know
from
the
p4rt
which
can
consume
the
p4
information
today
in
sonic
and
a
quick
update
about
the
underlying
layer
in
the
psi
in
the
sonic
sync
d
right
for
the
psi
adapter
portion.
When
it
interfaces
with
the
programming
layer
for
the
p40
pdk,
there
will
be
no
additional
grpc.
There
will
be
no
additional
rpc
there.
It
will
be
a
direct
call
into
the
programming
library.
So
there
is
that
part
there
as
well
yeah.
C
So
I
know
we're
going
all
over
the
place,
but
this
is
sort
of
a
leveling
knowledge,
leveling
opportunity
right
and
it's
exciting
to
hear
what
maddie
had
to
say.
I
also
I
updated
this
diagram,
which
some
of
you
may
have
seen
in
previous
meetings.
It's
kind
of
a
lot
to
digest,
but
different
from
the
last
version.
You
saw
sorry
something
happened
with
my
screen.
C
C
C
It's
it's
really
kind
of
barefoot
runtime
put
out
into
the
public
community,
and
so
this
is
a
performant.
You
know
directly
compiled
back
end
on
top
of
that
they
have
a
p4
runtime
server,
which
theoretically
we
could
use,
but
in
the
concept
of
the
context
of
dash
testing,
it's
probably
not
particular.
C
Right
right,
but
it's
part
of
the
architecture-
and
I
want
people
to
understand
this-
what
we
would
do
for
dash
is
in
intel
would
have
a
libside
wrapper
of
some
sort
or
adapter
that
is
linked
to
this
table
driven
interface,
and
then
there
could
be
a
side.
Thrift
server
on
top
of
that
for
testing
just
like
there's
a
side,
thrift
server
on
top
of
whatever
vendor's
lip
side.
C
So
this
is
the
this
is
sort
of
the
architecture,
and
you
know
embedded
this
with
with
both
and
andy
fingerhunt
and
reshma
in
the
background
last
week,
just
to
make
sure
it
wasn't
off
base.
So
this
shows
that
this
be
pretty
performant,
there's
no
before
runtime
intermediate
server
from
the
standpoint
of
simulation,
but
if
there
were
test
cases
developed,
for
example,
nvidia
that
had
people
run
time,
it
could
be
applied
to
this
interface
too.
So
there's
some
commonality.
C
C
G
B
B
We
are
lucky
so
whether
it
is
critical
for
the
simulator,
I'm
not
sure,
but
if
there
is
a
better
back
end,
let's
use
it.
The
only
reason
we
use
bmv2
because
it
is
there
and
we
believe
that
in
a
matter
of
weeks
we
can
make
it
work
like
we
can
come
up
with
a
fully
functional
simulator
for
dash,
like
90,
is
already
functional,
so
we
can
add
10
and
it
will
be
fully
functional.
C
F
If
it's,
if
you're
90
of
the
way
there,
I
suspect
you're
going
to
win
that
race,
and
I
don't
have
any
problem
with
that.
Personally,
I
did
want
to
just
double
check
with
the
deciders
or
the
dash
group.
I
I
imagine
a
reference
model,
that's
like
the
code
is
available
to
all
of
us
to
run
and
download,
and
it's
you
know
either
all
open
source,
or
at
least
under
some
open
license
is.
F
B
H
Hey
chris,
I
have
a
quick
question
on
this
just
to
for
my
understanding,
yeah.
I
believe
this
this.
You
know
the
stack
that
you
have
shown:
p4,
dpdk
tdi
and
before
rds,
it's
like
reversed
right,
I
mean,
in
other
words,
you're
going
up,
as
in
terms
of
you
know,
from
the
from
the
from
the
flow
perspective.
G
H
G
H
C
H
G
Even
in
sonic,
I
think
you
know
there
is
no
need
for
additional
p4rt
between
sonic
and
the
programming
layers
like
tdi,
that
that's
there.
If
we
were
to
use
without
sonic,
you
know
pay
for
rt
with
other
means
of
testing,
then
p4rt
can
exist
there.
That
is
just
be
just
above
the
tdi
programming
layer,
yeah.
C
Based
on
this
discussion
and
and
maddie's,
you
know
description
of
progress
which
is
really
exciting.
I'm
going
to
redraw
this,
so
this
is
just
a
simpler
box
that
says:
p4,
p4
software
model
with
interface,
psi
interface
and
optional,
p4,
runtime
interface
and
then
I'll
have
another
page
that
expands
to
show
the
p4dpdk
stack
a
little
bit
better
and
the
bmv2
stack.
So
this
diagram
becomes
simpler.
C
K
F
So
if
I
could
just
I
mean
I
here's
my
understanding
and-
and
I
don't
know
who
the
decider
is-
that
can
say
this,
but
please
feel
the
jump
jump
in
an
answer.
My
understanding
is
dash
apis
psi.
Apis
are
the
top
level
that
all
conformance
tests
for
dash
will
be
written
to
use
and
what
the
what
the
final
products
are
expected
to
interact
with
the
controller
with
and
if
there's
any
other
apis
exposed
by
the
device,
whether
it's
p4runtime
or
tdi
or
whatever,
or
if
any
of
those
are
used.
F
A
C
A
It's
also
good
for
us
to
understand
that
p4
is
great.
I
think
it's
great,
it's
a
fine
model,
but
more
than
half
of
all
implementations
are
not
p4.
So,
let's
we
have
to
accept
that
and
that's
why
we
have
this
side
the
same
for
switching
all
the
switches
had
different
sdks.
In
the
end
it
didn't
matter.
We
raised
the
psi
up
a
level
so
that
that
wouldn't
matter
anymore,
so
the
same
principle
here
and
so
whether
you're
p4
or
whether
you're
running
c
code
underneath
or
whether
you're
running
dpdk
doesn't
really
actually
matter.
A
C
Yeah
the
good
thing
about
v4
is
that
we
can
actually
look
at
the
data
plane,
description
and
agree
on
or
disagree
on,
the
behavior
of
it.
That
way,
if
someone
could
just
write
it
in
ocam
or
python
and
still
function,
but
we
wouldn't
be
able
to
understand
it
right.
So
p4
makes
it
easy
to
understand
yeah
right.
L
J
J
J
C
Let's
say
we
don't
have
any
p4,
then
you
can
almost
take
this
diagram
and
draw
a
diagonal
line
through
it
and
ignore
the
lower
part
you
have.
We
have
some
test
cases
that
are,
you
know,
functional
unit
and
functional
tests,
and
hopefully
these
are
in
some
kind
of
an
abstract
format
that
don't
presume
what
the
northbound
or
southbound
interfaces
are
just
describes,
a
test
that
can
be
run
by
some
kind
of
a
test
script
engine
that
would
then,
for
example,
configure
hcl
tables.
C
C
This
is
just
trying
to
show
the
relationship
of
all
the
moving
parts
so
that
there's
a
lot
going
on,
and
in
order
for
this
to
work,
the
vendor
has
to
implement
libside
on
their
that's,
like
minimum,
be
compiled
into
for
testing
purposes.
It
would
be
compiled
and
linked
with
the
scithrift
server
skeleton.
C
C
H
H
Way
it
came
out
so
so
yeah
legend
in
the
sense
that
you
know
if
you
basically
have
some
documentation.
Oh
so
you
because
there
are
three
different-
I
see
there's
solid
line.
Then
there
is
a
dashed
line
and
then
there's
a
gray
color
line,
and
then
there
are
a
bunch
of
different.
You
know
colors
used
so
just
wanted
to
see.
If
there
is
no
relevance
there,
then
maybe
we
can
simplify
it.
Otherwise,
we
can
document
to
see
that
what
do
they
really
mean
right?
For
clarity's
sake,.
C
E
A
E
A
As
as
the
vendors
implement,
this
having
a
software
simulator
is
super
useful
for
them
to
know
when
they're
done,
because
actually
the
software
simulator,
I
hope,
will
be.
You
know
the
the
thing
that
is
the
golden
standard,
and
then
they
can.
They
can
use
that
in
their
testing.
They
start
off
with
something
they
have
something
in
their
hands.
A
You
know,
we
hope
that
we
will
actually
generate
tests
for
the
community,
which
will
all
be
open
source.
You
can
generate
your
own
tests,
but
we
want
to
generate
for
the
community
as
many
tests
as
we
can,
so
that
people
who
are
companies
that
do
develop
this
hardware
they're
starting
off
with
a
good
set
of
test
cases
and
a
good
set
of
simulators
that
they
can
start
with
and
know
that
if
they
go
down
this
journey
that
they're
not
starting
from
scratch,
they
can
actually
reuse
a
lot
of
the
work
that
the
communities.
J
Right
and
gerald,
if
I
could
add
to
that,
you
know
if
everyone's
agreeing
on
the
test
cases
and
they're
consistent
and
another
supplier
comes
in
and
generates
a
random
test
case.
That
means
nothing
to
us
because
they're
you
know
generating
their
own
and
delivering
results
that
really
aren't
apples
to
apples
comparison
with
what
we're
already
doing
so
they
have
to
you
know
they
would
have
to
conform
to
what
we're
asking.
So
we
can,
you
know
analyze.
A
D
F
D
D
E
B
B
J
B
Let
me
try
to
answer
first,
a
connection
tracking
within
the
pna
is
not
really
standard.
It's
not
in
the
proof
standard.
It
is
under
process
it's
under
discussion
and
we
are
in
video
having
a
different.
We
think.
Otherwise,
we
we
believe
that
the
connection
planning
should
be
more
generalized
and
not
be
like.
Instead
of
saying,
let's
say
the
connection
tracking
table,
we
would
like
to
add
a
stateful
table
that
can
implement
connection
taking.
B
We
would
like
to
add
the
infrastructure
for
that
the
language
to
create
that
not
the
implementation
of
a
specific
logic,
so
you
presented
as
if
there
is
a
kind
of
an
post
standard,
and
but
this
is
actually
not
the
case
so
and
and
and
and
to
say,
like
and
by
the
way
the
style
stateful
proposal
is
an
open
proposal
as
well.
So
I
can
ask
the
opposite
as
well
why
there
is
a
way
they
need
to
standardize
the
pna
when
there
is
a
standard
psi
api
that
can
solve
that.
E
Site,
but
also
you
know,
dash
as,
as
we
said
several
times,
is
standardizing
the
api
to
control
the
the
device,
not
the
language
with
which
we
express
the
the
the
behavior
so
that
behavior,
the
the
language
that
we
chose
to
express
the
behavior
is
before,
which
is
not
part
of
the
I
mean
my
understanding
is
that
dash.
The
dash
effort
is
not
going
to
define
a
dash
version
of
before
it's
going
to
define
a
dash
version
of
the
api
of
psi.
K
F
E
I'm
sorry
just
one
one
thing
I
think
what
shibano
was
suggesting
before
is
you
have
a
is
a
simulator
already,
which
is
not
supporting
the
stateful
graphs
as
well
as
it's
not
supporting
pna.
I
like
the
way
you
could
extend
it
to
support
pna.
This
way
your
simulator
would
be
pna
compliant
and
maybe
that
extension
is
even
simpler
than
adding
the
connection
graphs.
In
reality,
I
guess
they
are
quite
equivalent,
but
I
think
that's
what
silvano
was
was
saying
before
so.
B
B
On
top
of
that,
we
do
have
a
modification
modified
version
of
bmv2
that
can
simulate
a
stateful
stateful
operation,
as
proposed
into
the
sci
community,
a
generic
way
to
do
stateful
operation,
but
so-
and
we
have
it
working
already
now.
It
is
not
fully
fully
functional
in
terms
of
publishing
it,
and
it
is
not
fully
functional
in
terms
of
in
terms
of
it
will
take
a
few
times
a
few
weeks
to
make
it
fully
functional.
Now
to
your
question,
this
is
what
we
have
again.
B
E
You
know
advantages
and
disadvantages
of
going
one
way
or
the
other
one
I
mean
you
know
to
be
honest
on
from
from
one
point
of
view,
as
we
are
saying,
p4
is
just
a
way
of
describing
a
behavior,
that's
not
what
we,
what
we
care
and
what
we
are
interested
in,
but
but
if
on
the
way
we
invent
a
new
type
of
before
a
new
dialect
of
before
that,
the
before
community
is
not
really
using,
and
it's
not
dash's
goal
to
extend
before
then.
Why
do
we
do
it?
I
mean
you
know.
H
Yeah,
I
completely
agree.
You
know,
I
think
in
last
meeting
also.
We
said
that
we
try
to
remain
compliant
with
dna,
so
if
we
have
a
way
to
basically
do
this
thing
and
by
the
way
you
know
if,
if
we
take
a
different
path
right
now
remember
we
are
only
addressing
this
one
use
case.
As
we
discussed
right
like
we
need
to
v-net
communication.
H
H
And
then
you
know,
if
we
don't
want
to
deviate,
if
we
can,
basically,
you
know
remain
otherwise
we're
just
going
to
go
on
our
own
journey
and
then
we
will
not
have
a
real.
You
know
concrete
way
of
actually
saying
okay,
this
is
how
we
remain
compliant
with
whatever
the
the
p4
or
dna
is
doing,
and
that's
that's
just
you
know
my
my
view
on
that.
B
J
J
B
J
B
J
Term
is
to
have
something
get
it
working
now
today,
because
we
have
hardware
and
the
long
term
is
to
be
whatever
compliant
whatever
we
decide
on
in
the
long
term,
would
you
agree
gerald
yes
yeah,
so
because
there's
a
lot
of
engineers
and
architects
on
the
phone,
the
fun
thing
is
to
get
the
the
short
term
working
and
see
what
we
can
do.
But
we
do
you
know
we
do
need
to
align
to
the
future
too.
J
D
Can
I
suggest
one
thing
if
that
is
the
case,
why
don't
we
let
nvidia
and
intel
present
the
roadmap,
because
I
haven't
understood
in
reality
when
nvidia
is
going
to
have
a
full
solution,
I
understand
that
it
has
something
to
dive.
It
is
sort
of
working,
as
does
entire,
but
I
would
like
to
have
in
this
on
a
piece
of
paper
on
a
presentation,
black
and
white,
something
that
says
we
are
going
this
way
because
it
really
save
us
six
months
and
it
and
for
that
six
months
we
are
going
to
pay
with
proprietor.
C
B
C
C
If
sometime
down
the
road
that'll
become
move
because
nvidia
will
then
be
able
to
upgrade
and
align
with
pna
and
we'll
have
two
two
ways
of
simulating
the
same
thing:
just
different
implementations
with
the
same
p4
model
same
language,
the
same
code.
So
maybe
we
just
take
the
gift
that
they're
offering
us
in
the
near
term
as
a
way
of
doing
functional
simulation,
and
we
kind
of
suspend
the
pedantic
discussion
of
exactly
how
the
p4
is
rendered
because
eventually
it'll
resolve
itself,
and
we
can,
we
can
then
work
on
the
longer
term
pna
version.
C
E
E
The
comment
that
that
andy
was
writing
and
and
one
of
the
things
that
he
wrote
is
fine,
but
I'm
not
sure
that
this
does
exactly
what
the
other
code
is
doing,
and
I
said
the
same
I
mean
you
know
it's
not
easy
to
understand
this
code
and
to
and
to
maintain
it.
So
this
way
we
will
have
two
sets
of
codes,
or
or
at
least
for
certain
parts
of
code.
We
will
have
two
versions
that
we
will
have
to
maintain
coherence,
but.
F
C
A
C
B
It
will
eventually
line
again
so
so
somalia,
if,
if
I
get
correct
correctly,
what
really
disturb
you
is
the
around
it's
not
around
the
current.
Let's,
let's
like
there
is
the
stateful
part
like
the
connection
breaking
part
of
the
dash,
and
there
is
the
rest
like
what
you
are
more
concerned
about.
The
co
is
connection
tracking
of
the
dash.
Am
I
correct.
B
B
In
order
to
express
connection
tracking-
and
this
is
the
discussion-
I
would
love
to
do
with
you
offline
and
if
we
can
converge
to
a
single
model
together
with
the
intel
if
they
were
they're
willing
to
be
in
on
the
room.
It
is
amazing,
but
it's
not
related
to
this
project
and
the
simulator.
It's
my
it's
a
general
statement.
How
stateful
operation
should
be
expressing
before.
D
B
B
For
your
proprietary
model,
fine,
I
guess
it's
it
again.
We
are
looking
for
in
that.
In
that
discussion
we
are
looking
for
a
simulator.
This
is
really
what
we,
what
we
are
looking
for
and
preferable
simulator
will
be
in
a
language
that
we
all
familiar
with
like
if
we
can
really
look
at
on
the
pipeline
that
we
created
and
say,
okay,
I
can
easily
understand
it
so
currently,
90
of
it
is,
is
like
that,
and
that
is
10,
which
is
debatable.
Whether
stateful
operation
need
to
be
done
in
one
way
or
another.
E
You're
right
that
discussion
is
very
interesting
but,
and
it
would
be
great
at
some
point
to
do
it
in
some
other
countries
so
on,
but
but
I
think
here
the
point
is
different.
You
said
it,
as
you
were
saying
here.
We
want
to
have
a
tool
that
enables
us
to
simulate
and
to
express
in
a
way
that
everyone
understands
what
we
are
trying
to
do.
E
Our
point
was
simply
that
everyone
understands
what
is
standard,
something
that
is
not
standard.
It's
going
to
be
something
that
that
not
everyone
will
understand.
That
was
the
whole
point
right.
I
I
personally
like
very
much
your
your
your
graph.
It's
a
neat
idea,
but
but
it's
just
the
point
is
just
it's
not
what
everyone
understands.
B
Mario,
that's
fine
again
that
that's
a
that's
a
very
that's,
a
very
interesting
discussion
and
we
are
all
in
actually.
This
is
something
we
are
trying
to
standardize.
It's
not!
Actually
you
can
look
at
the
side.
There
is
a
push
pull
request
with
this
proposal
for
psy.
You
know
to
standardize
that
so
we
can
take
it
in
a
different
form,
trying
to
figure
out
what
is
better.
G
Maddie,
if
you
anyway,
I
think
you
are
going
to
publish
the
descriptions
of
the
new
extensions
that
you've
added
right.
It
would
be
really
good
to
use
them
and
you
know,
fill
any
gaps
if
there
are,
if
there
are
in
pna
as
well.
That
way,
everything
is
from
paper
wise.
What
is
needed
from
dash
is
all
standard,
and
it's
available
in
pna
as
well.
G
A
I
think,
as
long
as
it's
all
open,
everybody
learns
whether
it's
p
a
or
not
right,
it's
open,
and
so
everybody
will
learn
from
it
and
which
way
you
go
down
the
road.
You
still
started
from
something
that
was
open
and
somebody
did
some
work
and
we
all
benefit
from
that.
So
the
faster
we
make
it
open
the
better
and
then
we
can
have
some
really
good
conversations.
A
M
I
have
a
suggestion,
I
think
maybe
we
should
look
at
the
mario's,
pia
and
you
know
try
to
understand
whether
it's
equivalent
to
the
existing
model
so
because
I
think
what
we
care
is
mostly.
You
know
whether
the
api
generated
are
the
same
or
not.
I
briefly
look
at
my
api.
It
seems
like
it's
going
to
define
the
same
table
as
the
previous.
Just
you
know
how
to
implement
the
table
is
different
right.
So.
M
If
they
are
functional
equivalent
and
they're
generally
the
same
api,
I
I
suspect
that
we
we
do
not
really
care
about.
You
know
how
to
implement
that
connection
tracking
in
the
p4
right,
so
whether
it's
using
the
pm
model
that
provided
you
know
proposed
by
mario
is,
is
it
is
maddie's?
You
know
more
graph
model
right.
So
as
long
as
you
know,
they
are
generally
the
same
behavior.
A
Think
I
think
other
people
care,
I
think,
you're
right
gohan.
You
know
microsoft
doesn't
care,
I
don't
think
anybody
who's
using.
It
cares,
but
I
think
other
people
at
this
table
here
do
care
because
they
want
to
be
able
to
to
to
basically
understand
everything,
that's
going
on
using
standard
approaches
so
that
it's
easier
for
anybody
to
get
in
here
and
contribute.
I
think
that
was
the
discussions
and
there's
yeah,
so
I
think,
but
but
actually.
M
No
no,
but
I
you
know
we,
we
should
look
at
the
pr.
What
what
my
suggestion,
if
you
look
at
pr,
it's
defined
as
a
you
know,
option
right.
So
maybe
you
know
when
we
use
it.
When
we
later
move
to
the
pna,
you
know
we
can
use
that
model
right
so
and
you
know
those
two
models
can
coexist,
that
that
is
what
I'm
saying
right.
So.
B
J
B
Me
let
me
I
just
a
minute
guys
if
we
are
going
to
work
with
in
a
community
effort,
meaning
and
when
I'm
referring
to
community
effort,
I'm
referring
to
coding,
then
it's
totally
on
the
table.
So
if
there
are
engineers
that
are
willing
to
code
mario
proposal
into
the
current
bmv2
v1
model
and
extend
it
together
with
us,
amazing
really
amazing,
I'm
not
insisting
on
anything.
I
want
a
functional
model.
B
J
J
G
And
mario,
as
as
I
think
andy
mentioned
earlier,
that
p4dpdk
part
can
be
like
this
second
dash
reference
model.
You
know
based
on
standards
that
will
take
some
time
and
would
really
you
know,
request
help
from
the
community
to
enhance
it.
Once
we
have
some
basic
feature
site
implemented,
we
definitely
plan
to
open
source.
It.
E
J
J
A
A
H
Christina
one
quick
note
before
we
log
off
is
that
you
know
there
was
a
we
shouldn't
entertain,
like
you
know,
at
least
in
my
view,
two
data
model
or
do
two
to
behavior
model
to
coexist
right
because
we
generate
you,
know
scientists
with
them.
So
let's
community
should
basically
strive
to
converge
on
a
single
model,
and
then
you
know
that
should
be
our
goal
right.
Okay,.