Hi Barry, The discussion of your review comments went on on the I2RS list without fully copying you on the responses. Let me try to summarise where we got to and add some detail myself.
> Block (2012-12-27) > > The second paragraph says this: > > I2RS facilitates real-time or event driven interaction with the > routing system through a collection of control or management > interfaces. These allow information, policies, and operational > parameters to be injected into and retrieved (as read or by > notification) from the routing system while retaining data > consistency and coherency across the routers and routing > infrastructure, and among multiple interactions with the routing > system. > > Nowhere that I can see does it give me any idea what the target of these > interfaces is: what is it that you want having interaction with the routing > system? What is it that will inject information, policies, and operational > parameters, that can't do so now? I having a little difficulty parsing your questions, so let me give some broad-scope answers. The object of the interfaces is the routing system. I think this is clear in the second paragraph of the draft charter. The purpose of the interactions at the interfaces are, I think, captured in the second sentence of the second paragraph and (perhaps more importantly) in the use cases. The subject of the interfaces is some lump of stuff that decides to poke the routing system. In the architecture (I-D) the subject end of the interface is called the I2RS Client and serves one or more "applications". We got a bit hung up about what constitutes an application: is it, for example, a P2P streaming application, or is it a tool that is responsible for shaping the network? In the end, the answer appeared to be "yes". Now, on the list it was suggested that this is and should be deliberately out of scope... | We're not trying to define what it is that wants to interact with the | control plane in this way, only to provide an interface for any such | processes. The use cases point us to examples where these interactions | are defined without identifying what the off-board processes actually | look like. That leaves us with your last part of the question which I will invert to read: what can be done today? The problem here is that there is a feeling that the existing standardised protocols and encoding languages are missing features to provide the necessary functions. There is a lot of debate on this, which is why it is necessary to do requirements work. Additionally, we need information models for the things that are to be injected/retrieved. Of course, it is likely that in a number of vendors' router quite a few of the things can be injected or retrieved using CLI, proprietary protocols, proprietary extensions to existing protocols, or proprietary schemas for existing encoding languages. But that is not a standard solution. > Comment (2012-12-27) > > Especially because charters, including this one, don't have the sorts of > citations and references that we have in RFCs, it would be helpful to expand > "RIB" and "FIB" (and, for completeness, "BGP") on first use. I know that > routing people know those terms cold... but some of us don't (Wikipedia taught > be that they're "Routing Information Base" and "Forwarding Information Base", > so I'm now better informed). OK, we can do that. Hoping this clears your issues. Cheers, Adrian _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
