Network Working Group A. Wang Internet-Draft China Telecom Intended status: Informational 16 May 2025 Expires: 17 November 2025 The Reason for Abandoning the UPA Draft draft-wang-lsr-reasons-of-abandon-upa-proposal-01 Abstract [I-D.ietf-lsr-igp-ureach-prefix-announce] (UPA draft) proposes the solution to announce the prefix unreachable information within the IGP domain. It utilizes the LSInfinity concept that is introduced in [RFC2328], without analysis the dormant and flawed design. It defines some new flags to convey the maintenance information, which is not the role of IGP protocols and finally, there are several parts that are overlap with another precedent draft that discusses the corresponding contents more throughly. This document analyzes the above issues, suggests the IETF commuity abandon the UPA draft, replace it with other more comprehensive document [I-D.wang-lsr-prefix-unreachable-annoucement](Founder Draft), to provide the IETF community the more optimal solution. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Wang Expires 17 November 2025 [Page 1] Internet-Draft abandon-upa-proposal May 2025 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 November 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. LSInfinity Feature is Flawed . . . . . . . . . . . . . . . . 3 3. U/UP Flag Definitiaon should be Removed . . . . . . . . . . . 4 4. Mimic Parts should be Removed . . . . . . . . . . . . . . . . 5 4.1. Control Knob at the ABR . . . . . . . . . . . . . . . . . 5 4.2. Partitiion Consideration . . . . . . . . . . . . . . . . 5 4.3. Receiver Behavior . . . . . . . . . . . . . . . . . . . . 5 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction [I-D.ietf-lsr-igp-ureach-prefix-announce] (UPA draft) describes one proposal that tries to announce the prefix unreachable information within the IGP domain. It explores one seldom used LSInfinity feature that is defined in [RFC2328] for OSPF(with the value set as the 24-bit binary value of all ones:0xFFFFFF), MAX_PATH_METRIC in "IS-IS Extensions for Traffic Wang Expires 17 November 2025 [Page 2] Internet-Draft abandon-upa-proposal May 2025 Engineering" [RFC5305]and MAX_V6_PATH_METRIC in "Routing IPv6 with IS-IS" [RFC5308], with the value set as 0xFE000000(the 32-bit binary, 2^32 - 2^25) It defines also two new flags U/UP, that are used to transfer the unreachable reason within the IGP domain, which does not fit into the role of IGP protocol. The other parts of the document describe how to control the advertisement of unreachable information on ABR, its consideration with the area partition etc, which are first and throughly described clearly and more throughly in [I-D.wang-lsr-prefix-unreachable-annoucement](Founder Draft). Even including these mimic parts, it still lacks the key consideration of the receiver behavior, which is important for the overall signaling effect. After analyzing these issues, this document recommends the IETF community to abandon the forwarding of UPA draft, replace it with Founder Draft, which is one far earlier and more comprehensive solution. 2. LSInfinity Feature is Flawed [RFC2328] defines the LSInfinity feature, but doesn't give any reasonable explanation. Actually, using the LSInfinity value for one prefix to indicate the prefix is unreachable is problematic in many scenarios in the network, even in the simple topology that illustrated below: +----------------------------+----------------------------------------------------+ | +--+ +--+ +-+-+ ++-+ +--+ | | |R1+--(30)--+R2+---(30)--+ABR+--(20)--|R3+--(10)--+R4+--+-(LSInfinity-10)---P0 | | +--+ +--+ +-+-+ +--+ +--+ +-(LSInfinity)------P1 | | | | | Area 0 | Area 1 | +----------------------------+----------------------------------------------------+ Figure 1: LSInfinity defined in RFC2328 Is Flawed In Figure 1, the value between the router is the cost of the link. Suppose the Router R4 has two prefixes, one is P0, with the metric set to (LSInfinity-10); another is P1, with the metric set to LSInfinity. Wang Expires 17 November 2025 [Page 3] Internet-Draft abandon-upa-proposal May 2025 R4 advertises these two prefixes within the Area1, with two different LSAs. When R3 receives the LSA for prefix P0, according to the description in RFC 2328, it will treat the prefix P0 as reachable, because the cost within the LSA for prefix P0 is lower than LSInfinity. When R3 receives the LSA for prefix P1, according to the description in RFC 2328, it will treat the prefix P1 as unreachable, because the cost within the LSA for prefix P1 is LSInfinity. But on R3, the total cost to P0 and P1 are all LSInfinity, but one is reachable, another is unreachable, results in Fist contradiction conclusion. When the above LSAs reach to ABR, ABR will take the similar treatment, that, it should treat prefix P0 as reachable, and prefix P1 as unreachable. But according to the description in RFC 2328, "if the routing table cost equals or exceeds the value LSInfinity, a summary-LSA cannot be generated for this route", then ABR can't generate the summary LSA, neither for prefix P0(reachable, but total cost exceed LSInfinity), nor for prefix P1(Unreachable). The routers within area0, R1 and R2 can't reach prefix P0 then. This is Second contradiction conclusion. From the above examples, we can know the LSInfinity feature described in [RFC2328] is flawed. Such analysis can also apply to the MAX_PATH_METRIC in [RFC5305] and MAX_V6_PATH_METRIC in [RFC5308] used for the same purpose. The IETF community should erase such flawed features, instead of exploiting it to signal unreachable information. Then section 3 of UPA draft should be removed. 3. U/UP Flag Definitiaon should be Removed Section 5 of UPA draft defines two new flags: U and UP to signal the reason of unreachable information. It says U flag is used to indicate "prefix is unreachable due to the unplanned reason.", the UP flag is used to indicate "the prefix is unreachable due to the planned reason". Wang Expires 17 November 2025 [Page 4] Internet-Draft abandon-upa-proposal May 2025 These flags are not used to influence the SPF calculation of each router, just gives some ambiguous and insufficient reasons(for example, what's the specific unplanned reason?----node failure, link failure, configuration failure? And what's the plan of planned reason") for the unreachable, which is belong to the maintenance information, not required by IGP protocol. Then such information should not be flooded within the IGP protocol. Section 5 of UPA draft should be removed. 4. Mimic Parts should be Removed There are several parts in UPA draft mimic the descriptions in the corresponding parts of Founder Draft which described the related contents throughly about one year earlier. 4.1. Control Knob at the ABR Section 4 of UPA draft describes the generation of the UPA signalling, which mimic directly from Founder Draft. Even so, it lacks still other control knobs at the ABR, for example, how to balance the reachable and unreachable advertisement in some rigid conditions. In order to maintain the code of conduct within IETF community, such mimic parts should be removed. 4.2. Partitiion Consideration Section 6 of UPA draft describes the "deployment consideration for UPA", which is mainly for the duration of UPA signaling and area/ domain partition, all these contents are first described in Founder Draft. For area/domain partition, UPA draft can't give suitable solution, can only describe "UPA is not meant to address an area/domain partition.". If so, section 6 of UPA draft should be removed. 4.3. Receiver Behavior Section 7 of UPA draft describes the process of the UPA should be controlled by the configuration at the receiver. But it lacks one key point, as described in Founder Draft, that the trigger action can only be activated when the receivers receives the UPA signal from all of the ABRs of one area. Or else, there will be misoperation. Wang Expires 17 November 2025 [Page 5] Internet-Draft abandon-upa-proposal May 2025 5. Conclusion The unique parts of UPA draft either should be discouraged(exploiting the flawed LSInfinity feature) or not appropriate(U/UP Flag, which floods maintenance information within IGP protocol). The other parts of UPA mimic the Founder draft Then, the IETF community should abandon the UPA draft, put forward to the Founder Draft instead. 6. Security Considerations The mechanism described in this document does not raise any new security issues for the IGP protocols. 7. Acknowledgement TBD. 8. IANA Considerations None. 9. References 9.1. Normative References [I-D.ietf-lsr-igp-ureach-prefix-announce] Psenak, P., Filsfils, C., Voyer, D., Hegde, S., and G. S. Mishra, "IGP Unreachable Prefix Announcement", Work in Progress, Internet-Draft, draft-ietf-lsr-igp-ureach- prefix-announce-05, 8 May 2025, . [I-D.wang-lsr-prefix-unreachable-annoucement] Wang, A., Hu, Z., Sun, J., and C. Lin, "Prefix Unreachable Announcement", Work in Progress, Internet-Draft, draft- wang-lsr-prefix-unreachable-annoucement-14, 23 April 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Wang Expires 17 November 2025 [Page 6] Internet-Draft abandon-upa-proposal May 2025 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References Author's Address Aijun Wang China Telecom Beiqijia Town, Changping District Beijing 102209 China Email: wangaj3@chinatelecom.cn Wang Expires 17 November 2025 [Page 7]