> On May 9, 2025, at 10:08 AM, Aijun Wang <[email protected]> wrote: > > 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.
As long as there is at least 1 reachable route subsumed by the area range, there will be a summary-LSA. Acee > > 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]
