►
From YouTube: DASH High Availability Working Group Oct 11 2022
Description
MetaData standardization
AMD update to proposal
Syncs near real-time, not necessarily real-time
A
And
presented
the
notes
from
last
time
and
seems
like
we
had
a
huge
conversation
last
time,
I
took
a
lot
of
notes
and
you
know
kind
of
like
how
the
the
re-simulation
was
triggered
last
time
from
amd's
perspective
and
how
they
were
doing
it
and
not
necessarily
that
everyone
has
to
do
it
the
same
way
and
then
we
started
talking
at
the
end
more
about
like
you
know,
we
still
need
to.
We
still
need
to
kind
of
figure
out.
A
You
know
how
how
the
control
plane
and
the
the
data
plane
in
the
packet
format
like
how
we're
going
to
do
this
and
Define
the
control,
Channel
and
so
thought.
Maybe
we
could
pick
up
there
or
if
anyone
had
a
PR
or
work
item
they
wanted
to
talk
about.
First.
A
B
Oh,
oh
okay,
I,
I,
think
I.
Think
last
week.
Maybe
Maria
says
that
you
know
he
he
would
review
those
updated
hld
right
so
and
provide
the
you
know
feedback.
If
there's
any
I
wonder
you
know,
since
we
talk
a
lot
about
and
the
last
10
months
that
Melody
I
mean
wonder
if
Marine
look
at
the
you
know
other
updates
and
have
any
comments.
Okay,
oh.
A
B
A
The
Sanjay
or
Vijay
did
you
add
to
The
Proposal.
C
Whatever
was
added
then
Christina,
then
there
are
no
new
updates,
but
I
think,
like
not
clear,
was
the
agreement
that
we
would
put
the
metadata
format,
because
that
I
don't
know
if
we
can
put
that
right.
That
doesn't
seem
like
there
is
I
think
what
we
had
agreed
before
when
we
are
before
I
updated.
The
thing
was,
we
will
call
out
what
are
the
things
that
need
to
be
there
in
the
metadata.
C
The
reason
is
the
way
we
communicate
the
metadata.
We
cannot
have
a
lot
of
processing
on
the
standby
side
before
we
insert
the
flow
right.
Otherwise
we
will
not
be
able
to
keep
up
with
CPS
numbers
that
we
want
right,
because
it's
a
combination
of
processing
on
the
active
processing
on
the
standby,
so
we
can't
send
it
in
some.
C
C
So
I
don't
know
if
it's
a
reasonable
thing
for
us
to
put
forth
whatever
exact
packet
format
we
send
across
Etc,
because
it
won't
make
sense,
it's
very,
very
implementation,
specific,
very
table
specific
how
the
way
we
the
way
we
have
laid
it
out
right,
but
I,
think
the
general
in
the
proposal.
This
thing
says:
what
are
the
things
that
you
need
to?
The
implementation
needs
to
carry
now
how
you
in
how
each
implementation
encodes
it
is
up
to
the
implementation.
C
If
each
implementation
is
going
to
have
its
own
optimized
format,
what
would
be
the
purpose
in
laying
out
what
the
exact
packet
format
is,
because
the
way
the
tables
are
laid
out,
the
way
the
data
structures
are
laid
out
may
be
very
different
from
implementation
to
implementation.
C
In
our
view,
it
does
not
I
think
this
is
a
critical
path
right.
Each
flow
entry
when
we
are
creating
when
we
are
inserting,
is
a
very
critical
path.
You
we
should
be
driving
for
the
best
optimization
we
can,
unless
we
are
okay
with
a
much
lower
CPS
number
right.
Since
the
this
thing
is
a
high
CPS
number,
we
are
at
the
edge
of
from
our
experience
right.
We
are
at
the
edge
of
performance
right.
C
We
can't
we
have
pushed
it
to
the
way
extent
we
can
to
get
whatever
CPS
numbers
that
we
are
getting
today
and
making
it
sub-optimal
by
adding
layers
of
processing,
I.
Think
we'll
cut
down
the
numbers
quite
significantly
significantly.
C
A
The
quick
question
on
this
metadata
right
so
when
we.
A
Do
we
carry
any
metadata
in
the
in
the
flow
sync?
Yes,
we
do.
Okay,
so,
and
so
then,
and
flow
sync
is
basically
done
through
control,
channel
right
through
control,
plane.
C
A
Control
yeah
right,
I
agree.
So
hence
if
if
that
is
the
case
and
if
our
objective
is
to
you
know,
we
discussed
for
H
A,
we
want
to
have
at
least
the
control
Channel
or
the
control
plane
to
be
interoperable,
multiple
vendors
right
and
if
there
is,
if
that
is
the
goal,
and
we
leave
the
data
plane
to
be,
you
know,
perhaps
be
interoperable
at
a
later
point,
but
it
initially
to
start
with
the
control
channels.
A
You
know,
is
mandatory
to
be
interoperable,
then,
in
that
case,
I
believe
the
metadata
should
be
standard
right,
so
whatever
is
is
need
to
be
used
which
we
should
Define
it,
and
we
should
agree
on.
You
know
on
the
format
of
it.
C
A
C
Question
then,
if
would
you
when
we
say
control
plane
is
compatible,
but
not
the
data
plane,
I
didn't
get
the.
So
if
you
had
a
active
standby
pair,
are
you
saying
that
that
active
standby
pair
would
be
two
different
vendors.
A
No
I
think
it
was
basically
priority
point
of
view
to
start
with
right.
To
start
with,
we
said:
okay,
we
may
basically
come
up
and
say:
okay,
fine,
our
data
plane
should
also
interoperably
at
a
later
point,
but
at
least
we
start
with
our
control
Channel.
Where
we
do
this
perfect
sync,
it
should
be
interoperable.
That
was
the
goal.
I
thought
you
know,
Gerald
also
said,
and
we
kind
of
agreed
on
that
right.
Yes,
yeah.
D
That's
the
piece
that
would
be
I,
I
agree
with
that
goal
and
and
whether
we
can
achieve
it
or
not,
I
don't
know,
but
that
that
should
be
the
goal
that
the
control
plane
could
be
interoperable,
but
the
data
plane
I
think
is
going
to
be
really
tough
in
the
beginning.
So
we
can
leave
it
for
maybe
a
little
bit
later,
but
we
should
explore
that
and
and
if
that's
not
accomplishable
I
think
we
do
that
by
focusing
on
the
control
plane
and
seeing
how
far
we
can
go
with
that.
A
C
That
is,
that
is
I.
Think
the
opaque
stuff
is
the
actual.
What
we
insert
in
the
flow
in
mind,
whatever
is
there
in
The
Proposal,
but
the
rest
is
rest,
is
in
the
open.
I
mean
whatever
thing:
whatever
is
implementation,
specific
is
what
we
thought
was
opaque.
B
You
know
I
think
you
know.
Hanif
has
a
good
point
where
I
just
look
at
the
you
know
the
update
the
this
pr244
right.
So
you
know
in
the
side
header
this
flow
sync
messages
which
is
used
for
the
control
plan.
I
think
the
metadata
somehow
is
still
opaque
data
right.
So
if
we
want
to
achieve
this,
you
know
control
plane,
think
about,
then
you
know
we
we
need.
We
need
to
Define.
You
know
more
detail
on
that
meta
right.
Basically,
I
read
the
I,
raise
a
crushing
on
your
pr244
asking.
C
Yeah
yeah
yeah,
so
this
is
what
I
was
saying
on
the
format
of
the
metadata
itself.
Today,
the
we
think
what
the
way
we
have
been
able
to
get
whatever
performance
we
can
we
could
get
is
it
is
very,
very
implementation,
specific
right.
It
is
because
we
don't
want
to
get
some,
at
least
when
our
in
our
experience,
getting
some
abstract
data
and
then
converting
it
to
what
we
want
to
do
to
push
is
was
affecting.
C
It's
very
similar
right,
whatever
we
sent
even
in
the
data
plane
sync,
when
we,
when
we
sync
a
flow,
a
new
flow
right,
it
carries
the
same
metadata
across
to
the
other
side,
because
that
is
how
we
insert
the
flow
right,
even
whether
we
carry
it,
the
metadata
itself
is
the
same,
whether
we
carry
it
in
the
control
plane
or
we
carry
it
in
the
data
plane,
but
think
of
it,
this
way
right
or
how
do
I
say
it.
Let's
say
we
are.
B
Inside
that
part,
but
I
think
you
know,
because
the
control
plan
is,
you
know,
there's
a
CPU
involved
right.
So
you
know
why
can't
we
just
Define
some
standard,
the
metadata
and
you
know,
do
a
simple
if
we
need
to
insert
the
hardware
image,
simple
translation
right
so.
D
A
D
Still
require
opaque
data,
which
is
specific
to
the
hardware.
I
think
that's
what
I'm
hearing
so
the
bulk
of
it
could
be
interoperable,
but
I.
Don't
think
I
think
what
I'm
hearing
is
there.
You
can't
get
around
the
fact
that
you'll
still
need
to
send
opaque
data,
which
is
specific
to
their
hard
work.
B
D
B
B
D
D
Yeah
we're
not
talking
about
CPS
we're
talking
about
the
communications,
Channel
It's
associated
with
how
you
know
CPS,
but
it's
not
CPS
you're
you're.
You
are
creating
a
connection
on
the
other
device,
the
same
one
that
you
have
you're
creating
a
connection
and
then
subsequent
messages
are
updating
that
connection.
That's
what
you're
doing
the.
B
D
B
B
C
B
C
So
the
data
part
sync
itself
we
have
before
we
insert
the
flow
before
we
complete,
inserting
the
flow
we
have
to
send
it
to
the
standby.
The
standby
has
to
insert
the
flow
and
then
once
only
once
that
is
done
is
when
we,
when
we
say
I
mean
the
flow,
is
inserted
even
on
the
active.
So
that
is
what
effects
I
mean.
That
is
the
CPS
right.
How
much?
How
fast
we
can
do
that.
C
But
it
is
going
to
the
same
table.
That's
right,
like
Gerald,
was
saying
it's
going
to
the
same
table.
So
that
is
why
we
had
all
these
messages
where
we
said
that
there
is
a
bunch
of
optimizations
to
be
had
in
how
we
do
the
bulk
sync
2.
We
cannot
do
it
in
a
blind
way
right,
because
the
minute
we
start
doing
it
in
a
blind
way.
C
There
are
multiple
threads
that
come
in
from
our
implementation,
I'm
thinking
that
it
will
be
the
same
for
other
implementations
too
right
is
you,
you
will
have
multiple
threads
and
you
will
have
logs
on
those
threads,
because
you
are
accessing
the
same.
You
can
have
slices,
but
you
will
still
have
blocks
and
you
will
have
some
concurrency
this
thing
internet.
So
once
you
do
that,
if
you
just
blindly
sink
over
even
for
the
bulk
sink
and
hold
up
the
table,
your
DP
sync
also
will
get
held
up
right.
C
We
are
talking
about
4
million
CPS
per
second
right.
It's
not
a
small
number
right.
B
At
this
point,
no
I
don't
understand
sorry,
okay,
so
you're
talking
about
the
lock
right
so
but
I
don't
understand
why
you
want
to
hold
the
lock
when
you,
when
your
data
is
not
ready
right.
So
you
know
imagine
for
the
control,
we're
not
talking
about
the
data
plastic,
we're
talking
about
the
control
plan.
Let's
make
clear
about
that
right
so
for
the
control
plan,
sync,
so
our
our
let's
be
clear
on
the
scope
right.
B
So
our
our
thinking
is
that
why
this
metadata
on
the
on
the
control
plan
Channel,
cannot
be
standardized
and
has
to
be
vendor
specific,
and
you
are
saying
this
is
because
you
need
to
do
the
translation
and
the
translation
impact
the
CPS
right.
So
that's
what
you're
saying
so
so
so
we
want
to
understand
this
one
right
so
and
then
you
are
saying
why
it's
impacting
the
CPS
is
because
you
know
you
are
updating.
You
are
holding
the
log,
therefore
you're
blocking
the
data
plan
right.
So
is
that
what
your?
What's
your
expense
vanishes.
C
Like
whenever
we
are
touching
the
floor,
go
on,
it
has
I
think
when
our
experience
it
has
been
that
the
most
efficient
we
are
trying
to
get
to
the
most
efficient,
because
anything
that
we
do
every
bit
and
piece
is
affecting
I
mean
it
will
affect
the
CPS
I.
B
Think
no
I
I,
guess
that
part
right.
So
when
you,
when
you
do
the
lock
only
lock,
has
a
critical
section
that
that's
totally
understood,
but
you
know
have
that's
not
conflict
with
a
standardizing.
The
control
plan
metadata
messages
right
because
you
know
you
have
standardized
a
method
in
a
message
engine
before
you
translate.
She
translate
that
standard
messages
into
the
hardware.
Specific
message
don't
hold
the
lock
right,
because
at
that
moment
you
know
you
are
not
ready
to
insert
to
the
header.
Why
do
you
hold
the
lock
at
that
point
of
time.
A
The
data
that
we
think
itself
is
vendor
specific
data,
isn't
it
so
it
depends
on
the
how
the
tables
are
implemented,
how
the
dash
pipeline
has
been
implemented
in
each
vendor
specific
pipeline.
So.
A
We
are
thinking
is
not
is
not
the
common
data,
it
is
the
lookup
results
of
each
table
and
stuff
like
that.
For.
B
Sure,
no
sure
I
think
we
definitely
understand
you
know
there
could
be
some
optional
data
right.
So,
but
you
know,
in
terms
of
there
must
be
some.
You
know
required
data
that
is
common
for
for
everybody
right.
So
are
you
saying
that
any
you
know
all
the
data
is
not
common?
Is
all
vendor
specific,
so.
C
Let
me,
for
example,
if
you
could
go
down
to
the
data
State
synchronization
itself,
it's
a
little
few
little
bit.
State
synchronization.
C
No,
no,
no,
no!
No,
sorry!
Sorry!
It's
not
I
should
put
some
section
numbers
there,
but
by
little
high
little
it
is
become
a
little
lower
question.
If
you
can
just
look
for
yeah.
C
C
C
So
if
you
go
down
the
we
have
listed
out
what
needs
to
be
synced.
A
C
C
C
All
right,
so,
if
you
see
there
go
on,
for
example,
we
are
saying
policy
results
from
the
security
lookup
right
or
there
is
mapping
and
Route
route
Lookup
All
These
are,
you
know,
rewrite
information.
All
these
are
very
specific.
My
these
are
very
specific
to
the
implementation.
Today
right
we
have
to
come
up
with
some.
Is
there
abstract
way
of
referring
to
this?
Maybe
we
need
to
this
thing.
Oh.
B
A
B
C
B
I
already
raised
my
argument
on
that
part.
You
know
if
the
translation
causes
CPU,
you
know
sure,
but
if
the
translation
is
blocking
the
CPS,
you
know
why.
Why
why
why
you,
you
know
you
put
your
law
kind
of
a
non-critical
section.
C
A
B
Sure
I
mean
we
already.
We
already
asked
that
point
right
so,
but
we
said:
okay,
let's,
let's
define
the
common
things.
First,.
A
C
So
one
thing
going
I
think
one
thing
we
should
this
thing
right:
these
are
not
like
32
core
x86
CPUs
that
we
are
running
right.
These
are
our
CPUs
run
almost
at
the
edge
when
we
are
scheduled
and
then
when
we
are
at
scale,
so
the
data
part
CPUs
are
running
almost
to
the
Limit
right.
So
in
our
this
thing,
Even
in
our
the
TPO
messages
that
we
have,
we
have
to
kind
of.
C
Even
for
the
this
thing
we
have
to
find
out
when
CPU
has
when
which
core,
when
a
core
has
three
Cycles
to
take
pulsing
messages
to
put
in
that
is
the
level
at
which
it
is
our.
At
least
our
implementations
are
running
to
achieve
this
CPS
length
right.
So,
if
I
I
think
at
a
high
level,
it
looks
fine
to
say
that
do
not
put
a
log.
Do
everything
then
get
to
a
critical
section,
but
when
we
are
implementing
it,
we
find
that
it
is
a
problem
right.
C
If
you
have
to
do
any
translation,
any
additional
CPU
load,
I.
B
Mean
tell
me
something
special
about
the
translation.
You
need
to
do
right
so
sure,
tell
me
some
specific
translation.
You
know
what
what
what
what
what
could
be
done
for
say,
APM,
app
I
mean
it's
IP
address
is
how
would
you
translate
them?
You
need
to
sorry
to
be
the
you
know
128
bit
right.
So
what
kind
of
translation
you're
going
to
do.
A
A
B
But
I'm
not
sure
you
know
that
you
know
people
are
fully
agreed
on
the
DP.
Sync
that
you
know
you
know.
Maybe
you
know
people
other
people
have
a
different
to
do
the
DP
sync
right
so,
but
you
know
on
the
on
the
CP
sync:
we
should
align
right,
so
DP
sync
I,
think
you
know
because
of
the
hardware
limitation.
Maybe
you
know
different
people
will
have
a
you
know
different.
B
C
Dp
sync
also
goes
through
this.
The
initiation
happens
from
the
this
thing,
but
it
goes
through
this
just.
C
C
Whoever
was
implementing
this
thing
was,
if
you
try
to
add
and
try
to
make
it
improv,
it
will
not
scale,
it
will
not
be
able
to
get
what
we
are
able
to
do
it,
because
we
are
I.
Think
that
we
are
like
I
was
saying
right.
We
are
almost
at
adding
any
unnecessary
computation
on
the
CPUs
will
not
on
any
of
the
cores
is
going
to
be
detrimental.
This
is
the
voice
to
this
thing.
B
A
D
I
agree
with
that
that
I
think
the
use
case
here
is
important
that
when
you're
doing
a
vault
sync,
this
is
something
that
happens.
You
know
whether
it
happens
in
30
seconds
or
one
minute
is,
is
not
really
it's
not
like
a
real.
It's
a
it's
a
near
real
time
thing.
It's
not
a
real-time
thing,
so
it's
not
it's.
If
it's
taxing,
then
you
just
take
a
little
bit
longer
to
do
it.
D
Well,
that's
not
the
that's,
not
the
issue
here,
it's
a
let's
say:
I
have
the
bigger
issue
for
me.
I
have
two
vendors
I
now
know
that
both
vendors
from
a
control
side
work
the
same.
They
look
the
same.
They
we
understand
what
it's
doing.
We
understand
the
messages
we
understand
the
the
flow
charts.
We
understand
everything
that's
going
on,
at
least
on
that
control
side.
D
It's
not
that
we're
going
to
mix
the
vendors,
it's
that
we
need
to
have
a
consistent
operations
that
we
can
understand
and
rely
on,
and
if
we
can
get
the
control
channel
to
be
reliable,
easily
understood
all
the
way
around
by
our
Engineers.
Even
if
we
don't
sync,
two
different
machines,
I
mean
that
should
be
the
goal,
but
I
mean
if
we
don't
do
that,
we
get
a
lot
out
of
that,
because
our
testing
can
be
almost
identical
for
boxing.
B
Yeah
I
I
would
completely
echoose.
You
know
the
the
Josh
point.
You
know
think
about
the
from
the
operational
perspective
right
so
think
about
it
from
the
monitoring
the
debugging
perspective.
You
are
saying
now
you're
saying
right,
so
even
for
the
control
message
you
are
transferring
between
those
two
machines.
There
are
some
may
opaque
data
that
we
do
not
understand
when
we
say
we
do
not
understand,
meaning
the
Sonic
Community
do
not
understand.
I
think
this
is.
Could
this
could
cause
extremely?
B
You
know,
difficulties
in
terms
of
the
debuggings,
the
troubleshootings
that
understand
what
state
has
been
transferred
from
one
one
machine
to
another
machine
right.
So
you
know,
therefore,
that's
why
you
know
we
think
it's
very
critical
and
important
to
make
sure
those
control
messages
have
well-defined
data
structure
will
Define
somatic
and
then
people
can
understand
what
message
has
been
transferred,
but
we're
talking
about
the
opaque
data.
C
Know
there
will
be
issues
without
any
opaque
data.
I,
don't
know,
I
think
even
the
DP
sync
messages
between
that
data
path.
I
think
we
need
some
opaque
messaging
Gohan
I
am
very
worried.
If
you
say
everything
is,
there
is
no
opaque
allowed
at
all
principle
between
the
two.
Given
the
current
experience,
I,
don't
think
it
will
be
very
I.
D
D
B
D
C
If
you
look
at
the
messages,
it's
a
general
there
is
this
bulk
sync
message
itself
all
of
it,
except
for
this
metadata
is
open
right.
It's
not
like.
We
are
just
bulk,
syncing
everything,
that's
not
a
proposal
too
yeah,
so.
B
Okay,
yeah
yeah,
sorry
I
mean
I
I,
think
a
company
I
mean
either
side
right.
So
you
know
the
obviously
you
know
we'll
we'll
have
vendor
extensions
right.
So
we're
not
saying
that
you
know
everything
you
know,
because
we
understand
right.
So
you
know
but
I
think
the
you
know
I
like
what
reshma
say.
You
know
those
say
appear
to
mapping
right.
So
those
rewrite
information.
It
looks
like
it's,
not
the
you
know
when
there's
specific
implementation
is
more
like
a
control
plan
messages.
B
You
know
that
the
sdn
controller
tells
you
right
so.
C
I
see
okay,
I
think
we
can
it's
I,
think
just
to
put
in
the
bulk
sink.
We
can
put
the
the
rewrite
information,
I.
Think
whatever
is
listed
there
right,
I
think
we
could
it's
not
this
thing
we
can
leave
the
leave
some
opaque
field
for
anything
else
We.
Additionally,
we
need
to
carry-
and
we
can
put
this-
that's
that's
that's
it.
We
can
do
that
one.
C
What
I'm
saying
is
whatever
that
state
synchronized,
whatever
is
listed
there
right,
we'll
just
convert
that
to
this
thing,
which
says
policy
result
which
is
a
enum
and
then
mapping
lookup
result
which
is
which
is
the
destination,
and
we
can
try
to
make
that
into
this
thing,
but
we
will
definitely
need
opaque
data
in
the
in
in
the
sync
messages.
Without
that
I
it
will
be
very
hard.
D
I
think
I'll
take
messages.
What
we
could
do
is
because
opaque
are
usually
proprietary
go
on.
We
can
maybe
work
on
the
common
pieces,
and
then
we
can
have
like
a
private
meeting
with
you
know
any
company
who's
trying
to
explain
why
they
need
the
opaque
because
they're,
obviously
that's
not
a
community
thing.
You
can
kind
of
take
that
offline
and
understand
it
a
bit
better.
Yeah.
C
Yeah
I
have
to
go
look
at
to
see
what,
in
the
in
each
of
these
this
thing
that
we're
seeing
today
I
think
we
need
to
go
look
at
it
in
detail
to
see,
because
we
have
not
considered
trying
to
make
it
into
a
yeah
right
all
the
structures
that
we
this
thing.
The
reason
is
I
think
there
are
implications
right,
so
the
code
path,
the
path
that
we
follow
either
for
DP
string
car
for
this
thing
is
very
common
right,
except
for
the
higher
you
know,
one
shim
layer
on
top.
C
A
It
no
I'll
just
approximately
yeah
yeah
sounds
good
thanks,
yeah,
so
Sanjay
as
part
of
this
HF
proposal.
Should
we
not
also
Define
the
message
format
as
well,
and
so
that
we
know
that?
Okay,
how?
Where
do
things
go
and
then,
and
also
of
course,
you
know-
have
a
room
for
wherever?
Basically,
the
opaque
or
vendor
specific
information
also
goes.
C
That's
there
in
the
proposal
below
did
you
in
the
in
the
jrpc
channel.
You
see
the
floor,
sync
message
is
defined
and
then
there
is
the
metadata
which
is
defined
as
bytes
there,
so
that
is
the
opaque
section
other
than
that
everything
else
is
defined
in
the
grpc
section.
C
So
let
me
just
passed
that
if
we,
if
you
look
for.
B
C
Is
defined
I
think
we
are
only
speaking
about
one
portion
of
that
flow
sync
message,
which
is
the
metadata
everything
else
is
defined,
and
if
okay,
okay.
A
C
Yeah
I
think
we
can.
You
can
do
an
attempt
yeah,
but
one.
This
thing,
though
I
think
yeah
the
implementation,
whatever
we
are
standing
by
this
proposal,
to
say
that,
okay,
whatever
was
the
goals
that
we
wanted,
we
are
able
to
achieve
with
this
right
if
we
try
to
cut
it
out
into
different
things
and
force
the
implementation
to
actually
convert
from
that
abstract.
C
To
this
thing,
while
I
understand
that
it
is
on
the
message,
if
you
wanted
to
look
at
on
The
Wire
packets
and
see
what
was
being
transferred
instead
of
looking
at
the
state
on
each
of
the
nodes,
it
is
kind
of
it
is
nice
to
have.
C
You
know,
it
is
good
to
have
this
thing,
but
while
we
stand
with
whatever
word
mean,
we
are
trying
to
take
what
implementation
we
have
with
with
you
know,
taking
it
as
a
working
model
right
of
where
it
is
working
and
standing
up
to
whatever
is
the
required
performance.
If
we
make
the
changes
to
this
thing,
I
think
we
will
need
to
re-evaluate
to
see
whether
we
can
get
the
same
amount
of
performance.
C
If
we
make
the
change
or
is
it
going
to
drop
right
because,
like
I
was
saying
it's
delicate
balance
that
we
have,
we
will
try
to
break
it
up
anyway
for
us
for
the
proposal,
we
can
do
it,
but
I
think
General
from
performance
I
think
we
will
need
to
check
and
see
if
he,
because.
D
A
D
C
A
Question
about
your
data
path,
sync
versus
the
bulk
sync
is
the
metadata
and
the
way
you
sync,
the
flows.
Etc
is
very
similar.
C
C
Yeah,
so
it's
just
flow
info
and
this
thing,
which
is
going
in
batches,
which
doesn't
happen
in
the
TP
data
part
sync,
because
it's
with
paper
packet
thing,
but
the
handling
is
very,
very
simple.
Metadata
is
exactly
the
same.
The
handling
is.
C
C
Cool
yeah,
I
think
yeah
I
think
so
what
we
agreed
on
is
that
state
synchronization,
whatever
we
have,
we
can
try
to
move
that
into
the
the
four
or
five
elements
that
we
said
that
we
that
is
needed
to
be
synced,
agreed
I
think
we
can
move
it
to
this
thing,
but
we
will
have
one
vendor
specific.
This
thing,
too
portion
two
along
with
the.
B
B
C
That's
going
to
remain
the
same
I
think
only
this
thing
is
these
things
will
reflect
in
the
message
itself
question
so
today,
all
these
are
covered
by
the
metadata
one.
Member
in
that
flow
sync
message:
we'll
break
it
up
into
these
four
plus
one
opaque
vendor,
vendor
extension,
yeah.
C
A
I'm,
just
gonna
add
notes
to
our
original
High
availability
and
scale
document
here
just
to
kind
of
capture
what
we're
doing
at
the
bottom
sure.
B
Oh
okay,
so
so
maybe
the
other
question
is
like
when
we'll
be
able
to
review
that
I
think
the
side
header
needs
to
some
update
right.
So
you
can
see
we
Define
those
metadata
messages.
So
when
we'll
be
able
to
review
that
updater,
sorry
that
that
side,
header
update.
C
Be
great
but
I
think
the
rest
I
think
this
will
be
that
only
in
that
flow
sync
message:
please
review
the
rest.
I
think
this
will
be
that
contain
change
within
that
the
definition
itself,
wherever
they
might
get
it
yeah.
A
A
Yeah
well
thanks
for
thanks
for
offering
to
make
those
changes.
Anything
else
for
this
call
from
the
rest
of
the
team.
I
feel
like
I
feel,
like
we've.
C
C
Was
just
going
to
ask
if
we
were
we're
going
to
look
at
the
ecmp?
This
thing
too
I'm
very
curious
on
the
PFT
CMP.
B
That
that's
a
I
think
maybe
I
don't
know
like
a
prince.
When
do
you
think
you
will
be
able
to
talk
about
that.
A
I
can
talk
about
that,
but
anyway
we
don't
have
this
meeting
next
week
right.
So
the.
B
A
A
Oh,
he
must
I
think
he
dropped
okay,
so
so
I
feel
like
we've
had
AMD
and
on
the
hot
seat,
quite
a
bit
here.
So
thank
you
very
much.
Does
anyone
else
want
to
talk
about
anything
else,
other
than
AMD.
A
C
Yeah
yeah
either
probably
add
it
to
the
same
yeah
or
if
you
want,
we
can
merge
this
PR.
So
it's
easier
to
read
for
everyone
which,
however,
we
want
to
handle.
A
It
so
me
merge
the
pr
first
and
then
you
keep
going.