<?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-chen-rtgwg-srv6-midpoint-protection-14"
     ipr="trust200902">
  <front>
    <title abbrev="SRv6 Midpoint Protection">SRv6 Midpoint Protection</title>

    <author fullname="Huanan Chen" initials="H." surname="Chen">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>109, West Zhongshan Road, Tianhe District</street>

          <city>Guangzhou</city>

          <code>510000</code>

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

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

    <author fullname="Zhibo Hu" initials="Z." surname="Hu">
      <organization>Huawei Technologies</organization>

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

          <city>Beijing</city>

          <code>100095</code>

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

        <email>huzhibo@huawei.com</email>
      </address>
    </author>

    <author fullname="Huaimo Chen" initials="H." surname="Chen">
      <organization>Futurewei</organization>

      <address>
        <postal>
          <street/>

          <city>Boston, MA</city>

          <region/>

          <code/>

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

        <email>hchen.ietf@gmail.com</email>
      </address>
    </author>

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

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>gengxuesong@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Yisong Liu" initials="Y." surname="Liu">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>liuyisong@chinamobile.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Gyan S. Mishra" initials="G" surname="Mishra">
      <organization>Verizon Inc.</organization>

      <address>
        <postal>
          <street>13101 Columbia Pike</street>

          <city>Silver Spring</city>

          <code>MD 20904</code>

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

        <phone>301 502-1347</phone>

        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

    <date year="2024"/>

    <abstract>
      <t>The current local repair mechanism, e.g., TI-LFA, allows 
      the upstream neighbor of the failed node or link to
      fast re-route traffic around the failure. 
      This mechanism does not
      work properly for SRv6 TE path
      after the failure happens in an endpoint node and
      IGP converges on the failure. 

      This document defines midpoint protection for SRv6 TE path, 
      which enables the upstream endpoint node of the failed node
      to perform the endpoint behavior for the faulty node and 
      fast re-route traffic around the failure 
      after IGP converges on the failure.
      </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>The current local repair mechanism, e.g., 
      Topology-Independent Loop-Free Alternate (TI-LFA) (<xref
      target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/>), allows 
      the upstream neighbor of the failed node or link to
      fast re-route traffic around the failure. This mechanism does not
      work properly after the failure happens in an endpoint node and 
      IGP converges on the failure. 
      </t>

      <t>In SRv6, 
<!--
       a node N is an endpoint node of an SRv6 TE path
         if the IPv6 destination address (DA) of the packet
             received by N from the path is a N's local END SID.
-->
      the IPv6 destination address (DA) in the outer IPv6 header 
      could be a segment
      endpoint node (or endpoint for short) of an SRv6 TE path 
      (or SRv6 path for short) 
      rather than the destination of the SRv6
      path (<xref target="RFC8986"/>).
 
      After the endpoint fails and IGP converges on the failure, 
      the packet with the failed endpoint as DA will be dropped since
      there is no FIB entry for DA (i.e., no route to this endpoint). 
      The upstream non-endpoint neighbor of the failed endpoint 
      will not receive the packet for the SRv6 path.   

     <xref target="I-D.ietf-spring-segment-protection-sr-te-paths"/> and
     <xref target="I-D.hu-spring-segment-routing-proxy-forwarding"/> 
     propose midpoint protection for SR-MPLS TE path 
     after IGP converges on the failure of a node along the path.</t>

      <t>This
      document defines midpoint protection for SRv6 path
      after IGP converges on the failure of an endpoint on the path, 
      which enables the upstream endpoint of the failed endpoint to
      perform the endpoint behavior for the failed endpoint and fast re-route
      traffic around the failure after IGP converges on the failure.
      </t>
    </section>

    <section anchor="srv6-midpoint-mech"  
             title="SRv6 Midpoint Protection Mechanism">

      <t>When an endpoint node fails, the packet needs to bypass the failed
      endpoint node and be forwarded to the next endpoint node of the failed
      endpoint. Only endpoint node can process SRH, so, only endpoint
      nodes can perform midpoint protection. There are two stages or time
      periods after an endpoint node fails. The first is the time period from
      the failure until the IGP converges on the failure. The second is the
      time period after the IGP converges on the failure.</t>

      <t>During the first time period, the packet will be sent to the upstream
      neighbor of the failed endpoint node. After detecting the failure of its
      interface to the failed endpoint node, the neighbor forwards the packet
      around the failed endpoint node using TI-LFA.</t>

      <t>During the second time period, there is no FIB entry for 
      the failed endpoint. 
      When a upstream/previous endpoint of the
      failed endpoint has no FIB entry for 
      the failed endpoint, it changes the DA of the packet to
      the IPv6 address of the next endpoint (of the failed endpoint)
      and forwards the packet using the FIB entry for the next endpoint.
      Note that the upstream/previous endpoint node may not be the 
      upstream neighbor of the failed endpoint.</t>

      <!--
On the Repair Node (i.e., the previous hop of the failed
      endpoint node), it performs the proxy forwarding as follows after
      detecting the failure of its interface to the endpoint node.</t>

      <t>Case 1: Route to the failed endpoint could be found in its FIB:
        <list style="symbols">
          <t>If the Repair Node is not directly connected to the failed
          endpoint, the normal Ti-LFA is executed;</t>

          <t>If the Repair Node is directly connected to the failed endpoint,
          the Repair Node forwards the packets through a bypass to avoid 
          the failed
          endpoint. It replaces the IPv6 destination address with the IPv6
          address of the next, the last or other reasonable endpoint nodes,
          which could avoid going through the failed endpoint.</t>
        </list>
      </t>

     <t>Case 2: Route to the failed endpoint could not be found in its FIB:
       <list style="symbols">
          <t>Repair Node forwards the packets through a bypass of the failed
          endpoint to the next, the last or other reasonable endpoint node
          directly. There is no need to check whether the failed endpoint
          node is directly connected to the Repair Node or not.</t>
       </list>
     </t>
-->
    </section>

    <section title="SRv6 Midpoint Protection Example">
      <t><xref target="ex-net"/> illustrates an example of
      network topology with SRv6 enabled on each node.
      The cost of each link is 1 by default, except for the costs of 
      the links indicated by numbers on the links.</t>

      <t>In this document, an end SID at node Ni with locator block B is
      represented as B:i. 
<!--
An end.x SID at node n towards node k with locator
      block B is represented as B:n:k. 
-->
      A SID list is represented as &lt;S1,
      S2, S3&gt; where S1 is the first SID to visit, S2 is the second SID to
      visit and S3 is the last SID to visit along the SRv6 TE path.</t>

      <t><figure anchor="ex-net"
          title="An example of network for midpoint protection">
          <artwork align="center"><![CDATA[
                               +-----+        +-----+
                   +-----------|  N6 |--------|  N7 |-----------+
                   |           +-----+        +-----+           |
                   |              |              |              |  
                   |2             |2             |              |
                   |              |              |              |
 +-----+        +-----+        +-----+        +-----+        +-----+
 |  N1 |--------|  N2 |--------|  N3 |--------|  N4 |--------|  N5 |
 +-----+        +-----+        +-----+        +-----+        +-----+
]]></artwork>
        </figure></t>

      <t>In the reference topology, suppose that there are two SRv6 paths 
         having node N1 as ingress.
      The first path is from N1 through endpoint nodes N4 and N5, 
      which is represented by SID list &lt;B:4, B:5&gt;.
      The second path is from N1 through endpoint nodes N2, N4 and N5,
      which is represented by SID list &lt;B:2, B:4, B:5&gt;.

      For a packet to be transported by the first path, 
      N1 encapsulates the packet with &lt;B:4, B:5&gt;. 
      For a packet to be transported by the second path, 
      N1 encapsulates the packet with &lt;B:2, B:4, B:5&gt;.</t>

      <t>When N4 fails, the packet on each of the two paths 
      needs to bypass the failed endpoint
      N4 and be forwarded to the next endpoint N5 after the failed
      endpoint.</t>

      <t>During the first time period 
      (i.e., after N4 fails and before IGP converges on the failure),
      N3 (upstream neighbor of N4) as a Repair Node receives 
      the packet for each of the two SRv6 paths.
      It forwards the packet around
      the failed endpoint N4 after detecting the failure of the outbound
      interface/link to the endpoint B:4. 
      It uses the TI-LFA to forward the packet through
      encapsulating the packet with SID list &lt;B:6, B:7&gt; as a TI-LFA 
      repair path.</t>

      <t>During the second time period 
      (i.e., after N4 fails and after IGP converges on the failure):
      <list style="symbols">
        <t>For the first path, 
        N3 (upstream endpoint neighbor of N4) as a Repair Node receives 
        the packet,
        N3 has no FIB entry for the failed endpoint N4. 
        N3 forwards the packet around the failed endpoint N4
        to the next endpoint (e.g., N5) using the FIB entry for the next 
        endpoint. N3 changes the DA of the packet to the next SID B:5 
        and forwards the packet using the FIB entry for DA = B:5 
        (i.e., using IGP SPF path to B:5).</t>

        <t>For the second path, 
        N3 (upstream non-endpoint neighbor of N4) will not receive any packet for the path.
        The upstream endpoint N2 of the failed 
        endpoint N4 will not send any packet for the path to N3. 

        N2 has no FIB entry for the failed N4.
        N2, as a Repair Node, sends the packet around N4
        to the next endpoint (e.g., N5) using the FIB entry for the next 
        endpoint. N2 changes
        the DA of the packet to
        the next SID B:5 and sends the packet using the FIB entry 
        for DA = B:5 (i.e., using IGP SPF path to B:5).</t>
      </list>
</t>
    </section>

    <section title="SRv6 Midpoint Protection Behavior">
<!--
      <t>A node N protecting the failure of an endpoint node on a SRv6 path
      may be one of the following cases: 
        <list style="numbers">
          <t>A upstream neighbor (non-endpoint or endpoint): 
          The neighbor uses
          normal TI-LFA to re-route the packet around the failure 
          during the first time period.</t>

          <t>A upstream/previous endpoint node (neighbor or non-neighbor): 
          The upstream/previous endpoint node uses the SRv6 
          Midpoint Protection Mechanism during the second time period in 
          <xref target="srv6-midpoint-mech"/>. 
          A upstream/previous endpoint node: an endpoint node or 
          an endpoint x node (i.e., an endpoint with cross-connect node).
            <list style="symbols">
             <t>an endpoint node: the destination address (DA) of the packet
             received by N is a N's local END SID.</t>

             <t>an endpoint x node:
             the destination address (DA) of the packet received by N is a N's
             local End.X SID with an array of layer 3 adjacencies.</t>
            </list>
          </t>
        </list> 
      This section describes the behavior of a upstream/previous endpoint node 
      of an endpoint node for the two time periods after the endpoint node
      fails. 
      The upstream endpoint node can be the upstream neighbor or 
      non-neighbor of the failed node.</t>

      <section title="Upstream Endpoint Node as Repair Node">
-->
        <t><xref target="proc-upstream-node"/> shows the procedure
        of a upstream (endpoint) node of an endpoint node on an SRv6 path
        for midpoint protection in pseudo code.</t>
 
        <t>When the endpoint (e.g., N4) fails and 
        before IGP converges on the failure 
        (i.e., in the first period),
        if the upstream node (e.g., neighbor N3) of the failed endpoint 
        detects the failure of the link used to send the packet 
        for the path 
        and the FIB entry for the DA of the packet exists, 
        then it uses TI-LFA to fast re-route the packet around the failure 
        (refer to line 1 and 2 of the procedure);

        otherwise, the link used to send the packet works (i.e., no failure)
        or no FIB entry for DA of the packet 
        (i.e., after the failure and IGP converges on the failure, 
         or say in the second period).
        </t>

        <t>If the upstream node (e.g., endpoint N2 for the second path)
        has no FIB entry for the DA of the packet, then
        it changes the DA to the next SID and 
        sends the packet using the FIB entry for DA = next SID
        when the packet has a SRH with SIDs as a next header
        (refer to lines 3 to 6). 
        When the packet has no SRH with SIDs as a next header,
        the packet is dropped (refer to line 7 to 8).</t>

        <t>When the upstream node has a FIB entry for the DA of the packet
         (i.e., no failure or 
          there is a failure and before IGP converges on the failure 
          which is in the first time period), 
         it sends the packet using the FIB entry for the DA 
         (refer to line 9 to A).</t>

        <t>
        <figure anchor="proc-upstream-node"
          title="Procedure of Upstream Node for Midpoint Protection">
          <artwork align="center"><![CDATA[
 1: IF link for sending packet failed and FIB entry for DA exists THEN
 2:   use TI-LFA to re-route packet around failure; // in 1st period
 3: ELSE IF no FIB entry for DA of packet (i.e., in 2nd period) THEN 
 4:   IF NH = SRH && SL != 0 THEN // if next header is SRH with SIDs
 5:     SL--; DA = SRH[SL]; // change DA of packet to next SID/endpoint
 6:     forward packet using FIB entry for DA;//send packet to next SID
 7:   ELSE // next header is not SRH with SIDs 
 8:     drop the packet;
 9: ELSE //has FIB entry for DA of packet(i.e.,normal or in 1st period)
 A:   forward packet accordingly to FIB entry for DA;]]></artwork>
        </figure>

        </t>

<!--
      </section>
      <section title="Endpoint x Node as Repair Node">
        <t>When the Repair Node is an endpoint x node, it provides fast
        protections for the failure through executing the following procedure
        after updating DA.</t>

        <figure>
          <artwork><![CDATA[
     IF the layer-3 adjacency interface is down THEN
       FIB lookup on the updated DA;
       IF the primary interface used to forward the packet failed THEN
         the normal TI-LFA is executed;
       ELSE IF there is no FIB entry for forwarding the packet THEN
         IF NH = SRH && SL != 0 THEN
           SL decreases; update the IPv6 DA with SRH[SL];
           FIB lookup on the updated DA;
           forward the packet according to the matched entry;
         ELSE
           drop the packet;
     ELSE
       forward accordingly to the matched entry;]]></artwork>
        </figure>
        <t/>
      </section>
-->
    </section>

    <section title="Determining whether the Endpoint could Be Bypassed">
      <t>SRv6 Midpoint Protection provides a mechanism to bypass a failed
      endpoint. But in some scenarios, some important functions may be
      implemented in the bypassed failed endpoints that should not be
      bypassed, such as firewall functionality or In-situ Flow Information
      Telemetry of a specified path. Therefore, a mechanism is needed to
      indicate whether an endpoint can be bypassed or not. <xref
      target="I-D.li-rtgwg-enhanced-ti-lfa"/> provides method to determine
      whether enable SRv6 midpoint protection or not by defining a "no bypass"
      flag for the SIDs in IGP.</t>
    </section>

    <section title="Security Considerations">
      <t>To ensure that the
      Repair node does not modify the SRH header Encapsulated by nodes outside
      the SRv6 Domain, 
      the segment within the SRH needs to be in the same domain as
      the repair node. 
      So it is necessary to check the skipped segment has the same
      block as the repair node.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>


  </middle>

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

    <references title="Informative References">
     <?rfc include="reference.I-D.ietf-spring-segment-protection-sr-te-paths"?>
      <?rfc include="reference.I-D.hu-spring-segment-routing-proxy-forwarding"?>
      <?rfc include="reference.I-D.ietf-rtgwg-segment-routing-ti-lfa"?>
      <?rfc include="reference.I-D.li-rtgwg-enhanced-ti-lfa"?>
    </references>

    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t>The authors would like to thank Bruno Decraene, Jeff Tantsura, 
      Ketan Talaulikar, Yingzhen Qu and Parag Kaneriya
      for their comments to this work.</t>
    </section>

  </back>
</rfc>
