Hi Acee,
Yes the text indicating to purge the functionally equivalent type-7 LSA is a
lowercase “should” as opposed to an Uppercase “MUST". However, it is introduced
according to 12.4.4.1 of RFC 2328 which says "must" for the similar case of ASE
LSAs as
"it must be unambiguously
defined as to which router originates the LSAs"
Then I guess it is better to treat it as "must" as RFC 2328.
At the same time, when the equivalent LSA is flushed, in RFC 2328 there is no
rule for ASE calculation similar to rule (e) to get a preferred path during the
window of flushing the LSA. Then in this case, if rule (e) is important and
necessary, it should be added in RFC 2328. If not, maybe we could just ignore
it in RFC 3101.
Regards,
Chao Fu
-----Original Message-----
From: Acee Lindem (acee) [mailto:[email protected]]
Sent: Wednesday, August 17, 2016 23:59
To: Chao Fu <[email protected]>; RFC Errata System
<[email protected]>; [email protected]; [email protected];
[email protected]; Alvaro Retana (aretana) <[email protected]>; Abhay Roy (akr)
<[email protected]>
Cc: [email protected]
Subject: Re: [Technical Errata Reported] RFC3101 (4767)
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 protected]> 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.
> (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 protected]]
>Sent: Monday, August 15, 2016 21:39
>To: Chao Fu <[email protected]>; RFC Errata System
><[email protected]>; [email protected]; [email protected];
>[email protected]; Alvaro Retana (aretana) <[email protected]>; Abhay Roy
>(akr) <[email protected]>
>Cc: [email protected]
>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
>
>On 8/15/16, 4:57 AM, "Chao Fu" <[email protected]> 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:[email protected]]
>>Sent: Friday, August 12, 2016 00:46
>>To: Chao Fu <[email protected]>; RFC Errata System
>><[email protected]>; [email protected]; [email protected];
>>[email protected]; Alvaro Retana (aretana) <[email protected]>; Abhay Roy
>>(akr) <[email protected]>
>>Cc: [email protected]
>>Subject: Re: [Technical Errata Reported] RFC3101 (4767)
>>
>>Hi Chao,
>>
>>On 8/11/16, 5:22 AM, "Chao Fu" <[email protected]> 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 protected]]
>>>Sent: Monday, August 08, 2016 19:15
>>>To: RFC Errata System <[email protected]>;
>>>[email protected]; [email protected]; [email protected]; Alvaro
>>>Retana
>>>(aretana) <[email protected]>; Abhay Roy (akr) <[email protected]>
>>>Cc: Chao Fu <[email protected]>; [email protected]
>>>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" <[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_bL1knrc6uVl
>>>>T
>>>>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
>>>>
>>>
>>
>
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
