"t.petch" <[email protected]> writes: > ----- 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.
Yes, although platforms that control all channels through which the operator can interact with the box often try to pretend that config and operational state are the same. It is reflected somewhat in the design of YANG where operational state data (config false) may be embedded within the configuration tree. > > 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. Agreed. > > 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. Yes, and I plan to propose that the relationship of such twin trees be formally stated in YANG models - currently it is only explained in descriptions. > > 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. It is necessary to think about some arbitration rules that prevent NETCONF and I2RS (or other means for changing operational state) to stomp on each other's toes. I don't think though this has anything to do with user/system-controlled interfaces. > > So one module, three trees, an additional YANG substatement for a leaf > that is writable by I2RS. Rather than inventing new annotations, I'd rather like to see making YANG less NETCONF-specific so that it could directly define schema and constraints for other datastores such as the one for I2RS. Lada > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
