> 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 think defining this would be 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. Or maybe I misunderstand the comment? > 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). I would agree with this one. :-) Russ -- <>< [email protected] [email protected] _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
