Hi Andy, Thanks very much for the feedback.
In my view, I2RS is between the I2RS Agents and I2RS Clients. An I2RS Agent is associated with a single Routing element. The I2RS agent can communicate with many I2RS Clients; an I2RS client can talk to many I2RS agents. I don't think that an I2RS agent talks to other I2RS agents. A routing element might have an I2RS agent and an I2RS client associated with it. For instance, say there's a routing element that implements BGP and doesn't have a forwarding plane associated with it. The associated I2RS agent might support the BGP service. The associated I2RS client might be used to communicate to a different routing element for its RIB service. If a network application needs routing state at multiple routers, then I agree with Adrian. Either the i2RS client talks to each router individually or the I2RS client talks to a single router to trigger the distribution of the routing state (i.e. an RSVP-TE LSP, a prefix in OSPF, etc). I do hear you on the thoughts about a base core of functionalit y. What I'm picturing is that there are basically two types of info-models that we need to create. The first type are "per service" info models - where it applies to a particular routing functionality - whether BGP, OSPF, ISIS, RIB, PIM, RSVP-TE, etc. We could use a better term than the overloaded service - any suggestions? The second type will be I2RS protocol-related info-models. This might be to describe I2RS-related event notifications or to control the role of a client or to describe the capabilities of the I2RS agent in terms of what services it supplies. We haven't really touched on this part yet... Each routing element may provide a different set of services - and I don't think we can mandate what those are. It'll depend on the role of the routing element in the network. What I think we can require is a set of core I2RS protocol-related functionality - so that I2RS clients can learn what is supported, the associated capabilities, etc. Focusing on a few services at first, from a WG perspective, does make sense to me. I believe that is starting with the RIB information model and the topology information model. I think we need a simple BGP info model soon as well - though I'm not sure if that's being worked on yet. Regards, Alia On Sun, Jun 23, 2013 at 5:11 PM, Andy Bierman <[email protected]> wrote: > > > On Sun, Jun 23, 2013 at 1:35 PM, Adrian Farrel <[email protected]>wrote: > >> Andy, >> >> > my question is how many I2Rs agents does a client need to >> > contact to perform a task that requires changes on multiple routers? >> >> You probably won't like my answer "that depends". >> >> If the effect of the action on router 1 is to cause router 1 to use a >> routing/signaling protocol to make things happen in the network, then the >> answer >> may be 1. >> >> If the changes cannot be effected in that way, then the client may need >> to talk >> to multiple routers to make the different things happen on each router. >> >> > > I meant a high-level task performed by the client that requires > routing state to be manually injected on multiple routers, > not via routing protocols. > > I am happy to consider the I2RS agent to be running on a single router > and the I2RS client to be the network-level broker. The API to > specific network-wide services topology or routing can be standardized > next. > > IMO it is better to start with the core functionality that is expected on > one device > (for some definition of "core" the WG will agree on later). > > > Andy > > And in between there lies the case of needing to touch some, but not all >> routers >> because other routers in between are worked on by signaling/routing. >> >> So the answer is 1 <= #agents <= #routers >> >> And that answer is modulo there being only one agent on each router :-) >> >> For (crass) examples of the above I give you: >> >> Set up an LSP using RSVP-TE (just talk to head-end router) >> Set up an end-to-end static route (talk to each router) >> Set up a multi-segment pseudo-wire (talk to the T-PEs and the S-PEs) >> >> Adrian >> >> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
