Speaking as WG member: Aijun,
> On May 11, 2025, at 9:33 PM, Aijun Wang <[email protected]> wrote: > > Hi, Acee: > > The "area range" is not always be configured at the ABR, or the "area range" > may not cover all of the prefixes within the area. > In such situation, if there is no summary LSA advertised for these prefixes( > with which their total cost exceed LSInifinity), the routers within other > area can't reach these prefixes. > The network traffic will be discarded wrongly. The UPA is specifically targeted toward prefixes that are subsumed by a shorter prefix corresponding to a summary. > > And, we can image even another scenario, even the routers within the same > area can't reach these prefixes, if they treat the prefixes that the 'total > cost' equal LSinifity as unreachable. > > This is one remain bug of RFC 2328. The situation is same for RFC5305/RFC5308 > UPA solution shouldn't depend on such bug base. There is no bug in RFC 2328/RFC 5305/RFC 5308, prefixes with an infinite metric are unreachable by design. I'm not going to debate this. Acee > > > Best Regards > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 > Acee Lindem > 发送时间: 2025年5月9日 22:18 > 收件人: Aijun Wang <[email protected]> > 抄送: Peter Psenak <[email protected]>; lsr <[email protected]> > 主题: [Lsr] Re: [LSInfinity Features within OSPF is FLAWed, it should be > Abandoned, not Enhanced instead] I-D Action: > draft-ietf-lsr-igp-ureach-prefix-announce-05.txt > > > >> 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-p >>>>>>> refix-announce-05 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-urea >>>>>>> ch-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] > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
