Re: [irs-discuss] IRS comments

[Alia Atlas <[e-mail]>]

I do agree - and trying to describe IRS can be hard because of
confusion as to whether it is a configuration protocol or ...

It's really to support programmable networks - I rather like the idea
of describing it as Network Programming Plane...

Alia

On Mon, Jul 30, 2012 at 10:05 PM, Gert Grammel <[e-mail]> wrote:
> Alia,
>
> My point was not about the abbreviation. It was about positioning IRS.
> In the end IRS is not yet another MIB nor just another IGP extension.
>
> Gert
>
>
>
>
> ----- Original Message -----
> From: Alia Atlas <[e-mail]>
> To: Gert Grammel
> Cc: [e-mail] <[e-mail]>
> Sent: Tue Jul 31 02:44:35 2012
> Subject: Re: [irs-discuss] IRS comments
>
> We can consider other namings, whether NPP or RSI or other suggestions.
>
> I think we still have a bit of time and discussion for the
> requirements before we have to finalize that.
>
> Alia
>
> On Mon, Jul 30, 2012 at 9:40 PM, Gert Grammel <[e-mail]> wrote:
>> Tom,
>>
>> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
>> To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP.
>> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
>> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.
>>
>>
>> Gert
>>
>>
>>
>>
>> ----- Original Message -----
>> From: [e-mail] <[e-mail]>
>> To: Lenny Giuliano; Alia Atlas
>> Cc: [e-mail] <[e-mail]>
>> Sent: Tue Jul 31 01:50:40 2012
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>> [Re-adding IRS]
>>
>>         Thank you for reviewing and the comments. We will incorporate the edits
>> in the next rev.
>>
>>         --Tom
>>
>>
>> On 7/30/12 5:04 PM, "Lenny Giuliano" <[e-mail]> wrote:
>>
>>>
>>>Minor points:
>>>
>>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>>
>>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>>    remove or read state from the multicast RIB."
>>>       -How is this unique to mcast?  Couldn't you say the same thing
>>>       about unicast?
>>>
>>>-4.1.3 "The multicast state added need not match to well-known protocol
>>>    installed state.  For instance, traffic received on an specified set,
>>>    or all, interfaces that is destined to a particular prefix from all
>>>    sources or a particular prefix could be subject to the specified
>>>    replication."
>>>       -Not clear to me at all what this para is saying.
>>>
>>>-"IRS"- you may want to select a different acronym that isn't related to
>>>something as unpopular as taxation (something we learned with AMT).
>>>Maybe
>>>RSI instead...
>>>
>>>Overall, I found the doc to be clearly written and straightforward.
>>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>>didn't mention Openflow, but it did seem like an elephant in the room as
>>>I
>>>was reading thru.  Also, I did wonder what was new and novel here, as
>>>this
>>>sounded like our SDK which has been around for years.
>>>
>>>
>>>-Lenny
>>
>> _______________________________________________
>> 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