Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior

Mike Fox <mjfox@US.IBM.COM> Fri, 12 August 2005 13:24 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZWh-000753-4E for ospf-archive@megatron.ietf.org; Fri, 12 Aug 2005 09:24:47 -0400
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21487 for <ospf-archive@LISTS.IETF.ORG>; Fri, 12 Aug 2005 09:24:44 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010C92A4@cherry.ease.lsoft.com>; Fri, 12 Aug 2005 9:24:44 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82294639 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Aug 2005 09:24:42 -0400
Received: from 32.97.110.133 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 12 Aug 2005 09:24:42 -0400
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j7CDOgWY219798 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 12 Aug 2005 09:24:42 -0400
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7CDOQhh533518 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 12 Aug 2005 07:24:26 -0600
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j7CDOf2f021318 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 12 Aug 2005 07:24:41 -0600
Received: from [9.17.195.144] (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j7CDOfBe021312 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 12 Aug 2005 07:24:41 -0600
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
X-MIMETrack: S/MIME Sign by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 08/12/2005 09:25:39 AM, Serialize by Notes Client on Mike Fox/Raleigh/IBM(Release 6.0.2CF1|June 9, 2003) at 08/12/2005 09:25:39 AM, Serialize complete at 08/12/2005 09:25:39 AM, S/MIME Sign failed at 08/12/2005 09:25:39 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V70_M6_06302005 Beta 4|June 30, 2005) at 08/12/2005 07:25:02, Serialize complete at 08/12/2005 07:25:02
Content-Type: multipart/alternative; boundary="=_alternative 0049C29F8525705B_="
Message-ID: <OFBCC5FEE9.52523A12-ON8525705B.00486E77-8525705B.0049C2A2@us.ibm.com>
Date: Fri, 12 Aug 2005 07:24:59 -0600
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mike Fox <mjfox@US.IBM.COM>
Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <D04CF6BF-A60F-4F61-AC4A-5EFCC488A7A1@juniper.net>
Precedence: list

Dave Katz wrote: 

> I guess the broader question is, does this really matter at all?  Are 
> stub areas even useful any longer?

Yes and yes!!!

> Once upon a time, routers were memory-starved little boxes, but it's 
> not clear to me at this point why anybody actually needs stub areas, 
> unless they're still running AGS+'s someplace.

Not every box running OSPF is a router.  My platform, z/OS, is an example. 
 It is far from a "memory-started little box." However its main purpose is 
to be an application host but it runs OSPF in support of value-added 
features like sysplex and dynamic VIPA, and also to optimize failover 
recovery and interactions with its routers, etc.  Our customers often need 
to run OSPF but they want to devote as few resources to it as they can 
because they want to spend the cycles running databases, CICS, IMS, and 
other business applications.  For several years we have been recommending 
that our customers put our boxes into totally stubby areas whenever 
possible, and have gotten very positive results with that setup. 

So given the above you may not be surprised to learn that my preference is 
to NOT allow unknown LSAs (or any additional LSA type) in stub areas.  We 
don't support NSSA on our platform so I don't really have an opinion on 
what you do with that. 

Mike
-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA