Re: [irs-discuss] IRS comments

[Gert Grammel <[e-mail]>]

Susan,

The difference of a NP-plane compared to control and management planes
can best be explained by describing a power cycle:
- The Management plane supervises (Monitoring and Alarms), and when
configuring, it creates persistent state in the switching element as
well as in the Management plane itself. In other words state that
remains in the box (switch and NMS) even after a power cycle. 

- A control plane behaves differently. After a power cycle the switching
element needs to re-learn state from its peers.

- The NPP is a strange hybrid, it can create persistent state in the NPP
but not in the switching element. In other words, if you re-start the
NPP, all configuration comes up as of before. If you re-start the
switching element, it needs to synch up with NPP.

A nice example for a NPP function is e.g. a centralized PCE server. You
can create a lot of persistent rules and parameters there on how to
calculate the path. Those parameters will remain in the PCE-server even
after a PCE-server re-start. Yet the PCE doesn't create persistent
information in the switching elements. If those re-start, they'll have
to re-synch. 

I am well aware that in the past folks positioned various elements (PCE,
RR, IRS, ...) either as part of the Control Plane or a part of the
management plane. And yes, positioning is not an exact science.
Nevertheless I believe that it is now time to give a class name to those
vagabonding objects. 

-- Gert


-----Original Message-----
From: Thomas Nadeau [mailto:[e-mail]] 
Sent: Thursday, August 09, 2012 9:38 AM
To: Susan Hares
Cc: Gert Grammel; Thomas Nadeau; Lenny Giuliano; Alia Atlas;
[e-mail]
Subject: Re: [irs-discuss] IRS comments

We intended for irs to need both read and write capabilities, hence our
use of "bidirectional" in describing the interface characteristics in
the problem statement.  One big difference between existing "network
management" and what we are trying to specify now is real-time
transactional capabilities.

Tom 



On Aug 9, 2012, at 10:57 AM, Susan Hares <[e-mail]> wrote:

> 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
>