Hi James, First off, it’s really important to remember that NETCONF and YANG are just tools - they don’t make up a whole NMS, which is what I think you are trying to describe. YANG is a data modelling language that defines the schema for data of a device’s management plane; and NETCONF is one of the protocols that defines a set of RPCs to be able to interact with a device.
NETCONF defines a set of RPCs such as ‘get’, ‘get-config’, ‘edit-config’... These allow parts of the schema to be retrieved or edited. There are various efforts to define YANG models - some which are vendor-specific, and some which are intended to be vendor neutral. On 22 September 2015 at 16:49:59, James Bensley (jwbens...@gmail.com) wrote: > > With all that in mind, only the “Apply the proposed config” part > actually falls under the remit of NETCONF and YANG (as per the > functionality defined in the existing RFCs). Does anyone know if there > is any scope to extend NETCONF/YANG to include reading stats such as > number of routes received from a specified BGP peer, CPU usage, memory > usage, FIB usage, and so on, everything we are probably getting via > SNMP? [2] NETCONF does not define any RPCs to be able to do all of the things that you mention, but yes, it can definitely be used to retrieve operational state data. YANG includes a ‘config false’ statement that can be used on leaves to show they are state data. The YANG models that OpenConfig has defined aim to align state and configuration within the schema (see draft-openconfig-netmod-opstate), such that it is simple operationally to be able to distinguish various types of op-state (e.g., derived state, which refers to the counters and state information derived from protocol interactions, and the applied state - which shows the configuration that the device has ingested). We have suggested additional RPCs within supporting protocols that allow retrieval of *just* state information (e.g., get-operational defined in the above draft). The existing OpenConfig models already add leaves for some of the values you mention: https://github.com/YangModels/yang/tree/master/experimental/openconfig In parallel with the work that is related to having the schema store the state information (which could be polled by NETCONF/RESTCONF/...), OpenConfig is also considering how one can subscribe to certain parts of the schema, such that there is no need to poll particular information - and rather a real-time element of the NMS can collect the information sent to it directly from a device. Compiling this into the same YANG-defined schema, then allows an NMS (or applications that interact with the NMS) to be able to work with that data to implement pre-check, post-check etc. mechanisms. If you are interested in this, check out the talks that Anees Shaikh and Josh George have given at NANOG on what Google are working on in this area. The way I would think of it is this: NETCONF/RESTCONF will help with the application of configuration changes onto a device (pushing config); and polling some information. The streamed telemetry protocols are somewhat more in their infancy, so at the current time, you may need to glue existing data sources back into a schema - but these will help with populating your view of the state more efficiently than existing polled mechanisms. The OpenConfig models provide a set of models that can be used to have an operationally-useful way to be able to represent the two config and state together. The thing that glues it all together and lets you define your pre-/post- checks is the overall NMS software. A bunch of folks are working on systems in this area. > What are others doing here to keep the whole process sane? The way that our system is currently working is that we have a split between data collection and configuration management elements. The query infrastructure can be used to combine the two into the single OpenConfig schema (and other schemas that we are defining that abstract the configuration from clients). The NMS layer provides the entire life-cycle that you mention: pre-check, apply-change, post-check, on-demand checks and some other things. Our system provides means to be able to define these functions that do this as part of the network design. Parts of it are open source (e.g., the code that generates Python bindings for YANG data models - http://github.com/robshakir/pyangbind, or in your own system you could use an alternative that Google have written for Go - http://github.com/openconfig/goyang), other parts are not. Unfortunately, the NETCONF support that is on existing devices is not great - but we’re seeing both vendor-specific models, and vendor-neutral models start to become supported. Juniper have publicly spoken about their aims to implement OpenConfig - and other vendors are also working on implementations. To address the comment about having been able to do things with expect, the advantages of doing this with YANG models (particularly OpenConfig) and a protocol of your choice that can interact with the device directly is that you get: * a declarative API: the network element determines how to get from state A to state B, rather than the imperative nature of the CLI. * a schema that is understood by both the client and the NMS for both config and state: where screen-scraping, there is no contract, and everything may change and break your tools - then if the data model is described in YANG, then you can be clear what to expect for various values. * a combined way to relate configuration data and state: so it is not a case of knowing that a certain neighbour corresponds to some particular show commands, or an SNMP OID, but rather the schema follows conventions such that these can be easily determined. I’m happy to talk more about OpenConfig; or some of the work that we’ve been doing in this area. We need to take steps forward with the management plane. The current status-quo is simply unacceptable in terms of the speed/complexity of interacting with the network. r.
