Hi Tom, On Tue, Jun 10, 2014 at 11:25 AM, t.petch <[email protected]> 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! > [Alia] If the state couldn't be set via CLI/NETCONF/SNMP etc, then the state will revert to the system default or what was dynamically learned (if that was something safe to be overwritten). This is describing what the behavior should be when written state is deleted by I2RS - not making a statement on what the scope of the models are. > 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 > [Alia] Again - generically changes can originate - but that doesn't mean that the full scope will originate from either. Collisions and interactions are of interest when they both can. > > 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). > [Alia] Right - because doing so seriously risks breaking the routing protocol and leading to incorrect behavior. Let's crawl before we run a marathon! > 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. > [Alia] If C/N/S write to the config which then writes to the operational data and I2RS writes to the operational data, what is the final content of the operational data? If I2RS can write set A and C/N/S can write set B, saying that A & B overlap doesn't imply that A == B. > > 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:-) > [Alia] Remember that low latency, high throughput, and asynchronous operations are all aspects of what I2RS is facilitating. There's a big difference between change one and change 1000+ in less than a second. Whereever I look, I struggle to see what I2RS will write that C/N/S will > not. > [Alia] Personally, I think that I2RS will write lower-level abstractions (all the details for the RIB info-model which aren't a standard part of configuration) and subsets of data that need to change fast - plus being a good interface for push notifications and event streams. If you are looking for examples, I'd look at the use-cases. > 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. > [Alia] True - and if I2RS is designed and implemented well, possibly higher-level abstractions will also be possible. We see the start of that at the desire to have a single abstract link-state topology for reading, for instance. The WG is chartered to crawl first and see what's feasible. Getting the problem-statement and architecture out of the way, along with the language and protocol base selection that has happened, is likely to open up the ability to seriously discuss detailed models. Regards, Alia > > Tom Petch > > > > > > > either on the list or in this I-D, so I am left wondering what it > is > > > that I2RS will do that NETCONF potentially cannot. > > > > The longer term question and netconf/yang continue to evolve (perhaps > with > > impetus from our use cases) will generally be what work belongs in > various > > groups. Yang modules are being proposed in the various working groups > to > > cover protocol specific configuration and general management. This is > > great! The question then becomes, where does I2RS fit into that sort > of > > picture. > > > > One of the reasons I think nailing down specific requirements (as Jim > Uttaro > > raised in a separete response) has come down to the somewhat nebulous > > ability to interact with functionality that is either not quite a fit > for > > standard config/query or interact with models that are one or more > levels of > > abstraction above a given protocol component. > > > > The degenerate case - the ability to ephemerally inject static routing > > information - certainly seems like work that could be done outside of > I2RS. > > Definitely so if it is decided that the ephemeral model is something > that > > becomes core to netconf/restconf. (The question of how this is > represented > > in the data model is the longer question.) > > > > Where the use cases start getting more substance are when we get > somewhat > > more abstract: > > - An API to the traffic engineering state in a routing system. This > is not > > just the OSPF, IS-IS or BGP-LS TEDBs, it's a summary view. Which > working > > group produces that model if done on a per-protocol basis? > > - A policy layer on top of BGP. That's perhaps in-scope for IDR or > GROW. > > As you definitely know (:-) ) such a policy layer will interact with > a lot > > of non-BGP components and potentially other databases. > > - A management layer to provision VPN instances (service layer > routing). > > Does that work get done in IDR? MPLS? L2/L3VPN? > > > > And of course, there's the whole matter of how do you bring together > > contributors with expertise in modeling, operations and the mix of > routing > > and other protocols in question and where do you do it? From the > first BoF, > > it was clear there are a lot of people who want to work on the things > that > > fall in these nebulous gaps between working groups. > > > > I2RS is here to be the big tent to let us gather people under to do > that > > sort of work. Maintaining enough focus to make progress on a > constrained > > number of items is the main early challenge. A survey of the use case > > documents should definitely suggest there's a lot more that people > would > > like to work on. > > > > > > > I do find the I-D quite hard to follow as the terminology seems > > > inconsistent - the word 'state' is much used but it is unclear to me > if > > > the term can be given a single definition in this context; and even > if > > > it can, the word seems an unfortunate choice since the IETF Ops Area > has > > > given it a precise definition which is at odds with its use here. > > > > Are there specific edits you would suggest to clarify the document? > > > > -- Jeff > > > > _______________________________________________ > > i2rs mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
