



Network Working Group                                            A. Wang
Internet-Draft                                             China Telecom
Intended status: Informational                              17 June 2025
Expires: 19 December 2025


                The Reason for Abandoning the UPA Draft
           draft-wang-lsr-reasons-of-abandon-upa-proposal-04

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 analyzing the dormant and flawed design.

   The proposal doesn't work even in simple scenario, is based on one
   flawed feature, lacks the explicit withdrawn procedures.

   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/.

   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."




Wang                    Expires 19 December 2025                [Page 1]

Internet-Draft            abandon-upa-proposal                 June 2025


   This Internet-Draft will expire on 19 December 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.  UPA Proposal Doesn't Work in Simple Scenario  . . . . . . . .   3
   3.  LSInfinity Feature is Flawed  . . . . . . . . . . . . . . . .   4
   4.  No Explicit UPA Withdrawn Method  . . . . . . . . . . . . . .   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
   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)

   The proposal doesn't work even in very simple scenario and lacks the
   key consideration of the the explicit withdraw method.





Wang                    Expires 19 December 2025                [Page 2]

Internet-Draft            abandon-upa-proposal                 June 2025


   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).

   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.  UPA Proposal Doesn't Work in Simple Scenario

   UPA proposal doesn't work even in simple scenario.  Such issues can
   be illustrated in the following example:

   In Figure 1, PE1 and PE2 locate in different areas, which are
   connected via the backbone area 0, via ABR1 and ABR2 respectively.

   When one prefix P0 on PE2 become unreachable, according to the UPA
   proposal, ABR2 will signal the UPA, flood it within area 0, with the
   metric of the summary LSA set to LSInfinity.

   When such UPA signal reaches ABR1, according to the description in
   section 12.4.3( "Summary-LSAs") of [RFC2328]:

   "......, if the routing table cost equals or exceeds the value
   LSInfinity, a summary-LSA cannot be generated for this route."

   There will be no summary LSA generated for the received UPA signal.
   It is to say, UPA signal can't cross area border.

   PE1 which locates in area 1 can't know the P0 on PE2 is unreachable
   as expected.  Any application switchover on PE1 will never happen.


              +------------+----------------+----------------+
              |            |                |                |
              | +---+    +-+--+    +--+   +-+--+    +---+    |
              | |PE1+----+ABR1+----|P +---|ABR2+----|PE2+--P0|
              | +---+    +-+--+    +--+   +-+--+    +---+    |
              |            |                |                |
              |   Area 1   |     Area 0     |     Area 1     |
              +-----------------------------+----------------+

             Figure 1: UPA Signal Can't Cross Area Border

   The UPA procedure is broken in such scenario.



Wang                    Expires 19 December 2025                [Page 3]

Internet-Draft            abandon-upa-proposal                 June 2025


3.  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 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 2: LSInfinity defined in RFC2328 Is Flawed

   In Figure 2, 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.

   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.






Wang                    Expires 19 December 2025                [Page 4]

Internet-Draft            abandon-upa-proposal                 June 2025


   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 and section 4 of UPA draft should be removed.

4.  No Explicit UPA Withdrawn Method

   The UPA document specifies that the UPA must be withdrawn when the
   prefix is reachable again, but gives no explicit UPA withdrawn
   method.

   The author declares that stopping advertising UPA is equal to UPA
   withdrawn, actually it doesn't.  The following are the detail
   analysis:

   There are at least two reasons to stop advertising UPA:

   1) Case A is that the UPA has been advertised for enough time to let
   the receiver accomplish the related application switchover

   2) Case B is the specific prefix is reachable again.

   For Case A, when the receiver stop receiving UPA signal, it doesn't
   represent the prefix is reachable again.

   If there is no explicit UPA withdrawn method, the network can't
   recover to the normal state before the UPA triggered switchover.

   Explicit UPA Withdrawn Method is necessary.







Wang                    Expires 19 December 2025                [Page 5]

Internet-Draft            abandon-upa-proposal                 June 2025


5.  Conclusion

   The UPA proposal doesn't work even in simple scenario, is based on
   the flawed feature, lacks explicit withdraw signal.

   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-08, 5 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-
              ureach-prefix-announce-08>.

   [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-15, 26 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-wang-lsr-
              prefix-unreachable-annoucement-15>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://www.rfc-editor.org/info/rfc2328>.



Wang                    Expires 19 December 2025                [Page 6]

Internet-Draft            abandon-upa-proposal                 June 2025


   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
              DOI 10.17487/RFC5308, October 2008,
              <https://www.rfc-editor.org/info/rfc5308>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

Author's Address

   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China
   Email: wangaj3@chinatelecom.cn




























Wang                    Expires 19 December 2025                [Page 7]
