rfc9524xml2.original.xml   rfc9524.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc category="std" consensus="true"
<?rfc compact="yes"?> docName="draft-ietf-spring-sr-replication-segment-19" ipr="trust200902"
<?rfc subcompact="no"?> number="9524" obsoletes="" sortRefs="true" submissionType="IETF"
<rfc category="std" docName="draft-ietf-spring-sr-replication-segment-19" symRefs="true" tocDepth="3" tocInclude="true" updates="" version="3"
ipr="trust200902"> xml:lang="en">
<front> <front>
<title abbrev="SR Replication Segment">SR Replication segment for
Multi-point Service Delivery</title>
<author fullname="Daniel Voyer (editor)" initials="D." <title abbrev="SR Replication Segment">Segment Routing Replication
surname="Voyer, Ed."> for Multipoint Service Delivery</title>
<organization>Bell Canada</organization>
<seriesInfo name="RFC" value="9524"/>
<author fullname="Daniel Voyer" initials="D." role="editor"
surname="Voyer">
<organization>Bell Canada</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Montreal</city> <city>Montreal</city>
<country>Canada</country>
<region/>
<code/>
<country>CA</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>daniel.voyer@bell.ca</email> <email>daniel.voyer@bell.ca</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Brussels</city> <city>Brussels</city>
<country>Belgium</country>
<region/>
<code/>
<country>BE</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Rishabh Parekh" initials="R." surname="Parekh"> <author fullname="Rishabh Parekh" initials="R." surname="Parekh">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region>
<region/> <country>United States of America</country>
<code/>
<country>US</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>riparekh@cisco.com</email> <email>riparekh@cisco.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli"> <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Ottawa</city> <city>Ottawa</city>
<country>Canada</country>
<region/>
<code/>
<country>CA</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>hooman.bidgoli@nokia.com</email> <email>hooman.bidgoli@nokia.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Zhaohui Zhang" initials="Z." surname="Zhang"> <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>zzhang@juniper.net</email> <email>zzhang@juniper.net</email>
</address> </address>
</author> </author>
<date day="28" month="August" year="2023"/> <date month="February" year="2024"/>
<area>rtg</area>
<workgroup>spring</workgroup>
<abstract> <abstract>
<t>This document describes the Segment Routing Replication segment for <t>This document describes the Segment Routing Replication segment for
Multi-point service delivery. A Replication segment allows a packet to multipoint service delivery. A Replication segment allows a packet to be
be replicated from a Replication node to Downstream nodes.</t> replicated from a replication node to downstream nodes.</t>
</abstract> </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> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>Replication segment is a new type of segment for Segment Routing (SR) <name>Introduction</name>
<xref target="RFC8402"/>, which allows a node (henceforth called a
Replication node) to replicate packets to a set of other nodes (called <t>The Replication segment is a new type of segment for Segment Routing
Downstream nodes) in a Segment Routing Domain. A Replication segment can (SR) <xref format="default" target="RFC8402"/>, which allows a node
replicate packets to directly connected nodes or to downstream nodes (henceforth called a "replication node") to replicate packets to a set
(without need for state on the transit routers). This document focuses of other nodes (called "downstream nodes") in an SR domain.
on specifying behavior of a Replication segment for both Segment Routing A Replication segment can replicate packets to directly connected nodes
with Multiprotocol Label Switching (SR-MPLS) <xref target="RFC8660"/> or to downstream nodes (without the need for state on the transit
and Segment Routing with IPv6 (SRv6) <xref target="RFC8986"/>. The routers). This document focuses on specifying the behavior of a
examples in the Appendix illustrate the behavior of a Replication Replication segment for both Segment Routing with Multiprotocol Label
Segment in SR domain. The use of two or more Replication segments Switching (SR-MPLS) <xref format="default" target="RFC8660"/> and
stitched together to form a tree using a control plane is left to be Segment Routing with IPv6 (SRv6) <xref format="default"
specified in other documents. The management of IP multicast groups, target="RFC8986"/>. The examples in <xref format="default"
building IP multicast trees, and performing multicast congestion control target="Appendix"/> illustrate the behavior of a Replication Segment in
are out of scope of this document.</t> 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 numbered="true" toc="default">
<name>Terminology</name>
<section title="Terminology">
<t>This section defines terms introduced and used frequently in this <t>This section defines terms introduced and used frequently in this
document. Refer to Terminology sections of <xref target="RFC8402"/>, document. Refer to the Terminology sections of <xref format="default"
<xref target="RFC8754"/> and <xref target="RFC8986"/> for other terms target="RFC8402"/>, <xref format="default" target="RFC8754"/>, and
used in Segment Routing.</t> <xref format="default" target="RFC8986"/> for other terms used in
SR.</t>
<t><list style="symbols"> <dl newline="false" spacing="normal">
<t>Replication segment: A segment in SR domain that replicates <dt>Replication segment:</dt>
packets. See <xref target="RepSeg"/> for details.</t>
<t>Replication node: A node in SR domain which replicates packets <dd>A segment in an SR domain that replicates packets. See <xref
based on Replication segment.</t> format="default" target="RepSeg"/> for details.</dd>
<t>Downstream nodes: A Replication segment replicates packets to a <dt>Replication node:</dt>
set of nodes. These nodes are Downstream nodes.</t>
<t>Replication state: State held for a Replication segment at a <dd>A node in an SR domain that replicates packets based on a
Replication node. It is conceptually a list of replication Replication segment.</dd>
branches to Downstream nodes. The list can be empty.</t>
<t>Replication SID: Data plane identifier of a Replication <dt>Downstream nodes:</dt>
segment. This is a SR-MPLS label or SRv6 Segment Identifier
(SID).</t>
<t>SRH: IPv6 Segment Routing Header <xref target="RFC8754"/>.</t> <dd>A Replication segment replicates packets to a set of nodes.
These nodes are downstream nodes.</dd>
<t>Point-to-Multipoint Service: A service that has one ingress <dt>Replication state:</dt>
node and one or more egress nodes. A packet is delivered to all
the egress nodes</t>
<t>Root node: An ingress node of a P2MP service,</t> <dd>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.</dd>
<t>Leaf node: An egress node of a P2MP service.</t> <dt>Replication-SID:</dt>
<t>Bud node: A node that is both a Replication node and a Leaf <dd>Data plane identifier of a Replication segment. This is an
node.</t> SR-MPLS label or SRv6 Segment Identifier (SID).</dd>
</list></t>
<dt>SRH:</dt>
<dd>IPv6 Segment Routing Header <xref 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.</dd>
<dt>Root node:</dt>
<dd>An ingress node of a P2MP service.</dd>
<dt>Leaf node:</dt>
<dd>An egress node of a P2MP service.</dd>
<dt>Bud node:</dt>
<dd>A node that is both a replication node and a 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>
<section title="Use Cases"> <section numbered="true" toc="default">
<name>Use Cases</name>
<t>In the simplest use case, a single Replication segment includes the <t>In the simplest use case, a single Replication segment includes the
ingress node of a multi-point service and the egress nodes of the ingress node of a multipoint service and the egress nodes of the
service as all the Downstream nodes. This achieves Ingress Replication service as all the downstream nodes. This achieves Ingress Replication
<xref target="RFC7988"/> that has been widely used for Multicast VPN <xref format="default" target="RFC7988"/> that has been widely used
(MVPN) <xref target="RFC6513"/> and Ethernet VPN (EVPN)<xref for Multicast VPN (MVPN) <xref format="default" target="RFC6513"/> and
target="RFC7432"/> bridging of Broadcast, Unknown Unicast, and Ethernet VPN (EVPN) <xref format="default" target="RFC7432"/> bridging
Multicast (BUM) traffic. This Replication segment can be either of Broadcast, Unknown Unicast, and Multicast (BUM) traffic. This Replic
provisioned locally on ingress and egress nodes, or using dynamic ation segment on ingress and
auto-discovery procedures for MVPN and EVPN. Note <xref egress nodes can either be provisioned locally or using dynamic autodisc
target="RFC8986">SRv6</xref> has End.DT2M replication behavior for overy procedures for MVPN and
EVPN BUM traffic.</t> 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 <t>Replication segments can also be used to form trees by stitching
Replication segments on a Root node, intermediate Replication nodes Replication segments on a root node, intermediate replication nodes,
and Leaf nodes for efficient delivery of MVPN and EVPN BUM and leaf nodes for efficient delivery of MVPN and EVPN BUM
traffic.</t> traffic.</t>
</section> </section>
</section> </section>
<section anchor="RepSeg" title="Replication Segment"> <section anchor="RepSeg" numbered="true" toc="default">
<t>In a Segment Routing Domain, a Replication segment is a logical <name>Replication Segment</name>
construct which connects a Replication node to a set of Downstream
nodes. A Replication segment is a local segment instantiated at a <t>In an SR domain, a Replication segment is a logical
Replication node. It can be either provisioned locally on a node or construct that connects a replication node to a set of downstream nodes.
programmed by a control plane.</t> 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 co
ntrol plane.
</t>
<t>Replication segments can be stitched together to form a tree by <t>Replication segments can be stitched together to form a tree by
either local provisioning on nodes or using a control plane. The either local provisioning on nodes or using a control plane. The
procedures for doing this are out of scope of this document. One such procedures for doing this are out of scope of this document. One such
control plane using a PCE with SR P2MP policy is specified in <xref control plane using a PCE with the SR P2MP policy is specified in <xref
target="I-D.ietf-pim-sr-p2mp-policy"/>. However, if local provisioning format="default" target="I-D.ietf-pim-sr-p2mp-policy"/>. However, if
is used to stitch Replication segments, then a chain of Replication local provisioning is used to stitch Replication segments, then a chain
segments SHOULD NOT form a loop. If a control plane is used to stitch of Replication segments <bcp14>SHOULD NOT</bcp14> form a loop. If a
Replication segments, the control plane specification MUST prevent control plane is used to stitch Replication segments, the control plane
loops, or to detect and mitigate loops in steady state.</t> specification <bcp14>MUST</bcp14> prevent loops or detect and mitigate
loops in steady state.</t>
<t>A Replication segment is identified by the tuple &lt;Replication-ID, <t>A Replication segment is identified by the tuple &lt;Replication-ID,
Node-ID&gt;, where:</t> Node-ID&gt;, where:</t>
<t><list style="symbols"> <dl newline="false" spacing="normal">
<t>Replication-ID: An identifier for a Replication segment that is <dt>Replication-ID:</dt>
unique in context of the Replication node.</t>
<t>Node-ID: The address of the Replication node that the Replication <dd>An identifier for a Replication segment that is unique in context
segment is for. Note that the Root of a multi-point service is also of the replication node.</dd>
a Replication node.</t>
</list></t>
<t>Replication-ID is a variable length field. In simplest case, it can <dt>Node-ID:</dt>
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 <dd>The address of the replication node for the Replication segment.
document. The length of Replication-ID is specified in the signaling Note that the root of a multipoint service is also a Replication
mechanism used for Replication segment. Examples of such signaling and node.</dd>
extensions are described in <xref </dl>
<t>Replication-ID is a 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 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; Replication segment to its node, the &lt;Replication-ID, Node-ID&gt;
tuple identifies the segment.</t> tuple identifies the segment.</t>
<t>A Replication segment includes the following elements: <list <t>A Replication segment includes the following elements:</t>
style="symbols">
<t>Replication SID: The Segment Identifier of a Replication segment.
This is a SR-MPLS label or a SRv6 SID <xref target="RFC8402"/>.</t>
<t>Downstream nodes: Set of nodes in Segment Routing domain to which <dl newline="false" spacing="normal">
a packet is replicated by the Replication segment.</t> <dt>Replication-SID:</dt>
<t>Replication state: See below.</t> <dd>The Segment Identifier of a Replication segment. This is an
</list></t> SR-MPLS label or an SRv6 SID <xref format="default"
target="RFC8402"/>.</dd>
<t>The Downstream nodes and Replication state of a Replication segment <dt>Downstream nodes:</dt>
can change over time, depending on the network state and Leaf nodes of a
multi-point service that the segment is part of.</t>
<t>Replication SID identifies the Replication segment in the forwarding <dd>Set of nodes in an SR domain to which a packet is
plane. At a Replication node, the Replication SID operates on replicated by the Replication segment.</dd>
Replication state of the Replication segment.</t>
<t>Replication state is a list of replication branches to the Downstream <dt>Replication state:</dt>
nodes. In this document, each branch is abstracted to a &lt;Downstream
node, Downstream Replication SID&gt; tuple. &lt;Downstream node&gt;
represents the reachability from the Replication node to the Downstream
node. In its simplest form, this MAY be specified as an interface or
next-hop if downstream node is adjacent to the Replication node. The
reachability may be specified in terms of Flexible Algorithm path
(including the default algorithm) <xref target="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 <xref target="RFC9256"/>.
Downstream Replication SID is the Replication SID of the Replication
segment at the Downstream node.</t>
<t>A packet is steered into a Replication segment at a Replication node <dd>See below.</dd>
</dl>
<t>The downstream nodes and Replication state (RS) of a Replication segmen
t
can change over time, depending on the network state and leaf nodes of a
multipoint service that the segment is part of.</t>
<t>The Replication-SID identifies the Replication segment in the
forwarding plane. At a replication node, the Replication-SID operates on
the RS of the Replication segment.</t>
<t>RS is a list of Replication branches to the downstream
nodes. In this document, each branch is abstracted to a &lt;downstream
node, downstream Replication-SID&gt; tuple. &lt;downstream node&gt;
represents the reachability from the replication node to the downstream
node. In its simplest form, this <bcp14>MAY</bcp14> be specified as an
interface or next-hop if the downstream node is adjacent to the
replication node. The reachability may be specified in terms of a
Flexible Algorithm path (including the default algorithm) <xref
format="default" target="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 <xref format="default" target="RFC9256"/>. The downstream
Replication-SID is the Replication-SID of the Replication segment at the
downstream node.</t>
<t>A packet is steered into a Replication segment at a replication node
in two ways:</t> in two ways:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>When the Active Segment <xref target="RFC8402"/> is a locally <li>When the active segment <xref format="default" target="RFC8402"/>
instantiated Replication SID</t> is a locally instantiated Replication-SID.</li>
<t>By the Root of a multi-point service based on local configuration <li>By the root of a multipoint service based on local configuration
outside the scope of this document.</t> that is outside the scope of this document.</li>
</list></t> </ul>
<t>In either case, the packet is replicated to each Downstream node in <t>In either case, the packet is replicated to each downstream node in
the associated Replication state.</t> the associated RS.</t>
<t>If a Downstream node is an egress (Leaf) of the multi-point service, <t>If a downstream node is an egress (leaf) of the multipoint service,
no further replication is needed. The Leaf node's Replication segment no further replication is needed. The leaf node's Replication segment
has an indicator for Leaf role and it does not have any Replication has an indicator for the leaf role, and it does not have any RS (i.e., the
state i.e. the list of Replication branches is empty. The Replication list of Replication branches is empty). The Replication-SID at a leaf node <bcp
SID at a Leaf node MAY be used to identify the multi-point service. 14>MAY</bcp14> be used to identify the multipoint
Notice that the segment on the Leaf node is still referred to as a service. Notice that the segment on the leaf node is still referred to
Replication segment for the purpose of generalization.</t> as a "Replication segment" for the purpose of generalization.</t>
<t>A node can be a Bud node, i.e. it is a Replication node and a Leaf <t>A node can be a bud node (i.e., it is a replication node and a leaf
node of a multi-point service <xref node of a multipoint service <xref format="default"
target="I-D.ietf-pim-sr-p2mp-policy"/>. Replication segment of a Bud target="I-D.ietf-pim-sr-p2mp-policy"/>). The Replication segment of a
node has a list of Replication Branches as well as Leaf role bud node has a list of Replication branches as well as a leaf role
indicator.</t> indicator.</t>
<t>In principle it is possible for different Replication segments to <t>In principle, it is possible for different Replication segments to
replicate packets to the same Replication segment on a Downstream node. replicate packets to the same Replication segment on a downstream node.
However, such usage is intentionally left out of scope of this However, such usage is intentionally left out of scope of this
document.</t> document.</t>
<section title="SR-MPLS data plane"> <section numbered="true" toc="default">
<t>When the Active Segment is a Replication SID, the processing <name>SR-MPLS Data Plane</name>
results in a POP <xref target="RFC8402"/> operation and lookup of the
associated Replication state. For each replication in the Replication
state, the operation is a PUSH <xref target="RFC8402"/> of the
downstream Replication SID and an optional segment list on to the
packet to steer the packet to the Downstream node.</t>
<t>The operation performed on incoming Replication SID is NEXT <xref <t>When the active segment is a Replication-SID, the processing
target="RFC8402"/> at Leaf/Bud nodes where delivery of payload off results in a POP <xref format="default" target="RFC8402"/> operation
tree is per local configuration. For some usages, this may involve and the lookup of the associated RS. For each
looking at the next SID for example to get the necessary context.</t> replication in the RS, the operation is a PUSH <xref
format="default" target="RFC8402"/> of the downstream Replication-SID
and an optional segment list onto the packet to steer the packet to
the downstream node.</t>
<t>When the Root of a multi-point service steers a packet to a <t>The operation performed on the incoming Replication-SID is NEXT
Replication segment, it results in a replication to each Downstream <xref format="default" target="RFC8402"/> at a leaf or bud node where
node in the associated replication state. The operation is a PUSH of delivery of payload off the tree is per local configuration. For some
the replication SID and an optional segment list on to the packet usages, this may involve looking at the next SID, for example, to get
the necessary context.</t>
<t>When the root of a multipoint service steers a packet to a
Replication segment, it results in a replication to each downstream
node in the associated RS. The operation is a PUSH of
the Replication-SID and an optional segment list onto the packet,
which is forwarded to the downstream node.</t> which is forwarded to the downstream node.</t>
<t>The following applies to Replication SID in MPLS encapsulation:</t> <t>The following applies to a Replication-SID in MPLS
encapsulation:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>SIDs MAY be inserted before the downstream SR-MPLS Replication <li>SIDs <bcp14>MAY</bcp14> be inserted before the downstream
SID in order to guide a packet from a non-adjacent SR node to a SR-MPLS Replication-SID in order to guide a packet from a
Replication node.</t> non-adjacent SR node to a replication node.</li>
<t>A Replication node MAY replicate a packet to a non-adjacent <li>A replication node <bcp14>MAY</bcp14> replicate a packet to a
Downstream node using SIDs it inserts in the copy preceding the non-adjacent downstream node using SIDs it inserts in the copy
downstream Replication SID. The Downstream node may be a Leaf node preceding the downstream Replication-SID. The downstream node may be
of the Replication segment, or another Replication node, or both a leaf node of the Replication segment, another replication node, or
in case of Bud node.</t> both in the case of a bud node.</li>
<t>A Replication node MAY use an Anycast SID or Border Gateway <li>A replication node <bcp14>MAY</bcp14> use an Anycast-SID or a
Protocol (BGP) PeerSet SID in segment list to send a replicated Border Gateway Protocol (BGP) PeerSet-SID in the segment list to
packet to one downstream Replication node in an Anycast set if and send a replicated packet to one downstream replication node in a set o
only if all nodes in the set have an identical Replication SID and f
reach the same set of receivers.</t> Anycast nodes. This occurs if and only if all nodes in the set have an
identical Replication-SID and reach the same set of receivers.</li>
<t>For some use cases, there MAY be SIDs after the Replication SID <li>For some use cases, there <bcp14>MAY</bcp14> be SIDs after the
in the segment list of a packet. These SIDs are used only by the Replication-SID in the segment list of a packet. These SIDs are used
Leaf/Bud nodes to forward a packet off the tree independent of the only by the leaf and bud nodes to forward a packet off the tree
Replication SID. Coordination regarding the absence or presence independent of the Replication-SID. Coordination regarding the
and value of context information for Leaf/Bud nodes is outside the absence or presence and value of context information for leaf and bud
scope of this document.</t> nodes is outside the scope of this document.</li>
</list></t> </ul>
</section> </section>
<section anchor="SRv6" title="SRv6 data plane"> <section anchor="SRv6" numbered="true" toc="default">
<t>For SRv6 <xref target="RFC8986"/>, this document specifies <name>SRv6 Data Plane</name>
&ldquo;Endpoint with replication&rdquo; behavior (End.Replicate for
short) to replicate a packet and forward the replicas according to a
Replication state.</t>
<t>When processing a packet destined to a local Replication SID, the <t>For SRv6 <xref format="default" target="RFC8986"/>, this document
packet is replicated according to the associated Replication state to specifies "Endpoint with replication and/or decapsulate" behavior (End.R
Downstream nodes and/or locally delivered off tree when this is a eplicate for
Leaf/Bud node.For replication, the outer header is re-used, and the short) to replicate a packet and forward the replicas according to an
Downstream Replication SID, from Replication state, is written into RS.</t>
the outer IPv6 header destination address. If required, an optional
segment list may be used on some branches using H.Encaps.Red <xref
target="RFC8986"/> (while some other branches may not need that). Note
that this H.Encaps.Red is independent of the replication segment
&ndash; 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 <xref target="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. This also
applies when the Replication segment is for the Root node, whose
upstream node has placed the Replication-SID in the header.</t>
<t>A local application on Root, for e.g. MVPN <xref target="RFC6513"/> <t>When processing a packet destined to a local Replication-SID, the
or EVPN <xref target="RFC7432"/>, may also apply H.Encaps.Red and then packet is replicated according to the associated RS to
steer the resulting traffic into the Replication segment. Again, note downstream nodes and/or locally delivered off the tree when this is a
that the H.Encaps.Red is independent of the Replication segment leaf or bud node. For replication, the outer header is reused, and the
&ndash; it is the action of the application (e.g. MVPN/EVPN service). downstream Replication-SID, from RS, is written into
If the service is on a Root node, the two H.Encaps mentioned, one for the outer IPv6 header Destination Address (DA). If required, an
the service and other in the previous paragraph for replication to optional segment list may be used on some branches using H.Encaps.Red
Downstream node SHOULD be combined for optimization (to avoid extra <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: it is just used to steer the replicated packet on
a traffic-engineered path to a 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 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. This also applies when the
Replication segment is for the root node, whose upstream node has
placed the Replication-SID in the header.</t>
<t>A local application on root (e.g., MVPN <xref format="default"
target="RFC6513"/> or EVPN <xref format="default" target="RFC7432"/>)
may also apply H.Encaps.Red and then steer the resulting traffic into
the Replication segment. Again, note that H.Encaps.Red is independent
of the Replication segment: it is the action of the application (e.g.
MVPN or EVPN service). If the service is on a root node, then the two
H.Encaps mentioned, one for the service and the other in the previous
paragraph for replication to the downstream node,
<bcp14>SHOULD</bcp14> be combined for optimization (to avoid extra
IPv6 encapsulation).</t> IPv6 encapsulation).</t>
<t>When processing a packet destined to a local Replication SID, IPv6 <t>When processing a packet destined to a local Replication-SID, the
Hop Limit MUST be decremented and MUST be non-zero to replicate the IPv6 Hop Limit <bcp14>MUST</bcp14> be decremented and
packet. A Root node that encapsulates a payload can set the IPv6 Hop <bcp14>MUST</bcp14> be non-zero to replicate the packet. A root node
Limit based on a local policy. This local policy SHOULD set the IPv6 that encapsulates a payload can set the IPv6 Hop Limit based on a
Hop Limit so that a replicated packet can reach the furthest Leaf local policy. This local policy <bcp14>SHOULD</bcp14> set the IPv6 Hop
node. A Root node can also have a local policy to set the IPv6 Hop Limit so that a replicated packet can reach the furthest leaf node. A
Limit from the payload. In this case, IPv6 Hop Limit may not be root node can also have a local policy to set the IPv6 Hop Limit from
sufficient to get the replicated packet to all the Leaf nodes; the payload. In this case, the IPv6 Hop Limit may not be sufficient to
non-replication nodes i.e. nodes which forward replicated packets get the replicated packet to all the leaf nodes. Non-replication nodes
based on IPv6 locator unicast prefix can decrement IPv6 Hop Limit to (i.e., nodes that forward replicated packets based on the IPv6 locator
zero and originate ICMPv6 Error packets to the Root node. This can unicast prefix) can decrement the IPv6 Hop Limit to zero and originate
result in a storm of ICMPv6 packets (see <xref target="ICMP"/>) to the ICMPv6 error packets to the root node. This can result in a storm of
Root node. To avoid this, a Replication Segment has an optional IPv6 ICMPv6 packets (see <xref format="default" target="ICMP"/>) to the
Hop Limit threshold. If this threshold is set, a Replication node MUST root node. To avoid this, a Replication segment has an optional IPv6
discard an incoming packet with local Replication SID if the IPv6 Hop Hop Limit Threshold. If this threshold is set, a replication node
Limit in the packet is less than the threshold and log this in a rate <bcp14>MUST</bcp14> discard an incoming packet with a local
limited manner. The IPv6 Hop Limit Threshold SHOULD be set so that Replication-SID if the IPv6 Hop Limit in the packet is less than the
incoming packet can be replicated to furthest Leaf node.</t> threshold and log this in a rate-limited manner. The IPv6 Hop Limit
Threshold <bcp14>SHOULD</bcp14> be set so that an incoming packet can
be replicated to the furthest leaf node.</t>
<t>For Leaf/Bud nodes local delivery off the tree is per Replication <t>For leaf and bud nodes, local delivery off the tree is per Replicatio
SID or next SID (if present in SRH). For some usages, this may involve n-SID or the next SID (if present in the SRH). For some usages, this may
getting the necessary context either from the next SID (e.g., MVPN involve getting the necessary context either from the next SID (e.g.,
with shared tree) or from the replication SID itself (e.g., MVPN with MVPN with a shared tree) or from the Replication-SID itself (e.g.,
non-shared tree). In both cases, the context association is achieved MVPN with a non-shared tree). In both cases, the context association
with signaling and is out of scope of this document.</t> is achieved with signaling and is out of scope of this document.</t>
<t>The following applies to Replication SID in SRv6 encapsulation:</t> <t>The following applies to a Replication-SID in SRv6
encapsulation:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>There MAY be SIDs preceding the SRv6 Replication SID in order <li>There <bcp14>MAY</bcp14> be SIDs preceding the SRv6 Replication-SI
to guide a packet from a non-adjacent SR node to a Replication D in order to guide a packet from a non-adjacent SR node to a
node via an explicit path.</t> replication node via an explicit path.</li>
<t>A Replication node MAY steer a replicated packet on an explicit <li>A replication node <bcp14>MAY</bcp14> steer a replicated packet
path to a non-adjacent Downstream node using SIDs it inserts in on an explicit path to a non-adjacent downstream node using SIDs it
the copy preceding the downstream Replication SID. The Downstream inserts in the copy preceding the downstream Replication-SID. The
node may be a Leaf node of the Replication segment, or another downstream node may be a leaf node of the Replication segment,
Replication node, or both in case of Bud node.</t> another replication node, or both in the case of a bud node.</li>
<t>For SRv6, as described in above paragraphs, the insertion of <li>For SRv6, as described in above paragraphs, the insertion of
SIDs prior to Replication SID entails a new IPv6 encapsulation SIDs prior to the Replication-SID entails a new IPv6 encapsulation
with SRH, but this can be optimized on Root node or for compressed with the SRH. However, this can be optimized on the root node or for
SRv6 SIDs.</t> compressed SRv6 SIDs.</li>
<t>The locator of Replication SID is sufficient to guide a packet <li>The locator of the Replication-SID is sufficient to guide a
on shortest path, for default or Flexible algorithm, between packet on the shortest path between non-adjacent nodes for default
non-adjacent nodes.</t> or Flexible Algorithms.</li>
<t>A Replication node MAY use an Anycast SID or BGP PeerSet SID in <li>A replication node <bcp14>MAY</bcp14> use an Anycast-SID or a
segment list to send a replicated packet to one downstream BGP PeerSet-SID in the segment list to send a replicated packet to
Replication node in an Anycast set if and only if all nodes in the one downstream replication node in an Anycast set. This occurs if
set have an identical Replication SID and reach the same set of and only if all nodes in the set have an identical Replication-SID
receivers.</t> and reach the same set of receivers.</li>
<t>There MAY be SIDs after the Replication SID in the SRH of a <li>There <bcp14>MAY</bcp14> be SIDs after the Replication-SID in
packet. These SIDs are used to provide additional context for the SRH of a packet. These SIDs are used to provide additional
processing a packet locally at the node where the Replication SID context for processing a packet locally at the node where the
is the Active Segment. Coordination regarding the absence or Replication-SID is the active segment. Coordination regarding the
presence and value of context information for Leaf/Bud nodes is absence or presence and value of context information for leaf and bud
outside the scope of this document.</t> nodes is outside the scope of this document.</li>
</list></t> </ul>
<section title="End.Replicate: Replicate and/or Decapsulate"> <section numbered="true" toc="default">
<t>The "Endpoint with replication and/or decapsulate behavior <name>End.Replicate: Replicate and/or Decapsulate</name>
(End.Replicate for short) is variant of End behavior. The
pseudo-code in this section follows the convention introduced in
<xref target="RFC8986">RFC 8986</xref>.</t>
<t>A Replication state conceptually contains the following <t>The "Endpoint with replication and/or decapsulate"
(End.Replicate for short) is a variant of End behavior. The
pseudocode in this section follows the convention introduced in
<xref format="default" target="RFC8986"/>.</t>
<t>An RS conceptually contains the following
elements:</t> elements:</t>
<figure> <sourcecode name="" type="pseudocode"><![CDATA[
<artwork><![CDATA[
Replication state: Replication state:
{ {
Node-Role: {Head, Transit, Leaf, Bud}; Node-Role: {Head, Transit, Leaf, Bud};
IPv6 Hop Limit Threshold; # default is zero IPv6 Hop Limit Threshold; # default is zero
# On Leaf, replication list is zero length # On Leaf, replication list is zero length
Replication-List: Replication-List:
{ {
Downstream node: <Node-Identifier>; downstream node: <Node-Identifier>;
Downstream Replication SID: R-SID; downstream Replication-SID: R-SID;
# Segment-List may be empty # Segment-List may be empty
Segment-List: [SID-1, .... SID-N]; Segment-List: [SID-1, .... SID-N];
} }
} }
]]></sourcecode>
]]></artwork>
</figure>
<t>Below is the Replicate function on a packet for Replication state <t>Below is the Replicate function on a packet for Replication state
(RS).</t> (RS).</t>
<figure> <sourcecode name="" type="pseudocode"><![CDATA[
<artwork><![CDATA[S01. Replicate(RS, packet) S01. Replicate(RS, packet)
S02. { S02. {
S03. For each Replication R in RS.Replication-List { S03. For each Replication R in RS.Replication-List {
S04. Make a copy of the packet S04. Make a copy of the packet
S05. Set IPv6 DA = RS.R-SID S05. Set IPv6 DA = RS.R-SID
S06. If RS.Segment-List is not empty { S06. If RS.Segment-List is not empty {
S07. # Head node may optimize below encapsulation and S07. # Head node may optimize below encapsulation and
S08. # the encapsulation of packet in a single encapsulation S08. # the encapsulation of packet in a single encapsulation
S09. Execute H.Encaps or H.Encaps.Red with RS.Segment-List S09. Execute H.Encaps or H.Encaps.Red with RS.Segment-List
on packet copy #RFC 8986 Section 5.1, 5.2 on packet copy #RFC 8986, Sections 5.1 and 5.2
S10. } S10. }
S11. Submit the packet to the egress IPv6 FIB lookup and S11. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination transmission to the new destination
S12. } S12. }
S13. } S13. }
]]></sourcecode>
]]></artwork> <t>Notes:</t>
</figure>
<t>Notes:<vspace blankLines="0"/></t>
<t><list style="symbols"> <ul spacing="normal">
<t>The IPv6 destination address in the copy of a packet is set <li>The IPv6 DA in the copy of a packet is set
from local state and not from SRH</t> from the local state and not from the SRH.</li>
</list></t> </ul>
<t>When N receives a packet whose IPv6 DA is S and S is a local <t>When N receives a packet whose IPv6 DA is S and S is a local
End.Replicate SID, N does:</t> End.Replicate SID, N does:</t>
<figure> <sourcecode name="" type="pseudocode"><![CDATA[
<artwork><![CDATA[S01. Lookup FUNCT portion of S to get Replicatio S01. Lookup FUNCT portion of S to get Replication state (RS)
n state RS
S02. If (IPv6 Hop Limit <= 1) { S02. If (IPv6 Hop Limit <= 1) {
S03. Discard the packet S03. Discard the packet
S04. # ICMPv6 Time Exceeded is not permitted (ICMPv6 section below) S04. # ICMPv6 Time Exceeded is not permitted
(see Section 2.2.3)
S05. } S05. }
S06. If RS is not found { S06. If RS is not found {
S07. Discard the packet S07. Discard the packet
S08. } S08. }
S09. If (IPv6 Hop Limit < RS.IPv6 Hop Limit Threshold) { S09. If (IPv6 Hop Limit < RS.IPv6 Hop Limit Threshold) {
S10. Discard the packet S10. Discard the packet
S11. # Rate-limited logging S11. # Rate-limited logging
S12. } S12. }
S13. Decrement IPv6 Hop Limit by 1 S13. Decrement IPv6 Hop Limit by 1
S14. If (IPv6 NH == SRH and SRH TLVs present) { S14. If (IPv6 NH == SRH and SRH TLVs present) {
S15. Process SRH TLVs if allowed by local configuration S15. Process SRH TLVs if allowed by local configuration
S16. } S16. }
S17. Call Replicate(RS, packet) S17. Call Replicate(RS, packet)
S18. If (RS.Node-Role == Leaf OR RS.Node-Role == Bud) { S18. If (RS.Node-Role == Leaf OR RS.Node-Role == bud) {
S19. If (IPv6 NH == SRH and Segments Left > 0) { S19. If (IPv6 NH == SRH and Segments Left > 0) {
S20. Derive packet processing context(PPC) from Segment List S20. Derive packet processing context (PPC) from Segment List
S21. If (Segments Left != 0) { S21. If (Segments Left != 0) {
S22. Discard the packet S22. Discard the packet
S23. # ICMPv6 Parameter Problem with Code 0 S23. # ICMPv6 Parameter Problem message with Code 0
S24. # (Erroneous header field encountered) S24. # (Erroneous header field encountered)
S25. # is not permitted (ICMPv6 section below) S25. # is not permitted (Section 2.2.3)
S26. } S26. }
S27. } Else { S27. } Else {
S28. Derive packet processing context(PPC) S28. Derive packet processing context (PPC)
from FUNCT of Replication SID from FUNCT of Replicatio-SID
S29. } S29. }
S30. Process the next header S30. Process the next header
S31. }]]></artwork> S31. }
</figure> ]]></sourcecode>
<t>The processing of Upper-Layer header of a packet matching <t>The processing of the Upper-Layer header of a packet matching the
End.Replicate SID at Leaf/Bud node is as follows:</t> End.Replicate SID at a leaf or bud node is as follows:</t>
<figure> <sourcecode name="" type="pseudocode"><![CDATA[
<artwork><![CDATA[S01. If (Upper-Layer header type == 4(IPv4) OR S01. If (Upper-Layer header type == 4(IPv4) OR
Upper-Layer header type == 41(IPv6) ) { Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers S02. Remove the outer IPv6 header with all its extension headers
S03. Process the packet in context of PPC S03. Process the packet in context of PPC
S04. } Else If (Upper-Layer header type == 143(Ethernet) ) { S04. } Else If (Upper-Layer header type == 143(Ethernet) ) {
S05. Remove the outer IPv6 header with all its extension headers S05. Remove the outer IPv6 header with all its extension headers
S06. Process the Ethernet Frame in context of PPC S06. Process the Ethernet Frame in context of PPC
S07. } Else If (Upper-Layer header type is allowed S07. } Else If (Upper-Layer header type is allowed
by local configuration) { by local configuration) {
S08. Proceed to process the Upper-Layer header S08. Proceed to process the Upper-Layer header
S09. } Else { S09. } Else {
S10. Discard the packet S10. Discard the packet
S11. # ICMPv6 Parameter Problem with Code 4 S11. # ICMPv6 Parameter Problem message with Code 4
S12. # (SR Upper-layer Header Error) S12. # (SR Upper-Layer header Error)
S13. # is not permitted (ICMPv6 section below) S13. # is not permitted (Section 2.2.3)
S14. } ]]></artwork> S14. }
</figure> ]]></sourcecode>
<t>Notes:</t>
<t>Notes:<vspace blankLines="0"/></t> <ul spacing="normal">
<li>The behavior above <bcp14>MAY</bcp14> result in a packet with
a partially processed segment list in the SRH under some
circumstances. For example, a head node may encode a context-SID
in an SRH. As per the pseudocode above, a replication node that
receives a packet with a local Replication-SID will not process
the SRH segment list and will just forward a copy with an
unmodified SRH to downstream nodes.</li>
<t><list style="symbols"> <li>The packet processing context is usually a FIB table "T".</li>
<t>The behavior above MAY result in a packet with partially </ul>
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.</t>
<t>The packet processing context usually is a FIB table T</t> <t>If configured to process TLVs, processing the Replication-SID may
</list></t> 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>
<t>Processing the Replication SID may modify, if configured to <section numbered="true" toc="default">
process TLVs, the "variable-length data" of TLV types that change en <name>Hashed Message Authentication Code (HMAC) SRH TLV</name>
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 Message Authentication Code (HMAC) SRH TLV"> <t>If a root node encodes a context-SID in an SRH with an optional
<t>If a Root node encodes a context SID in SRH with an optional HMAC SRH TLV <xref format="default" target="RFC8754"/>, it
HMAC SRH TLV <xref target="RFC8754"/>, it MUST set the 'D' bit as <bcp14>MUST</bcp14> set the 'D' bit as defined in <xref
defined in Section 2.1.2 because the Replication SID is not part section="2.1.2" sectionFormat="of" target="RFC8754"/> because the
of the segment list in SRH.</t> Replication-SID is not part of the segment list in the SRH.</t>
<t>HMAC generation and verification is as specified in RFC 8754. <t>HMAC generation and verification is as specified in <xref
Verification of HMAC TLV is determined by local configuration. If format="default" target="RFC8754"/>. Verification of an HMAC TLV
verification fails, an implementation of Replication SID MUST NOT is determined by local configuration. If verification fails, an
originate an ICMPv6 error message (parameter problem, code 0). The implementation of a Replication-SID <bcp14>MUST NOT</bcp14>
failure SHOULD be logged (rate limited) and the packet SHOULD be originate an ICMPv6 Parameter Problem message with code 0. The
discarded.</t> failure <bcp14>SHOULD</bcp14> be logged (rate-limited) and the
packet <bcp14>SHOULD</bcp14> be discarded.</t>
</section> </section>
</section> </section>
<section title="OAM Operations"> <section numbered="true" toc="default">
<t>RFC 9259 <xref target="RFC9259"/> specifies procedures for OAM <name>OAM Operations</name>
operations like ping and traceroute on SRv6 SIDs.</t>
<t>It is possible to ping a Replication SID of a Leaf/Bud node, <t><xref format="default" target="RFC9259"/> specifies procedures
assuming the source node knows the Replication SID a priori, for Operations, Administration, and Maintenance (OAM) like ping and
directly by putting it in the IPv6 destination address without a SRH traceroute on SRv6 SIDs.</t>
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. Note that a transit Replication node may replicate Echo
Request packets to other Leaf/Bud nodes. These nodes will drop the
Echo Request due to incorrect checksum. Procedures to prevent the
mis-delivery of Echo Request may be addressed in a future document.
Appendix A.2.1 illustrates examples of ping to a Replication
SID.</t>
<t>Traceroute to a Leaf/Bud node Replication SID is not possible due <t>Assuming the source node knows the Replication-SID a priori, it
to restriction prohibiting origination of ICMPv6 Time Exceeded error is possible to ping a Replication-SID of a leaf or bud node directly b
message for a Replication SID as described in the section below.</t> y
</section> putting it in the IPv6 DA without an SRH or in an
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 a leaf or bud node of a tree via the Replication-SI
D
of intermediate transit nodes. The source of the ping
<bcp14>MUST</bcp14> compute the ICMPv6 Echo Request checksum using
the Replication-SID of the leaf or bud node as the DA. The
source can then send the Echo Request packet to a transit node's
Replication-SID. The transit node replicates the packet by replacing
the IPv6 DA until the packet reaches the leaf or bud
node, which responds with an ICMPv6 Echo Reply. Note that a transit
replication node may replicate Echo Request packets to other
leaf or bud nodes. These nodes will drop the Echo Request due to an
incorrect checksum. Procedures to prevent the misdelivery of an Echo
Request may be addressed in a future document. <xref
format="default" target="A.2.1"/> illustrates examples of a ping to
a Replication-SID.</t>
<section anchor="ICMP" title="ICMPv6 Error Messages"> <t>Traceroute to a leaf or bud node Replication-SID is not possible du
<t>ICMPv6 RFC <xref target="RFC4443"/> Section 2.4 states an ICMPv6 e
error message MUST NOT be originated as a result of receiving a to restrictions prohibiting the origination of the ICMPv6 Time
packet destined to an IPv6 multicast address. This is to prevent a Exceeded error message for a Replication-SID as described in <xref
storm of ICMPv6 error messages resulting from replicated IPv6 format="default" target="ICMP"/>.</t>
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.</t>
</section> </section>
</section>
</section>
<section title="Implementation Status"> <section anchor="ICMP" numbered="true" toc="default">
<t>Note to the RFC Editor: Please remove this section and reference to <name>ICMPv6 Error Messages</name>
RFC 7942 before publication.</t>
<t>This section records the status of known implementations of the <t><xref section="2.4" sectionFormat="of" target="RFC4443"/> states
protocol defined by this specification at the time of posting of this an ICMPv6 error message <bcp14>MUST NOT</bcp14> be originated as a
Internet-Draft, and is based on a proposal described in <xref result of receiving a packet destined to an IPv6 multicast address.
target="RFC7942">RFC 7942</xref>. The description of implementations in This is to prevent a source node from being overwhelmed by a storm of
this section is intended to assist the IETF in its decision processes in ICMPv6 error messages resulting from
progressing drafts to RFCs. Please note that the listing of any replicated IPv6 packets. There are
individual implementation here does not imply endorsement by the IETF. two exceptions:</t>
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. <ol>
Interoperability reports for the implementations are not applicable <li>The Packet Too Big message for Path MTU discovery, and</li>
since this draft does not specify inter-operable elements of Replication
segments.</t>
<section title="Cisco implementation"> <li>The ICMPv6 Parameter Problem message with Code 2 reporting an
<t>Cisco Implementation uses Replication segments defined in this unrecognized IPv6 option.</li>
draft as a basis for PCE to compute and establish P2MP trees in SR </ol>
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/a
sr9k-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>An implementation of a Replication segment for SRv6
<t>Nokia has implemented replication SID as defined in this draft to <bcp14>MUST</bcp14> enforce these same restrictions and
establish P2MP tree in segment routing domain. The implementation exceptions.</t>
supports SR-MPLS encapsulation and has all the MUST and SHOULD clause </section>
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> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has assigned the following codepoint for End.Replicate behavior <t>IANA has assigned the following codepoint for End.Replicate behavior
in the "SRv6 Endpoint Behaviors" registry in the "Segment Routing" in the "SRv6 Endpoint Behaviors" registry in the "Segment Routing"
registry group.</t> registry group.</t>
<texttable anchor="endpoint_cp_types" <table align="center" anchor="endpoint_cp_types">
title="IETF - SRv6 Endpoint Behaviors"> <name>SRv6 Endpoint Behavior</name>
<ttcol align="left">Value</ttcol>
<ttcol align="center">Hex</ttcol> <thead>
<tr>
<th align="left">Value</th>
<ttcol align="center">Endpoint behavior</ttcol> <th align="center">Hex</th>
<ttcol align="center">Reference</ttcol> <th align="center">Endpoint Behavior</th>
<c>75</c> <th align="center">Reference</th>
<c>0x004B</c> <th align="center">Change Controller</th>
</tr>
</thead>
<c>End.Replicate</c> <tbody>
<tr>
<td align="left">75</td>
<c>[This.ID]</c> <td align="center">0x004B</td>
</texttable>
<td align="center">End.Replicate</td>
<td align="center">RFC 9524</td>
<td align="center">IETF</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The SID behaviors defined in this document are deployed within an SR <t>The SID behaviors defined in this document are deployed within an SR
domain <xref target="RFC8402"/>. An SR domain needs protection from domain <xref format="default" target="RFC8402"/>. An SR domain needs
outside attackers as described in <xref target="RFC8754"/> and following protection from outside attackers (as described in <xref
is a brief reminder of the same:</t> format="default" target="RFC8754"/>). The following is a brief reminder
of the same:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>For SR-MPLS deployments:<list style="symbols"> <li>
<t>By disabling MPLS on external interfaces of each edge node or <t>For SR-MPLS deployments:</t>
any other technique to filter labeled traffic ingress on these
interfaces.</t>
</list></t>
<t>For SRv6 deployments:<list style="symbols"> <ul spacing="normal">
<t>Allocate all the SIDs from an IPv6 prefix block S/s and <li>Disable MPLS on external interfaces of each edge node or any
configure each external interface of each edge node of the other technique to filter labeled traffic ingress on these
domain with an inbound infrastructure access list (IACL) that interfaces.</li>
drops any incoming packet with a destination address in S/s.</t> </ul>
</li>
<t>Additionally, an iACL may be applied to all nodes (k) <li>
provisioning SIDs as defined in this specification:<list <t>For SRv6 deployments:</t>
style="symbols">
<t>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.</t>
</list></t>
<t>Denying traffic with spoofed source addresses by implementing <ul spacing="normal">
recommendations in BCP 84 <xref target="RFC3704"/>.</t> <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 Control List (IACL) that drops
any
incoming packet with a DA in S/s.</li>
<t>Additionally the block S/s from which SIDs are allocated may <li>
be a non-globally-routable address such as ULA or the prefix <t>Additionally, an IACL may be applied to all nodes (k)
defined in <xref target="I-D.ietf-6man-sids"/>.</t> provisioning SIDs as defined in this specification:</t>
</list></t>
</list>Failure to protect the SR MPLS domain by correctly provisioning <ul spacing="normal">
MPLS support per interface permits attackers from outside the domain to <li>Assign all interface addresses from within IPv6 prefix
send packets that use the replication services provisioned within the 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 DA in Sk/sk if the source
address is not in A/a.</li>
</ul>
</li>
<li>Deny traffic with spoofed source addresses by implementing
recommendations in BCP 84 <xref format="default"
target="RFC3704"/>.</li>
<li>Additionally, the block S/s from which SIDs are allocated may
be an address that is not globally routable such as a Unique Local
Address (ULA) or the prefix defined in <xref format="default"
target="I-D.ietf-6man-sids"/>.</li>
</ul>
</li>
</ul>
<t>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.</t> domain.</t>
<t>Failure to protect the SRv6 domain with IACLs on external interfaces, <t>Failure to protect the SRv6 domain with IACLs on external interfaces
combined with failure to implement BCP 38 <xref target="RFC2827"/>or combined with failure to implement the recommendations of BCP 38 <xref
apply IACLs on nodes provisioning SIDs, permits attackers from outside format="default" target="RFC2827"/> or apply IACLs on nodes provisioning
the SR domain to send packets that use the replication services SIDs permits attackers from outside the SR domain to send packets that
provisioned within the domain.</t> use the replication services provisioned within the domain.</t>
<t>Given the definition of the Replication segment in this document, an <t>Given the definition of the Replication segment in this document, an
attacker subverting ingress filter above cannot take advantage of a attacker subverting the ingress filters above cannot take advantage of a
stack of replication segments to perform amplification attacks nor link stack of Replication segments to perform amplification attacks nor link
exhaustion attacks. Replication segment trees always terminate at a Leaf exhaustion attacks. Replication segment trees always terminate at a leaf
or Bud node resulting in a decapsulation. This however does allow an or bud node resulting in a decapsulation. However, this does allow an
attacker to inject traffic to the receivers within a P2MP service.</t> attacker to inject traffic to the receivers within a P2MP service.</t>
<t>This document introduces a SR segment endpoint behavior that <t>This document introduces an SR segment endpoint behavior that
replicates and decapsulates an inner payload for both the MPLS and IPv6 replicates and decapsulates an inner payload for both the MPLS and IPv6
data planes. Similar to any MPLS end of stack label, or SRv6 END.D* data planes. Similar to any MPLS end-of-stack label, or SRv6 END.D*
behavior, if the protections described above are not implemented an behavior, if the protections described above are not implemented, an
attacker can perform an attack via the decapsulating segment (including attacker can perform an attack via the decapsulating segment (including
the one described in this document).</t> the one described in this document).</t>
<t>Incorrect provisioning of Replication segments can result in a chain <t>Incorrect provisioning of Replication segments can result in a chain
of Replication segments forming a loop. This can happen if Replication of Replication segments forming a loop. This can happen if Replication
segments are provisioned on SR nodes without using a control plane. In segments are provisioned on SR nodes without using a control plane. In
this case, replicated packets can create a storm till MPLS TTL (for this case, replicated packets can create a storm until MPLS TTL (for
SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero. A control SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero. A control
plane, for example PCE, can be used to prevent loops. The control plane plane such as PCE can be used to prevent loops. The control plane
protocols (like PCEP, BGP, etc.) used to instantiate Replication protocols (like Path Computation Element Communication Protocol (PCEP),
segments can leverage their own security mechanisms such as encryption, BGP, etc.) used to instantiate Replication segments can leverage their
authentication filtering etc.</t> own security mechanisms such as encryption, authentication filtering,
etc.</t>
<t>For SRv6, <xref target="ICMP"/> describes an exception for Parameter
Problem Message, code 2 ICMPv6 Error messages. If an attacker sends a
packet destined to Replication SID with source address of a node and
with an extension header using 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
does not specify any extension headers, any future extension of this
document doing so is susceptible to this security concern.</t>
<t>If an attacker can forge an IPv6 packet with source address of a
node, Replication SID as destination address and an IPv6 Hop Limit such
that nodes which forward replicated packets on IPv6 locator unicast
prefix, decrement the Hop Limit to zero, then these nodes can cause a
storm of ICMPv6 Error packets to overwhelm the source node under attack.
The IPv6 Hop Limit Threshold check described in <xref 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>For SRv6, <xref format="default" target="ICMP"/> describes an
exception for the ICMPv6 Parameter Problem message with Code 2. If an atta
cker sends a packet destined to 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 document does not specify any extension
headers, any future extension of this document that does so is
susceptible to this security concern.</t>
<t>Kurtis Gillis <vspace blankLines="0"/> Bell Canada <vspace <t>If an attacker can forge an IPv6 packet with:</t>
blankLines="0"/> Halifax <vspace blankLines="0"/> Canada</t>
<t>Email: kurtis.gillis@bell.ca</t> <ul spacing="normal">
<li>the source address of a node,</li>
<li>a Replication-SID as the DA, and</li>
<li>an IPv6 Hop Limit such that nodes that forward replic
ated packets on an IPv6 locator
unicast prefix, decrement the Hop Limit to zero,</li>
</ul>
<t>Arvind Venkateswaran <vspace blankLines="0"/> Cisco Systems, Inc. <t>then these nodes can
<vspace blankLines="0"/> San Jose <vspace blankLines="0"/> US</t> cause a storm of ICMPv6 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>
</middle>
<t>Email: arvvenka@cisco.com</t> <back>
<displayreference target="I-D.ietf-pim-sr-p2mp-policy" to="P2MP-POLICY"/>
<t>Zafar Ali <vspace blankLines="0"/> Cisco Systems, Inc. <vspace <displayreference target="I-D.filsfils-spring-srv6-net-pgm-illustration"
blankLines="0"/> US</t> to="PGM-ILLUSTRATION"/>
<t>Email: zali@cisco.com</t> <displayreference target="I-D.ietf-6man-sids" to="SIDS-SRv6"/>
<t>Swadesh Agrawal <vspace blankLines="0"/> Cisco Systems, Inc. <vspace <references>
blankLines="0"/> San Jose <vspace blankLines="0"/> US</t> <name>References</name>
<t>Email: swaagraw@cisco.com</t> <references>
<name>Normative References</name>
<t>Jayant Kotalwar <vspace blankLines="0"/> Nokia <vspace <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
blankLines="0"/> Mountain View <vspace blankLines="0"/> US</t> 119.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<t>Email: jayant.kotalwar@nokia.com</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<t>Tanmoy Kundu <vspace blankLines="0"/> Nokia <vspace blankLines="0"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
Mountain View <vspace blankLines="0"/> US</t> 402.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<t>Email: tanmoy.kundu@nokia.com</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<t>Andrew Stone <vspace blankLines="0"/> Nokia <vspace blankLines="0"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
Ottawa <vspace blankLines="0"/> Canada</t> 443.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<t>Email: andrew.stone@nokia.com</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
259.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<t>Tarek Saad <vspace blankLines="0"/> Cisco Systems Inc.<vspace <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
blankLines="0"/> Canada</t> 754.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
</references>
<t>Email:tsaad@cisco.com</t> <references>
<name>Informative References</name>
<t>Kamran Raza <vspace blankLines="0"/> Cisco Systems, Inc. <vspace <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
blankLines="0"/> Canada</t> 513.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<t>Email:skraza@cisco.com</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
432.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<t>Jingrong Xie <vspace blankLines="0"/> Huawei Technologies <vspace <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
blankLines="0"/> Beijing <vspace blankLines="0"/> China</t> 988.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<t>Email:xiejingrong@huawei.com</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</section> 660.xml"
</middle> xmlns:xi="http://www.w3.org/2001/XInclude"/>
<back> <reference anchor="I-D.ietf-pim-sr-p2mp-policy">
<references title="Normative References"> <front>
<?rfc include="reference.RFC.2119"?> <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.</organization>
</author>
<author fullname="Rishabh Parekh" initials="R." surname="Parekh">
<organization>Cisco Systems, 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>
<?rfc include="reference.RFC.8174"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
350.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<?rfc include="reference.RFC.8402"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<?rfc include="reference.RFC.8986"?> <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.</organization>
</author>
<author fullname="Pablo Camarillo" initials="P." role="editor"
surname="Camarillo">
<organization>Cisco Systems, 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>
<?rfc include='reference.RFC.4443'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
704.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<?rfc include='reference.RFC.9259'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
827.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<?rfc include='reference.RFC.8754'?> <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> </references>
<references title="Informative References"> <section anchor="Appendix" numbered="true" toc="default">
<?rfc include="reference.RFC.6513"?> <name>Illustration of a Replication Segment</name>
<?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 of a Replication Segment">
<t>This section illustrates an example of a single Replication segment. <t>This section illustrates an example of a single Replication segment.
Examples showing Replication segment stitched together to form P2MP tree Examples showing Replication segments stitched together to form a P2MP
(based on SR P2MP policy) are in <xref tree (based on SR P2MP policy) are in <xref format="default"
target="I-D.ietf-pim-sr-p2mp-policy"/>.</t> target="I-D.ietf-pim-sr-p2mp-policy"/>.</t>
<t>Consider the following topology:</t> <t>Consider the following topology:</t>
<figure title="Topology for illustration of Replication Segment"> <figure>
<artwork><![CDATA[ R3------R6 <name>Topology for Illustration of a Replication Segment</name>
<artwork align="left" alt="" name="" type=""><![CDATA[
R3------R6
/ \ / \
R1----R2----R5-----R7 R1----R2----R5-----R7
\ / \ /
+--R4---+ ]]></artwork> +--R4---+
]]></artwork>
</figure> </figure>
<section title="SR-MPLS"> <section numbered="true" toc="default">
<t>In this example, the Node-SID of a node Rn is N-SIDn and <name>SR-MPLS</name>
Adjacency-SID from node Rm to node Rn is A-SIDmn. Interface between Rm
and Rn is Lmn. The state representation uses "R-SID-&gt;Lmn" to <t>In this example, the Node-SID of a node Rn is N-SIDn and the
represent a packet replication with outgoing replication SID R-SID Adj-SID from node Rm to node Rn is A-SIDmn. The interface
sent on interface Lmn.</t> between Rm and Rn is Lmn. The state representation uses
"R-SID-&gt;Lmn" to represent a packet replication with outgoing
Replication-SID R-SID sent on interface Lmn.</t>
<t>Assume a Replication segment identified with R-ID at Replication <t>Assume a Replication segment identified with R-ID at Replication
node R1 and downstream nodes R2, R6 and R7. The Replication SID at node 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 node n is R-SIDn. A packet replicated from R1 to R7 has to traverse
R4.</t> R4.</t>
<t>The Replication segment state at nodes R1, R2, R6 and R7 is shown <t>The Replication segments at nodes R1, R2, R6, and R7 are shown
below. Note nodes R3, R4 and R5 do not have state for the Replication below. Note nodes R3, R4, and R5 do not have a Replication
segment.</t> segment.</t>
<t>Replication segment at R1:</t> <t>Replication segment at R1:</t>
<figure> <sourcecode name="" type="pseudocode">Replication segment
<artwork><![CDATA[Replication segment <R-ID,R1>: &lt;R-ID,R1&gt;: Replication-SID: R-SID1 Replication state: R2:
Replication SID: R-SID1 &lt;R-SID2-&gt;L12&gt; R6: &lt;N-SID6, R-SID6&gt; R7: &lt;N-SID4,
Replication state: A-SID47, R-SID7&gt;</sourcecode>
R2: <R-SID2->L12>
R6: <N-SID6, R-SID6>
R7: <N-SID4, A-SID47, R-SID7>
]]></artwork>
</figure>
<t>Replication to R2 steers the packet directly to R2 on interface <t>Replication to R2 steers the packet directly to R2 on interface
L12. Replication to R6, using N-SID6, steers the packet via shortest L12. Replication to R6, using N-SID6, steers the packet via the
path to that node. Replication to R7 is steered via R4, using N-SID4 shortest path to that node. Replication to R7 is steered via R4, using
and then adjacency SID A-SID47 to R7.</t> N-SID4 and then adjacency SID A-SID47 to R7.</t>
<t>Replication segment at R2:</t> <t>Replication segment at R2:</t>
<figure> <sourcecode name="" type="pseudocode">Replication segment
<artwork><![CDATA[Replication segment <R-ID,R2>: &lt;R-ID,R2&gt;: Replication-SID: R-SID2 Replication state: R2:
Replication SID: R-SID2 &lt;Leaf&gt;</sourcecode>
Replication state:
R2: <Leaf>]]></artwork>
</figure>
<t>Replication segment at R6:</t> <t>Replication segment at R6:</t>
<figure> <sourcecode name="" type="pseudocode">Replication segment
<artwork><![CDATA[Replication segment <R-ID,R6>: &lt;R-ID,R6&gt;: Replication-SID: R-SID6 Replication state: R6:
Replication SID: R-SID6 &lt;Leaf&gt;</sourcecode>
Replication state:
R6: <Leaf>]]></artwork>
</figure>
<t>Replication segment at R7:</t> <t>Replication segment at R7:</t>
<figure> <sourcecode name="" type="pseudocode">Replication segment
<artwork><![CDATA[Replication segment <R-ID,R7>: &lt;R-ID,R7&gt;: Replication-SID: R-SID7 Replication state: R7:
Replication SID: R-SID7 &lt;Leaf&gt;</sourcecode>
Replication state:
R7: <Leaf>]]></artwork>
</figure>
<t>When a packet is steered into the Replication segment at R1:</t> <t>When a packet is steered into the Replication segment at R1:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>Since R1 is directly connected to R2, R1 performs PUSH <li>R1 performs the PUSH operation with just the &lt;R-SID2&gt;
operation with just &lt;R-SID2&gt; label for the replicated copy label for the replicated copy and sends it to R2 on interface L12,
and sends it to R2 on interface L12. R2, as Leaf, performs NEXT since R1 is directly connected to R2. R2, as leaf, performs the NEXT
operation, pops R-SID2 label and delivers the payload.</t> operation, pops the R-SID2 label, and delivers the payload.</li>
<t>R1 performs PUSH operation with &lt;N-SID6, R-SID6&gt; label <li>R1 performs the PUSH operation with the &lt;N-SID6, R-SID6&gt;
stack for the replicated copy to R6 and sends it to R2, the label stack for the replicated copy to R6 and sends it to R2, which
nexthop on shortest path to R6. R2 performs CONTINUE operation on is the nexthop on the shortest path to R6. R2 performs the CONTINUE
N-SID6 and forwards it to R3. R3 is the penultimate hop for operation on N-SID6 and forwards it to R3. R3 is the penultimate hop
N-SID6; it performs penultimate hop popping, which corresponds to for N-SID6; it performs penultimate hop popping, which corresponds
the NEXT operation and the packet is then sent to R6 with to the NEXT operation. The packet is then sent to R6 with
&lt;R-SID6&gt; in the label stack. R6, as Leaf, performs NEXT &lt;R-SID6&gt; in the label stack. R6, as leaf, performs the NEXT
operation, pops R-SID6 label and delivers the payload.</t> operation, pops the R-SID6 label, and delivers the payload.</li>
<t>R1 performs PUSH operation with &lt;N-SID4, A-SID47, R-SID7&gt; <li>R1 performs the PUSH operation with the &lt;N-SID4, A-SID47,
label stack for the replicated copy to R7 and sends it to R2, the R-SID7&gt; label stack for the replicated copy to R7 and sends it to
nexthop on shortest path to R4. R2 is the penultimate hop for R2, which is the nexthop on the shortest path to R4. R2 is the
N-SID4; it performs penultimate hop popping, which corresponds to penultimate hop for N-SID4; it performs penultimate hop popping,
the NEXT operation and the packet is then sent to R4 with which corresponds to the NEXT operation. The packet is then sent to
&lt;A-SID47, R-SID1&gt; in the label stack. R4 performs NEXT R4 with &lt;A-SID47, R-SID1&gt; in the label stack. R4 performs the
operation, pops A-SID47, and delivers packet to R7 with NEXT operation, pops A-SID47, and delivers the packet to R7 with
&lt;R-SID7&gt; in the label stack. R7, as Leaf, performs NEXT &lt;R-SID7&gt; in the label stack. R7, as leaf, performs the NEXT
operation, pops R-SID7 label and delivers the payload.</t> operation, pops the R-SID7 label, and delivers the payload.</li>
</list></t> </ul>
</section> </section>
<section title="SRv6"> <section numbered="true" toc="default">
<t>For SRv6 , we use SID allocation scheme, reproduced below, from <name>SRv6</name>
Illustrations for SRv6 Network Programming <xref
target="I-D.filsfils-spring-srv6-net-pgm-illustration"/></t>
<t><list style="symbols"> <t>For SRv6, we use the SID allocation scheme, reproduced below, from
<t>2001:db8::/32 is an IPv6 block allocated by a Regional Internet "Illustrations for SRv6 Network Programming" <xref format="default"
Registry (RIR) to the operator</t> target="I-D.filsfils-spring-srv6-net-pgm-illustration"/>:</t>
<t>2001:db8:0::/48 is dedicated to the internal address space</t> <ul spacing="normal">
<li>2001:db8::/32 is an IPv6 block allocated by a Regional Internet
Registry (RIR) to the operator.</li>
<t>2001:db8:cccc::/48 is dedicated to the internal SRv6 SID <li>2001:db8:0::/48 is dedicated to the internal address space.</li>
space</t>
<t>We assume a location expressed in 64 bits and a function <li>2001:db8:cccc::/48 is dedicated to the internal SRv6 SID
expressed in 16 bits</t> space.</li>
<t>Node k has a classic IPv6 loopback address 2001:db8::k/128 <li>We assume a location expressed in 64 bits and a function
which is advertised in the Interior Gateway Protocol (IGP)</t> expressed in 16 bits.</li>
<t>Node k has 2001:db8:cccc:k::/64 for its local SID space. Its <li>Node k has a classic IPv6 loopback address 2001:db8::k/128,
SIDs will be explicitly assigned from that block</t> which is advertised in the Interior Gateway Protocol (IGP).</li>
<t>Node k advertises 2001:db8:cccc:k::/64 in its IGP</t> <li>Node k has 2001:db8:cccc:k::/64 for its local SID space. Its
SIDs will be explicitly assigned from that block.</li>
<t>Function :1:: (function 1, for short) represents the End <li>Node k advertises 2001:db8:cccc:k::/64 in its IGP.</li>
function with Penultimate Segment Pop of SRH (PSP) <xref
target="RFC8986"/> and USD support</t>
<t>Function :Cn:: (function Cn, for short) represents the End.X <li>Function :1:: (function 1, for short) represents the End
function from to Node n with PSP and USD support</t> function with the Penultimate Segment Pop (PSP) of the SRH <xref
</list></t> format="default" target="RFC8986"/> and USD support.</li>
<t>Each node k has: <list style="symbols"> <li>Function :Cn:: (function Cn, for short) represents the End.X
<t>An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to function from to Node n with PSP and USD support.</li>
an End function with additional support for PSP and USD</t> </ul>
<t>An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to <t>Each node k has:</t>
an End.X function to neighbor J with additional support for PSP
and USD</t>
<t>An explicit SID instantiation 2001:db8:cccc:k:Fk::/128 bound to <ul spacing="normal">
an End.Replicate function</t> <li>An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to
</list></t> an End function with additional support for PSP and 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.</li>
<li>An explicit SID instantiation 2001:db8:cccc:k:Fk::/128 bound to
an End.Replicate function.</li>
</ul>
<t>Assume a Replication segment identified with R-ID at Replication <t>Assume a Replication segment identified with R-ID at Replication
node R1 and downstream nodes R2, R6 and R7. The Replication SID at node R1 and downstream nodes R2, R6, and R7. The Replication-SID at
node k, bound to an End.Replicate function, is node k, bound to an End.Replicate function, is
2001:db8:cccc:k:Fk::/128. A packet replicated from R1 to R7 has to 2001:db8:cccc:k:Fk::/128. A packet replicated from R1 to R7 has to
traverse R4.</t> traverse R4.</t>
<t>The Replication segment state at nodes R1, R2, R6 and R7 is shown <t>The Replication segments at nodes R1, R2, R6, and R7 are shown
below. Note nodes R3, R4 and R5 do not have state for the Replication below. Note nodes R3, R4, and R5 do not have a Replication
segment. The state representation uses "R-SID-&gt;Lmn" to represent a segment. The state representation uses "R-SID-&gt;Lmn" to represent a
packet replication with outgoing replication SID R-SID sent on packet replication with outgoing Replication-SID R-SID sent on
interface Lmn. "SL" represents and optional segment list used to steer interface Lmn. "SL" represents an optional segment list used to steer
a replicated packet on a specific path to a Downstream node.</t> a replicated packet on a specific path to a downstream node.</t>
<t>Replication segment at R1:</t> <t>Replication segment at R1:</t>
<figure> <sourcecode name="" type="pseudocode">Replication segment
<artwork><![CDATA[Replication segment <R-ID,R1>: &lt;R-ID,R1&gt;: Replication-SID: 2001:db8:cccc:1:F1::0 Replication
Replication SID: 2001:db8:cccc:1:F1::0 state: R2: &lt;2001:db8:cccc:2:F2::0-&gt;L12&gt; R6:
Replication state: &lt;2001:db8:cccc:6:F6::0&gt; R7: &lt;2001:db8:cccc:4:C7::0&gt;, SL:
R2: <2001:db8:cccc:2:F2::0->L12> &lt;2001:db8:cccc:7:F7::0&gt;</sourcecode>
R6: <2001:db8:cccc:6:F6::0>
R7: <2001:db8:cccc:4:C7::0>, SL: <2001:db8:cccc:7:F7::0>
]]></artwork>
</figure>
<t>Replication to R2 steers the packet directly to R2 on interface <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 L12. Replication to R6, using 2001:db8:cccc:6:F6::0, steers the packet
via shortest path to that node. Replication to R7 is steered via R4, via the shortest path to that node. Replication to R7 is steered via
using H.Encaps.Red with End.X SID 2001:db8:cccc:4:C7::0 at R4 to R4, using H.Encaps.Red with End.X SID 2001:db8:cccc:4:C7::0 at R4 to
R7.</t> R7.</t>
<t>Replication segment at R2:</t> <t>Replication segment at R2:</t>
<figure> <sourcecode name="" type="pseudocode">Replication segment
<artwork><![CDATA[Replication segment <R-ID,R2>: &lt;R-ID,R2&gt;: Replication-SID: 2001:db8:cccc:2:F2::0 Replication
Replication SID: 2001:db8:cccc:2:F2::0 state: R2: &lt;Leaf&gt;</sourcecode>
Replication state:
R2: <Leaf>]]></artwork>
</figure>
<t>Replication segment at R6:</t> <t>Replication segment at R6:</t>
<figure> <sourcecode name="" type="pseudocode">Replication segment
<artwork><![CDATA[Replication segment <R-ID,R6>: &lt;R-ID,R6&gt;: Replication-SID: 2001:db8:cccc:6:F6::0 Replication
Replication SID: 2001:db8:cccc:6:F6::0 state: R6: &lt;Leaf&gt;</sourcecode>
Replication state:
R6: <Leaf>]]></artwork>
</figure>
<t>Replication segment at R7:</t> <t>Replication segment at R7:</t>
<figure> <sourcecode name="" type="pseudocode">Replication segment
<artwork><![CDATA[Replication segment <R-ID,R7>: &lt;R-ID,R7&gt;: Replication-SID: 2001:db8:cccc:7:F7::0 Replication
Replication SID: 2001:db8:cccc:7:F7::0 state: R7: &lt;Leaf&gt;</sourcecode>
Replication state:
R7: <Leaf>]]></artwork>
</figure>
<t>When a packet, (A,B2), is steered into the Replication segment at <t>When a packet, (A,B2), is steered into the Replication segment at
R1:</t> R1:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>Since R1 is directly connected to R2, R1 creates encapsulated <li>R1 creates an encapsulated replicated copy (2001:db8::1,
replicated copy (2001:db8::1, 2001:db8:cccc:2:F2::0) (A, B2), and 2001:db8:cccc:2:F2::0) (A, B2), and sends it to R2 on interface L12,
sends it to R2 on interface L12. R2, as Leaf, removes outer IPv6 since R1 is directly connected to R2. R2, as leaf, removes the outer
header and delivers the payload.</t> IPv6 header and delivers the payload.</li>
<t>R1 creates encapsulated replicated copy (2001:db8::1, <li>R1 creates an encapsulated replicated copy (2001:db8::1,
2001:db8:cccc:6:F6::0) (A, B2) then forwards the resulting packet 2001:db8:cccc:6:F6::0) (A, B2) then forwards the resulting packet on
on the shortest path to 2001:db8:cccc:6::/64. R2 and R3 forward the shortest path to 2001:db8:cccc:6::/64. R2 and R3 forward the
the packet using 2001:db8:cccc:6::/64. R6, as Leaf, removes outer packet using 2001:db8:cccc:6::/64. R6, as leaf, removes the outer
IPv6 header and delivers the payload.</t> IPv6 header and delivers the payload.</li>
<t>R1 has to steer packet to Downstream node R7 via node R4. It <li>
can do this in one of two ways:<list style="symbols"> <t>R1 has to steer the packet to downstream node R7 via node R4.
<t>R1 creates encapsulated replicated copy (2001:db8::1, It can do this in one of two ways:</t>
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.</t>
<t>R1 is Root of replication segment. Therefore, it can <ul spacing="normal">
combine above encapsulations to create encapsulated replicated <li>R1 creates an encapsulated replicated copy (2001:db8::1,
copy (2001:db8::1, 2001:db8:cccc:4:C7::0) 2001:db8:cccc:7:F7::0) (A, B2) and then performs H.Encaps.Red
(2001:db8:cccc:7:F7::0; SL=1) (A, B2) and sends it to R2, the using the SL to create the (2001:db8::1, 2001:db8:cccc:4:C7::0)
nexthop on shortest path to 2001:db8:cccc:4::/64. R2 forwards (2001:db8::1, 2001:db8:cccc:7:F7::0) (A, B2) packet. It sends
packet to R4 using 2001:db8:cccc:4::/64. R4 executes End.X this packet to R2, which is the nexthop on the shortest path to
function on 2001:db8:cccc:4:C7::0, performs PSP action, 2001:db8:cccc:4::/64. R2 forwards the packet to R4 using
removes SRH and sends resulting packet (2001:db8::1, 2001:db8:cccc:4::/64. R4 executes the End.X function on
2001:db8:cccc:7:F7::0) (A, B2) to R7. R7, as Leaf, removes 2001:db8:cccc:4:C7::0, performs a USD action, removes the outer
outer IPv6 header and delivers the payload.</t> IPv6 encapsulation, and sends the resulting packet (2001:db8::1,
</list></t> 2001:db8:cccc:7:F7::0) (A, B2) to R7. R7, as leaf, removes the
</list></t> outer IPv6 header and delivers the payload.</li>
<section title="Pinging Replication SID"> <li>R1 is the root of the Replication segment. Therefore, it can
<t>This section illustrates ping of a Replication SID.</t> 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 the SRH, and sends the resulting packet
(2001:db8::1, 2001:db8:cccc:7:F7::0) (A, B2) to R7. R7, as leaf,
removes the outer IPv6 header and delivers the payload.</li>
</ul>
</li>
</ul>
<t>Node R1 pings replication SID of node R6 directly by sending the <section anchor="A.2.1" numbered="true" toc="default">
following packet:</t> <name>Pinging a Replication-SID</name>
<t><list style="numbers"> <t>This section illustrates the ping of a Replication-SID.</t>
<t>R1 to R6: (2001:db8::1, 2001:db8:cccc:6:F6::0; NH=ICMPv6)
(ICMPv6 Echo Request)</t>
<t>Node R6 as a Leaf processes upper layer ICMPv6 Echo Request <t>Node R1 pings the Replication-SID of node R6 directly by sending
and responds with ICMPv6 Echo Reply</t> the following packet:</t>
</list></t>
<t>Node R1 pings Replication SID of R7 via R4 by sending the <ol spacing="normal" type="1">
following packet with SRH:</t> <li>R1 to R6: (2001:db8::1, 2001:db8:cccc:6:F6::0; NH=ICMPv6)
(ICMPv6 Echo Request).</li>
<t><list style="numbers"> <li>Node R6 as a leaf processes the upper-layer ICMPv6 Echo
<t>R1 to R4: (2001:db8::1, 2001:db8:cccc:4:C7::0) Request and responds with an ICMPv6 Echo Reply.</li>
(2001:db8:cccc:7:F7::0; SL=1; NH=ICMPV6) (ICMPv6 Echo </ol>
Request)</t>
<t>R4 to R7: (2001:db8::1, 2001:db8:cccc:7:F7::0; NH=ICMPv6) <t>Node R1 pings the Replication-SID of R7 via R4 by sending the
(ICMPv6 Echo Request)</t> following packet with the SRH:</t>
<t>Node R7 as a Leaf processes upper layer ICMPv6 Echo Request <ol spacing="normal" type="1">
and responds with ICMPv6 Echo Reply</t> <li>R1 to R4: (2001:db8::1, 2001:db8:cccc:4:C7::0)
</list></t> (2001:db8:cccc:7:F7::0; SL=1; NH=ICMPV6) (ICMPv6 Echo
Request).</li>
<t>Assume node R4 is a transit Replication node with Replication SID <li>R4 to R7: (2001:db8::1, 2001:db8:cccc:7:F7::0; NH=ICMPv6)
2001:db8:cccc:4:F4::0 replicating to R7. Node R1 pings Replication (ICMPv6 Echo Request).</li>
SID of R7 via Replication SID of R4 as follows:</t>
<t><list style="numbers"> <li>Node R7 as a leaf processes the upper-layer ICMPv6 Echo
<t>R1 to R4: (2001:db8::1, 2001:db8:cccc:4:F4::0; NH=ICMPv6) Request and responds with an ICMPv6 Echo Reply.</li>
(ICMPv6 Echo Request)</t> </ol>
<t>R4 replicates to R7 by replacing IPv6 destination address <t>Assume node R4 is a transit replication node with Replication-SID
with Replication SID of R7 from its Replication state</t> 2001:db8:cccc:4:F4::0 replicating to R7. Node R1 pings the
Replication-SID of R7 via the Replication-SID of R4 as follows:</t>
<t>R4 to R7: (2001:db8::1, 2001:db8:cccc:7:F7::0; NH=ICMPv6) <ol spacing="normal" type="1">
(ICMPv6 Echo Request)</t> <li>R1 to R4: (2001:db8::1, 2001:db8:cccc:4:F4::0; NH=ICMPv6)
(ICMPv6 Echo Request).</li>
<t>Node R7 as a Leaf processes upper layer ICMPv6 Echo Request <li>R4 replicates to R7 by replacing the IPv6 DA
and responds with ICMPv6 Echo Reply</t> with the Replication-SID of R7 from its Replication state.</li>
</list></t>
<li>R4 to R7: (2001:db8::1, 2001:db8:cccc:7:F7::0; NH=ICMPv6)
(ICMPv6 Echo Request).</li>
<li>Node R7 as a leaf processes the upper-layer ICMPv6 Echo
Request and responds with an ICMPv6 Echo Reply.</li>
</ol>
</section> </section>
</section> </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> </back>
</rfc> </rfc>
 End of changes. 223 change blocks. 
865 lines changed or deleted 1092 lines changed or added

This html diff was produced by rfcdiff 1.48.