►
From YouTube: SONiC DASH Workgroup Community Meeting Apr 19 2023
Description
PR289 - Still needs volunteer - Dockerfile.saithrift-client has a static tag in the FROM instruction
PR350 - Add protobuf description for dash app_db (NorthBound)
@chris to check the Excel sheet - downloaded and looked good
PR336 - [ACL]: Optimize DASH ACL by introducing cluster tag
Continue “acl tag” convo
PR346 - Change SAI submodule URL to opencomputeproject/master
No update this week
A
B
A
Downloaded
and
looked
good,
okay,
great
and
then
for
PR
358.
We
did
have
this
update
here
to
update
I
guess
this
is
the
header
or
the
something
and
then
I
went
ahead
and
merged
this
one.
So
358
is
merged
and
then
we
have
this
very
large
conversation
we
talked
about
and
this
PR
is
going
this
336.
The
tags
is
going
to
be
polished
in
another
one.
A
C
What
the
hld
described
is
a
tag
is
a
set
of
prefix.
It's
a
prefix
list,
it's
a
set
of
prefix
and
it's
V4
or
V6
perfectly
fine
and
I
believe
also
that
the
ACL
could
include
a
tag
with
a
list
of
prefix
and
or
you
know,
just
one
at
least
its
own
set
of
prefixes
via
the
current.
The
current
information
that
we
have
now
when
I
pull
that
and
I
get
when
I
pull
this
commit
and
I
look
at
the
side,
Generation
Well,
it's
not
the
tag
is
not
defined.
C
Lucky
hdld
does
it's
basically
an
IP
prefix
and
be
added
could
be
assigned
a
tag
or
multiple
tags,
so
the
tag
is
an
attribute
of
the
prefix
not
the
way
around
and
then
suddenly
in
the
ACL
rule.
The
tag
now
is
certainly
so
all
this
implementation
there,
the
generation
from
the
the
P4
code,
is,
is
totally
different
from
what
was
you
know
from
the
requirement
description
in
the
hld
I
think
that's
a
problem.
A
D
B
D
Exactly
and
you
know-
and
some
might
some
might
not,
but
the
the
implementation
of
the
P4
code
like
separates
out
like
as
part
of
the
key
the
tag
and
the
IP
address
in
the
packet.
So
you
do
a
lookup
on
the
IP
address
of
the
packet.
You
might
get
a
tag
and
then
the
key
has
both
of
them
in
it,
and
so
that
creates
sort
of
like
like
it
for
the
ACL
lookup.
D
It's
like
an
and
you
know
like
if
this
field
matches
and
that
field
matches
and
the
next
field
matches,
then
the
rule
matches
but
like
it's
not
really
an
and
that
you
want
to
do
on
the
tag
and
then
the
other
prefixes
that
it
might
have
might
have
been
Pro
programmed
as
part
of
the
rule
it's
more
like
an
or,
and
so
like.
It's
just
the
way
this
is
implemented
just
really
doesn't
match.
D
F
A
C
C
Other
thing
I
wanted
to
add,
while
he
drives
to
there
is
our
coverage.
Is
that
the
the
granular
you
you
handle
a
tag
like
a
list
of
prefixes
and
when
you
remove
a
tag
you
remove
all
the
prefixes.
Now
the
API
that
got
defined
because
it
kind
of
turned
things
around.
You
can
add
multiple
tags
to
an
IP,
but
when
you
remove,
they
only
remove
API
that
gets
created
is
remove
that
prefix.
C
So
basically
remove
you
have
to
scan
all
the
tags
to,
and
you
cannot
when
you
remove
that
IP,
you
basically
remove
the
IDP
from
all
the
tag.
So
it's
more
work
and
B.
It's
not
the
granular
ID
that
I
think
the
CLI
was
intended
to
be
anyway.
I
mean
you
handle
tag
and
prefixes
like
you
handle
groups
and
rules
within
the
group.
C
E
C
Not
outside
Works,
anyway,
when
you
remove
you,
remove
an
object
right,
so
you
remove.
The
key
here
is
the
prefix
the
way
it's
defined
now
the
key
is
the
prefix
and
the
tag
is
just
an
attribute
of
it.
When
you
remove
that
object,
you
remove
the
prefix,
you
know.
Basically,
you
remove
its
Association
to
tags
to
whatever
list
of
tags.
C
E
G
Control
plane
does
Microsoft
association
between
an
IP
and
attack
is
expressed
in
a
different
way
and
from
what
I
from
when
I
checked
the
pull
request.
I
understand
the
reason,
the
main
reason
being
that
one
IP
can
be
used
in
multiple
tags.
So
if
you
have
another
way
of
expressing
this,
so
that
this
condition
will
be
satisfied,
same
IP
or
same
prefix
may
appear
in
multiple
tags.
C
C
D
Okay,
when
you
say
like
that
was
like
the
way
like
the
best
way
to
implement
it
in
P4
that
maybe
was
the
way
to
implement
it,
but
like
if
you're
thinking
about
it,
just
from
an
sdn
controller
point
of
view,
you'd
say:
I
have
a
tag.
This
is
the
list
of
IP
prefixes
that
are
members
of
that
tag.
Then
you
can
say:
I
have
a
different
tag.
Here's
the
list
of
IP
addresses
for
the
different
tag.
The
same
address
might
be
used
in
each
of
those
tags.
It
doesn't
prevent.
G
D
D
H
H
F
People
are
not
in
I
think
there
is
a
fundamental
problem
that
I
see.
Is
that
do
we
even
understand
you
know
what
had
you
know?
It
really
means
here
right,
I,
think
I
see
a
lot
of
different,
or
at
least
I'm
trying
to
see
that
you
know
or
I
I'm,
observing
that
there
are
conflicting
understandings
of
the
tag.
If
people
understand
what
the
ecmp
groups
are
right,
I
don't
know
whether
people
have
the
familiarity
with
that
in
certain
implementations
of
Asics,
where
ecmp
groups
generally
mean
you
know,
this
is
an
indirection.
F
This
is
something
shared
across
multiple
different.
You
know
destination
is
the
routing
table
right,
so
ecmp
group
is
used
as
a
set
of
Next
Tops.
Okay
and
it
is,
it
is
shared
across
multiple
destinations
if
they
happen
to
basically
have
the
same
ecmp
group
that
they
point
to
when
and
something
basically,
some
destination
is
wants
to
point
to
some
other
set
of
next
hops.
Then
they
end
up
actually
creating
a
new
ecmb
group
that
may
overlap
with
the
previous
one,
but
it
is
unique
in
the
sense
that
hey
you
know
it's
a
different
set.
F
So
in
this
case,
what
happens
is
that
if
people
are
talking
about
sharing,
should
we
even
call
it
attack
because
there's
some
confusion
should
we
call
it
a
prefix
groups
right
of
prefix
group
and
then
it
is
shared
across
all.
You
know
the
rules
where
they
happen
to
have
the
same
set
that
they
want
to
really
use,
and
if
somebody
wants
to
delete
or
add
anything,
it
means
that
they
may
end
up
actually
creating
a
new
group,
okay,
which
will
be
unique
in
its
members
that
it
can
basically
be
used.
F
Does
that
actually
drive
with
the
understanding
that
you
know
I
have
and
now,
when
you
have
indirection
I
agree
that
hey
you
know
if,
if
the
underlying
implementation
Hardware
implementation
does
not
support
it,
they
can
expand
it
and
use
it.
As
you
know,
full
set
of
prefixes
and
not
have
you
know
separate
indirection
or
table,
but
if
they
do,
they
can
use
it
as
an
interaction
to
save
the
you
know
the
space
within
their
implementation
as
a
space
saving
part,
because
this
is
where
we
all
you
know
going
towards
that.
D
Is
it
not
true,
I
I
think
what
you
described,
I
think
it
describes
sort
of
the
problem,
but
I
think
it
wasn't
really
to
optimize
any
kind
of
memory
space.
Necessarily
that's
each
vendor
can
decide
what
they
want
to
do.
I
think
it
was
it's
more
that
like
for,
for
example,
let's
say:
I
have
a
set
of
servers
set
of
VMS
that
are
email
servers.
Another
set
of
VMS
that
are
spam.
D
Servers
and
I
want
to
create
like
a
bunch
of
ACL
rules
where
I
want
to
be
able
to
say,
hey.
The
spam
servers
are
allowed
to
talk
to
the
email
servers
and
this
group
is
allowed
to
talk
to
that
group,
and
so
it's
just
a
way
of
like
reducing
from
a
control
plane
perspective
having
to
reference
like
the
the
full
set
of
IP
addresses
every
time
you
want
to
create
a
rule.
It's
like
a
it's
a
macro.
D
You
know
on
an
IP
address
to
to
get
what
tags
are
associated
with
it
or
you
could
just
expand
the
macro
in
every
single
rule
that
references
the
macro
and
that's
like
up
to
the
implementer
to
just
decide
right
but
like,
like
the
the
idea
of
the
tag.
I
think
is
just
that.
It's
a
macro
that
represents
a
set
of
prefixes
and
one
tag
does
not
have
to
be
orthogonal
from
another
tag
like
you
could
have
multiple
tags
that
have
overlapping
prefixes.
B
C
Unfortunately,
that's
all
generated
stuff,
although
you
know
you
could
obviously
get
it
from
the
LPM,
so
the
opmlookup
that
P4
decides
to
do
is
basically
this.
So
at
the
end
of
the
day,
the
tag
is
you
key.
Your
object
is
the
prefix
and
the
tag
is
an
attribute,
as
opposed
to
the
reverse,
which
is
similar
to
what
I
need
to
say.
The
anacr
group
is
compared
to
ACR.
G
G
H
C
H
C
Let's
try
to
understand,
we
don't
care,
it's
a
map
or
not.
This
is
32-bit,
and
actually
we
have
what
4K
tags
or
something
like
that
so
watching
Code.
If
you
encode
anything
in
there,
it's
not
even
the
point
right
now.
The
point
is
the
tag
is
the
attribute
of
the
prefix
now
the
way
around,
which
is
what
the
hld
is
described,
which
which
makes
sense
based
on
what
we
all
talked
about
so
far,
so
you
can,
you
should
have
the
object
should
be
the
tag,
but
it's
not.
C
H
C
G
C
H
C
C
C
H
Okay,
no,
no,
you
can
do
update
API,
where
you
just
update
the
the
attribute
of
this
tag,
the
the
tag
that
is
belonged
to
this
prefix
right.
So
you
you
say
the
tag
is
a
attribute
of
this
prefix.
So
in
that
tag
you
know,
there's
a
you
know:
it's
a
map
right,
so
it
just
to
remove
that
particular
tag
from
that
map.
What
does
that
mean?
It's
a
map.
C
C
F
You
know
that
thing,
because
you
know
eventually
I
think
the
idea
here
is
that
you
know
there
are
apis.
There
are
going
to
be
apis
which
will
allow
you
to
manipulate
the
cad
okay.
You
can
update
the
tag
as
Gohan
is
saying
by
saying:
okay
remove
this
prefix
from
this
tag.
That
is
going
to
be
the
API
right
and.
H
F
Can
use
it
to
attribute
it
now
by
removing
the
the
prefix
what
you
mentioned
that
remove
from
all
the
tags?
Well,
you
have
to
have
that
separate
API
to
remove
it
from
all
the
tags
to
say
any
and
all
the
tags
remove
this
prefix
right.
So
those
is
that
you
can.
Probably
you
know.
You
can't
say
that
okay
I
want
to
have
one
API
and
say:
oh
remove
this
prefix
and
remove
these
prefix
from
all
the
tags
right,
so
I
think
the
there
are.
You
can
have
two
apis.
Why
do
you
have?
C
F
C
H
H
H
A
D
D
He
said
he's
already
there.
Okay,
so
I'm
saying
there's
two
issues:
one
is:
does
that?
Does
the
the
PSI
API
satisfy
Express,
the
the
the
the
feature
of
ta
of
tags,
and
maybe
it
does
you
say
it
does
and
it
it
probably
does
okay.
The
second
issue
is
that
the
implementation
of
the
tag
feature
in
the
P4
like
creates
a
behavior.
That's
like
not
the
intended
Behavior.
H
I
C
D
Think
it's
ternary
because,
like
each
rule,
may
or
may
not
include
each
tag
right
so
like.
If
a
tag
is
not
included
in
the
rule,
then
that
tag
would
be
like
don't
cared
in
that
rule.
Okay,
that's
why
it's
turnery,
Vincent
I,
think
but
the.
But
the
problem
is
that
the
lookup,
the
ACL
lookup,
isn't
just
about
the
tag
the
ACL
it's
the
rule
itself
can
also
have
its
own
list
of
prefixes
and.
D
Right
and
if
you
look
at
the
way
the
P4
is
implemented.
Okay,
the
ACL
is
a
key
made
up
of
fields
right
and
logically,
in
order
to
match
a
rule,
each
field
has
to
match.
In
an
and
fashion
field,
one
has
to
match
the
rule
field
two
has
to
match
the
rule
field
three
has
to
match
a
rule.
If
all
the
fields
of
a
rule
match,
then
the
rule
matches
okay.
D
If
you
have
the
tag
as
one
field
of
the
rule
and
you
have
a
a
list
of
prefixes
as
a
second
field
of
the
rule,
you
could
match
on
the
tag
but
not
match
on
the
list
of
prefixes
or
you
could
match
on
the
list
of
prefixes
but
not
match
on
the
tag.
So
it's
created
like
an
and
of
the
tag
field
in
the
pre
in
the
prefix
list
that
the
rule
can
have
and
that's
a
behave
that
behavior
is
not
correct.
D
G
D
H
Mean
that's!
No,
that
that's
a
Northbound.
We
need
to
differentiate
the
Norse
band
and
southbound
right,
so
the
northbounder
I
don't
know
if
the
the
controller
will
send
us
a
rule
that
has
both
tag
and
prefix,
but
even
they
do
with
way.
You
know
the
old
kitchen
will
separate
them
and
put
them
into
a
two
different
rules
and
okay.
D
All
right
all
right,
if
we
everybody
agrees
on
that,
then
it's
fine,
but
it's
like
it's
like
nothing
describes
that
there's
just
some
there's
some
P4
Behavior
there
and
by
the
way,
like
some
data
plane,
implementations,
wouldn't
need
those
separated
into
two
rules.
So
it's
you
know
like
it's.
It's
like
you.
It's
creating
like
a
Saab
optim
like
the
the
P4
implementation
is
created.
A
behavioral
model
is
creating
like
a
sub-optimal
implementation.
If
you
did
it
differently,
I.
H
H
You
know
that
that
is
my
understanding
of
the
no
respondent
Behavior,
but
even
if
they
as
I
said
even
so.
Therefore
we
never
you
know,
thought
about
it
as
thanks
for
pointing
out,
but
even
if
they
do
I
think
you
know
Prince,
you
can
add
those
kind
of
you
know
notes
in
the
implementation
to
say.
Okay,
you
know
here's
the
requirement
if.
C
B
B
Go
on
but
like,
like
god
mentioned
like
even
if
the
Northbound
provides,
will
separate
it
to
two
different
rules,
because
we
don't
have
a
way
to
specify
both
tags
and
prefixes
in
one
attribute
list
that
that's
making
it
complicated.
So
that's
why
we
separated
the
tag
and
prefixes
to
two
different
attributes
and
and
you're
right
like
if
in
case
we
provide
it
like
that.
Then
it
is
an
ant
operation,
not
an
or
operation.
G
G
E
I
D
Can
we
eliminate
the
Andover
the
the
the
fact
that
there's
a
like,
like
I,
think
it's
a
problem
to
say
if
they're
both
provided
it
has
to
be
an
and
operation
I
think
I
think
that's
a
problem.
I
think
it
would
be
best
to
say
the
rule
will
either
consist
of
tags
or
the
rule
will
consist
of
a
list
of
prefixes.
If
and
if
it's
both
it'll
be
programmed
as
two
rules.
H
I
F
The
question
is
that
basically,
you
know,
can
we
also
modify-
or
at
least
you
know,
update
our
you
know,
Northbound
reference
example
that
we
have
in
which
we
are
saying.
These
are
the
the
kind
of
configuration
that
we
can
pass
through
northbound
and
in
that,
if
we
explain
how
the
rules
are
basically
going
to
be
communicated
from
the
Northbound
down
to
the
to
the
Appliance
or
any
device
that
would
also
clarify
it.
How
we,
you
know
how
it's
going
to
be
structured
right.
So
can
we
do
that?
Please.
H
B
H
B
E
E
B
E
H
B
E
I
And
those
are
may
or
may
not
be
fully
transformed
into
the
reference
model
P4,
but
then
we
are
deriving
the
PSI
wave
PSI
apis
from
the
P4.
So
unless
and
until
the
reference
model
is
exactly
like
the
hld
definition,
then
the
PSI
will
not
be
current
with
the
hld
definition.
This
is
just
a
generic
comment.
I
think
you
know
I
wanted
to
mention
this
for
some
time.
F
I
think
we
we
at
least
put
a
stick
in
the
ground
and
said:
okay,
you
are
going
to
have
always
you
know,
P4
as
a
as
a
single
source
of
Truth,
and
that
is
going
to
basically
create
an
API.
We
are
not
going
to
hand
modify
it
for
everything
we
are
going
to
create
it,
and
then
we
have
to
agree
upon
it
that
we
created
and
then
that's
way
that
way.
We
we
be,
you
know
completely
uniform
in
our.
You
know
our
implementation.
F
F
It
is
going
to
cover
all
the
cases
right,
even
in
this
case,
if
somebody
wants
to
just
expand
and
not
have
to
have
the
tag
carried
all
the
way
through
into
the
hardware,
and
let
that
be
right,
let
that
be
basically,
you
know
one
way
to
do
it,
but
then
another
way
is
to
have
some
indirection
right.
So
you
have
to
have
the
definition
of
saying.
Okay,
there
is
a
tag
we'll
we
will.
I
I
They
could
be
a
lag
in
the
reference
model
when
we
are
discussing
the
hld
and
the
features
in
the
hld
which
are
required,
and
that's
why
it
has
gone
into
the
hld.
But
then
the
API
then
will
have
lag
2
if
not
completely
miss.
You
know
in
some
certain
extreme
cases,
it
does
yeah
there's
something
to
consider.
H
A
C
So
I'm
going
to
reiterate
also
and
Marianne
thanks
for
the
email
I'm
on
PTO,
so
I
will
check
that
when
I
get
back
the
bmv2
model,
if
it's
the,
if
it's
the
model
for
the
side
duration,
then
again
we
still
have
the
ecl
rule
problem
where
it's
zeroids
and
IP
as
opposed
to
prefix.
It's
not
it's
orthogonal
to
the
tags
here.
So
I
know
there
is
a
hidden
flag,
I
think
it's
that
Dash
match
and
I
will
check
it
out,
but
shouldn't
we
shoot
on
the
Baseline
generation
of
bmv2.
C
A
C
A
G
C
C
G
C
C
C
E
E
E
This
is
the
question
for
who
wants
to
call
this
API
if
they
want
to
maintain
the
full
tagged,
IP,
prefix
mapping
and
look
and
every
time
they
want
to
remove
a
prefix
from
one
tag.
Look
up
all
the
other
tags,
that's
already
part
of
and
shoot
those
down
in.
The
API
called
they're
welcome
to
do
that,
but
they
have
to
do
that
in
this
API.