SR Replication segment for Multi-point Service Delivery
draft-ietf-spring-sr-replication-segment-16

Network Working Group                                      D. Voyer, Ed.
Internet-Draft                                               Bell Canada
Intended status: Standards Track                             C. Filsfils
Expires: 1 February 2024                                       R. Parekh
                                                     Cisco Systems, Inc.
                                                              H. Bidgoli
                                                                   Nokia
                                                                Z. Zhang
                                                        Juniper Networks
                                                            31 July 2023

        SR Replication segment for Multi-point Service Delivery
              draft-ietf-spring-sr-replication-segment-16

Abstract

   This document describes the Segment Routing Replication segment for
   Multi-point service delivery.  A Replication segment allows a packet
   to be replicated from a Replication node to Downstream nodes.

Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 1 February 2024.

Voyer, Ed., et al.       Expires 1 February 2024                [Page 1]
Internet-Draft           SR Replication Segment                July 2023

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Replication Segment . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  SR-MPLS data plane  . . . . . . . . . . . . . . . . . . .   6
     2.2.  SRv6 data plane . . . . . . . . . . . . . . . . . . . . .   7
       2.2.1.  End.Replicate: Replicate and/or Decapsulate . . . . .   9
       2.2.2.  OAM Operations  . . . . . . . . . . . . . . . . . . .  11
       2.2.3.  ICMPv6 Error Messages . . . . . . . . . . . . . . . .  12
   3.  Implementation Status . . . . . . . . . . . . . . . . . . . .  12
     3.1.  Cisco implementation  . . . . . . . . . . . . . . . . . .  13
     3.2.  Nokia implementation  . . . . . . . . . . . . . . . . . .  13
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Appendix A.  Illustration of a Replication Segment  . . . . . . .  19
     A.1.  SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . .  19
     A.2.  SRv6  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
       A.2.1.  Pinging Replication SID . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

Voyer, Ed., et al.       Expires 1 February 2024                [Page 2]
Internet-Draft           SR Replication Segment                July 2023

1.  Introduction

   Replication segment is a new type of segment for Segment Routing (SR)
   [RFC8402], which allows a node (henceforth called a 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 (P2MP) delivery via
   SR Point-to-Multipoint (SR P2MP) policy.  A Replication segment can
   replicate packets 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 for both Segment
   Routing with Multiprotocol Label Switching (SR-MPLS) [RFC8660] and
   Segment Routing with IPv6 (SRv6) [RFC8986].  The examples in the
   Appendix illustrate the behavior of Replication Segment in SR domain.
   The use of one or more stitched Replication segments constructed for
   SR P2MP Policy tree is specified in [I-D.ietf-pim-sr-p2mp-policy].
   This document focuses on specifying replication behavior in an SR
   domain.  The management of IP multicast groups, building IP multicast
   trees, and performing multicast congestion control are out of scope
   of this document.

1.1.  Terminology

   This section defines terms introduced and used frequently in this
   document.  Refer to Terminology sections of [RFC8402], [RFC8754] and
   [RFC8986] for other terms used in Segment Routing.

   *  Replication segment: A segment in SR domain that replicates
      packets.  See Section 2 for details.

   *  Replication node: A node in SR domain which replicates packets
      based on Replication segment.

   *  Downstream nodes: A Replication segment replicates packets to a
      set of nodes.  These nodes are Downstream nodes.

   *  Replication state: State held for a Replication segment at a
      Replication node.  It is conceptually a list of replication
      branches to Downstream nodes.  The list can be empty.

   *  Replication SID: Data plane identifier of a Replication segment.
      This is a SR-MPLS label or SRv6 Segment Identifier (SID).

   *  SRH: IPv6 Segment Routing Header [RFC8754].

   *  Point-to-Multipoint Service: A service that has one ingress node
      and one or more egress nodes.  A packet is delivered to all the
      egress nodes

Voyer, Ed., et al.       Expires 1 February 2024                [Page 3]
Internet-Draft           SR Replication Segment                July 2023

   *  Root node: An ingress node of a P2MP service,

   *  Leaf node: An egress node of a P2MP service.

   *  Bud node: A node that is both a Replication node and a Leaf node.

1.2.  Use Cases

   In the simplest use case, a single Replication segment includes the
   ingress (Root) node of a multi-point service and the egress (Leaf)
   nodes of the service as all the Downstream nodes.  This achieves
   Ingress Replication [RFC7988] that has been widely used for Multicast
   VPN (MVPN) [RFC6513] and Ethernet VPN (EVPN)[RFC7432] BUM (Broadcast,
   Unknown and Multicast) traffic.

   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
   [I-D.ietf-pim-sr-p2mp-policy].

2.  Replication Segment

   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 Path Computation Element (PCE).

   A Replication segment is identified by the tuple <Replication-ID,
   Node-ID>, where:

   *  Replication-ID: An identifier for a Replication segment that is
      unique in context of the Replication node.

   *  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.

   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.  This is out of scope
   for this document.  The length of Replication-ID is specified in the
   signaling mechanism used for Replication segment.  Examples of such
   signaling and extensions are described in
   [I-D.ietf-pim-sr-p2mp-policy].  When the PCE signals a Replication
   segment to its node, the <Replication-ID, Node-ID> tuple identifies
   the segment.

Voyer, Ed., et al.       Expires 1 February 2024                [Page 4]
Internet-Draft           SR Replication Segment                July 2023

   A Replication segment includes the following elements:

   *  Replication SID: The Segment Identifier of a Replication segment.
      This is a SR-MPLS label or a SRv6 SID [RFC8402].

   *  Downstream nodes: Set of nodes in Segment Routing domain to which
      a packet is replicated by the Replication segment.

   *  Replication state: See below.

   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.

   Replication SID identifies the Replication segment in the forwarding
   plane.  At a Replication node, the Replication SID operates on
   Replication state of the Replication segment.

   Replication state is a list of replication branches to the Downstream
   nodes.  In this document, each branch is abstracted to a <Downstream
   node, Downstream Replication SID> tuple. <Downstream node> 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 Flexible Algorithm path
   (including the default algorithm) [RFC9350], or specified by an SR
   explicit path represented either by a SID-list (of one or more SIDs)
   or by a Segment Routing Policy [RFC9256].  Downstream Replication SID
   is the Replication SID of the Replication segment at the Downstream
   node.

   A packet is steered into a Replication segment at a Replication node
   in two ways:

   *  When the Active Segment [RFC8402] is a locally instantiated
      Replication SID

   *  By the Root of a multi-point service based on local configuration
      outside the scope of this document.

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

   If a Downstream node is an egress (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

Voyer, Ed., et al.       Expires 1 February 2024                [Page 5]
Internet-Draft           SR Replication Segment                July 2023

   incoming Replication SID is NEXT https://www.rfc-editor.org/rfc/
   rfc8402#section-2.  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.

   A node can be a Bud node, i.e. it is a Replication node and a Leaf
   node of a multi-point service [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.

   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.

2.1.  SR-MPLS data plane

   When the Active Segment is a Replication SID, the processing results
   in a POP https://www.rfc-editor.org/rfc/rfc8402#section-2 operation
   and lookup of the associated Replication state.  For each replication
   in the Replication state, the operation is a PUSH https://www.rfc-
   editor.org/rfc/rfc8402#section-2 of the downstream Replication SID
   and an optional segment list on to the packet to steer the packet to
   the Downstream node.

   For Leaf/Bud nodes local delivery off tree is per local
   configuration.  For some usages, this may involve looking at the next
   SID for example to get the necessary context.

   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.

   The following applies to Replication SID in MPLS encapsulation:

   *  SIDs MAY be inserted before the downstream 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 a Leaf
      node of the Replication segment, or another Replication node, or
      both in case of Bud node.

Voyer, Ed., et al.       Expires 1 February 2024                [Page 6]
Internet-Draft           SR Replication Segment                July 2023

   *  A Replication node MAY use an Anycast SID or Border Gateway
      Protocol (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.

   *  For some use cases, there MAY be SIDs after the Replication SID in
      the segment list of a packet.  These SIDs are used only by the
      Leaf/Bud nodes to forward a packet off the tree independent of the
      Replication SID.  Coordination regarding the absence or presence
      and value of context information for Leaf/Bud nodes is outside the
      scope of this document.

2.2.  SRv6 data plane

   For SRv6 [RFC8986], this document specifies “Endpoint with
   replication” behavior (End.Replicate for short) to replicate a packet
   and forward the replicas according to a Replication state.

   When processing a packet destined to a local Replication SID, the
   packet is replicated according to the associated Replication state to
   Downstream nodes and/or locally delivered off tree when this is a
   Leaf/Bud node.  IPv6 Hop Limit MUST be decremented and MUST be non-
   zero to replicate an incoming packet.  For replication, the outer
   header is re-used, and the Downstream Replication SID, from
   Replication state, 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 https://www.rfc-editor.org/rfc/
   rfc8986.html#name-hencapsred-hencaps-with-red (while some other
   branches may not need that).  Note that this H.Encaps.Red is
   independent from the replication segment – it is just used to steer
   the replicated packet on a traffic engineered path to a Downstream
   node.  The penultimate segment in encapsulating IPv6 header will
   execute Ultimate Segment Decapsulation (USD) flavor [RFC8986] of End/
   End.X behavior and forward the inner (replicated) packet to the
   Downstream node.  If H.Encaps.Red is used to steer a replicated
   packet to a Downstream node, the operator must ensure the MTU on path
   to the Downstream node is sufficient to account for additional SRv6
   encapsulation.

   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, for e.g.  Multicast VPN (MVPN)
   [RFC6513] or Ethernet VPN (EVPN) [RFC7432], 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 – it is the action of the application (e.g.  MVPN/EVPN
   service).  If the service is on a Root node, the two H.Encaps

Voyer, Ed., et al.       Expires 1 February 2024                [Page 7]
Internet-Draft           SR Replication Segment                July 2023

   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).

   For Leaf/Bud nodes local delivery off the tree is per Replication SID
   or next SID (if present in SRH).  For some usages, this may involve
   getting the necessary context either from the next SID (e.g., MVPN
   with shared tree) or from the replication SID itself (e.g., MVPN with
   non-shared tree).  In both cases, the context association is achieved
   with signaling and is out of scope of this document.

   The following applies to Replication SID in SRv6 encapsulation:

   *  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 a 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.

   *  The locator of Replication SID is sufficient to guide a packet on
      shortest path, for default or Flexible algorithm, 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.  Coordination regarding the absence or
      presence and value of context information for Leaf/Bud nodes is
      outside the scope of this document.

Voyer, Ed., et al.       Expires 1 February 2024                [Page 8]
Internet-Draft           SR Replication Segment                July 2023

2.2.1.  End.Replicate: Replicate and/or Decapsulate

   The "Endpoint with replication and/or decapsulate behavior
   (End.Replicate for short) is variant of End behavior.  The pseudo-
   code in this section follows the convention introduced in RFC 8986
   [RFC8986].

   A Replication state conceptually contains the following elements:

   Replication state:
   {
     Node-Role: {Head, Transit, Leaf, Bud};
     # On Leaf, replication list is zero length
     Replication-List:
     {
       Downstream node: <Node-Identifier>;
       Downstream Replication SID: R-SID;
       # Segment-List may be empty
       Segment-List: [SID-1, .... SID-N];
     }
   }

   Below is the Replicate function on a packet for Replication state
   (RS).

   S01. Replicate(RS, packet)
   S02. {
   S03.    For each Replication R in RS.Replication-List {
   S04.       Make a copy of the packet
   S05.       Set IPv6 DA = RS.R-SID
   S06.       If RS.Segment-List is not empty {
   S07.         # Head node may optimize below encapsulation and
   S08.         # the encapsulation of packet in a single encapsulation
   S09.         Execute H.Encaps or H.Encaps.Red with RS.Segment-List
                on packet copy #RFC 8986 Section 5.1, 5.2
   S10.       }
   S11.       Submit the packet to the egress IPv6 FIB lookup and
              transmission to the new destination
   S12.   }
   S13. }

   Notes:

   *  The IPv6 destination address in the copy of a packet is set from
      local state and not from SRH

   When N receives a packet whose IPv6 DA is S and S is a local
   End.Replicate SID, N does:

Voyer, Ed., et al.       Expires 1 February 2024                [Page 9]
Internet-Draft           SR Replication Segment                July 2023

  S01.   Lookup FUNCT portion of S to get Replication state RS
  S02.   If (IPv6 Hop Limit <= 1) {
  S03.     Discard the packet
  S04.     # ICMPv6 Time Exceeded is not permitted (Section 2.2.3 below)
  S05.   }
  S06.   If RS is not found {
  S07.     Discard the packet
  S08.   }
  S09.   Decrement IPv6 Hop Limit by 1
  S10.   If (IPv6 NH == SRH and SRH TLVs present) {
  S11.     Process SRH TLVs if allowed by local configuration
  S12.   }
  S13.   Call Replicate(RS, packet)
  S14.   If (RS.Node-Role == Leaf OR RS.Node-Role == Bud) {
  S15.     If (IPv6 NH == SRH and Segments Left > 0) {
  S16.       Derive packet processing context(PPC) from Segment List
  S17.       If (Segments Left != 0) {
  S18.         Discard the packet
  S19.         # ICMPv6 Parameter Problem with Code 0
  S20.         # (Erroneous header field encountered)
  S21.         # is not permitted (Section 2.2.3 below)
  S22.       }
  S23.     } Else {
  S24.       Derive packet processing context(PPC)
             from FUNCT of Replication SID
  S25.     }
  S26.     Process the next header
  S27.   }

   The processing of Upper-Layer header of a packet matching
   End.Replicate SID at Leaf/Bud node is as follows:

   S01.   If (Upper-Layer header type == 4(IPv4) OR
              Upper-Layer header type == 4(IPv6) ) {
   S02.     Remove the outer IPv6 header with all its extension headers
   S03.     Process the packet in context of PPC
   S04.   } Else If (Upper-Layer header type == 143(Ethernet) ) {
   S05.     Remove the outer IPv6 header with all its extension headers
   S06.     Process the Ethernet Frame in context of PPC
   S07.   } Else If (Upper-Layer header type is allowed
                     by local configuration) {
   S08.     Proceed to process the Upper-Layer header
   S09.   } Else {
   S10.     Discard the packet
   S11.     # ICMPv6 Parameter Problem with Code 4
   S12.     # (SR Upper-layer Header Error)
   S13.     # is not permitted (Section 2.2.3 below)
   S14.   }

Voyer, Ed., et al.       Expires 1 February 2024               [Page 10]
Internet-Draft           SR Replication Segment                July 2023

   Notes:

   *  The behavior above MAY result in a packet with partially processed
      segment list in SRH under some circumstances.  Fox example a head
      node may encode a context SID in an SRH.  As per pseudo-code
      above, a Replication node that receives a packet with local
      Replication SID will not process the SRH segment list and just
      forward a copy with unmodified SRH to Downstream nodes.

   *  The packet processing context usually is a FIB table T

   Processing the Replication SID may modify, if configured to process
   TLVs, the "variable-length data" of TLV types that change en route.
   Therefore, TLVs that change en route are mutable.  The remainder of
   the SRH (Segments Left, Flags, Tag, Segment List, and TLVs that do
   not change en route) are immutable while processing this SID.

2.2.1.1.  Hashed Message Authentication Code (HMAC) SRH TLV

   If a Root node encodes a context SID in SRH with an optional HMAC SRH
   TLV [RFC8754], it MUST set the 'D' bit as defined in Section 2.1.2
   because the Replication SID is not part of the segment list in SRH.

   HMAC generation and verification is as specified in Section 2.1.2.1
   of RFC 8754 (https://www.rfc-editor.org/rfc/rfc8754.html#name-hmac-
   generation-and-verific).  Verification of HMAC TLV is determined by
   local configuration.  If verification fails, an implementation of
   Replication SID MUST NOT originate an ICMPv6 error message (parameter
   problem, code 0).  The failure SHOULD be logged (rate limited) and
   the packet SHOULD be discarded.

2.2.2.  OAM Operations

   RFC 9259 [RFC9259] specifies procedures for OAM operations like ping
   and traceroute on SRv6 SIDs.

Voyer, Ed., et al.       Expires 1 February 2024               [Page 11]
Internet-Draft           SR Replication Segment                July 2023

   It is possible to ping a Replication SID of a Leaf/Bud node, assuming
   the source node knows the Replication SID a priori, directly by
   putting it in the IPv6 destination address without a SRH or in a SRH
   as the last segment.  While it is not possible to ping a Replication
   SID of a transit node because transit nodes do not process upper
   layer headers, it is still possible to ping a Replication SID of
   Leaf/Bud node of a tree via the Replication SID of intermediate
   transit nodes.  The source of ping MUST compute the ICMPv6 Echo
   Request checksum using the Replication SID of Leaf/Bud as destination
   address.  The source can then send the Echo Request packet to a
   transit node's Replication SID.  The transit nodes replicate the
   packet by replacing the IPv6 destination address till the packet
   reaches the Leaf/Bud node which responds with an ICMPv6 Echo Reply.
   Appendix A.2.1 illustrates examples of ping to a Replication SID.

   Traceroute to a Leaf/Bud node Replication SID is not possible due to
   restriction prohibiting origination of ICMPv6 Time Exceeded error
   message for a Replication SID as described in the section below.

2.2.3.  ICMPv6 Error Messages

   ICMPv6 RFC [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.

   An implementation of Replication segment for SRv6 MUST enforce these
   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.

3.  Implementation Status

   Note to the RFC Editor: Please remove this section and reference to
   RFC 7942 before publication.

   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 RFC 7942
   [RFC7942].  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

Voyer, Ed., et al.       Expires 1 February 2024               [Page 12]
Internet-Draft           SR Replication Segment                July 2023

   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 RFC 7942 [RFC7942],
   "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".

   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.

3.1.  Cisco implementation

   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 Cisco documentation
   (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) and
   the point of contact is Rishabh Parekh (riparekh@cisco.com).

3.2.  Nokia implementation

   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 Nokia help
   (https://infocenter.nokia.com/public/7750SR207R1A/
   index.jsp?topic=%2Fcom.sr.multicast%2Fhtml%2Ftreesid.html) and the
   point of contact is hooman.bidgoli@nokia.com.

4.  IANA Considerations

   IANA has assigned the following codepoint for End.Replicate behavior
   in the "SRv6 Endpoint Behaviors" registry in the "Segment Routing"
   registry group.

Voyer, Ed., et al.       Expires 1 February 2024               [Page 13]
Internet-Draft           SR Replication Segment                July 2023

            +=======+========+===================+===========+
            | Value |  Hex   | Endpoint behavior | Reference |
            +=======+========+===================+===========+
            | 75    | 0x004B |   End.Replicate   | [This.ID] |
            +-------+--------+-------------------+-----------+

                 Table 1: IETF - SRv6 Endpoint Behaviors

5.  Security Considerations

   The SID behaviors defined in this document are deployed within an SR
   domain [RFC8402].  An SR domain needs protection from outside
   attackers as described in [RFC8754] and following is a brief reminder
   of the same:

   *  For SR-MPLS deployments:

      -  By disabling MPLS on external interfaces of each edge node or
         any other technique to filter labeled traffic ingress on these
         interfaces.

   *  For SRv6 deployments:

      -  Allocate all the SIDs from an IPv6 prefix block S/s and
         configure each external interface of each edge node of the
         domain with an inbound infrastructure access list (IACL) that
         drops any incoming packet with a destination address in S/s RFC
         8754 Section 5.1 (https://www.rfc-editor.org/rfc/
         rfc8754.html#name-securing-the-sr-domain).

      -  Additionally, an iACL may be applied to all nodes (k)
         provisioning SIDs as defined in this specification:

         o  Assign all interface addresses from within IPv6 prefix A/a.
            At node k, all SIDs local to k are assigned from prefix Sk/
            sk.  Configure each internal interface of each SR node k in
            the SR domain with an inbound IACL that drops any incoming
            packet with a destination address in Sk/sk if the source
            address is not in A/a.  RFC 8754 Section 5.1
            (https://www.rfc-editor.org/rfc/rfc8754.html#name-securing-
            the-sr-domain).

      -  Denying traffic with spoofed source addresses by implementing
         recommendations in BCP 84 [RFC3704].

      -  Additionally the block S/s from which SIDs are allocated may be
         a non-routable address such as ULA or the prefix defined in
         [I-D.ietf-6man-sids].

Voyer, Ed., et al.       Expires 1 February 2024               [Page 14]
Internet-Draft           SR Replication Segment                July 2023

   Failure to protect the SR MPLS domain by correctly provisioning MPLS
   support per interface permits attackers from outside the domain to
   send packets that use the replication services provisioned within the
   domain.

   Failure to protect the SRv6 domain with IACLs on external interfaces,
   combined with failure to implement BCP 38 [RFC2827]or apply IACLs on
   nodes provisioning SIDs, permits attackers from outside the SR domain
   to send packets that use the replication services provisioned within
   the domain.

   Given the definition of the Replication segment in this document, an
   attacker subverting ingress filter above cannot take advantage of a
   stack of replication segments to perform amplification attacks nor
   link exhaustion attacks.  Replication segment trees always terminate
   at a Leaf or Bud node resulting in a decapsulation.  This however
   does allow an attacker to inject traffic to the receivers within a
   P2MP service.

   Incorrect provisioning of Replication segments can result in a chain
   of Replication segments forming a loop.  This can happen if
   Replication segments are provisioned on SR nodes without using a
   control plane.  In this case, replicated packets can create a storm
   till MPLS TTL (for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements
   to zero.  A control plane, for example PCE, can be used to prevent
   loops.  Loop prevention is out of scope of this document.  The
   control plane protocols (like PCEP, BGP, etc.) used to instantiate
   Replication segments can leverage their own security mechanisms such
   as encryption, authentication filtering etc.

   For SRv6, 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 concern.

6.  Acknowledgements

   The authors would like to acknowledge Siva Sivabalan, Mike Koldychev,
   Vishnu Pavan Beeram, Alexander Vainshtein, Bruno Decraene, Thierry
   Couture, Joel Halpern, Ketan Talaulikar and Darren Dukes for their
   valuable inputs.

7.  Contributors

   Clayton Hassen Bell Canada Vancouver Canada

Voyer, Ed., et al.       Expires 1 February 2024               [Page 15]
Internet-Draft           SR Replication Segment                July 2023

   Email: clayton.hassen@bell.ca

   Kurtis Gillis Bell Canada Halifax Canada

   Email: kurtis.gillis@bell.ca

   Arvind Venkateswaran Cisco Systems, Inc.  San Jose US

   Email: arvvenka@cisco.com

   Zafar Ali Cisco Systems, Inc.  US

   Email: zali@cisco.com

   Swadesh Agrawal Cisco Systems, Inc.  San Jose US

   Email: swaagraw@cisco.com

   Jayant Kotalwar Nokia Mountain View US

   Email: jayant.kotalwar@nokia.com

   Tanmoy Kundu Nokia Mountain View US

   Email: tanmoy.kundu@nokia.com

   Andrew Stone Nokia Ottawa Canada

   Email: andrew.stone@nokia.com

   Tarek Saad Cisco Systems Inc. Canada

   Email:tsaad@cisco.com

   Kamran Raza Cisco Systems, Inc.  Canada

   Email:skraza@cisco.com

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Voyer, Ed., et al.       Expires 1 February 2024               [Page 16]
Internet-Draft           SR Replication Segment                July 2023

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

   [RFC9259]  Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M.
              Chen, "Operations, Administration, and Maintenance (OAM)
              in Segment Routing over IPv6 (SRv6)", RFC 9259,
              DOI 10.17487/RFC9259, June 2022,
              <https://www.rfc-editor.org/info/rfc9259>.

8.2.  Informative References

   [I-D.filsfils-spring-srv6-net-pgm-illustration]
              Filsfils, C., Camarillo, P., Li, Z., Matsushima, S.,
              Decraene, B., Steinberg, D., Lebrun, D., Raszuk, R., and
              J. Leddy, "Illustrations for SRv6 Network Programming",
              Work in Progress, Internet-Draft, draft-filsfils-spring-
              srv6-net-pgm-illustration-04, 30 March 2021,
              <https://datatracker.ietf.org/doc/html/draft-filsfils-
              spring-srv6-net-pgm-illustration-04>.

   [I-D.ietf-6man-sids]
              Krishnan, S., "Segment Identifiers in SRv6", Work in
              Progress, Internet-Draft, draft-ietf-6man-sids-03, 11
              April 2023, <https://datatracker.ietf.org/doc/html/draft-
              ietf-6man-sids-03>.

Voyer, Ed., et al.       Expires 1 February 2024               [Page 17]
Internet-Draft           SR Replication Segment                July 2023

   [I-D.ietf-pim-sr-p2mp-policy]
              Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
              J. Zhang, "Segment Routing Point-to-Multipoint Policy",
              Work in Progress, Internet-Draft, draft-ietf-pim-sr-p2mp-
              policy-06, 13 April 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-
              p2mp-policy-06>.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <httpss://www.rfc-editor.org/info/rfc2827>.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <httpss://www.rfc-editor.org/info/rfc3704>.

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <https://www.rfc-editor.org/info/rfc6513>.

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [RFC7988]  Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
              Replication Tunnels in Multicast VPN", RFC 7988,
              DOI 10.17487/RFC7988, October 2016, <httpss://www.rfc-
              editor.org/info/rfc7988>.

   [RFC8660]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing with the MPLS Data Plane", RFC 8660,
              DOI 10.17487/RFC8660, December 2019, <httpss://www.rfc-
              editor.org/info/rfc8660>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

Voyer, Ed., et al.       Expires 1 February 2024               [Page 18]
Internet-Draft           SR Replication Segment                July 2023

   [RFC9350]  Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
              and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
              DOI 10.17487/RFC9350, February 2023, <httpss://www.rfc-
              editor.org/info/rfc9350>.

Appendix A.  Illustration of a Replication Segment

   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 [I-D.ietf-pim-sr-p2mp-policy].

   Consider the following topology:

                                  R3------R6
                                 /         \
                         R1----R2----R5-----R7
                                 \         /
                                  +--R4---+

         Figure 1: Topology for illustration of Replication Segment

A.1.  SR-MPLS

   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->Lmn" to represent a
   packet replication with outgoing replication SID R-SID sent on
   interface Lmn.

   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.

   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.

   Replication segment at R1:

   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>

Voyer, Ed., et al.       Expires 1 February 2024               [Page 19]
Internet-Draft           SR Replication Segment                July 2023

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

   Replication segment at R2:

   Replication segment <R-ID,R2>:
    Replication SID: R-SID2
    Replication state:
      R2: <Leaf>

   Replication segment at R6:

   Replication segment <R-ID,R6>:
    Replication SID: R-SID6
    Replication state:
      R6: <Leaf>

   Replication segment at R7:

   Replication segment <R-ID,R7>:
    Replication SID: R-SID7
    Replication state:
      R7: <Leaf>

   When a packet is steered into the Replication segment at R1:

   *  Since R1 is directly connected to R2, R1 performs PUSH operation
      with just <R-SID2> 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.

   *  R1 performs PUSH operation with <N-SID6, R-SID6> label stack for
      the replicated copy to R6 and sends it to R2, the nexthop on
      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 <R-SID6> in the
      label stack.  R6, as Leaf, performs NEXT operation, pops R-SID6
      label and delivers the payload.

   *  R1 performs PUSH operation with <N-SID4, A-SID47, R-SID7> label
      stack for the replicated copy to R7 and sends it to R2, the
      nexthop on 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
      <A-SID47, R-SID1> in the label stack.  R4 performs NEXT operation,

Voyer, Ed., et al.       Expires 1 February 2024               [Page 20]
Internet-Draft           SR Replication Segment                July 2023

      pops A-SID47, and delivers packet to R7 with <R-SID7> in the label
      stack.  R7, as Leaf, performs NEXT operation, pops R-SID7 label
      and delivers the payload.

A.2.  SRv6

   For SRv6 , we use SID allocation scheme, reproduced below, from
   Illustrations for SRv6 Network Programming
   [I-D.filsfils-spring-srv6-net-pgm-illustration]

   *  2001:db8::/32 is an IPv6 block allocated by a Regional Internet
      Registry (RIR) to the operator

   *  2001:db8:0::/48 is dedicated to the internal address space

   *  2001:db8:cccc::/48 is dedicated to the internal SRv6 SID space

   *  We assume a location expressed in 64 bits and a function expressed
      in 16 bits

   *  Node k has a classic IPv6 loopback address 2001:db8::k/128 which
      is advertised in the Interior Gateway Protocol (IGP)

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

   *  Node k advertises 2001:db8:cccc:k::/64 in its IGP

   *  Function :1:: (function 1, for short) represents the End function
      with Penultimate Segment Pop of SRH (PSP) [RFC8986] and USD
      support

   *  Function :Cn:: (function Cn, for short) represents the End.X
      function from to Node n with PSP and USD support

   Each node k has:

   *  An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an
      End function with additional support for PSP and USD

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

   *  An explicit SID instantiation 2001:db8:cccc:k:Fk::/128 bound to an
      End.Replicate function

Voyer, Ed., et al.       Expires 1 February 2024               [Page 21]
Internet-Draft           SR Replication Segment                July 2023

   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.

   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->Lmn" to
   represent a packet replication with outgoing replication SID R-SID
   sent on interface Lmn. "SL" represents and optional segment list used
   to steer a replicated packet on a specific path to a Downstream node.

   Replication segment at R1:

   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>, SL: <2001:db8:cccc:7:F7::0>

   Replication to R2 steers packet directly to R2 on interface L12.
   Replication to R6, using 2001:db8:cccc:6:F6::0, steers packet via
   shortest path to that node.  Replication to R7 is steered via R4,
   using H.Encaps.Red with End.X SID 2001:db8:cccc:4:C7::0 at R4 to R7.

   Replication segment at R2:

   Replication segment <R-ID,R2>:
    Replication SID: 2001:db8:cccc:2:F2::0
    Replication state:
      R2: <Leaf>

   Replication segment at R6:

   Replication segment <R-ID,R6>:
    Replication SID: 2001:db8:cccc:6:F6::0
    Replication state:
      R6: <Leaf>

   Replication segment at R7:

   Replication segment <R-ID,R7>:
    Replication SID: 2001:db8:cccc:7:F7::0
    Replication state:
      R7: <Leaf>

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

Voyer, Ed., et al.       Expires 1 February 2024               [Page 22]
Internet-Draft           SR Replication Segment                July 2023

   *  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.

   *  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.

   *  R1 has to steer packet to Downstream node R7 via node R4.  It can
      do this in one of two ways:

      -  R1 creates encapsulated replicated copy (2001:db8::1,
         2001:db8:cccc:7:F7::0) (A, B2) and then performs H.Encaps.Red
         using the SL to create (2001:db8::1, 2001:db8:cccc:4:C7::0)
         (2001:db8::1, 2001:db8:cccc:7:F7::0) (A, B2) packet.  It sends
         this packet to R2, the nexthop on 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 USD action, removes outer IPv6
         encapsulation 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.

      -  R1 is Root of replication segment.  Therefore, it can combine
         above encapsulations to create 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 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.

A.2.1.  Pinging Replication SID

   This section illustrates ping of a Replication SID.

   Node R1 pings replication SID of node R6 directly by sending the
   following packet:

   1.  R1 to R6: (2001:db8::1, 2001:db8:cccc:6:F6::0; NH=ICMPv6) (ICMPv6
       Echo Request)

Voyer, Ed., et al.       Expires 1 February 2024               [Page 23]
Internet-Draft           SR Replication Segment                July 2023

   2.  Node R6 as a Leaf processes upper layer ICMPv6 Echo Request and
       responds with ICMPv6 Echo Reply

   Node R1 pings Replication SID of R7 via R4 by sending the following
   packet with SRH:

   1.  R1 to R4: (2001:db8::1, 2001:db8:cccc:4:C7::0)
       (2001:db8:cccc:7:F7::0; SL=1; NH=ICMPV6) (ICMPv6 Echo Request)

   2.  R4 to R7: (2001:db8::1, 2001:db8:cccc:7:F7::0; NH=ICMPv6) (ICMPv6
       Echo Request)

   3.  Node R7 as a Leaf processes upper layer ICMPv6 Echo Request and
       responds with ICMPv6 Echo Reply

   Assume node R4 is a transit Replication node with Replication SID
   2001:db8:cccc:4:F4::0 replicating to R7.  Node R1 pings Replication
   SID of R7 via Replication SID of R4 as follows:

   1.  R1 to R4: (2001:db8::1, 2001:db8:cccc:4:F4::0; NH=ICMPv6) (ICMPv6
       Echo Request)

   2.  R4 replicates to R7 by replacing IPv6 destination address with
       Replication SID of R7 from its Replication state

   3.  R4 to R7: (2001:db8::1, 2001:db8:cccc:7:F7::0; NH=ICMPv6) (ICMPv6
       Echo Request)

   4.  Node R7 as a Leaf processes upper layer ICMPv6 Echo Request and
       responds with ICMPv6 Echo Reply

Authors' Addresses

   Daniel Voyer (editor)
   Bell Canada
   Montreal
   Canada
   Email: daniel.voyer@bell.ca

   Clarence Filsfils
   Cisco Systems, Inc.
   Brussels
   Belgium
   Email: cfilsfil@cisco.com

Voyer, Ed., et al.       Expires 1 February 2024               [Page 24]
Internet-Draft           SR Replication Segment                July 2023

   Rishabh Parekh
   Cisco Systems, Inc.
   San Jose,
   United States of America
   Email: riparekh@cisco.com

   Hooman Bidgoli
   Nokia
   Ottawa
   Canada
   Email: hooman.bidgoli@nokia.com

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net

Voyer, Ed., et al.       Expires 1 February 2024               [Page 25]