<?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-11"
     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="13" month="January" year="2023"/>

    <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"/>
      <xref target="RFC8174"/> when, and only when, they appear in all
      capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Replication segment is a new type of segment for Segment Routing
      <xref target="RFC8402"/>, 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 title="Terminology">
        <t><list style="symbols">
            <t>Multi-point Service: A service that has multiple endpoints. A
            packet is delivered to all the endpoints.</t>

            <t>Replication Segment: A segment in SR domain that replicates
            packets.</t>

            <t>Replication Node: A node in SR domain which replication packets
            based on Replication Segment</t>

            <t>Downstream Nodes: A Replication Node replicates packets to a
            set of Downstream Nodes</t>

            <t>Replication-ID: Identifier of a Replication Segment at
            Replication Node</t>

            <t>Replication State: This is state of Replication Segment at a
            Replication Node. It is conceptually a list of replication
            branches to Downstream nodes. The list can be empty.</t>

            <t>Replication SID: Data plane identifier of a Replication
            Segment. This is a SR-MPLS label or SRv6 SID.</t>
          </list></t>
      </section>
    </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 Segment
      Routing over MPLS (SR-MPLS) and IPv6 (SRv6).</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>Replication-ID is a variable length field. In simplest case, it 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="RFC9256"/> 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. &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
      next-hop 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="RFC9256"/>.
      Downstream Replication SID is the Replication SID of the Replication
      Segment at the Downstream Node.</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 i.e. the list of
      Replication branches is empty. The Replication segment will have an
      indicator role of the node is Leaf. The operation performed on incoming
      Replication SID 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"/>. Replication Segment of a Bud
      Node has a list of Replication Branches as well as Leaf role
      indicator.</t>

      <t>In principle it is possible for different Replication Segments to
      replicate packets to the same Replication Segment on a Downstream Node.
      However, such usage is intentionally left out of scope of this
      document.</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>

        <t>There MAY be SIDs preceding the SR-MPLS Replication SID in order to
        guide a packet from a non-adjacent SR node to a Replication Node. A
        Replication Node MAY replicate a packet to a non-adjacent Downstream
        Node using SIDs it inserts in the copy preceding the downstream
        Replication SID. The Downstream Node may be leaf node of the
        Replication Segment, or another Replication Node, or both in case of
        bud node. A Replication Node MAY use an Anycast SID or BGP PeerSet SID
        in segment list to send a replicated packet to one downstream
        Replication node in an Anycast set if and only if all nodes in the set
        have an identical Replication SID and reach the same set of receivers.
        There MAY be SIDs after the Replication SID in the segment list of a
        packet. These SIDs are used to provide additional context for
        processing a packet locally at the node where the Replication SID is
        the Active Segment. The processing of SIDs following the Replication
        SID MUST NOT forward the SR-MPLS packet to another 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. If SRv6 SID
        compression is possible <xref
        target="I-D.ietf-spring-srv6-srh-compression"/>, the Replication node
        SHOULD use a Compressed SID (C-SID) container with Downstream
        Replication SID as the Last uSID in the container instead of
        H.Encaps.Red.</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.DTMC4/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.DTMC4/6 or End.DT2M. Note that decapsulation is not
        an inherent action of a Replication segment even on a bud/leaf
        node.</t>

        <t>There MAY be SIDs preceding the SRv6 Replication SID in order to
        guide a packet from a non-adjacent SR node to a Replication Node via
        an explicit path. A Replication Node MAY steer a replicated packet on
        an explicit path to a non-adjacent Downstream Node using SIDs it
        inserts in the copy preceding the downstream Replication SID. The
        Downstream Node may be leaf node of the Replication Segment, or
        another Replication Node, or both in case of bud node. For SRv6, as
        described in above paragraphs, the insertion of SIDs prior to
        Replication SID entails a new IPv6 encapsulation with SRH, but this
        can be optimized on Root node or for compressed SRv6 SIDs. Note that
        locator of Replication SID is sufficient to guide a packet on IGP
        shortest path, for default or Flex algo, between non-adjacent nodes. A
        Replication Node MAY use an Anycast SID or BGP PeerSet SID in segment
        list to send a replicated packet to one downstream Replication node in
        an Anycast set if and only if all nodes in the set have an identical
        Replication SID and reach the same set of receivers. There MAY be SIDs
        after the Replication SID in the SRH of a packet. These SIDs are used
        to provide additional context for processing a packet locally at the
        node where the Replication SID is the Active Segment. The processing
        of SIDs following the Replication SID MUST NOT forward the SRv6 packet
        to some other node. The restrictions described in this paragraph apply
        to both un-compressed and compressed SRv6 encapsulation.</t>

        <section title="ICMPv6 Error Messages">
          <t>ICMPv6 RFC <xref target="RFC4443"/> Section 2.4 states an ICMPv6
          error message MUST NOT be originated as a result of receiving a
          packet destined to an IPv6 multicast address. This is to prevent a
          storm of ICMPv6 error messages resulting from replicated IPv6
          packets from overwhelming a source node. There are two exceptions
          (1) the Packet Too Big message for Path MTU discovery, and (2)
          Parameter Problem Message, Code 2 reporting an unrecognized IPv6
          option.</t>

          <t>An implementation of Replication Segment for SRv6 MUST enforce
          this same restrictions and exceptions, though this specification
          does not use any extension header a future extension may do so and
          MUST support the exception (2) above.</t>
        </section>
      </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 title="Implementation Status">
      <t>Note to the RFC Editor: Please remove this section and reference to
      RFC 7942 before publication.</t>

      <t>This section records the status of known implementations of the
      protocol defined by this specification at the time of posting of this
      Internet-Draft, and is based on a proposal described in <xref
      target="RFC7942">RFC 7942</xref>. The description of implementations in
      this section is intended to assist the IETF in its decision processes in
      progressing drafts to RFCs. Please note that the listing of any
      individual implementation here does not imply endorsement by the IETF.
      Furthermore, no effort has been spent to verify the information
      presented here that was supplied by IETF contributors. This is not
      intended as, and must not be construed to be, a catalog of available
      implementations or their features. Readers are advised to note that
      other implementations may exist. According to <xref target="RFC7942">RFC
      7942</xref>, "this will allow reviewers and working groups to assign due
      consideration to documents that have the benefit of running code, which
      may serve as evidence of valuable experimentation and feedback that have
      made the implemented protocols more mature. It is up to the individual
      working groups to use this information as they see fit".</t>

      <t>There are two known implementations of this draft by Cisco and Nokia.
      Interoperability reports for the implementations are not applicable
      since this draft does not specify any inter-operable elements of
      Replication segments.</t>

      <section title="Cisco implmentation">
        <t>Cisco Implementation uses Replication Segments defined in this
        draft as a basis for PCE to compute and establish P2MP trees in SR
        domain to provide multi-point services. The implementation, based on
        latest version of this draft, is in production and supports all MUST
        and SHOULD clauses for SR-MPLS Replication segments. The documentation
        is available at <eref
        target="https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-3/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-73x/b-segment-routing-cg-asr9000-71x_chapter_01001.html ">Cisco
        documentation</eref> and the point of contact is Rishabh Parekh
        (riparekh@cisco.com).</t>
      </section>

      <section title="Nokia implementation">
        <t>Nokia has implemented replication SID as defined in this draft to
        establish P2MP tree in segment routing domain. The implementation
        supports SR-MPLS encapsulation and has all the Must and SHOULD clause
        in this draft. The implementation is at general availability maturity
        and is compliant with the latest version of the draft. The
        documentation for implementation can be found at <eref
        target="https://infocenter.nokia.com/public/7750SR207R1A/index.jsp?topic=%2Fcom.sr.multicast%2Fhtml%2Ftreesid.html">Nokia
        help</eref> and the point of contact is hooman.bidgoli@nokia.com.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA has assigned the following codepoint in "SRv6 Endpoint
      Behaviors" sub-registry of "Segment Routing Parameters" top-level
      registry for End.Replicate behavior.</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>75</c>

        <c>0x004B</c>

        <c>End.Replicate</c>

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

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations described in RFC 8402, RFC 8986 and RFC
      8754 also apply to this document.</t>

      <t>ICMPv6 specification <xref target="RFC4443"/> Section 5.2 describes
      how the Parameter Problem Message, code 2 exception for ICMPv6 Error
      message originated for IPv6 multicast destination can be used by a
      malicious node to cause a denial-of-service attack. Although this
      specification does not use any extension headers, any future extension
      doing so is susceptible to the same security consideration.</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, Joel Halpern and Ketan Talaulikar 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"/> Cisco Systems Inc.<vspace
      blankLines="0"/> Canada</t>

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

      <t>Kamran Raza <vspace blankLines="0"/> Cisco Systems, Inc. <vspace
      blankLines="0"/> Canada</t>

      <t>Email:skraza@cisco.com</t>
    </section>
  </middle>

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

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

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

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

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

      <?rfc include='reference.RFC.4443'?>
    </references>

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

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

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

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

      <?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'?>

      <?rfc include='reference.I-D.ietf-spring-srv6-srh-compression'?>
    </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="Topology for illustration of Replication Segment">
        <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. The state representation uses "R-SID-&gt;Lmn" to
        represent a packet replication with outgoing replication SID R-SID
        sent on interface 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="symbols">
            <t>2001:db8::/32 is an IPv6 block allocated by a Regional Internet
            Registry (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="symbols">
            <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.Replicate 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.Replicate 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. The state representation uses "R-SID-&gt;Lmn" to represent a
        packet replication with outgoing replication SID R-SID sent on
        interface Lmn.</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>
