----- 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. 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
