Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01
On Tue, Aug 11, 2015 at 12:12 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Fri, Aug 07, 2015 at 03:21:48PM -0400, Rob Shakir wrote: Juergen Schoenwaelder wrote: But you are right, it is not just the path that is needed to identify data residing in configuration datastores. It is in general a tuple selector, path and for configuration data the selector is a configuration datastore name. Thanks for the clarification. Do you have examples of other (i.e., non-NETCONF) systems that utilise this convention that a path is not an absolute reference to a certain data node? Reviewing with various interested parties, I'm not sure that there are clear cases that form a precedent for this. SNMP has an even more complex naming scheme. If we consider that this then might drive some new behaviour where the systems architecture for NMS differs from elsewhere then we might want to question whether this is necessary complexity. Indeed, for me this comes back to one of the discussions about the other datastores that we had on an interim call. * 'startup' is really a property of the intended configuration - as to whether it has been made persistent. In general, I see very few changes that are made where we interact only with the persistent version of the intended configuration; and even fewer where the intended configuration is not made persistent. In both cases, it tends to be the lack of a declarative configuration API that drives the need to interact with either. You can have a NETCONF server without 'startup' and it still has persistent running config. I have no clue what 'the lack of a declarative configuration API' means. The startup datastore simply represents the config that will be used at the next reboot. It is useful to compare the running config to candidate or startup. * 'candidate' is again a property of the intended configuration - insofar that the 'candidate' set of configuration represents a set of changes that have not been requested to be transitioned to the 'applied configuration'. This makes sense when a human is working through building up a transaction (configure protocol X, protocol Y .. protocol Z, then commit) - but isn't quite so clear when it programmatic interaction with the network. There are commercial implementations that make use of candidate datastores and the transaction, validation and rollback capabilities they provide. You may decide that you do not need them but this does not imply that nobody else will need them. RFC 6241 should be clear that the candidate is a scratchpad. It has no effect on the system unless and until a commit is attempted. Since NETCONF (incorrectly) couples the confirmed commit procedure with the candidate config, it is useful to programmatic APIs. In reality, confirmed commit has absolutely nothing to do with candidate, but there seems to be no interest in fixing that. It is quite trivial for me to see cases where an external NMS would never really need to interact with either of these datastores - such that it's quite tricky for me to determine that we really want to architect the entire NMS to be able to carry the selector,path tuple (stealing your terms, thanks!), especially if this means that it has to work entirely differently w.r.t paths than the rest of OSS. It is certainly up to you how you architect your NMS the way to think it works best. I am just trying to explain how NETCONF and YANG work. But I would expect that an NMS is able to integrate namespaces. We should not dumb-down the standard to support dumb NMS software. Datastores and namespaces are part of the standard. Neither are difficult to implement. The selector, path approach allows us to use the same path in different datastores, this is considered to be a feature and not a bug. /js Andy -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01
Hi, Rob Shakir r...@rob.sh wrote: Juergen Schoenwaelder wrote: But you are right, it is not just the path that is needed to identify data residing in configuration datastores. It is in general a tuple selector, path and for configuration data the selector is a configuration datastore name. Thanks for the clarification. Do you have examples of other (i.e., non-NETCONF) systems that utilise this convention that a path is not an absolute reference to a certain data node? Reviewing with various interested parties, I'm not sure that there are clear cases that form a precedent for this. One example is SNMP, where a tuple (enginge id, context, OID) is needed. In general you also need a device id of some sort (address, port). How the necessary info is handled seems to be an implementation detail, and it seems to be pretty trivial, but maybe I have misunderstood something. If we consider that this then might drive some new behaviour where the systems architecture for NMS differs from elsewhere then we might want to question whether this is necessary complexity. Indeed, for me this comes back to one of the discussions about the other datastores that we had on an interim call. * 'startup' is really a property of the intended configuration - as to whether it has been made persistent. In general, I see very few changes that are made where we interact only with the persistent version of the intended configuration; and even fewer where the intended configuration is not made persistent. In both cases, it tends to be the lack of a declarative configuration API that drives the need to interact with either. I do not understand this comment. Are you proposing some kind of changes to current YANG models to handle 'startup'? Are you proposing changing NETCONF? * 'candidate' is again a property of the intended configuration - insofar that the 'candidate' set of configuration represents a set of changes that have not been requested to be transitioned to the 'applied configuration'. This makes sense when a human is working through building up a transaction (configure protocol X, protocol Y .. protocol Z, then commit) - but isn't quite so clear when it programmatic interaction with the network. If I understand your terms correctly, 'running' would be the intended configuration. 'candidate' is a separate structure, that is not part of the intended configuration. Are you proposing some YANG or NETCONF changes to handle the candidate? It is quite trivial for me to see cases where an external NMS would never really need to interact with either of these datastores - such that it's quite tricky for me to determine that we really want to architect the entire NMS to be able to carry the selector,path tuple (stealing your terms, thanks!), especially if this means that it has to work entirely differently w.r.t paths than the rest of OSS. Even if we had the four separate datastores 'startup', 'running', 'candidate', and 'applied', it is not entirely clear to me why the datastore would have to be carried together with the path internally all the time. (We do not carry the current datastores in our system today). Maybe this is an implementation issue? /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01
Martin, To be clear -- I'm not proposing any changes to YANG or NETCONF. I was merely trying to write down the discussion that we had on one of the interims about ways that 'datastores' may be considered by some implementations, particularly as this view can mean that they might be able to ignore them - based on the current ones that are implemented. Martin Bjorklund wrote: Even if we had the four separate datastores 'startup', 'running', 'candidate', and 'applied', it is not entirely clear to me why the datastore would have to be carried together with the path internally all the time. (We do not carry the current datastores in our system today). Maybe this is an implementation issue? Sure, it does not have to be carried all the time, but is /is/ required in some cases. If one wants a standardised 'path' format to be passed between systems then there's going to need to be space for the 'datastore' to be carried in path references that are handed about (even if there is a 'default' datastore). I, for one, would find it messy if there needs to be context specific ways of handling what a path looks like. I find the fact that there can be ambiguity for a certain path something that is quite different from all other systems, and hence consider it to be suboptimal when compared to having a unique path to a particular set of data. Having a path that can result in different values being returned seems fragile. Best, r. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] draft-openconfig-netmod-opstate: Changes in -01
Hi netmod folks, Prior to the Prague IETF, Anees, Marcus and I took some time to update draft-openconfig-netmod-opstate. The intent of this update was two-fold: * to provide clarifications of the types of data that we consider to exist within a YANG module. This very much reflects the discussions that we had both on the interim meeting calls, and subsequently on the list. We aimed to document the terms 'intended configuration', 'applied configuration' and 'derived state', and record the relationship between them that we'd iterated on. o This is contained in Section 2. We would encourage interested parties to review these definitions to ensure that the common understanding that we reached has been documented. * add some clarifications to the requirements based on alternative suggestions that had been briefly mentioned during the interims. Particularly, it is worth mentioning: o Section 4.5: we added some clarification about paths within some of the NMS systems that we are working on. o Section 7: which is dedicated to covering some of the observations that have been made relating to the proposed solution. We (the authors) have tried to provide some feedback to some of these points (where it has been possible to do so). The diff for this revision can be found at https://tools.ietf.org/rfcdiff?url2=draft-openconfig-netmod-opstate-01.txt - Appendix D provides a brief changelog. Kind regards, r. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01
On Fri, Aug 07, 2015 at 10:40:06AM -0400, Rob Shakir wrote: Juergen Schoenwaelder wrote: I assume you meandatastore, path instead ofRPC-call, path. /js Hi Juergen, Generically, the intent here is express that it is 'some-access-method, path' rather than merely 'path'. The 'some-access-method' might be a reference to a particular datastore, or a certain operation within the access protocol (GET vs. GET-OPER maybe). Configuration data resides in configuration datastores. This is quite deeply wired in the NETCONF and YANG specifications. For operations on the configuration datastores, the datastore name is passed as an argument in RPC calls. Hence, for configuration data, the naming model is datastore, path. There have been many discussions over the years whether there should be an explicitly named operational datastore since architecturally we treat operational data somewhat differently. Some of this is hinted at in section 4.3.3 of RFC 6244 and you can find also various I-Ds that were posted in this context. But you are right, it is not just the path that is needed to identify data residing in configuration datastores. It is in general a tuple selector, path and for configuration data the selector is a configuration datastore name. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] draft-openconfig-netmod-opstate: Changes in -01
Juergen Schoenwaelder wrote: I assume you meandatastore, path instead ofRPC-call, path. /js Hi Juergen, Generically, the intent here is express that it is 'some-access-method, path' rather than merely 'path'. The 'some-access-method' might be a reference to a particular datastore, or a certain operation within the access protocol (GET vs. GET-OPER maybe). Thanks, r. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
