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

["Acee Lindem (acee)" <[e-mail]>]

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