Hi, Acee: If no summary LSA for these prefixes, then, there will be no LSA for these prefixes, it leads the same WRONG results—-such prefixes are unreachable in another area.
Aijun Wang China Telecom > On May 9, 2025, at 21:58, Acee Lindem <[email protected]> wrote: > > Speaking as WG member, > > >> On May 9, 2025, at 9:28 AM, Peter Psenak >> <[email protected]> wrote: >> >> Aijun, >> >>> On 09/05/2025 15:22, Aijun Wang wrote: >>> Hi, Peter: >>> >>> UPA doesn’t influence the results of the prefixes that are set to be the >>> LSInfinity at its originator, but it influences the results of the prefixes >>> whose metrics are lower than LSInfinity. >> no UPA does not affect prefixes that are advertised with valid metric. >>> >>> I have show you the example in the previous mail—-For example, in >>> https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/47864-ospfdb5.html >>> , when prefix 4.0.0.0/8 reaches to the ABR, it is reachable(prefix cost is >>> 0xffffff-0x40, lower than LSInfinity). >>> >>> But after the ABR advertise the prefix in area 1 with the Summary LSA, its >>> metric will be LSInfinity. >>> >>> According to the UPA rule, or RFC 2328, every router(includes the final >>> receiver) within the area 1 will treat this prefix as unreachable, which is >>> NOT right. >> If the prefix metric is LSInfinity, the prefix is unreachable. UPA does not >> change any of that. >>> >>> It’s time to fix RFC2328/RFC5305/RFC5308. >> I don't think so. > > I agree. There is nothing in the UPA draft, that says the unreachable prefix > will be included in the summary cost calculation. I don't know how one would > come to that conclusion. > > Also, for OSFP, in section 12.4.3 of RFC 2328, routes with a metric of > LSInfinity or higher are explicitly disqualified from the summary computation. > > o Else, if the routing table cost equals or exceeds the > value LSInfinity, a summary-LSA cannot be generated for > this route. > > > Thanks, > Acee > > > > > >>> >>> Let’s do this together before forwarding the UPA draft? >> no, we are not going to modify the LSInfinity in any way inside or outside >> of the UPA. >> I'm done with this discussion now. >> Regards, >> Peter >>> >>> Aijun Wang >>> China Telecom >>> >>>> On May 9, 2025, at 18:04, Peter Psenak <[email protected]> wrote: >>>> >>>> Aijun, >>>> the problem you have described below has no relevance to the UPA. In the >>>> UPA case we are deliberately originating the prefix with the unreachable >>>> metric, so adding anything to it at ABR is not going to make any >>>> difference, it will stay as unreachable. >>>> As I have replied to you many times the meaning of the LSInfinity was >>>> defined in the base protocol specification and we are not altering it in >>>> any way. We are using it the way it was defined. >>>> Regards, Peter >>>> >>>> On 09/05/2025 10:55, Aijun Wang wrote: >>>>> Hi, Peter: >>>>> >>>>> I noticed the updated draft includes the new contributors to respect >>>>> their previous efforts, this should be encouraged within IETF. >>>>> >>>>> But, I must point out that, the direction that Reusing the LSInfinity to >>>>> advertise the unreachable information should be discarded. >>>>> >>>>> The LSInfinity feature that is defined in RFC 2328 is FLAWED, we should >>>>> try to fix it, not exploit it again. >>>>> >>>>> Let's give you the simple example, that described in "OSPF Inter-Area >>>>> Routing" [1] >>>>> This is one 20 years ago article, it states clearly that when ABR do the >>>>> summary action, it will add the cost of the prefix itself and the cost of >>>>> the path between the prefix originator and the ABR together, as the newly >>>>> cost of the summary LSA for the prefix: >>>>> In the example, the original cost of 4.0.0.0/8 is 10, the link cost >>>>> between Router 1.1.1.1 and Router 2.2.2.2 is 64, the ABR(router 2.2.2.2) >>>>> will advertise the summary LSA for 4.0.0.0/8 to Area 1, with the cost set >>>>> to 10+64=74 (please see the output of "r2.2.2.2#show ip ospf database >>>>> summary 4.0.0.0") >>>>> >>>>> Then coming the question(let's take the same example): >>>>> If the cost of prefix 4.0.0.0/8 is set to 0xffffff-0x40(64), on >>>>> ABR(router 2.2.2.2), the cost of summary LSA for prefix 4.0.0.0/8 will >>>>> reach 0xfffff. >>>>> If the ABR(router 2.2.2.2) follow the guideline of RFC 2328, the prefix >>>>> 4.0.0.0/8 will be unreachable, and will be not advertised to area 1, >>>>> router in area 1 can't reach the 4.0.0.0/8. >>>>> But actually, 4.0.0.0/8 is reachable via the ABR(router 2.2.2.2). >>>>> >>>>> If we consider there may be several hops between the prefix originator >>>>> and the ABR, then the cost of the prefix can't exceed 【0xffffff-(several >>>>> hops)*(possible link metric)】, which will be varied with different >>>>> network topology, and can't be considered as one universal value, even a >>>>> definite range. >>>>> >>>>> Then, such flaw in OSPF 2328, and also the similar mechanism in RFC >>>>> 5305/RFC5308 for IS-IS should be fixed. >>>>> >>>>> The reason that there is no emerged network outrage in these years is >>>>> that the operator configure seldom the cost of the prefix directly. >>>>> But if we expand the LSInfinity feature as described in this WG document, >>>>> more chaos, and network outrages will be emerged. >>>>> >>>>> Let's stop forwarding to this direction. >>>>> >>>>> [1]: >>>>> https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/47864-ospfdb5.html >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> Aijun Wang >>>>> China Telecom >>>>> >>>>> >>>>> -----邮件原件----- >>>>> 发件人: [email protected] [mailto:[email protected]] >>>>> 代表 [email protected] >>>>> 发送时间: 2025年5月9日 2:21 >>>>> 收件人: [email protected] >>>>> 抄送: [email protected] >>>>> 主题: [Lsr] I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-05.txt >>>>> >>>>> Internet-Draft draft-ietf-lsr-igp-ureach-prefix-announce-05.txt is now >>>>> available. It is a work item of the Link State Routing (LSR) WG of the >>>>> IETF. >>>>> >>>>> Title: IGP Unreachable Prefix Announcement >>>>> Authors: Peter Psenak >>>>> Clarence Filsfils >>>>> Daniel Voyer >>>>> Shraddha Hegde >>>>> Gyan Mishra >>>>> Name: draft-ietf-lsr-igp-ureach-prefix-announce-05.txt >>>>> Pages: 15 >>>>> Dates: 2025-05-08 >>>>> >>>>> Abstract: >>>>> >>>>> In the presence of summarization, there is a need to signal loss of >>>>> reachability to an individual prefix covered by the summary. This >>>>> enables fast convergence by steering traffic away from the node which >>>>> owns the prefix and is no longer reachable. >>>>> >>>>> This document describes how to use the existing protocol mechanisms >>>>> in IS-IS and OSPF, together with the two new flags, to advertise such >>>>> prefix reachability loss. >>>>> >>>>> The IETF datatracker status page for this Internet-Draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/ >>>>> >>>>> There is also an HTMLized version available at: >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-05 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-ureach-prefix-announce-05 >>>>> >>>>> Internet-Drafts are also available by rsync at: >>>>> rsync.ietf.org::internet-drafts >>>>> >>>>> >>>>> _______________________________________________ >>>>> Lsr mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>>> _______________________________________________ >>>>> Lsr mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> Lsr mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
