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