Subject: [irs-discuss] An idea ... MTR + IRS

From: Robert Raszuk <[email-masked]>
Date: Fri, 03 Aug 2012 02:02:20 +0200

Hi,

This morning Scott mentioned that he would like to use IRS to shut down 
all protocols and just be able to write to RIB. Now James said that he 
would like to get a network topology as "every OpenFlow controller 
requires this"

Both connected together resulted in an idea of using 
multi-topology-routing where your base topology discovers physical link 
connectivity graph while other topologies could be programmed by 
external entities example: OF controllers or any other external to 
routers network intelligence oracles to deliver actual services ?

Would that be in scope of IRS effort ? If so what would be the proposed 
"write to RIB" set of protocols ? Would you support OF 1.3 even if one 
would be happy to lock such topologies only to software/programmable 
switching paths ?

Best rgs,
R.

---

From: Lin Han <[email-masked]>
Date: Tue, 7 Aug 2012 20:58:06 +0000

I think the MT will provide the network virtualization which is based on the basic topo of the forwarding device.
It should belong to either orchestration or application (SDN point of view). OF controller should only support OF, no more intelligence such as decision for routing and switching.
I don't know if IRS frame work should cover this since IRS frame work has a lot debatable areas.

Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, August 02, 2012 5:02 PM
To: [email-masked]
Subject: [irs-discuss] An idea ... MTR + IRS

Hi,

Best rgs,
R.
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

---

From: Edward Crabbe <[email-masked]>
Date: Tue, 7 Aug 2012 15:19:40 -0700

Robert,

If topo information export is in scope (which I believe it is) and PBR
route injection with nh recursion to rib (and thus connected routes) is in
scope (which I'm quite sure it is) then yes, this is in scope.

Although I'm not sure what it has to do with OF /OF controllers? ;P

On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]> wrote:

> would like to get a network topology as "every OpenFlow controller requires
> this"
>
> connectivity graph while other topologies could be programmed by external
> entities example: OF controllers or any other external to routers network
> intelligence oracles to deliver actual services ?
>
> ______________________________**_________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss>
>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 7 Aug 2012 18:22:28 -0400

I agree. The only related thing is that you can run both on the same box, effectively creating another "hybrid" scenario, or as we like to call it, tri-brid. *)

--Tom

From: Edward Crabbe <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 7, 2012 6:19 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

Robert,

If topo information export is in scope (which I believe it is) and PBR route injection with nh recursion to rib (and thus connected routes) is in scope (which I'm quite sure it is) then yes, this is in scope.

On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

This morning Scott mentioned that he would like to use IRS to shut down all protocols and just be able to write to RIB. Now James said that he would like to get a network topology as "every OpenFlow controller requires this"

Both connected together resulted in an idea of using multi-topology-routing where your base topology discovers physical link connectivity graph while other topologies could be programmed by external entities example: OF controllers or any other external to routers network intelligence oracles to deliver actual services ?

Would that be in scope of IRS effort ? If so what would be the proposed "write to RIB" set of protocols ? Would you support OF 1.3 even if one would be happy to lock such topologies only to software/programmable switching paths ?

Best rgs,
R.
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

---

From: Tina TSOU <[email-masked]>
Date: Tue, 7 Aug 2012 22:23:32 +0000

Nitin said topo information export is on the sub-layer under IRS.

Tina

From: [email-masked] [mailto:[email-masked]] On Behalf Of Edward Crabbe
Sent: Tuesday, August 07, 2012 3:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [irs-discuss] An idea ... MTR + IRS

Robert,

Best rgs,
R.

---

From: Alia Atlas <[email-masked]>
Date: Tue, 7 Aug 2012 20:30:26 -0400

Topology export is definitely under the umbrella of IRS - and we are
actively starting to think about the associated requirements and
use-cases.   Feel free to contribute - on the list or towards drafts!

Alia

On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU <[email-masked]> wrote:
> If topo information export is in scope (which I believe it is) and PBR route
> injection with nh recursion to rib (and thus connected routes) is in scope
> (which I'm quite sure it is) then yes, this is in scope.
>
>
>
> This morning Scott mentioned that he would like to use IRS to shut down all
> protocols and just be able to write to RIB. Now James said that he would
> like to get a network topology as "every OpenFlow controller requires this"
>
> Both connected together resulted in an idea of using multi-topology-routing
> where your base topology discovers physical link connectivity graph while
> other topologies could be programmed by external entities example: OF
> controllers or any other external to routers network intelligence oracles to
> deliver actual services ?
>
> "write to RIB" set of protocols ? Would you support OF 1.3 even if one would
> be happy to lock such topologies only to software/programmable switching
> paths ?
>
> Best rgs,
> R.

---

From: Tina TSOU <[email-masked]>
Date: Wed, 8 Aug 2012 02:40:46 +0000

Oh, I meant in Nitin's description in the mailing list, there are 3 sub-layers of a orchestrator.
Top layer: Northboundapi
Middle layer: IRS
Bottom layer: topo export

Therefore, the topo export is not part of IRS. It is another layer which sits below IRS.

Tina

---

From: Alia Atlas <[email-masked]>
Date: Wed, 8 Aug 2012 00:01:49 -0400

The requirement for topology export is DEFINITELY part of IRS.  It is
a crucial piece for a meaningful feedback loop.   Clearly there are
existing technology pieces that may have a role to play as well.

Alia

---

From: Tina TSOU <[email-masked]>
Date: Wed, 8 Aug 2012 04:07:51 +0000

So, r u updating Nitin's statement as following?
Top layer: Northboundapi
Middle layer: IRS
Bottom layer: IRS (topo export)

Tina

On Aug 7, 2012, at 9:01 PM, "Alia Atlas" <[email-masked]<mailto:[email-masked]>> wrote:

Alia

On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:
Oh, I meant in Nitin's description in the mailing list, there are 3 sub-layers of a orchestrator.
Top layer: Northboundapi
Middle layer: IRS
Bottom layer: topo export

Tina

On Aug 7, 2012, at 5:30 PM, "Alia Atlas" <[email-masked]<mailto:[email-masked]>> wrote:

Alia

On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:
Nitin said topo information export is on the sub-layer under IRS.

Tina

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
Behalf Of Edward Crabbe
Sent: Tuesday, August 07, 2012 3:20 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Robert,

Hi,

Best rgs,
R.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 8 Aug 2012 00:38:15 -0400

Tina,

Nitin made a single comment on this list that you are reading too much into.

I have written the two base drafts for IRS and am working on driving
the definition of the work that is proposed.  The presentation that I
gave in Routing Area Open Meeting CLEARLY describes topology as not
only being in the proposed scope, but one of the more urgent items.

Why are you NOT listening?

Perhaps rereading the problem-statement and framework drafts would
help clarify your mental model?

IRS does not talk about a northboundapi - there are applications that
can use IRS.  How those applications communicate with other
applications is NOT in the proposed scope.

Alia

On Wed, Aug 8, 2012 at 12:07 AM, Tina TSOU <[email-masked]> wrote:
> On Aug 7, 2012, at 9:01 PM, "Alia Atlas" <[email-masked]> wrote:
>
> From: [email-masked] [mailto:[email-masked]] On
>
> Behalf Of Edward Crabbe
>

---

From: Tina TSOU <[email-masked]>
Date: Wed, 8 Aug 2012 05:24:56 +0000

Alia,
It is just to clarification.
Just to confirm that draft-atlas and draft-ward state that IRS positions below the northboudapi in an orchestrator, and IRS includes both routing state and topo export. Is it correct understanding?
Thank you.

Tina

> From: Alia Atlas [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2012 9:38 PM
> To: Tina TSOU
> Cc: Edward Crabbe; [email-masked]; [email-masked]
> > On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU
> <[email-masked]>
> > wrote:
> >
> > Therefore, the topo export is not part of IRS. It is another layer
> which
> > sits below IRS.
> >
> >
> > Tina
> >
> >
> > On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU
> <[email-masked]>
> > wrote:
> >

---

From: Alia Atlas <[email-masked]>
Date: Wed, 8 Aug 2012 01:33:02 -0400

Tina,

IRS makes no statement about orchestrators; I'm pretty sure the word
doesn't appear in either draft at all.  Certainly an orchestrator is a
type of application that could use IRS.

IRS includes routing state, topology, and the ability to get
measurements and dynamic events.  All may be needed for a meaningful
feedback loop run by an application.

Alia

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 08 Aug 2012 12:10:45 +0200

Ed,

 > If topo information export is in scope (which I believe it is) and
 > PBR route injection with nh recursion to rib (and thus connected
 > routes) is in scope (which I'm quite sure it is) then yes, this is in
 > scope.

Great !

> Although I'm not sure what it has to do with OF /OF controllers? ;P

One could observe that entire OF can be very easily mapped to well 
implemented and scaable PBR ;)

Best,
R.

---

From: David Meyer <[email-masked]>
Date: Wed, 8 Aug 2012 07:59:07 -0700

> So, r u updating Nitin's statement as following?

#dmm: I propose we depricate the term "Northbound API".  It is pretty
much (if not completely)  meaningless.

---

From: Scott Whyte <[email-masked]>
Date: Fri, 10 Aug 2012 15:51:51 -0700

> implemented and scaable PBR ;)

I guess that depends on what you define Policy Based ROUTING to be ;)

-Scott

-- 
panem et circenses - a winning strategy for over 2000 years!