Hi Aijun, This is exactly how things are designed to work. The explanation has been attempted multiple times now, please stop sending email on this.
Acee, Chris and YIngzhen (LSR Chairs) On Wed, May 14, 2025 at 6:13 PM Aijun Wang <[email protected]> wrote: > Hi, Peter: > > Among the discussions, we should keep the argument logic consistence. > Let's pin the example here to illustrate your contradictory reasoning: > > Assume the following simple topology: > R1-(10)---R2---(20)--ABR--(30)--R3--(40)--R4--(LSInifinity-20)---P0 > With the value in parenthesis indicates the cost the link between the > routers > > In your argument: > R3 will treat the prefix P0 as reachable, because the cost within the > LSA is (LSInifinity-20), lower than LSInifinity, although the cost to the > prefix P0 reaches the limit of LSInifinity. > ABR will treat the prefix P0 as unreachable and doesn't advertise > summary LSA, because it " reached the limit of what protocol defines as > reachable metric for the prefix." > > Both reaches the "limit of what protocol defines as reachable metric for > the prefix", why the final treatments are different and contradictory? > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] > 代表 Peter Psenak > 发送时间: 2025年5月14日 20:54 > 收件人: Aijun Wang <[email protected]> > 抄送: Acee Lindem <[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 14/05/2025 13:28, Aijun Wang wrote: > > Please overrides the previous unfinished mail. > > > >>>> On 14/05/2025 03:08, Aijun Wang wrote: > >>>> I have pointed out these guidelines within 16.2, 16.3 and 16.4 are > problematic. > >>>> They don't give the reasonable explanations to define LSInfinity. > >>>> If you think there is any content within RFC 2328 gives the reason, > please quote them directly. > >>>> > >>>> Let me describe again the scenario that demonstrate these issues that > current RFC 2328 has: > >>>> 1) Assume the following simple topology: > >>>> > R1-(10)---R2---(20)--ABR--(30)--R3--(40)--R4--(LSInifinity-20)---P0 > >>>> With the value in parenthesis indicates the cost the link > >>>> between the routers > >>>> 2) when one set the cost of prefix P0 that attached R4 as > "LSInifinity-20", it is reachable on R4. > >>>> > >>>> 3) When the LSA that includes prefix P0, reaches R3, R3 will > calculate the total cost to this prefix exceeds LSInfinity. > >>>> Should R3 treat this prefix as reachable or unreachable? > >> yes, there's nothing wrong with the path cost to be higher than > LSInfinity. It's the cost of LSInfinity advertised inside the LSA which > makes the prefix unreachable. > >> > >> RFC2328 clearly states it - "If the cost specified by the LSA is > LSInfinity". > > [WAJ] OK. Then R3 and ABR should treat prefixes P0 as reachable. > > > > Then emerge the contradiction results: in these routers, although the > cost of the prefixes P0 reach to LSInfinity, they are still reachable. > > > > But at the original router, if we set the cost of the prefixes as > LSInfinity, they indicate unreachable. > > > > Don’t you think these contradicting design puzzled? > > no, it looks perfectly valid to me. > > > > > > >>>> 4) When such LSA reaches ABR, according to current description of > section 12.4.3 of OSPF 2328, there will be no summary LSA generated for > prefix P0("Else, if the routing table cost equals or exceeds the > >>>> value LSInfinity, a summary-LSA cannot be generated > for this route."). > >>>> Routers R1 and R2, which are in another area, will not have the > information about prefix of P0, the traffic from R1/R0 to prefix P0 will be > broken. > >> Nothing is broken, you reached the limit of what protocol defines as > reachable metric for the prefix. > > [WAJ] it is one obvious broken design. > > If the ABR treat the prefix P0 as reachable, why don’t advertise them in > summary LSA? > > > > If the ABR doesn’t advertise the prefixes P0, R1 and R2 in other area > can’t reach prefix P0, which is undesirable. > > I don't see any problem. > > > > > >> All of the above is completely orthogonal to UPA. > > [WAJ] UPA actives the above contradictory design. > > no, it does not. UPA originates the prefix with LSInfinity, so it is > unreachable from the very beginning and keeps that property as it is > flooded or propagated. > > I'm done with this discussion now. > > Peter > > > > >> regards, > >> Peter > >> > >> > >>>> How can you solve the above dilemma, under the current description of > RFC 2328? > >>>> Please gives the coherent quotation. > >>>> > >>>> > >>>> Best Regards > >>>> > >>>> Aijun Wang > >>>> China Telecom > >>>> > >>>> -----邮件原件----- > >>>> 发件人: Acee Lindem [mailto:[email protected]] > >>>> 发送时间: 2025年5月14日 3:07 > >>>> 收件人: 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 > >>>> > >>>> > >>>> > >>>>> 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 <ppsenak= > [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 > >>>>>>>>>>>> -pa > >>>>>>>>>>>> t > >>>>>>>>>>>> h > >>>>>>>>>>>> - > >>>>>>>>>>>> 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- > >>>>>>>>>>>> pre > >>>>>>>>>>>> f > >>>>>>>>>>>> i > >>>>>>>>>>>> x > >>>>>>>>>>>> -announce/ > >>>>>>>>>>>> > >>>>>>>>>>>> There is also an HTMLized version available at: > >>>>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ur > >>>>>>>>>>>> eac > >>>>>>>>>>>> h > >>>>>>>>>>>> - > >>>>>>>>>>>> p > >>>>>>>>>>>> refix-announce-05 > >>>>>>>>>>>> > >>>>>>>>>>>> A diff from the previous version is available at: > >>>>>>>>>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-ig > >>>>>>>>>>>> p-u > >>>>>>>>>>>> r > >>>>>>>>>>>> e > >>>>>>>>>>>> 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] > > > > _______________________________________________ > 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]
