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

[Acee Lindem <[e-mail]>]

I'd have to agree that stub and NSSA areas are still beneficial. Even if 
all of the
routers in the routing domain could accommodate all the LSAs, there is 
still a benefit
in being able break up the routing domain into smaller areas with 
reduced flooding
and simplified routing. NSSAs have additional benefits in being able to 
partition (with
limitations) your routing domain into sub-domains sharing a common 
backbone (a la
Pat Murphy's network).

Thanks,
Acee

Andrew Smith wrote:

>Stub areas are very useful. Some networks, such as cable modem networks,
>branch out from the core of the network like tree roots. Some providers
>choose to run OSPF on the Layer 3 CMTSs which may or may not be able to
>handle thousands of routes.
>
>I have used Stub and NSSA areas in these situations with very good
>results. The routers and CMTSs are quite peaceful with only a few
>hundred intra-area routes.
>
>Unless you have a network full of high-end routers I recommend using
>Stub or NSSA areas on segments of the network that don't require a full
>routing table or a full view of the routing domain. It can increase
>operational stability of the network.
>
>Regards,
>Andy Smith
>
>-----Original Message-----
>From: Mailing List [mailto:[e-mail]] On Behalf Of Dave
>Katz
>Sent: Thursday, August 11, 2005 10:34 PM
>To: [e-mail]
>Subject: Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior
>
>
>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
>
>
>On Aug 11, 2005, at 5:09 PM, 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
>>>>
>>>>
>>>>        
>>>>
>>    
>>
>
>  
>