Re: [OSPF] [Technical Errata Reported] RFC3101 (4767)

[Chao Fu <[e-mail]>]

Hi Acee,

Thank you very much for the clarification. If so, does it mean 2.5.(3) could be more exact to remove " Type-5 capable area" from following words?
          " For a Type-5 LSA the matching
          routing table entry must specify an intra-area or inter-area
          path through a Type-5 capable area "

IMO a Type-5 capable area does not include NSSA area nor stub area from the definition in RFC 3101 Section 1.3, the second paragraph. 
"   The OSPF specification defines two general classes of area
   configuration.  The first allows Type-5 LSAs to be flooded throughout
   the area.  In this configuration, Type-5 LSAs may be originated by
   routers internal to the area or flooded into the area by area border
   routers.  These areas, referred to herein as Type-5 capable areas (or
   just plain areas in the OSPF specification) "

Regards,
Chao Fu

-----Original Message-----
From: Acee Lindem (acee) [mailto:[e-mail]] 
Sent: Friday, August 12, 2016 00:46
To: Chao Fu <[e-mail]>; RFC Errata System <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Alvaro Retana (aretana) <[e-mail]>; Abhay Roy (akr) <[e-mail]>
Cc: [e-mail]
Subject: Re: [Technical Errata Reported] RFC3101 (4767)

Hi Chao, 

On 8/11/16, 5:22 AM, "Chao Fu" <[e-mail]> wrote:

>Hi Acee,
>
>If my understanding is correct, you said there is the topology that an 
>ABR receives one NSSA LSA and one ASE LSA with the same destination, 
>cost and non-zero forwarding address.  It is right but when doing 
>external route calculation, one of it would be rejected according to 2.5.(3):
>          If the forwarding address is non-zero look up the forwarding
>          address in the routing table.  For a Type-5 LSA the matching
>          routing table entry must specify an intra-area or inter-area
>          path through a Type-5 capable area.  For a Type-7 LSA the
>          matching routing table entry must specify an intra-area path
>          through the LSA's originating NSSA.
>Then the path to the forwarding address cannot be through a Type-5 
>capable area and an NSSA area at the same time, which means one of them 
>would be ignored here and no chance to match rule (e).

With this respect to this reasoning, your understanding is incorrect. If the FA path is via a intra-area NSSA route (which it would be for an NSSA ABR), then it would be pass the reachability test for both the NSSA-LSA and the AS-External LSA.

Thanks,
Acee 


>
>At the same time, rule (e) is not  only defined to check the mixture of 
>an ASE LSA and an NSSA LSA, and then it is possible to compare two ASE 
>LSAs or two NSSA LSAs. But the referenced text describes that no such 
>two NSSA LSAs exist because one of them should be flushed. 
>Consequently, the condition of rule (e) will never be matched and then 
>it is a redundant rule.
>
>If rule (e) is not valid, I guess it is better to record it somewhere, 
>otherwise some conformance testers always want to verify it, that is 
>the reason why I would like to report the errata. If my understanding 
>on rule
>(e) is wrong, please correct me and I will appreciate it very much.
>
>Thanks & best Regards,
>Chao Fu
>
>-----Original Message-----
>From: Acee Lindem (acee) [mailto:[e-mail]]
>Sent: Monday, August 08, 2016 19:15
>To: RFC Errata System <[e-mail]>; 
>[e-mail]; [e-mail]; [e-mail]; Alvaro Retana 
>(aretana) <[e-mail]>; Abhay Roy (akr) <[e-mail]>
>Cc: Chao Fu <[e-mail]>; [e-mail]
>Subject: Re: [Technical Errata Reported] RFC3101 (4767)
>
>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" <[e-mail]>
>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 <[e-mail]>
>>
>>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
>>
>