Inline: > On Sep 10, 2015, at 11:46 AM, Ladislav Lhotka <[email protected]> wrote: > > Hi, > > comments inline. > > Benoit Claise <[email protected]> writes: > >> Dear all, >> >> The YANG coordination team >> <http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html> >> has >> spent some time reading and gathering input on the requirements and >> proposed solutions in draft-openconfig-netmod-opstate. This note is to >> collect some observations that will hopefully contribute to progress in >> the working group. >> >> We believe it is useful to consider that YANG was initially designed to >> be a data modeling language for the NETCONF protocol. IETF is also >> working on RESTCONF which is an HTTP-based protocol to access data >> defined in YANG, using the datastores defined in NETCONF. >> >> YANG is fulfilling its intended role with NETCONF and RESTCONF and has >> gained some significant traction in this capacity. There are some >> changes worked on in YANG 1.1, but they are mostly incremental. >> >> There is interest in using other protocols outside of NETCONF and >> RESTCONF to manipulate data described by YANG. The proposals in the >> draft is based on the assertion that YANG models should be usable for >> protocols beyond RESTCONF and NETCONF. So these are new requirements on >> YANG from, or in preparation for, new protocol bindings. >> >> We have focused on two main aspects of the draft. >> >> FIRSTLY: The proposed split between intended and applied configuration >> as described in sections 4.1 (requirements) and 5.1 (implications) >> >> There are two observations here: >> 1. The implication is that all configurable data nodes ("intended >> configuration") shall be repeated in an operational version ("applied >> configuration") in all models for all applications going forward. This >> would apply independent of if the system is synchronous or asynchronous >> in nature. Synchronous systems would simply hard-wire the applied >> configuration to be the same as intended configuration at all times. >> 2. An informal round of conversations with some vendors as well as some >> tooling vendors show that there are currently no widely known platforms >> that allow for observing the intended and applied state separately. A >> common architecture includes a central configuration data store that is >> being updated by the manageability framework and updates read by the >> subsystems affected by the change (e.g. the BGP service or the interface >> manager). In this case, there is no other source of configuration except >> for the content of the data store. > > It may be because vendors tend to limit user access to the device > configuration to a few official interfaces.
Agreed, a strong requirement for most of these systems is to provide coherent views of configuration and state through a set of protocols (normally CLI, SNMP and NETCONF). And since the application-level environment in theses systems are usually very heterogenous (various userland and kernel subsystems, some based on open source, some proprietary), it is hard to avoid a registry-style approach with integration interfaces for various types of applications. > In contrast, consider for example a typical Linux system. No matter what > "official" configuration system is used (init scripts, NetworkManager, > UCI in OpenWRT, even NETCONF), there is always a way to change the > run-time configuration without the official configuration system being > notified. For instance, one can go to the /proc filesystem and change > many kernel parameters on the fly, such as IP addresses assigned to > interfaces. > > Since I am mainly interested in such open systems, I do see a use case > for making the distinction between intended and applied > configuration. And by the way, it might help solve the NETCONF/I2RS > dilemma: NETCONF/RESTCONF would only be allowed to modify intended > configuration whereas I2RS would operate exclusively on applied > configuration. I think the issue at hand here is that the suggested changes require that all (intended) configuration parameters always have corresponding (applied) values. This will actually make a little interesting for open (or perhaps more loosely coupled) systems like the one you mention above. For every (intended) configuration parameter you model, you need to come up with a way to read back the applied configuration. Now, think about configuration parameters that have applied configuration located in more than one place. Let’s say you change the IP address of an interface, it is likely that this configuration will be passed around as input to a handful of subsystems (e.g. the DHCP server, some routing daemons that may bind to specific IP addresses). Is the intended and applied in sync when a specific subset of those configurations are updated. What happens if there’s a partial failure? > Finally, most existing NETMOD models in fact already have intended and > applied configuration even if they aren't called so: the applied one is > represented by nodes in *-state trees that are duplicates of > configuration entries. Yes, but do we want to enforce this for all models for all applications? >> >> Please note that this was not an exhaustive collection of data, but >> should give some directional information. >> >> The *implication* we would like to make here is that by making this >> feature mandatory part of the YANG language itself (as opposed to an >> optional capability) we risk introducing a fake perception that the >> current NETCONF server supports a capability it can't support. Indeed, >> polling the applied configuration would always return the intended >> configuration. >> >> A *question* would be if it would be useful to consider a direction >> where we make an attempt to separate out requirements that are tied to >> specific protocols and solve them in the protocol semantics rather than >> in the language to the extent we can. Without knowing more about the >> intended protocol in the case of this draft, it is hard to make more >> progress. >> >> A *suggestion* is to ask the draft authors to document the protocol >> bindings in order to qualify the requirements going forward. >> >> SECONDLY: The proposed schema locations for configuration and >> corresponding operational state in sections 4.5 (requirements) and 5.4 >> (implications) >> >> The observation to be made here is well captured in the draft itself as >> bullet 3 under section 7: >> >> "The proposal does not allow items that are not configured, >> configured but not present, or system configured." >> >> Please note that this is a general note that would apply to the language >> itself. Meaning that YANG will no longer be able to describe situations >> like the above for any type of application in any context. >> >> Examples beyond what's already mentioned in the bullet of this could >> include: >> - Removable physical assets (line cards, mezzanine cards) in systems >> that allow pre-provisioning of configuration >> - Physical assets that arrive in the system with readable default >> state > > I agree, existing NETMOD modules already support pre-provisioning and > system-controlled components. > > Lada > >> >> Independent of the direction we will be taking going forward, the >> implication we make is that it is a pretty significant impact on the >> expressivity of the language itself and how useful it is in terms of >> modeling application data sets that may not align with the requirements. >> >> The question we would ask is if it would be possible to rebalance the >> implication and make it a little more modular and optional in the >> language. We are aware of suggestions to use the extensibility of the >> language itself (e.g. in draft-kwatsen-netmod-opstate) to express >> relations across data sets. Understanding that this suggested approach >> does not normalize the paths according to the wish of the authors, but >> it can perhaps be a balanced approach that impacts the expressivity less. >> >> Regards, the YANG coordination team >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
