I2RS does not provide a single transaction spanning multiple I2RS agents. Though a client may use I2RS to read state from an I2RS-agent that was installed by another client via I2RS, ensuring consistency of that state network-wide is completely up to the clients and is outside the scope of I2RS architecture.
On Wed, Nov 6, 2013 at 1:06 PM, Shah, Himanshu <[email protected]> wrote: > 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
