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

Russ White <riw@CISCO.COM> Mon, 15 August 2005 21:38 UTC

Received: from ([] by with esmtp (Exim 4.32) id 1E4mfR-0006fL-Jv for; Mon, 15 Aug 2005 17:38:49 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id RAA06028 for <ospf-archive@LISTS.IETF.ORG>; Mon, 15 Aug 2005 17:38:47 -0400 (EDT)
Received: from ( by (LSMTP for Digital Unix v1.1b) with SMTP id <>; Mon, 15 Aug 2005 17:38:47 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82662305 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Aug 2005 17:38:48 -0400
Received: from by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 15 Aug 2005 17:28:48 -0400
Received: from ( by with ESMTP; 15 Aug 2005 17:28:46 -0400
X-IronPort-AV: i="3.96,108,1122868800"; d="scan'208"; a="66577148:sNHT28364948"
Received: from russpc ( []) by (8.12.10/8.12.6) with ESMTP id j7FLSgT7016482 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 15 Aug 2005 17:28:43 -0400 (EDT)
Received: from [] by russpc (PGP Universal service); Mon, 15 Aug 2005 17:28:44 -0500
X-PGP-Universal: processed; by russpc on Mon, 15 Aug 2005 17:28:44 -0500
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <>
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID: <>
Date: Mon, 15 Aug 2005 17:28:37 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Russ White <riw@CISCO.COM>
Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior
In-Reply-To: <>
Precedence: list

Hash: SHA1

First, I'll comment that I believe stub areas are still useful....

> If an application requires an area flooding scope, typically its LSA will
> have the U-bit set so that the LSA be flooded as if it was understood and
> avoiding the requirement that all routers understand the new LSA. With the
> current specification in 2740, we cannot define new LSA with area flooding
> scope for Stub / NSSA unless the U-bit is clear therefore this cause two
> issues
> - We cannot have incremental deployment for a given application
> - We would be defining two LS type for the same application as U-bit will be
> set for regular areas and U-bit will be clear for Stub/ NSSA where all
> routers have to understand the new LSA


I do see some merit in suggesting that an implemenation MAY filter
unknowns at a stub area ABR, as long as the network implementor is
willing to accept the possible negative consequences from this action.



- -- CCIE <>< Grace Alone

Version: PGP Desktop 9.0.2 (Build 2424)