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

Erblichs <erblichs@EARTHLINK.NET> Fri, 12 August 2005 00:13 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3NB9-0002MI-6k for ospf-archive@megatron.ietf.org; Thu, 11 Aug 2005 20:13:43 -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 UAA07891 for <ospf-archive@LISTS.IETF.ORG>; Thu, 11 Aug 2005 20:13:41 -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 <1.010C890F@cherry.ease.lsoft.com>; Thu, 11 Aug 2005 20:13:38 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82216229 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Aug 2005 20:13:37 -0400
Received: from 207.69.195.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 11 Aug 2005 20:13:37 -0400
Received: from h-68-164-89-195.snvacaid.dynamic.covad.net ([68.164.89.195] helo=earthlink.net) by pop-gadwall.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1E3NB2-0002vk-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Aug 2005 20:13:37 -0400
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <42778DFC.4060107@cisco.com> <42FBBD03.6090004@cisco.com>
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <42FBE8A5.916FCADE@earthlink.net>
Date: Thu, 11 Aug 2005 17:09:09 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA07891

Group,

	I vote NOT to remove the restriction on the
flooding of unknown LSAs into stub area. I vote for
#2 or #3. Sorry, I have not spent any major time looking
at the pros / cons between the later 2.

Why?
    1) The primary reason is that some of the these LSAs
       are unknown to a percentage of the routers within
       the stub area. Even the "attempt" to limit them
       would follow the reason to limit the database size,
       memory requirements, sizing of OSPF control packets,
       etc... This limit is suggested in the 1st paragraph
       of every OSPF v2 RFC. A copy is in the middle of this
	email.

     2) What is an unknown LSA? What LSA type greater than
	X is an unknown? What help is it by having just 1
	router understand it? Can they equal in number
	over time External-LSAs and be totally useless in
	our env? Where should we put the older routers that
	we want to isolate from our network?

     3) Is is possible to have 30% - 90% of LSAs in a router's
	db be present in a stub area, be unknown LSAs? Shouldn't
	their be an attempt to limit this percentage?

	3b) Could we be using / spending a large percentage
	    of our OSPF control packet time / resources
	    handling unknown LSAs?

     4) Backward compatibility.. I would assume that most
	environments would not like to just start seeing
	something new in their network just show up.

	"An area can be configured as a stub when there is a single exit
        point from the area, or when the choice of exit point need not
        be made on a per-external-destination basis."

	Lets look at the third word, can. It would be different
	if we used the word SHOULD or MUST.

	Thus, if a area that CAN be configured as a stub wishes
	to process unknown LSAs, then why not configure the
	without the STUB area identification? Wouldn't this allow
	for backward capability? Yes, we then allow AS-external-LSAs
	in this non named stubby area.

	Or create a new "stubby area" type that accepts or
	not accept, xyz type LSAs. This new area type would then be
	allowed to accept new LSAs as they show up? The diff
	would be that "unknown LSAs" have no restrictions and
	could consume the majority of the router's LSDB.


	Mitchell Erblich
	-----------------------


RFC 1247, 1583, 2178, 2328 : OSPFv2.
---------
3.6 Supporting stub areas

In some Autonomous Systems, the majority of the topological database may
consist of external advertisements.  An OSPF external advertisement is
usually flooded throughout the entire AS.  However, OSPF allows certain
areas to be configured as "stub areas".  External advertisements are not
flooded into/throughout stub areas; routing to AS external destinations
in these areas is based on a (per-area) default only.  This reduces the
topological database size, and therefore the memory requirements, for a
stub area's internal routers.


==========================

========================

Acee Lindem wrote:
> 
> At the 63rd IETF in Paris, I proposed that we remove the restriction on the
> flooding of unknown LSAs into stub areas. Here is an excerpt from the
> presentation:
> 
> - Section 2.9 mandates that an OSPFv3 router should NOT advertise an
> unknown LSA if the U bit is set to “1” – flood as if known.
> ->Should be removed in RFC 2740 respin.
> ->Limits backward compatibility for new LSA types
> ->No corresponding rule for opaque LSAs
> ->Fact that LSA is flooded at all implies one router is stub/NSSA
> understands it.
> ->Ineffective/non-deterministic database limit
> ->As long as there is an intra-area spanning tree of routers that
> understand the LSA type - The LSA will be in everyones database
> 
> Comments? Speak now if you wish to retain the current stub area restriction.
> My intent is to deprecate it with an appendix documenting it's removal.
> 
> Thanks,
> Acee
> 
> Acee Lindem wrote:
> 
> > In the evolution of the OSPFv2 protocol specification
> > (RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous
> > bugs were fixed and some protocol behaviors were altered. Examples
> > include the metric cost for area ranges and the selection of the
> > ASBR for AS external route computation.
> >
> > In the context of documenting the OSPFv3 NSSA differences I've
> > looked again at section 2.10 and I really think the idea of not flooding
> > unknown LSA types with the U-bit set to 1 is broken. I think it breaks
> > the whole idea of being able to introduce new LSA types in a backward
> > compatible fashion. Furthermore, it won't stop the leakage of these
> > unknown LSAs when some routers understand them and others do not -
> > it all depends on whether you have a spanning tree of routers that
> > understand them. Since the LSAs in question are area scoped or link
> > scoped, it implies that at least one router (the originator)
> > understands the
> > new type and you will have a mixture. IMHO, this is broken. I've had
> > some discussions with others who agree. At this juncture,
> > we have 3 alternatives:
> >
> > 1) Remove the restriction for that unknown LSAs with the U-bit
> > set to 0 for stub areas.
> > 2) Extend the broken restriction to NSSAs in the update.
> > 3) Limit the damage to stub areas and only restrict AS scoped LSAs
> > from NSSAs.
> >
> > Of course, I'd vote for #1 or I wouldn't be sending this E-mail.
> >
> > Thanks,
> > Acee
> >