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.) > 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
