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

[Chao Fu <[e-mail]>]

Hi Acee,

Rule (e) is applied only when the LSAs have same non-zero forwarding address. If they have different forwarding address, they would be ECMP instead of applying rule (e) I think.
          (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

Regards,
Chao Fu

-----Original Message-----
From: Acee Lindem (acee) [mailto:[e-mail]] 
Sent: Monday, August 15, 2016 21:39
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,
I answered too fast - you are right that a type-5 LSA path to a forwarding address cannot be accessible through an NSSA area. However, there is still the scenario where the same prefix is advertised with different forwarding addresses and everything else is equal (metrics, ASBR/Forwarding address cost, path preference, etc). In this case, the tie-breaker rule is still required. 

Thanks,
Acee

On 8/15/16, 4:57 AM, "Chao Fu" <[e-mail]> wrote:

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