<?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="std" docName="draft-ietf-lsr-igp-reverse-spf-algo-02" ipr="trust200902">
  <front>
    <title abbrev="IGP Reverse SPF Algorithm">IGP Reverse SPF Algorithm</title>

    
    <author fullname="Peter Psenak" initials="P." surname="Psenak">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>Apollo Business Center</street>
          <street>Mlynske nivy 43</street>

          <city>Bratislava</city>

          <code>82109</code>

          <country>Slovakia</country>
        </postal>

        <email>ppsenak@cisco.com</email>
      </address>
    </author>
    
    <author fullname="Jakub Horn" initials="J." surname="Horn">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street></street>

          <city>Milpitas</city>

          <code>95035</code>

          <region>CA</region>

          <country>USA</country>
        </postal>

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

    <author fullname="Les Ginsberg" initials="L." surname="Ginsberg">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street></street>

          <city>Milpitas</city>

          <code>95035</code>

          <region>CA</region>

          <country>USA</country>
        </postal>

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

    <date/>
    
    
    <area>Routing Area</area>

    <workgroup>LSR Working Group</workgroup>

    <keyword>IGP</keyword>

    <keyword>Draft</keyword>

    <abstract>
    
    <t>IANA has set up a subregistry called "IGP Algorithm Type" under the
     "Interior Gateway Protocol (IGP) Parameters" registry. This draft introduces
     a new algorithm type which utilizes the cost in the reverse direction
     on each link.</t>

     <t>This document also discusses using this new algorithm type in combination
     with IGP Flexible Algorithm to compute constraint-based paths.</t>
      
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
    
      <t>Existing IGP Algorithm types as defined in the IANA IGP Algorithm Types 
      registry created by <xref target="RFC8665"/> utilize metrics in the forward direction 
      on each link. But there are use cases (discussed later in this document) 
      where utilizing the metric in the reverse direction on each link is desirable.</t>

      <t>This document defines a new IGP Algorithm type which uses link metrics in 
      the reverse direction.</t>
      
      <t>An IGP Flexible Algorithm as specified in <xref target="RFC9350"/> 
      computes a constraint-based path. It supports various metric types, 
      including native Interior Gateway Protocol (IGP) metric, Min Unidirectional
      Link Delay, Traffic Engineering Default Metric, all defined in <xref target="RFC9350"/>. 
      In addition, Bandwidth Metric and User defined metrics are defined in 
      <xref target="I-D.ietf-lsr-flex-algo-bw-con"/>.</t>
      
      <t>Existing IGP Flexible Algorithm use cases specify an IGP Algorithm Type where 
      all these link metric types are used by Flexible Algorithm in the forward direction, 
      e.g., the direction in which the link is added to the topology during the 
      computation.</t>
      
      <t>This document extends IGP Flexible Algorithm to be able to use the IGP Algorithm 
      Type which specifies using the link metric in a reverse direction.</t>
      
      <t>Usage of the Reverse Shortest Path First (RSPF) algorithm outside of the IGP
      Flexible Algorithm is outside of the scope of this draft.</t>

    </section>

    <section anchor="ReqLang" title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in <xref
      target="RFC2119">BCP 14</xref> <xref target="RFC8174"/> when, and only
      when, they appear in all capitals, as shown here.</t>
    </section>

    <section title="Use Case Example">
       
      <t>A multicast tree is typically established from the receivers (R) towards 
      the multicast source (S). When determining the path for traffic originating 
      from S towards R, a shortest path from R to S is often used. When the metric on all 
      links is symmetric, e.g. equal in both directions, this provides the correct 
      outcome.</t> 
      
      <t>With the introduction of IGP Flexible Algorithms, additional metrics become 
      available for calculating the shortest path. One commonly employed metric is 
      latency, which often exhibits asymmetry. Multicast traffic is frequently required 
      to take the path  with the minimal latency. In the presence of the asymmetric 
      link latency, the usage of the reverse link latency is required for multicast 
      tree calculation. Failure to use the reverse link latency can result in 
      multicast traffic not taking the least latency path across the network.</t>
                
    </section>

    <section anchor="FA-RSPF"
               title="Flexible Algorithm Usage of Reverse Shortest Path First Algorithm">
        
        <t>Flexible Algorithm Definition Sub-TLV <xref target="RFC9350"/> defines the 
        Calc-Type field, that carries the calculation-type used by the Flexible Algorithm.
        Values are defined in IANA "IGP Algorithm Types" registry defined under the 
        "Interior Gateway Protocol (IGP) Parameters" registry.</t>
        
        <t>We define a new IGP Algorithm Type - Reverse Shortest Path First (SPF) 
        algorithm based on link metric. It is equivalent to the IGP Algorithm Type 0, 
        but the link metric is taken from the reverse direction of the link.</t>
                        
        <t>If the winning Flexible Algorithm Definition signals the Reverse SPF algorithm 
        calculation-type, defines the metric-type other than IGP metric and such metric 
        is not advertised for the link in the reverse direction in a topology for which
        the computation is done, such link MUST be pruned from the computation. A metric 
        of value 0 MUST NOT be assumed in such a case. This is the application of 
        the rule (5), as specified in section 13 of <xref target="RFC9350"/>, 
        in a reverse direction.</t>
    
      </section>
      

    <section anchor="IANA" title="IANA Considerations">
      
      <section anchor="IANAFADFLGAS"
               title="IGP Algorithm Types Registry">

        <t>This document defines a new algorithm type in the IANA "IGP Algorithm Types" 
        registry defined under the "Interior Gateway Protocol (IGP) Parameters" 
        registry. The "value" is suggested - to be assigned by IANA.<figure>
            <artwork><![CDATA[
        Value   Description
        -----   ------------------------------
        2       Shortest Path First (SPF) algorithm based on reverse link metric. It's 
                equivalent to standard (SPF) algorithm (IGP Algorithm Type 0), but uses 
                the metric from the reverse direction of the link. 
        
     ]]></artwork>
          </figure></t>
          
     </section>      
   
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document inherits security considerations from the <xref target="RFC9350"/></t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8174'?>
      
      <?rfc include='reference.RFC.8665'?>

      <?rfc include='reference.RFC.9350'?>
      
      <?rfc include='reference.I-D.ietf-lsr-flex-algo-bw-con'?>
      
    </references>
  </back>
</rfc>
