[Note that I'm responding to things in thread-order. I2RS was very busy for a few days while I had to pay attention to other things, so my responses may appear to jump around a bit.]
Sue, On Fri, Sep 26, 2014 at 12:22:25PM -0400, Susan Hares wrote: > > Just to confirm three facts before I put them in i2rs drafts (based on > Juergen's email > > - based on Juergen's email: I2RS is "config true empheral". This is a point of discussion. A critical thing to realize from the netmod interim is that it was simply a first step to trying to define what "ephemeral" even *means* in the context of existing yang and netconf/restconf. The "option 4" solution was the proposal that worked its way through discussion points with the yang experts, but still needs discussion within I2RS and then related followup with netconf if we decide it's the way to go. I like the idea, but as discussion is pointing out, there's a lot of details to reconcile. The impact of this upon writing data models for I2RS would appear to be at this point: - They're just "config true" (per correction from Juergen), but simply done in the ephemeral datastore. How you document that they're just in the ephemeral data store is unclear at this point. - They're otherwise just normal models. - But if they're intended to be i2rs ephemeral extensions on local config models (e.g. protocol WG data models), we have some dependency work to reconcile with those groups. > If i2rs has additional configuration for BGP related to your I2RS peers for > reporting routes: > > > > . BGP based config + I2RS additional config + AS Config > > > > Can I2RS have additional configuration values specific to I2RS? For > example, information regarding how often to report the routes for a > particular pear? Correct. We have roughly four scenarios with regard to modeling impact: A. Completely disjoint models for I2RS that use no state from other protocol modules and no dependencies, but interact with underlying state of that protocol. E.g. BGP configuration in an I2RS model that doesn't extend a IDR Yang module nor have constraints in such a module. B. A disjoint model for I2RS that has constraints against other modules. E.g. the I2RS BGP module may have a "must" statement against a IDR yang module's "autonomous system" configuration. C. A hybrid I2RS module that augments an underlying protocol module. This is the scenario you're suggesting above. The critical detail is since it's an augmentation it is suggesting there exists such a protocol module. D. There is a unified module developed in some working group that may simply choose to store some of its state in an ephemeral fashion. D is the newest option enabled by the "option 4" discussion from the netmod interim. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
