Subject: Re: [netmod] review of draft-openconfig-netmod-opstate-01

From: Rob Shakir <[email-masked]>
Date: Thu, 3 Sep 2015 10:05:59 -0400

Kent,

Apologies, I missed this email. If I can respond to a limited section of it.

On August 24, 2015 at 22:14:47, Kent Watsen ([email-masked]) wrote:
>  
> And yet again in Section 2, Figure 1 and text just below it don't square up. The applied  
> config is shown as having the same leaves as the intended config, and is listed below the  
> line marked config: false. Also, the text says "Only derived state is marked as operational  
> data" and while I also see "operational:true" in Figure 1, this is a forward reference  
> to Section 9.1, which is confusing. Attached is a picture illustrating my view on this. 

I don’t agree with this diagram. The applied configuration is essentially the current running state of the hardware. It cannot be directly changed by a user, and hence it needs to be read-only and hence config false.

operational: true is used to represent op-state that does not correspond to any configuration (neither applied, nor intended), but represent parameters that are related to protocol interactions, counters, etc. This again is read-only.

> Also in Section 2, the end of the 6th paragraph states "To this end, operational state 
> information can be considered to be 'unknown' to the network manager." - what does this mean?
>   - isn't it just a matter of the NMS polling on this YANG-modeled data?

Consider a system that has a single NMS that talks to all elements, and it is the *only* means of managing those elements. In general, that NMS knows what the state of the intended config is (it wrote it), if the system is synchronous then it also knows the state of the applied config. Therefore if it is polling, it is likely to want to only get the derived state data, which can be filtered on operational true. The intention of these statements is to impress the need on the reader to have a mechanism to poll only this data efficiently (if this is, indeed, to be polled).

r.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 03 Sep 2015 16:26:11 +0200 (CEST)

Rob Shakir <[email-masked]> wrote:
> I don’t agree with this diagram. The applied configuration is
> essentially the current running state of the hardware. It cannot be
> directly changed by a user, and hence it needs to be read-only

Agreed.

> and hence config false.

Not necessarily.  In the solution we propose (see
draft-kwatsen-netmod-opstate) the applied config datastore is read
only.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 3 Sep 2015 14:37:39 +0000

[as a contributor]

Hi Rob,

>I don¹t agree with this diagram. The applied configuration is essentially
>the current running state of the hardware. It cannot be directly changed
>by a user, and hence it needs to be read-only and hence config false.

Agreed that the applied config is read-only, but that doesn't mean the
data tree has to be config false.  For instance, in the draft submitted
yesterday, this requirement is achieved by defining a read-only datastore.

>operational: true is used to represent op-state that does not correspond
>to any configuration (neither applied, nor intended), but represent
>parameters that are related to protocol interactions, counters, etc. This
>again is read-only.

I'm unclear with the difference, how is it different than data modeled
config false?

>>Consider a system that has a single NMS that talks to all elements, and
>>it is the *only* means of managing those elements. In general, that NMS
>>knows what the state of the intended config is (it wrote it), if the
>>system is synchronous then it also knows the state of the applied
>>config. Therefore if it is polling, it is likely to want to only get the
>>derived state data, which can be filtered on operational true. The
>>intention of these statements is to impress the need on the reader to
>>have a mechanism to poll only this data efficiently (if this is, indeed,
>>to be polled).

Okay, but there are other ways to enable a client to poll just the derived
state (config false nodes).  For instance, the draft posted yesterday
introduces a <get-state> operation to do this.

K.