Re: [irs-discuss] IRS Problem Statement Posted

[Alia Atlas <[e-mail]>]

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

On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares <[e-mail]> wrote:
> 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:[e-mail]]
> Sent: Monday, July 30, 2012 6:40 PM
> To: Susan Hares
> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [e-mail]
> 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 <[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
>> _______________________________________________
>> irs-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/irs-discuss