►
From YouTube: SONiC DASH Workgroup Community Meeting Feb 22 3023
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Community
call
it
looks
like
this
is
our
57th
meeting,
so
we've
looked,
we've
been
meeting
a
long
time.
It
looks
like
last
week
we
talked
about
these
things
in
the
notes
and
maybe
Yusuf.
A
If
you
can
help
me
out
a
little
bit,
but
it
looks
like
looks
like
we
covered
inbound
routing
scale
and
we
had
a
PR
332
and
we
had
pr336,
and
then
we
talked
about
the
difference
between
the
subnet
alkyl
and
the
v-net
apple
and
I
believe
these
would
be
Echo
level,
one
two
and
three
which
was
in
the
packet
Transformations
document
or
the
pipeline
document.
I,
can
pull
that
up.
A
If
we
need
to
see
that
and
and
do
we
have
any
minimum
Max
requirement
for
bulk
API,
so
so
this
is
what
it
looks
like
we
talked
about
last
week
right.
Everyone.
A
And
if
there
were
okay
and
if
there
were
things
we
wanted
to
cover
from
here
or
PRS,
we
want
to
start
covering
this
week.
I
can
pull
up
my
screen
and
take
a
look
at
that.
The
pr
list,
if
you
give
me
just
a
second
here
I,
can
pull
up
the
PRS
that
I've
seen
kind
of
coming
through
this
week.
A
A
A
Track
I
requested
an
approval
from
Prince
here.
I
can
work
with
him
here.
I
must
have
made
some
sort
of
quick
change
here.
A
Yeah
I
was
just
making
a
change
to
further
Define
active
flows
and
things
like
that.
So
I'll
work
with
Prince
on
that
one.
A
A
Anyone
anyone
else
want
to
go
first
or
do
we
want
to
just
start.
B
I
can
talk
about,
let's
see,
I'm
trying
to
read
it.
It
says
three,
four,
it
says
issue
I
think
it's
the
second
one.
B
That's
a
little
funny
last
week
at
the
behavioral
model,
meeting
well
discussed
Andy's
PR
to
add
the
P4
dpdk
compilation,
and
so
we
compile
we'll
now
compile
the
code
against
the
P4
dpdk
backend
as
part
of
ongoing
regression
testing
and
in
fact,
hanaf
raised
the
question.
Well,
so
we
don't
know
if
this
is
going
to
publish
to
Docker
to
ACR,
because
that's
the
one
thing
that
is
not
done
until
you
do
a
pull
request.
B
I
said:
correct,
I'll
watch
it
and
so
I
merged
the
request,
and
lo
and
behold
it
did
not
publish
to
ACR
and
I,
dug
in
and
found
out.
None
of
them
were
being
published
at
ACR
anymore.
We
we
broke
it
when
we
changed
it
from
Azure
to
Sonic,
net,
okay
and
all
the
CI
scripts
have
some
conditional
code
in
there.
B
That
says
only
publish
if
this
repo
running
this
CI
script
is
azure
Dash,
so
instead
of
a
fork,
in
other
words
and
so
I
I
went
through
in
this
PR
and
modified
all
the
CI
scripts
to
change
that
too.
If
the
repo
running
this
is
Sonic
net,
so
it's
just
an
oversight.
It
was
like
a
loose
end
from
the
repo
migration,
and
the
ironic
thing
is:
there's
no
way
to
really.
A
On
about
you
said,
it's
just
always
not
possible
to
die.
B
Oh,
it
was
kind
of
a
silent
failure
and
I
don't
know
what
the
remedy
for
that
is.
B
You
can
look
at
the
files
changed
and
see
all
the
scripts.
So
once
this
is
merged,
we'll
find
out
it's
going
to
really
work
right,
grpc
yeah,
all
the
see
how
I'm
just
changing
everything-
and
there
was
a
few-
there-
was
a
few
loose
ends
and
some
image
files
too
or
my
script-
didn't
catch.
I
was
looking
for
GitHub
.com,
Azure
instead
of
just
Azure,
so
that
was
kind
of
maybe
my
oversight.
There
anyway
did
you
picked
it.
A
So
I
wonder
if
any
GitHub
experts
on
the
call
would
know
that
you
know
if
we
do
migrate,
a
repo,
how
do
we?
How
do
we
catch
everything
that
might
be
hard
coded
to
a
specific
repo,
It,
Go,
Go,
Hunter,
Prince
or
anyone
else
super?
That
means
a
lot
of
mirror.
Do
you
guys
know
or
it's
something
we
can
go,
investigate,
I
guess.
E
B
Yeah
yeah,
it's
probably
just
like
a
checklist.
You
know
when
you
migrate,
repo,
here's
all
the
things
you
better
pre-pre-vet,
let's
say
before
you
actually
push
throw
the
switch.
You
know
it's
just,
but
you
know
you
learn
something
new
every
day.
Okay,.
B
That's
the
ironic
thing
is
the
scripts
when,
when
we
do
the
make
files-
and
we
try
to
pull
the
document,
if
it
fails
to
pull
it,
just
builds
it
locally
in
place,
so
the
silent
failure
is
well
it'll,
take
a
little
longer
to
run
the
CI
script.
But
no
one
knows
it
happened.
So
unless
you
read
the
scripts
all
right,
so
it's
got
a
built-in
safety
net,
which
is
good.
B
So
that's
what
this
is
and
if
we
just.
C
A
quick
question
Chris
on
on
this,
where
you
define
the
GitHub
repository,
could
you
have
defined
this
one
as
a
URL
like
like
https,
you
know
your
your
scripture?
C
B
So
I
I
don't
know
I'm
I'm,
assuming
that
that
those
variables
GitHub
dot
repository
Etc
is
a
is
a
well-known.
B
You
know
attribute,
that's
that
exists
within
the
context
of
this
script
and
it's
looking
for
the
name,
not
the
URL.
That's
that's
my
son.
Just
reading
this
I
didn't
write
particularly
I'm,
not
an
expert
in
every
Nuance
of
these
of
these
GitHub
workflow
commands,
but
I,
don't
I!
Guess
that
would
have
just
I
would
might
have
found
it.
When
I
did
my
string
search,
that's
right.
C
B
Guess
Azure
Dash
in
my
string,
search
I
would
have
found
this
too.
It's
just
one
of
those
oversights,
but
what
I'm
saying
is
that
I
mean
just
with
the
words
of
wisdom
before
and
what
migrates
a
repo
there
ought
to
probably
be
some
checklist
in
general.
You
know
just
kind
of
a
reminder
and
that's
probably
just
GitHub
travel
knowledge.
A
Yeah
yeah
did
we
need
to
cover
233
some
more
about
breaking
breaking
this
into
two
issues,
and
you
know,
and
do
we
need
to
cover
any
more
of
this
Anton
this
week?
A
And
let's
see
Prince,
which
one
here.
A
G
One
I
I
think
I
can
discuss
number
three,
but
before
that
one
two
three
yeah,
but
before
that
I
like
there
are
few
peers
that
we
already
discussed
and
almost
ready
for
merge.
But
we
need
some
approval,
so
the
actual
one
optimized
cycle.
So
this
we
discussed
last
week
and
if
I
think
some
of
the
comments
that
was
discussed
was
also
addressed.
G
Yeah,
so
Marine
is
reviewing
some
of
the
behavioral
model
part,
but
on
the
hld
I
think
there
were
some
comments
from
last
week's
feedback,
so
if
honey
for
someone
can
approve,
that
would
be
great.
Let.
C
Yeah
I'll
look
at
it
today
and
then
hopefully
approve
it.
Thanks
honey.
H
One
question
on
this:
so
the
gnma
model
and
the
style
API
kind
of
reversed
it
for
this
one,
the
tag
key.
G
Do
you
know
my
no
it's
it's
pretty
much
the
same
right.
What
do
you
I.
H
H
G
H
G
Imagine
you
will
okay
yeah
awesome
so
because
I
think
we
need
to
probably
Marine
Mukesh
also
to
take
care
of
tonight,
so
yeah
and
then
I
think
Vijay
should
be
here.
Vijay
on
that
metering,
I
believe
we
have
addressed
everything
right.
Is
there
anything.
G
Because
that's
a
PR
that
we
wouldn't
need
to
merge
as
well,
can
you
scroll
down
maybe
yeah
and
outbound
metering.
A
G
You
yeah
I
think
this
one.
We
would
need
again
like
Honeys
and
Gohan's.
A
Tourist
time
around
okay,
did
you
want.
G
This
one
yeah
I
think
we
can
yeah.
This
is,
if
you
clarifications,
and
also
a
new
scenario,
that
is
being
that
is
missed
in
the
the
previous
definition,
so
that's
being
newly
added.
G
So
basically,
this
is
called
private
link
on
NSG.
So
it's
a
it's
a
third
level
of
encapsulation
as
compared
to
the
existing
private
link
model.
So
in
today's
private
link
definitions,
what
what
we
have
done
is
two
level
of
encapsulation.
One
is
ipv4
to
IPv6
transposition
and
the
other
is
a
nvgr
or
vxlan
and
cap
right.
So.
G
This
one
like
yeah,
that's
the
one
that
you
can
highlight.
So
if
the
routing
action
type
is
private
link
NSG
this,
this
type
was
already
defined
earlier,
but
we
haven't
expanded
on
the
on
on
the
action.
So
that's
what
is
being
this
PR
about,
so
we
called
out
all
the
different
routing
types
in
the
original
hld,
like
Direct,
in
a
direct
private
link
and-
and
one
of
that
was
also
privately
NSU,
and
this
is
how
it
would
look
like.
G
So
there
will
be
a
third
action
as
compared
to
the
regular
private
link,
which
will
be
a
an
encapsulation
to
an
appliance.
G
So
that's
what
is
the
action
three
and
and
the
pipeline
shell
to
one
more
level
of
encapsulation
and
forward
that
packet
to
this
this
Appliance
or
a
dedicated
device
that
does
all
the
nsgs
so
an
example
is
captured
here,
but
maybe
Krishna.
If
we
can
scroll
up
a
bit
on
that
yeah.
So
yeah
I
think
this
this
one.
G
So
you
see
the
the
mapping
table
can
have
like
now
different
action
type
one
one
of
this
newly
introduced
one
is
private
link
nsta,
so
we
have
already
defined
private
link
earlier,
so
this
one
will
have
a
private
link
industry
and
you
can
also
see
a
routing
Appliance
ID
that
is
being
mentioned,
so
that
will
be
used
for
the
third
level
of
encapsulation.
G
G
So
this
is
the
destination
IP
of
the
the
third
encapsulation
and
the
source
is
nothing
but
the
source
of
that
the
current
Appliance.
So
that's
why
it's
not
explicitly
mentioned.
G
So
this
is
about
private
link
industry,
but
basically
an
extension
to
the
private
link.
Yeah.
E
G
This
one
is
encapping
everything
to
the
to
that
gun,
so
we
haven't
had
we
don't
have
a
model
where
we
can.
We
are
in
capping
only
the
the
first
packet,
but
if
that
is
if,
when
that
becomes
our
requirement,
we'll
probably
would
need
to
extend
the
this,
but
but
at
this
point
for
of
for
all
the
packets
that
are
testing
to
this
IP
like
10209,
it's
it's
all
encapsulated
to
that.
G
And
not
this
just
now
you
can
scroll
scroll.
A
How
far
what.
G
So
I
think
I
mentioned
that
at
the
last
statement
like
in
bone
flow.
A
G
H
A
I
know
I
know:
I
was
just
reading
what
the
differences
were.
Sorry.
E
But
do
we
know
that
you
know
the
Fast
Cash
will
also
bypass
this
young
HD
device,
or
we
don't
know
that
we.
G
Don't
know
that
for
private
link,
NSG
I,
don't
know
the
the
fast
path
Behavior.
A
G
Yeah
I
think
we
we
have
to
have
the
fast
path,
behavior
model
for
all
different
actions
as
well,
not
just
for
private
link.
It's
a
missing
for
service
tunnels,
also.
G
Yeah,
so
so
this
one
one
more
thing,
I
captured
in
the
same
appear,
is
like.
If
you
scroll
up,
there
is
one
few
questions
that
we
had
in
the
past
about
the
outer
encapsulation
Behavior.
So
that's
3.3,.
G
I
think
I
I,
remember,
like
you
know
some
of
our
discussions.
What
what
should
be
the
outer
DHCP
those
values?
So
that's
this
section.
Basically,
all
the
outer
end
cap
will
be
independent
of
the
the
actual
package.
So
when
the
appliance
encapsulate
the
packet,
the
outer
DHCP
shall
be
reset
to
zero
and
TTL
is
like
at
a
predefined
value.
G
E
Machines,
these
parties
need
a
little
bit.
Are
you
talking
about
the
customer
order,
or
are
you
talking
about
the.
E
But
I
saw
the
you
know
the
clients
they
have.
This
trust
me
beans
right
so.
G
So
Trace
me
a
bit
if
that
is
that
is
required,
then
I
think
we
need
to
have
a
different
different
setting
for
that
I
believe
on,
like
we
cannot
have
the
default
Behavior
to
to
be
uniform.
This
is
like
a
default
Behavior.
E
No,
no,
but
what
no
I
saw
this
one
two
scenes
right.
So
why
is
that
you
know
for
the
customers
packet?
You
will
initially
get
to
the
place
that
one
we
need
to
set
a
policy
to
determine.
You
know
what
is
a
you
know
what
what
is
the
DHCP
for
that,
but
after
that,
once
we
have
the
once
we
derive
that
outer
header,
then
everything
else
we
actually
will
add
additional
layer
of
the
header.
It
should
always
copy
the
DHCP
right.
E
G
E
G
E
Yeah
but
I
saw
that
kind
of
header.
You
know
the
DHCP
value
is
already
embedded
in
the
from
the
VM
to
the
appliance
that
should
always
having
that
values.
There.
E
Because
you
want
to
trace
all
the
way
you
know,
you
know
to
make
sure
that
you
know
the
packet
goes
all
the
way
to
to
the
place
where
I
should,
even
between
the
VM
to
the
Appliance.
You
need
to
know
that
right,
so
you
need
to
you
need
to
understand
that
packet
hack
can
be
traceable
even
from
the
VM
to
the
to
the
Appliance
I.
Think
that
Hatter
should
be.
You
know,
whatever
the
the
you
know,
the
deal
should
it
be
there
already
embedded
in
the
vehicle.
E
G
So
then,
I
think,
if
I,
if
I
yeah,
if
I
understand
correctly,
that
means
the
the
default
Appliance
Behavior
must
be
uniform
instead
of
pipe.
E
G
Okay
and
and
TTL,
of
course
we
can,
we
can
have
the
the
pipe
but
yeah
it's.
E
A
little
bit
it's
a
little
bit,
you
know
on
the
uniform
side,
because
it's
not
so
because
of
you
know.
When
you
get
to
the
place,
you
first
Decap
the
header
right
so
and
then
you
know
try
to
do
that
in
cap,
but
the
ink
cap,
the
DHCP
value,
is
not
deriving
from
the
original
customers.
G
A
Be
uniforms
or
dependent.
G
A
A
D
Christina
yeah
I
just
wanted
to
mention
about
the
first
pull
request
here:
I
just.
H
D
It
this
is
another,
let's
say:
infrastructure
changes,
so
we're
moving
the
side
repo
to
the
official
open
compute,
because
currently
the
the
repo
is
using
is
used
here.
So
I
will
move
into
the
to
show,
let's
say
open,
compute
PSI
as
a
sub
size
sub
model.
So
it
still
requires
some,
let's
say
fixes
to
make
the
Jenkins
happy,
but
just
for
everyone
to
understand
always.
A
B
No
no
lips
eye,
it
needs
a
new
W
function.
Api.
It
looks
like
Psy
added
a
new
function
to
the
headers
right,
API
uninitialized
also.
I
A
little
bit
more,
but
basically
the
there
was
a
vxlan
issue
that
was
in
PTF
that
didn't
let
us
use.
You
know
the
official
ocp
as
ocp
PSI
as
the
sub
module,
and
now
the
CP
size
pointing
to
the
latest
PDF
MP4
language
has
this
fix
and
it's
merged
so
we're
using
the
ocp
size
submodule
here
in
dash
directly
without
using
our
private
repo
that
we
had
to
use
all
this
while
so
I,
don't
know
if
there's
any
change
required
in
the
CI.
For
this.
I
In
the
CI
CD
I
don't
know
if
you
need
any
change.
No.
B
B
Yes,
it
looks
like
that's
new
since
the
last
time
we
integrated
with
PSI
right,
and
so
there
needs
to
be
a
dummy
function
added
if
you
click
on
that,
if
you
click
on
that
link
below
in
the
next
section
this
one
yeah,
if
you
click
there,
you'll
see
the
code.
It's
it's
really
easy
looks
like
we
just
need
to
add
something.
Just
like
this.
B
When
I
uninitialize
I
mean
it's
probably
five
minutes
of
work,
and
you
can
try
that
and
build
it
locally
on
your
machine
blood
emergency
that
that
the
paths
probably
failing
on
your
local
machine
too,
if
you
just
try
to
run
make
all
it
would
fail,
so
I
recommend
you,
you
add
a
function,
should
look
some
similar
to
this
I.
Don't
know
the
function.
Signature
of
API
uninitialized
but
it'll,
be
in
the
side.
Header
files.
Add
that
try
it
out
locally.
B
It's
good
to
get
up
to
it's
good,
to
get
up
to
sync
with
Psy,
so
I.
B
Yeah,
if
I
see
it
passing-
and
you
know
it
looks
good
I-
can
merge
it
too.
We
don't
have
to
wait
a
week
right.
No,
no.
A
I
So
yeah
thanks
also
for
merging
332.
first
two
and
these
changes.
A
A
Okay,
guys
open
for
Q
a
then
or
if
you
want
to
bring
up
anything
else.
I
know
you
know,
you've
probably
noticed
I've
been
pushing
the
high
availability.
Excuse
me
high
availability
meetings
and
and
when
we
have
content
or
discussion
topics
we'll
pick
those
back
up.
It's
no
problem,
I,
don't
mind
holding
that
invite
and
keeping
that
so
still
have
that
on
our
calendars
and
oh
something
I
did
want
to
talk
about.
If
you
guys
don't
mind,
does
anyone
have
anything
else.
H
H
No,
no
just
a
question
for
like
Prince.
H
Many
yeah
I
put
it
in
the
chat
like
how
many
times
what
can
you
expect
and
how
many
prefixes
in
a
tag
or
the
other
way
around
how
many
tags
in
one
or
one
to
fix.
G
A
Good
point
Mukesh,
so
anyone
else
or
I
kind
of
had
one
thing:
I
wanted
to
bring
up
yeah.
F
So
it's
Eddie
here
so
I
guess
today:
I
have
a
tackle
with
the
Gohan
also,
so
we
give
the
so
we're
thinking
about
bringing
in
the
Alibaba
use
case,
so
we
probably
will
raise
it
at
the
pr
to
the
dash
and
then
maybe
like
two
weeks
from
now
so
not
next
week,
part
of
the
week
after
we
can
talk
about
that
hld.
F
A
And
so
what
I
wanted
to
talk
to
you
guys
about
is
especially
Prince
and
Gohan,
and
everyone
on
the
call
is,
you
know
we
do
have
behavioral
model
meeting
on
Thursday.
We
have
Dash
community
on
Wednesday
and
we
might
have
some
conflicts
on
Thursdays
and
so
I
was
curious.
What
you
all
thought
about,
combining
changing,
moving
meeting
times,
Maybe
Prince
or
Gohan?
Can
you
talk
about
a
little
bit
more,
but
is
it
still
beneficial
to
have
the
two
full
one-hour
meetings,
or
are
you
open
to
changes
or
not?
A
So
we
have
Wednesday
Dash
Community
call
where
we
talk
about
architecture.
We
talk
about
design,
we
talk
about
PRS,
we
have
q
a
we
talk
about
a
lot
of
different
things
in
the
different
features
and
then
on
Thursday.
We
have
behavioral
model
which
is
specific
to
the
pipeline
and
P4,
and
the
code
and
things
like
that,
and
so
does
it
make
sense
to
combine
those
or
keep
them
separate
or
change.
The
timing
just
curious
what
you
guys
think.
E
A
So
behavioral
model
is
like
I,
said
it's
specific
to.
A
P4
I
mean
maybe
it
was
kind
of
initiated
by
was
it
Marian,
reshma
hanif,
it's
things
more
related
to
that
and
P4
more
than
just
Dash
overall
am
I,
am
I
explaining
that
right,
honey.
C
Yeah
so
I
think
one
of
the
things
we
basically
did
for
the
you
know
for
the
for
the
behavioral
model
meeting.
Is
we
review
the
models
right
I
mean
when
people
have
models
to
to
review
and
then
get
the
feedback?
C
We
do
do
that
and
we
also
go
ahead,
and
you
know
talk
about
some
of
the
things
before
that
like
pertaining
to
bmv2,
or
perhaps
you
know
some
of
the
tests
that
were
running
on
those
Behavior
models,
so
it
was
very
specific
to
the
behavioral
model
and
we
always
had
something
to
talk
about,
unlike
which
has
really
stalled
in
terms
of
you
know,
whatever
we
have
done
so
far,
I
think
we
have
had
great
discussions
on
HSI,
but
there
hasn't
been
anything
else
going
on.
So
we
have
been
keep
on
canceling.
H
A
E
H
A
C
Yeah
so
I
think
and
for
General
PR
discussions.
We
use
Community
meetings
right.
So
those
two
meetings,
I
I,
believe
if,
if
you
want
to
reduce
the
frequency
of
the
the
behavior
model,
meeting
to
go
ahead
and
say:
okay,
we
do
it
every
other
week.
Maybe
that's
okay,
that
we
can.
We
can
do
those
Thursday
meetings
to
be
every
other
week
and
we
can
keep
the
register
meeting
as
every
week.
That
would
basically
also
be
fine,
but
yeah
I
guess
for
Hab
have
been
canceling
it
for
I.
C
A
I
could
also
move
it
and
try
and
find
a
time
where
people
other
people
could
attend
as
well
Prince.
What
do
you
think
so
so
Prince
behavioral.
E
E
A
Time,
okay,
we
could
do,
we
could
do
something
like
and
I'm,
not
saying
we
have
to
change
it
I'm
just
trying
to
get
your
guys's
thoughts.
You
know
and
I'm
happy
to
change
it.
What
what
does
everyone
else
think
are?
We
do
you
think
behavior
model
is
too
frequent
or.
I
A
Okay,
because
we
we
basically
have
bmv2
and
then
we
have
the
P4
dpdk
and
things
that
we
talk
about
there
and
the
last
yeah.
We
we
talk
about
a
lot
of
times.
We
talk
about
different
items
and
features
that
need
to
go
into
the
behavioral
model
and
how
we're
going
to
do
it
and
then
how
it
kind
of
works
into
this
graphic
here
and
the
different
things
we
need
to
clarify
and
then
the
Sonic
pieces
so
I
think
that's
pretty
good
idea.
A
A
Okay,
do
you
guys
think
30
minutes
would
be
enough
time.
I
A
I
A
H
A
Or
not
well,
and
that
one's
basically
about
are
we
optimizing
for
perfect
synchronization,
or
are
we
often
optimizing
for
a
performance
or
you
know?
How
are
we
going
to
manipulate
this?
You
know
that
I
mean
it's
a
lot
of
back
and
forth
in
that
discussion.
I
think
the
boxing,
and
so
it's
pretty
interesting,
so,
okay,
but
back
to
what
we're
doing
today,
anything
else
for
today,
then
any
other
PRS
or
things
we
want
to
talk
about.
A
I
A
All
right
and
how
is
this
something
that
the
Sonic
Team
or
we
need,
or
the
SDA
sdn
team
needs
to
prep
for
or
is
this
just
like
round
robin
all-around
conversation.