Going in a slightly different direction with a change subject line. Tom Petch
----- Original Message ----- From: "Jeffrey Haas" <[email protected]> To: "Martin Bjorklund" <[email protected]> Cc: <[email protected]>; <[email protected]>; <[email protected]> Sent: Thursday, May 01, 2014 1:24 AM > 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. Jeff If I2RS updates the routing table, do we expect it to persist for any length of time? That is, the routing table is stable, the result of the convergence of the routing protocols (and configuration) across the relevant routers in the routing system and is reflected in the operational state of a router. A stable system in engineering is one that when perturbs, returns to its original state. So make a change in one router and I would expect the rest of the system to gang up on that router and reinstate the status quo. For example, what I have in Adj-RIB-Out comes from someone else via Adj-RIB-In and if I change Adj-RIB-Out, then sooner or later I will refresh it from Adj-RIB-In and be back where I started, while if I change Adj-RIB-In, then the other router will repeat its advertisement - and I will be back where I started. If I think of the changes I might want to make, it seems to me that they have to be changes to what NETCONF/YANG refer to as config and not to the operational state. Ephemeral or persistent, which I take to refer to what happens after a reboot, is then a question of which NETCONF datastore I update, running or startup or both. Tom Petch > > 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
