►
From YouTube: DASH Behavioral Model WG Sep 22 2022
Description
Reshma hosting :)
A
Thank
you,
hi
everyone.
This
is
the
behavioral
model,
sync
up
from
Dash
Thursday
morning,
September
22nd,
sorry,
I,
think
it's
20
seconds
2022
and
the
behavioral
model
sync
up
agenda.
We
don't
have
a
predefined
agenda
at
this
moment,
so
we
will
keep
it
open
and
anybody
has
anything
to
bring
up
and
we
can
go
from
there
and
also
share
my
screen
that
the
task
items
that
we
are
tracking
for
Dash
behavioral
model
anybody
have
anything
to
present
today.
B
C
A
A
B
B
A
A
E
So
one
I
saw
that
about
a
month
ago
there
was
a
change
to
the
inbound
routing
table
keys
and
the
eni
was
added
as
one
of
the
keys
and
I'm
sure
I
think
Marion
might
have
done
this
and
I'm
sure
that
I
I
saw
in
the
change.
It
was
moved
from
the
PA
validation
table
to
the
inbound
routing
table
and
I'm
fairly
confident
that
it
was
the
right
change
to
make.
But
I
just
wanted
to
ask
the
question
again.
B
E
B
E
Yeah
I
remember:
there
was
a
a
comment
there.
There
was
there
were
two
pieces
of
documentation
and
they
were
not
in
agreement
on
one
of
the
points,
but
I
didn't
think
it
was
on
the
the
disagreement
was
over.
The
E
and
I
feel
I
thought
it
was
over
something
else.
Let
me
let
me
try
to
find
that
quickly.
E
Yeah
so
I
mean
if
the
eni
idea
is
supposed
to
be
part
of
the
table,
and-
and
we
know
that
for
sure
I
mean
it's-
that's
fine,
I
just
didn't
see
it
in
the
documentation
and
as
I
went
to
sort
of
implement
this
table
I
mean
it's
kind
of
a
a
slightly
different
tables,
a
little
bit
challenging
to
implement
because
it's
partially
exact
match
and
partially
tcam
and
and
so
anything
that
could
simplify.
It
might
be
worthwhile
to
to
understand.
D
F
E
E
G
G
Yeah
so
so,
if
you
look
at
this
right,
the
based
on
incoming
packets,
V
and
I
right,
the
direction
is
set
up
and
maps
to
the
corresponding
eni
based
on
the
inner
destination
map
right
yeah.
So
once
based
on
the
inner
destination
map
it
identifies
the
eni,
then
it
looks
up
into
the
routing
Rule
table
that
is
associated
to
the
eni.
G
So
this
is
a
priority
based
Rule
and
it's
not
a
scaled
rule
like
what
we
have
for
outbound
so
maybe
like,
let's
say,
100
rules
or
or
200
rules
like
that
I
I,
don't
know
exactly
the
scale,
but
it's
not
a
very
high
scale.
Priority
rule
here
so
to
match
this
flow.
You
find
the
eni
and
then
you
look
at
the
priority
as
like
rules
based
on
priority
Associated
to
the
cni.
So
eni
must
be
a
key
here.
D
Prince
one
question
we
have
there
is,
let's
say
I
think
that
there
is
a
similar
questions.
Well,
but
if
two
Enis
belong
to
the
same
v-net
yeah,
would
they
have
something
like
the
same
vni
pointing
to
two
different
units?
So
this
inbound
routing
table
is
also
used
to
kind
of
further
receive
vni
to
identify
a
v-net
twin.
D
E
D
In
with
a
vni
right
yeah
from
the
remote,
so
we
are
using
this
inbound
routing
table
to
identify
the
v-net
from
that
incoming
vni
right,
so
the
prefix
The
Source
IP,
the
The
Source
PA
and
the
vni
put
together.
We
are
using
that
to
identify
your
v-net,
so
would
this
change
for
each
eni,
I'm,
assuming
the
source,
PA
and
Vienna
incoming
vni
is
going
to
be
kind
of
unique
right.
It's
it's
not
going
to
be
different
for
each
year
line,
so
why
should
we
have
a
per
eni
entry
for
this?
It's
a
replicated
entry.
G
D
Yeah,
so
that
was
the
question.
So,
since
the
we
are
identifying
the
v-net
here,
that
would
be
a
that
that
phone
wouldn't
be
different
for
each
for
each
eni
right.
It's
going
to
be
the
same,
because
it's
based
on
the
incoming
Vienna,
why
you
would
would
it
be
different
for
each
ni
is
the
question:
why
would
we
need.
G
I
can
I
can
I
can
double
check
that,
but
I
I
see
the
question
here,
but
I
see
that
the
current
configurations
are
associated
to
eni
or
based
on
the
rules
and
the
and
the
number
of
rules
are
not
that
high
so,
but
from
a
lookup
standpoint,
even
if
eni
is
not
there,
what
are
the
action
types
take
care
for
drop?
Okay,
so
that's
another
thing
right
if
the
routing
rule
okay,
that
okay
here
is
another
problem.
G
G
So
that's
one
concern.
Let's
see
what
other
thing
is
there.
Protocol
may
not
be
an
issue.
Pa
validation
can
also
be
generic
and
the
other
thing
is
yeah.
So
the
other
thing
is
this
metering
bucket.
This
also
is
perennial
So
based
on
the
action
type
and
metering
bucket
I
mean
like
what
I'm
saying
is.
This
is
my
thought,
but
I
can
come
come
back
after
discussing
with
the
internal
team,
but
to
me
it
looks
like
if
we
have
to
have
a
unique
action,
type
and
metering
bucket.
F
F
G
Yeah
but
yeah
can
you
scroll
scroll
to
the
right?
Maybe
I
I
think
we
have
returned
something
about
so
eni:
vni
prefix
eni
inbound
route
table
with
the
vni
and
optional
Source
PA
prefix
yeah.
So
that
means
the
prefix
is
optional,
so
the
parsing
logic
will
first
take
the
value
after
the
first
colon
as
eni
for
sure.
So
it
cannot
be.
F
G
That's
what
I
so
I
yeah
like
I
said
right.
The
exact
scale
number
I
can
get
back,
but
when
I
came
up
with
this
table,
I
I
I,
remember
the
the
expectation
was
like
limited
number
of
inbound
routing
rule
so
when
I
say
limited,
I
I'm,
just
comparing
it
to
the
outbound
route
rule
which
is
at
the
100K
or
that
scale.
But
inbound
control
is
not
that.
D
G
E
So
I
I
actually
don't
have
a
a
good
feel
for
on
the
outbound
side.
What's
the
number
of
different
dnis
that
could
be
in
play
in
in
all
these
different
outbound
tables
and
and
I
guess,
maybe
that's
the
same
way
as
asking
like
how
many
different
vnis
do.
We
need
to
recognize
on
the
inbound
side,
I
think
you're
saying
it's
only
a
couple
hundred.
G
F
E
Well,
I
was
just
going
to
follow
up
on
the
on
the
scale.
If
you
look
at
the
the
issue
that
I
raised
in
in
GitHub
I
asked
about
the
scale
in
a
couple.
Different
ways
like
like
total
number
of
entries,
like
the
sip
prefix
is
optional,
but
I
mean
in
theory,
could
be
specified
for
every
entry.
There's
nothing
stating
that
it
would
not
be
like
how
many
entries
do
you
expect
would
actually
have
prefixes
and
and
things
along
those
lines.
E
G
G
G
So
how
many
Regional
pairings
are
happening
with
this
eni
is
what
determines
the
the
prefix,
because
that's
when
that's
when
we
want
to
distinguish
between
within
the
region
versus
outside
region,
so
based
on
the
number
of
regions
like
it
will
be
like
10
or
15
or
in
so
so
that
that
much
is
what
we
can
like
if
there
are
a
lot
of
pairings
with
the
different
regions
yeah.
But
if
you
want
I
can
check
what
is
the
max?
That
can
happen
with
the
prefix
process.
G
G
F
G
G
F
D
G
D
G
D
G
D
A
G
G
D
D
D
G
F
F
G
No
actually
I
I,
wouldn't
I
didn't
fully
agree
to
that
because
in
most
cases
yes,
the
idea
is
here
is
a
prefix
and
VNA
can
be
at
a
higher
priority
than
the
one,
with
vni
or
V
and
I
alone.
But
if
there
is
some
special
treatment
required
for
a
special
vni,
then
it
is
possible
that,
with
this
schema
that
can
take
a
higher
priority.
G
D
G
G
H
I
I
Mean
one
case
would
be,
for
instance,
the
temporary,
so
you
have
a
bunch
of
prefixes
rules
and
then
one
catch,
all
I
guess
on
the
vni
and
then
maybe
sdn
wants
to
change
the
configuration
and
suddenly
just
allow
for
temporary
just
to
to
have
just
V
and
I
at
a
higher
priority
and
then
remove
it.
You
still
leave
the
other
ones.
Behind
too
I
mean
it
gives
yeah
yeah
control,
plane
flexibility
about
all
how
to
do
things
from
a
data
plane
standpoint,
it's
just
a
bunch
of
rules
with
their
priority
like
a
tcam
right.
I
F
D
G
J
J
Okay,
what
I
meant
was
I,
don't
know
if
we'll
have
time
in
today's
meeting
to
go
over
the
confusing
detail.
One
minute
just
get
a
consensus
on
the
approach
we
ought
to
take.
You
know,
for
example,
I
know
that
I
don't
know
if
Vladimir
had
a
list
of
a
whole
bunch
of
test
cases
he
wanted
to
develop,
but
it
seemed
like
he
was
stymied
for
most
of
them
and
I
know.
Anton
has
a
also
has
a
test
case.
J
J
So
what
I'm
suggesting
is,
is
the
test
case
developers
articulate
each
one
of
these
as
as
one
issue,
and
then
we
can
triage
those?
Maybe
you
know
some
of
the
experts
can
weigh
in
on
the
issues
list
even
offline,
because
they'll
be
able
to
just
quickly
either
answer
it
or
say
yes,
this
needs,
you
know
attention
or
it's
going
to
be
handled.
J
I'm
thinking
that's
one
thing
we
lack
is
maybe
a
good
idea
of
a
road
map
that
we
all
agree
to,
like
you
know,
here's
a
sequence
of
of
releases
with
certain
features
or
enhancements,
or
capabilities
that
we're
going
to
add
progressively,
maybe
I'm
simply
unaware
of
that
road
map
and
other
people
know
it
I
think
we're
lacking
kind
of
like
a
release
roadmap
in
a
way
that
seemed
like
a.
We
could
almost
treat
this
like
a
set
of
software
releases
that
we
can
then
say
by
such
and
such
a
release.
K
Anyone
have
anything.
No.
This
sounds
like
a
good
idea.
Chris
I
think
we.
We
do
need
to
start
with
filing
issues
as
you
mentioned,
and
then
we
need
to
triage
them.
We
need
to
discuss
them
and
then
you
know
I
think
you
know
we.
We
were,
in
my
view,
I,
guess
somewhat
premature
in
declaring
that
okay,
we
we
are
complete
or
we
have
either
completed
or
we
have.
K
Basically,
you
know
by
by
just
writing
the
the
you
know,
P4
code
and
saying:
okay,
we
we
have
the
behavior
model
for
at
least
one
use
case
completed,
as
we
all
know.
Unless
it's
tested,
it's
broken
in
my
view,
right
since
we
did
not
have
was
not
tested,
I
think
you
know
we
cannot
declare
this
is
done
and
then
now
it's
it's
high
time
that
you
know.
If
you
have
test
cases
for
the
same
use
case,
we
have
to
really
ensure
that
okay,
those
test
case
pass
then
can
only.
K
We
can
say
that
okay
yeah
now
we
can
say
it
is
it
is
you
know,
either
we
have
completed
one
use
case
like
v-net
and
I.
I
completely
agree
whether
we
call
it
a
release
or
whatever
the
Milestone
that
may
be,
but
I
think
you
know
there
has
to
be
some
gates
to
say
that,
okay,
if,
unless
we
pass
all
these
test
cases
or
or
some
some
sort
of
other
gate,
then
can
we
only
say
that
we
are
done.
J
Yeah
I
think
we've
been
doing
a
lot
of
improvising.
You
know
what
this
thing
takes
shape,
but
I
think
it's
I
think
we
need
to
kind
of,
let's
say
get
to
the
next
level
of
of
call.
You
know
managing
this
and
and
again
I
think
maybe
coming
up
with
some
dot
releases,
and
then
we
once
those
are
working
and
the
test
case
passes.
J
You
know
we
can
look
at
that
and
say
well,
let's
address
those
in
a
certain
order
and
let's
assign
those
Milestones
to
dot
releases
for
something
so
I
just
wanted
to
get
that
conversation
going
and
then,
besides
the
pipeline,
you
know
yesterday's
meeting
brought
up
issues
about
the
completeness
of
the
slip
side
and
the
management
interface
to
the
behavior
model,
and
right
now
it
supports,
create
and
remove
operations
only
scalar,
not
all
no
get
no
SEC.
So
are
we
happy
with
that?
Do
we
want
to
set
Higher
Goals
who's
going
to
do
the
work?
J
What's
the
plan
for
that
I
think
that
that
needs
to
be
discussed
at
some
point
too,
and
then,
of
course,
once
we
make
some
agreements
on
an
overall
plan
that
then
we
can,
we
can
get
into
deep
Dives
on
each
issue
like
we
did
today.
You
know
on
the
behavior,
so
I
just
want
to
throw
that
out
there
because
I
don't
know
where
we're
at
and
where
we're
going.
You
know
myself,
and
maybe
that's
just
me,
but
I-
think
we
need
a
little
bit
of
some
documentation.
That
shows
our
plan
of
record.
J
B
We
can
assign
priority
I
can
propose
one
way
to
assign
priorities
first.
The
first
would
be
the
test
cases
that
can
run
but
fail.
Second,
would
be
the
test
cases
that
cannot
run
because
there
are
some
of
the
implementation
missing
and
third
would
be
test
cases.
That
cannot
even
be
done,
because
we
are
missing
some
some
apis
in
the
first
place.
I
can
we
can
start
by
by
fixing
what
was
supposed
to
be
working
but
fails.
First.
J
J
So
that'll
be
the
plan
of
record
and
and
then
what
we'll
do
should
we
should
we
break
that
into
some
kind
of
cadence,
or
you
know,
dot
releases
saying
these
are
associated
with
a
certain
release
plan
because
that'll
kind
of
give
an
ordering
to
things.
We
don't
want
to
work
on
the
least
important
feature
first
right
so.
A
The
the
second
part
that
Marianne
mentioned
the
implementation
could
be
missing
for
the
test
case
yeah.
For
that
you
know
if
there
is
a
further
Deep
dive,
but
I
guess
the
complete
plan.
There
may
not
be
available
right
at
the
beginning,
but
we
can
identify
some
of
the
implementation
that
may
be
missing,
that
we
have
identified
right
now
and
and
put
them
down
in
priority
list
priority
order
and
and
then
keep
adding
to
it.
J
Yeah
I
mean
I.
Think
the
test
plan
would
be
kind
of.
This
is
the
goal
we
want
all
these
things
working,
but
it's
not
really
a
an
action
plan
right
for
the
teams.
It's
just
a
goal.
It's
the
definition
of
what
the
output
should
be.
What
we
need
is
a
work
plan
and
yeah
break
I.
Agree
that
how
to
triage
and
prioritize
into
rough
categories.
J
C
I
I
just
wanted
to
add
one
thing
so
sometimes
go
ask
about
when
to
fail
the
issue,
so
maybe
in
this
case
we
can
start
failing
issue
on
the
dash
repo
first
and
then
you
know
open
and
follow-up
issues
if
needed
on
other
repos,
but
we
will
be
able
to
track
the
you
know.
Each
of
the
issue
on
the
Dutch,
repo
and
I
think
that
it
makes
sense.
J
K
So
guys
I
have
a
question,
you
know:
I
sorry,
I
I
joined
the
meeting
a
little
late,
so
I
missed
the
test
plan
review,
so
I
guess
with
every
you
know,
feature
or
release,
or
whatever
have
you
right?
We
we
have
these
test
plans
with
you
know,
which
is
comprised
of
certain
number
of
test
cases
right
and
we
reviewed
to
ensure
that
okay,
it
covers,
you
know
end
to
end.
It's
pretty
comprehensive.
It
essentially
is
going
to.
K
You
know,
have
a
provide
a
full
coverage
of
all
the
you
know,
cases
that
we
need
to
test
right.
So
so
do
we
want
to
really?
You
know,
have
a
PR
that
people
can
review
and
put
their
comments
and
also
maybe
perhaps
suggest
more
test
cases
before
we
say
that
okay,
we
do
have
the
entire
test
plan,
and
then
this
will
becomes
a
plane
of
plan
of
record.
A
Yeah,
honey,
actually
Anton
did
not
present
it
today.
I
think
he
had
presented
in
the
dash
meeting
at
some
point,
but
totally
agree
that
there
is
a
PR
for
that
and
we
should
add
comments
to
it
and
solidify
it,
and
we
should
all
agree
on
the
plan
and
and
then
and
then
actually
close
on
it
sometime
soon.
K
A
Yeah
I
agree
for
the
future
implementations
once
the
implementation
is
completed
with
the
identified
items
that
are
missing
in
the
test.
The
future
implementation,
sorry
and
the
features
definitely
it'll
be
yeah.
We
should
we
should
ask
for
the
a
feature
honor
to
come
up
with
the
test
case.
That'd
be
really
great
here.
J
Thanks
yeah
and
I
think
I,
like
that
plan,
and
you
know
the
initial
test
case
that
accompanied
a
feature
doesn't
necessarily
have
to
be
exhaustive.
It
should
be
at
least
proved
the
basic
feature
enough
to
satisfy
and
also
to
catch
regressions
later,
and
you
know
we'll
take
some
of
these
sort
of
seed
Crystal
test
cases
like
we
have
the
v-net
out
and
we'll
probably
people
will
take
those
and
expand
on
them
and
use
them
as
the
starting
point
for
more
exhaustive
tests.
J
So
it's
real
important
to
get
that
first
test
case
that
can
teach
let's
say
test
test
people
who
might
want
to
focus
just
on
the
testing
to
sort
of
take
their
cue
from
the
initial
test
for
tests
and
build
on
it,
because
sometimes
it
requires
a
lot
of
deep
understanding
of
of
the
feature
or
the
behavior
of
the
pipeline
and
the
best
way
to
get.
That
is
the
first
test
case
that
the
expert
creates.
C
A
F
C
To
do
it,
that's
a
few
one,
but
so
maybe
just
a
quick
question.
We
have
four
minutes,
probably
about
the
VM,
v9
and
v-net.
So
my
question
is
why
we
cannot
use
for
the
indent,
for
example
the
v-net
ID
and
you
know,
look
up
the
vni
instead
of
the
DMV
now
and
why?
Why
do
we
need
this
v9?
Because
from
my
perspective
it
looks
like
the
same
field.
I
would
say,
because
once
we
create
a,
we
set
the
vni
ID
there.
F
C
C
What
info,
what
the
information
from
the
packet
we
have
to
use
for
the
routing
lookup
I
mean
that,
should
we
have
should
we
use
the
underlay
routing
and
the
fixed
LAN
header
for
under
the
loading
or
there
should
be
some
specific
kind
of
underlay
records
for
wrote,
Direct
because
I,
say
I,
certainly
know
the
row.
Direct
is
actually
doing.
The
Cup
and
the
packets
goes
from
the
appliance
as
a
end
caps
as
a
decapsulated.
C
B
B
After
so
you
stripped
and
then
so
the
problem
here
is
that
not
really
what
you
do
the
when
you
do
the
underlay
routing,
but
underlay
routing
should
be
after
the
overlay
routing.
Basically,
so
you
need
to
do
the
outbound
routing,
then
the
resulting
action
either.
It
is
be
excellent,
end
cap
for
v-net
route,
or
it
is
nothing
for
the
case
of
a
direct
route.
In
any
case,
you
do
the
underlay
routing
after
that,
but.
C
B
What
is
effectively
programmed
is
ecmp
on
those
two
Port
router
interfaces.
That's
what
Sonic
programs,
because
the
dpu
isn't
sitting
somewhere
on
the
edge
of
the
network,
nothing
like
that.
It's
just
too
identical
tours
that
it
is
connected
to,
or
in
the
case
of
the.
Let's
take
another
interesting
example:
the
Smart
Switch.
B
B
So
it
is
a
similar
story,
even
if
dpu
is
discrete,
so
the
different
tactics
can
be
done
there,
but
the
result
will
be
the
same.
You
can
do
underly
routing
on
two
ports
with
ecmp.
You
can
do
ecmp
hashing.
If
you
want
to
you,
can
you
can
just
have
a
hash
algorithm
to
be
like
Ingress
Port,
sorry,
egress
Port
equals
Ingress
Port.
Basically
do
the
hairpinning
result
will
be
the
same.
K
B
K
Yeah
but
I
think
there
is
I,
don't
know
whether
the
question
was
to
do
with.
Basically,
there
is,
there
is
some
sort
of
a
routing.
We
do
say
that,
okay,
we
are
going
to
do
by
looking
at
the
underlay
one,
which
is
which
is
to
just
whether
or
not
we
are
going
to
admit
the
packet
for
further
processing,
and
then
that's.
If
that
is
the
way,
then
you
know
I
mean
that
that's
probably
the
explanation,
I
guess.
B
Yeah
but
then,
after
that,
you
again
have
like,
if
you
look
at
the
full,
if
you
would
like
to
build
the
food
theoretical
pipeline,
you
would
have
inbound
routing,
then
you
would
have
packets
stripped
after
you
validated
that
this
packet
is
allowed.
You
strip
the
vxlan,
then
you
go
along
with
the
inbound
pipeline.
You
see
that
this
packet
belongs
to
some
eni.
Then
you
do
vxlan
end
cup.