►
From YouTube: DASH High Availability Working Group Oct 4 2022
Description
Discussion on MetaData policies/expectations
Proposals to define InterOp in the future
Future work suggested by Guohan: Community to work on CP and DP InterOp, and packet format
Need to get control channel defined
A
Thanks
for
coming
to
the
high
availability
meeting
for
October
4th
and
I'm
going
to
go
ahead
and
share
my
screen,
so
we
can
take
a
quick
look
at
this.
Is
the
pr
opened
by
Sanjay,
and
you
wanted
to
address
comments
so,
like
Marianne
said,
this
is
a
bigger
one
for
sure,
so
this
one
would
probably
need
to
be
looked
at
by
the
next
time
we
talk
next
week
and
what
did
you
notice
Marianne
just
that
it
was
larger
and
had
a
lot
of
stuff
in
there.
B
A
A
A
A
C
A
C
While
are
those
you
know,
policies
being
used,
whether
they
are
optional
or
not?
You
know
I
remember
you
know,
MD
mentioned
that
some
of
the
aqua
actually
is
a
requirement
and
to
be
encoded.
They
I
guess
there
were
some.
Some
questions
from
the
audience
is
why
those
are
required
can
came
to
explain
that.
A
D
C
E
C
D
Policy
policy
lookup
results,
it's
basically
the
the
actual
lookup
right
to
allow
the
flow
or
the
delay
the
flow
based
on
whatever
policies
like
V
A,
based
to
policies
that
are
configured
so
those
those
lookup
security.
Lookup
results
are
carried
in
the
metadata.
The
mapping
and
Route
lookup
results
the
rewrite
information
whatever
for
the
rewrite
for
the
source,
IP
desktop
source
for
this
port
vni
and
whatever
metering
that
has
been
chosen.
It's
also
carried
to
the
to
the
peer.
C
D
D
So
when
you
set
up
a
connection,
basically
we
we
want
to.
We
want
to
sync
the
connection
with
the
same
set
of
you,
know,
policy,
lookup
results
and
other
rewrites.
We
don't
want
to
go
and
basically
do
another
lookup
there
in
the
in
the
peer,
because
if
you
do
the
lookup,
it's
not
guaranteed
to
give
the
same
results
over
there
right.
So
that's.
C
D
No,
so
what
see
the
reconcile?
Okay
so
after
after
switchover,
basically
there
is
a
there
is
a
reconcile
event
that
is
pushed
from
the
controller
that
is
to
that
is
to
say
basically
from
now
on,
you
can
go,
you
can
go
and
reconcile,
because
this
particular
node
has
caught
up
to
the
configuration
level
as
what
it
was
in
the
previous
node.
D
But
basically
it's
not
like
the
I
mean
the
way.
What
we
do
is
it's
not
like
we
go.
We
go
and
do
reconciliation
of
all
the
Flows
at
that
time.
Right,
because
if
you
go
and
do
everything
and
it
fix
up
everything
at
that
time,
then
it
is
going
to
be
a
there
will
be
a
lot
of
descriptions
at
that
time.
So,
basically
the
reconcile
event
the
way
to
use
it
is
so
so
basically
say.
D
D
So
we
wait
for
the
reconciliation
event
when
the
reconciliation
even
comes
so
we.
So
at
that
point
of
time
we
check
the
config
level
of
the
connection
with
the
config
level.
What
is
there
in
the
local
node
if
it
is
already
in
version
one
level,
then
there
is
no
need
to
do
any
fix
up
for
that,
because
it's
already,
we
are
already
sync
it
at
that
level,
right
whatever
level,
because
we
carry
everything
as
part
of
the
metadata.
D
B
A
C
D
C
I,
don't
care
I,
yeah,
okay,
so
then
how
do
you
determine
the
version?
Then?
Because
you
know
how
do
you
know?
Okay?
So
when
I,
when
I
you
know
set
up
this
connection
I'm
using
you
know
the
policy
version,
you
know
100
and
the
next
one
I
said
about
using
policy
version.
You
know
101
and
you
can
keep
track
of
those
versions.
C
Yeah
I
mean
so
so
I'm
still
not
getting
okay.
So
let's
have
we
have.
We
have
a
concrete
example.
You
know,
for
example,
you
know
this
node
a
right,
so
you
know
there's
the
echo
policies
to
deny
okay.
So
you
know
when
we
Replay
that
the
scene
packet
on
the
you
know
on
the
and
the
standby
node,
maybe
at
that
point
time
the
virtually
saying,
okay,
you
know
that
version
this
is
this
should
be
allowed.
So
therefore,
you
know
on
the
primary
you
have
denied
the
on
the
backup.
C
You
have
you
have
a
lot.
Actually
you
know
for
the
deny
we
probably
didn't
set
up
the
floating
tree
right,
so
I
guess
I.
You
know,
then
what
what
so
I
guess,
I'm
trying
to
understand
you
know
do
I
have
a
concrete
case.
You
know
must
be
accepted
right.
So
only
when,
when
the
primary
says
accepted,
then
you
know
we
we
forward
the
packet
to
the
to
the
backup
right.
C
D
No,
there
are,
there
are
Gohan,
there
are
multiple
cases
so
see.
Only
yes
only
accept
only
for
the
case
of
accept.
We
create
the
connection,
and
only
when
we
create
the
connection,
it
is
sync
to
the.
It
is
sync
to
the
standby,
but
there
can
also
so
whenever
there
is
a
deny
connection,
it
is
not
even
created
in
the
in
the
active,
so
it
won't
be
created
in
the
standby.
D
That
is
correct,
but
that
is
you
are
talking
about
the
case
where,
when
initially,
the
connection
gets
set
up
right,
but
while
the
connection
is
in
place
and
it
has
been
set
up,
it
has
been
synced,
someone
can
go
and
change
the
configuration
to
you
know
from
then
on
to
deny
those
flows
right.
So
we
need
to
go
and
act
on
those
connections.
D
C
D
C
D
C
D
So
so,
for
the
connection
setup
that
I
mean
connection
setup
and
tear
down
those
are
the
those
are
the
control
packets
right,
if
you,
if
you
take
TCP,
those
are
all
the
same
packets,
the
finf,
finite
packets,
hack
packets.
In
addition
to
that,
the
the
the
configuration
change
basically
can
change.
The
configuration
I
mean
I
can
change
the
connection.
State
yeah,
like
a
a
rewrite,
can
be
changed
or
other
things
can
be
changed.
D
F
You
know
I
think
it'll
be
good.
If
you
have
some
example,
for
example,
right
right
now,
it
seems
like
what
you're
talking
about
is.
It
is
a
flurry
simulation
right.
So
let's
say
a
connection
is
already
established
and
everything
is
hunky-dory.
Everything
is
Flowing,
fine
and
suddenly
a
configuration
changes
that
configuration
change
is
a
policy
change.
That
would
really
mean
that
okay,
you
have
to
tear
down,
let's
say
a
disconnection,
meaning
that
you
cannot
admit
this
one,
because
the
previous
policy,
you
were
able
to
admit
that
connection
with.
F
You
have
to
basically
you
know,
deny
this
connection
now
in
order
to
deny
this
connection.
You
have
to
tear
down
this
connection
and
you
in
order
to
tear
down
this
connection,
you
need
to
tear
down
the
connection
on
both
active
and
standby
right.
So,
in
order
to
do
this
thing
right,
you
are
the
one
who
is
initiating
you,
meaning
that,
okay,
let's
say
an
active
person
who
is
going
to
initiate
you
know
the
resetting
of
the
connection
or
whatever
be
the
case.
D
D
That
is,
you
can
do
it
in
different
ways.
So
what
we
do
is
whenever
there
is
a
configuration
change
right,
we
don't
go
and
immediately
change
the
state
in
the
connect
connection,
because
the
connection
basically
needs
the
state
change
only
when
the
packet
packet
is
received
right
and
we
want
to
forward
the
package
so
whenever
the
packet
gets
received.
At
that
point,
we
basically
we
go
and
fix
up
the
connection
with
a
new
configuration,
and
that
is
the
packet
which
experienced
a
state.
A
D
F
D
Is
changing
this?
No,
no,
so
yeah
what
I
mean
to
us
see
when
when
okay,
let's
say
there
is
a
connection,
and
it
is
not
seeing
any
packet
right
and
it
is
there
configuration
changes,
you
won't
go
and
fix
up
that
if
you
won't
go
and
update
the
connection.
Yet
the
configuration
is
updated.
All
your
data
structures
are
updated,
but
the
connection
is
not
modified.
A
Last
week,
I
had
asked
the
new
simulation
question.
You
know
whether
we
will
use
grpc
if
it
is
like
offline,
because
the
configuration
is
changing
and
there
are
no
packets
coming
or
are
we
going
to
use
the
data
path?
Sync,
you
know
so
I
guess
this
answers
the
question
that
once
the
configuration
change
happens,
which
is
offline
not
related
to
the
data
sync,
you
just
wait
till
the
packet
comes
and
then
apply
the
change,
and
then
it
becomes
like
a
data
sync.
After
that
point,.
D
C
But
why
we're
using
this
way
because
I?
What
is
the
benefit
of
doing
you
know
if
you,
if
you,
you,
know
okay,
so
this,
because
you
have
to
mark
this
connection
in
a
certain
State
saying:
okay,
now
the
con
the
control
plan
deleted,
we
are
waiting
for
a
new
package
come
in
to
to
get
then
to
send
a
notification
to
the
peer.
You
know.
In
that
case,
you
know
which
connection
you
know
is
is
changing
the
state,
why
why
not
using
the
control
plan
to
sync
that
state
to
the
pier?
D
C
No
I
understand
that
right,
so
you,
okay,
so
you
you
receive
a
new
country.
This
new
conversation
Mark
a
few
connections.
You
know
tens
of
whatever
the
connection
to
be.
You
know:
stale
State
rise
to
be
removed
in
this
particular
case.
So
so
in
this
case,
why
not
you
know,
use
the
control
channel
to
sync
all
these
states
into
be
removed
to
the
pier,
and
you
know
through
that
channel
to
do
it.
Why
do
you
need
to
wait
for
the
new
package
to
come
and
then
sync
the
state?
A
And
is
it
the
data
packet
or
the
control
packet
right?
If
you're
looking
at
data
packet,
then
what?
If
it
is
the
deny
case
in
the
sense
the
controller
sent
that
the
vni
is
no
longer
applicable
for
this
card,
then
will
not
get
the
data
packet,
because
you
know
the
VM
is
no
longer
gonna
send
based
on
the
controller.
D
C
D
D
So
only
only
when
the
packet
comes,
it
is
enough
that
we
go
and
update
the
connection
with
the
back
see
there
are
millions.
The
scale
of
connections
is
quite
a
lot
if
you
have
to
go
and
update
each
and
every
connection
at
the
time
of
configuration
change,
there
is
no
guarantee
that
you
are
going
to
finish
it
before
the
connection
comes
anyway,
you
have
to
win
the
connection
games.
You
have
to
make
sure
that
we
update
the
connection
because
of
the
configuration
change
and
forward
it
properly,
but.
D
F
Just
I
think
what
what's
going
on
is
that
it.
If
we
take
a
step
back
and
say
you
know
our
forwarding
pipeline
at
certain
assumptions,
and
you
know
certain
way,
we
thought
that
you
know
we
have
explained
it
right.
For
example,
there
is
a
slow
path
and
there
is
a
transplant
right.
So
slow
path
is
essentially
that
you
know
what
we
talk
about
this
connection
tracking
and
then
where
we
are
going
to
really
evaluate
on
the
policies
like
the
routing
and
ecl
and
so
forth,
and.
F
F
E
D
Exactly
so
yeah,
so
there
is
no
Mark,
so
again
yeah,
it's
it's
it's
basically
the
Implement
center
right
see
you
don't
have
to
go
and
Mark
it
then,
and
there.
Basically,
whenever
you
create
the
connection,
you
maintain
the
config
level
at
which
the
connection
was
created
and
whenever
you
are
receiving
the
packet
there
are
data
structures
that
are
being
updated
as
part
of
the
configuration,
not
the
connection.
D
So
you,
when
you,
when
you
try
to
when
you
get
the
packet
you
refer
to
what
is
the
config
level,
that
is,
that
is
cached
in
the
car
in
the
connection
and
what
is
the
config
level
of
objects?
That
is,
that
is
there
currently
in
the
in
the
data
path.
If
there
is
a
if
there
is
a
discrepancy
between
them,
then
that
says
that
the
config
level
has
been
updated.
Then
you
trigger
basically
from
the
fast
path
you
go
to
a
slow
path.
For
that
connection,
does
it
make
sense
whatever
I
said
or.
C
Maybe
no
no
I
I,
don't
get
it.
I
mean
what
is
this
configuration
level
I
mean
I'm.
Trying
to
you
know
understand
it.
Is
this
config
level
per
connection
instead
or
how
this?
Because,
because
you,
you
know
config
level,
I
would
imagine
you
know
there
are
thousands
of
policies
right.
So
if
you
change
one
policy,
how
do
you
know
which
connections
you
know
being
applied
by
this
particular
policy?.
D
So
let
me
use
one
example
right,
so
that
is,
there
are
these
policies
that
are
associated
with
the
vinic
and
Whenever.
There
is
a
let's
say:
we
have
a
configuration
for
a
winning.
We
we
create
a
version.
Let's
say
you
can
create
something
like
a
version
zero
or
something
for
that
for
that
we
need
and
whatever
connections
that
are
created
during
that
time,
you
can
maintain
that
version.
D
You
can
cache
those
that
version
of
configuration
in
your
connection,
saying
that
this
connection
has
been
created
with
the
config
level,
config
level
or
config
version
of
zero,
and
now,
let's
say
user,
comes
and
changes
the
policies
for
that
we
make.
And
basically
then
we
update
our
local
version
for.
D
Okay,
so
then,
when
the
user
comes
and
updates
the
updates,
the
config
for
the
for
the
eni,
we
then
we
update
our
local
version
for
the
eni
config
version
for
the
eni.
So
now
the
best,
basically,
the
connection
has
has
been
created
and
the
cached
with
the
version
of
zero,
whereas
the
current
version
for
the
eni
config
version
for
the
ENA
will
say
not
zero
right,
something
one
or
two
whatever.
D
C
So
so
let
me
ask
you
this
question
because
let's
say
you
know,
you
and
I
can
associate
like
a
thousand
policy
right.
So
then
you
know,
if
are
you
saying,
if
there's
a
single
policy
change
in
that
thousands
of
policies,
then
you
will
update
the
version
to
from
one
to
two,
and
in
this
case
you
know,
for
example,
you
know
this.
This
UI
could
associate
with
muting
of
connections
for
each
and
every
connection.
It
will
know,
there's
a
conflict
change
because
it
changes
from
one
to
two
so
I.
C
D
It
could
be
using.
You
know,
a
policy,
so
we
translate
rewrite
the
related
stuff.
All
those
things
I
mean
the
way.
The
you
the
way
you
maintain
this
config
level
is,
and
you
are
not
saying
that
this
connection
is
associated
with
this
particular
policy.
With
this
particular
rewrite,
like
I,
mean
a
very
specific
configuration
right.
We
you
what
what
we
maintain
is
at
a
Ena
level.
There
are
these
configuration,
and
the
flows
that
are
associated
with
the
DNA
are
also
are
also
are
having
this
corresponding
configuration
level.
D
C
A
A
C
A
A
I
I
think
what
he's
saying
is
that
the
fix
up
is
done
like
per
packet
on
that
connection,
right
like
if
no,
if
there's
millions
of
connections
but
like
you
know
a
packet
comes
in,
then
the
fix
up
is
done.
Then
the
next
packet
comes
in
for
a
different
flow.
Then
the
fix
up
is
done
on
that
flow
right,
it's
being
done
like
per
packet
as
the
as
as
the
packets
come
in.
If
there's
like
very
idle
connections
or
very
infrequent
connections
and
they're,
not
like
fixed
up
until
a
packet
comes
in.
Is
that
correct?
A
D
C
F
C
This
yeah
so
yeah
sure
sure,
let's
try
to
understand
what
exactly
here
right,
so
I'm
still
not
quite
clear.
So
what
okay?
So
you
know,
there's
a
comforting
change
and
all
the
all
the
connection
detects,
there's
a
configuring
change
and
then
for
the
subsequent
packet
that
belongs
to
those
connection.
What
we
do
here,
we
send
those
packets.
You
know
the
first
packet
to
the
to
the
control
plan,
the
to
the
slow
pass
and
do
the
processing
or.
C
D
Yes,
I
mean
see
we
today
we
basically
we
send
subsequent
Packers.
Basically,
it
has
to
go
through
the
slow
path.
It
has
to
finish
the
fix
up
as
soon
as
the
fix
up
gets
done.
The
connection
will
be
at
the
same
config
level,
so,
whatever
packets
that
we
see
during
the
time
you
have
the
either
you
have
the
option
of
dropping
them
or
you
can
still
pass
them
up
to
your
slow
path
and
then
get
it
fixed
I
mean
it
all
depends
on.
F
E
E
F
Understand
it
and
correct
me
if
I'm
wrong,
so
what
happens
is
that
you
know
the
configuration
changes
you
mark
the
connection
to
the
new
new
configuration
version
and
when
the
next
packet
comes
whenever
it
comes
in
right
now,
you're
processing
it
as
if
it's
not
a
floatable
hit
at
a
fast,
fast
path,
but
instead
it's
like
a
slow
path.
Processing,
you're
going.
F
Evaluation
of
all
those
you
know,
policies
and
if
you
have
anything
at
the
connection
established
in
time,
although
it's
not
a
connection
establishing
packet,
it's
just
regular
data
market
at
that
particular
time.
We're
going
to
do
all
this
ACL
and
loading
all
of
those
things
that
you
have
to
go
through
the
slope
app
and
if
that
were
to
mean
that
okay,
you
have
to
deny
it,
then
it
means
that
you
are
going
to
go
ahead
and
go
and
and
then
try
to
reset
connection.
F
A
I
I
I
think
what
you
described
is
is
probably
correct,
but
I
think
that
there's
one
difference
is
that
the
slow
path
for
this
kind
of
config
change
is
like
not
like
reinserting
a
brand
new
flow
into
the
flow
table.
The
flow
already
exists
in
the
flow
table.
It's
just
being
updated
by
the
slow
path
based
on
you
know,
maybe
reevaluating
the
the
the
policy,
but
it's,
but
it's
not
like
allocating
and
inserting
and
updating
like
a
new
phone
cable.
It's
already
existing
exactly
so.
A
F
A
D
D
A
D
No,
no,
as
he
said
right
when
the
connection
get
in
the
connection
State,
you
maintain
what
is
the
config
version
at
which
it
was
created
or
it
was
last
updated
and
whenever
we
receive
the
packet
before
we
forward
the
packet,
we
look
at
the
version
that
is
maintained
in
the
connection
and
the
current
version
of
the
the
data
structures.
That
is
there
in
the
data
path
for
the
for
the
objects
that
we
refer
to
right
are
being
used
in
the
connections.
D
C
Think
I
guess
you
know
this
is
also
opportunity,
like
you
know,
because
how
do
you?
How?
How
do
you
reconcile
say?
Okay,
the
version
you
know
for
the
control
plan.
Hardware
is
the
sync
because
you
know
if
you
set
up
a
timer
it
may
not.
It
may
not
be
the
case
that
all
the
the
connection
you
have
will
be
seeing
a
packet
because
the
Recon
sale
only
happens
when
you
see
a
packet
right.
So
what
if
you
know
if
the?
C
A
C
A
D
No
so
yeah
so
as
with
the
fix
up
see
even
before
going
to
reconcile
right.
So
just
how
do
you
know
whether
the
connection
is
updated
for
the
connection
update
or
not
right?
So
that's.
Why
I
that?
That's
what
as
I
said,
let's
say
eni
when
you,
when
you
create
a
configuration
for
a
eni,
you
can
have
I
mean
internally,
you
can
maintain
some
version
for
the
eni,
let's
say
version
one.
Let's
say
when
you
create
a
connection.
You
catch.
D
That
version
in
the
connection
saying
that
this
connection
is
using
version
one
config
after
eni.
Now,
when
user
comes
and
changes
the
configuration
for
the
eni
it
will,
the
version
will
be
updated,
and
now,
after
that
update
of
config,
let's
say
packet
is
received
by
the
connection
for
the
eni.
Then
it
will
basically
see
that
the
version
maintained
in
the
connection,
whatever
the
config
version,
is
version
one.
D
C
C
A
C
Sorry,
sorry,
so
so
at
where,
at
each
connection,
you
will
maintain
the
version
that,
when
the
connection
is
created
right,
so
you
know
for
that
one.
So
you
know,
for
example,
when
the
connection
is
created
at
that
time,
the
uni
version
is
one
so
that
this
connection
version
will
be
what
right.
So
then,
if
it's
Emi
is
at
the
point
of
the
equation,
is
two
of
the
you
know.
This
connections
that
you
have
you
know
configuration
version
is
two
right.
So
for
every
connection,
you
will
have
a
cached
version
right,
correct,
okay,
but.
F
You
know
Balki,
why
do
you
have
to
do
this
thing?
I
mean
just
imagine
what
I
see
this
thing
is
that
for
all
the
connections
that
you
have
on
any
eni,
if
you
have
a
marking
that
hey
you
know,
it
needs
to
go
through
slow
path
right
because
of
some
configuration
chain,
I
mean
the
configuration
may
have
changed
10
times
before
that
right.
But
if
all
you
do,
is
you
just
Market
that
you
know
the
next
packet
I
need
to?
F
D
F
D
D
F
E
D
D
Mean
see
this,
this
see
this
car.
This
fixer
thing
I
mean
connection
fix
up,
it's
I
mean
you
can
do
it
in
different
ways.
I
I,
don't
know
whether
we
need
to
discuss
that,
but
it's
it's
kind
of
very
implementation.
Specific
for
this
flow.
Sync
discussion,
I,
don't
know
whether
we
have
to
go
into
that
the
implementation
details
of
how
you
fix
up
the
connection
right
I
mean
depending
on
your
hardware,
and
this
thing.
Yes,
you
can
ask
them.
D
When
configuration
gets
updated,
you
can
go
and
sweep
the
connection
and
and
then
you
can
go
and
fix
it
up.
If
you
find
that
to
be
optimal
for
your
implementation
right
or
you
can
you
can
do
it
based
on
a
packet
driven
mechanism
which
which
whatever
we
are,
we
are
doing
right,
but
that
doesn't
mean
that
as
soon
as
config
update
happens,
we
go
through
each
and
every
connect
connection
and
go
and
Market.
We
don't
do
that
so
so
Balki.
D
F
F
D
D
D
The
existing
flow
entry-
it
will
still
be
there
because
the
the
Tuple
doesn't
change
right.
The
flow
entry
will
be
there,
but
there
can
be
whatever
some
because
of
the
configuration
change
there
can
be
changes
to
the
state
in
the
connection.
Right,
like
some
rewrite,
can
be
changed.
Something
like
that.
It's
nothing
to
do
with
I
mean
you
don't
have
to
update
the
flow
per
se
yeah,
but
you
know
you
don't
know
that
right.
The
only
thing
that
you
know
is
the
config
is
dirty.
D
D
D
At
that
point,
the
way
the
way
you
have
the
flow
state
is,
you
know
whether
it
is
I
mean
it
is
going
and
updating
the
flow
Tuple
itself
right
or
it
is
affecting
if
it
is
changing,
only
the
rewrite
information
right
I
mean
if
it
is
changes
the
incoming
flow
Tuple
itself,
then
at
that
point
of
time
it
is
actually
becoming
a
totally
new
connection.
It's
not
like
existing
connection
right.
D
F
E
D
Okay,
so
yeah,
so
the
flow
see
flow
is
that
is
basically
flows,
the
connection
right
so
which
is
maintaining
the
version.
That
is
also
a
version
under
the
eni.
That
is
the
version.
The
current
version
configuration
version
for
the
eni.
So
when
you
so
now,
I
yeah
I'm
going
into
the
implementation
right.
So
when
you,
when
there
is
a
configuration
change,
you
go
and
change
the
version
in
the
eni.
You
don't
go
and
change
the
version
in
all
the
connection.
That
will
happen
as
part
of
the
fix
up.
D
F
D
B
For
for
this
synchronous,
State
replication
and
what
is
the
possible
optimization
or
what
is
a
vendor
specific,
because
I
think
that
we
started
the
conversation
why
we
have
metadata
there?
Then
we
went
to
all
the
flowry
simulation.
Then
we
discovered
that
that
there
is
some
vendor
specific
way
to
do
the
following
simulation
and
all
that
is.
B
Somehow
part
of
The
Proposal,
which
is
not
actually
here,
it
is
not
and
I
understand
why
it
is
not
listed
in
here,
because
it
is
vendor
specific
implementation.
I
agree
with
that,
but
I
don't
see
a
a
clear
line
between
what
is
the
core
of
the
proposal
and
what
is
considered
to
be
an
implementation
on
your
site.
C
Yeah
I,
I,
I
I,
think
I
I
I,
I
I.
You
know
agree
that
so
I
think
the
you
know.
Maybe
the
missing
part
is
like
okay,
you
know
because
it
mentioned
it
was
a
policy
and
you
know
it's
unclear
whether
those
are
optional
or
vendor
specific.
You
know,
implementation
or
versus
this
is
required
right.
So
so
going
back
to
the
question
right,
so
you
know
it
seems
like
carrying
metadata
is,
is
a
way
you
know
for
a
special
vendor
to
address
those.
You
know
State
synchronization,
but
you
know
there.
C
D
So
the
reconciliation
also
the
Recon
sorry
moment.
So
let
me
go
on.
Let
me
tell
you
the
reconciliation,
also
yeah.
How
does
the
the
flow
reconciliation
right,
whatever
that
controller
is
going
to
do?
It's
not
like?
As
soon
as
whichever
happens
it's
going
to
happen,
the
control
there
is
some
heuristics
that
the
controller
is
going
to
do.
I
mean
that
is.
That
is
how
Microsoft
is
doing.
Obviously,
but
there
is
some
heuristics
where
they
have
to
figure
out
that,
after
switch
over,
let's
say
node
one
node
2,
node
2
goes
down.
D
Node
2
takes
over
node,
one
goes
down.
Sorry
node
one
goes
down,
node
2
takes
over,
it's
not
like
it
can
come
and
say
you
can
reconcile
immediately
now
right,
based
on
some
heuristics.
They
will
figure
out
that
node
2
has
caught
up
to
the
config
level
of
node
one
and
enough
from
now
on,
connections
can
be
fixed
up.
I
mean
connections
can
be
reconciled
right,
but
during
the
time
before
that
can
happen,
there
are
packets
that
are
hitting
node
two
and
they
have
to
be
switched.
You
cannot
switch
them
with
old
configuration.
D
C
I'm
I'm
planned
I
get
you
know,
maybe
as
a
that
that
point
of
time
you
know
the
the
the
standby
is
not
up
to
date,
but
for
the
plan,
the
you
know
before
the
streets
over.
Why
can't
the
you
know
the
the
backup
one
get
you
know
up
to
date
it
and
then
do
the
switcher.
Why
why
we
cannot
prepare
the
you
know
standby
note
to
be.
You
know
to
be
fully
prepared
before
we
switch
over.
A
E
D
D
C
Why
why
we
are
making
you
know
this
problem?
You
know
already
a
challenging
problem,
even
more
challenging.
Why
we're
saying
okay
during
the
switch
over
the
the
the
primary
can
still,
you
know
updating
the
policy.
Why?
Why
why
we,
we
cannot
say:
okay,
you
know
during
this
reach
over
I
assume.
You
know
it's
just
you
know
several
seconds
right,
so
Street
series
can
we
stop
operating
the
the
primary?
Why?
Why
is
that
yeah.
D
C
A
D
A
But
isn't
that
true
that,
with
the
approach
where
you
update
the
connection
based
on
the
data
packet,
you
know
back
to
the
question
that
go
ahead
and
ask
earlier
you
don't
have
a
deterministic
way
of
saying
you
already
apply
all
the
configuration
right.
The
controller
have
no
way
of
knowing
that
before
any
initiate
a
plan
to
fails
because
of
the
approach,
the
data
plan
driven
approach.
D
A
Really
the
case
Yeah.
So
basically,
let's
say
a
configuration
change
happened
that
impact
a
million
entry
right,
but
we
don't
have
a
deterministic
way
of
saying
this.
One
million
entry
will
complete
the
processing
because
it
depends
on
the
packet
coming
in
on
those
million
entries.
So
from
the
controller
point
of
view,
how
would
that
know
that
the
configuration
already
applied
before
it
initiates
a
plan
to
fail
over.
C
Okay,
no
I
I!
Guess
you
know
I
guess
you
know
the
the
Microsoft.
You
know
poser
requirements.
Saying:
okay,
you
know,
you
know,
control
plan
I,
don't
have
ASL
to
guarantee
them
to
synchronize
right.
So
they
then
you
know
MD
helped
me
to
figure
out.
What
can
you
do
to
you
just
use
the
data
plan
to
do
the
synchronized,
then
the
empty
say:
okay,
hey
you
know.
Let
me
let
me
try
my
best
to
do
the
data
plan.
Synchronization
you
know,
use
whatever
technology.
E
C
E
C
A
C
That's
one
argument
that
gets
that
part
right
so
yeah.
Actually
you
know
for
the
unplanned.
Then
you
you
know
you
probably
have
a
you
know
different
configuration
at
that
point
of
time
and
then
you
know
if
that
happens,
then
you
know
your
daily
data
plan.
Schema
will
be
able
to
do
this.
Full
synchronization.
E
Yeah,
so
that
that
is
a
that
is
a
that
is
a
basic
requirement
from
a
basic
requirement
for
that
I
think
we
we're
all
agreed
already
on
the
fact
that
both
primary
and
standby
should
have
the
same
should
have
this
close
from
the
same
conflict
based
on
based
off
of
the
same
config,
I.
Think
that
was
already
agreed
upon,
and
so
that's
what
makes
this
when
we
do
the
flow
sync,
we
need
to
carry
the
metadata
to
with
the
policy
results
now
from
the
primary
to
the
secondary
okay.
A
E
F
E
E
So
those
are
all
implementation,
details,
I
think
so,
I
think
from
the
requirements
and
the
approach
point
of
view.
The
approach
is
that
we
we
carry
all
the
policy
results
in
such
a
way
that,
however,
the
data
path
is
set
up
right
in
such
a
way
that,
when
forwarding
happens
on
the
primary
or
the
secondary
after
switch
over,
there
should
be
no
difference.
F
Yeah,
you
know
vendor
implementation
or
implementation,
specific
detail
or
optional
thing
and
so
forth.
So
I
just
want
to
step
back
a
little
bit.
You
know
with
Marion's
comment
as
well.
As
you
know,
with
Gohan's
comment,
so
I
mean,
of
course
we
don't
have
the
time
left
for
today,
but
at
least
you
know,
maybe
we
can
do
it
in
the
next
session,
but
I
don't
want
to
touch
on
this.
One
is
that
you
know
whatever
we're
talking
about
the
optional
or
whatever
be
the
case.
F
What
I
see
here
is
there's
clearly
a
change
in
the
lookup
right
based
on.
So
there
is
a
pipeline
change
in
terms
of
okay.
There
is
a
version
number
that
you
have
to
match
against.
Whenever
you
see
the
packet
between
the
version
number
that
is
stored
in
the
connection
versus
the
version
number
with
the
eni,
and
then
you
know,
based
on
it,
you
decide
whether
you
go
through
the
slow
path
or
fast
path
and
so
forth.
So
this
this
processing,
you
know
the
packet
processing
that
is
happening
clearly
changes
this.
E
E
E
F
A
C
E
E
C
E
E
C
C
A
D
E
A
G
From
the
start,
we
wanted
the
control
Power
to
be
interoperable
and
then
the
data
path.
It
looked
like
a
bit
hard
to
start
off
with
interoperability
there.
So
things
like
perfect
sync
can
be
done
in
the
you
know,
the
slow
path
and
that
should
have
been
interoperable,
but,
however
I
we,
we
did
talk
about
not
inside
mode
one
data
path
being
interoperable
on
day
one
because
everybody
has
a
different
approach
and
we
just
didn't
seem
reasonable.
C
Yeah
I
mean
that
that's
I,
guess
that
not
on
day
one
but
shouldn't
wait
at
least
to
you
know,
try
that
and
at
least
it
out
so
that
we
have
a
base
version.
You
know,
then
people
can
start
the
because,
because
currently,
if
we're
not,
if
we're
not
the
you
know,
basically
we're
not
doing
any
front
on
that
data
pass
synchronization
in
our
ability,
right
so
just
to
say:
okay,
you
need
to
you
you're
using
this
and
that
it's
not
clear.
It's
not
defined
in
packet
format.
C
C
C
E
C
C
D
D
A
C
We
current
do
not
impose
right
so
by
at
least
I.
Think
we
need
to.
You
know,
have
something
that
the
community
can
take
a
look
at
right.
So
otherwise
right
so
you
know
we're
we're.
Not
we're
not
going
to
do
any
data
plan.
You
know
in
our
ability
and
then
there's
no
way
to
do
data
plane
or
probabilities.
Is
there
so
there's
no
way
to
do,
because
it's
a
purity,
control,
plane
or
ability.
That
is
not
sufficient
right.
C
So
if
we,
if
we
ever
want
to
do
those
interoperability
scenes,
then
right
so
there's.
Basically
you
know
if,
if
without
data
plan,
there's
no
way
to
do
it.
So
therefore
I
suggest
that
you
know
we.
We
can
at
least
get
a
version
and
discuss
it,
and
then
people
can
see
whether
we
can
do
it
or
not
right.
C
A
D
But
Gohan
the
reason
for
that
proposal
is
you
want
to
interoperate
a
different
vendor
implementations.
Is
that
what
you?
What
is
the
goal
for
this
exercise?
Exactly
now,
I
thought,
but
we
started
with
an
exercise
of
basically
having
some
of
the
common
aspects
of
it
more
to
the
the
sonic
layer,
right
that
that
is
how,
like
the
FSM
and
the
bulk,
seeing
that
kind
of
that
kind
of
aspects
to
be
moved
to
Sonic
right,
so
that
that
implementation
doesn't
have
to
be
repeated
in
others,
but
not
necessarily
interoperating
different
way.
C
Though
right
so
that's
original
goal,
I
mean
yeah.
Yes,
you
know
but
I
think
as
Jared
mentioned
right
at
least
we
should
try
it
right
so
because
if
we
you
know
currently,
if
we
do
not
present
it
I
mean
do
not
have
a
proposal.
They
you
know,
there's
no
way
to
try
it
right.
So
at
least
I
think
we
can
get
the
package
for
men
and
people
can
can
look
at
to
see
whether
there's
a
possibility
to
do
the
interrupt
right.
So.
G
Yeah,
it
could
be
that
the
message
is
is
written
in
such
a
way
that
there's
kind
of
mandatory
information
and
then
there's
some
opaque
information
that
you
know
gives
people
freedom
to
send
different
metadata
from
their
control
plane.
Something
like
that,
but
you
know,
looking
at
the
mandatory
kind
of
information
might
be
the
way
to
start
like
in
order
to
get
the
thought
process
going.
Yeah.
G
Then
you
know
you,
you
could
argue,
oh,
but
to
optimize
I'm,
going
to
send
this
opaque
stuff
too.
Okay,
so
then
the
message
format
should
be
flexible
enough
to
be
able
to
handle
that,
and
then
people
can.
You
know,
explain
why
they
need
that
other
information
to
us
or
somebody
else,
but
we
can
start
with
a
mandatory
like
the
things
that
make
common
sense
that
you
need
to
send
across.
So
then
people
can
kind
of
dissect.
Is
this
scheme
working
like?
Does
it
work
overall?
G
Like
does
you
know
all
the
stuff
that
you
guys
been
discussing,
but
you
have
something
to
look
at
that
I
would
at
least
try
to
think
of
it
that
way,
and
not
think
of
it.
As
oh
I
can't
say
my
metadata
anymore
and
geez,
it
would
have
been
so
much
more
often
I.
Don't
think
we
would
want
to
block
that,
but
there
must
be
some
subset.
That's
mandatory.