<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!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"?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc category="std" consensus="true"
     docName="draft-ietf-spring-sr-replication-segment-19"
     ipr="trust200902"> ipr="trust200902"
     number="9524" obsoletes="" sortRefs="true" submissionType="IETF"
     symRefs="true" tocDepth="3" tocInclude="true" updates="" version="3"
     xml:lang="en">
  <front>

    <title abbrev="SR Replication Segment">SR Segment">Segment Routing Replication segment
    for
    Multi-point Multipoint Service Delivery</title>

    <seriesInfo name="RFC" value="9524"/>

    <author fullname="Daniel Voyer (editor)" Voyer" initials="D."
            surname="Voyer, Ed."> role="editor"
            surname="Voyer">
      <organization>Bell Canada</organization>
      <address>
        <postal>
          <street/>
          <city>Montreal</city>

          <region/>

          <code/>

          <country>CA</country>
          <country>Canada</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>
          <country>Belgium</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>
          <region>CA</region>
          <country>United States of America</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>
          <country>Canada</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="28" month="August" year="2023"/> month="February" year="2024"/>

    <area>rtg</area>
    <workgroup>spring</workgroup>

    <abstract>
      <t>This document describes the Segment Routing Replication segment for
      Multi-point
      multipoint service delivery. A Replication segment allows a packet to be
      replicated from a Replication replication node to Downstream downstream nodes.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP 14
      [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as
      shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Replication numbered="true" toc="default">
      <name>Introduction</name>

      <t>The Replication segment is a new type of segment for Segment Routing
      (SR) <xref format="default" target="RFC8402"/>, which allows a node
      (henceforth called a
      Replication node) "replication node") to replicate packets to a set
      of other nodes (called
      Downstream nodes) "downstream nodes") in a Segment Routing Domain. an SR domain.
      A Replication segment can replicate packets to directly connected nodes
      or to downstream nodes (without the need for state on the transit
      routers). This document focuses on specifying the behavior of a
      Replication segment for both Segment Routing with Multiprotocol Label
      Switching (SR-MPLS) <xref format="default" target="RFC8660"/> and
      Segment Routing with IPv6 (SRv6) <xref format="default"
      target="RFC8986"/>. The examples in the Appendix <xref format="default"
      target="Appendix"/> illustrate the behavior of a Replication Segment in
      an SR domain. The use of two or more Replication segments stitched
      together to form a tree using a control plane is left to be specified in
      other documents. The management of IP multicast groups, building IP
      multicast trees, and performing multicast congestion control are out of
      scope of this document.</t>

      <section title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>

        <t>This section defines terms introduced and used frequently in this
        document. Refer to the Terminology sections of <xref format="default"
        target="RFC8402"/>, <xref target="RFC8754"/> format="default" target="RFC8754"/>, and
        <xref format="default" target="RFC8986"/> for other terms used in Segment Routing.</t>

        <t><list style="symbols">
            <t>Replication segment: A
        SR.</t>

        <dl newline="false" spacing="normal">
          <dt>Replication segment:</dt>

          <dd>A segment in an SR domain that replicates packets. See <xref
          format="default" target="RepSeg"/> for details.</t>

            <t>Replication node: A details.</dd>

          <dt>Replication node:</dt>

          <dd>A node in an SR domain which that replicates packets based on a
          Replication segment.</t>

            <t>Downstream nodes: A segment.</dd>

          <dt>Downstream nodes:</dt>

          <dd>A Replication segment replicates packets to a set of nodes.
          These nodes are Downstream nodes.</t>

            <t>Replication state: State downstream nodes.</dd>

          <dt>Replication state:</dt>

          <dd>State held for a Replication segment at a
            Replication replication node. It
          is conceptually a list of replication Replication branches to Downstream downstream nodes.
          The list can be empty.</t>

            <t>Replication SID: Data empty.</dd>

          <dt>Replication-SID:</dt>

          <dd>Data plane identifier of a Replication segment. This is a an
          SR-MPLS label or SRv6 Segment Identifier
            (SID).</t>

            <t>SRH: IPv6 (SID).</dd>

          <dt>SRH:</dt>

          <dd>IPv6 Segment Routing Header <xref target="RFC8754"/>.</t>

            <t>Point-to-Multipoint Service: A format="default"
          target="RFC8754"/>.</dd>

          <dt>Point-to-Multipoint (P2MP) Service:</dt>

          <dd>A service that has one ingress node and one or more egress
          nodes. A packet is delivered to all the egress nodes</t>

            <t>Root node: An nodes.</dd>

          <dt>Root node:</dt>

          <dd>An ingress node of a P2MP service,</t>

            <t>Leaf node: An service.</dd>

          <dt>Leaf node:</dt>

          <dd>An egress node of a P2MP service.</t>

            <t>Bud node: A service.</dd>

          <dt>Bud node:</dt>

          <dd>A node that is both a Replication replication node and a Leaf
            node.</t>
          </list></t> leaf node.</dd>
        </dl>

	        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>

      <section title="Use Cases"> numbered="true" toc="default">
        <name>Use Cases</name>

        <t>In the simplest use case, a single Replication segment includes the
        ingress node of a multi-point multipoint service and the egress nodes of the
        service as all the Downstream downstream nodes. This achieves Ingress Replication
        <xref format="default" target="RFC7988"/> that has been widely used
        for Multicast VPN (MVPN) <xref format="default" target="RFC6513"/> and
        Ethernet VPN (EVPN)<xref (EVPN) <xref format="default" target="RFC7432"/> bridging
        of Broadcast, Unknown Unicast, and Multicast (BUM) traffic.  This Replication segment can be either
        provisioned locally on ingress and
        egress nodes, nodes can either be provisioned locally or using dynamic
        auto-discovery autodiscovery procedures for MVPN and
        EVPN. Note <xref format="default" target="RFC8986">SRv6</xref> has
        End.DT2M replication behavior for EVPN BUM traffic.</t>

        <t>Replication segments can also be used to form trees by stitching
        Replication segments on a Root root node, intermediate Replication nodes replication nodes,
        and Leaf leaf nodes for efficient delivery of MVPN and EVPN BUM
        traffic.</t>
      </section>
    </section>

    <section anchor="RepSeg" title="Replication Segment"> numbered="true" toc="default">
      <name>Replication Segment</name>

      <t>In a Segment Routing Domain, an SR domain, a Replication segment is a logical
      construct which that connects a Replication replication node to a set of Downstream 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 control plane.</t> plane.
	  </t>

      <t>Replication segments can be stitched together to form a tree by
      either local provisioning on nodes or using a control plane. The
      procedures for doing this are out of scope of this document. One such
      control plane using a PCE with the SR P2MP policy is specified in <xref
      format="default" target="I-D.ietf-pim-sr-p2mp-policy"/>. However, if
      local provisioning is used to stitch Replication segments, then a chain
      of Replication segments SHOULD NOT <bcp14>SHOULD NOT</bcp14> form a loop. If a
      control plane is used to stitch Replication segments, the control plane
      specification MUST <bcp14>MUST</bcp14> prevent
      loops, loops or to detect and mitigate
      loops in steady state.</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

      <dl newline="false" spacing="normal">
        <dt>Replication-ID:</dt>

        <dd>An identifier for a Replication segment that is unique in context
        of the Replication node.</t>

          <t>Node-ID: The replication node.</dd>

        <dt>Node-ID:</dt>

        <dd>The address of the Replication replication node that for the Replication
          segment is for. segment.
        Note that the Root root of a multi-point multipoint service is also a Replication node.</t>
        </list></t>
        node.</dd>
      </dl>

      <t>Replication-ID is a variable length variable-length field. In the simplest case, it
      can be a 32-bit number, but it can be extended or modified as required
      based on the specific use of a Replication segment. This is out of scope
      for this document. The length of the Replication-ID is specified in the
      signaling mechanism used for the Replication segment. Examples of such
      signaling and extensions are described in <xref format="default"
      target="I-D.ietf-pim-sr-p2mp-policy"/>. When the PCE signals a
      Replication segment to its node, the &lt;Replication-ID, Node-ID&gt;
      tuple identifies the segment.</t>

      <t>A Replication segment includes the following elements: <list
          style="symbols">
          <t>Replication SID: The elements:</t>

      <dl newline="false" spacing="normal">
        <dt>Replication-SID:</dt>

        <dd>The Segment Identifier of a Replication segment. This is a an
        SR-MPLS label or a an SRv6 SID <xref target="RFC8402"/>.</t>

          <t>Downstream nodes: Set format="default"
        target="RFC8402"/>.</dd>

        <dt>Downstream nodes:</dt>

        <dd>Set of nodes in Segment Routing an SR domain to which a packet is
        replicated by the Replication segment.</t>

          <t>Replication state: See below.</t>
        </list></t> segment.</dd>

        <dt>Replication state:</dt>

        <dd>See below.</dd>
      </dl>

      <t>The Downstream downstream nodes and Replication state (RS) of a Replication segment
      can change over time, depending on the network state and Leaf leaf nodes of a
      multi-point
      multipoint service that the segment is part of.</t>

      <t>Replication SID

      <t>The Replication-SID identifies the Replication segment in the
      forwarding plane. At a Replication replication node, the Replication SID Replication-SID operates on
      Replication state
      the RS of the Replication segment.</t>

      <t>Replication state

      <t>RS is a list of replication Replication branches to the Downstream downstream
      nodes. In this document, each branch is abstracted to a &lt;Downstream &lt;downstream
      node, Downstream Replication SID&gt; downstream Replication-SID&gt; tuple. &lt;Downstream &lt;downstream node&gt;
      represents the reachability from the Replication replication node to the Downstream downstream
      node. In its simplest form, this MAY <bcp14>MAY</bcp14> be specified as an
      interface or next-hop if the downstream node is adjacent to the Replication
      replication node. The reachability may be specified in terms of a
      Flexible Algorithm path (including the default algorithm) <xref target="RFC9350"/>,
      format="default" target="RFC9350"/> or specified by an SR explicit SR-explicit path
      represented either by a SID-list SID list (of one or more SIDs) or by a Segment
      Routing Policy <xref format="default" target="RFC9256"/>.
      Downstream Replication SID The downstream
      Replication-SID is the Replication SID Replication-SID of the Replication segment at the Downstream
      downstream node.</t>

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

      <t><list style="symbols">
          <t>When

      <ul spacing="normal">
        <li>When the Active Segment active segment <xref format="default" target="RFC8402"/>
        is a locally instantiated Replication SID</t>

          <t>By Replication-SID.</li>

        <li>By the Root root of a multi-point multipoint service based on local configuration
        that is outside the scope of this document.</t>
        </list></t> document.</li>
      </ul>

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

      <t>If a Downstream downstream node is an egress (Leaf) (leaf) of the multi-point multipoint service,
      no further replication is needed. The Leaf leaf node's Replication segment
      has an indicator for Leaf role the leaf role, and it does not have any Replication
      state i.e. RS (i.e., the list of Replication branches is empty. empty). The Replication
      SID Replication-SID at a Leaf leaf node MAY <bcp14>MAY</bcp14> be used to identify the multi-point multipoint
      service. Notice that the segment on the Leaf leaf node is still referred to
      as a
      Replication segment "Replication segment" for the purpose of generalization.</t>

      <t>A node can be a Bud node, i.e. bud node (i.e., it is a Replication replication node and a Leaf leaf
      node of a multi-point multipoint service <xref
      target="I-D.ietf-pim-sr-p2mp-policy"/>. format="default"
      target="I-D.ietf-pim-sr-p2mp-policy"/>). The Replication segment of a Bud
      bud node has a list of Replication Branches branches as well as Leaf a leaf role
      indicator.</t>

      <t>In principle principle, it is possible for different Replication segments to
      replicate packets to the same Replication segment on a Downstream downstream node.
      However, such usage is intentionally left out of scope of this
      document.</t>

      <section title="SR-MPLS data plane"> numbered="true" toc="default">
        <name>SR-MPLS Data Plane</name>

        <t>When the Active Segment active segment is a Replication SID, Replication-SID, the processing
        results in a POP <xref format="default" target="RFC8402"/> operation
        and the lookup of the associated Replication state. RS. For each
        replication in the Replication
        state, RS, the operation is a PUSH <xref
        format="default" target="RFC8402"/> of the downstream Replication SID Replication-SID
        and an optional segment list on to onto the packet to steer the packet to
        the Downstream downstream node.</t>

        <t>The operation performed on the incoming Replication SID Replication-SID is NEXT
        <xref format="default" target="RFC8402"/> at Leaf/Bud nodes a leaf or bud node where
        delivery of payload off the tree is per local configuration. For some
        usages, this may involve looking at the next SID SID, for example example, to get
        the necessary context.</t>

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

        <t>The following applies to Replication SID a Replication-SID in MPLS
        encapsulation:</t>

        <t><list style="symbols">
            <t>SIDs MAY

        <ul spacing="normal">
          <li>SIDs <bcp14>MAY</bcp14> be inserted before the downstream
          SR-MPLS Replication
            SID Replication-SID in order to guide a packet from a
          non-adjacent SR node to a
            Replication node.</t>

            <t>A Replication replication node.</li>

          <li>A replication node MAY <bcp14>MAY</bcp14> replicate a packet to a
          non-adjacent
            Downstream downstream node using SIDs it inserts in the copy
          preceding the downstream Replication SID. Replication-SID. The Downstream downstream node may be
          a Leaf leaf node of the Replication segment, or another Replication replication node, or
          both in the case of Bud node.</t>

            <t>A Replication a bud node.</li>

          <li>A replication node MAY <bcp14>MAY</bcp14> use an Anycast SID Anycast-SID or a
          Border Gateway Protocol (BGP) PeerSet SID PeerSet-SID in the segment list to
          send a replicated packet to one downstream Replication replication node in an Anycast a set of
          Anycast nodes. This occurs if and only if all nodes in the set have an
          identical Replication SID Replication-SID and reach the same set of receivers.</t>

            <t>For receivers.</li>

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

      <section anchor="SRv6" title="SRv6 data plane"> numbered="true" toc="default">
        <name>SRv6 Data Plane</name>

        <t>For SRv6 <xref format="default" target="RFC8986"/>, this document
        specifies
        &ldquo;Endpoint "Endpoint with replication&rdquo; replication and/or decapsulate" behavior (End.Replicate for
        short) to replicate a packet and forward the replicas according to a
        Replication state.</t> an
        RS.</t>

        <t>When processing a packet destined to a local Replication SID, Replication-SID, the
        packet is replicated according to the associated Replication state RS to
        Downstream
        downstream nodes and/or locally delivered off the tree when this is a
        Leaf/Bud node.For
        leaf or bud node. For replication, the outer header is re-used, reused, and the
        Downstream Replication SID,
        downstream Replication-SID, from Replication state, RS, is written into
        the outer IPv6 header destination address. Destination Address (DA). If required, an
        optional segment list may be used on some branches using H.Encaps.Red
        <xref format="default" target="RFC8986"/> (while some other branches
        may not need that). Note that this H.Encaps.Red is independent of the replication segment
        &ndash;
        Replication segment: it is just used to steer the replicated packet on
        a traffic
        engineered traffic-engineered path to a Downstream downstream node. The penultimate
        segment in the encapsulating IPv6 header will execute the Ultimate
        Segment Decapsulation (USD) flavor <xref format="default"
        target="RFC8986"/> of End/End.X behavior and forward the inner
        (replicated) packet to the Downstream downstream node. If H.Encaps.Red is used to
        steer a replicated packet to a Downstream downstream node, the operator must
        ensure the MTU on path to the Downstream downstream node is sufficient to account
        for additional SRv6 encapsulation. This also applies when the
        Replication segment is for the Root root node, whose upstream node has
        placed the Replication-SID in the header.</t>

        <t>A local application on Root, for e.g. root (e.g., MVPN <xref format="default"
        target="RFC6513"/> or EVPN <xref target="RFC7432"/>, format="default" target="RFC7432"/>)
        may also apply H.Encaps.Red and then steer the resulting traffic into
        the Replication segment. Again, note that the H.Encaps.Red is independent
        of the Replication segment
        &ndash; segment: it is the action of the application (e.g. MVPN/EVPN
        MVPN or EVPN service). If the service is on a Root root node, then the two
        H.Encaps mentioned, one for the service and the other in the previous
        paragraph for replication to
        Downstream node SHOULD the downstream node,
        <bcp14>SHOULD</bcp14> be combined for optimization (to avoid extra
        IPv6 encapsulation).</t>

        <t>When processing a packet destined to a local Replication SID, Replication-SID, the
        IPv6 Hop Limit MUST <bcp14>MUST</bcp14> be decremented and MUST
        <bcp14>MUST</bcp14> be non-zero to replicate the packet. A Root root node
        that encapsulates a payload can set the IPv6 Hop Limit based on a
        local policy. This local policy SHOULD <bcp14>SHOULD</bcp14> set the IPv6 Hop
        Limit so that a replicated packet can reach the furthest Leaf leaf node. A Root
        root node can also have a local policy to set the IPv6 Hop Limit from
        the payload. In this case, the IPv6 Hop Limit may not be sufficient to
        get the replicated packet to all the Leaf nodes;
        non-replication leaf nodes. Non-replication nodes i.e.
        (i.e., nodes which that forward replicated packets based on the IPv6 locator
        unicast prefix prefix) can decrement the IPv6 Hop Limit to zero and originate
        ICMPv6 Error error packets to the Root root node. This can result in a storm of
        ICMPv6 packets (see <xref format="default" target="ICMP"/>) to the
        Root
        root node. To avoid this, a Replication Segment segment has an optional IPv6
        Hop Limit threshold. Threshold. If this threshold is set, a Replication replication node MUST
        <bcp14>MUST</bcp14> discard an incoming packet with a local Replication SID
        Replication-SID if the IPv6 Hop Limit in the packet is less than the
        threshold and log this in a rate
        limited rate-limited manner. The IPv6 Hop Limit
        Threshold SHOULD <bcp14>SHOULD</bcp14> be set so that an incoming packet can
        be replicated to the furthest Leaf leaf node.</t>

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

        <t>The following applies to Replication SID a Replication-SID in SRv6
        encapsulation:</t>

        <t><list style="symbols">
            <t>There MAY

        <ul spacing="normal">
          <li>There <bcp14>MAY</bcp14> be SIDs preceding the SRv6 Replication SID Replication-SID in order to guide a packet from a non-adjacent SR node to a Replication
          replication node via an explicit path.</t>

            <t>A Replication path.</li>

          <li>A replication node MAY <bcp14>MAY</bcp14> steer a replicated packet
          on an explicit path to a non-adjacent Downstream downstream node using SIDs it
          inserts in the copy preceding the downstream Replication SID. Replication-SID. The Downstream
          downstream node may be a Leaf leaf node of the Replication segment, or
          another
            Replication replication node, or both in the case of Bud node.</t>

            <t>For a bud node.</li>

          <li>For SRv6, as described in above paragraphs, the insertion of
          SIDs prior to Replication SID the Replication-SID entails a new IPv6 encapsulation
          with SRH, but the SRH. However, this can be optimized on Root the root node or for
          compressed SRv6 SIDs.</t>

            <t>The SIDs.</li>

          <li>The locator of Replication SID the Replication-SID is sufficient to guide a
          packet on the shortest path, path between non-adjacent nodes for default
          or Flexible algorithm, between
            non-adjacent nodes.</t>

            <t>A Replication Algorithms.</li>

          <li>A replication node MAY <bcp14>MAY</bcp14> use an Anycast SID Anycast-SID or a
          BGP PeerSet SID PeerSet-SID in the segment list to send a replicated packet to
          one downstream
            Replication replication node in an Anycast set set. This occurs if
          and only if all nodes in the set have an identical Replication SID Replication-SID
          and reach the same set of
            receivers.</t>

            <t>There MAY receivers.</li>

          <li>There <bcp14>MAY</bcp14> be SIDs after the Replication SID 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
          Replication-SID is the Active Segment. active segment. Coordination regarding the
          absence or presence and value of context information for Leaf/Bud leaf and bud
          nodes is outside the scope of this document.</t>
          </list></t> document.</li>
        </ul>

        <section title="End.Replicate: numbered="true" toc="default">
          <name>End.Replicate: Replicate and/or Decapsulate"> Decapsulate</name>

          <t>The "Endpoint with replication and/or decapsulate behavior decapsulate"
          (End.Replicate for short) is a variant of End behavior. The
          pseudo-code
          pseudocode in this section follows the convention introduced in
          <xref target="RFC8986">RFC 8986</xref>.</t>

          <t>A Replication state format="default" target="RFC8986"/>.</t>

          <t>An RS conceptually contains the following
          elements:</t>

          <figure>
            <artwork><![CDATA[

		            <sourcecode name="" type="pseudocode"><![CDATA[
Replication state:
{
  Node-Role: {Head, Transit, Leaf, Bud};
  IPv6 Hop Limit Threshold; # default is zero
  # On Leaf, replication list is zero length
  Replication-List:
  {
    Downstream
    downstream node: <Node-Identifier>;
    Downstream Replication SID:
    downstream Replication-SID: R-SID;
    # Segment-List may be empty
    Segment-List: [SID-1, .... SID-N];
  }
}

]]></artwork>
          </figure>
]]></sourcecode>

          <t>Below is the Replicate function on a packet for Replication state
          (RS).</t>

          <figure>
            <artwork><![CDATA[S01.

          <sourcecode name="" type="pseudocode"><![CDATA[
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, 8986, Sections 5.1 and 5.2
S10.       }
S11.       Submit the packet to the egress IPv6 FIB lookup and
           transmission to the new destination
S12.   }
S13. }

]]></artwork>
          </figure>

          <t>Notes:<vspace blankLines="0"/></t>

          <t><list style="symbols">
              <t>The
]]></sourcecode>

          <t>Notes:</t>

          <ul spacing="normal">
            <li>The IPv6 destination address DA in the copy of a packet is set
            from the local state and not from SRH</t>
            </list></t> the SRH.</li>
          </ul>

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

          <figure>
            <artwork><![CDATA[S01.

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

          <t>The processing of the Upper-Layer header of a packet matching the
          End.Replicate SID at Leaf/Bud a leaf or bud node is as follows:</t>

          <figure>
            <artwork><![CDATA[S01.

          <sourcecode name="" type="pseudocode"><![CDATA[
S01.   If (Upper-Layer header type == 4(IPv4) OR
           Upper-Layer header type == 41(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 message with Code 4
S12.     # (SR Upper-layer Header Upper-Layer header Error)
S13.     # is not permitted (ICMPv6 section below) (Section 2.2.3)
S14.   }                  ]]></artwork>
          </figure>

          <t>Notes:<vspace blankLines="0"/></t>

          <t><list style="symbols">
              <t>The
]]></sourcecode>
          <t>Notes:</t>

          <ul spacing="normal">
            <li>The behavior above MAY <bcp14>MAY</bcp14> result in a packet with
            a partially processed segment list in the SRH under some
            circumstances. Fox
              example For example, a head node may encode a context SID context-SID
            in an SRH. As per
              pseudo-code the pseudocode above, a Replication replication node that
            receives a packet with a local Replication SID Replication-SID will not process
            the SRH segment list and will just forward a copy with an
            unmodified SRH to Downstream
              nodes.</t>

              <t>The downstream nodes.</li>

            <li>The packet processing context usually is usually a FIB table T</t>
            </list></t>

          <t>Processing the Replication SID may modify, if "T".</li>
          </ul>

          <t>If configured to process TLVs, processing the Replication-SID may
          modify 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.</t>

          <section title="Hashed numbered="true" toc="default">
            <name>Hashed Message Authentication Code (HMAC) SRH TLV"> TLV</name>

            <t>If a Root root node encodes a context SID context-SID in an SRH with an optional
            HMAC SRH TLV <xref format="default" target="RFC8754"/>, it MUST
            <bcp14>MUST</bcp14> set the 'D' bit as defined in Section 2.1.2 <xref
            section="2.1.2" sectionFormat="of" target="RFC8754"/> because the Replication SID
            Replication-SID is not part of the segment list in the SRH.</t>

            <t>HMAC generation and verification is as specified in RFC 8754. <xref
            format="default" target="RFC8754"/>. Verification of an HMAC TLV
            is determined by local configuration. If verification fails, an
            implementation of Replication SID MUST NOT a Replication-SID <bcp14>MUST NOT</bcp14>
            originate an ICMPv6 error Parameter Problem message (parameter problem, with code 0). 0. The
            failure SHOULD <bcp14>SHOULD</bcp14> be logged (rate limited) (rate-limited) and the
            packet SHOULD <bcp14>SHOULD</bcp14> be discarded.</t>
          </section>
        </section>

        <section title="OAM Operations">
          <t>RFC 9259 <xref numbered="true" toc="default">
          <name>OAM Operations</name>

          <t><xref format="default" target="RFC9259"/> specifies procedures
          for OAM
          operations Operations, Administration, and Maintenance (OAM) like ping and
          traceroute on SRv6 SIDs.</t>

          <t>It

          <t>Assuming the source node knows the Replication-SID a priori, it
          is possible to ping a Replication SID Replication-SID of a Leaf/Bud node,
          assuming the source leaf or bud node knows the Replication SID a priori, directly by
          putting it in the IPv6 destination address DA without a an SRH or in a an
          SRH as the last segment. While it is not possible to ping a
          Replication SID
          Replication-SID of a transit node because transit nodes do not
          process upper layer Upper-Layer headers, it is still possible to ping a
          Replication SID
          Replication-SID of Leaf/Bud a leaf or bud node of a tree via the Replication SID Replication-SID
          of intermediate transit nodes. The source of the ping MUST
          <bcp14>MUST</bcp14> compute the ICMPv6 Echo Request checksum using
          the Replication SID Replication-SID of Leaf/Bud the leaf or bud node as destination address. the DA. The
          source can then send the Echo Request packet to a transit node's Replication SID.
          Replication-SID. The transit nodes
          replicate node replicates the packet by replacing
          the IPv6 destination address till DA until the packet reaches the Leaf/Bud node leaf or bud
          node, which responds with an ICMPv6 Echo Reply. Note that a transit Replication
          replication node may replicate Echo Request packets to other Leaf/Bud
          leaf or bud nodes. These nodes will drop the Echo Request due to an
          incorrect checksum. Procedures to prevent the
          mis-delivery misdelivery of an Echo
          Request may be addressed in a future document.
          Appendix A.2.1 <xref
          format="default" target="A.2.1"/> illustrates examples of a ping to
          a Replication
          SID.</t> Replication-SID.</t>

          <t>Traceroute to a Leaf/Bud leaf or bud node Replication SID Replication-SID is not possible due
          to restriction restrictions prohibiting the origination of the ICMPv6 Time
          Exceeded error message for a Replication SID Replication-SID as described in the section below.</t> <xref
          format="default" target="ICMP"/>.</t>
        </section>

        <section anchor="ICMP" title="ICMPv6 numbered="true" toc="default">
          <name>ICMPv6 Error Messages">
          <t>ICMPv6 RFC <xref Messages</name>

          <t><xref section="2.4" sectionFormat="of" target="RFC4443"/> Section 2.4 states
          an ICMPv6 error message MUST NOT <bcp14>MUST NOT</bcp14> be originated as a
          result of receiving a packet destined to an IPv6 multicast address.
          This is to prevent a source node from being overwhelmed by a storm of ICMPv6 error messages resulting from
          replicated IPv6
          packets from overwhelming a source node. packets. There are
          two exceptions
          (1) the exceptions:</t>

          <ol>
            <li>The Packet Too Big message for Path MTU discovery, and (2) and</li>

            <li>The ICMPv6 Parameter Problem Message, message with Code 2 reporting an
            unrecognized IPv6
          option. An option.</li>
          </ol>

          <t>An implementation of a Replication segment for SRv6 MUST
          <bcp14>MUST</bcp14> enforce these same restrictions and
          exceptions.</t>
        </section>
      </section>
    </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 inter-operable elements of Replication
      segments.</t>

      <section title="Cisco implementation">
        <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"> numbered="true" toc="default">
      <name>IANA Considerations</name>

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

      <texttable anchor="endpoint_cp_types"
                 title="IETF - SRv6

      <table align="center" anchor="endpoint_cp_types">
        <name>SRv6 Endpoint Behaviors">
        <ttcol align="left">Value</ttcol>

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

        <ttcol Behavior</name>

        <thead>
          <tr>
            <th align="left">Value</th>

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

            <th 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> Behavior</th>

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

            <th align="center">Change Controller</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td align="left">75</td>

            <td align="center">0x004B</td>

            <td align="center">End.Replicate</td>

            <td align="center">RFC 9524</td>

            <td align="center">IETF</td>
          </tr>
        </tbody>
      </table>
    </section>

    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>The SID behaviors defined in this document are deployed within an SR
      domain <xref format="default" target="RFC8402"/>. An SR domain needs
      protection from outside attackers as (as described in <xref target="RFC8754"/> and
      format="default" target="RFC8754"/>). The following is a brief reminder
      of the same:</t>

      <t><list style="symbols">

      <ul spacing="normal">
        <li>
          <t>For SR-MPLS deployments:<list style="symbols">
              <t>By disabling deployments:</t>

          <ul spacing="normal">
            <li>Disable MPLS on external interfaces of each edge node or any
            other technique to filter labeled traffic ingress on these
              interfaces.</t>
            </list></t>
            interfaces.</li>
          </ul>
        </li>

        <li>
          <t>For SRv6 deployments:<list style="symbols">
              <t>Allocate deployments:</t>

          <ul spacing="normal">
            <li>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 Infrastructure Access Control List (IACL) that drops any
            incoming packet with a destination address DA in S/s.</t> S/s.</li>

            <li>
              <t>Additionally, an iACL IACL may be applied to all nodes (k)
              provisioning SIDs as defined in this specification:<list
                  style="symbols">
                  <t>Assign specification:</t>

              <ul spacing="normal">
                <li>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 DA in Sk/sk if the source
                address is not in A/a.</t>
                </list></t>

              <t>Denying A/a.</li>
              </ul>
            </li>

            <li>Deny traffic with spoofed source addresses by implementing
            recommendations in BCP 84 <xref target="RFC3704"/>.</t>

              <t>Additionally format="default"
            target="RFC3704"/>.</li>

            <li>Additionally, the block S/s from which SIDs are allocated may
            be a non-globally-routable an address that is not globally routable such as ULA a Unique Local
            Address (ULA) or the prefix defined in <xref target="I-D.ietf-6man-sids"/>.</t>
            </list></t>
        </list>Failure format="default"
            target="I-D.ietf-6man-sids"/>.</li>
          </ul>
        </li>
      </ul>

      <t>Failure to protect the SR MPLS 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.</t>

      <t>Failure to protect the SRv6 domain with IACLs on external interfaces, interfaces
      combined with failure to implement the recommendations of BCP 38 <xref target="RFC2827"/>or
      format="default" target="RFC2827"/> or apply IACLs on nodes provisioning SIDs,
      SIDs permits attackers from outside the SR domain to send packets that
      use the replication services provisioned within the domain.</t>

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

      <t>This document introduces a an SR segment endpoint behavior that
      replicates and decapsulates an inner payload for both the MPLS and IPv6
      data planes. Similar to any MPLS end of stack end-of-stack label, or SRv6 END.D*
      behavior, if the protections described above are not implemented implemented, an
      attacker can perform an attack via the decapsulating segment (including
      the one described in this document).</t>

      <t>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 until MPLS TTL (for
      SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero. A control
      plane, for example PCE,
      plane such as PCE can be used to prevent loops. The control plane
      protocols (like PCEP, Path Computation Element Communication Protocol (PCEP),
      BGP, etc.) used to instantiate Replication segments can leverage their
      own security mechanisms such as encryption, authentication filtering filtering,
      etc.</t>

      <t>For SRv6, <xref format="default" target="ICMP"/> describes an
      exception for the ICMPv6 Parameter Problem Message, code 2 ICMPv6 Error messages. message with Code 2. If an attacker sends a packet destined to Replication SID a Replication-SID
      with the source address of a node and with an extension header using the
      unknown option type marked as mandatory, then a large number of ICMPv6
      Parameter Problem messages can cause a denial-of-service attack on the
      source node. Although this specification document does not specify any extension
      headers, any future extension of this document doing that does so is
      susceptible to this security concern.</t>

      <t>If an attacker can forge an IPv6 packet with with:</t>

		<ul spacing="normal">
			<li>the source address of a
      node, Replication SID node,</li>
			<li>a Replication-SID as destination address and an the DA, and</li>
			<li>an IPv6 Hop Limit such that nodes which that forward replicated packets on an IPv6 locator
      unicast prefix, decrement the Hop Limit to zero, then zero,</li>
		</ul>

	  <t>then these nodes can
      cause a storm of ICMPv6 Error error packets to overwhelm the source node under
      attack. The IPv6 Hop Limit Threshold check described in <xref
      format="default" target="SRv6"/> can help mitigate such attacks.</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, Ketan Talaulikar, Darren Dukes and Jingrong Xie
      for their valuable inputs.</t>
    </section>

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

  <back>
    <displayreference target="I-D.ietf-pim-sr-p2mp-policy" to="P2MP-POLICY"/>

    <displayreference target="I-D.filsfils-spring-srv6-net-pgm-illustration"
                      to="PGM-ILLUSTRATION"/>

    <displayreference target="I-D.ietf-6man-sids" to="SIDS-SRv6"/>

    <references>
      <name>References</name>

      <references>
        <name>Normative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
		    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9259.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>
      </references>

      <references>
        <name>Informative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7988.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <reference anchor="I-D.ietf-pim-sr-p2mp-policy">
          <front>
            <title>Segment Routing Point-to-Multipoint Policy</title>
            <author fullname="Daniel Voyer" initials="D." role="editor"
                    surname="Voyer">
              <organization>Bell Canada</organization>
            </author>
            <author fullname="Clarence Filsfils" initials="C."
                    surname="Filsfils">
              <organization>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 Inc.</organization>
            </author>
            <author fullname="Rishabh Parekh" initials="R." surname="Parekh">
              <organization>Cisco Systems, Inc. <vspace
      blankLines="0"/> US</t>

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

      <t>Swadesh Agrawal <vspace blankLines="0"/> Cisco Inc.</organization>
            </author>
            <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli">
              <organization>Nokia</organization>
            </author>
            <author fullname="Zhaohui (Jeffrey) Zhang" initials="Z. J."
                    surname="Zhang">
              <organization>Juniper Networks</organization>
            </author>
            <date day="11" month="October" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pim-sr-p2mp-policy-07"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9350.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <reference anchor="I-D.filsfils-spring-srv6-net-pgm-illustration">
          <front>
            <title>Illustrations for SRv6 Network Programming</title>
            <author fullname="Clarence Filsfils" initials="C."
                    surname="Filsfils">
              <organization>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 Inc.</organization>
            </author>
            <author fullname="Pablo Camarillo" initials="P." role="editor"
                    surname="Camarillo">
              <organization>Cisco Systems, Inc. <vspace
      blankLines="0"/> Canada</t>

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

      <t>Jingrong Xie <vspace blankLines="0"/> Huawei Technologies <vspace
      blankLines="0"/> Beijing <vspace blankLines="0"/> China</t>

      <t>Email:xiejingrong@huawei.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.4443'?>

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

      <?rfc include='reference.RFC.8754'?> Inc.</organization>
            </author>
            <author fullname="Zhenbin Li" initials="Z." surname="Li">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Satoru Matsushima" initials="S."
                    surname="Matsushima">
              <organization>SoftBank</organization>
            </author>
            <author fullname="Bruno Decraene" initials="B." surname="Decraene">
              <organization>Orange</organization>
            </author>
            <author fullname="Dirk Steinberg" initials="D."
                    surname="Steinberg">
              <organization>Lapishills Consulting Limited</organization>
            </author>
            <author fullname="David Lebrun" initials="D." surname="Lebrun">
              <organization>Google</organization>
            </author>
            <author fullname="Robert Raszuk" initials="R." surname="Raszuk">
              <organization>Bloomberg LP</organization>
            </author>
            <author fullname="John Leddy" initials="J." surname="Leddy">
              <organization>Individual Contributor</organization>
            </author>
            <date day="30" month="March" year="2021"/>
          </front>
          <seriesInfo name="Internet-Draft"
                      value="draft-filsfils-spring-srv6-net-pgm-illustration-04"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3704.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-6man-sids.xml"
                    xmlns:xi="http://www.w3.org/2001/XInclude"/>
      </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.RFC.8660"?>

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

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

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

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

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

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

      <?rfc include="reference.I-D.ietf-6man-sids"?>
    </references>

    <section title="Illustration anchor="Appendix" numbered="true" toc="default">
      <name>Illustration of a Replication Segment"> Segment</name>

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

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

      <figure title="Topology

      <figure>
        <name>Topology for illustration Illustration of a Replication Segment">
        <artwork><![CDATA[ Segment</name>

        <artwork align="left" alt="" name="" type=""><![CDATA[
                               R3------R6
                              /         \
                      R1----R2----R5-----R7
                              \         /
                               +--R4---+
]]></artwork>
      </figure>

      <section title="SR-MPLS"> numbered="true" toc="default">
        <name>SR-MPLS</name>

        <t>In this example, the Node-SID of a node Rn is N-SIDn and
        Adjacency-SID the
        Adj-SID from node Rm to node Rn is A-SIDmn. Interface The interface
        between Rm and Rn is Lmn. The state representation uses
        "R-SID-&gt;Lmn" to represent a packet replication with outgoing replication SID
        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 R6, and R7. The Replication SID 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 segments at nodes R1, R2, R6 R6, and R7 is are shown
        below. Note nodes R3, R4 R4, and R5 do not have state for the a Replication
        segment.</t>

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

        <figure>
          <artwork><![CDATA[Replication

        <sourcecode name="" type="pseudocode">Replication segment <R-ID,R1>:
 Replication SID:
        &lt;R-ID,R1&gt;: Replication-SID: R-SID1 Replication state: R2: <R-SID2->L12>
        &lt;R-SID2-&gt;L12&gt; R6: <N-SID6, R-SID6> &lt;N-SID6, R-SID6&gt; R7: <N-SID4, &lt;N-SID4,
        A-SID47, R-SID7>
]]></artwork>
        </figure> R-SID7&gt;</sourcecode>

        <t>Replication to R2 steers the packet directly to R2 on interface
        L12. Replication to R6, using N-SID6, steers the packet via the
        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

        <sourcecode name="" type="pseudocode">Replication segment <R-ID,R2>:
 Replication SID:
        &lt;R-ID,R2&gt;: Replication-SID: R-SID2 Replication state: R2: <Leaf>]]></artwork>
        </figure>
        &lt;Leaf&gt;</sourcecode>

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

        <figure>
          <artwork><![CDATA[Replication

        <sourcecode name="" type="pseudocode">Replication segment <R-ID,R6>:
 Replication SID:
        &lt;R-ID,R6&gt;: Replication-SID: R-SID6 Replication state: R6: <Leaf>]]></artwork>
        </figure>
        &lt;Leaf&gt;</sourcecode>

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

        <figure>
          <artwork><![CDATA[Replication

        <sourcecode name="" type="pseudocode">Replication segment <R-ID,R7>:
 Replication SID:
        &lt;R-ID,R7&gt;: Replication-SID: R-SID7 Replication state: R7: <Leaf>]]></artwork>
        </figure>
        &lt;Leaf&gt;</sourcecode>

        <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

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

            <t>R1 payload.</li>

          <li>R1 performs the PUSH operation with the &lt;N-SID6, R-SID6&gt;
          label stack for the replicated copy to R6 and sends it to R2, which
          is the nexthop on the shortest path to R6. R2 performs the 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 operation. The packet is then sent to R6 with
          &lt;R-SID6&gt; in the label stack. R6, as Leaf, leaf, performs the NEXT
          operation, pops the R-SID6 label label, and delivers the payload.</t>

            <t>R1 payload.</li>

          <li>R1 performs the PUSH operation with the &lt;N-SID4, A-SID47,
          R-SID7&gt; label stack for the replicated copy to R7 and sends it to
          R2, which is the nexthop on the 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 operation. The packet is then sent to
          R4 with &lt;A-SID47, R-SID1&gt; in the label stack. R4 performs the
          NEXT operation, pops A-SID47, and delivers the packet to R7 with
          &lt;R-SID7&gt; in the label stack. R7, as Leaf, leaf, performs the NEXT
          operation, pops the R-SID7 label label, and delivers the payload.</t>
          </list></t> payload.</li>
        </ul>
      </section>

      <section title="SRv6"> numbered="true" toc="default">
        <name>SRv6</name>

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

        <t><list style="symbols">
            <t>2001:db8::/32 format="default"
        target="I-D.filsfils-spring-srv6-net-pgm-illustration"/>:</t>

        <ul spacing="normal">
          <li>2001:db8::/32 is an IPv6 block allocated by a Regional Internet
          Registry (RIR) to the operator</t>

            <t>2001:db8:0::/48 operator.</li>

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

            <t>2001:db8:cccc::/48 space.</li>

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

            <t>We
          space.</li>

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

            <t>Node bits.</li>

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

            <t>Node (IGP).</li>

          <li>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 block.</li>

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

            <t>Function IGP.</li>

          <li>Function :1:: (function 1, for short) represents the End
          function with the Penultimate Segment Pop (PSP) of the SRH (PSP) <xref
          format="default" target="RFC8986"/> and USD support</t>

            <t>Function support.</li>

          <li>Function :Cn:: (function Cn, for short) represents the End.X
          function from to Node n with PSP and USD support</t>
          </list></t> support.</li>
        </ul>

        <t>Each node k has: <list style="symbols">
            <t>An has:</t>

        <ul spacing="normal">
          <li>An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to
          an End function with additional support for PSP and USD</t>

            <t>An USD.</li>

          <li>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</t>

            <t>An
          USD.</li>

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

        <t>Assume a Replication segment identified with R-ID at Replication
        node R1 and downstream nodes R2, R6 R6, and R7. The Replication SID 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 segments at nodes R1, R2, R6 R6, and R7 is are shown
        below. Note nodes R3, R4 R4, and R5 do not have state for the a Replication
        segment. The state representation uses "R-SID-&gt;Lmn" to represent a
        packet replication with outgoing replication SID Replication-SID R-SID sent on
        interface Lmn. "SL" represents and an optional segment list used to steer
        a replicated packet on a specific path to a Downstream downstream node.</t>

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

        <figure>
          <artwork><![CDATA[Replication

        <sourcecode name="" type="pseudocode">Replication segment <R-ID,R1>:
 Replication SID:
        &lt;R-ID,R1&gt;: Replication-SID: 2001:db8:cccc:1:F1::0 Replication
        state: R2: <2001:db8:cccc:2:F2::0->L12> &lt;2001:db8:cccc:2:F2::0-&gt;L12&gt; R6: <2001:db8:cccc:6:F6::0>
        &lt;2001:db8:cccc:6:F6::0&gt; R7: <2001:db8:cccc:4:C7::0>, &lt;2001:db8:cccc:4:C7::0&gt;, SL: <2001:db8:cccc:7:F7::0>
]]></artwork>
        </figure>
        &lt;2001:db8:cccc:7:F7::0&gt;</sourcecode>

        <t>Replication to R2 steers the packet directly to R2 on interface
        L12. Replication to R6, using 2001:db8:cccc:6:F6::0, steers the packet
        via the 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.</t>

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

        <figure>
          <artwork><![CDATA[Replication

        <sourcecode name="" type="pseudocode">Replication segment <R-ID,R2>:
 Replication SID:
        &lt;R-ID,R2&gt;: Replication-SID: 2001:db8:cccc:2:F2::0 Replication
        state: R2: <Leaf>]]></artwork>
        </figure> &lt;Leaf&gt;</sourcecode>

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

        <figure>
          <artwork><![CDATA[Replication

        <sourcecode name="" type="pseudocode">Replication segment <R-ID,R6>:
 Replication SID:
        &lt;R-ID,R6&gt;: Replication-SID: 2001:db8:cccc:6:F6::0 Replication
        state: R6: <Leaf>]]></artwork>
        </figure> &lt;Leaf&gt;</sourcecode>

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

        <figure>
          <artwork><![CDATA[Replication

        <sourcecode name="" type="pseudocode">Replication segment <R-ID,R7>:
 Replication SID:
        &lt;R-ID,R7&gt;: Replication-SID: 2001:db8:cccc:7:F7::0 Replication
        state: R7: <Leaf>]]></artwork>
        </figure> &lt;Leaf&gt;</sourcecode>

        <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

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

            <t>R1 payload.</li>

          <li>R1 creates an 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, leaf, removes the outer
          IPv6 header and delivers the payload.</t> payload.</li>

          <li>
            <t>R1 has to steer the packet to Downstream downstream node R7 via node R4.
            It can do this in one of two ways:<list style="symbols">
                <t>R1 ways:</t>

            <ul spacing="normal">
              <li>R1 creates an 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 the (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, which is the nexthop on the shortest path to
              2001:db8:cccc:4::/64. R2 forwards the packet to R4 using
              2001:db8:cccc:4::/64. R4 executes the End.X function on
              2001:db8:cccc:4:C7::0, performs a USD action, removes the outer
              IPv6
                encapsulation encapsulation, and sends the resulting packet (2001:db8::1,
              2001:db8:cccc:7:F7::0) (A, B2) to R7. R7, as Leaf, leaf, removes the
              outer IPv6 header and delivers the payload.</t>

                <t>R1 payload.</li>

              <li>R1 is Root the root of replication the Replication segment. Therefore, it can
              combine above encapsulations to create an 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, which
              is the nexthop on the shortest path to 2001:db8:cccc:4::/64. R2
              forwards the packet to R4 using 2001:db8:cccc:4::/64. R4
              executes the End.X function on 2001:db8:cccc:4:C7::0, performs a
              PSP action, removes SRH the SRH, and sends the resulting packet
              (2001:db8::1, 2001:db8:cccc:7:F7::0) (A, B2) to R7. R7, as Leaf, leaf,
              removes the outer IPv6 header and delivers the payload.</t>
              </list></t>
          </list></t> payload.</li>
            </ul>
          </li>
        </ul>

        <section title="Pinging Replication SID"> anchor="A.2.1" numbered="true" toc="default">
          <name>Pinging a Replication-SID</name>

          <t>This section illustrates the ping of a Replication SID.</t> Replication-SID.</t>

          <t>Node R1 pings replication SID the Replication-SID of node R6 directly by sending
          the following packet:</t>

          <t><list style="numbers">
              <t>R1

          <ol spacing="normal" type="1">
            <li>R1 to R6: (2001:db8::1, 2001:db8:cccc:6:F6::0; NH=ICMPv6)
            (ICMPv6 Echo Request)</t>

              <t>Node Request).</li>

            <li>Node R6 as a Leaf leaf processes upper layer the upper-layer ICMPv6 Echo
            Request and responds with an ICMPv6 Echo Reply</t>
            </list></t> Reply.</li>
          </ol>

          <t>Node R1 pings Replication SID the Replication-SID of R7 via R4 by sending the
          following packet with the SRH:</t>

          <t><list style="numbers">
              <t>R1

          <ol spacing="normal" type="1">
            <li>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)</t>

              <t>R4
            Request).</li>

            <li>R4 to R7: (2001:db8::1, 2001:db8:cccc:7:F7::0; NH=ICMPv6)
            (ICMPv6 Echo Request)</t>

              <t>Node Request).</li>

            <li>Node R7 as a Leaf leaf processes upper layer the upper-layer ICMPv6 Echo
            Request and responds with an ICMPv6 Echo Reply</t>
            </list></t> Reply.</li>
          </ol>

          <t>Assume node R4 is a transit Replication replication node with Replication SID Replication-SID
          2001:db8:cccc:4:F4::0 replicating to R7. Node R1 pings Replication
          SID the
          Replication-SID of R7 via Replication SID the Replication-SID of R4 as follows:</t>

          <t><list style="numbers">
              <t>R1

          <ol spacing="normal" type="1">
            <li>R1 to R4: (2001:db8::1, 2001:db8:cccc:4:F4::0; NH=ICMPv6)
            (ICMPv6 Echo Request)</t>

              <t>R4 Request).</li>

            <li>R4 replicates to R7 by replacing the IPv6 destination address DA
            with Replication SID the Replication-SID of R7 from its Replication state</t>

              <t>R4 state.</li>

            <li>R4 to R7: (2001:db8::1, 2001:db8:cccc:7:F7::0; NH=ICMPv6)
            (ICMPv6 Echo Request)</t>

              <t>Node Request).</li>

            <li>Node R7 as a Leaf leaf processes upper layer the upper-layer ICMPv6 Echo
            Request and responds with an ICMPv6 Echo Reply</t>
            </list></t> Reply.</li>
          </ol>
        </section>
      </section>
    </section>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>

      <t>The authors would like to acknowledge <contact
      fullname="Siva       Sivabalan"/>, <contact fullname="Mike Koldychev"/>,
      <contact fullname="Vishnu Pavan Beeram"/>, <contact
      fullname="Alexander       Vainshtein"/>, <contact
      fullname="Bruno Decraene"/>, <contact fullname="Thierry Couture"/>,
      <contact fullname="Joel Halpern"/>, <contact
      fullname="Ketan Talaulikar"/>, <contact fullname="Darren       Dukes"/>
      and <contact fullname="Jingrong Xie"/> for their valuable inputs.</t>
    </section>

    <section numbered="false" toc="default">
      <name>Contributors</name>

      <contact fullname="Clayton Hassen">
        <organization>Bell Canada</organization>

        <address>
          <postal>
            <city>Vancouver</city>

            <country>Canada</country>
          </postal>

          <email>clayton.hassen@bell.ca</email>
        </address>
      </contact>

      <contact fullname="Kurtis Gillis">
        <organization>Bell Canada</organization>

        <address>
          <postal>
            <city>Halifax</city>

            <country>Canada</country>
          </postal>

          <email>kurtis.gillis@bell.ca</email>
        </address>
      </contact>

      <contact fullname="Arvind Venkateswaran">
        <organization>Cisco Systems, Inc.</organization>

        <address>
          <postal>
            <city>San Jose</city>

            <region>CA</region>

            <country>United States of America</country>
          </postal>

          <email>arvvenka@cisco.com</email>
        </address>
      </contact>

      <contact fullname="Zafar Ali">
        <organization>Cisco Systems, Inc.</organization>

        <address>
          <postal>
            <country>United States of America</country>
          </postal>

          <email>zali@cisco.com</email>
        </address>
      </contact>

      <contact fullname="Swadesh Agrawal">
        <organization>Cisco Systems, Inc.</organization>

        <address>
          <postal>
            <city>San Jose</city>

            <region>CA</region>

            <country>United States of America</country>
          </postal>

          <email>swaagraw@cisco.com</email>
        </address>
      </contact>

      <contact fullname="Jayant Kotalwar">
        <organization>Nokia</organization>

        <address>
          <postal>
            <city>Mountain View</city>

            <region>CA</region>

            <country>United States of America</country>
          </postal>

          <email>jayant.kotalwar@nokia.com</email>
        </address>
      </contact>

      <contact fullname="Tanmoy Kundu">
        <organization>Nokia</organization>

        <address>
          <postal>
            <city>Mountain View</city>

            <region>CA</region>

            <country>United States of America</country>
          </postal>

          <email>tanmoy.kundu@nokia.com</email>
        </address>
      </contact>

      <contact fullname="Andrew Stone">
        <organization>Nokia</organization>

        <address>
          <postal>
            <city>Ottawa</city>

            <country>Canada</country>
          </postal>

          <email>andrew.stone@nokia.com</email>
        </address>
      </contact>

      <contact fullname="Tarek Saad">
        <organization>Cisco Systems, Inc.</organization>

        <address>
          <postal>
            <country>Canada</country>
          </postal>

          <email>tsaad@cisco.com</email>
        </address>
      </contact>

      <contact fullname="Kamran Raza">
        <organization>Cisco Systems, Inc.</organization>

        <address>
          <postal>
            <country>Canada</country>
          </postal>

          <email>skraza@cisco.com</email>
        </address>
      </contact>

      <contact fullname="Jingrong Xie">
        <organization>Huawei Technologies</organization>

        <address>
          <postal>
            <city>Beijing</city>

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

          <email>xiejingrong@huawei.com</email>
        </address>
      </contact>
    </section>
  </back>
</rfc>