On 24 Apr 2014, at 11:17, t.petch <[email protected]> wrote: > ----- Original Message ----- > From: "Martin Bjorklund" <[email protected]> > To: <[email protected]> > Cc: <[email protected]>; <[email protected]> > Sent: Wednesday, April 23, 2014 6:08 PM >> t.petch <[email protected]> wrote: >> > <snip> >>> In practice, this means that the YANG model comes in twin sets, one > of >>> read-write configuration and one of read-only not-configuration (as > can >>> be seen in the current I-Ds that the netmod WG is producing) >> >> Correct. This reflects how it usually works on devices; most routers >> and similar equipment has a "config mode CLI" and "show commands"; a >> linux box has config files and various ways of reading and writing >> operational state (/proc, direct apis...) These are different >> structures with different syntax and semantics. >> >> (SNMP tried to combine the two into one, but this turned out to be >> problematic.) >> >>> with no >>> formal way in YANG of relating the one to the other. So if you want >>> e.g. the routing table, the host software has to know where to look > and >>> how to combine the pieces to produce a coherent picture (and then > you >>> cannot edit most of it). > > I see this lack of combination as a separate issue. > > When the interest is in configuration, then the focus is on 'config > true' and anything else - state - can be ignored; NETCONF provides > get-config, edit-config etc which does just that. NETCONF did not have > to provide this - it could have used filtering to filter out the 'config > true' - but I do not think that that would have been viable. > > I2RS will have an interest in (some of) 'config true' and some of the > state - e.g. routing table entries learnt by BGP but not, at least in > some use cases, the read-only statistics. The models have two separate > schema trees for 'config true' and state, as > > http://www.ietf.org/id/draft-ietf-netmod-routing-cfg-13.txt > > Figure 1 and Figure 2 show. What YANG does not have is a way of > correlating the two trees - rather, each data model has to craft its > own, such as look for value 'mm' in both object X in one list and object > Y in another list and assume that they refer to matching entries of the > lists.
We tried to address this duality in this draft (now expired): http://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 The result was, at least in my view, less than satisfactory. There certainly is a correlation between configuration and state data but it can be tight or loose depending on at least the following two factors: - The amount of processing done by the configuration system. For example, it can turn high-level configuration into corresponding low-level settings in the device. - Often there are other factors beside configuration (e.g. network protocols) that influence the final result. So we eventually came to the conclusion that configuration and state data are in general independent, and separate trees were introduced - not only in the routing-cfg draft. Lada > > Splitting state into two, operational and the rest, with an > i2rs:edit-data for the former, does nothing to help with this - it could > make things more complex. > > We now have a three way split - do we now have three separate trees (if > not, why not)? How do we get the i2rs:edit-data? Do we use filters to > separate out the i2rs:edit-data, like a NETCONF get were get-config not > to exist? Or do we need an i2rs:get-edit-data, except that that still > leaves the issue of correlation, so do we need some help from YANG for > that? Do we need a i2rs:get-i2rs that spans 'config true' and > i2rs:edit-data? Or do we make everything of interest to I2RS > i2rs:edit-data and scrap 'config true' as far as I2RS is concerned? > > Most things are possible with YANG and NETCONF, but it will take time to > work out the details; perhaps we will end up changing some of the tenets > of RFC6020. Knowing how long operational state has been a topic on the > netmod WG list, will we still be working out the details of this in a > year's time? > > Tom Petch > > p.s. if only draft-ietf-i2rs-rib-info-model were updated to use YANG, > with or without i2rs:edit-data, so as to make this concrete? > >>> >>> So if I2RS never wants to write anything to a router, YANG is fine; > if >>> I2RS is only producing a Information Model (and ignoring whether or > not >>> data is read-only or read-write), and not moving on to an >>> implementation, then YANG is fine. >>> >>> Rather, as Andy Bierman said at IETF89, likely I2RS would need an >>> extension to YANG, a new sub-statement for all data objects, > semantics >>> not too clear but designed to separate out the not-configuration, > learnt >>> via a protocol, 'editable-state' (and in doing so, making it >>> read-write - but still 'config false'). >>> >>> Yes, YANG allows for such extensions but it seems to me that I2RS > would >>> then be getting YANG++ (and NETCONF++), once the necessary work has > been >>> done. >> >> You can call it YANG++ and NETCONF++, but the fact is that these >> things can be done today, without having to revise the YANG or NETCONF >> specs, by using the current extensibility mechanisms. >> >> >> /martin >> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
