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

From: Acee Lindem <[email-masked]>
Date: Thu, 11 Aug 2005 17:02:59 -0400

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
>

---

From: Erblichs <[email-masked]>
Date: Thu, 11 Aug 2005 17:09:09 -0700

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.

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

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

---

From: Dave Katz <[email-masked]>
Date: Thu, 11 Aug 2005 19:33:45 -0700

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

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.

Stub areas were a hack 15+ years ago (along with a bunch of other  
sort-sighted optimizations) but they don't seem all that useful these  
days...

--Dave

---

From: Mike Fox <[email-masked]>
Date: Fri, 12 Aug 2005 07:24:59 -0600

> stub areas even useful any longer?

Yes and yes!!!

> 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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 12 Aug 2005 11:42:05 -0400

Hi Mitchell,
Thanks for reponding - I was hoping someone would initiate some 
discussion (the
ADs always ask whether a change was discussed on the mailing list :^).
Anyway, what I'm proposing is no worse that OSPFv2. Consider the 
following points:

- The unknown LSA types in question are link or area scoped. Hence,
this implies that at least one router in the stub or NSSA area 
understands them (at
least one would hope an implementation would not originate an LSA it didn't
understand :^).
- The OSPFv2 analogy is a link or area scoped opaque LSA with unknown type.
There is no such restriction for these LSAs in OSPFv2 stub or NSSA areas.
- The mechanism is topology dependent. As long as there is a spanning 
tree of
OSPFv3 routers in the stub or NSSA understanding the LSA type, it will be
flooded to all routers in the area. If there is a real requirement to 
limit the
flooding domain, customers and vendors will implement filters which will
deterministically limit flooding.
- Experience has shown that the introducion of new OSPFv3 LSA types is
extremely slow. Hence, I don't see the need to limit the flooding to limit
database size (if there a need, see the previous point).

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Fri, 12 Aug 2005 19:26:45 -0700

Acee,

	Yes, I understand your points, however...

	If ONLY one router understands the new type,
	  I don't see the benefit of "fully accepting"
	  the new type into stub areas.

	What prevents a SIGNIFICANT FLOOD of specialized 
	unknown types?
	
	Even if a small percentage of routers in the area
	understands these unknown types, what do we gain?

	It would make sense if we had a notifcation type
	message that could be generated to reject these
	unknown types.

	I thought the reasoning for specialized areas was
	 to generate a homogeneous handing of message
	 types. Unknown types to some routers in the area
	 violates this.

	If we don't explicitly state acceptance criteria
	  for unknown types for stub area then it is a
	  defacto-standard that we have this restriction.
	  Wouldn't changing this value promote heterogeneous
	  handling of unknown types? Murphy says, by the time
	  unknown type A becomes generally supported, we
	  will have introduced unknown type B..

> >>understand the LSA type - The LSA will be in everyones database
	Ok, then why not add a mechanism for filtering these
	unknowns from the LSDBs? 

> >>->No corresponding rule for opaque LSAs

	Should we then add a defacto-standard rule?

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

---

From: Acee Lindem <[email-masked]>
Date: Sun, 14 Aug 2005 20:29:37 -0400

Mitchell,
Although we are in complete disagreement, this debate is good.
I encourage others to chime in. See my responses inline.

>	What prevents a SIGNIFICANT FLOOD of specialized 
If the one router that understands the new LSA type is connected to all the
other routers in the stub or NSSA - then the LSA is in everyone's database
anyway. It isn't as if these LSAs are coming from some distance galaxy they
are in the stub or NSSA area in question and are presumably under a single
administrative control.

>	understands these unknown types, what do we gain?
Simplicity and deterministic behavior. Also, it could ease migration if 
the application
of the new LSA isn't dependent on all routers in the area understanding it.

>	message that could be generated to reject these
I certainly wouldn't want to go there. This defeats the whole purpose of 
OSPFv3
unknown type handling.

>	Ok, then why not add a mechanism for filtering these
Filtering techniques have been implemented. They would be difficult to 
standardize
since they break some basic OSPF principles (e.g., routers within an 
area have an
identical database).

>	Should we then add a defacto-standard rule?
De facto?? This implies that it is already being used. In fact, the opposite
is true - RFC 2370 has been a PS document since July 1998 (and an 
implemented
draft for years long) and I've never heard of anyone having a requirement to
prevent unknown opaque types from being flooded in stub/NSSA areas.

---

From: Sina Mirtorabi <[email-masked]>
Date: Sun, 14 Aug 2005 23:01:06 -0700

Mitchell,

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

Obviously this is broken. As already mentioned, in OSPFv2 new opaque LSA are
flooded in Stub / NSSA therefore there is no reason trying to prevent that
in OSPFv3....

Sina

-> -----Original Message-----
-> From: Mailing List [mailto:[email-masked]] On 
-> Behalf Of Erblichs
-> Sent: Friday, August 12, 2005 7:27 PM
-> To: [email-masked]
-> Subject: Re: RFC 2370 Update and a Proposed Change to Stub 
-> Area Behavior
-> 
-> Acee,
-> 
-> 	Yes, I understand your points, however...
-> 
-> 	If ONLY one router understands the new type,
-> 	  I don't see the benefit of "fully accepting"
-> 	  the new type into stub areas.
-> 
-> 	What prevents a SIGNIFICANT FLOOD of specialized 
-> 	unknown types?
-> 	
-> 	Even if a small percentage of routers in the area
-> 	understands these unknown types, what do we gain?
-> 
-> 	It would make sense if we had a notifcation type
-> 	message that could be generated to reject these
-> 	unknown types.
-> 
-> 	I thought the reasoning for specialized areas was
-> 	 to generate a homogeneous handing of message
-> 	 types. Unknown types to some routers in the area
-> 	 violates this.
-> 
-> 	If we don't explicitly state acceptance criteria
-> 	  for unknown types for stub area then it is a
-> 	  defacto-standard that we have this restriction.
-> 	  Wouldn't changing this value promote heterogeneous
-> 	  handling of unknown types? Murphy says, by the time
-> 	  unknown type A becomes generally supported, we
-> 	  will have introduced unknown type B..
-> 
-> > >>->As long as there is an intra-area spanning tree of routers that
-> > >>understand the LSA type - The LSA will be in everyones database
-> > >>
-> 	Ok, then why not add a mechanism for filtering these
-> 	unknowns from the LSDBs? 
-> 
-> > >>->No corresponding rule for opaque LSAs
-> 
-> 	Should we then add a defacto-standard rule?
-> 
-> 	Mitchell Erblich
-> 	--------------------
-> 
-> 	
-> Acee Lindem wrote:
-> > 
-> > Hi Mitchell,
-> > Thanks for reponding - I was hoping someone would initiate some 
-> > discussion (the ADs always ask whether a change was 
-> discussed on the 
-> > mailing list :^).
-> > Anyway, what I'm proposing is no worse that OSPFv2. Consider the 
-> > following points:
-> > 
-> > - The unknown LSA types in question are link or area 
-> scoped. Hence, 
-> > this implies that at least one router in the stub or NSSA area 
-> > understands them (at least one would hope an 
-> implementation would not 
-> > originate an LSA it didn't understand :^).
-> > - The OSPFv2 analogy is a link or area scoped opaque LSA 
-> with unknown type.
-> > There is no such restriction for these LSAs in OSPFv2 stub 
-> or NSSA areas.
-> > - The mechanism is topology dependent. As long as there is 
-> a spanning 
-> > tree of
-> > OSPFv3 routers in the stub or NSSA understanding the LSA 
-> type, it will 
-> > be flooded to all routers in the area. If there is a real 
-> requirement 
-> > to limit the flooding domain, customers and vendors will implement 
-> > filters which will deterministically limit flooding.
-> > - Experience has shown that the introducion of new OSPFv3 
-> LSA types is 
-> > extremely slow. Hence, I don't see the need to limit the 
-> flooding to 
-> > limit database size (if there a need, see the previous point).
-> > 
-> > Thanks,
-> > Acee
-> > 
-> > Erblichs wrote:
-> > 
-> > >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
-> > >>>
-> > >>>
-> > >>>
-> > >
-> > >
-> > >
->

---

From: Russ White <[email-masked]>
Date: Mon, 15 Aug 2005 17:28:37 -0400

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

> routers have to understand the new LSA

Correct.

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.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Acee Lindem <[email-masked]>
Date: Mon, 15 Aug 2005 21:08:39 -0400

Hi Russ,

Russ White wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
I agree completely here.

>willing to accept the possible negative consequences from this action.
For stub areas, the ABR still won't allow any AS scoped LSAs to enter 
the area. The LSAs
in question are always understood and originated by at least one router 
in the stub or NSSA
area.

Thanks,
Acee

>-----BEGIN PGP SIGNATURE-----
>Version: PGP Desktop 9.0.2 (Build 2424)
>
>iQA/AwUBQwEJDBEdu7FIVPTkEQK5YQCffvjVDjTfbSjZq/NAxSpqgMG7RfQAoLOK
>c+Q2GrKYlQwY2zd1P3sfdDqD
>=hjsk
>-----END PGP SIGNATURE-----
>
>  
>