<?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-geng-spring-redundancy-policy-03"
     ipr="trust200902">
  <front>
    <title abbrev="Redundancy Policy">Redundancy Policy for Redundancy
    Protection</title>

    <author fullname="Fan Yang" initials="F." surname="Yang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

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

        <email>shirley.yangfan@huawei.com</email>
      </address>
    </author>

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

      <address>
        <postal>
          <street>156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

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

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

    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd.</street>

          <city>Beijing</city>

          <region/>

          <code>100095</code>

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

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

    <date day="11" month="July" year="2022"/>

    <workgroup>SPRING</workgroup>

    <abstract>
      <t>This document introduces a variant of SR Policy called Redundancy
      Policy, in order to instruct the replication of service packets and
      assign more than one redundancy forwarding paths used for redundancy
      protection.</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 .</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Redundancy protection <xref
      target="I-D.ietf-spring-sr-redundancy-protection"/> is a generalized
      protection mechanism by replicating and transmitting copies of flow
      packets on redundancy node over multiple different and disjoint paths,
      and further eliminating the redundant packets at merging node. This
      document introduces Redundancy Policy to support redundancy protection,
      which is a variant of SR Policy <xref
      target="I-D.ietf-spring-segment-routing-policy"/>. Redundancy Policy
      instructs the replication of service packets and assigns more than one
      equivalent forwarding paths used for redundancy protection. Redundancy
      Policy applies equally to both MPLS data plane (SR-MPLS) <xref
      target="RFC8660"/> and Segment Routing with IPv6 data plane (SRv6) <xref
      target="RFC8986"/>.</t>
    </section>

    <section title="Terminology and Conventions">
      <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 BCP 14
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>

      <t>The other terminologies used in this document are:</t>

      <t>Redundancy Node: the start point of redundancy protection, where the
      network node replicates the flow packets.</t>

      <t>Merging Node: the end point of redundancy protection, where the
      network node eliminates and ordering(optionally) the flow packets.</t>

      <t>Redundancy Policy: an extended SR Policy which instructs more than
      one redundancy forwarding paths to support packet redundant
      transmission.</t>

      <t/>
    </section>

    <section title="Redundancy Policy">
      <t>Redundancy Policy is used to enable packet replication and
      instantiation more than one active ordered lists of segments between
      redundancy node and merging node to steer the same flow through
      different paths in an SR domain.</t>

      <section title="Identification of Redundancy Policy">
        <t>Redundancy Policy is a variant of SR Policy and also identified
        through the tuple &lt;headend, color, endpoint&gt;. Specifically, a
        redundancy policy is identified by &lt;redundancy node, color, merging
        node&gt;. Redundancy node is specified as IPv4/IPv6 address of headend
        of Redundancy Policy, which is the node to perform packet replication.
        Merging node is specified as IPv4/IPv6 address of endpoint of
        Redundancy Policy, which is the node to perform packet elimination.
        The value of color specifies the intent of the redundancy policy is
        "redundancy protection for high reliability", which indicates service
        packets are replicated into multiple copies and carried on different
        forwarding paths .</t>

        <t/>
      </section>

      <section title="Structure of Redundancy Policy ">
        <t>Redundancy policy shares the basic structure and elements with SR
        Policy and its information model is shown in the following:</t>

        <t><figure>
            <preamble/>

            <artwork><![CDATA[Redundancy policy POL1 <R Node= R1, Color = 1, M Node = M1>
        Candidate-path CP1 <protocol-origin = 20, originator
                           = 100:1.1.1.1, discriminator = 1>
             Flag Redundancy
             Preference 200
             SID-List1 <SID11...SID1i>
             SID-List2 <SID21...SID2j>
        Candidate-path CP2 <protocol-origin = 20, originator
                           = 100:2.2.2.2, discriminator = 2>
             Preference 100
             Weight W3, SID-List3 <SID31...SID3i>
]]></artwork>
          </figure></t>

        <t>The Redundancy Policy POL1 is identified by the tuple
        &lt;redundancy node, color, merging node&gt;, in which R1 is the
        redundancy node, M1 is the merging node, and Color 1 represents the
        intent of redundancy protection. Two candidate-paths CP1 and CP2
        instruct the ordered segment lists from redundancy node to merging
        node. In candidate path CP1, a new attribute Flag is added to indicate
        the type of candidate path. When the candidate path is indicated with
        the flag of redundancy, the attribute Weight is not applicable to the
        SID-Lists and all SID Lists of the candidate path are used for
        redundancy forwarding. Regarding the other attributes of candidate
        path such as originator, preference, priority, segment-list etc, the
        definitions apply the same as <xref
        target="I-D.ietf-spring-segment-routing-policy"/>.</t>

        <t/>
      </section>

      <section title="Flag of a Candidate Path">
        <t>Flag is an optional attribute of a candidate path, which is used to
        indicate the type of a candidate path is for redundancy forwarding.
        When the candidate path with flag of redundancy is selected as the
        active candidate path, this SR Policy is identified as the Redundancy
        Policy. Flag of a candidate path is an 8-bit bitmap. The table below
        specifies the current definition of Flag:</t>

        <t><figure>
            <preamble/>

            <artwork><![CDATA[+----------------------------------+
| Bitmap | Flag |   Description    |
+----------------------------------+
|   0    |  R   | Redundancy paths |
+----------------------------------+
|  1-7   |  U   |    Reserved      |
+----------------------------------+]]></artwork>

            <postamble>Figure 2: Flag</postamble>
          </figure></t>
      </section>

      <section title="Behavior of Redundancy Policy">
        <t>When the SR policy is identified as a redundancy policy, network
        node uses rules to compute and select the valid active ordered
        segment-lists for redundancy forwarding. The specific rules are:</t>

        <t><list style="symbols">
            <t>The candidate paths are selected to determine the best path of
            an SR policy. Preference, Protocol-Origin, and other tie-breaking
            rules defined in section 2.9 of <xref
            target="I-D.ietf-spring-segment-routing-policy"/> are evaluated
            until only one valid best path is selected. </t>

            <t>In a redundancy policy, the candidate path with a flag of
            redundancy is always selected as the best path in the first place.
            </t>

            <t>When the selected active candidate path is with a flag of
            redundancy, all the segment-lists of the candidate path are used
            as the active segment-lists for redundancy forwarding, where each
            active segment-list carries an entire copy of service packets.</t>

            <t>Weight is not applicable for the segment-lists in a candidate
            path with a flag of redundancy. Redundancy policy has no purpose
            of weighted load-balancing.</t>

            <t>The candidate path without a flag of redundancy in the same SR
            policy with the candidate paths with a flag, is considered as the
            backup path, which allowing provisioning of multiple path
            options.</t>
          </list>Take the information model in section 3.2 as an example,
        preference value 200 of CP1 is higher than preference value 100 of
        CP2, thus CP1 is selected as the active candidate path. Because CP1 is
        with the flag of redundancy, both Segment-List1 and Segment-List2 are
        selected as the active Segment-Lists for redundancy forwarding. After
        service packets are replicated, each segment-list forwards each
        replicas of service packets. When CP1 becomes invalid and fallbacks to
        CP2, CP2 provides the backup path to the redundancy forwarding.</t>

        <t/>
      </section>

      <section title="BSID and Redundancy Policy">
        <t>Redundancy policy can be optionally associated with a Binding
        Segment. Redundancy SID defined in <xref
        target="I-D.ietf-spring-sr-redundancy-protection"/> can be the Binding
        SID of redundancy policy. In other words, Redundancy SID triggers the
        instantiation of redundancy policy in the forwarding plane on
        redundancy node.</t>

        <t/>
      </section>

      <section title="Steering into a Redundancy Policy">
        <t>A packet is steered into a Redundancy Policy at a redundancy node
        in following ways:</t>

        <t><list style="symbols">
            <t>Incoming packets have an active SID matching the Redundancy SID
            at the redundancy node.</t>

            <t>Per-destination Steering: incoming packets match a BGP/Service
            route which recurses on a Redundancy Policy.</t>

            <t>Per-flow Steering: incoming packets match or recurse on a
            forwarding array of where some of the entries are Redundancy
            Policy.</t>

            <t>Policy-based Steering: incoming packets match a routing policy
            which redirects them on a Redundancy Policy.</t>
          </list></t>

        <t/>
      </section>

      <section title="Protocol Extensions">
        <t>Similar to SR Policy, Redundancy Policy requires the control plane
        protocol extensions to distribute candidate paths and other
        information. New sub-TLVs are expected to be defined to encode new
        information of Redundancy Policy Candidate Paths in BGP <xref
        target="I-D.ietf-idr-segment-routing-te-policy"/> and PCEP <xref
        target="I-D.ietf-pce-segment-routing-policy-cp"/>.</t>

        <t/>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD</t>
    </section>
  </middle>

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

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

      <?target include="reference.RFC.8660"?>

      <?target include='reference.I-D.ietf-spring-segment-routing-policy'?>

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

    <references title="Informative References">
      <?target include='reference.I-D.ietf-spring-sr-redundancy-protection'?>

      <?target include='reference.I-D.ietf-idr-segment-routing-te-policy'?>

      <?target include='reference.I-D.ietf-pce-segment-routing-policy-cp'?>

      <?target ?>

      <?target ?>
    </references>
  </back>
</rfc>
