►
From YouTube: DASH High Availability Working Group Aug 30 2022
Description
AMD provided an overview of their HA proposal
B
So
what
we're
presenting
is
a
proposal
for
the
thing
based
on
the
implementation
that
we
have
yeah
like
yeah,
so
we
have
I'll
just
give
a
quick
overview
on
what
is
to
come.
So
we
all
of
us
are,
you
know
we
know
what
to
expect
what's
coming
up
next,
so
I
think
we
have
some
design
goals.
We
have
a
functional
description
that
includes
how
the
network
topology
looks
and
what
we
have
designed
it
for,
and
we
also
kind
of
go
through.
What
are
the
ips
that
we
are?
B
What
do
we
expect
from
the
network
right
in
terms
of
the
whip
in
terms
of
the
loopbacks
that
we
expect,
and
then
there
is
how
the
activeactive
works.
Then
we
have
a
small
section
about
the
heartbeat
and
then
we
get
into
the
state
synchronization,
both
the
bulk
sync
and
data
path,
synchronization
of
how
it
works.
I
think
bulky
had
presented
some
of
this
already.
I
think
we
have
kind
of
taken
it
can
try
to
put
in
more
details
and
abstract
it.
Some
more
details.
B
We
have
kind
of
tried
to
bring
those
out
in
each
of
these
sections
and
then
we
go
through
one
go
through
the
state
machine
itself,
the
hs
state
machine,
some
explanation
of
the
states
and
after
that
I
think,
to
illustrate
what
we
mean
by
you
know:
there
are
a
lot
of
messages
that
are
going
across
in
each
of
the
states,
etc.
So
there
are
two
sections
for
these
messages.
This
is
this
is,
I
think
the
messages
themselves
are
illustrated
to
show
what
we
mean
by
what
should
go
in
these
messages.
B
There's
one
set
of
side,
definitions
right:
this
is
the
interaction
between
the
sonic
layer
and
the
sdk
and
anything
the
tpu
hardware,
software
underneath
that
and
then
finally,
we
have
we
have
some
control
plane
messages.
These
are
the
messages
that
are
going,
that
we
are
proposing,
go
between
the
two
sonic
instances
right
and
and
then
there
are
some
message
flows
right.
So
we
have
taken
some
important
procedures
like
the
node,
pairing
and
pulsing
and
how
that
is
what
are
the
message
flow
between
them?
B
B
B
So
these
are
the
from
you
know.
Getting
from
the
get
go
from
the
design
goals
is
what
I'll
get
presented
to.
So
here
we
are
saying
so
we
are
on
on
switchover.
The
intent
is
that
all
connections
set
up
before
the
switchover
have
to
reliably
work.
Whenever
there
is
a
switch
over
either
planned
or
unplanned
right
we're
trying
to
keep
the
drops
if
there
was
a
flow
that
was
allowed
before
and
it
was
functioning.
B
We
tried
to
never
drop
that
flow
or
create
a
disruption
in
that
flow
for
plants,
whichever
the
design
is
attempts
to
get
a
zero
down
time
for
plant
switch
hours
and
less
than
two
second
downtime
for
unplanned
switchovers,
also
because
of
floor
replication.
We
don't
want
any
data
packets
to
be
dropped.
That
is
a
goal
that
we
try
to
achieve
and,
of
course,
the
high
cps
rates
that
are
the
requirement
here.
B
One
goal
is
to
actually
not
over
use
the
pps
path
and
keep
the
data
traffic
to
them
as
minimum
as
possible
right
and
sync
only
the
required
packets
we're
at
a
very
high
level.
This
is
the
I
think,
just
to
clear
out
the
terminology
in
terms
of
how
we
are
using
terms
to
look.
So
there
is
a
sonic
stack
about.
This
is
all
the
sync
d
asws
everything
else
at
enmi.
Everything
else
then
there's
the
dash
sdk.
This
is
the
implementer
implementation,
the
sdk
layer,
then
there's
the
dpu.
B
The
dpu
could
be
hardware
or
could
be
any
associated
software
components.
For
example,
we
might
have
some
software
components
for
the
cps
path,
and
things
like
that,
so
the
dpo
is
one
glob
which
covers
both
the
hardware
and
the
software
components
where
everything
that
is
under
the
dash
sdk
is
the
tpu.
B
B
And
apart
from
that,
we
have
because
we
don't
want
the
to
be
tied
to
any
of
the
physical
links.
We
have
a
loopback
ip,
which
is
apart
from
these
two
link,
ips,
which
we
call
as
the
control
plane,
ip
right
or
the
control
network
id.
And
then
there
are
two
data
pathways
that
are
shared
between
the
dpus
and
both
of
them
advertisement.
They
kind
of
own,
the
first
one,
the
control
network
ip
is
owned
by
each.
B
You
know
it's
unique
to
each
dpu
and
the
reason
we
need
the
control
plane,
ipa,
so
that
if
any
one
of
the
links
go
down,
we
don't
kind
of
bring
down
h.
There
is
still
a
identity
that
can
be
reached
as
long
as
there
is
right,
so
the
control
plane
ipr,
the
cnip
as
we
use
it,
underneath
this
is
used
for
all
the
control
plane
traffic,
for
example,
all
the
synchronization,
both
bulk
and
data
path.
B
Sync
any
heartbeat
messages
that
go
between
the
two
or
any
control
messages
in
the
proposal
to
move
the
states
from
from
for
the
state
machine
from
one
state
to
the
other.
So
everything
that
we
want
for
the
control
plane
or
anything
that
dput
dpu
traffic
is
originated
using
the
cnip
and
terminated
using
the.
B
B
B
One
of
the
whips
will
be
primary
and
the
other
will
be
secondary
on
one
dpu
and
it
will
be
a
mirror
image
on
the
other
side
right,
so
the
other
whip
will
be
primary
and
secondary.
The
idea
is,
if
one
of
the
tpu
fades
or
if
there
is
a
switch
over,
then
the
surviving
dpu
kind
of
becomes
primary
for
both
reps
right
and
then
continues
to
service
all
traffic
for
them.
B
So
this
is
how,
because
of
this,
we
are
able
to
do
active
active,
so
each
eni
is
assigned
two
of
it
right,
so
both
the
so.
This
is
what
we
call
as
eni,
based
active
active
and
the
data
paths
for
both
the
on
both
the
dpus
are
always
always
forwarding
and
always
active
in
terms
of
the
forward
part,
because
they
are
active
for
either
either
one
of
the
pips
at
least
one
of
the
website.
B
Then
there
is
a
data
path
heartbeat.
There
is
a
heartbeat
message
that
is
periodically
sent
between
the
two
dpus.
There
is
a
configurable
interval
and
there
is
a
how
many
loss
can
we
tolerate
right?
If
the?
If
there
are
x
number
of
losses
between
the
heartbeat,
then
we
declare
that
the
pier
has
been
lost.
B
A
Hey
sanjay
yeah.
I
have
a
question
so
this
data
plane
whips
right
like
so,
I
think
like
theoretically,
each
dpu
can
I
mean
like
it,
can
obviously
handle
multiple
enis
and
this
enas
can
be
replicated
across
a
different
set
of
dpu
pairs
right
and
now
yeah
like
so.
If
we,
if
we
have
this
dp
pairs,
do
you
expect
that
each
dp,
you
have
like
multiple
of
this
books
or
we'll
just
pair
with
just
one
other
dpu,
and
they
will
just
yeah
like
provide
for
the
cni's.
B
C
All
they
know
is
they
the
those
multiple
gpus
have
identical
policies
and
different
connections
land
on
each,
but
that's
done
by
spreading
it
through
some
ecmp
algorithm
at
the
vm
itself.
So
the
dpus
actually
don't
know
that
there's
another
gpu
handling
some
of
the
connections
for
that
eni
that
have
no
idea.
So
from
their
perspective,
it's
just
you
know
two
bips.
C
D
I
believe
the
question
was
perhaps
the
sharing
of
the
whip
across
multiple
enis
right.
The
way
I
understood
it,
because
what
happens
is
that
you
know
if
you
have
a
primary
and
secondary
webs,
are
they
primary
and
secondary
per
eni?
Because
if
you
think
about
it
right,
any
dpu
could
be
an
active
for
some
enis,
but
you
know
standby
for
others,
and
vice
versa.
Right
so
in
that
sense
are
the:
are
we
really
controlling
at
the
whip
level
or
you
can
be
controlling
it?
C
D
Correct,
but
what
happens
is
that
you
know
your
dpu
is
not
the
entire
dpu
is
not
really
acting
as
a
standby
for
all
all
the
ends
that
it
is
serving,
it
could
be
half
and
up
right.
You
can
say
that,
however,
the
enis
are
probably
you
know
right
right,
right,
correct.
So
then,
then,
the
the
question
here
is
that
you
know
how
are
we
really
distributing?
E
Yeah
yeah,
I
think
I
think
you
know
the
way
piece
per
per
card
right,
so
you
know,
because
you
cannot
really
advertise
too
many
whips
because
cause
some
other
issues
for
the
underlying
network,
but
I
think
you
know
this
party,
I
I
I
would
say
it's
not.
You
know
directly
relevant
to
the
to
the
hd
park.
It's
a
you
know,
because
you
know
different
setup.
A
different
you
know
setup
may
have
a
different.
You
know
how
they
advertise
the
vape
right.
E
A
E
A
B
A
A
A
A
E
E
I
think
I
think
maybe
you
know
this
is
a
little
bit
confusing
as
we
we
should
focus
on
the
you
know
the
h.a
part,
because
the
setup
I
think
it
could
be
different.
You
know
you
know.
Maybe
we
should
you
know
you
know,
simplify
the
dog
a
little
bit
and
focus
on
entry
part.
You
know
saying
that
you
know
for
the
hra.
We
should
focus
on
per
yin
ai
based
hr,
so
every
year,
and
I
we
should
be
able
to
you
know,
do
the
trade
right
so
that
that
is.
E
C
E
D
I
have
a
question,
let's
say
in
a
configuration,
you
have
a
simple
configuration
of
two
dpus
and
you
have
64
enis.
Are
you
going
to
have
all
64
eni
is
going
to
be
back?
You
know
active
on
one
dpu
and
then
another
dpu,
basically
acting
as
a
as
a
as
a
standby
for
the
the
those
all
64.
Or
are
you
going
to
really
split
them
onto
both
the
dpus
saying
that
okay
32
are
actually
1,
1
and
32
are
acting
on
other
ones?
D
B
D
Tpu,
this
is
exactly
my
point
and
now
now
what
happens
is
that
if
that
were
to
be
the
case
right
and
that's
how
I
understood
it
as
well?
If
that
were
to
be
the
case
right,
then
your
whip
advertisements
are
different
for
different
dni
right.
So
so,
and
in
one
case
you
know
one
one
dpu
is
advertising
the
secondary
repair,
the
primary
or
or
you
know,
and
vice
versa,
so
that
they
know
that
okay,
this
is
how
it
is
working
is,
isn't
it
isn't
it
the
case
right
that
is.
B
Okay,
so
the
it
is
mirrored
so
there
is.
We
haven't
gone
too
much
into
detail
into
the
actual
advertisement
on
how
we
are
controlling
the
the
bgp
advertisements
or
whatever
the
protocol
advertisements,
but
we
can
so
there
is
the
way
it
would
be.
Is
it
will
be
mirrored
so
the
way
the
standby
or
the
secondary
announces
the
announces
to
whips
one
whip
will
have
a
good
metric.
The
second
whip
will
have
a
less
desirable
metric
and
it
will
be
the
mirror
image
on
the
other
side.
On
the
other.
D
D
B
B
Then,
if
there
is
nothing
more,
you
can
go
to
the
synchronization
itself,
so
the
state
synchronization
here.
I
think
this
uses
that,
as
we
said
before,
this
uses
the
cna
pipey-
and
you
know
this
originates
in
this
thing,
the
the
so
there
are
two
pieces
for
the
straight
synchronization
there's
a
bulk
sink,
and
then
there
is
a
the
data
path
sink,
which
happens,
which
is
the
flow
by
flow
sync,
and
then
there
is
a
bulk
sink
right
effectively.
B
I
think
there
are
two
channels
or
two
pipes
that
we
have
to
communicate
between
the
two
one
is
the
control
plane
channel
and
one
one
is
the
dpsing
channel.
As
the
name
indicates,
the
control
plane
channel
is
used
for
all
the
control
pane
messages
between
the
two
tpus
dps.
I
mean
the
whole
units,
and
then
there
is
a
datapath
sync
channel,
which
is
which
connects
the
two
tpus.
The
actual
forwarding
this
thing
to
synchronize
the
flow
by
flow
I
mean
flow
by
flow.
Sync
happens
there
right
so
the
control
plane
channel
in
this
proposal.
B
We
are,
I
mean
it's
represented
as
mean
it
is
it's
a
bi-directional
grpc
stream
that
goes
between
the
two
instances,
and
these
the
stream
can
carry
messages
between
the
sonic
stacks
right.
This
might
be
for
controlling
the
state,
machine
or
messages
to
that
effect,
or
it
could
be
messages
that
are
going.
You
know
the
dpu
to
dpu.
If
there
are
some
messages
that
need
to
go,
it
gets
relayed
through
the
sonic
stack
via
the
control
plane
channel,
but
effectively
it
is
a
streaming
channel.
I
think
what
the
bi-directional
the
streaming
gives
us.
B
It
gives
us
more
efficiency
and
it
gives
us
enough.
There
are
no.
If
there
were
if
it
was
a
unary
kind
of
a
thing,
if
it
was
a
request,
response
kind
of
a
thing
it
becomes
slower.
So
this
stream
gives
us
some
advantage
there,
and
the
dpsing
channel
is
also
another
stream
between
the
two
dps,
which
carries
the
flow
by
layer
flow
by
flow
sync
messages
between
them.
B
B
Yes
yeah,
so
this
might
be
there
are.
There
are
messages
that
are,
I
mean
there
might
be
messages
on
the
control
plane
channel,
which
are
originated
by
the
sonic
stack
itself.
That
is
the
orange
line.
There
is
a
purple
line
where
the
dpu,
if
there
is
some
control,
plane
information
that
mean
if
there
is
some
signaling
that
needs
to
go
between
the
dpus
too
there
could
be.
B
I
think
the
dpu
also
could,
via
this
eye,
there
might
be
notifications
that
come
up
get
relayed
across
this
control,
plane
channel
and
to
the
other
side.
So
these
are
essentially
control,
plane
messages,
but
not
between
the
dpu,
but
not
the
data
path.
Sync
messages
if
everything
else
goes
via
the
same
control,
plane
channel.
E
B
B
Okay,
so
the
bulk
sync
itself
is
when
we
need
it
is
we
have
one
gpu
which
boots
up
and
then
when,
when
the
dpu
comes
up,
you
know
the
lifetime.
We
could
see
that
there
is
no
other
peer,
we
wait
for
a
timeout
and
then
it
would
go
into
what
we
call
as
the
primary
standalone
mode
right.
So
it
is
configured
as
it
is
working
as
primary,
but
it
is
not
syncing
anywhere.
It
is
in
standalone
right,
so
this
would
be
for
both
the
webs.
B
Let's
say
at
some
later
point
in
time.
The
second
dpu
comes
online
when
the
second,
the
pr
dpu
comes
online,
the
two
would
detect
each
other.
The
two
dps
would
detect
each
other.
Now
the
the
the
new
dpu
that
is
coming
up
would
need
to
sync
up
all
the
state
from
all
the
accumulated
state
from
the
primary
right,
whatever
was
in
the
primary
standalone
mode.
B
So
this
is
when
we
do
the
pulsing
right
at
this
point
in
time
we
use
the
control
plane
channel
that
we
have
and
then
on
this
channel
we
sync
all
the
slope.
No,
all
this
accumulated
state
right.
So
this
is
a
bi-directional
stream
and
in
this
stream
the
key
difference
here.
I
think
why
it's
been
a
stream.
Is
we
want
to
from
our
experience.
B
What
we
have
discovered
is
the
indiscriminately.
You
know
if
you
just
dump
all
the
state
to
the
other
side
to
the
other
dpo
it
can
start
affecting.
Sometimes
you
know,
one
of
the
whips
might
have
come
online.
It
starts
affecting
the
cps
path
of
whatever
is
already
being
serviced
right.
So
I
think
what
the
bi-directional
stream
affords
us
is.
We
can
actually
stream
it
in
a
way
so
that
we
can
more
efficiently
populate
the
other
side.
So
there
is,
there
could
be
in
the
stream.
B
You
could
go
through
some
portion
of
the.
We
are
following
the
same
perfect
sync
mechanism
right,
so
we
are
marked
in
the
this
thing.
We
are
taking
a
snapshot
in
this
mechanism.
We
take
a
snapshot
of
what
is
in
the
current
flow
table
and
we
mark
everything
else
that
knew
all
the
new
connections
that
come
up.
They
are
marked
as
some
color
right,
so
we
sync
everything
like
the
pin
the
perfect
sync
mechanism.
We
sync
everything
in
that
bulk.
B
So
while
this
is
happening,
we
want
to
sync
this
in
the
most
efficient
way,
because
it's
a
scale
thing,
so
we
stream
all
the
flow
sync
messages.
So
what
we
would
require,
what
the
dpu
can,
I
think,
each
implementation
on
each
side.
The
dpu
might
have
efficient
ways
of
selecting
the
flows
that
it
needs
to
sync,
for
example,
it
could
be,
we
could
have
a
slide.
B
B
So
I
think
the
key
thing
is
it's
not
like.
There
is
a
list
of
all
the
flows
and
we
copy
over
all
the
flows
in
one
go
to
the
other
side.
Rather,
it
is
more
of
a
stream
where
the
tpu
can
choose
which,
which
set
of
flows
to
pull
from
the
primary
so
that
it
can
be
more
efficient
when
we
sync
up
from
that.
D
B
B
Okay,
okay
thanks.
So
essentially,
I
think
one
thing
one
thing
to
note
here
is
during
the
bulk
sync:
we
are
not
actually
carrying
any
user
traffic
itself
right.
So
this
is
our
own
format
that
we
have
below.
I
think
that's
there
in
the
defined
messages
below.
So
this
is
our
own
format
that
we
are
sending.
B
B
E
Part,
I
think
I
get
it,
but
I
I
don't
quite
understand
the
comments
about
the
boxing.
I
understand
the
back
pressure
scenes
right,
but
I
don't
understand,
like
the
selecting
part
right,
so
you
know
what
what
is
the
criteria
you're,
selecting
the
flows
to
sync,
I
think
you
know
in
the
initial
boxing
isn't
that
on
one
side,
it's
you
know
it
has
all
the
data
on
the
other
side,
it
doesn't
have
the
you
know:
zero
zero
flows.
So
so
you,
you
could
just
stump
all
the
flows
from
one
side
to
the
other
side.
E
B
Even
the
walk
to
we,
we
have
multiple
of,
I
think,
I'm
I
mean
we
I'm
just
we're
taking
when
I
say
from
pennsylvania.
I
think
it
is
our
implementation,
but
we
expect
it
might
be
very
similar
in
other
implementations
too.
So
there
are
multiple
of
these
control
plane
threads
that
we
have
so
the
way
we
want
to
select
and
push
them
to
the
other
side.
Might
we
could
choose
from
the
other
side
so
this
this?
This
is
effectively
the
purple
line.
That
is
there
go
on
each
of
them.
B
It
could
be
we
want
to
for
one
thread.
We
want
to
get
n
number
of
flows
from
the
from
for
one
one
of
the
cps
threads
and
then
we
also
because
it's
all
the
buffers
are
also
limited.
So
from
one
thread
we
don't
want
to
block
any
of
the
threads
in
trying
to
populate
the
the
buffer
to
pull
push
to
the
other
side.
So
there's
some
back
pressure
there
too
right
on
how
much
we
can.
B
B
The
second
thing
is,
as
we
are
for
each
of
these
threads.
We
should
also
note
that
I
think
I
have
some
of
that.
We
noted
down
in
the
interaction
between
the
two
as
we
are
picking
from
these
flows.
There
is
also
the
same.
Floatable
is
being
acted
upon
by
current
activity
from
the
network
right,
so
there
could
be.
B
There
could
be
other
traffic
which
is
changing
the
state
of
the
flow
like
terminating
the
flow,
or
there
could
be
some
policy
changes
that
are
happening
where
we
are
resimulating
or
we
are
changing
the
flow
itself
right.
So
there
is
some
because
that
is
happening
on
the
same
thread
that
is
operating
on
the
bulk
sink
too.
So
there
could
be
some
locks
right
so
and
we
don't.
E
That's
a
sir,
that's
fine
right,
so
you
know
because
I
think
you
know,
because
I
because
you
know
I
I
haven't
seen
the
document
right
so
because
you
know
basically,
I
think
all
I
care
about
is
the
api
between
the
sonic
and
the
the
site
right.
So
you
know
as
long
as,
for
example,
you
know
I
think
in
your
sdk
you
may
have
shred
you
may
have
logs.
You
may
have
other
things
that
you
want
to.
You
know
decide
which
flow
you
want
to
sing.
First,
you
know
those
kind
of
thing.
E
B
Yeah
right,
so,
I
think
the
way
sonic
controls
to
say
that
start,
the
bulk
sync
now
pull
the
flows
and
push
them
and
then
the
messages
themselves
are
all
the
messages
are
defined
messages
for
the
flows
themselves.
So
on
this
stream,
the
only
thing
the
dpu
controls
is:
how
do
we
push
these
messages,
and
I
mean
these
flowsync
these
flows
in
what
order
that
is,
but
it
does,
I
think
it
is
controlled
by
sonic.
I
think
when
we
come
to
the
messages,
maybe
that
will
be
a
little
more
clear.
B
C
Yeah,
I
I
I
just
wanted
to
put
one
thing
and
make
sure
people
understand.
There
are
two
things
going
on.
At
the
same
time,
you
are
doing
a
bulk
sync
and
you
are
also
doing
your
regular
data
paths,
sync
where
new
connections
come
in
those
are
being
sent
over
in
parallel
and
they
are
independent
and
that's
why
you
can
take
a
snapshot
and
just
work
on
that.
But
the
new
connections
actually
just
behave
as
normal.
They
go
through
the.
This
is
what
he's
calling
the
dp
sync
channel.
A
That
was
my
question:
is
there
any
race
condition
that
might
happen
while
we
are
doing
the
control
plane
sink
and
the
flows
are
cued
up
there
and
the
dp
sync
channel
has
the
latest
and
it's
already
synced
that
and
then
you
know
once
the
bulk
sync
goes
through?
Will
it
be
you
know,
do
we
have
a
means
to
avoid
that.
B
Yes,
so
there
is
so
this
is
part
of
the
yeah.
There
is
you're
right
so
why
there
could?
There
are
two
two
conditions
here
right,
so
one
is.
While
we
have
a
snapshot,
there
might
be
a
new
connection
that
is
created
right,
so
that
is
the
easier
one
right.
So
we
know
that
we
look
at
this
color
and
then
we
say
that
okay,
it's
a
new
connection
and
it
is
not
there
in
the
snapshot,
so
we
just
sync
it
across
to
the
other
side.
B
Right
I
mean
the
dp
sync
carries
the
flow.
We
know
that
the
control
plane
sink
is
not
going
to
come
and
interact
with
that
flow
at
all,
because
that
is
a
completely
new
flow
now
yeah.
So
the
second
one,
the
second
condition
my
the
second.
This
thing
is
scenario:
is
we
have
a
flow
which
is
there
in
the
in
the
snapshot?
It
was
there.
No,
it
has
the
same
color
which
we
are
going
to
think
via
the
cp
sync
channel.
B
B
Where
is
it
if
you
have
already
seen
the
flow
across
right?
It
is
okay
for
dpsing
to
go
ahead
and
right
send
an
incremental
thing,
but
if
that
flow
has
not
been
synced
across
right,
then
you
can
hold
off
on
syncing
on
the
dp
sync,
and
the
control
plane
would
actually
sink
over
the
state
when
it
actually
pushes
the
state
across
right.
That.
B
A
B
Yeah,
so
I
think
that
might
be,
I
think,
in
the
in
the
what
would
need
in
the
implementation
what
would
need
to
happen.
I
think
these
are
cases
that
are
there
below
what
we
need
to
take
care
of
effectively
what,
in
the
it's,
a
very
implementation,
specific
thing,
but
we
actually
go
mark
in
the
flow.
B
E
E
A
B
A
D
B
C
A
Like,
for
example,
when
we
have
all
the
flows
included
in
the
snapshot
for
bulk
sync,
at
the
same
time,
there
is
change
in
the
state
of
the
flow,
that's
in
the
snapshot,
but
not
yet
sent
or
processed
all
right,
not
sent
suppose
if
there's
a
way
to
notify
the
dpu
that
the
sorry
the
dpsync
channel
to
hold
off
on
that
one,
then,
then
we
are
good
right.
Yeah.
C
C
B
A
Hey
sanjay
one
question
like
so
in
terms
of
partitioning
of
work
right
like
so,
I
expect
there
will
be
like
a
sonic
module,
which
is
the
one
actually
streaming,
this
connections
that
the
flow
state
and
it
goes
via
the
psi
apis
to
stream
the
flows
from
the
dpu
and
streams
it
across
to
the
paired
dpu
right.
Like
so
question
is
like.
A
B
B
Then
then
we
have
the
data
path,
synchronization
itself.
I
think
in
this
proposal
we
follow
the
inline
replication.
That
bulky
explained
in
the
last
meeting
in
the
couple
of
meetings
back
so
in
this,
I
think
we
think
effectively.
We,
the
two
dpos,
are
treated
as
one
dpu.
I
mean
as
one
logical
unit
right
and
whenever
there
is
a
flow
inserted,
we
make
sure
that
the
other,
the
pr
also
inserts
the
flow
before
it
gets
forwarded
to
the
other
side
right.
B
Right
and
so
when
we
are
syncing
it
to
the
other
side,
the
primary
dpu
is
the
is
the
one
that
I'll
change
something
the
dsc
is
dpu.
I
think
dse
is
our
transcendental
terminology,
so
the
the
primary
dpu
kind
of
evaluates
all
the
policies
and-
and
then
you
know
inserts
the
flow
in
the
secondary
and
whatever
was
the
policy
results
from
the
primary
is
honored
on
the
secondary.
I
think
the
flow
insert
happens
with
exactly
the
same.
There's
no
difference
between
the
two.
B
So
the
reason
I
think
this
is
critical
is
because
we
can
never
guarantee
that
the
primary
and
the
dsc
will
be
at
exactly
the
same
configuration
level
at
any
given
point
in
time.
There
might
be
differences
between
the
two,
where
the
controller
has
put
some
config
new
config
to
one
of
the
dps,
but
not
the
other,
yet
right
or
we
haven't
applied
on
both
the
debuts
at
exactly
the
same
time.
B
So
it's
a
critical
that
we
have
some
source
of
truth
and
the
source
of
truth
for
policy
is
the
whatever
is
the
primary
gpu
in
this
case
and
then
on
switch
over
there
is
a
reconciliation
or
the
flow
recimination
that
we've
been
talking
about.
That
kind
of
updates
to
whatever
is
the
config
level
on
on
the
secondary,
it
kind
of
updates
the
flows,
and
it
gets
it
back
to
that
level
on
the
secondary,
but
during
the
sync
it
is
always
the
policy
results
from
the
primary
dpu
that
that
stays
another
takes.
B
E
B
E
E
E
A
B
B
B
A
C
What
it's
all
it's
all
the
layers
you
could
have
a
change
re-simulation
is
to
fix
all
the
layers
you,
you
can
come
down
and
change
the
change,
the
transformation
of
of
a
policy.
You
can
change
the
rules,
they're,
not
a
sale,
they're
called
rules.
You
can
change
any
of
the
rules
right
in
any
of
the
transformations.
C
So
so
it's
all
of
it,
but
that's
re-simulation,
can
happen
after
the
fact
I
mean
it
can
just
be
initiated
and
it
can
happen
per
normal
re-simulation
rules
it.
It
has
nothing
to
do
with
aj.
Really
it's
just
something
that
after
you
do
an
aha,
it's
obviously
a
good
thing
to
do.
Re-Simulation,
but
it's
independent
of
the
aha.
E
So
basically,
what
I'm
hearing
is
that
you
know
before
you.
You
first
do
the
sync
right.
So
then
you
know
before
you
do
the
switch
over.
Actually
the
control
plane
is
doing
the
switch
over.
You
know
right
before
that
you
switch
to
the
second
dsc
then
at
that
moment
the
second
dsa
is
getting
all
the
up-to-date
policy
and
do
the
re-simulation
on
the
second
dlc
right.
So
that's
what
you're
talking
about.
C
E
D
D
D
C
C
May
be
out
of
sync,
because
software
can't
update
them
both
simultaneously
no
multicast
here,
so
they
could
be
slightly
out
of
sync
at
any
any
period
of
time
and
that's
why
we
do
re-simulations.
But
you
don't
need
to
do
it
as
as
part
of
the
aj.
You
don't
need
to
do.
It's
just
highly
advisable
to
do
it
after
aj
is
done
or
before
you
do
the
actual
switchover,
but
it's
independent.
C
D
So
then,
the
question
here
is
that
you
know
when
the
policy
changes
happen.
They
are
reflected
on
both
the
dpus
and
so
then.
The
question
here
is
that
do
both
dpus
run
their
flow
resimulation
independently
or
is
the
primary
runs?
The
resimulation
of
the
changes
are
actually
synced
across
to
the
secondary
afterwards.
How
does
actually
that
work.
C
The
thing
is
that
the
it's
independent,
because
the
gpus
know
that
they've
received
new
policies,
so
you
could
be
doing
a
bulk,
sync
and,
and
the
data
pass
sync
and
the
dpu
is
still
getting
policy
updates
from
sdn
somewhere
because
they're
asynchronous,
they
don't
necessarily
know
what's
going
on,
and
so
they
can
decide
to
do
a
re-simulation
at
any
time.
If
they've
received.
A
A
So
that
means
there
will
be
a
notification
right
from
the
newly
active
back
to
the
controller
indicator
is
ready
for
re-simulation,
not
notification,
see
after
switch
over
the
unplanned
switch
over
after
that.
The
controller
basically
sees
that
there
is
a
switch
over
event
and
then
it
will
invoke
the
apa
to
start
the
re-simulation.
A
B
A
Yeah,
the
dpo
once
it
comes
from
standby,
to
active
once
it's
fin,
it's
done
with
some
init
tasks.
It
has
to
inform
the
controller
that
it's
ready
or
it
can.
You
know
once
it
if
the
rx
channel
is
already
open
and
it
can
get
the
command
from
the
controller,
then
it
can
cue
it
and
do
the
resimulation
also
that's
true.
It's
it
probably
doesn't
need
the
you
know
that
the
dpo
is
ready
signal
to
the
controller.
Then.
A
B
Yeah,
so
I
think
from
a
network
perspective,
the
traffic
is
still,
I
mean
on
switch
over
without
any
of
the
control
plane,
whatever
the
messages
that
we
are
talking
about,
without
any
intervention
there,
the
network
will
actually
start
forwarding
traffic
to
the
secondary,
and
we
will
continue
to
forward
in
for
any
traffic
for
any
of
the
flows
according
to
whatever
the
state
was
synced
right.
Now
the
flurry
simulation
kind
of
updates
again
yeah.
A
C
E
E
Is
that
maybe
you
know
it
would
be,
you
know
better
to
get
to
mark
down
so
that
we
can
easier
comment
on
the
and
document,
but
I
might
find
you
know
if
you,
you
know,
get
the
pdf
out
first
and
then
I
think
you
know
yeah.
So
there
are
some
details
that
we
can
look
and
people
can
communicate
and
look
and
then
and
then
read
more.