Tom, [retaining lots of content for context]
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, > > > > Thanks for the comments. > > > > On Tue, Jun 10, 2014 at 12:12:35PM +0100, t.petch wrote: > > > but reading Architecture, the examples I see are ones that seem to > fall > > > within the remit of NETCONF (being config) as and when a suitable > data > > > model has been defined (e.g. for OSPF or BGP). Initially I had > thought > > > of several things that I2RS might do but these have been ruled out, > > > > It'd help if you listed the ones in question. Some of these things > may be > > part of the work that is left currently out of scope to attempt to > constrain > > the WG to things we have decided to get done first. (Don't bite off > more > > than you can chew.) > > e.g. > 6.2.3. Reversion "In all such cases, the state will revert to what it > would have been without the I2RS; that state is generally whatever was > specified via the CLI, NETCONF, SNMP, etc." > which seems to say that C(LI)/N(ETCONF)/S(NMP) set it to X, I2RS sets it > to Y then disappears so it reverts to X, for all values of 'it' - i.e. > 'it' is what NETCONF would call config and so could have been set by > NETCONF, no need for I2RS! > > 6.3. Interactions with Local Config "Changes may originate from either > Local Config or from I2RS." > Taking Local Config to be what NETCONF/YANG calls 'config' then again, > nothing there it seems that C/N/S cannot do 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? > > 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
