i2rs is basically an API into the router. I think what you're looking for is an api into the network as a whole. I have yet to grok all the i2rs docs but something like that seems very clearly Somebody Else's Problem - that is, out of scope.
eric > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Shah, Himanshu > Sent: Wednesday, November 06, 2013 1:06 PM > To: Sriganesh Kini > Cc: Russ White; [email protected]; Joel M. Halpern; Alia Atlas > Subject: Re: [i2rs] question on I2RS architecture > > I don't think so (apples vs oranges). > Not sure if you got the point I made. > It is not about client <-> agent transaction integrity. > It is about different clients talking to different agents and making > sure about the network wide consistency. > If there is only one client talking to all agents, then your point > stands, but that is not what I was discussing. > > /himanshu > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Sriganesh Kini > Sent: Wednesday, November 06, 2013 3:43 PM > To: Shah, Himanshu > Cc: Alia Atlas; Russ White; [email protected]; Joel M. Halpern > Subject: Re: [i2rs] question on I2RS architecture > > Himanshu, > > It seems like you are comparing apples to oranges when you compare a > distributed routing protocol to the interface to the routing system. > > If it helps any, take a look at Fig 1. of draft-ietf-i2rs-rib-info- > model. The distributed routing protocol would be a client. The I2RS > agent (not shown in that Fig) would provide the interface from the > client towards the Routing System (in the context of this draft, this is > the RIB). Just as a routing-protocol may have an eventual-consistency > model, any new client using the I2RS interface would have to design its > own consistency model. The client can use mechanisms such as > transactions (sec 6.9 of > draft-ietf-i2rs-architecture) towards that. > > - Sri > > > On Wed, Nov 6, 2013 at 11:45 AM, Shah, Himanshu <[email protected]> wrote: > > Wouldn’t this be a stumbling block for I2RS architecture? (sorry for > > having missed the discussion on mailing list on this issue). > > > > In distributed control plane, transient inconsistencies are repaired > > eventually (once every node has updated topo info). > > > > I am not sure I2RS mechanisms has built-in detection and/or repair > > mechanism resulting in sustained instability. > > > > > > > > May be I2RS clients need to get ‘permission’ from an orchestrator or > > “an I2RS-coordinator” before issuing ‘set’ operations to I2RS agent? > > > > > > > > /himanshu > > > > > > > > > > > > > > > > From: Alia Atlas [mailto:[email protected]] > > Sent: Wednesday, November 06, 2013 1:30 PM > > To: Russ White > > Cc: Joel M. Halpern; [email protected]; Shah, Himanshu > > > > > > Subject: Re: [i2rs] question on I2RS architecture > > > > > > > > This is an aspect of the unexpected interactions problem. There's > text in > > the architecture saying that these can happen. This was offered for > > discussion on the list to resounding silence. > > > > We can't reasonably solve this distributed problem from the vantage of > > a particular network element, which is what an I2RS agent has. > > > > Alia > > > > On Nov 6, 2013 9:19 AM, "Russ White" <[email protected]> wrote: > > > > > > The problem with enforcing consistency in this environment is it would > > be just as impossible to attain as it is with a distributed control > > plane in real time. It seems, to me, that we can provide an interface, > > but the controller/software doing the controlling must do the > > consistency insurance, just as routing protocols do today... > > > > :-) > > > > Russ > > > > <>< > > [email protected] > > Ericsson > > > >> On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" <[email protected]> wrote: > >> > >> I was not alluding to malicious use but genuine use of I2rs interface > >> in the absence of complete view of the latest network topology and/or > >> view of what other I2RS client are doing or are about to do. There > >> needs to be safeguards. I2RS needs to address consistency > >> verification aspects. > >> > >> If that is offloaded to some other entity, I2RS arch spec needs to > >> explicitly mention that. > >> > >> /himanshu > >> > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:[email protected]] > >> Sent: Wednesday, November 06, 2013 11:55 AM > >> To: Shah, Himanshu; [email protected] > >> Subject: Re: [i2rs] question on I2RS architecture > >> > >> If someone wants to create inconsistency using I2RS, we won't stop > them. > >> And although there was opne request for very precise timing on > >> operations, that seems to me to be a step too far. > >> > >> Yours, > >> Joel > >> > >>> On 11/5/13 9:07 PM, Shah, Himanshu wrote: > >>> /At the IETF I2RS interim meeting, I raised the concern about > >>> conflicting set operations by I2RS clients to different I2RS > >>> agents,/ > >>> > >>> /Which may end up causing micro-loop or far-side loop. / > >>> > >>> // > >>> > >>> /Is this addressed in the architecture? / > >>> > >>> /May be this is responsibility of network orchestrator./ > >>> > >>> /If it is not mentioned in the doc, may be some text necessary to > >>> explain??/ > >>> > >>> // > >>> > >>> /Thanks,/ > >>> > >>> /himanshu/ > >>> > >>> // > >>> > >>> /Himanshu Shah/ > >>> > >>> /Ciena Corp/ > >>> > >>> > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/i2rs > >> _______________________________________________ > >> i2rs mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > > i2rs mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > _______________________________________________ > > i2rs mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
