►
From YouTube: SONiC DASH Workgroup Community Meeting May 10 2023
Description
Continued ACL Tag Feature discussion as it relates to the P4 behavioral model, and whether P4 implements the match logic required of the feature.
A
And
thanks
for
coming
to
the
dash
Community
call,
this
is
for
the
10th
of
May
and
so
I'll
go
ahead
and
cover
what
we
talked
about
last
week
and
so
last
week
we
did
more
of
a
discussion
on
Apple
tags
and
we
also
it's
easier
for
me
to
go
off
of
these
notes.
We
talked
about
the
smart
Nook
Summit
again,
it
looks
like
ocp
is
coming
up.
A
We
talked
about
Apple
takes
again
here
and
we
talked
about
how
nice
it
would
be
to
have
an
example
of
maybe
how
the
matching
works
here
and
I
put
that
in
the
notes
here
about
I
sent
it
out.
Maybe
someone
would
volunteer
to
take
a
look
at
that
for
us,
we
also
talked
about
when
were
changes
going
to
be
in
the
Sonic
repo,
with
respect
to
sync
D
and
Sasha.
A
Alexander
gave
us
a
update
on
that,
and
then
we
talked
about
PR
346,
where
we
were
waiting
on
changes
here
at
a
site,
and
so
today
I
think
we
were
going
to
continue.
The
discussion
of
Faculty
I
had
a
request
on
that
and
then,
if
you
guys
have
anything
else,
you
would
like
to
talk
about
just
let
me
know,
but
anything
from
the
meeting
minutes
from
last
week.
A
B
Yeah
yeah
I'm
gonna
present
some
slides
I'll
put
my
camera
on
okay
and
I
I'll
apologize
in
advance
that
my
slides
are
not
that
good,
but
hopefully
we'll
get
the
point
across
okay.
Can
people
see
this
I?
Can
okay,
so
like
At?
First
I
just
want
to
talk
about
like
what
was
the
current
ACL
rule
API
before
we
added
tags,
so
the
rule
API
before
we
added
tags
had
sorry
this.
This
is
still
has
the
tags
in
there
see
I
told
you
my
slides
weren't
that
good.
B
Okay
so
before
we
had
the
tag,
basically,
the
matching
of
a
rule
is
based
on
a
list
of
protocols,
a
list
of
source
prefixes,
a
list
of
desk
prefixes
list
of
source,
Port
ranges
and
listed
desk.
Port
ranges
and
the
the
logic
for
matching
a
rule
was
a
rule
matches.
If
the
packet
has
a
protocol,
that's
part
of
the
list
of
protocols
and
the
source
address
is
matches.
A
B
An
and
kind
of
logic
where
each
field
of
the
five
Tuple
has
to
have
a
match
within
the
lists
of
acceptable
values
for
those
fields
or
prefixes
for
those
fields.
So
I
think
this
was
understandable,
I
think
everyone.
You
know
on
understands
this
match
Logic
for
the
ACL
rule
before
tags
were
introduced
and
it.
If
there's
any
question
on
this,
we
can
talk
about
that.
Otherwise,
I'll
go
to
the
next
slide.
B
This
ACL
tag
feature
was
added
as
a
requirement
to
dash,
so
it's
good
to
think
about
like
well.
What
was
the?
What
is
the
purpose
of
the
ACL
tag
feature,
and
these
are
the
purposes
I
came
up
with.
There
may
be
others,
but
one
is.
It
provides
an
abstraction
to
the
tenant
for
group
and
common
sets
of
prefixes
so
rather
than
you
know,
reusing
the
same
prefixes
over
and
over
again
or
lists
of
prefixes.
B
Over
and
over
again
in
your
rules,
you
can
just
refer
to
a
set
of
prefixes
with
a
tag,
it's
a
sort
of
an
indirection
that
adds
a
level
of
abstraction,
and
it
also
provides
the
potential
of
both
communication
and
memory
efficiency
for
the
control
plane.
The
control
plane
doesn't
necessarily
have
to
store
the
rules
in
a
form
where
all
of
the
prefixes
are
fully
elaborated.
The
control
plane
could
store
the
rules
in
a
form
where
the
rules
refer
to
tags
instead
of
prefixes
and
so
in
the
in
the
requirements.
B
For
this
feature,
this
prefix
tag
table
is
defined
and
the
object
is
a
tag
and
the
attributes
is
a
list
of
prefixes
and
it's
possible
that
several
tags
could
contain
the
same
prefixes
overlapping
prefixes
there's
no
requirement
that
these
tags
have
lists
of
prefixes
that
are
orthogonal
from
each
other.
It's
just
a
tag
is
refers
to
a
list
of
prefixes
in
the
way
I
think
about
this
is
that
tags
are
used
as
macros
in
ACL
rules.
B
D
B
Oh
you
mean
a
tag
for
like
a
list
of
Port
ranges:
yeah
I
I
mean
I.
Suppose
you
could
Gerald,
but
I
think
that
I
I
I
I
think
that
the
tag
on
the
prefixes
is
like,
maybe
more
logical
in
the
sense
that
you
know
as
a
tenant
in
the
cloud
I
may
have
you
know
hundreds
of
VMS
and
you
know
maybe
a
set
of
those
VMS
serve
some
function.
B
You
know
kind
of
feature
to
lists
of
ports,
but
I
think
that,
like
the
that
those
maybe
don't
tend
to
be
as
large
as
like
the
lists
of
prefixes,
but
but
I
mean
it,
it's
I
mean
it
would
be
reasonable
to
to
have
a
tag
feature
for
ports
and
protocols
and
everything
but
I
think
it's
the
prefixes.
That
are
the
ones
that
are
like,
where
there's
like
large
scale,
yeah
largest
number
of
prefixes,
and
it
provides
like
a
nice
shorthand
for
that.
B
Right
right,
accurate
right
so
so
this
is
the
feature
as
it's
been
defined
and
as
I
interpret,
you
know
the
the
the
the
the
the
feature.
I
didn't
Define
this
feature.
So
if
we
take
a
look
at
like
what's
the
rule
API
with
tags?
Well,
you
know
a
couple:
more
attributes
have
been
added
to
to
the
rule,
a
list
of
tags,
Source
tags
and
a
list
of
desk
tags.
B
Okay.
Well
now,
what's
the
match
logic?
Well,
the
match.
Logic
for
this
is
you
know
that
the
protocol
of
the
packet
must
match
one
or
more
of
the
protocols
in
the
list
of
protocols,
but
when
it
comes
to
the
source
address
it's
a
little
bit
more
complicated,
The
Source
addressed
must
match
one
or
more
of
the
prefixes
in
the
source
prefix
list,
or
it
must
be
associated
with
one
of
the
prefixes
for
one
of
the
tags
in
the
tag
list.
B
So
there's
an
or
kind
of
logic
there
and
again
it's
not
just
one
tag
that
prefix
could
be
associated
with
one
or
more
tags
in
the
tag
list
and
then
the
same
is
true
for
the
desk
address
and
the
you
know
matching
like
one
or
more
of
the
prefixes
in
the
desktops
prefix
list
or
one
or
more
of
the
tags
in
the
associated
with
one
or
more
of
the
tags
in
the
tag
list
and
then
and
the
port.
You
know
Source
Port
needs
to
match.
B
B
B
A
B
B
C
I
have
a
question:
yeah
I,
have
a
question
I
understand,
based
on
what
you
are
saying.
Why
is
this
not
a
function
of
the
user
interface
and
when
it's
passed
down
to
Hardware,
it's
not
already
expanded
and
provided
as
a
list
like
before.
Why
do
we
need
to
provide
these
tags
all
the
way
to
the
hardware
and
not
just
expand
it
unless
the
hardware
optimized,
based
on
the
implementation,
how
they
want
to
compact
them
and
do
other
things
yeah.
B
B
It's
a
great
question
and
it's
it's
a
question
that
I'll
bring
up
in
these
next
slides
and
I.
I
agree
like.
Is
this
really
meant
to
be
a
data
plane
feature?
Why
is
it
being
exposed
to
the
data
plane?
Why
wasn't
this?
Just
you
know
a
a
feature:
sort
of
a
user
feature
and
and
a
control
plane
feature
but
I
think
it
was
proposed
as
an
API
and
so
because
it
was
proposed
as
an
API.
B
This
is
what
is
being
attempted
to
be
implemented
in
the
data
plane,
but
I
think
like
I,
think
we,
if
you
just
defer
that
question
for
a
little
while
I
think
like
we
should
have
a
full
discussion
on
on
that
yeah.
Okay.
So
let's
talk
about
what's
implemented
in
the
P4
so
what's
implemented
in
the
P4,
is
a
prefix
search
that
Associates
a
prefix
with
a
bit
vector
where
each
bit
in
the
bit
Vector
represents
a
tag
and
it's
limited
to
32
tags.
B
Now
the
requirement
for
the
feature
was
that
that
it
that
the
feature
would
support
a
scale
up
to
4K
tags,
but
this
implementation
in
P4.
You
know
you,
basically,
you
can
do
a
lookup
on
a
prefix
and
it
gives
you
a
vector
to
tell
you
which
tags
the
prefix
is
associated
with
note
that
that's
actually
kind
of
backward
from
from
the
the
API
that
was
proposed
in
the
feature
where
a
tag
is
the
object
and
the
object
contains
a
list
of
prefixes.
B
This
kind
of
reverses
it
and
says:
hey,
given
a
prefix,
tell
me
which
tags
are
associated
with
it?
Okay,
now
you
know
they're,
just
you
know
the
the
they're
equivalent
to
each
other,
but
the
P4
kind
of
implements
it
sort
of
in
the
opposite
way
of
the
I
would
say
the
the
the
intent
of
of
the
API,
and
so
then
the
ACL
table
implementation
does
not
actually
perform
the
intended
rule
match
logic.
B
So
this
Vector
of
tag
bits,
does
a
ternary
compare
in
the
ternary.
Compare
has
this
property
that
that
it
doesn't
really
implement
the
or
like?
If,
if,
if,
if,
if
the
address
in
the
packet
matched
on
multiple
tags,
the
ternary
compare
won't
match
that,
basically,
this
bit
Vector
sort
of
is
constraining
in
that
it
can
only
really
match
on
one
tag
at
a
time
and
not
one
or
more
tags,
and
likewise,
if
there
was
a
match
on
a
on
a
tag
as
well
as
a
match
on
just
a
prefix.
B
That's
in
the
rule
itself.
That
also
can't
be
done
with
a
single
rule
in
the
way
that
this
is
implemented
in
P4.
So
the
solution
that's
been
talked
about
in
some
of
the
previous
meetings.
I
apologize,
I
wasn't
on
the
last
meeting.
Is
that
well
we'll
just
insert
multiple
rules,
so
you
know
if
you
can't
represent
the
logic
of
matching.
You
know
in
the
way
that
was
intended
by
the
API.
B
So
the
example
I
give
is
suppose
you
had
20
Source
tags
and
20
desk
tags
and
as
well
as
like
a
list
of
source
prefixes
and
a
list
of
desk
prefixes,
this
explodes
to
1600
rules,
and
so
what
the
tenant
considered
to
be
like
one
rule,
has
now
exploded
into
the
data
plane
to
be
1600
rules
and
there's
you
know.
The
the
current
requirement
of
the
data
plane
is
that
you
know
that
there's
a
thousand
ACL
rules,
and
so
you
know,
I,
don't
I.
E
B
B
B
So
you
know
you
know:
I
could
match
on
one
of
20
Source
tags.
I
can
match
on
one
of
20
test
tags.
I
would
need
400
rules
to
express,
like
all
the
different
combinations
of
which
source
tag
and
which
desk
tag
matches
and
then
combine
that
with
the
list
of
source,
prefixes
and
list
of
desk
prefixes
and
those
each
could
double
the
number
of
rules
and
you
get
to
this
combinatorial
explosion.
Okay
of
of
in
this
example,
1600
rules
and
I.
Don't
think
that
this
is
unreasonable.
I
mean
I.
B
Don't
think
that
this
is
unreasonable
rules,
and-
and
so
this
is
like
very
problematic
for
for
multiple
reasons-
one.
It
doesn't
address
this
artificial
constraint
of
32
tags
per
eni.
The
requirement
was
4K
and
then
the
explosion
of
rules
in
the
data
plane
could
have
significant
impact
on
the
performance
of
the
ACL
I
mean
it
really
depends
on
the
on
the
vendor's
implementation,
but
you
know
scaling.
B
The
number
of
rules
could
directly
impact
performance
and
the
only
reason
why
the
number
of
rules
here
are
being
scaled
is
because
the
P4
implementation
of
an
ACL
doesn't
really
implement
the
match.
Logic,
that's
required
of
the
feature,
and
so
I
I
it.
You
know
this
this
also,
you
know,
let's
just
say
in
the
future:
there
are
more
like
per
rule
kinds
of
features
added
like,
for
example,
debug
counters.
B
Well,
if
you
needed
a
debug
counter
per
Rule
now
you
need
1600
debug
counters
for
this
one
rule
that
was
exploded
into
1600
rules.
So
this
is
like
the
in
my
mind,
the
most
important
point
about
the
problem
with
the
P4
implementation
of
this
feature
is
that
it's
imposing
this
requirement
that
rules
be
expanded
into
multiple
rules
because
of
the
cross
product
of
tags,
and
you
know
the
source
and
s
prefix
lists.
B
F
B
And
that
that's
what
gets
that's?
What
gets
to
my
next
slide
Andy
is,
is
like
you
know,
can
we
sort
of
relax?
You
know,
hey
the
reference
model
can't
deal
with.
You
know
multiple
tags,
you
know
matching
on
multiple
tags
in
the
same
rule
or
it
can't
deal
with
a
list
of
prefixes
and
tags.
We
imagine
the
same
rule
the
implement
the
the
actual
Dash
implementation
must
deal
with
that,
but
the
but
the
reference
model
doesn't,
and
so
it's
like
you
know
it's
it's.
B
B
There
may
be
other
features
in
the
future
that
you
know
have
this
same
kind
of
issue
where
you
know
a
very
nice
abstract
feature
can
be
defined
with
a
nice,
API
and,
and
you
know
in
a
behavior
could
be
expressed
perhaps
in
English,
but
that
behavior
is
very
difficult
to
express,
let's
say
in
the
current
form
of
P4,
and
so
are
we
going
to
let
P4
then
ultimately
Define
what
our
apis
are
for
Dash
and
I?
Think
it's
a
mistake
to
do
that.
I
think
that
there
are
ways
that
we
can
deal
with
this.
B
You
know
again,
we
can.
We
can
eliminate
the
requirement
that
P4
Pass
the
full
full
set
of
tests.
This
particular
feature,
as
merch
I
think
pointed
out
like.
Why
is
this
feature?
Even
a
data
plane
feature
like
if
the
orc
agent
was
capable
of
expanding
a
rule
into
multiple
rules?
Why
didn't
work
agent
just
expand
the
tags
into
a
bigger
list
of
prefixes.
E
I
think
I
I
think
I'm,
not
sure
if
you
get
a
chance
to
look
at
the
requirements
PR
that
was
raised
recently
regarding
tax,
but
from
a
dash
perspective,
I've
listed
out.
What
is
the
requirement?
What
are
the
different
behaviors
if
based
on
the
bitmap
bit
Vector
size,
and
it's
also
possible
that
if
the
PSI
implementation
doesn't
need
to
deal
with
tax
or
cage
and
can
expand
based
on
what
is
the
capability
returned
right?
So
it's
kind
of
a
flexibility
that
we
want
to
add.
B
I
did
not
read
through
that,
but
I
mean
if
what
you're
saying
is
like.
If
a
data
plane
says
it
doesn't
support
the
tag
capability,
then
then
the
org
agent
would
just
you
know,
would
expand
the
tags
into
the
pre
into
like
a
larger
list
of
prefixes.
That's
right.
Yeah
I
mean
that
I
think
that
that
would
be
good.
G
The
other
thing-
maybe
our
position
agent
needs
to
consider-
is
that
the
tag,
the
way
it's
been
defined
from
user
point
of
view
can
be
any
tag
value
right.
It
doesn't
necessarily
have
to
be
within
a
bit
Vector
fashion.
All
right,
whereas
you
know
what's
highlighted
here,
is
that
the
data
plane
needs
to
work
on
beat
vector.
So
if
it's
a
free
phone
tag
from
user
point
of
view,
there
is
some
translation
that
needs
to
be
done
to
be
feeding
bit
vector
and
if
so,
orchestration
agent
can
help.
With
that.
B
What
is
really
like,
a
synthetic
thing,
that's
being
created
only
for
the
purpose
of
a
P4
behavioral
model
implementation
like
I,
think
that
that
it's
not
the
natural
way
to
represent
the
relationship
of
prefixes
and
tags.
The
the
natural
way
is
that
a
tag
is
the
object
and
is
associated
with
a
list
of
prefixes,
not
the
opposite.
Now
the
opposite,
I.
E
B
E
Because
the
P4
behavioral
model
defines
the
the
pipeline
model,
but
also
like
it's
it's
again
like
a
slightly,
if
you
think
in
a
different
way,
right,
though,
the
packet
is
coming
with
an
IP
address
right
now,
this
IP
address
is
the
one
that
has
to
match
different
tags
like
how
do
we
make
that
comparison?
If,
if,
if
there
is
no
prefix
to
tag
mapping
provided
like
it's
the
vendor
to
implement
look.
B
B
It
would
then
iterate
over
the
list
of
prefixes
for
each
tag
in
the
rule,
and
it
would
like
linearly
search
the
list
of
tags
and
then
the
list
of
prefixes
within
the
tag
until
it
determined
whether
there
was
a
match
for
that
address
on
that
rule.
So
so,
like
there's
a
you
know
like
again.
If
it
were
a
different
language,
it
would
be
like
a
very
simple
algorithm
that
could
express
the
desired
math.
E
B
No,
but
no,
but
but
this
is
a
behavioral
model.
This
isn't
Hardware,
okay,
okay,
this
this
is
a
behavioral
model
right,
it's
not
Hardware,
so
the
behavior
is
does,
if
you
iterate
it
over
all
of
the
tags
for
a
rule,
does
the
prefix
and
then
for
each
of
those
tags
you
iterated
over
each
of
the
prefixes.
B
You
could
determine
whether
the
address
in
the
packet
matched
a
tag
for
that
rule
right
and
that's
the
behavior
and
that's
the
correct
behavior
and
it's
a
very
simple
algorithm
now
how
how
a
vendor
implements
that
algorithm
in
their
data
plane
is
up
to
them
right.
But
but
what
we're
doing
here
is
we're
saying:
oh
somehow,
we're
thinking
of
the
P4
model
as
the
hardware
and
like
this
is
how
the
hardware
has
to
work,
and
it's
not.
B
The
P4
model
is
a
behavioral
model
and,
and
it's
I
don't
want
to
denigrate
P4,
but
it's
like
it's
it
it
it
doesn't
easily
match.
It
doesn't
easily.
Allow
you
to
implement
this
kind
of
logic
that,
in
some
other
language,
would
be
just
like
a
simple.
You
know
Loop,
so
like
I.
Don't
think
that
we
should
let
that
constraint
of
P4
like
like
Drive
our
apis
and
drive,
how
vendors
Implement
their
own
data
plane.
B
E
D
I
mean
I
just
suggest
that
I'm
not
hearing
anybody
who
writes
in
P4
respond
to
John's
concerns,
and
there
are
people
I
can
see
on
here
who
have
implementations
of
people
and
let
alone
know
people.
So
is
anybody
in
the
P4
Camp
here
have
an
opinion
on
this
or
knows
a
way
around
this
or
knows
how
to
change
this
I
mean
I
I'm,
not
really
hearing
anybody
in
the
P4
Arena
say
anything.
H
H
You
know
we
probably
shared
our
our
brains
a
little
bit,
so
this
may
look
familiar
but
I
think
the
two
non-negotiable
deliverables
of
this
working
group
are
a
data
playing
behavioral
spec
that
we
can
all
agree
with
and
it
can
be
an
English
in
diagrams
or
something
it
doesn't
have
to
be
executable
and
a
really
good,
PSI
interface,
so
that
this
can
be
integrated
to
me.
Those
are
table
Stakes
for
the
output
of
this
group
to
me,
and
everything
else
is
nice
to
have.
In
my
humble
opinion,
a.
D
I
D
B
D
H
H
H
Then
we
have
to
we
have
to
backtrack,
and
what
we
may
need
to
do
is
write
P4
code
that
produces
the
same
packet
in
pack
it
out,
behavior
that
we
want,
regardless
of
how
awkward
the
P4
ends
up
being
to
accommodate
today's
language.
We
may
need
six
tables
and
some
weird
actions
to
combine
and
or
different
outcomes.
H
P4
wasn't
designed
to
do
the
kind
of
things
we're
asking
it
to
do
in
this
particular
instance.
That
doesn't
mean
it
can't
evolve.
I
mean
we
also
didn't
have
two
years
ago,
add-on
Miss
and
it
was
a
response
to
Industrial
needs.
So
it's
possible
that
over
time,
some
of
these
features
will
make
their
way
into
the
language
and
the
back
ends,
but
we
shouldn't
let
that
you
know
stop
us
so
to
speak.
H
We
might
have
to
do
something
awkward
under
the
hood
and
the
automatic
code
generation
to
me
is
is
not
the
most
important
part
of
this
discussion.
We
can.
We
can
skip
this
Auto
generation
for
this
API
and
also
it
feel
I
feel
like
this
whole
tag
mechanism
is
kind
of
a
control
plane
convenience.
It's
not
really
describing
the
data
plane.
Behavior,
like
John,
said
it's
more
of
a
macro.
We're
really
matching
on
IP
addresses
we're
not
matching
on
tags.
H
I
H
So
so
yeah,
so
it
seems
like
it's
an
optimization
and
maybe
it's
a
optional
capability
or
if
it's
not
optional,
then
the
implementate,
the
vendor
implementation,
can
expand
into
individual
entries
in
the
cross
product.
But
we
need
some,
you
know,
checks
and
balances
on
on
the
combinatorial
explosion.
You
know
has
to
probably
reject
configurations
that
won't
fit.
That
I
would
recommend
we
back
up
and
come
up
with
the
best
PSI
interface
for.
E
This
I
think
I
think
we
have.
We
have
this
introduction
of
capability
right
where
the
vendor
can
say,
like
you
know,
bitmap
size
is
0
and
orchidn
will
expand,
but
the
the
whole
point
here
is
the
end
of
the
day.
Giving
given
a
tag
under
the
bit
director
can
drastically
reduce
the
the
repetition
of
the
prefixes
and
the
and
the
data
structure
usage,
at
least
according
to
our
understanding.
E
But
but
we
expand
and
give
that's
fine,
but
it
should
not
cost
like
you
know,
memory
a
high
memory,
utilizations
or
or
any
hit
on
on
performance
that
that's
the
that's
the
whole
idea
about.
Like
you
know,
using
this
tag
and
and
coming
up
with
this
model,
so
we
can
expand,
we
can,
you
know,
go
with
what
vendor
is
returning,
but
our
our
end
call
must
match
what
we
are
yeah.
J
Most
of
all
definitely
agree
that
we
need
the
behavioral
model
and
we
need
the
representation
of
the
data
plane
that
we
can
all
refer
to
and
we
can
generate.
Tests
from
this
test
stands
point
from
the
functional
standpoint
that
we
have
been
working
on
from
the
best
hunter
standpoint
we
it
will
be,
it
will
be
good
to
have
the
behavioral
model
for
sure.
The
other
part
here
is
like
you
know.
J
The
behavioral
model
is
implemented
in
V1
model
and
all
of
that-
and
it
takes
time
to
implement
that
and
I
have
brought
this
up
earlier
too.
I
feel
that
the
apis
dash
apis
need
to
be
accurately
defined
first
and
again
from
test
hardness
standpoint
and
the
functional
test
that
we
are
writing
without
the
PSI
apis,
we
are
not
able
to
implement
those
tests
at
all.
We
need
to
utilize
the
apis
for,
in
this
case,
in
icel
case
in
metering
case
in
HR
case.
We
don't
have
those
apis
at
this
moment.
J
E
I
think
this
we
have,
we
have
analyzed
in
the
past
also
like
sometimes
the
the
auto
generated
ones
and
the
manual
ones
were
not
same.
Then
we
have
to
you
know,
modify
the
the
manual
one
to
again
to
this
Auto
generated
one.
So
I
think
then.
At
that
time
we
kind
of
probably
agree
to
have
this
Auto
generated
method
to
generate
IAP,
so
that
it's
in
sync
between
the
sad.
J
E
One
thing
I'm
thinking
going
back
towards
right:
the
behavioral
model
is
the
the
must-have
so
and
that
can
change
the
size
generated
APS.
Based
on
how
we,
you
know,
model
the
behavioral
model
right.
But
if
we
come
up
with
a
manual
generation
of
PSI,
it's
highly
likely
that
it
will.
It
will
go
for
a
change
after
the
behavioral
model
is
defined,
and
then
it's
a
it's
an
extra
effort
for
the
vendor
to
again
now
go
and
change
according
to
the
new
auto
generate.
E
B
D
B
F
H
We
can
put
an
annotation
in
the
P4
code,
saying
don't
Auto
gen
and
hand,
write
that
just
like
we've
already
handwritten
some
other
apis
right
and
then
we'll
make
the
P4
code
Bend
to
our
will,
and
it
may
be
awkward.
But
there's
probably
way
to
do
this
by
having
multiple
lookup
tables.
Have
the
control
playing
code
distribute
the
tag,
expand
the
track
tags
under
the
hood
as
an
optimization
and
the
P4
code
will
produce
the
right
result.
H
F
K
B
I
B
H
L
The
CCL
tag,
actually
the
what
we're
talking
about
here
might
be
a
good
case
to
add
the
infrastructure
to
be
able
to
do
just
that
to
basically
Define
to
have
whatever
we
need
for
a
the
capability
of
a
ride,
so
that
the
oxygen
in
this
case
would
expand
before
pushing
to
psi
or
n
or
sorry.
Defining
a
PSI
API
that
it's
not
generated
by
the
P4
I.
Don't
think
we
have
all
those
pieces.
That
might
be
the
good
time
to
have
those
pieces.
I
So
one
example
that
I
could
think
of
where
we
have
seen
such
I
mean
I
think
we
have
had
prior
examples
of
this
where
P4
code
dictates
how
this
IAP
should
look.
One
example,
I
could
think
of.
Is
this
eni
attributes,
so
I
would
have
assumed
that
psiap
for
eni
should
have
all
the
attributes
with
the
create
call.
But
what
we
have
today
is
the
MAC
address
comes.
The
eni
MAC
address
is
one
of
the
key
attributes
of
the
enact,
but
it
comes
as
a
separate
API,
and
then
we
associate
that
to
the
eni.
J
I,
just
thinking
I'm
just
thinking
about
it
in
this
way,
we
if
we
implement
it
in
the
before
behavioral
model
and
derive
the
PSI
apis
and
then
hand
modify
it
on
top.
Whatever
is
missing
in
the
sign
right,
is
it
possible
to
do
the
reverse,
to
that
will
Define
the
dash
apis
and
and
then
once
we
implement
it
in
the
behavioral
model?
If
there
are
any
changes
needed,
we
can
always
update
those
Dash
apis.
E
H
That's
that's
irrespective
of
what's
under
this.
What's
under
the
side
layer,
P4
or
not,
you
know
if
you
change
the
side
layer
from
Auto
generating
code,
you
have
that
same
problem,
so
I
think
that's
a
wash
yes
implementing
the
translation
from
the
ideal
SCI
layer
into
our
behavioral
model,
maybe
a
lot
of
grunt
work,
but
we
have
the
right
interface
having
the
wrong
interface,
will
haunt
us
forever.
L
The
I
mean
the
the
side
API,
like
you
mentioned
the
architecture.
It's
got
a
ripple
effect.
All
the
way
to
the
north
right
I
mean
that's
a
fact.
You
already
have
that
right
now,
so
I
suppose
so
far,
I
guess
maybe
it's
been
easy
quote.
Unquote,
I'm
not
saying
it's
easy,
but
to
have
the
P4
generated
what
was
needed
and
made
sense,
but
you
still
have
the
work
of
okay.
L
L
K
If
we
want
to
exclude
that
particular
thing
from
behavioral
model,
probably
that's
the
discussion
that
we
can
have,
but
other
features
that
actually
do
packet,
Transformations
and
all
that
to
to
First
Define
apis,
then
try
to
fit
behavioral
model
to
it
and
and
see
that
we
missed
something
only
after
apis
are
accepted
inside,
but
we
didn't
have
behavioral
model
back
then
and
run
into
those
issues
later.
That's
a
bigger
problem
for.
L
E
Right,
I
think
even
for
the
actual,
when
we
introduced
tag,
there
was
always
this
confusion
if
it
is
an
ant
operation
or
an
over
operation
right.
So
so,
if
we,
if
we
write
a
way,
generate
handwrittens
I,
apis
and
the
vendor
implements
it,
it
may
be
different
Behavior
across
different
vendors
and
unless
it
is
all
clearly
called
out
so
I
think
that's
where
the
behavioral
model
can
potentially
help
right.
E
H
E
H
I
mean
like
if
we
agree,
this
is
the
interface
I.
Don't
think
anyone
is
having
trouble
understanding
this
this
slide
here.
It
doesn't
even
have
to
be
written
in
P4.
To
do
this
right,
P4
could
just
have
the
same.
You
know,
scalar
list
of
prefixes
the
cross
product
and
the
control
plane
in
our
behavior
model
can
just
expand
it
under
the
hood
it
doesn't.
We
don't
have
to
even
make
it
in
P4.
It's
not
a
data
plane.
It's
actually
not
even
data
plane
features
it's
more
of
a
control,
plane
convenience.
H
H
Yeah
and
the
tags
can
just
be
syntactic
sugar
at
the
side
to
data
plane,
translation
layer,
I
mean
we
don't
the
tags
aren't
really
looked
up
really
in
in
the
data
plane,
they're
just
a
way
of
describing
the
entries
now,
P4
language
had
semantics,
or
we
had
an
architecture
and
that's
something.
Andy
I
wanted
to
get
your
opinion
on.
Do
you
think
this
would
actually
require
different
P4
language
constructs
or
just
a
different
architecture
to
allow
different
match
type.
F
F
F
F
Sure
I
mean
it's
been
a
volunteer
opportunity
for
the
past
year.
I
mentioned
this
a
year
ago
and
and
I
said,
is
that
ever
going
to
be
done
and
it
sounded
like
nobody,
I
mean
it
can
still
be
taking
up
anybody.
I'm
not
saying
it's.
It's
it's
not
hard
to
do
it's
time
consuming
it'll,
probably
take
you
know,
it'd
probably
take
somebody
a
couple
months.
If
they
wanted
to
do
it,
but
no
Hardware
Target
would
ever
use
it.
It
would
only
be
probably
used
for
Dash
and
no
other
purpose.
B
D
D
It's
proprietary,
oh
no!
So
the
point
is
we
should
find
out
that
we
have
tags
going
into
vfp
today,
which
is
which
is
our
current
implementation
on
all
of
our
servers.
We
should
figure
out.
Why
do
they
have
tags
and
what
do
they
do
for
them?
I,
don't
think
it
was
arbitrary
I
mean
if
they're
using
them.
They
must
have
had
a
reason.
L
What
I
would
say
also
is
we
talk
about
the
API
generation
and
all
that,
but
the
point
is
also:
is
the
implementation
right
now
doesn't
match,
and
maybe
it
was
not
defined.
Property
I,
don't
know,
but
what
we
have
here,
the
logic
the
rule
match
logic.
Here,
it's
really
important,
that's
what
tags
are
about.
So
if
we
agree
on
that
one
here,
the
definition
that
we
have
currently
doesn't
match
that.
B
F
E
B
F
B
F
E
L
C
L
F
Northbound
API
we're
talking
about
is
to
the
control
plane.
Color
southbound
is
to
the
data
plane,
I'd
say:
Northbound
needs
tags,
keep
them
cell
phone
optionally
have
tags,
but
some
targets,
like
you
say
you
can
expand
up
tags
if
they
don't
support
them
and
the
reference
model
would
be
one
that
doesn't
support
tags.
L
B
Right
I,
I
agree
with
Vincent
I
mean
this
API
on
this
screen
is
fine,
like
we
don't
have
a
problem
with
this
AC
with
this
API.
It's
just
that
this
API
should
be
a
single
rule
in
the
data
plane
not
expanded
to
like
a
cross
product
of
of
rules.
I
mean
the
behavioral
model
can
do
that
if
it
needs
to
do
that,
but
this,
but
it
shouldn't
be
done
on
the
vendor
implementation.
B
E
I
B
Time,
you
add
a
a
prefix
to
the
data
plane
you're
going
to
provide
a
4K
map
of
bitmap
with
that,
it's
like
it
seems
like
a
very
inefficient
way
of
implementing
the
of
of
defining
the
API.
The
original
definition
of
the
API,
where
a
tag
is
a
list
of
prefixes,
seems
much
more
scalable
than
doing
it.
The
opposite
way
where
each
prefix
now
is
associated
with
a
4K
bitmap.
H
B
Right,
that's
right,
I
think
it
was
on
the
previous
slide.
I
mean
this
is
what
this
is.
What
was
proposed
for
the
feature-
and
this
is
again-
this
is
fine,
like
I-
have
no
problem
with
this
definition
or
this
definition.
What
I
have
a
problem
with
is
that
taking
a
behavioral
model
that
doesn't
Implement
these
and
now
pushing
constraints?