Subject: [i2rs] question on I2RS architecture

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 5 Nov 2013 21:07:53 -0500

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

---

From: "Russ White" <[email-masked]>
Date: Wed, 6 Nov 2013 09:49:34 -0500

> At the IETF I2RS interim meeting, I raised the concern about conflicting
set
> operations by I2RS clients to different I2RS agents,
> 

There's no way, in this sort of architecture, to prevent people from tying a
noose in the rope. :-)

OTOH, the priority of different set operations by different agents, and
whether things are strictly time ordered is, I think, still under
discussion, and will need to be resolved to get to the protocol stage. Maybe
someone else can comment on the current state around this specific piece to
clarify (?).

:-)

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 06 Nov 2013 11:54:32 -0500

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-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 6 Nov 2013 12:11:39 -0500

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-masked]] 
Sent: Wednesday, November 06, 2013 11:55 AM
To: Shah, Himanshu; [email-masked]
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

---

From: Russ White <[email-masked]>
Date: Wed, 6 Nov 2013 09:19:05 -0800

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-masked]
Ericsson

> On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" <[email-masked]> wrote:
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 6 Nov 2013 13:30:24 -0500

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-masked]> 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-masked]
> Ericsson
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 6 Nov 2013 14:45:55 -0500

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-masked]]
Sent: Wednesday, November 06, 2013 1:30 PM
To: Russ White
Cc: Joel M. Halpern; [email-masked]; 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-masked]<mailto:[email-masked]>> wrote:

:-)

Russ

<><
[email-masked]<mailto:[email-masked]>
Ericsson

> On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" <[email-masked]<mailto:[email-masked]>> wrote:
>
> From: Joel M. Halpern [mailto:[email-masked]<mailto:[email-masked]>]
> To: Shah, Himanshu; [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 6 Nov 2013 12:42:42 -0800

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-masked]> 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).
>
> May be I2RS clients need to get ‘permission’ from an orchestrator or “an
> I2RS-coordinator” before issuing ‘set’ operations to I2RS agent?
>
>
>
> /himanshu
>
>
>
>
>
>
>
> controller/software doing the controlling must do the consistency insurance,
> just as routing protocols do today...
>
> :-)
>
> Russ
>
> <><
> [email-masked]
> Ericsson
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 6 Nov 2013 16:06:27 -0500

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-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Wednesday, November 06, 2013 3:43 PM
To: Shah, Himanshu
Cc: Alia Atlas; Russ White; [email-masked]; 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-masked]> wrote:
> Wouldn’t this be a stumbling block for I2RS architecture? (sorry for 
> having missed the discussion on mailing list on this issue).
>
> 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
>
>
>
>
>
>
>
> We can't reasonably solve this distributed problem from the vantage of 
> a particular network element, which is what an I2RS agent has.
>
> Alia
>
> 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-masked]
> Ericsson
>
>> 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.
>>

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 6 Nov 2013 13:35:21 -0800

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.

---

From: "Russ White" <[email-masked]>
Date: Wed, 6 Nov 2013 16:48:22 -0500

> “an I2RS-coordinator” before issuing ‘set’ operations to I2RS agent?

Backing up a little in the thread --this, specifically, is what we want to avoid. We don't want a "lock/release," or a transaction oriented protocol to ensure referential integrity across all devices in the I2RS domain. 

Maybe an illustration would help: Does the OSPF to RIB interface ensure referential integrity among all the routers within a single OSPF flooding domain? No... the forwarding plane on each device counts on OSPF to ensure integrity (and, BTW, OSPF doesn't ensure perfect real time integrity -- take a look at the work going on in fast reroute and ordered FIB as examples of narrowing the window of time during which the link state topology and the real world topology are not congruent). In the same way, the integrity or loopfreeness of the routes calculated by the control plane -- some process residing on the client -- is not something the interface between the client and the agent can, or should, handle. It's up to the creator of the protocol running in that process to ensure things are being forwarded correctly, etc.

If you're trying to prevent order of operation issues, again this is no different than the problem of microloops in any link state protocol, or the BGP hunt convergence, or BGP flipping back and forth between two different routes. The protocols can be fixed to stop this sort of stuff, but that's a protocol level problem, not a problem to be addressed by making all BGP processes check with a central process before installing a route in a local RIB.

So no, there's protection against such things with the I2RS charter, or any of the drafts (that I know of) so far. And I, for one, would actually object to such a thing -- because it adds a level of complexity into I2RS that should rightfully live someplace else in the system -- specifically within the control plane(s) driving I2RS.

HTH

:-)

Russ

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 6 Nov 2013 22:45:42 +0000

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shah, Himanshu
> Sent: Wednesday, November 06, 2013 1:06 PM
> To: Sriganesh Kini
> Cc: Russ White; [email-masked]; Joel M. Halpern; Alia Atlas
> If there is only one client talking to all agents, then your point
> stands, but that is not what I was discussing.
> 
> /himanshu
> 
> 
> 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

---

From: Scott Whyte <[email-masked]>
Date: Thu, 7 Nov 2013 16:35:18 -0800

> 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 So…

https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final8.pdf
might be of interest as I believe it addresses some (not all) of the
issues raised on this thread.  And I agree with Eric this sort of
thing lives on a client not an agent (per the architecture draft
diagram).

-Scott