> On May 13, 2025, at 3:28 AM, Aijun Wang <[email protected]> wrote: > > Hi, Acee: > > Until now, I haven't found any reasonable explanation that " prefixes with an > infinite metric are unreachable by design " in the existing documents(for > example, > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-ls-link-infinity/ gives > the reason to introduce the value of LSLinkInfinity).
See sections 16.2, 16.3, and 16.4 or RFC 2328. > There are many possible scenarios that the 'total cost' of one prefix reach > the infinite metric. > > Actually, such design can lead the network traffic be broken > unintentionally(I have given you the example, with or without summary LSA). > > The proposal within the current UPA will activate such dormant, should be > abandoned feature, and bring more network outages accidently. > > The WG should seek other solution to achieve the same aim of UPA proposal. > > Best Regards > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: Acee Lindem [mailto:[email protected]] > 发送时间: 2025年5月12日 19:12 > 收件人: Aijun Wang <[email protected]> > 抄送: Peter Psenak <[email protected]>; lsr <[email protected]> > 主题: Re: [Lsr] [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 > > 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-prefi >>>>>>>> x >>>>>>>> -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-ure >>>>>>>> a >>>>>>>> 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]
