Hi, Acee: The discussion in this thread is related to the "...the WG discussions of new drafts to signal unreachability outside the area... " The discussion for the "......any usage of LSInfinity within that area...... " is at this thread https://mailarchive.ietf.org/arch/msg/lsr/Z0rlEGlIyzYAXOdl7ZQ75POIerw/
All are related to the usages of LSInfinity and its potential updates to RFC 8362. >From the current two threads, we can get the following conclusions: 1) The current usages of LSInfinity (introduced originally in RFC2328, inherited by RFC 5340, should be constrained to its actual meanings ----"Don't parse the associated LSA, or Premature the associated LSA"-----, or even deprecated it, because of the following second conclusion: 2) It is problematic to expand/inherit such definition within RFC8362, because the intra- and inter- LSA use the same length of metric fields. I think we can find other solutions for the proposals that based on the "LSInfinity", if not, please state them on the list, let's discuss them and accomplish such aims. Best Regards Aijun Wang China Telecom -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Acee Lindem (acee) Sent: Saturday, October 15, 2022 1:48 AM To: Aijun Wang <[email protected]> Cc: Huzhibo <[email protected]>; Peter Psenak (ppsenak) <[email protected]>; [email protected] Subject: Re: [Lsr] RFC 8362 and LSInfinity Hi Aijun, On 10/13/22, 6:53 AM, "Aijun Wang" <[email protected]> wrote: Hi, Acee and Peter: I think you all misunderstood the intent of his scenario. The correct understanding are the followings: 1) When aggregate route is configured in the ABR, the specified detail route should be withdrawn. 2) ABR can withdraw the advertised LSA that describes the specific detail route, via premature mechanism(MaxAge or LSInfinity, the former is preferred according to RFC2328) 3) But, withdrawn such specific LSA doesn’t mean the corresponding detail route unreachable——This destination can be reached via the aggregate route advertised by ABR instead. This is the original usage of LSInfinity defined in RFC2327. It should be expanded further. How to apply it in RFC8362 is another issue, as indicated my responses in another thread. In summary, again, we should constrain or depreciate the confusion usages of LSInfinity. The lack of visibility into the another area due to summarization is independent of any usage of LSInfinity within that area. This is also independent of the WG discussions of new drafts to signal unreachability outside the area. Thanks, Acee Aijun Wang China Telecom > On Oct 13, 2022, at 18:07, Acee Lindem (acee) <[email protected]> wrote: > > Hi Zhibo, > > On 10/13/22, 2:26 AM, "Lsr on behalf of Huzhibo" <[email protected] on behalf of [email protected]> wrote: > > Hi LSR: > > LSInfinity > The metric value indicating that the destination described by an > LSA is unreachable. Used in summary-LSAs and AS-external-LSAs > > I want to clarify the meaning of unreachable in LSifinity, > Assume that a node advertise specific route of 1.1.1.1/32, and an aggregate route 1.1.0.0/16 is configured. > This node should premature aging of the 1.1.1.1/32 LSA. > If this node using LSInfinity metric instead of prematuring aging, route 1.1.1.1/32 is still reachable. > Therefore, the "unreachable" described by LSifinity is not really unreachable. > > If your OSPF implementation includes unreachable LSAs in the summary cost computation, it is indeed broken. > > Thanks, > Acee > > Thanks > Zhibo hu > >> -----Original Message----- >> From: Lsr [mailto:[email protected]] On Behalf Of Peter Psenak >> Sent: Wednesday, October 5, 2022 5:32 PM >> To: [email protected] >> Subject: [Lsr] RFC 8362 and LSInfinity >> >> Hi Folks, >> >> metric of LSInfinity (0xFFFFFF) has been defined in RFC2328: >> >> LSInfinity >> The metric value indicating that the destination described by an >> LSA is unreachable. Used in summary-LSAs and AS-external-LSAs >> as >> an alternative to premature aging (see Section 14.1). It is >> defined to be the 24-bit binary value of all ones: 0xffffff. >> >> RFC5340 inherited it from RFC2328: >> >> Appendix B. Architectural Constants >> >> Architectural constants for the OSPF protocol are defined in >> Appendix >> B of [OSPFV2]. The only difference for OSPF for IPv6 is that >> DefaultDestination is encoded as a prefix with length 0 (see >> Appendix A.4.1). >> >> Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix >> reachability, so the LSInfinity was not applicable for intra-area prefixes. >> >> RFC8362 defines 24-bit metric for all prefix reachability TLVs - >> Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV. >> Al _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
