Re: [irs-discuss] IRS comments

Susan Hares <> Fri, 10 August 2012 01:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0695C21F85C6 for <>; Thu, 9 Aug 2012 18:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.313
X-Spam-Status: No, score=-5.313 tagged_above=-999 required=5 tests=[AWL=1.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TGuETQgTSiJk for <>; Thu, 9 Aug 2012 18:56:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 228F321F85C5 for <>; Thu, 9 Aug 2012 18:56:13 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.2.3-GA FastPath) with ESMTP id AIS11449; Thu, 09 Aug 2012 17:56:12 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 9 Aug 2012 18:51:40 -0700
Received: from ([]) by ([]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 18:51:37 -0700
From: Susan Hares <>
To: Gert Grammel <>, Thomas Nadeau <>
Thread-Topic: [irs-discuss] IRS comments
Thread-Index: Ac1utoJXMLn1Fv5cTmO9ZkEBmEbA7gABwUJeAcg805AAKmPZAAAHCbOAAAZRSNA=
Date: Fri, 10 Aug 2012 01:51:36 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Thomas Nadeau <>, Alia Atlas <>, Lenny Giuliano <>, "" <>
Subject: Re: [irs-discuss] IRS comments
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Aug 2012 01:56:14 -0000


I'm interested in discussing the theory of the network management. Tradition Network management (ISO documents) looked at such generic ideas as configuration, performance, fault management, and monitoring. Which NM are you implying here? 

Configuration included download plus transactional (roll forward/roll-back). 

Your description does not match the current status of the IGPs or BGP implementations. 

Where do you place the Graceful-Restart or Hitless Restart or High availability work? Do you place this in a PCE or a stateful PCE? 


-----Original Message-----
From: Gert Grammel [] 
Sent: Thursday, August 09, 2012 1:00 PM
To: Thomas Nadeau; Susan Hares
Cc: Thomas Nadeau; Lenny Giuliano; Alia Atlas;
Subject: RE: [irs-discuss] IRS comments


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 [] 
Sent: Thursday, August 09, 2012 9:38 AM
To: Susan Hares
Cc: Gert Grammel; Thomas Nadeau; Lenny Giuliano; Alia Atlas;
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.


On Aug 9, 2012, at 10:57 AM, Susan Hares <> 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
> Sue
> -----Original Message-----
> From: 
> [] On Behalf Of Gert Grammel
> Sent: Monday, July 30, 2012 6:41 PM
> To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
> Cc:
> 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
> Gert
> ----- Original Message -----
> From: <>
> To: Lenny Giuliano; Alia Atlas
> Cc: <>
> 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" <> wrote:
>> Minor points:
>> -section 4, para 2, 3rd sentence, "Howeve,r"
>> -4.1.3 "There is no bidirectional programmatic interface to add,
>>   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
>>   installed state.  For instance, traffic received on an specified
>>   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
>> 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
> _______________________________________________
> irs-discuss mailing list
> _______________________________________________
> irs-discuss mailing list