Re: [irs-discuss] IRS Problem Statement Posted

[Susan Hares <[e-mail]>]

Nitin:

Thanks for the agreement.  The real challenge is how to fit the middleware into the needs of application and network layer.  Framework, architecture, design steps have fascinating challenges that build on the 30+ years of distributed and centralized networking algorithms. 

Two things often forgotten in these models are security and mobility.  In the DC & VM-aware world, we cannot skips these two items. 

As a side note,  John Day in Patterns of Networking - suggests that all of networking can be viewed as middleware. For in the end - we are multiplexing application traffic over some media.  Networks exist to provide service to applications.  

Sue 
[love this discussion!]

-----Original Message-----
From: Nitin Bahadur [mailto:[e-mail]] 
Sent: Monday, July 30, 2012 6:39 PM
To: Susan Hares
Cc: James Kempf; Thomas Nadeau; [e-mail]
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Hi Susan,

    You've expressed my thoughts very succinctly. I fully agree with all you said. IRS is nothing but a middleware IMO. 

An orchestrator has 3 layers:

The top layer exposes the northbound Apis to apps - I want a path from A to B with a constrain on low latency. That's all the app should need to say.

The bottom layer fetches topology, stats and other data from network elements and programs the network elements.

And the middle layer is the business layer that takes user input from northbound Apis, takes input from bottom layer; munches on the data and converts it into rules for the bottom layer to program.

So IRS needs to define interfaces for both the lower layer and the upper layer.

Thanks
Nitin

On Jul 30, 2012, at 6:27 PM, "Susan Hares" <[e-mail]> wrote:

> Nitin: 
> 
> Exposing some network intelligence can either be done in detail or in some amount of summarization. 
> If you are doing detail, you have bandwidth issues. If you are doing summarization or opacity, you are talking about layers of information. 
> 
> Apps need to find out what they need to get. They do not need all the details - just the fact they can get from point A to Point B (or for multi-cast B/C/D). They need to where they can go to date other applications.  They need a match-maker for the application who determine where the applications shall flow.  Now, if they are smart - like people going out to eat - they pick several ways go to eat traffic.  
> 
> The network orchestration then serves to be the paths to the place to eat.  This can either be distributed or centralized.  
> 
> If we have an Interface to routing, it need to have a two-layer concept of exposing information.  
> 
> Sue Hares 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Nitin Bahadur
> Sent: Monday, July 30, 2012 3:33 PM
> To: James Kempf; Thomas Nadeau; [e-mail]
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
> 
> Hi James,
> 
> This is not about splitting control plane and forwarding plane. It is about exposing network intelligence in the network elements to an external controller.
> And it is about allowing an external controller to use that information for enabling network-aware apps. And it is about allowing apps to influence the
> network element's RIB (not the FIB directly).
> 
> Streaming is essential to allow for operations at scale...and avoid a request/response gated mechanism.
> 
> Hope that helps.
> 
> Thanks
> Nitin
> 
> On 7/30/12 3:11 PM, "James Kempf" <[e-mail]> wrote:
> 
> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
> 
> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
> 
>                jak
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Thomas Nadeau
>> Sent: Monday, July 30, 2012 11:18 AM
>> To: [e-mail]
>> Subject: [irs-discuss] IRS Problem Statement Posted
>> 
>> 
>> 
>> Please review and discuss.
>> 
>> Thanks,
>> 
>> Tom, Alia, Ward
>> 
>> 
>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>> 
>> 
>> _______________________________________________
>> irs-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> 
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss