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

[Dave Katz <[e-mail]>]

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
>>>
>>>
>
>