Thomas, Responses in-line
On Thu, Jan 3, 2013 at 5:14 PM, Thomas Narten <[email protected]> wrote: > Alia Atlas <[email protected]> writes: > ... > > > The second paragraph starts with: > > > "I2RS facilitates real-time or event driven interaction with the > > routing system through a collection of control or management > > interfaces." > > > While the type of interface is, I think, clear and beaten to death, > > I'd like to jump further on it by suggesting adding "protocol-based" > > to the list of possible descriptors. That would make it: > > > "I2RS facilitates real-time or event driven interaction with the > > routing system through a collection of control or management > > protocol-based interfaces." > > I'm OK with this change, but the bigger question I have when reading > the charter (at a general level), is how this "management interface" > differs from what we already have today. E.g., config files. I suspect > one answer is "you can't do what we want to do through the existing > config file mechanisms", but that's only partly helpful and begs the > question of just what is something this effort is intended to do that > can't already be done today. The charter itself doesn't say anything > like that. It's just silent about why what I2RS is trying to do can't > be done today. Indeed, there is no hint at all about how this might be > done (and the BOF had lots of questions along the lines of "why can't > you use <insert favorite protocol> to do this today?" > > I'm not sure what to suggest here, but my own sense is that an outside > reader looking at this charter will have a hard time understanding > just what the scope of this effort is and what problem it is trying to > solve. > There are a couple things going on here. First, it is entirely possible that the needs of I2RS could be met by extending <pick your favorite protocol and data model language>; however, we don't want to pre-judge whether that will be the case before the requirements and use-cases are clearly agreed upon. Second, the type of programmatic interface we are looking for is: a) "streaming" or "asynchronous" - it is possible to have many different operations simultaneously being worked upon - from the same and different clients. b) bi-directional: clients can register for significant events and request information. There is the possibility that an I2RS agent may solicit work/direction from one or more clients as well. c) low-overhead and fast: An I2RS client may have hundreds or thousands of IRS agents that need to be occasionally communicated with - and similarly an IRS agent may get operations from many I2RS clients. In such a situation, there's little need to keep alive a communication channel. Avoiding capability negotiation/learning every time a client reconnects is preferable. d) multi-channel: Let's acknowledge that routing elements are multi-processor - whether that means the control plane or the forwarding plane - and have an interface that easily allows transmission of lots of data from multiple processors without having to go through a particular bottleneck. For instance, if an I2RS client requests counter data - potentially lots - it'd be better to have that deliverable directly from the local line processor. But those are my initial ideas - and what we resolve to depends on the use-cases and WG. So, I don't see them as belonging in the charter. So - there are multiple aspects that I2RS is looking to handle: a) "application-friendly" or "machine-to-machine focused" programmatic interfaces b) address the feedback loop - so that an IRS client easily has the information to make decisions c) standard data models to ease application development If you have thoughts on how to fairly describe that in the charter, they'd certainly be welcome. Alia
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
