►
From YouTube: DASH HA High Availability Working Group 20220419
Description
April 19, 2022 HA WG Call
A
Okay,
I
see
it's
recording
so
hi
everyone
yeah.
So
as
christina
mentioned,
our
goal
here
is
to
have
a
series
of
meetings
to
discuss
different
topics
regarding
the
high
availability
in
dash
and
eventually
come
up
with
some
standard
defined
protocol,
so
that
the
dash
appliances
dash
cards
will
be
able
to
communicate
their
state
to
one
another.
A
So
that's
why
we're
all
here
so
a
little
bit
more
about,
but
why
we
need
this
is,
as
you
can
see,
what
we
are
changing
with
dash
is
a
path
with
which
the
packet
is
traveling
through
the
network.
So
if
we
are
this
aggregating
our
state
away
from
nodes
that
are
running
vms
to
dedicated
appliances,
now
it
means
that
our
path
is
changed
slightly.
It's
not
just
going
from
one
node
to
another.
It
will
have
additional
hops,
which
are
our
dash
devices
and
it
introduces
a
new.
A
New
points
of
failure,
which
are
at
the
moment,
don't
have
any
redundancy,
so
we
of
course,
have
redundancy
at
t1
t2.
Of
course,
we
we
can
have
in
t0
as
well
as,
for
example,
microsoft
is
doing
in
sonic
with
dual
tor,
but
when
we
are
introducing
our
dash
devices,
this
is.
We
are
running
again
into
the
issue
of
what
happens
when
one
of
them
fails
and
how
we
can
minimize
the
impact
of
such
failure.
A
So
this
will
be
if
I
will
try
to
keep
this
these
series
of
meetings
as
interactive
as
possible,
because
the
goal
here
is
not
to
to
come
to
you
and
to
present
something
that
I
think
how
it
is
supposed
to
look
like.
But
I
want
to
do
it
in
a
way
that
everyone
provides
inputs
on
different
topics
and
at
the
end
of
these
meetings,
we
will
be
able
to
converge
to
to
a
protocol.
A
A
There
are
some
requirements
already
available
in
the
dash
repository
documentation
that
I
have
copied
in
here
and
also
I
would
want
to
get
more
input
on
every
of
these
topics
also
to
talk
about
end-to-end
flows.
How
do
we
see
this
working
in
in
the
real
network?
How
all
of
the
how
this,
how
all
of
the
scenarios
will
evolve
the
control
plane
interactions?
Of
course,
what
is
the
data?
What
are
the
inputs
from
control
plane?
A
Yes,
so
this
is.
This
is
how
I
see
these
meetings
moving
forward.
If
you,
by
the
way,
have
any
topics
that
you
think
should
be
included
into
the
future
meetings,
you
can
you
can.
Let
me
know
right
now.
I
will
keep
this
presentation
in
edit
mode.
We
can,
we
can
add
everything
that
we
think
is
worth
going
over
or
you
can
just
after
the
meeting
just.
I
will
of
course
send
this
presentation
you
can
you
can
just
reply
to
me
with
stuff
that
you
think
should
be
added
as
well
yeah.
B
B
Maybe
a
few
other
goals
we
could
consider
one
is:
do
we
want
a
behavioral
model
or
add
this
to
the
behavior
model,
because
this
might
be
modelable
partly
in
p4
and
partly
in
you
know,
c
or
something
like
that
and
having
a
model
of
it
might
really
help
might
even
provide
some
implementation
start
not
just
a
model.
Even
I
would
say
a
simulation.
We
could
have
a
simulation
of
two
dpus
interacting
sharing
their
flow
state,
and
so
that's
one
idea
another
is.
A
A
Oh
yeah,
of
course,
smart,
switch
and
also
other
use
cases.
I
think
it
should
be
extendable.
We
haven't
talked
about
in
dash,
probably
because
we
haven't
finished
with
v-net
yet,
but
there
is
slb,
there
is
other
stuff
and
it
should
be
extendable
to
those
as
well
yeah.
So
I
think
this
is
also
like
smart
switch.
I
think
this
falls
under
intent,
flows
as
well:
smart,
switch,
slb,
etc.
B
I
I
I
wrote,
I
made
a
couple
of
diagrams
new
ones
in
a
pull
request
that
I
put
in
last
week
and
I
was
hoping
for
microsoft
to
be
able
to
review
them
at
some
point
and
see
if,
if
they
make
sense,
because
do
you
want
to
review
them
today,
yeah
yeah,
we
could
look
at
them
at
the
right
time.
I'd
be
happy
to
share
my
screen.
B
C
In
the
dpu
standpoint,
the
high
availability
still
has
to
work
within
the
device
itself
right.
That's
that's
one
thing
and
then
flow
level
that
is
across
dpos
how
we
synchro
synchronize
the
flows
and
how
we,
you
know
if
one
of
the
devices
go
down,
how
we
switch
over.
All
of
that
is
just
is
another
flow
level,
high
availability
within
the
device
itself
like,
for
example,
if
we
have
you
know,
if
we
have
control
plane,
we
have
arc
agent.
All
of
those.
A
C
A
B
A
B
C
A
Yeah,
so
this
this
is
intra
delay,
so
we're
talking
about
replicating
state
of
one
device
into
another
device.
This
is
exactly
our
goal,
but
we're
focus
we're
focusing
on
the
state
of
the
data
plane
not
what's
going
on
in
the
control
plane
assumption
for
this
working
group,
at
least
for
now
is
that
failure
happens.
Sorry,
no
failure
happens
and
the
control
plane
or
almost
no
failure
happens
to
the
extent
that
we
can
allow
that.
So
we
want
to
replicate
data
plane
on
the
control
plane.
C
C
A
A
Yeah,
so
if
you
don't
have
anything
else
to
add,
I
will
I
will
be
also.
As
I
said,
this
is
kind
of
the
presentation
that
will
be
updated
on
the
fly.
I
will
keep
track.
I
will
have
this
as
the
meeting
notes
for
every
of
our
session,
with
the
dates
attendees
and
so
on,
so
just
for
you
to
know
so
so
that
you
can
pick
up
from
any
place
if
you
in
case,
if
you
missed
a
meeting
or
joined
later,
or
something
like
that
yeah.
So,
let's
jump
into
the
requirements.
A
A
For
now
I
have
only
one
item
that
we
briefly
touched
upon,
but
let's
go
over
what
was
already
in
the
dash
documents
and
try
to
decipher
this
and
understand
how
it
affects
a
standard
or
protocol
itself.
So
first
three
are
kind
of
from
the
same
basket.
They
are
talking
about
the
how
the
failover
should
happen.
A
I
hope
you
agree
with
me
that
we
want
to
our
main
goal
in
here
is
to
replicate
all
of
the
connections
across
two
devices.
So
assuming
we
have
active
and
we
have
a
standby
device,
we
should
be
constantly
keeping
the
hot
copy
of
of
an
active
device
in
our
standby
with
all
of
the
connection
tracking
present
already.
So
it
can
take
over
at
any
point
of
time
and.
A
A
E
Can
okay,
so
I'm
basically
coordinating
from
microsoft's
site,
so
I
can
tell
you
guys
that
currently,
the
first
version
is
like
active
standby.
However
long-term
vision
and
if
you
are
actually
going
towards
it,
we
actually
would
like
to
have
active
active,
mostly
because
the
active
standby
right
now
we
are
kind
of
solving
with
asm
prepaints,
and
there
is
actually
not
enough
t-com
space
to
kind
of
advertise
and
carry
over
over
different
layers
or
tours
or
the
sn
printer
pre-pencil
will
be
going
towards
active,
active,
so
preferable.
Socials
should
support
active,
active
right
now.
E
So
I
know
that,
from
the
from
the
source
side
right,
the
connection
will
always
always
go
to
specific
device
right
so
for
for
a
specific,
like
five
tuple
right-
and
this
is
also
one
of
the
reason
why
we
are
switching
most
of
the
connection
from
nvgre
to
vxlan-
and
we
are
of
doing
this
because
there
is
just
more
intro
in
the
packets
and
tours
can
actually
correctly
hash
it,
because
if
there
was
nvgr
they
were
they
were.
Basically,
there
was
not
enough
entropy
in
the
outer
header
to
actually
do
this
so
yeah.
E
You
guys
can
assume
that,
for
example,
for
specific
five
tuple,
the
connection
will
always
the
tools
which
will
basically
should
prefer
hashing
to
one
specific
stuff
right.
But,
as
I
mentioned
like,
this
is
active
active
right.
So
when
the
connection
gets
established,
then
the
flow
should
be
replicated
to
the
to
the
other
one
right
and
and
the
following
packets
can
can
even
reach
the
other
ones
right.
A
E
E
And
then,
and
then
one
additional
stuff
when
you
are
thinking
from
the
standard
perspective
right,
I
was
talking
with
the
slbs
of
social,
advancing
team
on
my
site
right
and
even
right
now,
even
though
right
now
we
are
starting
from
which
will
have
a
two
devices
which
will
be
paired
with
each
other
right.
We
have
data
from
the
slb
team
which,
which
they
mentioned,
that
most
likely
to
avoid
some
of
the
critical
failures
that
they
hid
in
the
past.
E
At
some
point,
you
may
need
to
expand
it
into
potentially
airing
of
three
devices
they'll
be
communicating.
They
basically
mentioned
that
to
maybe
very
little
to
cover
some
of
the
scenarios,
but
right
now
we
are
basically
starting
with
two,
so
we
should
design
for
two,
but
but
the
design
should
keep
in
mind
that
potentially
in
the
future
we
may
want
to
be
able
to.
If
once
we
have
build
sufficient
capacity
or
purchase
sufficient
capacity
and
place
it
potentially
is
spreading
to
ring
of
three.
Maybe
in
some
configurations.
E
Yes,
but
this
is
this-
is
the
conversation
that's
happening
on
our
site.
This
was
basically
feedback
when
we
had
a
review
of
the
aha
at
microsoft
right,
there
was
the
feedback
from
the
lead
of
the
software
balancing
team.
That
said
that
they
also
started
from
two
instances
and
then
at
some
point
there
was
some
live
sites
incident
and
they
had
to
basically
scale
out
to
minimum
three
instances
for
them
to
handle
some
stuff,
and
I
think
like
if
we
start
from
two.
E
D
Okay,
just
one
more
question
on
the
same
topic
so
and
that
may
might
we
might
want
to
capture
it
as
a
requirement.
So
let's
say
the
connection
is
learned
on
one
of
the
active
and
then
it
gets
replicated
right
on
the
other
active
or
the
active
state
is
maintained
on
a
where
the,
where
the
connection
is
learned.
D
D
E
So
from
the
point
of
view
of
the
flow
table
right
in
order
for
them
to
successfully
fail
over,
they
will
need
to
maintain
exact
copy,
so
100
100
right
from
the
point
of
view
of
actual
processing
of
the
connection
right.
One
connection
will
most
of
the
time
unless
there
is
a
failover
or
the
switch
or
whatever
right
will
end
up
always
on
the
same
device
right.
So
from
the
point
of
the
cps
right.
This
doesn't
impact.
This
doesn't
increase
cps
by
two
right.
E
It's
mostly
allow
us
to
basically
spread
the
the
load,
because,
basically,
some
of
the
connection
lines
on
the
first
active
device.
Some
of
the
connection
will
land
on
the
other
active
device
right,
but
from
the
from
the
load
perspective
right,
but
from
the
point
of
view
of
the
flow
stage,
the
flow
state
will
need
to
be
duplicated
in
order
to
support
the
failover.
D
Got
it
got
it
so,
basically,
your
requirement
is
that
the
flow
state
for
all
the
connections
need
to
be
replicated
on
all
the
active
active
nodes,
whether
it's
a
two
device
or
three
device
configuration
and
then
and
then
the
the
processing
may
be
load
balanced
across
these
active
active.
Yes
right,
okay,.
E
E
E
E
D
E
D
D
E
E
Well,
so
so
in
case,
so
because
the
flows
are
getting
copied
right
so
once
the
flow
gets
established
and
what
the
specific
decision
to
use
the
specific
part
right
is
set
up
right,
this
decision
will
you
guys
I
mean
that
the
switches
will
propagate
the
decision
right.
So
even
if
the
return
will
land
on
a
different
one
right,
then
definitely
be
asynchronous
from
the
point
of
view
right.
However,
the
flow
will
be
there
so
we'll
be
able
to
basically
provide,
like
a
reverse
transposition,
to
deliver
the
packet
right.
E
I
don't
believe
it's
a
requirement
to
kind
of
do
to
hope
model
right,
preferably
not
if
we
can
avoid
it
right,
because
this
will
reduce
gps
right
at
the
same
point,
the
standard
that
you
are
discussing
is
is
not
is,
is
basically
not
scenario
with
the
with
the
actual
dynamic
ports
right.
We
haven't
discussed
slb
yet
so
I'm
not
quite
sure
if
we
should
park
this
decision
for
later
we'll
be
discussing
not
balancing
this
load.
Balancing
is
a
entire
set
of
forms,
regards
to
dynamic
portal
location
ability
for
the
customer
to
kind
of
control.
E
Exactly
so
so
that's
explicitly
one
of
the
main
reasons
why
we
put
the
nut
out
of
the
equation
for
now,
and
also
most
of
the
customers
who
are
actually
in
the
need
of
the
high
cps.
They
usually
have
some
firewall
appliances
that
have
dedicated,
for
example,
ip
address
and
all
the
traffic
tools
to
these
iprs
already,
for
example,
this
firewall
appliance
and
this
kind
of
stuff
right.
They
not
many
customers
from
that.
They're
using
nvas
are
using
this
kind
of
dynamic
portal
location.
They
usually
assign
the
actual
entire
vip
to
the
appliance.
F
E
Yeah,
so
I
would
say
the
state:
definitely
we
should
we
need
to
basically
because
like
when
the
packet
goes
out
right
for
the
first
time.
If
you
are
talking
about
the
load
balancing
right,
then
the
some
poor
gets
allocated
right,
but
even
though
we
didn't
even
want
to
even
try
talking
about
load
balancing
right
now,
but
sample
gets
located
and
this
allocation
for
the
specific
flow,
the
specific
port
that
the
traffic
will
be
snapped
to
right
needs
to
be
replicated
to
the
to
the
other
device
right.
E
So
when
the
packet
comes
back,
which
may
land
on
on,
of
course,
like
different
device
right,
we'll
know
how
to
do
this.
Reverse
transposition,
this
kind
of
stuff
right,
but
the
idea
is
no,
I
mean
you
potentially
want
to
bounce
the
first
packet,
a
kind
of
like
multi-hope
scenario.
You
know
in
a
way,
for
example,
when
the
connection
established,
for
example,
sin
sin
is
going
right.
We
can
potentially
do
the
same
thing
that
right
now
the
balancing
team
is
doing.
They
are
basically
bouncing
the
packet
across
the
ring,
so
usually
for
the
scene.
E
There,
for
example,
the
packet
lens
on
the
first
device.
Then
bouncing
this
to
the
second
device
they
bust,
the
third
device.
They
are
passing
the
packet
back
to
the
first
device
again
and
then
only
they
they
put
the
packet
back
to
the
to
the
network,
but
all
the
remaining
packets
they
never
bounce
across
all
the
devices
right,
because
this
will
greatly
reduce
the
capacity
of
the
network
and
devices
if
they
want
to
every
single
packet
bounce,
because
there
is
no
reason
to
the
state
doesn't
change
right.
E
F
There's
a
slight
difference
between
what
you're
saying
in
there
in
the
slb
case,
one
of
them
is
active
and
the
other
two
are
keeping
the
state.
You
are
kind
of
getting
an
assurance
that
all
packets
of
the
session
forward
and
reverse
will
end
up
at
the
same
slb.
In
this
particular
case
you
don't
have.
I
don't
believe
this
will
be.
F
F
E
Yeah,
so
from
the
from
the
point
of
view
of
like
a
sin,
as
I
mentioned,
like
sin
needs
to
be,
and
in
initial
handshake
needs
to
be
basically
most
likely
routed
through
all
the
devices
and
the
same
with
finn
right,
because
the
packet
also
needs
to
like
be
kind
of
terminated
to
all
the
devices
right.
So
it's
kind
of
similar,
also
not
only
for
load
balancing,
but
also
for
normal
traffic,
that
the
kind
of
the
pin
was
like
also
like
way
to
communicate
to
all
the
devices
that
the
state
actually
got
removed
right.
E
E
E
Also,
the
other
device
needs
to
be
informed
right.
So
so
so
answering
your
question
nirajan,
I
believe
again,
beginning
at
the
end
of
the
connection.
Definitely
right
from
the
middle
of
the
connection.
The
package
is
flowing,
transferring
data
right
then
I
don't
believe
we
need
to
impose
any
of
those
kind
of
requirements.
What
do
you.
E
E
F
E
E
F
A
E
A
Right,
yeah
so
metadata,
of
course,
but
if
we
are
defining
this
as
a
metadata
or
let's
say
just
notifying
about
the
state
change,
then
yeah.
But
I
have
a
problem
with
saying
that
we
are
bouncing
the
packets
themselves,
because
this
means
additional
logic
in
the
dpu
that
will
ensure
that
only
one
of
them
will
eventually
forward
the
packet
back
to
back
to
tour.
E
E
Because
if
we
are
just
bouncing
metadata
right,
the
thing
is
like
you
cannot
positively
acknowledge
the
connection
was
established
and
forward
this
kind
of
synonym
outside
till
you
actually
replicate
the
flow
right,
because
then,
then
you
are
breaking
the
customer
guarantee
that
the
flow
was
already
established.
So
there
was
full
exchange
on
since
in
arc
right
and
then
one
device
dies
and
then
this
flow
dies,
so
customer
connection
dies
right.
So
we
are
breaking
this
guarantee.
So
in
this
case
we
can
only
forward
kind
of
the
full
sin
right
to
the
customer
right.
E
E
Right
and
in
order
to
kind
of
positively
acknowledge
this
right,
you
will
need
to
somehow
wait
for
this
acknowledgement,
which
means
that
if
you're
only
bouncing
metadata
potential
is
okay,
but
then
you
want
to
kill
the
packet
and
considering
that
it's
like
high
cp
high
cps
traffic,
this
kind
of
stuff.
The
question
is:
can
you
actually
afford
queueing
the
packets
as
you're
bouncing
metadata
and
waiting
for
the
metadata
acknowledgement?
E
D
D
A
For
the
given
destination
ip
that
for
that,
iep
packet
is
supposed
to
be
mapped
to
some
certain
public
ip
and
then,
if
your
resulting
packet
is
the
vxlan
with
the
public
ip
of
that
ca.
However,
when
we
are
talking
about
bouncing
packet,
how
do
we
bounce
it?
What
in
that
case,
the
pa
should
be
epa
of
our
dpu
number
two
or
our
standby
dpu?
So
we.
E
D
D
Is
yeah
local
end
cap
can
be
done,
but
but
I
think
the
main
sorry
marion
thing,
which
is
not
clear
to
me
what
you're
saying
is:
okay,
let's
take
a
specific
example:
a
flow
got
a
fin
got
learned
on
a
one
dpu,
but
subsequent
packets,
the
intermediate
packets
are
going
on
a
dpu,
too
forwarding
is
happening
and
sen
appears
on
dp2.
Now,
ideally,
we
want
to
bind
the
box.
D
A
Sorry,
I
I
disagree
with
that.
With
this
premise
from
the
beginning,
we
cannot
switch
back
and
forth
from
dp1
to
dp2.
We
may
have
only
one
failover
before
before
that
point
of
time
everything
was
going
to
dp1
after
it's
going
to
depute
2..
How
can
we
have
unless
I
don't
understand
something?
How
can
we
have
some
packets
going
to
dp1
some
of
them
going
to
the
q2
for
the
same.
E
So
so
that
may
happen
in
case
there
is
a
thor
failure
right
or
the
link.
Failure
to
some
specific
tour
and
packet
on
the
physical
network
gets
redirected
to
different
tour,
which
potentially
may
do
different
hashing
of
the
packet
at
the
end
because,
like
at
the
end,
those
devices
are
going
to
the
tours.
E
A
E
F
F
F
E
Are
those
are
physical
network
devices
like,
for
example,
the
edge
device
which
are
getting
traffic
from
the
internet?
Like
reply
right?
Those
are
physical
network
devices,
they
will
do
their
own
hashtag,
we
don't
own
any
hashing
algorithms
there
and
it's
going
to
stop
right
and
it
will
just
bounce
the
packet
somewhere
wherever
the
vp
is
advertised.
E
So
indeed,
indeed,
the
asynchronous
asymmetrical,
yes
and
most
likely
from
the
point
of
view
of
that,
because,
like
in
case
of
v-net,
we
usually
control
both
source
and
destination
in
case
of
internet
traffic,
the
destination
is,
for
example,
internet.
So
this
may
happen
right.
This
is
this
is
when
you
involve
load
balancing
traffic,
and
this.
A
Okay-
okay,
yes,
so
there
was
a
comment
hold
on
from
chris
that
we
should
make
a
list
of
use
cases.
I
agree
this
is
this:
is
the
next
thing
that
we
will?
We
will
talk
about
so
probably
starting
next
time.
We
will
try
to
summarize
all
of
these
cases
that
we
have
asymmetrical
flows,
because
this
is.
This
is
really
something
new
to
me.
I
was
focusing
mostly
on
v-net
to
v-net,
where
flows
are
symmetrical
and
landing
on
the
same
dpu.
D
Yeah,
I
think
we
should
capture
it,
but
I
don't
see
a
problem
if
the
flow
state
is
replicated
right
across
all
active
nodes,
then
when
then,
eventually,
where
the
failover
results
in
flow
landing
right,
it
still
will
be
forwarded.
The
only
thing
which
I
am
little
bit
not
clear,
michael,
you
said
that
if
there
is
a
fin
packet
right
and
then
fin
packet
should
be
bounced
back
to
the
node
where
the
syn
packet
came
in
right,
that's
the
requirement
you
you
mentioned.
Is
that
correct.
D
E
D
D
C
From
the
forwarding
point
of
view,
the
active
active
pair
can
continue
to
forward
from
each
side,
but
there
is
this
aspect
of
control
messages
that
need
to
be
synced
and
we
invariably
have
all
these
intermediate
hops,
where
the
towers
or
other
switches
or
links
could
fail,
etc,
and
the
assumption
will
become
asymmetric
right.
So
the
control
messages
sync
has
to
be
handled
as
a
separate
task,
while
the
forwarding
definitely
can
be
done
active
active
across
both
the
devices
in
each
part.
C
They
need
to
be
synced
that
defines
the
state
of
the
flow
right
that
has
to
be
sort
of
synchronized
between
the
two
pairs
right.
Even
if
they're
in
active,
active
or
active
standby,
the
forwarding
side
of
things
will
fall
in
place
and
both
can
forward,
but
the
control
messages
have
to
be
relayed
like
if
one
of
the
two
devices
right
are
acting
in
the
active
active
mode
for
certain
set
of
flows.
C
The
forwarding
part,
I
think
we
understand
that
both
need
to
be
done
in
one
way
or
another,
either
it's
active,
active
or
active
standby,
but
the
control
messages.
If
one
receives
some
control
message
that
affects
the
state
of
a
given
flow
that
both
the
devices
are
managing.
It
is
required
to
sort
of
forward
that
control
message
to
the
other
side,
so
both
are
in
sync,
so
I
I
just
felt
that
the
control
messages
need
to
be
synchronized.
G
G
You
know
vm
equal
into
a
host
like
migration,
as
I
could
see
it,
but
we
migrate
when
we
migrate
a
flow.
The
state
of
the
flow
is
migrated
with
it
right
so
so
there
is
no
reason
to
kind
of
forward
any
sin,
packets
or
whatever,
to
get
the
state
aligned
or
anything
like
that,
and
there
was
one
more
comment
I
had
here.
The
window
is
two
seconds:
downtime.
G
E
Well
so
so
the
requirement
is
like
less
than
two
seconds
like
I'm,
I'm
all
for
for
basically
much
much
faster
right
for
that
plan,
but
the
unclan
basically
means
that
basically,
the
device
dies
and
somehow
we
maybe
discovered
this
too
late-
there's,
maybe
some
bgb
propagations
problem
and
this
kind
of
stuff
right.
So
the
recommends
to
second,
I
don't
want
to
impose
like
one
like
10
milliseconds
requirement,
like
you
guys
want.
I
can
definitely
tell
it
right,
but
but
but
right
now
the
requirement
is
like
two
seconds.
E
If
we
can
do,
of
course,
the
customer
wants
to
have
completely
not
noticeable
right,
but
it's
unplanned
fade
over,
which
means
the
device
files
right.
If
during
the
two
seconds
there
will
be
some
retransmits,
but
but
the
connection
doesn't
die
during
the
time
right.
That's
that
we
will
be
noticing.
Practice
is
right
now
kind
of
actionable
from
the
customer.
This
potentially
wants
some
rca
on
average.
The
99
is
much
much
faster
right,
but
that's
that's
kind
of
unplanned
failover.
E
The
platform
over
is
completely
zero.
It
must
be
zero
right.
So
in
a
way,
for
example,
if
we
need
to
service
one
device
like
in
a
way
update
field
murder-
and
there
is
no
way
to
do
this-
like
issu
updates
so
so
kind
of
like
there
is
no
way
to
fix
the
highway
as
the
highway
is
running.
But
there
is
some
big
big,
basically
maintenance,
that
we
need
to
actually
close
entire
highway
right
and
and
kind
of
like
redirect
traffic
the
other
way
right.
E
Then
this
will
be
handled
through
control
plane
from
the
point
of
view
that
control
plane
will
say:
hey
for
example,
drain
all
the
connections
like
stop
advertising
bgp,
wait
for
the
connection
to
drain
right
and
then,
for
example,
give
us
give
us
a
is
information
when
you
will
see
serial
connections
arriving
on
your
device
and
then
this
connection
will
be
training
right.
It
should
be
completely
zero
fa
downtime
for
the
plan
fade
over
right
and
then
you
service
device.
E
Then
after
we
service
the
device,
the
control
play
will
say:
okay,
you
can
pair
back
and
transition
all
the
states,
so
the
state
will
should
be
starting
replicating
in
the
meantime,
we'll
see.
Basically,
when
we
will
get
acknowledgement
that
the
the
state
it
was
fully
replicated
then
and
then
at
some
point
it
will
be
okay,
then
let's
start
advertising
the
vip
back
right.
So
we
can.
We
can
receive
the
packets
right
so
plan
failover
needs
to
be
fully
zero
downtime
because
we
can
actually
orchestrate
it
fully.
E
B
B
B
I
can
so
people
are
familiar
with
this
diagram,
but
from
the
spec,
and
it
doesn't
really
show
the
smart
switch
version
which
I'm
trying
to
infer
from
the
smart
switch
rfi.
So
I
thought
I
should
do
a
new
diagram.
Also
this
is,
we
don't
have
the
source
for
this
diagram.
No
one
can
bind
it,
it's
just
a
ping
and
we
want
to
build
an
edit
diagram.
So
I
read
through
it
with
draw.
I
o
so
now
it's
an
editable
svg
and
we
can
use
it
as
a
starting
point
for
other
diagrams.
B
I
didn't
show
the
third
appliance
over
here.
I
didn't
quite
understand
it,
but
after
this
discussion
I
understand
we
might
want
a
third
one
and
then
I
added
a
smart
tor
or
smart
switch
variation
where
the
dp
user
embedded
in
there.
So
this
is
just
a
starting
point.
Hopefully
it
can
aid
further
discussion
and
further,
you
know
specifications.
So
take
a
look
at
that.
Let
me
know
if
you
like
them,
we
can.
We
can
merge
it
into
the
repo
and
then
have
it
as
a
starting
point
for
other
diagrams.
B
E
Yeah
awesome
thanks
chris,
so
so
the
third
one
or
the
initial
diagram.
I
I
can
tell
you
that
it's
kind
of
like
a
backup,
so
we
were
thinking
to
have
kind
of
always
some
spur
capacity
with
some
percentage,
which
means
because
the
device
will
physically
die
right.
So
when
the
device
physically
dies,
one
device
dies,
but
the
connection
on
the
left
side
are
still
maintained
but,
for
example
like
if
there
is
condition
on
the
left
side.
This
card
is
kind
of
like
orphaned,
like
it's
a
single
one.
So
when
it
dies,
everything
dies.
So
we're.
E
E
C
E
A
E
I
can
definitely
spend
some
time
on
this,
but
I
think
it's
kind
of
like
in
the
agenda
we've
been
probably
not
more
than
15
minutes,
because,
theoretically,
it
is
kind
of
like
relatively.
I
think
one
diagram
kind
of
yeah
we'll
show
everything
right,
so
so
yeah
yeah.
So
we
can.
We
can
set
like
50
minutes
for
this
yeah.