[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

Erblichs wrote:

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?


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.


Even if a small percentage of routers in the area
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.

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


I certainly wouldn't want to go there. This defeats the whole purpose of OSPFv3
unknown type handling.

	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?

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


->No corresponding rule for opaque LSAs



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.


	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