<?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-spring-sr-replication-segment-07"
     ipr="trust200902">
  <front>
    <title abbrev="SR Replication Segment">SR Replication Segment for
    Multi-point Service Delivery</title>

    <author fullname="Daniel Voyer (editor)" initials="D."
            surname="Voyer, Ed.">
      <organization>Bell Canada</organization>

      <address>
        <postal>
          <street/>

          <city>Montreal</city>

          <region/>

          <code/>

          <country>CA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>daniel.voyer@bell.ca</email>

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

    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street/>

          <city>Brussels</city>

          <region/>

          <code/>

          <country>BE</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>cfilsfil@cisco.com</email>

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

    <author fullname="Rishabh Parekh" initials="R." surname="Parekh">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street/>

          <city>San Jose</city>

          <region/>

          <code/>

          <country>US</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>riparekh@cisco.com</email>

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

    <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street/>

          <city>Ottawa</city>

          <region/>

          <code/>

          <country>CA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>hooman.bidgoli@nokia.com</email>

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

    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization>Juniper Networks</organization>

      <address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>

    <date day="07" month="March" year="2022"/>

    <abstract>
      <t>This document describes the SR Replication segment for Multi-point
      service delivery. A SR Replication segment allows a packet to be
      replicated from a Replication Node to downstream nodes.</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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>We define a new type of segment for Segment Routing <xref
      target="RFC8402"/>, called Replication segment, which allows a node
      (henceforth called as Replication Node) to replicate packets to a set of
      other nodes (called Downstream Nodes) in a Segment Routing Domain.
      Replication segments provide building blocks for Point-to-Multipoint
      Service delivery via SR Point-to-Multipoint (SR P2MP) policy. A
      Replication segment can replicate packet to directly connected nodes or
      to downstream nodes (without need for state on the transit routers).
      This document focuses on the Replication segment building block. The use
      of one or more stitched Replication segments constructed for SR P2MP
      Policy tree is specified in <xref
      target="I-D.ietf-pim-sr-p2mp-policy"/>.</t>
    </section>

    <section title="Replication Segment">
      <t>In a Segment Routing Domain, a Replication segment is a logical
      construct which connects a Replication Node to a set of Downstream
      Nodes. A Replication segment is a local segment instantiated at a
      Replication node. It can be either provisioned locally on a node or
      programmed by a PCE. Replication segments apply equally to both SR-MPLS
      and SRv6 instantiations of Segment Routing.</t>

      <t>A Replication segment is identified by the tuple &lt;Replication-ID,
      Node-ID&gt;, where:</t>

      <t><list style="symbols">
          <t>Replication-ID: An identifier for a Replication segment that is
          unique in context of the Replication Node.</t>

          <t>Node-ID: The address of the Replication Node that the Replication
          segment is for. Note that the root of a multi-point service is also
          a Replication Node.</t>
        </list></t>

      <t>In simplest case, Replication-ID can be a 32-bit number, but it can
      be extended or modified as required based on specific use of a
      Replication segment. When the PCE signals a Replication segment to its
      node, the &lt;Replication-ID, Node-ID&gt; tuple identifies the segment.
      Examples of such signaling and extension are described in <xref
      target="I-D.ietf-pim-sr-p2mp-policy"/>.</t>

      <t>A Replication segment includes the following elements: <list
          style="symbols">
          <t>Replication SID: The Segment Identifier of a Replication segment.
          This is a SR-MPLS label or a SRv6 SID <xref target="RFC8402"/>.</t>

          <t>Downstream Nodes: Set of nodes in Segment Routing domain to which
          a packet is replicated by the Replication segment.</t>

          <t>Replication State: See below.</t>
        </list></t>

      <t>The Downstream Nodes and Replication State of a Replication segment
      can change over time, depending on the network state and leaf nodes of a
      multi-point service that the segment is part of.</t>

      <t>Replication SID identifies the Replication segment in the forwarding
      plane. At a Replication node, the Replication SID is the equivalent of
      Binding SID <xref target="I-D.ietf-spring-segment-routing-policy"/> of a
      Segment Routing Policy.</t>

      <t>Replication State is a list of replication branches to the Downstream
      Nodes. In this document, each branch is abstracted to a &lt;Downstream
      Node, Downstream Replication SID&gt; tuple.</t>

      <t>In a branch tuple, &lt;Downstream Node&gt; represents the
      reachability from the Replication Node to the Downstream Node. In its
      simplest form, this MAY be specified as an interface or nexthop if
      downstream node is adjacent to the Replication Node. The reachability
      may be specified in terms of Flex-Algo path (including the default algo)
      <xref target="I-D.ietf-lsr-flex-algo"/>, or specified by an SR explicit
      path represented either by a SID-list (of one or more SIDs) or by a
      Segment Routing Policy <xref
      target="I-D.ietf-spring-segment-routing-policy"/>.</t>

      <t>A packet is steered into a Replication segment at a Replication Node
      in two ways:</t>

      <t><list style="symbols">
          <t>When the Active Segment <xref target="RFC8402"/> is a locally
          instantiated Replication SID</t>

          <t>By the root of a multi-point service based on local configuration
          outside the scope of this document.</t>
        </list></t>

      <t>In either case, the packet is replicated to each Downstream node in
      the associated Replication state.</t>

      <t>If a Downstream Node is an egress (aka leaf) of the multi-point
      service, i.e. no further replication is needed, then that leaf node's
      Replication segment will not have any Replication State and the
      operation is NEXT. At an egress node, the Replication SID MAY be used to
      identify that portion of the multi-point service. Notice that the
      segment on the leaf node is still referred to as a Replication segment
      for the purpose of generalization.</t>

      <t>A node can be a bud node, i.e. it is a Replication Node and a leaf
      node of a multi-point service at the same time <xref
      target="I-D.ietf-pim-sr-p2mp-policy"/>.</t>

      <section title="SR-MPLS data plane">
        <t>When the Active Segment is a Replication SID, the processing
        results in a POP operation and lookup of the associated Replication
        state. For each replication in the Replication state, the operation is
        a PUSH of the downstream Replication SID and an optional segment list
        on to the packet which is forwarded to the Downstream node. For leaf
        nodes the inner packet is forwarded as per local configuration.</t>

        <t>When the root of a multi-point service steers a packet to a
        Replication segment, it results in a replication to each Downstream
        node in the associated replication state. The operation is a PUSH of
        the replication SID and an optional segment list on to the packet
        which is forwarded to the downstream node.</t>
      </section>

      <section title="SRv6 data plane">
        <t>In SRv6 <xref target="RFC8986"/>, the &ldquo;Endpoint with
        replication&rdquo; behavior (End.Replicate for short) replicates a
        packet and forwards the packet according to a Replication state.</t>

        <t>When processing a packet destined to a local Replication-SID, the
        packet is replicated to Downstream nodes and/or locally delivered off
        tree (when this is a bud/leaf node) according to the associated
        replication state. For replication, the outer header is re-used, and
        the Downstream Replication SID is written into the outer IPv6 header
        destination address. If required, an optional segment list may be used
        on some branches using H.Encaps.Red (while some other branches may not
        need that). Note that this H.Encaps.Red is independent from the
        replication segment &ndash; it is just used to steer the replicated
        traffic on a traffic engineered path to a Downstream node.</t>

        <t>The above also applies when the Replication segment is for the Root
        node, whose upstream node has placed the Replication-SID in the
        header. A local application (e.g. MVPN/EVPN) may also apply
        H.Encaps.Red and then steer the resulting traffic into the segment.
        Again note that the H.Encaps.Red is independent of the Replication
        segment &ndash; it is the action of the application (e.g. MVPN/EVPN
        service). If the service is on a Root node, the two H.Encaps
        mentioned, one for the service and other in the previous paragraph for
        replication to Downstream node SHOULD be combined for optimization (to
        avoid extra IPv6 encapsulation).</t>

        <t>For the local delivery on a bud/leaf node, the action associated
        with Replication-SID is &ldquo;look at next SID in SRH&rdquo;. The
        next SID could be a SID with End.DTM4/6 or End.DT2M local behavior
        (equivalent of MVPN/EVPN PMSI label in case of tunnel sharing across
        multiple VPNs). There may also not be a next SID (e.g. MVPN/EVPN with
        one tunnel per VPN), in which case the Replication-SID is then
        equivalent to End.DTM4/6 or End.DT2M. Note that decapsulation is not
        an inherent action of a Replication segment even on a bud/leaf
        node.</t>
      </section>
    </section>

    <section title="Use Cases">
      <t>In the simplest use case, a single Replication segment includes the
      root node of a multi-point service and the egress/leaf nodes of the
      service as all the Downstream Nodes. This achieves Ingress Replication
      <xref target="RFC7988"/> that has been widely used for MVPN <xref
      target="RFC6513"/> and EVPN <xref target="RFC7432"/> BUM (Broadcast,
      Unknown and Multicast) traffic.</t>

      <t>Replication segments can also be used as building blocks for
      replication trees when Replication segments on the root, intermediate
      Replication Nodes and leaf nodes are stitched together to achieve
      efficient replication. That is specified in <xref
      target="I-D.ietf-pim-sr-p2mp-policy"/>.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document requires registration of End.Replicate behavior in
      "SRv6 Endpoint Behaviors" sub-registry of "Segment Routing Parameters"
      top-level registry.</t>

      <texttable anchor="endpoint_cp_types"
                 title="IETF - SRv6 Endpoint Behaviors">
        <ttcol align="left">Value</ttcol>

        <ttcol align="center">Hex</ttcol>

        <ttcol align="center">Endpoint behavior</ttcol>

        <ttcol align="center">Reference</ttcol>

        <c>TBD</c>

        <c>TBD</c>

        <c>End.Replicate</c>

        <c>[This.ID]</c>
      </texttable>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>There are no additional security risks introduced by this design.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to acknowledge Siva Sivabalan, Mike Koldychev,
      Vishnu Pavan Beeram, Alexander Vainshtein, Bruno Decraene, Thierry
      Couture and Joel Halpern for their valuable inputs.</t>
    </section>

    <section title="Contributors">
      <t/>

      <t>Clayton Hassen <vspace blankLines="0"/> Bell Canada <vspace
      blankLines="0"/> Vancouver <vspace blankLines="0"/> Canada</t>

      <t>Email: clayton.hassen@bell.ca</t>

      <t>Kurtis Gillis <vspace blankLines="0"/> Bell Canada <vspace
      blankLines="0"/> Halifax <vspace blankLines="0"/> Canada</t>

      <t>Email: kurtis.gillis@bell.ca</t>

      <t>Arvind Venkateswaran <vspace blankLines="0"/> Cisco Systems, Inc.
      <vspace blankLines="0"/> San Jose <vspace blankLines="0"/> US</t>

      <t>Email: arvvenka@cisco.com</t>

      <t>Zafar Ali <vspace blankLines="0"/> Cisco Systems, Inc. <vspace
      blankLines="0"/> US</t>

      <t>Email: zali@cisco.com</t>

      <t>Swadesh Agrawal <vspace blankLines="0"/> Cisco Systems, Inc. <vspace
      blankLines="0"/> San Jose <vspace blankLines="0"/> US</t>

      <t>Email: swaagraw@cisco.com</t>

      <t>Jayant Kotalwar <vspace blankLines="0"/> Nokia <vspace
      blankLines="0"/> Mountain View <vspace blankLines="0"/> US</t>

      <t>Email: jayant.kotalwar@nokia.com</t>

      <t>Tanmoy Kundu <vspace blankLines="0"/> Nokia <vspace blankLines="0"/>
      Mountain View <vspace blankLines="0"/> US</t>

      <t>Email: tanmoy.kundu@nokia.com</t>

      <t>Andrew Stone <vspace blankLines="0"/> Nokia <vspace blankLines="0"/>
      Ottawa <vspace blankLines="0"/> Canada</t>

      <t>Email: andrew.stone@nokia.com</t>

      <t>Tarek Saad <vspace blankLines="0"/> Juniper Networks <vspace
      blankLines="0"/> Canada</t>

      <t>Email:tsaad@juniper.net</t>
    </section>
  </middle>

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

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

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

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

    <references title="Informative References">
      <?rfc include="reference.RFC.6513"?>

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

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

      <?rfc include='reference.I-D.ietf-pim-sr-p2mp-policy'?>

      <?rfc include='reference.I-D.ietf-lsr-flex-algo'?>

      <?rfc include='reference.I-D.filsfils-spring-srv6-net-pgm-illustration'?>
    </references>

    <section title="Illustration of a Replication Segment">
      <t>This section illustrates an example of a single Replication segment.
      Examples showing Replication segment stitched together to form P2MP tree
      (based on SR P2MP policy) are in <xref
      target="I-D.ietf-pim-sr-p2mp-policy"/>.</t>

      <t>Consider the following topology:</t>

      <figure title="Figure 1">
        <artwork><![CDATA[                               R3------R6
                              /         \
                      R1----R2----R5-----R7
                              \         / 
                               +--R4---+  ]]></artwork>
      </figure>

      <section title="SR-MPLS">
        <t>In this example, the Node-SID of a node Rn is N-SIDn and
        Adjacency-SID from node Rm to node Rn is A-SIDmn. Interface between Rm
        and Rn is Lmn.</t>

        <t>Assume a Replication segment identified with R-ID at Replication
        Node R1 and downstream Nodes R2, R6 and R7. The Replication SID at
        node n is R-SIDn. A packet replicated from R1 to R7 has to traverse
        R4.</t>

        <t>The Replication segment state at nodes R1, R2, R6 and R7 is shown
        below. Note nodes R3, R4 and R5 do not have state for the Replication
        segment.</t>

        <t>Replication segment at R1:</t>

        <figure>
          <artwork><![CDATA[Replication segment <R-ID,R1>:
 Replication SID: R-SID1
 Replication State:
   R2: <R-SID2->L12>
   R6: <N-SID6, R-SID6>
   R7: <N-SID4, A-SID47, R-SID7>
]]></artwork>
        </figure>

        <t>Replication to R2 steers packet directly to R2 on interface L12.
        Replication to R6, using N-SID6, steers packet via IGP shortest path
        to that node. Replication to R7 is steered via R4, using N-SID4 and
        then adjacency SID A-sID47 to R7.</t>

        <t>Replication segment at R2:</t>

        <figure>
          <artwork><![CDATA[Replication segment <R-ID,R2>:
 Replication SID: R-SID2
 Replication State:
   R2: <Leaf>]]></artwork>
        </figure>

        <t>Replication segment at R6:</t>

        <figure>
          <artwork><![CDATA[Replication segment <R-ID,R6>:
 Replication SID: R-SID6
 Replication State:
   R6: <Leaf>]]></artwork>
        </figure>

        <t>Replication segment at R7:</t>

        <figure>
          <artwork><![CDATA[Replication segment <R-ID,R7>:
 Replication SID: R-SID7
 Replication State:
   R7: <Leaf>]]></artwork>
        </figure>

        <t>When a packet is steered into the Replication segment at R1:</t>

        <t><list style="symbols">
            <t>Since R1 is directly connected to R2, R1 performs PUSH
            operation with just &lt;R-SID2&gt; label for the replicated copy
            and sends it to R2 on interface L12. R2, as Leaf, performs NEXT
            operation, pops R-SID2 label and delivers the payload.</t>

            <t>R1 performs PUSH operation with &lt;N-SID6, R-SID6&gt; label
            stack for the replicated copy to R6 and sends it to R2, the
            nexthop on IGP shortest path to R6. R2 performs CONTINUE operation
            on N-SID6 and forwards it to R3. R3 is the penultimate hop for
            N-SID6; it performs penultimate hop popping, which corresponds to
            the NEXT operation and the packet is then sent to R6 with
            &lt;R-SID6&gt; in the label stack. R6, as Leaf, performs NEXT
            operation, pops R-SID6 label and delivers the payload.</t>

            <t>R1 performs PUSH operation with &lt;N-SID4, A-SID47, R-SID7&gt;
            label stack for the replicated copy to R7 and sends it to R2, the
            nexthop on IGP shortest path to R4. R2 is the penultimate hop for
            N-SID4; it performs penultimate hop popping, which corresponds to
            the NEXT operation and the packet is then sent to R4 with
            &lt;A-SID47, R-SID1&gt; in the label stack. R4 performs NEXT
            operation, pops A-SID47, and delivers packet to R7 with
            &lt;R-SID7&gt; in the label stack. R7, as Leaf, performs NEXT
            operation, pops R-SID7 label and delivers the payload.</t>
          </list></t>
      </section>

      <section title="SRv6">
        <t>For SRv6 , we use SID allocation scheme, reproduced below, from
        Illustrations for SRv6 Network Programming <xref
        target="I-D.filsfils-spring-srv6-net-pgm-illustration"/></t>

        <t><list style="symbol">
            <t>2001:db8::/32 is an IPv6 block allocated by a RIR to the
            operator</t>

            <t>2001:db8:0::/48 is dedicated to the internal address space</t>

            <t>2001:db8:cccc::/48 is dedicated to the internal SRv6 SID
            space</t>

            <t>We assume a location expressed in 64 bits and a function
            expressed in 16 bits</t>

            <t>Node k has a classic IPv6 loopback address 2001:db8::k/128
            which is advertised in the IGP</t>

            <t>Node k has 2001:db8:cccc:k::/64 for its local SID space. Its
            SIDs will be explicitly assigned from that block</t>

            <t>Node k advertises 2001:db8:cccc:k::/64 in its IGP</t>

            <t>Function :1:: (function 1, for short) represents the End
            function with PSP support</t>

            <t>Function :Cn:: (function Cn, for short) represents the End.X
            function from to Node n</t>
          </list></t>

        <t>Each node k has: <list style="symbol">
            <t>An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to
            an End function with additional support for PSP</t>

            <t>An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to
            an End.X function to neighbor J with additional support for
            PSP</t>

            <t>An explicit SID instantiation 2001:db8:cccc:k:Fk::/128 bound to
            an End.Replcate function</t>
          </list></t>

        <t>Assume a Replication segment identified with R-ID at Replication
        Node R1 and downstream Nodes R2, R6 and R7. The Replication SID at
        node k, bound to an End.Replcate function, is
        2001:db8:cccc:k:Fk::/128. A packet replicated from R1 to R7 has to
        traverse R4.</t>

        <t>The Replication segment state at nodes R1, R2, R6 and R7 is shown
        below. Note nodes R3, R4 and R5 do not have state for the Replication
        segment.</t>

        <t>Replication segment at R1:</t>

        <figure>
          <artwork><![CDATA[Replication segment <R-ID,R1>:
 Replication SID: 2001:db8:cccc:1:F1::0
 Replication State:
   R2: <2001:db8:cccc:2:F2::0->L12>
   R6: <2001:db8:cccc:6:F6::0>
   R7: <2001:db8:cccc:4:C7::0, 2001:db8:cccc:7:F7::0>
]]></artwork>
        </figure>

        <t>Replication to R2 steers packet directly to R2 on interface L12.
        Replication to R6, using 2001:db8:cccc:6:F6::0, steers packet via IGP
        shortest path to that node. Replication to R7 is steered via R4, using
        End.X SID 2001:db8:cccc:4:C7::0 at R4 to R7.</t>

        <t>Replication segment at R2:</t>

        <figure>
          <artwork><![CDATA[Replication segment <R-ID,R2>:
 Replication SID: 2001:db8:cccc:2:F2::0
 Replication State:
   R2: <Leaf>]]></artwork>
        </figure>

        <t>Replication segment at R6:</t>

        <figure>
          <artwork><![CDATA[Replication segment <R-ID,R6>:
 Replication SID: 2001:db8:cccc:6:F6::0
 Replication State:
   R6: <Leaf>]]></artwork>
        </figure>

        <t>Replication segment at R7:</t>

        <figure>
          <artwork><![CDATA[Replication segment <R-ID,R7>:
 Replication SID: 2001:db8:cccc:7:F7::0
 Replication State:
   R7: <Leaf>]]></artwork>
        </figure>

        <t>When a packet, (A,B2), is steered into the Replication segment at
        R1:</t>

        <t><list style="symbols">
            <t>Since R1 is directly connected to R2, R1 creates encapsulated
            replicated copy (2001:db8::1, 2001:db8:cccc:2:F2::0) (A, B2), and
            sends it to R2 on interface L12. R2, as Leaf, removes outer IPv6
            header and delivers the payload.</t>

            <t>R1 creates encapsulated replicated copy (2001:db8::1,
            2001:db8:cccc:6:F6::0) (A, B2) then forwards the resulting packet
            on the shortest path to 2001:db8:cccc:6::/64. R2 and R3 forward
            the packet using 2001:db8:cccc:6::/64. R6, as Leaf, removes outer
            IPv6 header and delivers the payload.</t>

            <t>R1 creates encapsulated replicated copy (2001:db8::1,
            2001:db8:cccc:4:C7::0) (2001:db8:cccc:7:F7::0; SL=1) (A, B2) and
            sends it to R2, the nexthop on IGP shortest path to
            2001:db8:cccc:4::/64. R2 forwards packet to R4 using
            2001:db8:cccc:4::/64. R4 executes End.X function on
            2001:db8:cccc:4:C7::0, performs PSP action, removes SRH and sends
            resulting packet (2001:db8::1, 2001:db8:cccc:7:F7::0) (A, B2) to
            R7. R7, as Leaf, removes outer IPv6 header and delivers the
            payload.</t>
          </list></t>
      </section>
    </section>
  </back>
</rfc>
