<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
     docName="draft-wang-lsr-reasons-of-abandon-upa-proposal-00"
     ipr="trust200902">
  <front>
    <title abbrev="abandon-upa-proposal">Reasons of Abandon UPA
    Proposal</title>

    <author fullname="Aijun Wang" initials="A" surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>

          <city>Beijing</city>

          <region/>

          <code>102209</code>

          <country>China</country>
        </postal>

        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

    <date day="16" month="May" year="2025"/>

    <abstract>
      <t><xref target="I-D.ietf-lsr-igp-ureach-prefix-announce"/> (UPA draft)
      proposes the solution to announce the prefix unreachable information
      within the IGP domain.</t>

      <t>It utilizes the LSInfinity concept that is introduced in <xref
      target="RFC2328"/>, without analysis the dormant and flawed design.</t>

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

      <t>This document analyzes the above issues, suggests the IETF commuity
      abandon the UPA draft, replace it with other more comprehensive document
      <xref target="I-D.wang-lsr-prefix-unreachable-annoucement"/>(Founder
      Draft), to provide the IETF community the more optimal solution.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref target="RFC2119"/>
      <xref target="RFC8174"/> when, and only when, they appear in all
      capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t><xref target="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.</t>

      <t>It explores one seldom used LSInfinity feature that is defined in
      <xref target="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" <xref target="RFC5305"/>and MAX_V6_PATH_METRIC
      in "Routing IPv6 with IS-IS" <xref target="RFC5308"/>, with the value
      set as 0xFE000000(the 32-bit binary, 2^32 - 2^25)</t>

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

      <t>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 <xref
      target="I-D.wang-lsr-prefix-unreachable-annoucement"/>(Founder
      Draft).</t>

      <t>Even including these mimic parts, it still lacks the key
      consideration of the receiver behavior, which is important for the
      overall signaling effect.</t>

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

    <section anchor="LSInifinity" title="LSInfinity Feature is Flawed">
      <t><xref target="RFC2328"/> defines the LSInfinity feature, but doesn't
      give any reasonable explanation.</t>

      <t>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:</t>

      <t><figure>
          <artwork align="center"><![CDATA[                 
 +----------------------------+----------------------------------------------------+
 | +--+        +--+         +-+-+        ++-+        +--+                          |
 | |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
]]></artwork>
        </figure>In Figure 1, the value between the router is the cost of the
      link.</t>

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

      <t>R4 advertises these two prefixes within the Area1, with two different
      LSAs.</t>

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

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

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

      <t/>

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

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

      <t>The routers within area0, R1 and R2 can't reach prefix P0 then. This
      is Second contradiction conclusion.</t>

      <t/>

      <t>From the above examples, we can know the LSInfinity feature described
      in <xref target="RFC2328"/> is flawed. Such analysis can also apply to
      the MAX_PATH_METRIC in <xref target="RFC5305"/> and MAX_V6_PATH_METRIC
      in <xref target="RFC5308"/> used for the same purpose.</t>

      <t>The IETF community should erase such flawed features, instead of
      exploiting it to signal unreachable information.</t>

      <t>Then section 3 of UPA draft should be removed.</t>
    </section>

    <section anchor="U_UP FLAG"
             title="U/UP Flag Definitiaon should be Removed">
      <t>Section 5 of UPA draft defines two new flags: U and UP to signal the
      reason of unreachable information.</t>

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

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

      <t>Then such information should not be flooded within the IGP
      protocol.</t>

      <t>Section 5 of UPA draft should be removed.</t>
    </section>

    <section anchor="mimicparts" title="Mimic Parts should be Removed">
      <t>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.</t>

      <section anchor="ControlKnob" title="Control Knob at the ABR">
        <t>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.</t>

        <t>In order to maintain the code of conduct within IETF community,
        such mimic parts should be removed.</t>
      </section>

      <section anchor="partition" title="Partitiion Consideration">
        <t>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.</t>

        <t>For area/domain partition, UPA draft can't give suitable solution,
        can only describe "UPA is not meant to address an area/domain
        partition.".</t>

        <t>If so, section 6 of UPA draft should be removed.</t>
      </section>

      <section anchor="ReceiverBehavior" title="Receiver Behavior">
        <t>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.</t>
      </section>
    </section>

    <section anchor="Conclusion" title="Conclusion">
      <t>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).</t>

      <t>The other parts of UPA mimic the Founder draft</t>

      <t>Then, the IETF community should abandon the UPA draft, put forward to
      the Founder Draft instead.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The mechanism described in this document does not raise any new
      security issues for the IGP protocols.</t>
    </section>

    <section anchor="ack" title="Acknowledgement">
      <t>TBD.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>None.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.2328"?>

      <?rfc include="reference.RFC.5305"?>

      <?rfc include="reference.RFC.5308"?>

      <?rfc include="reference.RFC.8174"?>

      <?rfc include="reference.I-D.wang-lsr-prefix-unreachable-annoucement"?>

      <?rfc include="reference.I-D.ietf-lsr-igp-ureach-prefix-announce"?>
    </references>

    <references title="Informative References"/>

    <!---->
  </back>
</rfc>
