Alia Atlas <[email protected]> writes: > Hi Lada, > > > On Thu, Jun 12, 2014 at 5:15 AM, Ladislav Lhotka <[email protected]> wrote: > >> "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. >> > > [Alia] We described the arbitration rules in Section 6.3 of > draft-ietf-i2rs-architecture-03.
I guess we have to think about a proper representation of operational state and ways for tagging its contents or otherwise signalling what caused a particular change. For instance, if a configured static route is not present in a RIB (operational state), it may be because - the next hop wasn't reachable when the static route was configured, or - the I2RS agent deleted it. The NETCONF server should be able to discriminate between these two cases because its action (reinstall the route or not) may depend on it. Lada > > >> > >> > 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. >> > > [Alia] Please - I think there are different assumptions... > > Regards, > Alia > > >> >> 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 >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
