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
See also Lada's reply. What kind of correlation are you looking for? The point is that these are *different* structures, with different semantics. If an entry exists in the operational state, it doesn't imply there is a corresponding entry in the config, and vice versa. And just b/c a config entry also exists in operational state doesn't mean that it is *exactly* as configured; some other dynamic mechanism might have changed it. It all depends on what you model. > - 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)? I don't think a separate structure for i2rs routes are needed, b/c it is supposed to directly modify the operational state. Also, I don't think this is a YANG-specific issue; any modelling language can model one, two or three separate structures. If we put the configuration part aside, you still have to decide if you need one or two (or N) structures for "i2rs" state and "complete" state. > 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? Sure, just like might want to get the routes from bgp or some other protocol. /martin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
