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. > > > > 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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
