This Errata should be rejected as 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.
Thanks, Acee On 8/7/16, 11:50 PM, "RFC Errata System" <[email protected]> wrote: >The following errata report has been submitted for RFC3101, >"The OSPF Not-So-Stubby Area (NSSA) Option". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3101&eid=4767 > >-------------------------------------- >Type: Technical >Reported by: Chao Fu <[email protected]> > >Section: 2.5.(6).(e) > >Original Text >------------- > (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] > >Corrected Text >-------------- >NULL (it should be deleted because no LSAs would be compared here.) > >Notes >----- >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. > >Instructions: >------------- >This erratum is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC3101 (draft-ietf-ospf-nssa-update-11) >-------------------------------------- >Title : The OSPF Not-So-Stubby Area (NSSA) Option >Publication Date : January 2003 >Author(s) : P. Murphy >Category : PROPOSED STANDARD >Source : Open Shortest Path First IGP >Area : Routing >Stream : IETF >Verifying Party : IESG > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
