►
From YouTube: DASH Behavioral Model WG July 28 2022
Description
PR163 add vnet table to the pipeline; bring into line w/gNMI wrt VNET_ID and VNET_Table
Other PR149 to be approved, published and merged
PR has SAI header changes, separate PR that has not been changed yet, and a VNET_Out test case PR (more objects)
PR 141 needs 1 more look before Marian approves and merges
PR 152 - Marian has a similar PR (stages w/ENI as a key in the ACL)
The problem is changes to the configuration. ACL is a security table needs to be bound and unbound atomically.
Can we split this into BM and SAI API then Test? - Marian will review both today and merge.
PR160 https://github.com/Azure/DASH/pull/160
- IPv4 option parsing
Current code does not take into account IPv4 optional headers
What is priority based routing? Priority based routing lookup - (Marian) can we delay this question until next week?
CA-PA validation has to happen against specific CA address, does it need to come from a specific PA? We need to check whether the PA exists in entire mapping table.
Prince to sync w/Michal what to program and add to HLD
We need to document DSCP bit - Michal
A
B
C
C
C
Lookup
also
drives
a
destination
v-net
id
for
the
v-net
table
lookup,
and
we
as
part
of
this,
we
can
also
remove
the
eni
to
vni
table
because
now
that
is
redundant
and
we
also
have
an
option
to
choose
which
v-net
id
drives
the
final
bean
vni
in
the
outbound
direction,
based
on
the
boolean
coming
from
the
mapping.
So
all
these
changes
are
bringing
the
peer
model
in
line
with
the
gnmi,
as
we
discussed
in
the
last
week's
call.
C
So
I
think
mario-
and
you
already
took
a
look
at
the
pr-
and
I
saw
your
comments
so
yeah.
I
had
a
few
follow-up
questions
on
that,
so
I
think
the
first
one
is
the
handle
ids.
You
mentioned
that
they
are
32-bit
but
yeah.
I
think
we
were
just
following
the
existing
eni
id
and
we
noticed
that
those
are
16
bits.
So
that's
why
I
just
stepped
the
v
net.
Id
also
has
16
bit.
B
That's
yeah,
that's
so
the
reason
specifically
why
I
noticed
this
one
is
that
because,
theoretically
we
may
have,
I
don't
believe
it
will
be
a
case.
We
may
have
more
units,
but
really
we
will
be
restricted
roughly
to
the
number
of
enis.
So
probably,
let's
just
leave
it
as
is
right
now,
api
generation
does
not
really
depend
on
that.
So
I
think
I
would
withdraw
this
comment.
It's
not
really
relevant.
We
can
stay
with
16
bits.
B
C
Sure,
okay,
so
just
moving
on,
I
think
this
part
is
just
removing
the
redundant
table
and
yeah
I've
just
retained
this
logic.
So
here
I
think
we
had
just
one
question.
We
noticed
that
you
were
doing
this
kind
of
this
big
logic
here,
instead
of
simply
fills,
if
condition
so
it's
just
wondering.
Why
is
that
isn't
the
if
condition
a
bit
simpler.
C
C
C
C
Okay,
great
yeah
yeah.
I
think
that
would
be
more
simpler
to
follow
yeah
moving
ahead
so
now
yeah.
So
there
is
a
dist
we
net
id,
which
becomes
the
key
to
the
ca
to
p80
mapping
table
and
in
there's
also
the
v-net
table
where
the
v-net
table
is
keyed
with
the
v-net
id,
and
the
main
thing
here
is
that
the
v-net
id
logic
to
choose
the
v-net
id
lies
within
the
action
routine
for
the
mapping
table.
So
that's
based
on
the
boolean
coming
in
the
mapping
table.
C
So
I
think
all
this
is
mapping
to
what
the
gnmi
is
asking
us
to
do
and
I
think
moving
forward.
I
think
you
had
a
comment
on
this.
This
particular
comment,
so
I
think
I
just
expanded
it
so
yeah.
I
think
I
got
the
fact
that
you
were
basically
saying.
Probably
it
was
too
brief.
The
comment,
so
I
just
added
more
details.
So
vmware
is
basically
the
only
the
end
cap
vna,
which
is
used
for
the
tunnel
between
the
inbound,
dpo
and
vm.
D
C
C
C
But
I
hit
one
issue
here
where
the
yeah,
I
think
right
now,
we
can't
have
any.
We
can't
create
entries
for
tables
using
object
ids,
because
the
p4
control
plane
is
not
yet
doing
the
object
id
allocation,
so
I
think
mukesh's
pr
is
addressing
that
change
in
the
autogen,
so
yeah.
When
I
made
this
change,
I
hit
a
yeah.
It
crashed
due
in
the
ci
run.
So
that's
why
I
left
it
commented
out
for
now,
which
pr
are
you
talking
about.
C
E
Yeah,
so
this
this
was
the
pr
which
we
had
split
into
two.
So
originally
the
pr
had
both
an
actual
group
and
an
actual
group
test,
also
right.
So
as
part
of
that
I
had
to
fix
the
actual
for
the
apple
group,
which
was
an
object-based
table,
object
id.
So
I
had
to
fix
that
part
because
it
was
not
filling
the
object
id
into
the
p4
table,
but
as
part
of
the
split
I
think
now
that
has
so
the
current
pr
only
has
the
psi
hundred
changes.
B
F
E
F
Okay,
great,
you
know
you
could
also,
if
you,
if
you
felt
it
so
inclined,
you
could
try
to
add
like
a
ptf
test
case
or
a
pi
test
case,
and
try
your
hand
with
that.
If
you
want,
because
the
translation
is
pretty
direct,
in
fact,
I
started
okay.
I
started
with
the
v-net
out
case
as
my
c-plus
plus
code
as
my
starting
point
and
then
it's
just
experimented
until
I
figured
out
how
to
do
a
cythrip
test
case.
E
F
The
loopback
tests
that
I
do
they're
they're
only
passing
because
the
data
plane's
not
quite
right,
yet
it's
echoing
packets
out
one
and
always-
and
it's
not
dropping
packets-
that
should
drop.
So
as
soon
as
we
fix
the
data
plane,
those
tests
will
break
will
fail.
We
need
to
talk
about
that
at
some
point.
It's
kind
of
some
technical
debt.
C
E
B
B
E
E
F
Sometimes
you
file
a
pr
and
it
fails
the
pipeline
not
only
in
your
local
branch,
but
then,
if
it's
a
pr
already,
it's
going
to
fail
in
the
main
repo
and
the
actions
in
the
main
route
will
show
everything
that
you
push
to
that
pull
request,
and
sometimes
you
get
in
this
mode.
Where
you're
experimenting
to
try
to
fix
things
and
you
push
it
and
it
fails
again
and
then
it
shows
up
in
your
actions
and
in
the
main,
repo
actions.
F
Let's
say
branch
b,
merge
it
back
into
the
pull
request,
branch
you're
doing
and
push
that
and
that
way
you've
got
kind
of
a
nice
clean,
build
in
the
main
pipeline
and
all
the
trial
and
error
in
your
own
pipeline
doesn't
really
have
to
show
up,
and
I
can
write
an
email
about
this.
You
know
laying
it
out
if
people
want
to
know
it
only
takes
a
minute,
but
it
saves
a
lot
of
let's
say
noise
in
the
pipeline.
F
F
F
C
F
Well,
if
it's,
if
you've
already
submitted
a
pull
request
of
your
brand,
then
it's
inextricably
linked
to
the
main
repo
and
it's
just
considered
a
delta
to
the
pull
request
and
it's
going
to
rerun.
Ci
you've
already
started
you've
already
tied
your
fates
together.
So
what
I'm
saying
is
the
way
to
uncouple
that
is
to
make
check
out
a
branch
write
in
a
new
working
space,
just
name
it
something
different.
You
know:
version
fix,
b
or
v
net
b
whatever,
and
then
you
can
push
those
changes.
F
They
won't
show
up
in
azure,
repo,
okay,
you're
no
longer
tied
to
that
pull
request.
Then
you
can
merge
it
right
back
to
your
other
branch
instantly
and
there
won't
be
any
problems
because
they're
so
close
to
each
other
and
then
push
that
again.
So
it's
kind
of
like
I'm
going
to
go
off
and
do
this
on
the
side
for
a
while,
while
no
one's
looking
fix
it
and
then
push
it
again,
does
that
make
sense?
F
D
F
F
A
F
Oh,
it's
easy
in
the
pr
you
just
say,
fixes
and
then
copy
the
url
to
the
pull
request
and
it
will
show
up
as
number
48
right
and
then
and
then
in
the
pr
it'll
say
this
pr
was
mentioned.
I
mean
this
in
the
issue.
It'll
mention
this
issue
this
this
issue
is
mentioned
in
pr
whatever,
so
they
get
linked
by
github
automatically.
Okay,
it's
smart
enough
to
find
the
urls
and
realize
there's
an
association.
F
D
G
A
G
G
G
F
F
We
probably
should
make
a
note
to
create
some
test
cases
for
this.
You
know
functional
test
cases.
This
would
be
a
great
example.
So
if
you
want
to
do
that,
that
would
be
welcome.
You
know
maybe
as
a
follow-on
and
then
we
need
to
figure
out
what
changes
in
the
model
are
required
to
actually
test
this
properly.
F
C
F
F
F
If
you
want
to
drive
it
that'd
be
that
would
be
nice
to
start
building
up
some
functional
tests
like
that,
just
a
little
exemplar
test.
Then
later
we
get
a
few
different
type
of
example
tests
here
and
there
people
will
be
able
to
look
at
them
and
just
cut
and
paste
kind
of
a
rinse
and
repeat
it'll
become
kind
of
mechanical
and
easy.
It
won't
be
a
burden
just
routine
stuff.
F
F
A
G
D
A
E
B
H
B
H
H
B
H
D
E
B
B
B
Like
if
you
do
from
v-net
to
vni
in
the
outbound,
you
know
for
sure
what
the
vienna
always
maps
to
one,
the
united,
we
need
maps
always
to
one
dna,
but
if,
if
you're
receiving
packet,
especially
like,
if
you
go
from
different
region
and
so
on,
there
are
so
many
clients,
and
so
many
cloud
customers
and
units
so
that
you
don't
have
enough
vni's
and
vni
may
overlap.
So
you
need
to
look
at
two
things:
to
identify
your
venus.
B
E
So
for
the
behavioral
model
itself,
I
had
one
or
this
high
api.
Actually,
so
the
pa
validation
table
is
a
separate
style,
but
from
what
I
understand
it's
just
a
reverse
of
the
or
just
whatever
information
is
already
provided.
The
mapping
table
is
all
you
need
to
implement
the
pa
validation
functionality
so
should
do
we
even
need
a
separate
iep
there.
E
E
E
E
E
B
Yeah
because
it's
simpler
that
way,
it's
not
like
you
have
the
exact
right,
your
action
parameters
become
key
and
your
key
becomes
kind
of
well
you
on
the
pa,
validation.
You
take
action,
param
one
of
the
action
parameters
and
you
put
it
in
the
key.
So
it's
not
really
one
to
one
and
it
will
be
really
hard
so
that
there
is
no
way
to
heuristically
kind
of
derive
that
table
implementation
from
a
single
api.
There
is
no
way
so
you
would
need
to
put
some
additional
annotation
stuff
like
that.
D
B
D
C
H
Sorry,
csma
cd
is
the
collision.
Backup
is
not
working
so
also,
I'm
also
worried
about
the
implementation
itself
right.
So
if
there
are
redundant
calls
which
is
updating
the
same
data
and
and
it
makes
sense
in
the
implementation
for
most
of
the
implementations,
to
put
it
in
one
table
to
save
resources,
if
you
have
two
different
psi
api
calls,
I
think,
trying
to
do
make
sure
it's
all
the
same.
H
H
B
B
There
also
may
be
the
case
where
we
either
well
again.
I'm
not
sure
I
don't
have
the
full
understanding
yet,
but
is
it
always
true
that
we
install
apa
validation
entry
or
maybe
will
there
be
a
need
to
install
pa
validation
entries
for
mappings
that
do
not
exist
in
some
cases,
not
in
this
v-net
use
case,
but
beyond
that,
because
pa
validation
is
not
really
that
related
to
only
two
cpa
mappings.
It's
a
security
feature
against
spooking
the
addresses.
E
B
D
B
H
E
E
B
B
E
E
H
B
H
B
E
E
Yeah
a
couple
of
questions
there
one
is
the
cap.
The
pa
validation
has
to
happen
against
a
specific
ca
address,
which
means
like
we
are
going
to
look
up
for
a
given
vnet
or
this.
If
the
packet
is
received
with
this
customer
address
c
address,
then
it
has
to
come
from
this
particular
provider.
Address.
E
D
A
E
E
E
B
Well,
you
remember
the
yeah
you
you
covered
that
in
the
hld,
but
I
don't
think
that
you
had
that's
what
I
wanted
to
ask
you.
I
don't
think
that
you
added
this
table
that
michael
was
talking
about
and
that
you
described
verbally
is
that
to
identify
the
unit
in
inbound
direction,
we
need
to
look
at
the
pa,
prefix
and
vni.
D
B
I
I
E
E
I
I
Yeah
yeah
prefix,
so
you
will
have
like
set
of
rules.
So
it's
not
like
you
match
the
best
role
out
of
it.
You
will.
It
will
be
based
on
priority,
like
you
will
look
into
the
first
rule
and
if
it
matches
then
take
that
action,
so,
okay,
yeah,
so
in
in
what
I'm
saying
is
in
the
like
in
the
outbound,
where
we
have
a
proper
lpm
lookup
in
the
inbound,
you
don't
have
an
lpm
table,
so
that's
why
I,
I
rephrased
it
from
routing
table
to
routing
rules,
so
so
it
is,
it
cannot
be.
A
A
I
D
D
I
D
D
D
E
D
A
E
Okay,
so
this
is
what
we
have
today.
We
have
the
p4
at
the
top,
and
so
I'm
just
showing
the
p4
look
up
at
the
top,
and
this
iap
is
at
the
bottom.
So
we
have
a
mac
look
up
into
the
ni
ether
table,
which
yields
an
eni
id,
and
then
that
is
used
to
as
look
up
into
the
eni
table,
which
has
the
uni
parameters,
the
qrs
parameters
and
the
vmpn
and
so
on.
E
So
one
question
is
so
this
iap
also
is
the
same
way
because
it's
derived
from
p4
one
question
is
ideally
the
psi.
Api
could
have
been.
Also
this
way
where
we
just
have
an
eni
object,
which
has
all
the
qs
params
and
the
mac
address,
and
it
returns
a
dni
object
id
and
the
p4
then
would
have
to
be
a
single
table
like
this,
with
the
mac
lookup.
B
B
E
One
thing
so
one
thing
I
was
thinking
was
like:
we
already
have
these
rules
where
we're
determining
that,
if
the
key
has
a
underscore
id
suffix
to
the
table
name,
then
it's
like
an
object
id
right.
That's
an
existing
assumption
that
we're
making.
So
just
extending
that
assumption.
Can
we
say
that
if
one
of
the
attributes
has
an
underscore
ide
suffix
to
the
table
name
then
instead
treat
that
as
the
key
and
make
the
actual
key
as
an
attribute.
E
E
E
B
E
The
so
wiener
table
lookup,
you
mean
that's
just
v-net
id
is
the
key,
and
then
you
get
the
bni
as
the.
So
that's
that's,
okay,
for
now,
only
the
dni
we
are
actually
having.
So
I
think
we
have
so
originally
eni
was
like
spread
all
over
the
place
and
we
had
multiple
small
tables
right.
So
I
think
most
of
that
you
have
already
cleaned
up.
E
B
E
Yeah,
so
this
this
again
goes
back
to
the
same
question
of
don't.
We
want
this
iapa
to
be
as
clean
as
possible,
because
this,
the
behavioral
model
is
just
for
reference
and
for
test
conformance
and
all
that
right.
So
now
we
are
saying
that,
because
the
behavioral
model
generation
or
converting
it
to
the
behavior
model
is
complicated,
we
want
to
keep
us
high
api
redundant
apis
in
this
eye
and
so
on.
So
it
just
goes
back
to
what
is
the
correct
way
of
doing
this.
B
If
the
rules
are
as
simple
as
possible,
it's
easy
to
understand
apis
and
look
at
the
behavioral
model
as
the
expectation
of
how
api
implementation
is
supposed
to
behave
now,
if
we
will
have
more
and
more
things
like
that
right
now,
what
we
have
is
distinction
between
eni
ids,
meaning
like
object,
ids
and
entries,
which
was
native
to
psy,
so
no
big
deal
about
that
and
second,
we
had
to
consolidate
acls,
which
is
already
a
little
bit
counter-intuitive.
Now
there
will
be
another
thing.
B
B
However,
inside
we
have
multiple
stages,
because
it's
easy
to
understand,
we
have
from
route
to
next
hope
from
next
stop
to
neighbor
from
neighbor
to
fdb,
from
fdb
to
port,
but
at
the
end
of
the
day,
there
is
like
one
lookup
in
the
switch
for
the
performance
reasons
where
you
go
from
route
to
to
the
egress
board.
So
but
it's
much
easier
to
understand.
If
it's,
if
it's
digested
digested,
is
it
the
right
word
but
split
into
smaller.
D
B
B
C
H
B
If
it
was
a
physical
interface
like,
for
example,
standard
site
api
has
that
if
it's
a
router
interface
and
standard
site
api,
then
I
agree
you
derive
mac
from
the
interface
in
this
case.
What
we
really
do.
We
derive
interface
for
mac
because
we
are
virtualizing
the
interface,
so
I
I
would
rather
keep
it
this
way.
E
E
B
I
B
An
object
as
a
nice
abstraction
to
use
it
in
multiple
places
where
you
have
to
match
on
vlan,
because
later
on,
let's
go
to
a
route.
Look
up
where
eni
is
part
of
the
key,
then
you
really
need
an
eni
id
as
an
abstraction
to
provide
it
as
a
key
there
and
or
agent
won't
supply
you
with
such
an
id.
That's
why
the
site
api
is
done
in
a
way
that
psi
implementation
provides
you
with
a
key
sorry
with
an
object
and
not
vice
versa.
You
do
not
define
a
handle.