Subject: [netmod] posted: draft-kwatsen-netmod-opstate-00

From: Kent Watsen <[email-masked]>
Date: Thu, 3 Sep 2015 00:23:34 +0000

For next week's interim meeting, but feel free to post comments before
then  ;)

Cheers,
Kent

On 9/2/15, 7:55 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-kwatsen-netmod-opstate-00.txt
>has been successfully submitted by Kent Watsen and posted to the
>IETF repository.
>
>Name:		draft-kwatsen-netmod-opstate
>Revision:	00
>Title:		Operational State Enhancements for YANG, NETCONF, and RESTCONF
>Document date:	2015-09-02
>Group:		Individual Submission
>Pages:		12
>URL:            
>https://www.ietf.org/internet-drafts/draft-kwatsen-netmod-opstate-00.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
>Htmlized:       
>https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-00
>
>
>Abstract:
>   This document presents enhancements to YANG, NETCONF, and RESTCONF to
>   better support the definition of and access to operational state
>   data.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 10 Sep 2015 11:47:47 +0100

Hi Kent,

I've a few comments on draft-kwatsen-netmod-opstate-00:

1) Having a related-state statement seems to be a good solution for 
binding oper nodes to config nodes that are not directly related in the 
data tree.

But I note that the binding is attached to the config node.  I had 
incorrectly read/assumed that the binding would be attached to the 
operational node referring back to the config node.

A couple of potential advantages of attaching the binding on the oper 
node instead of the config node may be:
  - There may be cases where many oper nodes depend on a few config 
nodes (e.g. lots of oper nodes could choose to depend on the IP address 
configured on an interface), so spreading out the related-state 
statements may be beneficial.
- I think that it is more likely that oper nodes will be in other 
modules that depend on, or augment, a module with the dependent config 
node.  Obviously the related-state binding can't be written directly 
inline on the config node because the module dependency would be the 
wrong way round.  This could be achieved by augmenting the config node 
with a related-state statement, but this would seem to be less clear and 
more verbose than putting the related-state statement on the oper node 
itself.

2) <get-state> Operation.
Yes, I agree that this is a good addition to NETCONF.

3) The Applied Configuration Capability:
Using a separate datastore to differentiate between intended and applied 
cfg seems like an OK solution to me.

But for a separate datastore solution, it would feel more natural (at 
least to me) to put the intended-cfg in a separate datastore, and having 
the applied-cfg and derived-state in the default running datastore.

My reasoning for this is that logically the flow of config information 
through the system is:
[ (A) candidate cfg ] -> (B) intended cfg -> (C) applied cfg -> (D) 
derived state.

Hence, it seems strange to me that (A - candidate) and (C - applied) 
would each be in separate datastores but (B - intended) and (D - 
derived) are together in the running datastore.

I can appreciate that there may be some issues with making (B - 
intended) a separate datastore (i.e. what does an edit-config request 
mean on the running datastore?), but I think that it has the advantage 
that a <get> request on the running datastore would return the contents 
of (C - applied) and (D - derived) which is arguably more generally 
useful to an NMS dealing with an async system that presumably already 
knows the contents of (B - intended).

Cheers,
Rob

On 03/09/2015 01:23, Kent Watsen wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Sep 2015 13:02:01 +0200 (CEST)

Robert Wilton <[email-masked]> wrote:
> binding oper nodes to config nodes that are not directly related in
> the data tree.
> 

We discussed this as well.  We interpreted the requirement from
openconfig to be from config to state though.  Maybe it would be
useful to have both 'related-state' and 'related-config'.

> A couple of potential advantages of attaching the binding on the
> oper node instead of the config node may be:
>
>    nodes (e.g. lots of oper nodes could choose to depend on the IP
>    address configured on an interface), so spreading out the
>    related-state statements may be beneficial. 
>
>   modules that depend on, or augment, a module with the dependent
>   config node.  Obviously the related-state binding can't be written
>   directly inline on the config node because the module dependency
>   would be the wrong way round.  This could be achieved by augmenting
>   the config node with a related-state statement, but this would seem
>   to be less clear and more verbose than putting the related-state
>   statement on the oper node itself. 
> 
> 
> Using a separate datastore to differentiate between intended and
> applied cfg seems like an OK solution to me. 
> 
> But for a separate datastore solution, it would feel more natural
> (at least to me) to put the intended-cfg in a separate datastore,
> and having the applied-cfg and derived-state in the default running
> datastore. 

But running is (sometimes) writable, whereas applied config is always
read-only.

I rather map intended to running, and then define new protocol
operations so that the client can retrieve the necessary data properly
(essentially making current <get> less useful).

/martin

> My reasoning for this is that logically the flow of config information through the system is:
> intended) a separate datastore (i.e. what does an edit-config
> request mean on the running datastore?), but I think that it has the
> advantage that a <get> request on the running datastore would return
> the contents of (C - applied) and (D - derived) which is arguably
> more generally useful to an NMS dealing with an async system that
> presumably already knows the contents of (B - intended).
> 
> Cheers,
> Rob
> 
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 10 Sep 2015 13:59:09 +0100

Hi Martin,

> openconfig to be from config to state though.  Maybe it would be
I just see it as a logical relationship between a config node and an 
oper node.  Even if the direction that the relationship may be used is 
from a config node to the set of possibly impacted oper nodes, the 
relationship could presumably still be specified in the reverse 
direction if that made more sense.

But I actually think that the relationship could be useful in both 
directions, e.g.
1) When updating a config node, being able to subsequently fetch/monitor 
the set of oper nodes that may be impacted to ensure that the change had 
the desired effect.
2) If the NMS detects (or is notified) that an operational node has 
changed (potentially unexpected) to be able to know the set of config 
nodes that could impact that operational node.

> But running is (sometimes) writable, whereas applied config is always
Yes.  I think that the expectation would be:
  - if the server supports an intended-cfg datastore then clients should 
write to that one.
  - for backwards compatibility only, if a client attempts to write 
config to the running datastore, the config request would be routed to 
the intended-cfg datastore instead.

> (essentially making current <get> less useful).
Do you mean operations like allowing data to be fetching from multiple 
datastores in one request and merging the trees together in the 
response?  Or something else?

Thanks,
Rob

> .

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Sep 2015 13:12:47 +0000

>From a system processing perspective, I'm unsure it matters, in that every
forward pointer implies a reverse pointer.   From a readability
perspective, I think "related-state" makes more sense, as in config begets
state, but am open to a "related-config" statement if it helps.

>>   statement on the oper node itself.

Maybe so. If we pursue this direction, we should exercise these ideas to
ensure the solution we pick withstands these concerns.

>> Yes, I agree that this is a good addition to NETCONF.

A loooong overdo addition  ;)

>> presumably already knows the contents of (B - intended).

This gets into the ill-defined YANG meta-model, a simple version of which
is provided in Section 3 (Conception Model) and a more complex version is
attached.   In my mind, it is tempting to define something like a
"distinct-intended" capability that would provide read-only access to the
"intended" datastore, so that the combined effects of
running+ephemeral+future-whatever can be observed.

Kent