Found 1 record.
Status: Rejected (1)
RFC 3101, "The OSPF Not-So-Stubby Area (NSSA) Option", January 2003Source of RFC: ospf (rtg)
Errata ID: 4767
Publication Format(s) : TEXT
Reported By: Chao Fu
Date Reported: 2016-08-08
Rejected by: Alia Atlas
Date Rejected: 2016-08-08
Section 2.5.(6).(e) says:
(e) If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred: 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. [NSSA]
It should say:
NULL (it should be deleted because no LSAs would be compared here.)
If one LSA is Type-5 and the other is Type-7, one of them would be rejected at step (2.5.(3) ( please refer to OSPF mail list: https://mailarchive.ietf.org/arch/msg/ospf/KBoh5T75o-s7n_bL1knrc6uVlTs ). If both of them are Type-7 LSAs, one of them would be flushed according 2.4:
If two NSSA routers, both
reachable from one another over the NSSA, originate functionally
equivalent Type-7 LSAs (i.e., same destination, cost and non-zero
forwarding address), then the router having the least preferred LSA
should flush its LSA.
As a result, rule (e) would never be applied and should be removed.
It is easy to envision a topology where an ABR for an NSSA receives an NSSA-LSA from an NSSA internal router and an AS-Exernal-LSA from originating routers that do not receive each others equivalent LSAs. Furthermore, even if this were not the case, the referenced text refers to LSAs that are both NSSA-LSAs as opposed to a
mixture of an NSSA-LSA and an AS-External-LSA.