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

Reply via email to