►
From YouTube: DASH HA Working Group June 21, 2022
Description
Please review/leave Comments for SAI HA API proposal by Marian - thank you!
https://github.com/opencomputeproject/SAI/pull/1500
A
Thanks
for
coming
to
this
week's
high
availability
meeting
and
this
week,
I
do
have
a
pr
submitted
by
marion
from
nvidia
to
the
open,
compute
psi
branch
experimental
here.
He
wanted
me
to
share
it
with
you
all,
I'm
not
sure
if
y'all
have
seen
it,
but
he
asked
me
to
share
it
here
with
the
community
and
and
maybe
look
it
over
before
we
meet
next
week.
So
it
looks
like
he's
defined
some
code
here
and
I
can
put
the
the
link
in
the
chat
window.
B
C
B
C
B
B
B
D
B
No,
this
is
a
different
subject.
This
is,
I
mean
well
they're,
they're
they're,
orthogonal
issues,
so
marion
is
created
by
experimental
entry.
I
started
in
march
he's
just
adding
to
it
as
we
go
along,
but
including
I
as
a
sub
module
in
the
dash
is
a
separate
topic.
That's
just
a
way
of
configuration
management
and
I've
already
got
that
working
and
I'll
show
it.
Tomorrow
morning.
D
Okay
sure
in
that
case,
because
even
like
from
intel
the
work
that
we
are
doing
for
the
you
know
the
test
harness
and
all
that
the
code
has
to
be
upstreamed
at
some
point
and
the
question
is
within
psy:
do
we
want
to
have
a
separate
dash
project
for
all
these
changes,
or
will
it
go
directly
under
psy?
That's
yeah!
Those
are
the
you
know,
discussions.
I
think
we
have
not
yet
had.
B
D
E
This
is
a
job
we
need
to
do
that
because
having
where
you
have
the
repo
makes
a
difference
legally
on.
What's
what's
going
on
there
and
we've
had
these
issues
in
the
past,
where
it
sits
and
whether
companies
can
contribute
and
all
that
kind
of
stuff.
So
we
need
to
have
that
discussion
not
in
this
meeting.
But
let's
take
note,
we
should
make
sure
that
the
whole
community
is
in
alignment
on
where
this
is
sitting
and
what
it
actually
means
legally.
B
E
B
E
A
Yeah
gerald
what
I
was
presenting
was
marion,
submitted
a
pull
request
here
to
the
open,
compute
sai
folder,
and
asked
me
to
present
it.
He
has
a
qbr.
So
this
is
his
side
proposal
for
h,
api
and
share
with
the
group
and
ask
to
leave
comments.
So
that's
what
I
was
doing
right
here.
I've
put
this
link
in
the
chat
window.
It's
about
200
lines
of
definition.
E
And
is
it
and
okay?
So
we
need
michael
and
other
engineers
to
review
this,
I'm
sure
they
did
it
based
on
what
we
talked
about,
but
we'll
just
need
to
go
through
this
in
detail.
I
don't
think
we
can
do
that.
I
think
that
if
people
know
us
here,
everybody
can
have
a
chance
over
the
next
week
to
go,
read
it
and
come
with
comments,
as
opposed
to
trying
to
read
it
real.
D
A
A
D
So
the
question
was
that
how
will
we
program
from
sdn
the
status
of
one
of
the
partners
to
be
the
one
that
would
sink
the
flows?
To
the
other
side?
It
would
be
more
like
basically,
that's
not
possible,
because
the
sdn
may
not
be
able
to
control
that.
So
in
that
case,
that
variable
that
was
added
for
status
of
sorry
active
status
would
be
more
like
a
query
attribute,
not
something
that
sdn
would
write
down
to
the
device.
D
E
D
Correct
that
part
is
totally
agreeable.
I
think
if
we
go
back
to
the
slides
that
marian
had
presented
last
time-
or
maybe
it's
here
somewhere-
there
was
in
the
in
the
session
attribute
in
the
one
of
the
session
attributes
was
the
active
role
for
the
device
to
sync
the
flows
to
the
partner
hi
partner
device,
and
that's
something
that
we
cannot
assign
from
the
sdn
standpoint
in
case
of
the
topology,
where
the
two
partners
are
equidistant
from
the
from
the
server
where
the
flows
originated
from.
E
E
E
E
All
we
need
to
guarantee
in
dash
is
that
it's
gonna
arrive
that
you
know
the
primary
will
be
the
preferred
and
that's
all
we
need
to
do
in
dash
and
bgp
and
how
people
want
to
configure
it,
whether
they
use
meds,
what
they
use.
You
know
asp,
pins
and
all
that
kind
of
stuff,
that's
kind
of
outside
the
scope.
As
long
as
it
happens,.