Aijun Wang
>>
>>> 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, in R3, although the total cost exceeds the LSInfinity, it is
reachable.
Then, the results are contradictory: some routers treat the prefix with
LSInfinity as reachable, some routers treat the prefix
>
>>>
>>> 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]
>
> All of the above is completely orthogonal to UPA.
>
> 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
>>>>>>>> <[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-ureac
>>>>>>>>>>> h
>>>>>>>>>>> -
>>>>>>>>>>> p
>>>>>>>>>>> refix-announce-05
>>>>>>>>>>>
>>>>>>>>>>> A diff from the previous version is available at:
>>>>>>>>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-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]
