Re: [irs-discuss] IRS comments

[Robert Raszuk <[e-mail]>]

Hi Sue,

I am not sure about the division you are drawing. Consider SNMP ... it 
has both "get" and "set".

I think for IRS or for any SDN application the below must be combined 
and the boundary you have drawn removed.

Best,
R.

> Gert:
>
> How do you characterize network management?  Traditionally network
> management has been viewed in the IETF in two streams:  monitoring
> (active or passive) and configuration.
>
> What parts of these features do you think the IRS system needs to
> avoid?
>
> Sue
>
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Gert Grammel Sent:
> Monday, July 30, 2012 6:41 PM To: Thomas Nadeau; Lenny Giuliano; Alia
> Atlas Cc: [e-mail] Subject: Re: [irs-discuss] IRS
> comments
>
> 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
> _______________________________________________ irs-discuss mailing
> list [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>