<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC7684 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7684.xml">
<!ENTITY RFC8570 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8570.xml">
<!ENTITY RFC7471 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7471.xml">
<!ENTITY RFC9479 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9479.xml">
<!ENTITY RFC9492 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9492.xml">
<!ENTITY RFC8362 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8362.xml">
<!ENTITY RFC5305 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC9350 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9350.xml">
<!ENTITY RFC5357 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5357.xml">
<!ENTITY RFC8762 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8762.xml">
<!ENTITY RFC9843 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9843.xml">
]>
<?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="std" docName="draft-wang-lsr-flex-algo-link-loss-05"
     ipr="trust200902">
  <front>
    <title abbrev="IGP Flex-Algorithm with Link Packet Loss">IGP Flexible Algorithm
    with Link Packet Loss</title>

    <author fullname="Yifan Wang" initials="Y." surname="Wang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>Huawei Bld., No. 156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

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

        <email>wangyifan82@huawei.com</email>
      </address>
    </author>
    
    <author fullname="Jie Dong" initials="J." surname="Dong">
      <organization>Huawei</organization>

      <address>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>

    <author fullname="Xuesong Geng" initials="X." surname="Geng">
      <organization>Huawei</organization>

      <address>
        <email>gengxuesong@huawei.com</email>
      </address>
    </author>
	
	<author fullname="Peter Psenak" initials="P." surname="Psenak">
      <organization>Cisco Systems</organization>

      <address>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>

    <date day="2" month="March" year="2026"/>

    <abstract>
      <t>This document proposes extensions to the IGP Flexible Algorithm. It introduces a
   mechanism to exclude links exceeding a specified packet loss rate
   threshold during path computation. The solution leverages existing
   link packet loss advertisement via IS-IS and OSPF, and defines new constraints for Flex-Algorithm path
   calculation.</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 BCP 14 [RFC2119]
      [RFC8174] when, and only when, they appear in all capitals, as shown
      here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Link packet loss rate (hereafter "link loss") refers to the percentage of data
   packets that are lost during transmission over a network link. It is a critical metric
   for network performance evaluation. High packet loss rates directly impact
   service quality, congestion management, and operational efficiency.
   To maintain optimal forwarding paths, it is essential to avoid links
   with excessive packet loss during IGP path computation.</t>

      <t>The IGP Flexible Algorithms enable IGPs to compute constraint-based paths
      <xref target="RFC9350"/>. Current path computation methods focus on determining the minimum cost of the path from the source to the destination. Flex-Algorithm already supports path computation based on IGP cost, minimum link delay, and traffic-engineering metrics. 
      <xref target="RFC9843"/> defines a family of generic metrics (e.g., bandwidth-based metric type) and bandwidth-related constraints to enable path computation based on bandwidth. However, current flexible algorithm definitions lack native support for path computation based on packet loss, as the cost of packet loss is defined as the maximum or minimum packet loss value among all links along the path.</t>

      <t>To address this issue, two solutions are considered. First, a new operator, such as a maximum value operator, can be defined as a step function. Specifically, when the link loss exceeds a threshold, the link cost is set to the maximum value. Second, new Flexible Algorithm Definition (FAD) constraints can be defined to exclude links that do not meet the link loss requirements from path calculation. The second method is specifically demonstrated in this document, and the general ideas are as follows:</t>

      <t><list>
          <t>1. The link loss is used as a link constraint for path
          computation. That is, links with a loss rate exceeding the specified value are excluded.</t>

          <t>2. Metric-type remains unchanged: IGP, te, and delay.</t>
        </list></t>

      <t>This document proposes the method to exclude links exceeding a specified packet loss rate by defining:</t>
      
      <t><list>
          <t>a) A new Flexible Algorithm Definition (FAD) constraint to exclude
      links exceeding a configured maximum loss threshold (Section 2).</t>

          <t>b) Operational procedures for integrating loss constraints into
      Flex-Algorithm path computations (Section 3).</t>
          
          <t>c) Mechanisms to stabilize routing during loss metric fluctuations
      (Section 4).</t>
        </list></t>
    
      <t>The solution reuses existing link loss advertisements defined in <xref target="RFC8570"/> for IS-IS and <xref
      target="RFC7471"/> for OSPF, ensuring backward
   compatibility with deployed networks. The link packet loss rate can be measured using methods
      such as TWAMP <xref target="RFC5357"/> and STAMP <xref
      target="RFC8762"/>. However, these measurement techniques are beyond the scope of this document.
      It is important to ensure that link-loss measurements are consistent throughout the IGP routing domain.</t>
    </section>

    <section title="Exclude Maximum Link Loss Sub-TLV">
      <t>A new sub-TLV, the Exclude Maximum Link Loss Sub-TLV, is defined as part of the FAD TLV. To ensure loop-free forwarding, all routers participating in a Flex-Algorithm MUST agree on the FAD definition. Selected nodes within the IGP domain MUST advertise FADs by including them in their routing updates, as specified in Sections 5, 6, and 7 of <xref target="RFC9350"/>.</t>

      <t>The Exclude Maximum Link Loss Sub-TLV is introduced to define the maximum allowable link loss value. When this Sub-TLV is carried within the FAD TLV, all network links with packet loss rates exceeding the specified maximum value are excluded from the Flex-Algorithm path computation.</t>

      <section title="IS-IS Exclude Maximum Link Loss Sub-TLV">
        <t>The IS-IS Flex-Algorithm Exclude Maximum Link Loss Sub-TLV (FAEML) is defined as a sub-TLV of the IS-IS FAD Sub-TLV. The
   format follows standard TLV structure: <figure
            suppress-title="false" title="IS-IS FAEML Sub-TLV">
            <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type     |    Length     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Maximum Link Loss                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type: 252(TBA by IANA)
	  
      Length: 3 octets

      Max Link Loss:  24-bit unsigned integer representing the maximum
      allowable loss percentage. Encoded with a resolution of 0.000003%
      per unit, providing a maximum expressible value of 50.331642%
      (0xFFFFFF * 0.000003). Values exceeding this cap MUST be advertised
      as 0xFFFFFF.
]]></artwork>
          </figure></t>

        <t>The FAEML sub-TLV MUST appear at most once in the FAD Sub-TLV. If
        it appears more than once, the IS-IS FAD Sub-TLV MUST be ignored by
        the receiving node.</t>

        <t>The maximum link loss advertised in the FAEML Sub-TLV MUST be compared
        with the link loss advertised in Sub-Sub-TLV 36 <xref
        target="RFC8570"/> of ASLA Sub-TLV <xref target="RFC9479"/>. If the
        L-Flag is set in the ASLA sub-TLV, the maximum link loss advertised in the
        FAEML sub-TLV MUST be compared with the link loss advertised by the
        sub-TLV 36 of the TLV 22/222/23/223/141 <xref target="RFC5305"/> as
        defined in <xref target="RFC9479"/> Section 4.2.</t>

        <t>If the link loss exceeds the maximum link loss advertised in the
        FAEML sub-TLV, the link MUST be excluded from the Flex-Algorithm
        topology. However, if a link does not advertise the link loss but the FAD
        contains the FAEML sub-TLV, the link MUST NOT be excluded from the
        Flex-Algorithm topology.</t>
      </section>

      <section title="OSPF Exclude Maximum Link Loss Sub-TLV">
        <t>The OSPF Flex-Algorithm Exclude Maximum Link Loss Sub-TLV (FAEML) is defined as a sub-TLV of the OSPF FAD Sub-TLV. The
   format follows standard TLV structure: <figure
            suppress-title="false" title="OSPF FAEML Sub-TLV">
            <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Type            |            Length           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Maximum Link Loss              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	   
      Type: 252(TBA)
		  
      Length: 3 octets
		  
      Max Link Loss:  24-bit unsigned integer representing the maximum
      allowable loss percentage. Encoded with a resolution of 0.000003%
      per unit, providing a maximum expressible value of 50.331642%
      (0xFFFFFF * 0.000003). Values exceeding this cap MUST be advertised
      as 0xFFFFFF.
		]]></artwork>
          </figure></t>

        <t>The FAEML sub-TLV MUST appear at most once in the FAD Sub-TLV. If
        it appears more than once, the OSPF FAD Sub-TLV MUST be ignored by
        the receiving node.</t>

        <t>The maximum link loss advertised in the FAEML Sub-TLV MUST be compared
        with the link loss advertised in Sub-Sub-TLV 30 <xref
        target="RFC7471"/> of the ASLA Sub-TLV <xref target="RFC9492"/>. The ASLA
        Sub-TLV is advertised in Extended Link Opaque LSAs <xref
        target="RFC7684"/> for OSPFv2 and E-Router-LSAs <xref
        target="RFC8362"/> for OSPFv3.</t>

        <t>If the link loss exceeds the maximum link loss advertised in the
        FAEML sub-TLV, the link MUST be excluded from the Flex-Algorithm
        topology. However, if a link does not advertise the link loss but the FAD
        contains the FAEML sub-TLV, the link MUST NOT be excluded from the
        Flex-Algorithm topology.</t>
      </section>
    </section>

    <section title="Calculation of Flexible Algorithm Paths">
      <t>The following rule is added to the topology pruning rules in
   Section 13 of <xref
      target="RFC9350"/>:</t>

      <t><list>
          <t>1. Check if any exclude FAEML rule is part of the Flex-Algorithm
          definition. If such exclude rule exists and the link has link loss
          advertised, check if the link satisfies the FAEML rule. If not, the
          link MUST be pruned from the computation.</t>
        </list></t>
    </section>

    <section title="Operational Considerations">
      <t>In certain scenarios, the link status may fluctuate between available and unavailable due to the link packet loss rate oscillating around the threshold value. Consequently, Flex-Algorithm computation may be triggered repeatedly. Several mechanisms are considered to address this issue:
	  <t><list>
          <t>1. Delayed collection: The IGP-advertised link packet loss rate can be calculated over a sufficiently long interval, such as 10 minutes, to reduce the frequency of updates.</t>
		  <t>2. Averaging and normalization: The IGP-advertised link packet loss rate should be derived from a form of averaging, such as an exponential weighted average, of the collected loss values. The advertised loss rate can be normalized to prevent the dissemination of non-significant changes in loss metrics.</t>
		  <t>3. Flapping suppression: If frequent changes in the IGP-advertised link packet loss rate are detected, a timer can be implemented to delay the update process, thereby stabilizing the routing computation.</t>
       </list></t>
	    </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <section title="IS-IS Sub-Sub-TLVs in Flexible Algorithm Definition Sub-TLV">
        <t>Type: 252(TBA)</t>

        <t>Description: IS-IS Exclude Maximum Link Loss Sub-TLV</t>

        <t>Reference: This document Section 2.1</t>
      </section>

      <section title="OSPF Sub-Sub-TLVs in Flexible Algorithm Definition Sub-TLV">
        <t>Type: TBA</t>

        <t>Description: OSPF Exclude Maximum Link Loss Sub-TLV</t>

        <t>Reference: This document Section 2.2</t>
      </section>
    </section>
    
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Guoqi Xu for the review and valuable
      discussion of this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
	  &RFC2119;
	  &RFC8174;
      &RFC7684;
      &RFC9479;
      &RFC9492;
      &RFC8362;
	  &RFC5305;
	  &RFC9350;
	</references>
    <references title="Informative References">
	  &RFC8570;
	  &RFC7471;
	  &RFC5357;
	  &RFC8762;
      &RFC9843;
    </references>
  </back>
</rfc>
