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]<mailto:[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]<mailto:[email protected]>
Ericsson

> On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" 
> <[email protected]<mailto:[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]<mailto:[email protected]>]
> Sent: Wednesday, November 06, 2013 11:55 AM
> To: Shah, Himanshu; [email protected]<mailto:[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]<mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/i2rs
> _______________________________________________
> i2rs mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]<mailto:[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