----- Original Message ----- From: "Jeffrey Haas" <[email protected]> To: "t.petch" <[email protected]> Cc: "Jeffrey Haas" <[email protected]>; <[email protected]> Sent: Tuesday, June 10, 2014 7:07 PM > Tom, > > [retaining lots of content for context]
now elided as it is not so much about references to extracts of the architecture I-D > On Tue, Jun 10, 2014 at 04:25:53PM +0100, t.petch wrote: > > ---- Original Message ----- > > From: "Jeffrey Haas" <[email protected]> > > To: "t.petch" <[email protected]> > > Cc: "Jeffrey Haas" <[email protected]>; <[email protected]> > > Sent: Tuesday, June 10, 2014 2:41 PM > > > > > Tom, > > > <snip> > > This is much of what I had suggested about the semantics of introducing > ephemeral config into netconf. Our requirement is that these things are > ephemeral. (Although Tom Nadeau presents some nice cases as to why we may > want the equivalent of "write running-config" to permit persistence.) > > At this point, overlapping ephemeral configuration isn't something that > netconf supports. If you scan mail from the last month or so, you'll also > see some back and forth between Juergen and Andy and I about how we go about > representing such a thing in the yang model/modules. (And we never fully > converged.) > > From the config perspective, this ephemeral state wasn't something that I > believe was part of the config semantics of netconf/yang; it's an I2RS > requirement. Admittedly, once we have such a think then clearly > applications other than I2RS can make use of it. :-) > > Choosing a solution space will be the next challenge we have: > - Overlapping modules with i2rs context? > - Parallel modules? > - How to ensure maximum re-use of the yang modules for config in an i2rs > context if they are determined to have heavy overlap? Jeff Yes, I saw the thread - I think I started it and ended it! Leaving aside the question of just what objects I2RS wants to edit that NETCONF cannot (perhaps none:-), the rest of that thread seems clear to me. The architecture I-D talks of data store which I think unclear; I think that it should be datastore, as used in Ops Area (e.g. by NETCONF). The view that has evolved, and is reflected in the thread, is that NETCONF 'config true' is not really the configuration. The real configuration is the operational state, part learnt from protocols and hardware and part derived from 'config true'; but 'config true' is only what the operator would like to happen, the operational state is the reality. Currently we only have 'config true' written by NETCONF in a configuration datastore (with operational state not being part of any datastore, just part of state, using that term in the Ops Area sense). What I2RS then adds is an I2RS datastore, may be one, may be several, which is another expression of hope as to what the box will do; operational state, as ever, tells us what actually happens. The rules of persistence for I2RS are whatever I2RS wants them to be with no impact on NETCONF. So I suggest that it is wrong, as I and others have said in the past, to talk of editing operational state; the writing of the basic NETMOD models have shown that that does not work. The model that has evolved is what I call twin trees, one of 'config true' - an aspiration of the operator - and the other of 'config false' - operational state, the reality. You can see signs of this in the NETMOD models of interfaces-cfg, routing-cfg, system-cfg and so on. I2RS then adds a third tree to the model, of what it would like the box to do. I2RS would also need to specify how to resolve conflicts between NETCONF and I2RS should they specify different values for the same object. This is already an issue, IMO not fully resolved, when the user and the system have different views of what should happen - look for user-controlled and system-controlled in interfaces-cfg. So one module, three trees, an additional YANG substatement for a leaf that is writable by I2RS. Tom Petch > > 6.4.2" o writing policy information such as interface attributes that > > are > > specific to the routing protocol or BGP policy that may indirectly > > manipulate attributes of routes carried in BGP. > > > > o writing routes or prefixes to be advertised via the protocol" > > I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but the > > I-D goes on to say > > " direct modification of the link-state database MUST NOT be allowed" > > (which I have seen on the list w.r.t. the BGP RIB). > > > > or > > > > 8" The interaction of state installed via the I2RS and via a router's > > configuration needs to be clearly defined." > > which again implies that I2RS and C/N/S are writing to the same data. > > *Maybe.* > > In some cases, the overlap with config state will be quite obvious and your > observation will strongly hold. > > In other cases, I think a better perspective is that I2RS injected state is > effectively like that of another routing protocol. > > If you'd like to argue that BGP is effectively the same as C/N/S... well, if > we're talking Flowspec I might agree. :-) > > > The examples of data that can be changed are few, such as > > "For example, the interaction with OSPF might include modifying the > > local routing element's link metrics, announcing a locally-attached > > prefix, .." > > which leaves me wondering, do you expect an OSPF YANG model to be unable > > to change a link metric:-) > > Sure. In a highly dynamic fashion? With a fallback to a default config when > the application is done? > > By comparison to some vendor specific features, it's somewhat the difference > between a policy database (config) and the dynamic policy API that doesn't > require a system reconfiguration event. If you want to point out that the > relationship is strong and that the defining differences are shallow - you > could very well be right in those contexts. > > Again, we don't expect I2RS work to supplant netconf/yang. We expect to > leverage the work. > > > If I2RS were aiming at a higher level, say specifying policy and have > > the system translate that into actual config changes I would understand > > that, but I do not see I2RS going that far, rather when I2RS says > > policy, I think it means changing a community (config again) or some > > such ie more of an implementation detail than a high level strategy. > > I hesitate to frame it this way, but one example application is a form of > SDN. The front end says "provision this VPN" to a data model for that > purpose. The fact that it may go behind the covers via client->agent and > eventually install ephemeral netconf state is an implementation detail. > > If you want to argue that such a higher level model is simply netconf, then > perhaps we should de-charter and do all of the work in that group. I was, > however, under the impression that work for various models was being pushed > to be done in appropriate working groups. :-) > > -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
