Hi, Acee: Let me give you one more concrete example:
The metric of one prefix P is set to 0xFFFFFE(not LSInfinity, it can also be other large value), and this prefix is attached at one router that has the link cost 1 to ABR, what the value for the ABR to advertise for this Prefixes P into other attached area as one summary prefix? Aijun Wang China Telecom > On Oct 12, 2022, at 18:22, Acee Lindem (acee) > <[email protected]> wrote: > > > > On 10/12/22, 2:31 AM, "Lsr on behalf of Aijun Wang" <[email protected] on > behalf of [email protected]> wrote: > > Hi, Acee: > > Let me state some points more clearly: > 1) The LSInfinity is defined almost 30 years, but it is not > applied/deployed within the network about 30 years, why to deprecate it? > 2) RFC8362 say nothing about LSInifinity, only RFC5340 says it inherits > the definition from RFC2328. > 3) It is problematic to define again the LSInifinity within RFC8362, as > the value of 0xffffff, because the metric of the normal summary prefixes > advertised by ABR may reach this predefined value. > > This is not problematic. Only unreachable prefixes for an algorithm will have > a metric of LSInfinity and will, hence, be unreachable and will not > contribute to the cost of any summary prefixes. > > Thanks, > Acee > > The most important point is that there is reasonable/sound reason to > define such value for its special handling. > > Best Regards > > Aijun Wang > China Telecom > > > -----Original Message----- > From: [email protected] <[email protected]> On Behalf Of Acee Lindem > (acee) > Sent: Tuesday, October 11, 2022 11:20 PM > To: Peter Psenak (ppsenak) <[email protected]>; Aijun Wang > <[email protected]>; 'Ketan Talaulikar' <[email protected]> > Cc: [email protected] > Subject: Re: [Lsr] RFC 8362 and LSInfinity > > Hi Aijun, > > After almost 30 years, we're not going to deprecate OSPF LSInfinity based > on your opinion. > > Please be specific as to what you feel is problematic with usage in the > 24-bit metric in the E-Intra-Area-Prefix LSA. > > Thanks, > Acee > > On 10/11/22, 12:09 AM, "Peter Psenak" <[email protected]> wrote: > > Aijun, > >> On 11/10/2022 05:44, Aijun Wang wrote: >> Hi, Peter: >> >> Let's focus on OSPF itself then. >> >> In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the link or >> intra-area prefix is 16 bit; but the metric length for the summary >> LSA/inter-area is 24bit. >> There will be no problem to define the LSInfinity for the summary LSA as >> 0xFFFFFF( although the usages of such definition is doubtful and should be >> revaluated----for example, is there any real deployment for the mentioned >> possible usages?) >> >> But for OSPFv3(RFC8362), if you still define the LSInifiity as 0xFFFFFF, >> there is possible the cost to some prefixes advertised by the ABR reach this >> value, it is unreasonable to consider such prefixes are unreachable. Then, >> rely on such value of the metric to determine the reachability is >> problematic. > > again, there is no problem. For RFC8362 0xFFFFFF already means > LSInfinity for inter/external prefixes. All we propose is to define > the > same meaning for that metric for intra-area prefixes as it is 24 bits > as > well. > > Peter > >> >> We should decrease or abandon such unsound reliance. >> >> It is easy for the device to implement such special treatment, it is >> difficult and complex for the operator to run the network based on such >> special treatment. >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> -----Original Message----- >> From: [email protected] <[email protected]> On Behalf Of Peter Psenak >> Sent: Monday, October 10, 2022 3:56 PM >> To: Aijun Wang <[email protected]>; 'Acee Lindem (acee)' >> <[email protected]>; 'Ketan Talaulikar' >> <[email protected]>; 'Peter Psenak' <[email protected]> >> Cc: [email protected] >> Subject: Re: [Lsr] RFC 8362 and LSInfinity >> >> Aijun, >> >>> On 09/10/2022 07:44, Aijun Wang wrote: >>> Hi, Acee, Peter and Ketan: >>> >>> I propose we limit the usage of LSInfinity within the network. That is >>> to say, we should depreciate its usages, not enhance it. >>> >>> As defined in RFC2328, the sole purpose of LSInfinity is to let the >>> receiver bypass the SPF calculation for the associated LSA: >>> >>> a)In case the advertisement of LSA for some special aim. >>> >>> b)Another is for the premature aging the LSA (which is not encouraged). >>> >>> There is few application for the a) usage until now, same situation >>> for >>> b) usage. >> >> definition of LSInfinity is very exact - it means unreachability. >> >>> >>> The reason for the above situations may be the definition within the >>> RFC2328 is counterintuitive----the maximum value of the metric should >>> be used for the last resort of the reachability, no other more >>> meanings. Or else, it will complex the implementation and deployment, for >>> example: >>> >>> a)For OSPFv2, the LSInfinity is defined as 0xffffff >>> >>> b)For IS-IS, the equivalent variable is MAX_PATH_METRIC, which is >>> defined as 0xFE000000 >> >> you are comparing apples to oranges. These are two different protocols. >> >>> >>> c)For OSPFv3, which value will you be defined, especially for the >>> Intra-Area-Prefix? Considering the metric for the intra-area and >>> inter-area are all 24-bit long? >> >> OSPFv3 inherits all the constants defined for OSPFv2, it's explicitly >> mentioned in the OSPFv3 RFC. And LSInfinity is 24 bits long. >> >>> >>> d)And, for the metric in ”IP Algorithm Prefix Reachability” , >>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.3 >>> >>> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.3>, >>> its length is again 32-bit, will you define another LSInfinity value later? >> >> 0xFFFFFFFF seems like a good candidate for the unreachable metric for the IP >> flex-algo. >> >>> >>> Won’t you think the above special rule complex the whole situation? >> >> not at all. >> >>> >>> I think we should seek other methods to achieve the necessary goals. >> >> I do not see a problem >> >> thanks, >> Peter >>> >>> Best Regards >>> >>> Aijun Wang >>> >>> China Telecom >>> >>> *From:* [email protected] <[email protected]> *On Behalf Of >>> *Acee Lindem (acee) >>> *Sent:* Saturday, October 8, 2022 4:03 AM >>> *To:* Ketan Talaulikar <[email protected]>; Peter Psenak >>> <[email protected]> >>> *Cc:* [email protected] >>> *Subject:* Re: [Lsr] RFC 8362 and LSInfinity >>> >>> Hi Peter, Ketan, >>> >>> We’ll do another WG last call on the updated IP Flex Algo document and >>> it will update RFC 8362. As you probably surmised, this is useful for >>> OSPFv3 IP Flex Algorithm when you want don’t want to use the prefix >>> with the base algorithm. >>> >>> *From: *Lsr <[email protected] <mailto:[email protected]>> on >>> behalf of Ketan Talaulikar <[email protected] >>> <mailto:[email protected]>> >>> *Date: *Thursday, October 6, 2022 at 3:35 AM >>> *To: *Peter Psenak <[email protected] >>> <mailto:[email protected]>> >>> *Cc: *"[email protected] <mailto:[email protected]>" <[email protected] >>> <mailto:[email protected]>> >>> *Subject: *Re: [Lsr] RFC 8362 and LSInfinity >>> >>> Hi Peter, >>> >>> I support this "update" - not sure if it qualifies as a "clarification". >>> Also, this obviously is doable only when the network has migrated to >>> use only Extended LSAs (i.e., legacy LSAs are removed) as indicated in >>> https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1 >>> <https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1> >>> >>> In sparse-mode, the legacy LSAs are used. So if you want a prefix to >>> be unreachable with the base algorithm, simply omit it from the legacy >>> Intra-Area-Prefix LSA. >>> >>> Thanks, >>> Acee >>> >>> Thanks, >>> >>> Ketan >>> >>> On Wed, Oct 5, 2022 at 3:01 PM Peter Psenak >>> <[email protected] >>> <mailto:[email protected]>> >>> wrote: >>> >>> 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. >>> Although it is silent about the LSInfinity as such, it is assumed that >>> such metric means unreachability for Inter-Area-Prefix TLV and >>> External-Prefix TLV. Given that Intra-Area-Prefix TLV now has 24 bits >>> metric as well, it would make sense to define the LSInfinity as >>> unreachable for Intra-Area-Prefix TLV as well. >>> >>> Would anyone object such a clarification in RFC8362? >>> >>> thanks, >>> Peter >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/lsr >>> <https://www.ietf.org/mailman/listinfo/lsr> >>> >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> >> > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
