Subject: Re: [irs-discuss] IRS Problem Statement Posted

From: Susan Hares <[email-masked]>
Date: Wed, 1 Aug 2012 18:03:22 +0000

Alia:

+1 on abstraction + filters (abstract/detail) IRS fits at the routing control.  

The real question about translation is what the translation is doing.  Is it translating one thing to another at the same layer of abstraction (e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change. 

I define translation as the same layer of abstraction.  Some people suggest translation = abstract/detailing.  We first need a common way to talk about the difference. 

Sue

By the way --- I'm thrilled about the pace of the discussion. 

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

Sue,

I certainly agree that we want IRS to have the ability to express
information at different abstraction layers and filtered on request.

There may still be a gap between the "network OS abstractions" and IRS
sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
the bottom-up control strings.

IMHO, it's reasonable to have an entity that manages the translation.
For instance, one doesn't need a PCE-equiv in every application - nor
in every router; that might be an entity in between.

The quantity of information is part of why explicit filtering and
hopefully abstraction layers should be built into the data-models.

Alia

On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> Sent: Monday, July 30, 2012 3:33 PM
> To: James Kempf; Thomas Nadeau; [email-masked]
> 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" <[email-masked]> 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: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>> Sent: Monday, July 30, 2012 11:18 AM
>> To: [email-masked]
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

---

From: Susan Hares <[email-masked]>
Date: Wed, 1 Aug 2012 18:06:51 +0000

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:[email-masked]] 
Sent: Monday, July 30, 2012 6:39 PM
To: Susan Hares
Cc: James Kempf; Thomas Nadeau; [email-masked]
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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 1 Aug 2012 18:40:32 -0400

Sue,

In this case, I was thinking of "translating" from a "higher
abstraction layer" to a "lower abstraction layer".

Do you have a better/different term to suggest?  I agree that clarity
of terminology is important.

Alia

---

From: Susan Hares <[email-masked]>
Date: Wed, 1 Aug 2012 23:20:55 +0000

Alia:

I'm going to check with a colleague who has been doing lots of model work to see if he's got a better.  More later.

Sue 

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 3:41 PM
To: Susan Hares
Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked]
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Sue,

Alia

---

From: Susan Hares <[email-masked]>
Date: Fri, 10 Aug 2012 18:27:13 +0000

Robert:

[Catching up with old email]

Why are you concerned with the streaming aspects of the data from BGP and ISIS?  If you are could you cross post to [email-masked]. 
We are considering the draft-gredler-idr-ls-distribution at this time. 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, July 30, 2012 6:11 PM
To: Alia Atlas
Cc: Thomas Nadeau; James Kempf; Joel M. Halpern; [email-masked]; Thomas Nadeau
Subject: Re: [irs-discuss] IRS Problem Statement Posted

What is not clear for me is ability from arbitrary entities to be able to write to BGP or ISIS at sort of ad-hoc streaming. I do not see anything good can be seen as result of this. 

Exporting information is fine - no objection at all.

However for programming state into dynamic system the entity which writes in should be the master and not the slave which unfortunately as of now it looks like it is the latter.

Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps just add static routes, perhaps insert network statements into BGP configuration. But till details are defined and till we understand how is this any better from already standards based tools to do the same I think it is well premature to judge any benefit from the IRS framework.

Best Rgs,
R.

Sent from my iPad

On Jul 30, 2012, at 5:55 PM, Alia Atlas <[email-masked]> wrote:

> Rob,
> 
> We've been trying.  I've written semi-copious words so far.
> I'd be happy to discuss with you in person as well and get your
> thoughts on reasonable use-cases.
> 
> Describing an elephant for the first time is always tricky.
> 
> Perhaps you could describe your perspective on the problem and what
> you think is unclear.
> 
> Regards,
> Alia
> 
> 
> On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk <[email-masked]> wrote:
>> Tom,
>> 
>> Yes indeed .. Clearly defining what problem are you trying to solve would be greatly helpful.
>> 
>> Best,
>> R.
>> 
>> 
>> Sent from my iPad
>> 
>> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau <[email-masked]> wrote:
>> 
>>> 
>>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" <[email-masked]> wrote:
>>> 
>>>> Alia, I do have to disagree with one aspect of your characterization fo ForCES.  While the initial design goal was forwarding behavior, the protocol design is such that it is usable over a broad range of abstraction levels.
>>>> 
>>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG may be suitable / useable.
>>> 
>>>   We are not ruling out any existing solutions, either in whole or in part (modified). The goal right now is to define the problem space and a framework of components that can be used to solve that problem.
>>> 
>>>> On the other hand, I think that working out the problems and entities that need to be modeled first (which probably does need a dedicated working group), and then worrying about which protocol meets the requirements when we know what exactly we need.  At that point, the protocol work can be done wherever appropriate.
>>> 
>>>   Yes, that is precisely what the goals are right now.
>>> 
>>>   --Tom
>>> 
>>> 
>>>> 
>>>> yours,
>>>> Jitl
>>>> 
>>>> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>>>>> Hi James,
>>>>> 
>>>>> Thanks for your thoughts.   Streaming (as I've heard) is not as good a
>>>>> description of the desired interface attributes as described in Sec
>>>>> 1.1, the functional overview.
>>>>> 
>>>>> IRS is NOT about having interfaces to the forwarding plane.  That's
>>>>> what ForCES is focused on.   This is about communication to a router
>>>>> to install/retrieve routing state into the routing system (FIB, IGPs,
>>>>> BGP, RSVP-TE, etc.)   IRS is NOT splitting the control plane from the
>>>>> router.
>>>>> 
>>>>> Are you suggesting that ForCES should drastically expand its scope?
>>>>> 
>>>>> Before we start debating what and whether to expand existing
>>>>> protocols, I think we need a common understanding of the problem we're
>>>>> trying to solve and the related framework.
>>>>> 
>>>>> Alia
>>>>> 
>>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]> wrote:

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Aug 2012 21:40:16 +0200

Hi Sue,

My below email expresses no questions or issues towards 
draft-gredler-idr-ls-distribution.

The streaming aspect of IRS framework into BGP or IGPs was questioned.

Best regards,
R.

---

From: Susan Hares <[email-masked]>
Date: Fri, 10 Aug 2012 19:42:29 +0000

Robert:

I am now confused. Can you give me more examples about the streaming aspect of IRS framework, and why you questioned it. 

Thanks,

Sue Hares 

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: Friday, August 10, 2012 12:40 PM
To: Susan Hares
Cc: Alia Atlas; Thomas Nadeau; James Kempf; Joel M. Halpern; [email-masked]; Thomas Nadeau
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Hi Sue,

Best regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Aug 2012 22:43:50 +0200

Hi Sue,

> Robert:
>
> I am now confused. Can you give me more examples about the
> streaming aspect of IRS framework, and why you questioned it.
>
> Thanks,
> Sue Hares

The IRS framework draft says streaming 9 times (just few quotes ...):

    This document describes a framework for a standard, programmatic
    interface for full-duplex, streaming state transfer in and out of the
    Internet's routing system.

+

    The IRS
    is a programmatic, streaming interface for transferring state into
    and out of the Internet's routing system,

...

4.3.1.  IGP Interfaces

    The lack of a streaming programmatic interface to the IGPs limits the
    ability of applications to influence and modify the desired behavior
    of the IGP.

...

 > and why you questioned it.

Since I am quite pessimistic about influencing and modifying behaviour 
of the control plane (example above: IGP) by some external controller 
driven by applications.

IMHO IGP should provide solid domain wide IP paths between the network 
edges and should not be subject to fluctuations on a per application basis.

Best regards,
R.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 10 Aug 2012 16:57:29 -0400

Hi Robert,

The "streaming" adjective will be gone in the next draft revision.  It
was replaced by describing the key attributes needed for the
interface.

At the IGP level, I can see applications adding in new prefixes or
data to distribute.  We have to see what else makes sense for that
sub-interface.

Alia

On Fri, Aug 10, 2012 at 4:43 PM, Robert Raszuk <[email-masked]> wrote:
> Since I am quite pessimistic about influencing and modifying behaviour of
> the control plane (example above: IGP) by some external controller driven by
> applications.
>
> IMHO IGP should provide solid domain wide IP paths between the network edges
> and should not be subject to fluctuations on a per application basis.
>
> Best regards,
> R.
>
>