Subject: [netmod] Applied data store clarification in draft-nmdsdt-netmod-revised-datastores-00

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 15 Dec 2016 09:56:37 -0500

Authors,

Need some clarification about applied data store

In the draft, applied data store can contain data from 

This data can come from several sources; from  <intended>, from dynamic configuration protocols (e.g., DHCP), or from control-plane datastore.

The control-plane stores are not well clarified in my opinion

 The model foresees control-plane datastores that are by definition
   not part of the persistent configuration of a device.  In some
   contexts, these have been termed ephemeral datastores since the
   information is ephemeral, i.e., lost upon reboot.  The control-plane
   datastores interact with the rest of the system through the <applied>
   or <operational-state> datastores, depending on the type of data they
   contain.  Note that the ephemeral datastore discussed in I2RS
   documents maps to a control-plane datastore in the revised datastore
   model described here.

The other issue I have is with that control-plane data stores are shown connected to applied and operational-state. Which control plane data stores are directly influencing operational-state? 

Also, in the diagram control-plane protocols are connected only to operational-state data store. But isn’t the previous state exchanged via control plane protocols taken into account when validating data that is copied into applied data store?

Thx

Dean

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 15 Dec 2016 16:24:40 +0100 (CET)

Hi,

Dean Bogdanovic <[email-masked]> wrote:
> This data can come from several sources; from <intended>, from dynamic
> configuration protocols (e.g., DHCP), or from control-plane datastore.
> 
> The other issue I have is with that control-plane data stores are
> shown connected to applied and operational-state. Which control plane
> data stores are directly influencing operational-state?

We wanted to allow for other to-be-defined data stores by showing
where they can fit into the architecture.  When/if such a data store
is defined, it can relate to this architecture and explain exactly how
it fits in and how it affects applied config and/or operational state.

> Also, in the diagram control-plane protocols are connected only to
> operational-state data store. But isn’t the previous state exchanged
> via control plane protocols taken into account when validating data
> that is copied into applied data store?

When you say "data that is copied into applied", are you referring to
the arrow between intended and applied?

The answer is that the arrows show data flow.  The mechanism that
copies data from intended to applied will surely have to check
operational state and maybe physical resources in roder to do its job.

/martin

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 15 Dec 2016 15:11:22 -0500

> On Dec 15, 2016, at 10:24 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 
> Dean Bogdanovic <[email-masked] <mailto:[email-masked]>> wrote:
>> Authors,
>> 

Yes, correct
> operational state and maybe physical resources in roder to do its job.

But from the same diagram, it states that control protocols are not impacting applied data store, except the operational state. This is something I have to wrap my mind around it, as when the applied state is computed, it is taking into account data exchanged via control protocols.

Dean