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]
