<?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-yang-idr-bgp-redundancy-policy-01"
     ipr="trust200902">
  <front>
    <title abbrev="Advertising Redundancy Policy in BGP">Advertising
    Redundancy Policy in BGP</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="13" month="March" year="2023"/>

    <workgroup>IDR Working Group</workgroup>

    <abstract>
      <t>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. In order to support the replication
      behavior of redundancy protection, Redundancy Policy is used to instruct
      the replication of service packets and assign more than one redundancy
      forwarding paths. This document defines the extensions to BGP to
      advertise the redundancy policy.</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. To
      support the replication on the redundancy node, Redundancy Segment<xref
      target="I-D.ietf-spring-sr-redundancy-protection"/> and Redundancy
      Policy<xref target="I-D.geng-spring-redundancy-policy"/> are specified
      respectively. Redundancy Segment is the variation of Binding SID to
      associate with a Redundancy Policy, instantiation of which provides
      segment lists of more than one disjoint paths. Redundancy Policy is a
      variant of SR Policy <xref
      target="I-D.ietf-spring-segment-routing-policy"/>, and shares the basic
      structure and elements with SR Policy. Different from SR policy, a new
      attribute Flag is added to indicate the type of the Candidate Path as
      redundancy type, which means all the Segment-Lists in this candidate
      path are used to forward the different copies of service traffics.</t>

      <t>This document defines the extensions to Border Gateway Protocol (BGP)
      to distribute the redundancy policy information. As a variant of SR
      policy, Redundancy Policy reuses the BGP extensions to SR policy
      candidate path and other information distribution specified in <xref
      target="I-D.ietf-idr-segment-routing-te-policy"/>. In addition, a new
      sub-TLV is defined in this document to support the distribution of new
      attribute of redundancy policy.</t>
    </section>

    <section title="Terminology">
      <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>
    </section>

    <section title="BGP Extensions to Redundancy Policy">
      <t>As a variant of SR policy, redundancy policy uses the same Subsequent
      Address Family Identifier (SAFI) whose NLRI identifies an SR Policy
      candidate path. The Tunnel Type identifier for SR Policy and a set of
      sub-TLVs specifying segment lists of the SR Policy candidate path, as
      well as other information about the SR Policy are reused. The content of
      Redundancy Policy Candidate Path is encoded in the Tunnel Encapsulation
      Attribute <xref target="RFC9012"/> by using the same Tunnel-Type of SR
      Policy Type.</t>

      <t>The redundancy policy encoding structure is as follows:</t>

      <t><figure>
          <preamble/>

          <artwork><![CDATA[ SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
 Attributes:
    Tunnel Encaps Attribute (23)
        Tunnel Type: SR Policy
        Binding SID
        SRv6 Binding SID
        Redundancy Flag 
        Preference
        Priority
        Policy Name
        Policy Candidate Path Name
        Explicit NULL Label Policy (ENLP)
        Segment List
            Segment
            Segment
            ...
        ...
]]></artwork>

          <postamble/>
        </figure></t>

      <t/>

      <section title="Flag Sub-TLV">
        <t>Redundancy policy introduces a new attribute Flag to indicate the
        type of Candidate Path as redundancy type. Correspondingly, a new Flag
        sub-TLV is defined to be attached at the candidate path level as a
        sub-TLV. The Flag sub-TLV is optional and MUST NOT appear more than
        once in the Redundancy Policy encoding.</t>

        <t><figure align="center">
            <preamble/>

            <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(TBD1)  |     Length    |      Flags    |    RESERVED   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

            <postamble>Candidate Path Flag Sub-TLV</postamble>
          </figure></t>

        <t>where:</t>

        <t/>

        <t><list style="symbols">
            <t>Type: to be allocated by IANA.</t>

            <t>Length: specifies the length of the value field not including
            Type and Length fields.</t>

            <t>Flags: 1 octet of flags. It is requested to IANA to create a
            new registry "SR Policy Candidate Path Flags" . One flag is
            defined at this writing:</t>
          </list><figure align="left">
            <preamble/>

            <artwork><![CDATA[  0                
  0 1 2 3 4 5 6 7 
 +-+-+-+-+-+-+-+-+
 |R|U|U|U|U|U|U|U|
 +-+-+-+-+-+-+-+-+
    where:
]]></artwork>

            <postamble>Candidate Path Flags</postamble>
          </figure></t>

        <t><list style="hanging">
            <t>R-Flag: This flag encodes the redundancy policy behavior</t>

            <t>U-Flag: Unused and unassigned</t>
          </list><list style="symbols">
            <t>RESERVED: 1 octet of reserved bits. SHOULD be set to zero on
            transmission and MUST be ignored on receipt.</t>
          </list></t>

        <t/>

        <t/>

        <t/>

        <t/>
      </section>

      <section title="Redundancy Policy with a Redundancy Segment">
        <t>Redundancy Policy can be optionally associated with a Binding
        Segment, which can only be Redundancy Segment. When there is a
        Redundancy Segment associated with Redundancy Policy, Redundancy
        Segment is required to be distributed by the Binding SID Sub-TLV or
        SRv6 Binding SID Sub-TLV defined in section 2.4.2 and 2.4.3 of <xref
        target="I-D.ietf-idr-segment-routing-te-policy"/> respectively. In
        SRv6, the endpoint behavior End.R of Redundancy Segment is required to
        be distributed with SRv6 Binding SID at the same time.</t>

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

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

      <section title="Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs">
        <t>This document defines new sub-TLVs in the registry "BGP Tunnel
        Encapsulation Attribute sub-TLVs" that has been assigned codepoints by
        IANA as follows via the early allocation process:</t>

        <t><figure>
            <preamble/>

            <artwork><![CDATA[Codepoint        Description           Reference
-----------------------------------------------------
   TBD           Flag sub-TLV          This I-D
]]></artwork>

            <postamble/>
          </figure></t>
      </section>
    </section>

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

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

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

      <?rfc include='reference.I-D.ietf-spring-sr-redundancy-protection'?>

      <?rfc include='reference.I-D.geng-spring-redundancy-policy'?>

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

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

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

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