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

From: RFC Errata System <[email-masked]>
Date: Sun, 7 Aug 2016 20:50:16 -0700 (PDT)

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

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 8 Aug 2016 11:14:36 +0000

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-masked]> wrote:

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 11 Aug 2016 16:46:19 +0000

Hi Chao, 

On 8/11/16, 5:22 AM, "Chao Fu" <[email-masked]> 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:[email-masked]]
>Sent: Monday, August 08, 2016 19:15
>To: RFC Errata System <[email-masked]>; [email-masked];
>[email-masked]; [email-masked]; Alvaro Retana (aretana)
><[email-masked]>; Abhay Roy (akr) <[email-masked]>
>Cc: Chao Fu <[email-masked]>; [email-masked]
>Subject: Re: [Technical Errata Reported] RFC3101 (4767)
>
>an AS-Exernal-LSA from originating routers that do not receive each
>others equivalent LSAs. Furthermore, even if this were not the case, the
>>The following errata report has been submitted for RFC3101, "The OSPF
>>Not-So-Stubby Area (NSSA) Option".
>>
>>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.
>>

---

From: Chao Fu <[email-masked]>
Date: Mon, 15 Aug 2016 08:57:24 +0000

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:[email-masked]] 
Sent: Friday, August 12, 2016 00:46
To: Chao Fu <[email-masked]>; RFC Errata System <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Alvaro Retana (aretana) <[email-masked]>; Abhay Roy (akr) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Technical Errata Reported] RFC3101 (4767)

Hi Chao, 

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

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

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 

>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.
>
>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
>To: RFC Errata System <[email-masked]>; 
>[email-masked]; [email-masked]; [email-masked]; Alvaro Retana 
>(aretana) <[email-masked]>; Abhay Roy (akr) <[email-masked]>
>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
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 15 Aug 2016 13:38:36 +0000

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" <[email-masked]> 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?
>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.
>To: Chao Fu <[email-masked]>; RFC Errata System
><[email-masked]>; [email-masked]; [email-masked];
>[email-masked]; Alvaro Retana (aretana) <[email-masked]>; Abhay Roy
>(akr) <[email-masked]>
>Cc: [email-masked]

---

From: Chao Fu <[email-masked]>
Date: Tue, 16 Aug 2016 01:35:55 +0000

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:[email-masked]] 
Sent: Monday, August 15, 2016 21:39
To: Chao Fu <[email-masked]>; RFC Errata System <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Alvaro Retana (aretana) <[email-masked]>; Abhay Roy (akr) <[email-masked]>
Cc: [email-masked]
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" <[email-masked]> wrote:

>>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.
>>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
>>
>>>https://mailarchive.ietf.org/arch/msg/ospf/KBoh5T75o-s7n_bL1knrc6uVlT
>>>s
>>>).

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 17 Aug 2016 15:58:41 +0000

Hi Chao,
Yes - you are right that this rule only applies to functionally the same
LSAs.

For rule (e): 

      - I agree that type 5 LSAs would not be applicable since the
forwarding address in this case would be through the NSSA if it is the
same. 
      - However, since the text indicating to purge the functionally
equivalent type-7 LSA is a lowercase “should” as opposed to an Uppercase
“MUST”, this tie-breaker should match the type 7 precedence rules.
Additionally, even if the equivalent LSA is flushed, it is desirable pick
the preferred LSA during the window prior to it being flushed. Hence, the
only change would be to removed “2. A Type-5 LSA.”

Thanks,
Acee

On 8/15/16, 9:35 PM, "Chao Fu" <[email-masked]> wrote:

>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.
>Subject: Re: [Technical Errata Reported] RFC3101 (4
>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
>