►
From YouTube: SONiC DASH Workgroup Community Meeting July 26 2023
Description
PR404 Adds dash underlay routing functionality (PR #402)
This PR provides extra P4 code for underlay routing.
Underlay.p4 is the file where the underlay routing is defined (set_nhop) to the port
For hairpin, if there is a route we will provide next_hop_id as NULL, it will hairpin (favor port from which traffic came)
Connect this to GitHub Issue405
Sanjay: if ECMP route (with 2 next_hops), could be a platform implementation
Once we have ECMP route, can take a hash. OR we do a hairpin (choose port it comes from).
Make a special 'type' such as a hairpin type?
If ECMP not enabled, then...routes with specific ports would have no ECMP
next_hop_id as NULL in a platform is typically blackholed, not hairpin…unless DPU strategy is to hairpin
Chris: Need to have predictable behavior for testing.
If we create this now, and need additional in the future, the API will need to be defined/asserted at that point
SAI API remains the same, DPU behavior is to hairpin (how this happens is up to the supplier)
Need routes w/proper next hops, and hairpin behavior with ECMP routes (explicit or not)
Next steps: modify PR to reflect
PR395 - Yuri reviewing
Issue406 NVGRE parsing
A
Community
cup
the
day
is
the
26th.
It's
our
77th
meeting
together
and
this
these
are
the
notes
I
sent
out
one
day
late,
but
last
week
we
have
the
the
project
board
here
and
the
items
to
do
and
in
progress.
And
then
last
week
we
talked
about
PR
404,
which
was
submitted
by
keysight
and
team,
specifically
to
start
providing
code
for
the
underlay
routing,
and
then
we
had
a
big
conversation
about
that.
A
So
that's
what
we
did
last
week
and
I
think
there
was
in
issue
390.
There
were
a
couple
more
questions
submitted
in
by
Vincent
to
finish
off
this
issue,
and
then
we
were
waiting
for
the
community
to
take
a
look
at
395.
so
and
last
week,
kumaresh,
Cynthia
and
Amit
came
so,
and
here's
here
are
the
links
to
the
recordings
down
here
in
case.
You
guys
need
to
see
them
so
anyway,
go
to
the
project
board.
Here,
oops.
A
A
B
B
B
A
A
A
Something
like
that,
okay,
awesome,
sorry
I
had
to
stop
sharing
that
for
a
minute,
I
was
having
a
that
little
tab
at
the
top.
I
can't
control
the
screen.
So
can
you
guys
see
my
screen?
Okay,
again,
yeah,
okay,
cool
and
then
this
one
382?
We
didn't
talk
about
it
last
time,
but
Marian
was
saying
that
PR
396
should
fix
this
bmv2
pipeline
source
code
change.
That
was
needed,
and
so
basically,
someone
had
come
to
us
and
said
that
that
there
was
when
you're
going
through
these,
that
it
was
out
of
order.
A
You
know
the
the
fields
were
out
of
order,
and
so
we
had
created
a
a
task
to
fix
it,
and
so
theoretically
this
should
be
fixed.
So
I
just
wanted
to.
Let
you
guys
know
and
I'll
close
it
out
today,
yeah,
okay
and
then
did
we
want
to
go
over
the
one
from
last
week
and
talk
about
it
more.
The
one
from
actually
Amit
and
mercha
presented
it
this
one
here.
C
So
yeah,
based
on
the
feedback
from
last
week
so
last
week,
Behavior
was
that
if
you
do
not
have
a
route
or
a
route
is
not
being
matched,
it
will
reflect
back
the
traffic
to
help
in
it.
And
if
you
have
a
route,
it
will
respect
the
route.
So
the
feedback
was
to
hover
out
even
for
hair.
Pinning
so
I
ask
a
question:
I
think
under
issues
how
to
define
that
and
the
way
I'm
suggesting
it
to
Define
if
it
provide
next
hope
ID
as
null.
C
A
D
C
Case
drop
yes,
so
that
was
the
comment
from
last
week
that
actually,
if
you
don't
have
a
route,
it
should
draw
not
hairpin,
as
is
doing
today,
and
you
should
add
a
default
route
on
purpose.
If
you
want
helping-
and
it
can
be
something
like
0.0.0
next
hope,
ID
file
object,
ID
null
and
that
will
start
the
hair
pinning.
But
if
you
don't
have
it,
it
will
just
drop
okay,
actually.
E
C
E
C
But
then
how
do
we
Define?
Because
somebody
asked
about
the
flag
last
time?
How
do
we
Define
when
the
route
should
respect
the
route
The
Hope
or
it
should
help
him
back?
So
that
was
my
question.
I
put
it
there
in
the
community
how
we
do
that
we're
using
the
site
API
as
a
definition
of
herpin
or
respect
the
routing,
so
the
only
ideas
that
I
could
think
of
is
to
put
the
null
as
helping
and
then
that
doesn't
require
any
update
or
any
change
to
the
site.
Api,
okay,.
E
E
E
E
Router
that
comes
from
the
route
the
route
around
and
the
next
stop
follow.
What
what
is
the
proper
way
to
set
it
up
right?
So
you
have
an
ECM
paired
out
with
two
next
stops
with
the
two
ports
and
the
ecmp
strategy.
You
could
have
multiple
different
ways
of
you
doing,
ecmp
on
those
two
ports,
so
the
route.
What
I'm
saying
is
the
next
stop
is
set
up
right
with
all
the
next
stop
IP
address
being
there.
E
The
MAC
address
is
resolved
by
the
by
the
implementation
setup
in
the
way
it
is
done
today,
and
the
only
thing
is
now
once
we
have
a
ecmp
it
out.
What
is
the
strategy
we
use
to
actually
load
balance?
The
traffic
one
way
could
be
traditionally,
it
is
done
by
taking
a
hash
and
right
picking
the
interface
based
on
the
hash
off
the
off
the
acnp
members.
Instead
of
that,
it
could
be
that
we
don't
do
a
hash,
but
we
just
do
a
hairpin.
We
just
choose
which
Port
it
came
from.
E
A
G
Yeah
I
think
that
next
stop
by
the
null
is
kind
of
encouraging
it's
normal,
because
if
the
platform
gets
a
mixed
up
ideal,
the
natural
thing
to
do
is
to
treat
that
route
as
a
black
hole,
route
and
drop
the
packet
so
doing
a
special
casing
for
next
stop
writing
null,
as
I
had
been,
seems
incorrect
and
it
wouldn't
match
with
the
platform.
Behavior
I,
guess
that's
what
Sanjay
is
suggesting.
Maybe
we
should
just
make
it
an
ecmp
and
have
a
special
type,
which
is
like
a
hairpin
time.
E
B
C
B
D
C
So
the
way
I
understood
it
now
is
that
today,
if
we
create
a
new
CMP
route
to
the
ecmp
strategy
for
dpu
for
bmv2
will
be
helping
basically
to
favor
the
port
where
the
traffic
came
on
and
no
change
to
the
side.
Api
just
we
need
to
create
a
museum
key
route.
It
will
do
airplane
as
a
strategy.
If
you
put
a
static
route
specifying
to
support
the
interface
it
will
respected
and
in
the
future,
if
there
is
a
need
for
another
strategy,
it
will
be
solve
the
other
time.
A
E
Or,
in
other
words,
what
you're
saying
is
whether
that
hairpin
is
an
implicit
thing
that
happens
internally
or
is
it
explicitly
configured
as
a
parameter
right?
It's
still
using
the
default,
I
mean
the
ecmp
route.
To
do
the
decide.
I
mean
mechanism
is
to
do
the
ecmp,
but
but
The
Hairpin
behavior
is
implicit
or
is
it
explosive
thing?
If
I
understood
the
discussion.
D
H
C
Yes,
I
API
Remains,
the
Same,
but
also
the
dpu
behavior
will
be
to
help
in.
So
we
will
have
to
specify
that
in
suspect
to
help
it.
If
another
strategy
is
being
chosen,
then
an
API
needs
to
be
created
to
allow
you
to
select
the
strategy,
but
I
think
the
expectation
will
be
that
the
behavior
will
be
the
same
across
all
vendors
and
the
desired
behavior
is
to
help
him.
H
C
E
To
summarize
right,
so
what
we
are
saying
is
no
change
in
I
mean
we'll
still
need
routes
with
proper
next
stops,
Etc
both
specific
routes
and
for
for
the
default,
which
will
actually
you
know,
at
least
in
in
practice,
will
be
used
for
The
Hairpin
for
all
routes
and
many
what
we
are
saying
is
it
will
be
properly
there's
no
missing
field
side,
there's!
No,
all
the
next
stops
are
provided
Etc,
but
if
it
is,
if
you
need
help
in
Behavior
it
you
could
achieve
it
by
having
an
ECM
period.
E
A
C
A
A
A
C
A
A
This
is
the
for
everyone:
who's
not
familiar
on
the
call,
but
there's
the
Sonic
hld,
that's
authored
by
the
Sonic
Team,
mostly
Prince,
with
the
help
of
Vijay
Sanjay
Marion
everybody
there.
So
these
are
the
changes
here
in
that
PR
and
in
a
couple
of
comments
here
that
excite
labs
and
everyone
helped
and
then
the
second
one.
We
call
this
the
hero
test.
It's
called
program,
scale,
testing
requirements,
and
so
these
were
the
changes
here.
A
A
So
one
of
our
members
from
the
v-net
sdn
team
kind
of
came
back
and
they
were
researching.
You
know
official
numbers
for
mappings,
including
peering,
and
we
support
64
000
per
Vena
today,
and
we
wanted
to
support
128
000
per
v-net
or
VPC
and
and
a
million
including
all
paired
vpcs.
So
basically
they
they
were
just
making
corrections
to
what
the
the
numbers
first
were
primarily
from
about
a
year
and
some
odd
some
change
ago,
and
so
they
just
kind
of
went
back
and
took
a
second
look:
okay
and
I'm.
Sorry
I'm!
C
C
A
H
H
F
H
H
B
I
was
looking
at
the
CI
test
run
and
I
couldn't
find
the
detail
on
the
actual
failure.
It's
interesting,
I
suggest
it's
not
shown
in
the
printout.
What
what
actually
failed,
but
I,
see
I
suspect.
My
first
guess
would
be
the
remitting
some
new
attributes
and
the
P4
runtime
API
is
going
to
be
complaining
that
you
know
you
didn't
specify
a
few
attributes.
You
have
to
specify
all
of
them.
B
B
Yeah
I
would
look
at
the
bmb2
log
and
look
for
an
error
message
about
parameter
number
mismatch
and
then,
if
you,
if
you
do
that,
you
can
actually
see
you
could
go
back
to
the
where
the
metering
was
added
that
PR
that
was
added
a
while
ago
and
look
at
some
of
the
recent
commits.
You
can
see
the
parameters
that
were
added
in
the
test
case
to
rectify
that.
It's
probably
the
same
thing:
I'm
guessing
but
I'm,
happy
to
work
on
this
back
Channel
one-on-one.
If
you
need
help
foreign.