On Thu, Apr 24, 2014 at 01:12:44PM +0200, Martin Bjorklund wrote: > > 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.
As I try to work through my reading of netconf and yang, the use case we're discussing here is the one that troubles me the most. Let me pick two specific examples of injecting i2rs state on top of something that may have coverage within existing yang configuration models: static routes and BGP. It would be very convenient for purposes of configuring static routes in i2rs where the semantic is ephemeral configuration to not have to duplicate the existing yang model. If the model in question was design to use groupings, it appears that it would be easy to have one instance for normal configuration and a second one specifically for i2rs. It would be even more convenient if we had a semantic that was not only "config true", but potentially "config true|ephemeral". The issues then comes back to the ones noted in draft-bjorklund-netmod-operational-00: How do we distinguish operational, config or ephemeral config states? When there are different precedences (ephemeral overrides static, e.g.), how could you do a get that presents the implemented order? The BGP example to my mind may only go slightly further than this. For some types of i2rs configuration state, I can foresee wanting some portion of it to be based upon non-ephemeral configuration - for example base BGP state that should not be modified by i2rs. Presuming that base state exists, it may be desirable to permit something like BGP peer configuration to re-use the existing BGP yang model for configuration, just in an ephemeral context. Thus, some portions of the configuration are instantiated ephemerally and some require underlying non-i2rs config. > I don't think a separate structure for i2rs routes are needed, b/c it > is supposed to directly modify the operational state. This is where I think we're getting stuck. There is some vagueness between operational state that can be modified and ephemeral configuration. But the real issue is when multiple forms exist, how do we operate upon it/see it in a useful fashion? -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
