rfc9960xml2.original.xml   rfc9960.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 xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc compact="yes"?> tf-pim-sr-p2mp-policy-22" number="9960" consensus="true" ipr="trust200902" updat
<?rfc subcompact="no"?> es="9524" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" toc
<rfc category="std" docName="draft-ietf-pim-sr-p2mp-policy-22" Depth="3" symRefs="true" sortRefs="true" version="3">
ipr="trust200902" updates="9524">
<!--[rfced] Should "(SR)" and "(P2MP)" be added to this document's
title for consistency with the title in RFC-to-be 9961, or do you
prefer the current form?
Original:
Segment Routing Point-to-Multipoint Policy
Perhaps:
Segment Routing (SR) Point-to-Multipoint (P2MP) Policy
-->
<front> <front>
<title abbrev="SR P2MP Policy">Segment Routing Point-to-Multipoint <title abbrev="SR P2MP Policy">Segment Routing Point-to-Multipoint
Policy</title> Policy</title>
<seriesInfo name="RFC" value="9960"/>
<author fullname="Rishabh Parekh (editor)" initials="R." <author fullname="Rishabh Parekh" initials="R." surname="Parekh" role="edito
surname="Parekh, Ed."> r">
<organization>Arrcus</organization> <organization>Arrcus</organization>
<address> <address>
<postal> <postal>
<street/>
<city>San Jose</city> <city>San Jose</city>
<country>United States of America</country>
<region/>
<code/>
<country>US</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>rishabh@arrcus.com</email> <email>rishabh@arrcus.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Daniel Voyer" initials="D." surname="Voyer" role="editor">
<author fullname="Daniel Voyer (editor)" initials="D."
surname="Voyer, Ed.">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</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>davoyer@cisco.com</email> <email>davoyer@cisco.com</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="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 month="April" year="2026"/>
<area>RTG</area>
<workgroup>pim</workgroup>
<date day="04" month="September" year="2025"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->
<keyword>example</keyword>
<abstract> <abstract>
<t>Point-to-Multipoint (P2MP) Policy enables creation of P2MP trees for <t>The Point-to-Multipoint (P2MP) Policy enables creation of P2MP trees fo
efficient multi-point packet delivery in a Segment Routing (SR) domain. r
efficient multipoint packet delivery in a Segment Routing (SR) domain.
This document specifies the architecture, signaling, and procedures for This document specifies the architecture, signaling, and procedures for
SR P2MP Policies with Segment Routing over MPLS (SR-MPLS) and Segment SR P2MP Policies with Segment Routing over MPLS (SR-MPLS) and Segment
Routing over IPv6 (SRv6). It defines the SR P2MP Policy construct, Routing over IPv6 (SRv6). It defines the SR P2MP Policy construct,
candidate paths (CP) of an SR P2MP Policy and the instantiation of the candidate paths (CPs) of an SR P2MP Policy, and the instantiation of the
P2MP tree instances of a candidate path using Replication segments. P2MP tree instances (PTIs) of a CP using Replication segments.
Additionally, it describes the required extensions for a controller to Additionally, it describes the required extensions for a controller to
support P2MP path computation and provisioning. This document updates support P2MP path computation and provisioning. This document updates
RFC 9524.</t> RFC 9524.</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
<xref target="RFC2119"/> <xref target="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>RFC 9524 defines a Replication segment which enables an SR node to <name>Introduction</name>
replicate traffic to multiple downstream nodes in an SR domain <xref <t><xref target="RFC9524"/> defines a Replication segment that enables a S
target="RFC8402"/>. A P2MP service can be realized by a single egment Routing (SR) node to
replicate traffic to multiple downstream nodes in an SR domain <xref targe
t="RFC8402" format="default"/>. A Point-to-Multipoint (P2MP) service can be real
ized by a single
Replication segment spanning from the ingress node to the egress nodes Replication segment spanning from the ingress node to the egress nodes
of the service. This effectively achieves ingress replication which is of the service. This effectively achieves ingress replication, which is
inefficient since the traffic of the P2MP service may traverse the same inefficient since the traffic of the P2MP service may traverse the same
set of nodes and links in the SR domain on its path from the ingress set of nodes and links in the SR domain on its path from the ingress
node to the egress nodes.</t> node to the egress nodes.</t>
<t>A Multi-point service delivery can be efficiently realized with a <!--[rfced] Please let us know how we may clarify this sentence. Does
P2MP tree in a Segment Routing domain . A P2MP tree spans from a Root "stitched to one or more Replication segments..." refer to the
"Root node" (option A) or to the "Replication segment" (option B)?
Does "at" the Leaf nodes and intermediate Replication nodes mean
"between"?
Original:
It consists of a Replication segment at the Root node, stitched to one
or more Replication segments at Leaf nodes and intermediate
Replication nodes.
Perhaps A:
It consists of a Replication segment at the Root node, which is stitched
to one or more Replication segments between the Leaf nodes and intermediate
Replication nodes.
Perhaps B:
It consists of a Replication segment at the Root node, and that
Replication segment is stitched to one or more Replication segments
between the Leaf nodes and intermediate Replication nodes.
-->
<t>A multipoint service delivery can be efficiently realized with a
P2MP tree in a Segment Routing domain. A P2MP tree spans from a Root
node to a set of Leaf nodes via intermediate Replication nodes. It node to a set of Leaf nodes via intermediate Replication nodes. It
consists of a Replication segment at the Root node, stitched to one or consists of a Replication segment at the Root node, stitched to one or
more Replication segments at Leaf nodes and intermediate Replication more Replication segments at Leaf nodes and intermediate Replication
nodes. A Bud node <xref target="RFC9524"/> is a node that is both a nodes. A Bud node <xref target="RFC9524" format="default"/> is a node that is both a
Replication node and a Leaf node. Any mention of "Leaf node(s)" in this Replication node and a Leaf node. Any mention of "Leaf node(s)" in this
document should be considered as referring to "Leaf or Bud node(s)".</t> document should be considered as referring to "Leaf or Bud node(s)".</t>
<t>An SR P2MP Policy defines the Root and Leaf nodes of a P2MP tree. It <t>An SR P2MP Policy defines the Root and Leaf nodes of a P2MP tree. It
has one or more candidate paths (CP) provisioned with optional has one or more candidate paths (CPs) provisioned with optional
constraints and/or optimization objectives.</t> constraints and/or optimization objectives.</t>
<t>A controller computes P2MP tree instances of the candidate paths <t>A controller computes P2MP tree instances of the candidate paths
using the constraints and objectives specified in the candidate path. using the constraints and objectives specified in the candidate path.
The controller then instantiates a P2MP tree instance in the SR domain The controller then instantiates a P2MP tree instance in the SR domain
by signaling Replication segments to the Root, Replication and Leaf by signaling Replication segments to the Root, Replication, and Leaf
nodes. A Path Computation Element (PCE) <xref target="RFC4655"/> is one nodes. A Path Computation Element (PCE) <xref target="RFC4655" format="def
ault"/> is one
example of such a controller. In other cases, a P2MP tree instance can example of such a controller. In other cases, a P2MP tree instance can
be installed using NETCONF/YANG or Command Line Interface(CLI) on the be installed using the Network Configuration Protocol (NETCONF) / YANG or
Root, Replication and the Leaf nodes.</t> the Command Line Interface (CLI) on the
Root, Replication, and Leaf nodes.</t>
<t>The Replication segments of a P2MP tree instance can be instantiated <t>The Replication segments of a P2MP tree instance can be instantiated
for SR-MPLS <xref target="RFC8660"/> and SRv6 <xref target="RFC8986"/> for SR-MPLS <xref target="RFC8660" format="default"/> and SRv6 <xref targe t="RFC8986" format="default"/>
data planes, enabling efficient packet replication within an SR data planes, enabling efficient packet replication within an SR
domain.</t> domain.</t>
<t>This document updates the Replication-ID portion of the Replication seg
<t>This document updates Replication-ID portion of a Replication segment ment
identifier specified in Section 2 of <xref target="RFC9524"/>.</t> identifier (Replication-SID) specified in <xref target="RFC9524" section="
2"/>.</t>
<section title="Terminology"> <section numbered="true" toc="default">
<name>Terminology</name>
<t>This section defines terms used frequently in this document. Refer <t>This section defines terms used frequently in this document. Refer
to Terminology section of <xref target="RFC9524"/> for definition of to the Terminology section of <xref target="RFC9524" format="default"/> for the definitions of
Replication segment and other terms associated with it and the Replication segment and other terms associated with it and the
definition of Root, Leaf and Bud node.</t> definitions of Root, Leaf, and Bud nodes.</t>
<dl spacing="normal" newline="false">
<t>SR P2MP Policy: An SR P2MP Policy is a framework to construct P2MP <dt>SR P2MP Policy:</dt><dd>An SR P2MP Policy is a framework to construc
trees in an SR domain by specifying a Root and Leaf nodes.</t> t P2MP
trees in an SR domain by specifying Root and Leaf nodes.</dd>
<t>Tree-ID: An identifier of an SR P2MP Policy in context of the Root <dt>Tree-ID:</dt><dd>An identifier of an SR P2MP Policy in context of th
node.</t> e Root
node.</dd>
<t>Candidate path: A candidate path (CP) of SR P2MP Policy defines <dt>Candidate path (CP):</dt><dd>A CP of the SR P2MP Policy defines
topological or resource constraints and optimization objectives that topological or resource constraints and optimization objectives that
are used to compute and construct P2MP tree instances.</t> are used to compute and construct P2MP tree instances.</dd>
<dt>P2MP tree instance (PTI):</dt><dd>A PTI of a candidate path
<t>P2MP tree instance: A P2MP tree instance (PTI) of a candidate path is constructed by stitching Replication segments between the Root and Le
is constructed by stitching Replication segments between Root and Leaf af
nodes of an SR P2MP Policy. Its topology is determined by constraints nodes of an SR P2MP Policy. Its topology is determined by the constraint
and optimization objective of the candidate path.</t> s
and optimization objective of the candidate path.</dd>
<t>Instance-ID: An identifier of a P2MP tree instance in context of <dt>Instance-ID:</dt><dd>An identifier of a P2MP tree instance in contex
the SR P2MP Policy.</t> t of
the SR P2MP Policy.</dd>
<t>Tree-SID: The Replication-SID of the Replication segment at the <dt>Tree-SID:</dt><dd>The Replication-SID of the Replication segment at
Root node of a P2MP tree instance.</t> the
Root node of a P2MP tree instance.</dd>
</dl>
</section>
<section>
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="SR P2MP Policy"> <name>SR P2MP Policy</name>
<t>An SR P2MP Policy is used to instantiate P2MP trees between a Root <t>An SR P2MP Policy is used to instantiate P2MP trees between Root
and Leaf nodes in an SR domain. Note, multiple SR P2MP Policies can have and Leaf nodes in an SR domain. Note that multiple SR P2MP Policies can ha
identical Root node and identical set of Leaf nodes. An SR P2MP Policy ve
has one or more candidate paths <xref target="RFC9256"/>.</t> identical Root nodes and identical sets of Leaf nodes. An SR P2MP Policy
has one or more candidate paths <xref target="RFC9256" format="default"/>.
<section title="SR P2MP Policy identification"> </t>
<section numbered="true" toc="default">
<name>SR P2MP Policy Identification</name>
<t>An SR P2MP Policy is uniquely identified by the tuple &lt;Root, <t>An SR P2MP Policy is uniquely identified by the tuple &lt;Root,
Tree-ID&gt;, where:</t> Tree-ID&gt;, where:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Root: The IP address of the Root node of P2MP trees <t>Root: The IP address of the Root node of P2MP trees
instantiated by the SR P2MP Policy.</t> instantiated by the SR P2MP Policy.</t>
</li>
<li>
<t>Tree-ID: A 32-bit unsigned integer that uniquely identifies the <t>Tree-ID: A 32-bit unsigned integer that uniquely identifies the
SR P2MP Policy in the context of the Root node.</t> SR P2MP Policy in the context of the Root node.</t>
</list></t> </li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="Components of an SR P2MP Policy"> <name>Components of an SR P2MP Policy</name>
<t>An SR P2MP Policy consists of the following elements:</t> <t>An SR P2MP Policy consists of the following elements:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Leaf nodes: A set of nodes that terminate the P2MP trees of the <t>Leaf nodes: A set of nodes that terminate the P2MP trees of the
SR P2MP Policy.</t> SR P2MP Policy.</t>
</li>
<t>candidate paths: A set of possible paths that define <li>
<t>Candidate paths: A set of possible paths that define
constraints and optimization objectives for P2MP tree instances of constraints and optimization objectives for P2MP tree instances of
the SR P2MP Policy.</t> the SR P2MP Policy.</t>
</list></t> </li>
</ul>
<t>An SR P2MP Policy and its CPs are provisioned on a controller (see <t>An SR P2MP Policy and its CPs are provisioned on a controller (see
Section <xref format="counter" target="Controller"/>) or the Root node <xref target="Controller"/>) or the Root node
or both depending upon the provisioning model. After provisioning, the or both, depending upon the provisioning model. After provisioning, the
Policy and its CPs are instantiated on the Root node or the controller Policy and its CPs are instantiated on the Root node or the controller
by using a signalling protocol.</t> by using a signaling protocol.</t>
</section> </section>
<section anchor="Candidate_Path" numbered="true" toc="default">
<section anchor="Candidate_Path" <name>Candidate Paths and P2MP Tree Instances</name>
title="Candidate Paths and P2MP Tree instances">
<t>An SR P2MP Policy has one or more CPs. The tuple <t>An SR P2MP Policy has one or more CPs. The tuple
&lt;Protocol-Origin, Originator, Discriminator&gt;, as specified in &lt;Protocol-Origin, Originator, Discriminator&gt;, as specified in
Section 2.6 of <xref target="RFC9256"/>, uniquely identifies a <xref target="RFC9256" section="2.6"/>, uniquely identifies a
candidate path in the context of an SR P2MP Policy. The semantics of candidate path in the context of an SR P2MP Policy. The semantics of
Procotol-Origin, Originator and Discriminator fields of the identifier Protocol-Origin, Originator, and Discriminator fields of the identifier
are same as in Section 2.3, 2.4 and 2.5 of <xref target="RFC9256"/> are the same as in Sections <xref target="RFC9256" sectionFormat="bare"
section="2.3"/>, <xref target="RFC9256" sectionFormat="bare" section="2.4"/>, an
d <xref target="RFC9256" sectionFormat="bare" section="2.5"/> of <xref target="R
FC9256" format="default"/>,
respectively.</t> respectively.</t>
<t>The Root node of the SR P2MP Policy selects the active candidate <t>The Root node of the SR P2MP Policy selects the active candidate
path based on the tie breaking rules defined in Section 2.9 of <xref path based on the tiebreaking rules defined in <xref target="RFC9256" se
target="RFC9256"/>.</t> ction="2.9"/>.</t>
<t>A CP may include topological and/or resource constraints and <t>A CP may include topological and/or resource constraints and
optimization objectives which influence the computation of the PTIs of optimization objectives that influence the computation of the PTIs of
the CP.</t> the CP.</t>
<t>A candidate path has zero or more PTIs. A candidate path does not <t>A candidate path has zero or more PTIs. A candidate path does not
have a PTI when the controller cannot compute a P2MP tree from the have a PTI when the controller cannot compute a P2MP tree from the
netowrk topology based on the constraints and/or optimization network topology based on the constraints and/or optimization
objectives of the CP. A candidate path can have more than one PTIs, objectives of the CP. A candidate path can have more than one PTI,
for e.g during Make-Before-Break (see <xref target="Tree_Compute"/>) e.g., during the Make-Before-Break (see <xref target="Tree_Compute" form
at="default"/>)
procedure to handle a network state change. However, one and only one procedure to handle a network state change. However, one and only one
PTI MUST be the active instance of the CP. If more than one PTIs of a PTI <bcp14>MUST</bcp14> be the active instance of the CP. If more than o
CP are active at same time, and that CP is the active CP of SR P2MP ne PTI of a
CP is active at same time, and that CP is the active CP of the SR P2MP
Policy, then duplicate traffic may be delivered to the Leaf nodes.</t> Policy, then duplicate traffic may be delivered to the Leaf nodes.</t>
<t>A PTI is identified by an Instance-ID. This is an unsigned 16-bit <t>A PTI is identified by an Instance-ID. This is an unsigned 16-bit
number which is unique in context of the SR P2MP Policy of the number that is unique in context of the SR P2MP Policy of the
candidate path.</t> candidate path.</t>
<t>PTIs are instantiated using Replication segments. Section 2 of <!--[rfced] We are having difficulty parsing the listed items in this
<xref target="RFC9524"/> specifies Replication-ID of the Replication sentence. To clarify, may we update as follows?
Original:
For this use case, the Root MUST be zero (0.0.0.0 for IPv4 and ::
for IPv6) and the Instance-ID MUST be zero and the 32-bit Tree-ID
effectively make the Replication segment identifier <[0.0.0.0 or
::], Tree-ID, 0, Node-ID>.
Perhaps:
For this use case, the Root MUST be zero (0.0.0.0 for IPv4 and ::
for IPv6), the Instance-ID MUST be zero, and the 32-bit Tree-ID
effectively makes the Replication segment identifier <[0.0.0.0 or
::], Tree-ID, 0, Node-ID>.
-->
<t>PTIs are instantiated using Replication segments.
<xref target="RFC9524" section="2"/> specifies the Replication-ID of the
Replication
segment identifier tuple as a variable length field that can be segment identifier tuple as a variable length field that can be
modified as required based on the use of a Replication segment. modified as required based on the use of a Replication segment.
However, length is an imprecise indicator of the actual structure of However, length is an imprecise indicator of the actual structure of
the Replication-ID. This document updates the Replication-ID of a the Replication-ID. This document updates the Replication-ID of a
Replication segment identifier of RFC 9524 to be the tuple: &lt;Root, Replication segment identifier <xref target="RFC9524"/> to be the tuple: &lt;Root,
Tree-ID, Instance-ID, Node-ID&gt;, where &lt;Root, Tree-ID&gt; Tree-ID, Instance-ID, Node-ID&gt;, where &lt;Root, Tree-ID&gt;
identifies the SR P2MP Policy and Instance-ID identifies the PTI identifies the SR P2MP Policy and Instance-ID identifies the PTI
within that SR P2MP Policy. This results in the Replication segments within that SR P2MP Policy. This results in the Replication segments
used to instantiate a PTI being identified by the tuple: &lt;Root, used to instantiate a PTI being identified by the tuple: &lt;Root,
Tree-ID, Instance-ID, Node-ID&gt;. In the simplest case, Tree-ID, Instance-ID, Node-ID&gt;. In the simplest case, the
Replication-ID of a Replication segment is a 32-bit number as per Replication-ID of a Replication segment is a 32-bit number as per
Section 2 of RFC 9524. For this use case, the Root MUST be zero <xref section="2" target="RFC9524"/>. For this use case, the Root <bcp14
(0.0.0.0 for IPv4 and :: for IPv6) and the Instance-ID MUST be zero >MUST</bcp14> be zero
(0.0.0.0 for IPv4 and :: for IPv6) and the Instance-ID <bcp14>MUST</bcp1
4> be zero
and the 32-bit Tree-ID effectively make the Replication segment and the 32-bit Tree-ID effectively make the Replication segment
identifier &lt;[0.0.0.0 or ::], Tree-ID, 0, Node-ID&gt;.</t> identifier &lt;[0.0.0.0 or ::], Tree-ID, 0, Node-ID&gt;.</t>
<t>PTIs may have different tree topologies due to possibly differing <t>PTIs may have different tree topologies due to possibly differing
constraints and optimization objectives of the CPs in an SR P2MP constraints and optimization objectives of the CPs in an SR P2MP
policy and across different Policies. Even within a given CP, two PTIs Policy and across different policies. Even within a given CP, two PTIs
of that CP, say during Make-Before-Break procedure, are likely to have of that CP, say during the Make-Before-Break procedure, are likely to ha
ve
different tree topologies due to a change in the network state. Since different tree topologies due to a change in the network state. Since
the PTIs may have different tree topologies, their replication states the PTIs may have different tree topologies, their replication states
also differ at various nodes in the SR domain. Therefore each PTI has also differ at various nodes in the SR domain. Therefore, each PTI has
its own Replication segment and a unique Replication-SID at a given its own Replication segment and a unique Replication-SID at a given
node in the SR domain.</t> node in the SR domain.</t>
<t>A controller designates an active instance of a CP at the Root node <t>A controller designates an active instance of a CP at the Root node
of SR P2MP Policy by signalling this state through the protocol used of the SR P2MP Policy by signaling this state through the protocol used
to instantiate the Replication segment of the instance.</t> to instantiate the Replication segment of the instance.</t>
<t>This document focuses on the use of a controller to compute and <t>This document focuses on the use of a controller to compute and
instantiate PTIs of SR P2MP Policy CPs. It is also feasible to instantiate PTIs of SR P2MP Policy CPs. It is also feasible to
provision an explicit CP in an SR P2MP Policy with a static tree provision an explicit CP in an SR P2MP Policy with a static tree
topology using NETCONF/YANG or CLI. Note, a static tree topology will topology using NETCONF/YANG or CLI. Note that a static tree topology wil l
not adapt to any changes in the network state of an SR domain. The not adapt to any changes in the network state of an SR domain. The
explicit CPs may be provisioned on the controller or the Root node. explicit CPs may be provisioned on the controller or the Root node.
When an explicit CP is provisioned on the controller, the controller When an explicit CP is provisioned on the controller, the controller
bypasses the compute stage and directly instantiates the PTIs in the bypasses the compute stage and directly instantiates the PTIs in the
SR domain. When an explicit CP is provisioned on the Root node, the SR domain. When an explicit CP is provisioned on the Root node, the
Root node instantiates the PTIs in the SR domain. The exact procedures Root node instantiates the PTIs in the SR domain. The exact procedures
for provisioning an explicit CP and the signalling from the Root node for provisioning an explicit CP and the signaling from the Root node
to instantiate the PTIs are outside the scope of this document.</t> to instantiate the PTIs are outside the scope of this document.</t>
</section> </section>
</section> </section>
<section anchor="Steering" numbered="true" toc="default">
<section anchor="Steering" title="Steering traffic into an SR P2MP Policy"> <name>Steering Traffic into an SR P2MP Policy</name>
<t>The Replication-SID of the Replication segment at the Root node is <t>The Replication-SID of the Replication segment at the Root node is
referred to as the Tree-SID of a PTI. It is RECOMMENDED that the referred to as the Tree-SID of a PTI. It is <bcp14>RECOMMENDED</bcp14> tha t the
Tree-SID is also used as the Replication-SID for the Replication Tree-SID is also used as the Replication-SID for the Replication
segments at the intermediate Replication nodes and the Leaf nodes of the segments at the intermediate Replication nodes and the Leaf nodes of the
PTI as it simplifies operations and troubleshooting. However, the PTI as it simplifies operations and troubleshooting. However, the
Replication-SIDs of the Replication segments at the intermediate Replication-SIDs of the Replication segments at the intermediate
Replication nodes and the Leaf nodes MAY differ from the Tree-SID. For Replication nodes and the Leaf nodes <bcp14>MAY</bcp14> differ from the Tr
SRv6, Replication-SID is the FUNCT portion of the SRv6 SID <xref ee-SID. For
target="RFC8986"/> <xref target="RFC9524"/>.Note, even if the Tree-SID SRv6, Replication-SID is the FUNCT portion of the SRv6 segment ID (SID) <x
is the Replication-SID of all the Replication segments of a PTI, the LOC ref target="RFC8986" format="default"/> <xref target="RFC9524" format="default"/
portion of the SRv6 SID <xref target="RFC8986"/> differs for the Root >. Note that even if the Tree-SID
node, the intermediate Replication nodes and the Leaf nodes of the is the Replication-SID of all the Replication segments of a PTI, the locat
or (LOC)
portion of the SRv6 SID <xref target="RFC8986" format="default"/> differs
for the Root
node, the intermediate Replication nodes, and the Leaf nodes of the
PTI.</t> PTI.</t>
<t>An SR P2MP Policy has a Binding SID (BSID). The BSID is used to steer <t>An SR P2MP Policy has a Binding SID (BSID). The BSID is used to steer
traffic into an SR Policy, as described below, when the Root node is not traffic into an SR Policy, as described below, when the Root node is not
the ingress node of the SR domain where the traffic arrives. The packets the ingress node of the SR domain where the traffic arrives. The packets
are steered from the ingress node to the Root node using a segment list are steered from the ingress node to the Root node using a segment list
with the BSID as the last segment in the list. In this case, it is with the BSID as the last segment in the list. In this case, it is
RECOMMENDED that the BSID of an SR P2MP Policy SHOULD be constant <bcp14>RECOMMENDED</bcp14> that the BSID of an SR P2MP Policy <bcp14>SHOUL
throughout the lifetime of the Policy so the steering of traffic to the D</bcp14> be constant
Root node remains unchanged. The BSID of an SR P2MP Policy MAY be the throughout the lifetime of the policy so the steering of traffic to the
Tree-SID of the active P2MP instance of the active CP of the Policy. In Root node remains unchanged. The BSID of an SR P2MP Policy <bcp14>MAY</bcp
14> be the
Tree-SID of the active P2MP instance of the active CP of the policy. In
this case, the BSID of an SR P2MP Policy changes when the active CP or this case, the BSID of an SR P2MP Policy changes when the active CP or
the active PTI of the SR P2MP Policy changes. Note, the BSID is not the active PTI of the SR P2MP Policy changes. Note that the BSID is not
required to steer traffic into an SR P2MP Policy when the Root node of required to steer traffic into an SR P2MP Policy when the Root node of
an SR P2MP Policy is also the ingress node of the SR domain where the an SR P2MP Policy is also the ingress node of the SR domain where the
traffic arrives.</t> traffic arrives.</t>
<t>The Root node can steer an incoming packet into an SR P2MP Policy in <t>The Root node can steer an incoming packet into an SR P2MP Policy in
one of following methods:</t> one of following methods:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Local policy-based forwarding: The Root node maps the incoming <t>Local-policy-based forwarding: The Root node maps the incoming
packet to the active PTI of the active CP of an SR P2MP Policy based packet to the active PTI of the active CP of an SR P2MP Policy based
on local forwarding policy and it is replicated with the on local forwarding policy, and it is replicated with the
encapsulated Replication-SIDs of the downstream nodes. The encapsulated Replication-SIDs of the downstream nodes. The
procedures to map an incoming packet to an SR P2MP Policy are out of procedures to map an incoming packet to an SR P2MP Policy are out of
scope of this document. It is RECOMMENDED that an implementation scope of this document. It is <bcp14>RECOMMENDED</bcp14> that an imple mentation
provide a mechanism to examine the result of application of the provide a mechanism to examine the result of application of the
local forwarding policy i.e. provide information about the traffic local forwarding policy, i.e., provide information about the traffic
mapped to an SR P2MP Policy and the active CP and active PTI of the mapped to an SR P2MP Policy and the active CP and active PTI of the
Policy.</t> policy.</t>
</li>
<t>Tree-SID based forwarding: The Binding SID, which may be the <li>
<t>Tree-SID-based forwarding: The Binding SID, which may be the
Tree-SID of the active PTI, in an incoming packet is used to map the Tree-SID of the active PTI, in an incoming packet is used to map the
packet to the active PTI. The Binding SID in the incoming packet is packet to the active PTI. The Binding SID in the incoming packet is
replaced with the Tree-SID of the active PTI of active CPand the replaced with the Tree-SID of the active PTI of the active CP, and the
packet is replicated with the Replication-SIDs of the downstream packet is replicated with the Replication-SIDs of the downstream
nodes.</t> nodes.</t>
</list></t> </li>
</ul>
<t>For local policy-based forwarding with SR-MPLS, the TTL the Root node <t>For local-policy-based forwarding with SR-MPLS, the TTL for the Root no
SHOULD set the TTL in encapsulating MPLS header so that the replicated de
packet can reach the furthest Leaf node. The Root MAY set the TTL in <bcp14>SHOULD</bcp14> set the TTL in the encapsulating MPLS header so that
encapsulating MPLS header from the payload. In this case, the TTL may the replicated
packet can reach the furthest Leaf node. The Root <bcp14>MAY</bcp14> set t
he TTL in
the encapsulating MPLS header from the payload. In this case, the TTL may
not be sufficient for the replicated packet to reach the furthest node. not be sufficient for the replicated packet to reach the furthest node.
For SRv6, Section 2.2 of <xref target="RFC9524"/> provides guidance to For SRv6, <xref target="RFC9524" section="2.2" sectionFormat="of"/> provid es guidance to
set the IPv6 Hop Limit of the encapsulating IPv6 header.</t> set the IPv6 Hop Limit of the encapsulating IPv6 header.</t>
</section> </section>
<section anchor="P2MP_Tree" numbered="true" toc="default">
<section anchor="P2MP_Tree" title="P2MP tree instance"> <name>P2MP Tree Instance</name>
<t>A P2MP tree instance within an SR domain establishes a forwarding <t>A P2MP tree instance within an SR domain establishes a forwarding
structure that connects a Root node to a set of Leaf nodes via a series structure that connects a Root node to a set of Leaf nodes via a series
of intermediate Replication nodes. The tree consists of:</t> of intermediate Replication nodes. The tree consists of:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>A Replication segment at the Root node.</t> <t>A Replication segment at the Root node.</t>
</li>
<li>
<t>Zero or more Replication segments at intermediate Replication <t>Zero or more Replication segments at intermediate Replication
nodes.</t> nodes.</t>
</li>
<li>
<t>Replication segments at the Leaf nodes.</t> <t>Replication segments at the Leaf nodes.</t>
</list></t> </li>
</ul>
<section title="Replication segments at Leaf Nodes"> <section numbered="true" toc="default">
<name>Replication Segments at Leaf Nodes</name>
<t>A specific service is identified by a service context in a packet. <t>A specific service is identified by a service context in a packet.
A PTI is usually associated with one and only one multi-point service. A PTI is usually associated with one and only one multipoint service.
On a Leaf node of such a multi-point service, the transport identifier On a Leaf node of such a multipoint service, the transport identifier,
which is the Tree-SID or Replication-SID of the Replication segment at which is the Tree-SID or Replication-SID of the Replication segment at
a Leaf node is also associated with the service context because it is a Leaf node, is also associated with the service context because it is
not always feasible to separate the transport and service context with not always feasible to separate the transport and service context with
efficient replication in core since a) multi-point services may have efficient replication in core since a) multipoint services may have
differing sets of end-points, and b) downstream allocation of service differing sets of endpoints and b) downstream allocation of a service
context cannot be encoded in packets replicated in the core.</t> context cannot be encoded in packets replicated in the core.</t>
<t>A PTI can be associated with one or more multipoint services on
<t>A PTI can be associated with one or more multi-point services on
the Root and Leaf nodes. In SR-MPLS deployments, if it is known a the Root and Leaf nodes. In SR-MPLS deployments, if it is known a
priori that multi-point services mapped to an SR-MPLS PTI can be priori that multipoint services mapped to an SR-MPLS PTI can be
uniquely identified with their service label, a controller MAY opt not uniquely identified with their service label, a controller <bcp14>MAY</b
to instantiate Replication segments at Leaf nodes. In such cases, cp14> opt
to not instantiate Replication segments at Leaf nodes. In such cases,
Replication nodes upstream of the Leaf nodes can remove the Tree-SID Replication nodes upstream of the Leaf nodes can remove the Tree-SID
from the packet before forwarding it. A multi-point service context from the packet before forwarding it. A multipoint service context
allocated from an upstream assigned label or Domain-wide Common Block allocated from an upstream assigned label or Domain-wide Common Block
(DCB), as specified in <xref target="RFC9573"/>, is an example of a (DCB), as specified in <xref target="RFC9573" format="default"/>, is an example of a
globally unique context that facilitates this optimization.</t> globally unique context that facilitates this optimization.</t>
<t>In SRv6 deployments, Replication segments of a PTI MUST be <!--[rfced] FYI - To improve readability and avoid awkward hyphenation
instantiated on Leaf nodes of the tree since PHP like behavior is not of the expansion "PHP" when followed by "like", we updated
feasible because the Tree-SID is carried in IPv6 Destination Address this text as shown below.
field of outer IPv6 header. If two or more multi-point services are
Original:
In SRv6 deployments, Replication segments of a PTI MUST be
instantiated on Leaf nodes of the tree since PHP like behavior is not
feasible because the Tree-SID is carried in IPv6 Destination Address
field of outer IPv6 header.
Current:
In SRv6 deployments, Replication segments of a PTI MUST be
instantiated on Leaf nodes of the tree since behavior like Penultimate
Hop Popping (PHP) is not feasible because the Tree-SID is carried in IPv6
Destination Address field of outer IPv6 header.
-->
<t>In SRv6 deployments, Replication segments of a PTI <bcp14>MUST</bcp14
> be
instantiated on Leaf nodes of the tree since behavior like Penultimate H
op Popping (PHP) is not
feasible because the Tree-SID is carried in the IPv6 Destination Address
field of the outer IPv6 header. If two or more multipoint services are
mapped to one SRv6 PTI, an SRV6 SID representing the service context mapped to one SRv6 PTI, an SRV6 SID representing the service context
is assigned by the Root node or assigned from DCB. This SRv6 SID MUST is assigned by the Root node or assigned from the DCB. This SRv6 SID <bc p14>MUST</bcp14>
be encoded as the last segment in the Segment List of the Segment be encoded as the last segment in the Segment List of the Segment
Routing Header <xref target="RFC8754"/> by the Root node to derive the Routing Header <xref target="RFC8754" format="default"/> by the Root nod
packet processing context (PPC) for the service as described in e to derive the
Section 2.2 of <xref target="RFC9524"/> at a Leaf node.</t> packet processing context (PPC) for the service, as described in
<xref target="RFC9524" section="2.2" sectionFormat="of"/>, at a Leaf nod
e.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Shared Replication Segments</name>
<section title="Shared Replication segments"> <!--[rfced] We are having difficulty understanding how "to the common
<t>A Replication segment MAY be shared across different PTIs. One downstream node of these Replication segments" fits into this sentence.
Please review and let us know what updates may be made for clarity.
Original:
A shared Replication segment can protect
Replication segments of different PTIs against an adjacency or path
failure to the common downstream node of these Replication segments.
-->
<t>A Replication segment <bcp14>MAY</bcp14> be shared across different P
TIs. One
simple use of a shared Replication segment is for local protection on simple use of a shared Replication segment is for local protection on
a Replication node. A shared Replication segment can protect a Replication node. A shared Replication segment can protect
Replication segments of different PTIs against an adjacency or path Replication segments of different PTIs against an adjacency or path
failure to the common downstream node of these Replication failure to the common downstream node of these Replication
segments.</t> segments.</t>
<t>A shared Replication segment <bcp14>MUST</bcp14> be identified using
<t>A shared Replication segment MUST be identified using a Root set to a Root set to
zero (0.0.0.0 for IPv4 and :: for IPv6), Instance-ID set to zero and a zero (0.0.0.0 for IPv4 and :: for IPv6), an Instance-ID set to zero, and
Tree-ID that is unique within the context of the node where the a Tree-ID that is unique within the context of the node where the
Replication segment is instantiated. The Root is zero because a shared Replication segment is instantiated. The Root is zero because a shared
Replication segment is not associated with a particular SR P2MP Policy Replication segment is not associated with a particular SR P2MP Policy
or a PTI. Note, the shared Replication segment identifier conforms or a PTI. Note that the shared Replication segment identifier conforms
with the updated Replication-ID definition in <xref with the updated Replication-ID definition in <xref target="Candidate_Pa
target="Candidate_Path"/>.</t> th" format="default"/>.</t>
<t>It is possible for different PTIs to share a P2MP tree at a <t>It is possible for different PTIs to share a P2MP tree at a
Replication node. This allows a common sub-tree to be shared across Replication node. This allows a common sub-tree to be shared across
PTIs whose tree topologies are identical in some portion of a SR PTIs whose tree topologies are identical in some portion of an SR
domain. The procedures to share a P2MP tree across PTIs are outside domain. The procedures to share a P2MP tree across PTIs are outside
the scope of this document.</t> the scope of this document.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Packet forwarding in P2MP tree instance"> <name>Packet Forwarding in a P2MP Tree Instance</name>
<t>When a packet is steered into a PTI, the Replication segment at the <t>When a packet is steered into a PTI, the Replication segment at the
Root node performs packet replication and forwards copies to Root node performs packet replication and forwards copies to
downstream nodes.</t> downstream nodes.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Each replicated packet carries the Replication-SID of the <t>Each replicated packet carries the Replication-SID of the
Replication segment at the downstream node.</t> Replication segment at the downstream node.</t>
</li>
<t>A downstream node can be either: <list style="symbols"> <li>
<t>A downstream node can be either: </t>
<ul spacing="normal">
<li>
<t>A Leaf node, in which case the replication process <t>A Leaf node, in which case the replication process
terminates.</t> terminates, or</t>
</li>
<li>
<t>An intermediate Replication node, which further replicates <t>An intermediate Replication node, which further replicates
the packet through its associated Replication segments until the packet through its associated Replication segments until
it reaches all Leaf nodes.</t> it reaches all Leaf nodes.</t>
</list></t> </li>
</list></t> </ul>
</li>
</ul>
<!--[rfced] Is SRv6 replication intended for one downstream node or
multiple downstream nodes?
Original:
For details of SRv6 replication to non-adjacent downstream node and IPv6
Hop Limit considerations, refer to Section 2.2 of [RFC9524].
Perhaps A (singular):
For details of SRv6 replication to a non-adjacent downstream node and IPv6
Hop Limit considerations, refer to Section 2.2 of [RFC9524].
Perhaps B (plural):
For details of SRv6 replication to non-adjacent downstream nodes and IPv6
Hop Limit considerations, refer to Section 2.2 of [RFC9524].
-->
<t>A Replication node and a downstream node can be non-adjacent. In <t>A Replication node and a downstream node can be non-adjacent. In
this case the replicated packet has to traverse a path to reach the this case, the replicated packet has to traverse a path to reach the
downstream node. For SR-MPLS, this is achieved by inserting one or downstream node. For SR-MPLS, this is achieved by inserting one or
more SIDs before the downstream Replication SID. For SRv6, the LOC more SIDs before the downstream Replication-SID. For SRv6, the LOC
<xref target="RFC8986"/> of downstream Replication-SID can guide the <xref target="RFC8986" format="default"/> of the downstream Replication-
SID can guide the
packet to the downstream node or an optional segment list may be used packet to the downstream node or an optional segment list may be used
to steer the replicated packet on a specific path to the downstream to steer the replicated packet on a specific path to the downstream
node. For details of SRv6 replication to non-adjacent downstream node node. For details of SRv6 replication to non-adjacent downstream node
and IPv6 Hop Limit considerations, refer to Section 2.2 of <xref and IPv6 Hop Limit considerations, refer to <xref target="RFC9524" secti
target="RFC9524"/>.</t> on="2.2"/>.</t>
</section> </section>
</section> </section>
<section anchor="Controller" numbered="true" toc="default">
<section anchor="Controller" <name>Using a Controller to Build a P2MP Tree</name>
title="Using a controller to build a P2MP Tree"> <t>A controller is instantiated or provisioned with the SR P2MP Policy and
<t>A controller is instantiated or provisioned with SR P2MP Policy and
its candidate paths to compute and instantiate PTIs in an SR domain. The its candidate paths to compute and instantiate PTIs in an SR domain. The
procedures for provisioning or instantiation of these constructs on a procedures for provisioning or instantiation of these constructs on a
controller are outside the scope of this document.</t> controller are outside the scope of this document.</t>
<section numbered="true" toc="default">
<section title="SR P2MP Policy on a controller"> <name>SR P2MP Policy on a Controller</name>
<t>An SR P2MP Policy is provisioned on a controller by an entity which <t>An SR P2MP Policy is provisioned on a controller by an entity that
can be an operator, a network node or a machine, by specifying the can be an operator, a network node, or a machine by specifying the
addresses of the Root, the set of Leaf nodes and the candidate paths. addresses of the Root, the set of Leaf nodes, and the candidate paths.
In this case, the Policy and its CPs are instantiated on the Root node In this case, the policy and its CPs are instantiated on the Root node
using a signalling protocol. An SR P2MP Policy, its Leaf nodes and the using a signaling protocol. An SR P2MP Policy, its Leaf nodes, and the
CPs may also be provisioned on the Root node and then instantiated on CPs may also be provisioned on the Root node and then instantiated on
the controller using a signalling protocol. The procedures and the controller using a signaling protocol. The procedures and
mechanisms for provisioning and instantiate SR P2MP Policy and its CPS mechanisms for provisioning and instantiation of an SR P2MP Policy and i
ts CPS
on a controller or a Root node are outside the scope of this on a controller or a Root node are outside the scope of this
document.</t> document.</t>
<t>The possible set of constraints and optimization objective of a CP <t>The possible set of constraints and optimization objective of a CP
are described in Section 3 of <xref are described in <xref section="3" target="I-D.filsfils-spring-sr-policy
target="I-D.filsfils-spring-sr-policy-considerations"/>. Other -considerations" format="default"/>. Other
constraints and optimization objectives MAY be used for P2MP tree constraints and optimization objectives <bcp14>MAY</bcp14> be used for P
2MP tree
computation.</t> computation.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Controller Functions"> <name>Controller Functions</name>
<t>A controller performs the following functions in general:</t> <t>A controller performs the following functions in general:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Topology Discovery: A controller discovers network topology <t>Topology Discovery: A controller discovers network topology
across Interior Gateway Protocol (IGP) areas, levels or Autonomous across Interior Gateway Protocol (IGP) areas, levels, or Autonomous
Systems (ASes).</t> Systems (ASes).</t>
</li>
<li>
<!--[rfced] We note 80 instances of "SR P2MP Policy" but only two
instances of "SR P2MP". Are the two instances of "SR P2MP" okay as
is, or is an update needed for consistency?
Current:
* Capability Exchange: A controller discovers a node's capability to
participate in SR P2MP as well as advertise its capability to
support SR P2MP.
Perhaps:
* Capability Exchange: A controller discovers a node's capability to
participate in an SR P2MP Policy as well as advertise its capability
to support the SR P2MP Policy.
-->
<t>Capability Exchange: A controller discovers a node's capability <t>Capability Exchange: A controller discovers a node's capability
to participate in SR P2MP as well as advertise its capability to to participate in SR P2MP as well as advertise its capability to
support SR P2MP.</t> support SR P2MP.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="Tree_Compute" numbered="true" toc="default">
<section anchor="Tree_Compute" title="P2MP Tree Compute"> <name>P2MP Tree Compute</name>
<t>A controller computes one or more PTIs for CPs of an SR P2MP <t>A controller computes one or more PTIs for CPs of an SR P2MP
Policy. A CP may not have any PTI if a controller cannot compute a Policy. A CP may not have any PTIs if a controller cannot compute a
P2MP tree for it.</t> P2MP tree for it.</t>
<t>A controller <bcp14>MUST</bcp14> compute a P2MP tree such that there
<t>A controller MUST compute a P2MP tree such that there are no loops are no loops
in the tree at steady state as required by <xref in the tree at steady state as required by <xref target="RFC9524" format
target="RFC9524"/>.</t> ="default"/>.</t>
<t>A controller <bcp14>SHOULD</bcp14> modify a PTI of a candidate path o
<t>A controller SHOULD modify a PTI of a candidate path on detecting a n detecting a
change in the network topology, if the change affects the tree change in the network topology if the change affects the tree
instance, or when a better path can be found based on the new network instance or when a better path can be found based on the new network
state. Alternatively, the controller MAY decide implement a state. Alternatively, the controller <bcp14>MAY</bcp14> decide to implem
ent a
Make-Before-Break approach to minimize traffic loss. The controller Make-Before-Break approach to minimize traffic loss. The controller
can do this by creating a new PTI, activating the new instance once it can do this by creating a new PTI, activating the new instance once it
is instantiated in the network, and then removing the old PTI.</t> is instantiated in the network, and then removing the old PTI.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="SID Management"> <name>SID Management</name>
<t>The controller assigns the Replication-SIDs for the Replication <t>The controller assigns the Replication-SIDs for the Replication
segments of the PTI.</t> segments of the PTI.</t>
<t>The Replication-SIDs of a PTI of a CP of an SR P2MP Policy can be <t>The Replication-SIDs of a PTI of a CP of an SR P2MP Policy can be
either dynamically assigned by the controller or statically assigned either dynamically assigned by the controller or statically assigned
by entity provisioning the SR P2MP Policy.</t> by the entity provisioning the SR P2MP Policy.</t>
<!--[rfced] We are having difficulty parsing "globally significant the
SR domain any it may get depleted if significant number of PTIs" in the
sentence below. Please review and let us know how this text may be updated
for clarity.
Original:
It is NOT RECOMMENDED to allocate a Replication-SID from the SRBG
since this block is globally significant the SR domain any it may
get depleted if significant number of PTIs are instantiated in the
SR domain.
Perhaps:
It is NOT RECOMMENDED to allocate a Replication-SID from the SRGB
since this block is globally significant to the SR domain and it
may get depleted if a significant number of PTIs are instantiated
in the SR domain.
-->
<t>For SR-MPLS, a Replication-SID may be assigned from the SR Local <t>For SR-MPLS, a Replication-SID may be assigned from the SR Local
Block (SRLB) or the SR Global Block (SRGB) <xref target="RFC8402"/>. Block (SRLB) or the SR Global Block (SRGB) <xref target="RFC8402" format
It is RECOMMENDED to assign a Replication-SID from the SRLB since ="default"/>.
Replication segments are local to each node of the PTI. It is NOT It is <bcp14>RECOMMENDED</bcp14> to assign a Replication-SID from the SR
RECOMMENDED to allocate a Replication-SID from the SRBG since this LB since
Replication segments are local to each node of the PTI. It is <bcp14>NOT
RECOMMENDED</bcp14> to allocate a Replication-SID from the SRGB since th
is
block is globally significant the SR domain any it may get depleted if block is globally significant the SR domain any it may get depleted if
significant number of PTIs are instantiated in the SR domain.</t> significant number of PTIs are instantiated in the SR domain.</t>
<t><xref target="Steering" format="default"/> recommends that the Tree-S
<t><xref target="Steering"/> recommends the Tree-SID to be used as the ID be used as the
Replication-SIDs for all the Replication segments of a PTI. It may be Replication-SIDs for all the Replication segments of a PTI. It may be
feasible to allocate the same Tree-SID value for all the Replication feasible to allocate the same Tree-SID value for all the Replication
segments if the blocks used for allocation are not identical on all segments if the blocks used for allocation are not identical on all
the nodes of the PTI, or if the particular Tree-SID value in the block the nodes of the PTI or if the particular Tree-SID value in the block
is assigned to some other SID on some node.</t> is assigned to some other SID on some node.</t>
<t>A BSID is also assigned for the SR P2MP Policy. The controller <bcp14
<t>A BSID is also assigned for the SR P2MP Policy. The controller MAY >MAY</bcp14>
decide to not assign a BSID and allow the Root node of the SR P2MP decide to not assign a BSID and allow the Root node of the SR P2MP
Policy to assign the BSID. It is RECOMMENDED to assign the BSID of an Policy to assign the BSID. It is <bcp14>RECOMMENDED</bcp14> to assign th e BSID of an
SR P2MP Policy from the SRLB for SR-MPLS.</t> SR P2MP Policy from the SRLB for SR-MPLS.</t>
<t>The controller <bcp14>MAY</bcp14> be provisioned with a reserved bloc
<t>The controller MAY be provisioned with a reserved block or multiple k or multiple
reserved blocks for assigning Replication-SIDs and/or the BSIDs for SR reserved blocks for assigning Replication-SIDs and/or the BSIDs for SR
P2MP Policies. a A single block maybe be reserved for the whole SR P2MP Policies. A single block maybe be reserved for the whole SR
domain, or dedicated blocks can be reserved for each node or a group domain, or dedicated blocks can be reserved for each node or a group
of nodes in the SR domain. These blocks MAY overlap with either the of nodes in the SR domain. These blocks <bcp14>MAY</bcp14> overlap with
SRBG, SRLB or both. The procedures for provisioning these reserved either
the SRGB, the SRLB, or both. The procedures for provisioning these reser
ved
blocks and procedures for deconflicting assignments from these blocks and procedures for deconflicting assignments from these
reserved blocks with overlapping SRLB or SRGB blocks are outside the reserved blocks with overlapping SRLB or SRGB blocks are outside the
scope of this document.</t> scope of this document.</t>
<t>A controller may not be aware of all the assignments of SIDs from <t>A controller may not be aware of all the assignments of SIDs from
the SRGB or the SRLB of the SR domain. If reserved blocks are not the SRGB or the SRLB of the SR domain. If reserved blocks are not
used, the assignment of Replication-SIDs or BSIDs of SR P2MP Policies used, the assignment of Replication-SIDs or BSIDs of SR P2MP Policies
from these blocks may conflict with other SIDs.</t> from these blocks may conflict with other SIDs.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Instantiating P2MP tree instance on nodes"> <name>Instantiating P2MP Tree Instance on Nodes</name>
<t>After computing P2MP trees, the controller instantiates the <t>After computing P2MP trees, the controller instantiates the
Replication segments that compose the PTIs in the SR domain using Replication segments that compose the PTIs in the SR domain using
signalling protocols such as PCEP <xref signaling protocols such as the Path Computation Element Communication P
target="I-D.ietf-pce-sr-p2mp-policy"/>, BGP <xref rotocol (PCEP) <xref target="I-D.ietf-pce-sr-p2mp-policy" format="default"/>, BG
target="I-D.ietf-idr-sr-p2mp-policy"/> or other mechanisms such as P <xref target="I-D.ietf-idr-sr-p2mp-policy" format="default"/>, or other mechan
NETCONF/YANG <xref target="I-D.hb-spring-sr-p2mp-policy-yang"/> , etc. isms such as
NETCONF/YANG <xref target="I-D.hb-spring-sr-p2mp-policy-yang" format="de
fault"/>, etc.
The procedures for the instantiation of the Replication segments in an The procedures for the instantiation of the Replication segments in an
SR domain are outside the scope of this document.</t> SR domain are outside the scope of this document.</t>
<t>A node <bcp14>SHOULD</bcp14> report a successful instantiation of a R
<t>A node SHOULD report a successful instantiation of a Replication eplication
segment. The exact procedure for reporting this is outside the scope segment. The exact procedure for reporting this is outside the scope
of this document.</t> of this document.</t>
<t>The instantiation of a Replication segment on a node may fail,
<t>The instantiation of a Replication segment on a node may fail, for e.g., when the Replication-SID conflicts with another SID on the node.
e.g. when the Replication SID conflicts with another SID on the node. The node <bcp14>SHOULD</bcp14> report this, preferably with a reason for
The node SHOULD report this, preferably with a reason for the failure, the failure,
using a signalling protocol. The exact procedure for reporting this using a signaling protocol. The exact procedure for reporting this
failure is outside the scope of this document.</t> failure is outside the scope of this document.</t>
<t>If the instantiation of a Replication segment on a node fails, the <t>If the instantiation of a Replication segment on a node fails, the
controller SHOULD attempt to re-instantiate the Replication segment. controller <bcp14>SHOULD</bcp14> attempt to re-instantiate the Replicati
There SHOULD be an upper bound on the number of attempts. If the on segment.
instantiation of Replication segment ultimately fails after the There <bcp14>SHOULD</bcp14> be an upper bound on the number of attempts.
allowed number of attempts, the controller SHOULD generate an alert If the
via mechanisms like syslog. These alerts SHOULD be rate-limited to instantiation of a Replication segment ultimately fails after the
allowed number of attempts, the controller <bcp14>SHOULD</bcp14> generat
e an alert
via mechanisms like syslog. These alerts <bcp14>SHOULD</bcp14> be rate-l
imited to
protect the logging facility in case Replication segment instantiation protect the logging facility in case Replication segment instantiation
fails on multiple nodes. The controller MAY decide to tear down the fails on multiple nodes. The controller <bcp14>MAY</bcp14> decide to tea r down the
PTI if the instantiations of some of the Replication segments of the PTI if the instantiations of some of the Replication segments of the
instance fail. The controller is RECOMMENDED to tear down the PTI if instance fail. The controller is <bcp14>RECOMMENDED</bcp14> to tear down the PTI if
the instantiation of the Replication segment on the Root node fails. the instantiation of the Replication segment on the Root node fails.
The controller can employ different strategies to re-try instantiating The controller can employ different strategies to retry instantiating
a PTI after a failure. These are out of scope of this document.</t> a PTI after a failure. These are out of scope of this document.</t>
<t>A PTI should be instantiated within a reasonable time, especially if
<t>A PTI should be instantiated within a reasonable time especially if it is the active PTI of an SR P2MP Policy. One approach is the
it is the active PTI of a SR P2MP Policy. One approach is the
controller instantiates the Replication segments in a batch. For controller instantiates the Replication segments in a batch. For
example, the controller instantiates the Replication segments of the example, the controller instantiates the Replication segments of the
Leaf nodes and the intermediate Replication nodes first. If all of Leaf nodes and the intermediate Replication nodes first. If all of
these Replication segments are successfully instantiated, the these Replication segments are successfully instantiated, the
controller next proceeds to instantiate the Replication segment at the controller then proceeds to instantiate the Replication segment at the
Root node. If the Replication segment instantiation at the Root node Root node. If the Replication segment instantiation at the Root node
succeeds, the controller can immediately activate the instance if it succeeds, the controller can immediately activate the instance if it
needs to carry traffic of the SR P2MP Policy. A controller can adopt a needs to carry traffic of the SR P2MP Policy. A controller can adopt a
similar approach when instantiating the new PTI for Make-Before-Break similar approach when instantiating the new PTI for the Make-Before-Brea k
procedure.</t> procedure.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Protection"> <name>Protection</name>
<section title="Local Protection"> <section numbered="true" toc="default">
<t>A network link, node or replication branch on a PTI can be <name>Local Protection</name>
protected using SR Policies <xref target="RFC9256"/>. The backup SR <t>A network link, node, or replication branch on a PTI can be
protected using SR Policies <xref target="RFC9256" format="default"/>.
The backup SR
Policies are associated with replication branches of a Replication Policies are associated with replication branches of a Replication
segment, and are programmed in the data plane in order to minimize segment and are programmed in the data plane in order to minimize
traffic loss when the protected link/node fails. The segment list of traffic loss when the protected link/node fails. The segment list of
the backup SR policy is imposed on the downstream Replication SID of the backup SR Policy is imposed on the downstream Replication-SID of
a replication branch to steer the traffic on the backup path.</t> a replication branch to steer the traffic on the backup path.</t>
<t>It is also possible to use a node local Loop-Free Alternate <xref t
<t>It is also possible to use node local Loop-Free Alternate <xref arget="RFC5286" format="default"/> or Topology Independent Loop-Free Alternate (
target="RFC5286"/> or TI-LFA <xref TI-LFA) <xref target="RFC9855" format="default"/> protection and
target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/> protection and a Micro-Loop <xref target="RFC5715" format="default"/> or SR Micro-Loo
Micro-Loop <xref target="RFC5715"/> or SR Micro-Loop <xref p <xref target="I-D.bashandy-rtgwg-segment-routing-uloop" format="default"/> pre
target="I-D.bashandy-rtgwg-segment-routing-uloop"/> prevention vention
mechanisms to protect link/nodes of a PTI.</t> mechanism to protect the links/nodes of a PTI.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Path Protection"> <name>Path Protection</name>
<t>A controller can create a disjoint backup tree instance for <t>A controller can create a disjoint backup tree instance for
providing end-to-end tree protection if the topology permits. This providing end-to-end tree protection if the topology permits. This
can be achieved by having a backup CP with constraints and/or can be achieved by having a backup CP with constraints and/or
optimization objectives that ensure its PTIs are disjoint from the optimization objectives that ensure its PTIs are disjoint from the
PTIs of the primary/active CP.</t> PTIs of the primary/active CP.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document makes no request of IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<!--[rfced] To improve readability, may we update the second sentence as follows
?
Original:
Some security
considerations for Replication segments outlined in [RFC9524] are
also applicable to this document. Following is a brief reminder of
the same.
Perhaps:
Some security
considerations for Replication segments outlined in [RFC9524] are
also applicable to this document. Following is a brief reminder of
those security considerations.
-->
<section anchor="Security" title="Security Considerations">
<t>This document describes how a PTI can be created in an SR domain by <t>This document describes how a PTI can be created in an SR domain by
stitching Replication segments together. Some security considerations stitching Replication segments together. Some security considerations
for Replication segments outlined in <xref target="RFC9524"/> are also for Replication segments outlined in <xref target="RFC9524" format="defaul t"/> are also
applicable to this document. Following is a brief reminder of the applicable to this document. Following is a brief reminder of the
same.</t> same.</t>
<t>An SR domain needs protection from outside attackers as described in <t>An SR domain needs protection from outside attackers as described in
<xref target="RFC8402"/> <xref target="RFC8754"/> and <xref <xref target="RFC8402" format="default"/>, <xref target="RFC8754" format="
target="RFC8986"/> .</t> default"/>, and <xref target="RFC8986" format="default"/>.</t>
<t>Failure to protect the SR MPLS domain by correctly provisioning MPLS <t>Failure to protect the SR MPLS domain by correctly provisioning MPLS
support per interface permits attackers from outside the domain to send support per interface permits attackers from outside the domain to send
packets to receivers of the Multi-point services that use the SR P2MP packets to receivers of the multipoint services that use the SR P2MP
Policies provisioned within the domain.</t> Policies provisioned within the domain.</t>
<!--[rfced] FYI - We have updated "to implement BCP 38 [RFC2827]" as
shown below for clarity. Please review and let us know of any
objections.
Original:
Failure to protect the SRv6 domain with inbound Infrastructure Access
Control Lists (IACLs) on external interfaces, combined with failure
to implement BCP 38 [RFC2827] or apply IACLs on nodes provisioning
SIDs, permits attackers from outside the SR domain to send packets to
the receivers of Multi-point services that use the SR P2MP Policies
provisioned within the domain.
Current:
Failure to protect the SRv6 domain with inbound Infrastructure Access
Control Lists (IACLs) on external interfaces, combined with failure
to implement the method described in RFC2827 [BCP38] or apply IACLs on
nodes provisioning SIDs, permits attackers from outside the SR domain to
send packets to the receivers of multipoint services that use the SR P2MP
Policies provisioned within the domain.
-->
<t>Failure to protect the SRv6 domain with inbound Infrastructure Access <t>Failure to protect the SRv6 domain with inbound Infrastructure Access
Control Lists (IACLs) on external interfaces, combined with failure to Control Lists (IACLs) on external interfaces, combined with failure to
implement BCP 38 <xref target="RFC2827"/> or apply IACLs on nodes implement the method described in RFC 2827 <xref target="BCP38" format="de fault"/> or apply IACLs on nodes
provisioning SIDs, permits attackers from outside the SR domain to send provisioning SIDs, permits attackers from outside the SR domain to send
packets to the receivers of Multi-point services that use the SR P2MP packets to the receivers of multipoint services that use the SR P2MP
Policies provisioned within the domain.</t> Policies provisioned within the domain.</t>
<t>Incorrect provisioning of Replication segments by a controller that <t>Incorrect provisioning of Replication segments by a controller that
computes SR PTI can result in a chain of Replication segments forming a computes SR PTI can result in a chain of Replication segments forming a
loop. In this case, replicated packets can create a storm till MPLS TTL loop. In this case, replicated packets can create a storm until MPLS TTL
(for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero.</t> (for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero.</t>
<t>The control plane protocols (like PCEP, BGP, etc.) used to <t>The control plane protocols (like PCEP, BGP, etc.) used to
instantiate Replication segments of SR PTI can leverage their own instantiate Replication segments of SR PTI can leverage their own
security mechanisms such as encryption, authentication filtering security mechanisms such as encryption, authentication filtering,
etc.</t> etc.</t>
<t>For SRv6, <xref target="RFC9524"/> describes an exception for <!--[rfced] To reflect the text in RFC 9524, may we update this sentence
Parameter Problem Message, code 2 ICMPv6 Error messages. If an attacker as follows?
is able to inject a packet into Multi-point service 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.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to acknowledge Siva Sivabalan, Mike Koldychev
and Vishnu Pavan Beeram for their valuable inputs.</t>
</section>
<section title="Contributors">
<t>Clayton Hassen <vspace blankLines="0"/> Bell Canada <vspace
blankLines="0"/> Vancouver <vspace blankLines="0"/> Canada</t>
<t>Email: clayton.hassen@bell.ca</t>
<t>Kurtis Gillis <vspace blankLines="0"/> Bell Canada <vspace
blankLines="0"/> Halifax <vspace blankLines="0"/> Canada</t>
<t>Email: kurtis.gillis@bell.ca</t>
<t>Arvind Venkateswaran <vspace blankLines="0"/> Cisco Systems, Inc.
<vspace blankLines="0"/> San Jose <vspace blankLines="0"/> US</t>
<t>Email: arvvenka@cisco.com</t>
<t>Zafar Ali <vspace blankLines="0"/> Cisco Systems, Inc. <vspace
blankLines="0"/> US</t>
<t>Email: zali@cisco.com</t>
<t>Swadesh Agrawal <vspace blankLines="0"/> Cisco Systems, Inc. <vspace
blankLines="0"/> San Jose <vspace blankLines="0"/> US</t>
<t>Email: swaagraw@cisco.com</t>
<t>Jayant Kotalwar <vspace blankLines="0"/> Nokia <vspace
blankLines="0"/> Mountain View <vspace blankLines="0"/> US</t>
<t>Email: jayant.kotalwar@nokia.com</t>
<t>Tanmoy Kundu <vspace blankLines="0"/> Nokia <vspace blankLines="0"/>
Mountain View <vspace blankLines="0"/> US</t>
<t>Email: tanmoy.kundu@nokia.com</t>
<t>Andrew Stone <vspace blankLines="0"/> Nokia <vspace blankLines="0"/>
Ottawa <vspace blankLines="0"/> Canada</t>
<t>Email: andrew.stone@nokia.com</t>
<t>Tarek Saad <vspace blankLines="0"/> Juniper Networks <vspace
blankLines="0"/> Canada</t>
<t>Email:tsaad@juniper.net</t>
<t>Kamran Raza <vspace blankLines="0"/> Cisco Systems, Inc. <vspace
blankLines="0"/> Canada</t>
<t>Email:skraza@cisco.com</t>
<t>Anuj Budhiraja <vspace blankLines="0"/> Cisco Systems, Inc. <vspace
blankLines="0"/> US</t>
<t>Email:abudhira@cisco.com</t> Original:
For SRv6, [RFC9524] describes an exception for Parameter Problem
Message, code 2 ICMPv6 Error messages.
<t>Mankamana Mishra <vspace blankLines="0"/> Cisco Systems, Inc. <vspace Perhaps:
blankLines="0"/> US</t> For SRv6, [RFC9524] describes an exception for the ICMPv6 Parameter Problem
message with Code 2.
-->
<t>Email:mankamis@cisco.com</t> <t>For SRv6, <xref target="RFC9524" format="default"/> describes an except
ion for
Parameter Problem message, code 2 ICMPv6 Error messages. If an attacker
is able to inject a packet into a multipoint service with the source addre
ss
of a node and with an extension header using an 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.</t>
</section> </section>
</middle>
</middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-pce-sr-p2mp-policy" to="SR-P2MP-PING"/>
<?rfc include="reference.RFC.2119"?> <displayreference target="I-D.ietf-idr-sr-p2mp-policy" to="P2MP-BGP"/>
<displayreference target="I-D.hb-spring-sr-p2mp-policy-yang" to="SR-P2MP-YAN
<?rfc include="reference.RFC.8174"?> G"/>
<displayreference target="I-D.filsfils-spring-sr-policy-considerations" to="
<?rfc include='reference.RFC.8402'?> SR-POLICY"/>
<displayreference target="I-D.bashandy-rtgwg-segment-routing-uloop" to="SR-L
<?rfc include='reference.RFC.9524'?> OOP"/>
<references>
<?rfc include='reference.RFC.9256'?> <name>References</name>
</references> <references>
<name>Normative References</name>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.4655'?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.5286'?> 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.5715'?> 402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<?rfc include='reference.RFC.9573'?> 524.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<?rfc include='reference.RFC.8660'?> 256.xml"/>
</references>
<?rfc include='reference.RFC.8986'?> <references>
<name>Informative References</name>
<?rfc include='reference.RFC.8754'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
655.xml"/>
<?rfc include='reference.RFC.2827'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
286.xml"/>
<?rfc include='reference.I-D.ietf-pce-sr-p2mp-policy'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
715.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
573.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
660.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
38.xml"/>
<!-- [I-D.ietf-pce-sr-p2mp-policy]
draft-ietf-pce-sr-p2mp-policy-14
IESG State: I-D Exists as of 04/16/26
* Note this draft is also part of C556 *
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-pce-sr-p2mp-policy.xml"/>
<?rfc include='reference.I-D.ietf-idr-sr-p2mp-policy'?> <!-- [I-D.ietf-idr-sr-p2mp-policy]
draft-ietf-idr-sr-p2mp-policy-00
IESG State: Expired as of 04/16/26
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-idr-sr-p2mp-policy.xml"/>
<?rfc include='reference.I-D.hb-spring-sr-p2mp-policy-yang'?> <!-- [I-D.hb-spring-sr-p2mp-policy-yang]
draft-hb-spring-sr-p2mp-policy-yang-02
IESG State: Expired as of 04/16/26
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
hb-spring-sr-p2mp-policy-yang.xml"/>
<?rfc include='reference.I-D.filsfils-spring-sr-policy-considerations'?> <!-- [I-D.filsfils-spring-sr-policy-considerations]
draft-filsfils-spring-sr-policy-considerations-09
IESG State: Expired as of 04/16/26
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
filsfils-spring-sr-policy-considerations.xml"/>
<?rfc include='reference.I-D.ietf-rtgwg-segment-routing-ti-lfa'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 855.xml"/>
<?rfc include='reference.I-D.bashandy-rtgwg-segment-routing-uloop'?> <!-- [I-D.bashandy-rtgwg-segment-routing-uloop]
draft-bashandy-rtgwg-segment-routing-uloop-17
IESG State: Expired as of 04/16/26
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
bashandy-rtgwg-segment-routing-uloop.xml"/>
</references>
</references> </references>
<section numbered="true" toc="default">
<section title="Illustration of SR P2MP Policy and P2MP Tree"> <name>Illustration of the SR P2MP Policy and P2MP Tree</name>
<t>Consider the following topology:</t> <t>Consider the following topology:</t>
<figure align="center" title="SR Toplogy"> <figure>
<artwork name="SR_Topology" type="ascii-art"><![CDATA[ <name>SR Topology</name>
R3------R6 <artwork name="SR_Topology" align="center" alt=""><![CDATA[
Controller--/ \ R3------R6
R1----R2----R5-----R7 Controller--/ \
\ / R1----R2----R5-----R7
+--R4---+ \ /
]]></artwork> +--R4---+]]></artwork>
</figure> </figure>
<t>In these examples, the Node-SID of a node Rn is N-SIDn and <t>In these examples, the Node-SID of a node Rn is N-SIDn and
Adjacency-SID from node Rm to node Rn is A-SIDmn. Interface between Rm the Adjacency-SID from node Rm to node Rn is A-SIDmn. The interface betwee n Rm
and Rn is Lmn.</t> and Rn is Lmn.</t>
<t>For SRv6, the reader is expected to be familiar with SRv6 Network <t>For SRv6, the reader is expected to be familiar with SRv6 Network
Programming <xref target="RFC8986"/> to follow the examples.</t> Programming <xref target="RFC8986" format="default"/> to follow the exampl
es.</t>
<t><list style="symbols"> <ul spacing="normal">
<t>2001:db8::/32 is an IPv6 block allocated by a RIR to the <li>
operator</t> <t>2001:db8::/32 is an IPv6 block allocated by a Regional Internet Reg
istry (RIR) to the
<t>2001:db8:0::/48 is dedicated to the internal address space</t> operator.</t>
</li>
<li>
<t>2001:db8:0::/48 is dedicated to the internal address space.</t>
</li>
<li>
<t>2001:db8:cccc::/48 is dedicated to the internal SRv6 SID <t>2001:db8:cccc::/48 is dedicated to the internal SRv6 SID
space</t> space.</t>
</li>
<t>We assume a location expressed in 64 bits and a function <li>
expressed in 16 bits</t> <t>We assume a location is expressed in 64 bits and a function is
expressed in 16 bits.</t>
<t>node k has a classic IPv6 loopback address 2001:db8::k/128 which </li>
is advertised in the IGP</t> <li>
<t>Node k has a classic IPv6 loopback address 2001:db8::k/128, which
<t>node k has 2001:db8:cccc:k::/64 for its local SID space. Its SIDs is advertised in the IGP.</t>
will be explicitly assigned from that block</t> </li>
<li>
<t>node k advertises 2001:db8:cccc:k::/64 in its IGP</t> <t>Node k has 2001:db8:cccc:k::/64 for its local SID space. Its SIDs
will be explicitly assigned from that block.</t>
</li>
<li>
<t>Node k advertises 2001:db8:cccc:k::/64 in its IGP.</t>
</li>
<li>
<t>Function :1:: (function 1, for short) represents the End function <t>Function :1:: (function 1, for short) represents the End function
with Penultimate Segment Pop (PSP) support</t> with Penultimate Segment Pop (PSP) support.</t>
</li>
<li>
<t>Function :Cn:: (function Cn, for short) represents the End.X <t>Function :Cn:: (function Cn, for short) represents the End.X
function to node n</t> function to node n.</t>
</li>
<li>
<t>Function :C1n: (function C1n for short) represents the End.X <t>Function :C1n: (function C1n for short) represents the End.X
function to node n with Ultimate Segment Decapsulation (USD)</t> function to node n with Ultimate Segment Decapsulation (USD).</t>
</list></t> </li>
</ul>
<t>Each node k has: <list style="symbols"> <t>Each node k has: </t>
<ul spacing="normal">
<li>
<t>An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an <t>An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an
End function with additional support for PSP</t> End function with additional support for PSP</t>
</li>
<li>
<t>An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to <t>An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to
an End.X function to neighbor J with additional support for PSP</t> an End.X function to neighbor J with additional support for PSP</t>
</li>
<li>
<t>An explicit SID instantiation 2001:db8:cccc:k:C1j::/128 bound to <t>An explicit SID instantiation 2001:db8:cccc:k:C1j::/128 bound to
an End.X function to neighbor J with additional support for USD</t> an End.X function to neighbor J with additional support for USD</t>
</list></t> </li>
</ul>
<t>Assume a controller is provisioned with following SR P2MP Policy at <t>Assume a controller is provisioned with the following SR P2MP Policy at
Root R1 with Tree-ID T-ID:</t> Root R1 with Tree-ID T-ID:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> SR P2MP Policy <R1,T-ID>:
<artwork><![CDATA[SR P2MP Policy <R1,T-ID>:
Leaf nodes: {R2, R6, R7} Leaf nodes: {R2, R6, R7}
candidate-path 1: candidate-path 1:
Optimize: IGP metric Optimize: IGP metric
Tree-SID: T-SID1 Tree-SID: T-SID1
]]></artwork> ]]></artwork>
</figure>
<t>The controller is responsible for computing a PTI of the candidate <t>The controller is responsible for computing a PTI of the candidate
path. In this example, we assume one active PTI with Instance-ID I-ID1. path. In this example, we assume one active PTI with Instance-ID I-ID1.
Assume the controller instantiates PTIs by signalling Replication Assume the controller instantiates PTIs by signaling Replication
segments i.e. Replication-ID of these Replication segments is &lt;Root, segments, i.e., the Replication-ID of these Replication segments is &lt;Ro
ot,
Tree-ID, Instance-ID&gt;. All Replication segments use the Tree-SID Tree-ID, Instance-ID&gt;. All Replication segments use the Tree-SID
T-SID1 as Replication-SID. For SRv6, assume the Replication-SID at node T-SID1 as the Replication-SID. For SRv6, assume the Replication-SID at nod e
k, bound to an End.Replicate function, is 2001:db8:cccc:k:fa::/128.</t> k, bound to an End.Replicate function, is 2001:db8:cccc:k:fa::/128.</t>
<section numbered="true" toc="default">
<section title="P2MP Tree with non-adjacent Replication Segments"> <name>P2MP Tree with Non-Adjacent Replication Segments</name>
<t>Assume the controller computes a PTI with Root node R1, <t>Assume the controller computes a PTI with Root node R1,
Intermediate and Leaf node R2, and Leaf nodes R6 and R7. The Intermediate and Leaf node R2, and Leaf nodes R6 and R7. The
controller instantiates the instance by stitching Replication segments controller instantiates the instance by stitching Replication segments
at R1, R2, R6 and R7. Replication segment at R1 replicates to R2. at R1, R2, R6, and R7. The Replication segment at R1 replicates to R2.
Replication segment at R2 replicates to R6 and R7. Note nodes R3, R4 The Replication segment at R2 replicates to R6 and R7. Note that nodes R
3, R4,
and R5 do not have any Replication segment state for the tree.</t> and R5 do not have any Replication segment state for the tree.</t>
<section numbered="true" toc="default">
<section title="SR-MPLS"> <name>SR-MPLS</name>
<t>The Replication segment state at nodes R1, R2, R6 and R7 is shown <t>The Replication segment state at nodes R1, R2, R6, and R7 is shown
below.</t> below.</t>
<t>Replication segment at R1:</t> <t>Replication segment at R1:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R1>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: T-SID1 Replication-SID: T-SID1
Replication State: Replication State:
R2: <T-SID1->L12> R2: <T-SID1->L12>]]></artwork>
]]></artwork>
</figure>
<t>Replication to R2 steers a packet directly to the node on <t>Replication to R2 steers a packet directly to the node on
interface L12.</t> interface L12.</t>
<t>Replication segment at R2:</t> <t>Replication segment at R2:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R2>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: T-SID1 Replication-SID: T-SID1
Replication State: Replication State:
R2: <Leaf> R2: <Leaf>
R6: <N-SID6, T-SID1> R6: <N-SID6, T-SID1>
R7: <N-SID7, T-SID1>]]></artwork> R7: <N-SID7, T-SID1>]]></artwork>
</figure> <t>R2 is a Bud node. It performs the role of a Leaf as well as a trans
it
<t>R2 is a Bud node. It performs role of Leaf as well as a transit
node replicating to R6 and R7. Replication to R6, using N-SID6, node replicating to R6 and R7. Replication to R6, using N-SID6,
steers a packet via IGP shortest path to that node. Replication to steers a packet via IGP shortest path to that node. Replication to
R7, using N-SID7, steers a packet via IGP shortest path to R7 via R7, using N-SID7, steers a packet via IGP shortest path to R7 via
either R5 or R4 based on ECMP hashing.</t> either R5 or R4 based on ECMP hashing.</t>
<t>Replication segment at R6:</t> <t>Replication segment at R6:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R6>: Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: T-SID1 Replication-SID: T-SID1
Replication State: Replication State:
R6: <Leaf>]]></artwork> R6: <Leaf>]]></artwork>
</figure>
<t>Replication segment at R7:</t> <t keepWithNext="true">Replication segment at R7:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R7>: Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: T-SID1 Replication-SID: T-SID1
Replication State: Replication State:
R7: <Leaf>]]></artwork> R7: <Leaf>]]></artwork>
</figure>
<t>When a packet is steered into the active instance candidate path <t>When a packet is steered into the active instance candidate path
1 of SR P2MP Policy at R1:</t> 1 of the SR P2MP Policy at R1:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Since R1 is directly connected to R2, R1 performs PUSH <t>Since R1 is directly connected to R2, R1 performs the PUSH
operation with just &lt;T-SID1&gt; label for the replicated copy operation with just the &lt;T-SID1&gt; label for the replicated co
py
and sends it to R2 on interface L12.</t> and sends it to R2 on interface L12.</t>
</li>
<li>
<t>R2, as Leaf, performs NEXT operation, pops T-SID1 label and <!--[rfced] We are having difficulty understanding "one of IGP ECMP
nexthops towards R7". How should this text be clarified?
Original:
For replication to R7, R2 performs a PUSH operation of N-SID7, to
send <N-SID7,T-SID1> label stack to R4, one of IGP ECMP nexthops
towards R7.
Perhaps:
For replication to R7, R2 performs a PUSH operation of N-SID7 to
send the <N-SID7,T-SID1> label stack to R4, which is an IGP ECMP
next hop towards R7.
-->
<t>R2, as a Leaf, performs the NEXT operation, pops the T-SID1 lab
el, and
delivers the payload. For replication to R6, R2 performs a PUSH delivers the payload. For replication to R6, R2 performs a PUSH
operation of N-SID6, to send &lt;N-SID6,T-SID1&gt; label stack operation of N-SID6 to send the &lt;N-SID6,T-SID1&gt; label stack
to R3. R3 is the penultimate hop for N-SID6; it performs to R3. R3 is the penultimate hop for N-SID6; it performs
penultimate hop popping, which corresponds to the NEXT operation penultimate hop popping, which corresponds to the NEXT operation,
and the packet is then sent to R6 with &lt;T-SID1&gt; in the and the packet is then sent to R6 with &lt;T-SID1&gt; in the
label stack. For replication to R7, R2 performs a PUSH operation label stack. For replication to R7, R2 performs a PUSH operation
of N-SID7, to send &lt;N-SID7,T-SID1&gt; label stack to R4, one of N-SID7 to send the &lt;N-SID7,T-SID1&gt; label stack to R4, one
of IGP ECMP nexthops towards R7. R4 is the penultimate hop for of IGP ECMP nexthops towards R7. R4 is the penultimate hop for
N-SID7; it performs penultimate hop popping, which corresponds N-SID7; it performs penultimate hop popping, which corresponds
to the NEXT operation and the packet is then sent to R7 with to the NEXT operation, and the packet is then sent to R7 with
&lt;T-SID1&gt; in the label stack.</t> &lt;T-SID1&gt; in the label stack.</t>
</li>
<t>R6, as Leaf, performs NEXT operation, pops T-SID1 label and <li>
<t>R6, as a Leaf, performs the NEXT operation, pops the T-SID1 lab
el, and
delivers the payload.</t> delivers the payload.</t>
</li>
<t>R7, as Leaf, performs NEXT operation, pops T-SID1 label and <li>
<t>R7, as a Leaf, performs the NEXT operation, pops the T-SID1 lab
el, and
delivers the payload.</t> delivers the payload.</t>
</list></t> </li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="SRv6"> <name>SRv6</name>
<t>For SRv6, the replicated packet from R2 to R7 has to traverse R4 <t>For SRv6, the replicated packet from R2 to R7 has to traverse R4
using an SR Policy, Policy27. The Policy has one SID in segment using an SR Policy, Policy27. The policy has one SID in the segment
list: End.X function with USD of R4 to R7 . The Replication segment list: End.X function with USD of R4 to R7. The Replication segment
state at nodes R1, R2, R6 and R7 is shown below.</t> state at nodes R1, R2, R6, and R7 is shown below.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Policy27: <2001:db8:cccc:4:c17::>]]></artwork>
<artwork><![CDATA[Policy27: <2001:db8:cccc:4:c17::>
]]></artwork>
</figure>
<t>Replication segment at R1:</t> <t>Replication segment at R1:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R1>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: 2001:db8:cccc:1:fa:: Replication-SID: 2001:db8:cccc:1:fa::
Replication State: Replication State:
R2: <2001:db8:cccc:2:fa::->L12> R2: <2001:db8:cccc:2:fa::->L12>]]></artwork>
]]></artwork>
</figure>
<t>Replication to R2 steers a packet directly to the node on <t>Replication to R2 steers a packet directly to the node on
interface L12.</t> interface L12.</t>
<t keepWithNext="true">Replication segment at R2:</t>
<t>Replication segment at R2:</t> <artwork name="" type="" align="left" alt=""><![CDATA[
Replication segment <R1,T-ID,I-ID1,R2>:
<figure>
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: 2001:db8:cccc:2:fa:: Replication-SID: 2001:db8:cccc:2:fa::
Replication State: Replication State:
R2: <Leaf> R2: <Leaf>
R6: <2001:db8:cccc:6:fa::> R6: <2001:db8:cccc:6:fa::>
R7: <2001:db8:cccc:7:fa:: -> Policy27>]]></artwork> R7: <2001:db8:cccc:7:fa:: -> Policy27>]]></artwork>
</figure> <t>R2 is a Bud node. It performs the role of a Leaf as well as a trans
it
<t>R2 is a Bud node. It performs role of Leaf as well as a transit node replicating to R6 and R7. Replication to R6 steers a packet
node replicating to R6 and R7. Replication to R6, steers a packet
via IGP shortest path to that node. Replication to R7, via an SR via IGP shortest path to that node. Replication to R7, via an SR
Policy, first encapsulates the packet using H.Encaps and then steers Policy, first encapsulates the packet using H.Encaps and then steers
the outer packet to R4. End.X USD on R4 decapsulates outer header the outer packet to R4. End.X USD on R4 decapsulates the outer header
and sends the original inner packet to R7.</t> and sends the original inner packet to R7.</t>
<t>Replication segment at R6:</t> <t>Replication segment at R6:</t>
<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R6>: Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: 2001:db8:cccc:6:fa:: Replication-SID: 2001:db8:cccc:6:fa::
Replication State: Replication State:
R6: <Leaf>]]></artwork> R6: <Leaf>]]></artwork>
</figure>
<t>Replication segment at R7:</t> <t>Replication segment at R7:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R7>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: 2001:db8:cccc:7:fa:: Replication-SID: 2001:db8:cccc:7:fa::
Replication State: Replication State:
R7: <Leaf>]]></artwork> R7: <Leaf>]]></artwork>
</figure>
<t>When a packet (A,B2) is steered into the active instance of <t>When a packet (A,B2) is steered into the active instance of
candidate path 1 of SR P2MP Policy at R1 using H.Encaps.Replicate candidate path 1 of the SR P2MP Policy at R1 using H.Encaps.Replicate
behavior:</t> behavior:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Since R1 is directly connected to R2, R1 sends replicated <t>Since R1 is directly connected to R2, R1 sends the replicated
copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on
interface L12.</t> interface L12.</t>
</li>
<t>R2, as Leaf removes outer IPv6 header and delivers the <li>
payload. R2, as a bud node, also replicates the packet.</t> <t>R2, as a Leaf, removes the outer IPv6 header and delivers the
payload. R2, as a Bud node, also replicates the packet.</t>
<t><list style="symbols"> </li>
<li>
<ul spacing="normal">
<li>
<t>For replication to R6, R2 sends (2001:db8::1, <t>For replication to R6, R2 sends (2001:db8::1,
2001:db8:cccc:6:fa::) (A,B2) to R3. R3 forwards the packet 2001:db8:cccc:6:fa::) (A,B2) to R3. R3 forwards the packet
using 2001:db8:cccc:6::/64 packet to R6.</t> using the 2001:db8:cccc:6::/64 packet to R6.</t>
</li>
<li>
<t>For replication to R7 using Policy27, R2 encapsulates and <t>For replication to R7 using Policy27, R2 encapsulates and
sends (2001:db8::2, 2001:db8:cccc:4:C17::) (2001:db8::1, sends (2001:db8::2, 2001:db8:cccc:4:C17::) (2001:db8::1,
2001:db8:cccc:7:fa::) (A,B2) to R4. R4 performs End.X USD 2001:db8:cccc:7:fa::) (A,B2) to R4. R4 performs End.X USD
behavior, decapsulates outer IPv6 header and sends behavior, decapsulates the outer IPv6 header, and sends
(2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) to R7.</t> (2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) to R7.</t>
</list></t> </li>
</ul>
<t>R6, as Leaf, removes outer IPv6 header and delivers the </li>
<li>
<t>R6, as a Leaf, removes the outer IPv6 header and delivers the
payload.</t> payload.</t>
</li>
<t>R7, as Leaf, removes outer IPv6 header and delivers the <li>
<t>R7, as a Leaf, removes the outer IPv6 header and delivers the
payload.</t> payload.</t>
</list></t> </li>
</ul>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="P2MP Tree with adjacent Replication Segments"> <name>P2MP Tree with Adjacent Replication Segments</name>
<t>Assume the controller computes a PTI with Root node R1, <t>Assume the controller computes a PTI with Root node R1,
Intermediate and Leaf node R2, Intermediate nodes R3 and R5, and Leaf Intermediate and Leaf node R2, Intermediate nodes R3 and R5, and Leaf
nodes R6 and R7. The controller instantiates the PTI by stitching nodes R6 and R7. The controller instantiates the PTI by stitching
Replication segments at R1, R2, R3, R5, R6 and R7. Replication segment Replication segments at R1, R2, R3, R5, R6, and R7. The Replication segm
at R1 replicates to R2. Replication segment at R2 replicates to R3 and ent
R5. Replication segment at R3 replicates to R6. Replication segment at at R1 replicates to R2. The Replication segment at R2 replicates to R3 a
R5 replicates to R7. Note node R4 does not have any Replication nd
R5. The Replication segment at R3 replicates to R6. The Replication segm
ent at
R5 replicates to R7. Note that node R4 does not have any Replication
segment state for the tree.</t> segment state for the tree.</t>
<section numbered="true" toc="default">
<section title="SR-MPLS"> <name>SR-MPLS</name>
<t>The Replication segment state at nodes R1, R2, R3, R5, R6 and R7 <t>The Replication segment state at nodes R1, R2, R3, R5, R6, and R7
is shown below.</t> is shown below.</t>
<t>Replication segment at R1:</t> <t>Replication segment at R1:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R1>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: T-SID1 Replication-SID: T-SID1
Replication State: Replication State:
R2: <T-SID1->L12> R2: <T-SID1->L12>]]></artwork>
]]></artwork>
</figure>
<t>Replication to R2 steers a packet directly to the node on <t>Replication to R2 steers a packet directly to the node on
interface L12.</t> interface L12.</t>
<t>Replication segment at R2:</t> <t>Replication segment at R2:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R2>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: T-SID1 Replication-SID: T-SID1
Replication State: Replication State:
R2: <Leaf> R2: <Leaf>
R3: <T-SID1->L23> R3: <T-SID1->L23>
R5: <T-SID1->L25>]]></artwork> R5: <T-SID1->L25>]]></artwork>
</figure> <t>R2 is a Bud node. It performs the role of a Leaf as well as a trans
it
<t>R2 is a Bud node. It performs role of Leaf as well as a transit node replicating to R3 and R5. Replication to R3 steers a packet
node replicating to R3 and R5. Replication to R3, steers a packet directly to the node on L23. Replication to R5 steers a packet
directly to the node on L23. Replication to R5, steers a packet
directly to the node on L25.</t> directly to the node on L25.</t>
<t>Replication segment at R3:</t> <t>Replication segment at R3:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R3>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R3>:
Replication-SID: T-SID1 Replication-SID: T-SID1
Replication State: Replication State:
R6: <T-SID1->L36> R6: <T-SID1->L36>]]></artwork>
]]></artwork> <t>Replication to R6 steers a packet directly to the node on
</figure>
<t>Replication to R6, steers a packet directly to the node on
L36.</t> L36.</t>
<t keepWithNext="true">Replication segment at R5:</t>
<t>Replication segment at R5:</t> <artwork name="" type="" align="left" alt=""><![CDATA[
Replication segment <R1,T-ID,I-ID1,R5>:
<figure>
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R5>:
Replication-SID: T-SID1 Replication-SID: T-SID1
Replication State: Replication State:
R7: <T-SID1->L57> R7: <T-SID1->L57>]]></artwork>
]]></artwork> <t>Replication to R7 steers a packet directly to the node on
</figure>
<t>Replication to R7, steers a packet directly to the node on
L57.</t> L57.</t>
<t>Replication segment at R6:</t> <t>Replication segment at R6:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R6>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: T-SID1 Replication-SID: T-SID1
Replication State: Replication State:
R6: <Leaf>]]></artwork> R6: <Leaf>]]></artwork>
</figure>
<t>Replication segment at R7:</t> <t>Replication segment at R7:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R7>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: T-SID1 Replication-SID: T-SID1
Replication State: Replication State:
R7: <Leaf>]]></artwork> R7: <Leaf>]]></artwork>
</figure>
<t>When a packet is steered into the SR P2MP Policy at R1:</t> <t>When a packet is steered into the SR P2MP Policy at R1:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Since R1 is directly connected to R2, R1 performs PUSH <t>Since R1 is directly connected to R2, R1 performs the PUSH
operation with just &lt;T-SID1&gt; label for the replicated copy operation with just the &lt;T-SID1&gt; label for the replicated co
py
and sends it to R2 on interface L12.</t> and sends it to R2 on interface L12.</t>
</li>
<t>R2, as Leaf, performs NEXT operation, pops T-SID1 label and <li>
delivers the payload. It also performs PUSH operation on T-SID1 <t>R2, as a Leaf, performs the NEXT operation, pops the T-SID1 lab
el, and
delivers the payload. It also performs the PUSH operation on T-SID
1
for replication to R3 and R5. For replication to R6, R2 sends for replication to R3 and R5. For replication to R6, R2 sends
&lt;T-SID1&gt; label stack to R3 on interface L23. For the &lt;T-SID1&gt; label stack to R3 on interface L23. For
replication to R5, R2 sends &lt;T-SID1&gt; label stack to R5 on replication to R5, R2 sends the &lt;T-SID1&gt; label stack to R5 o
n
interface L25.</t> interface L25.</t>
</li>
<t>R3 performs NEXT operation on T-SID1 and performs a PUSH <li>
operation for replication to R6 and sends &lt;T-SID1&gt; label <t>R3 performs the NEXT operation on T-SID1, performs a PUSH
operation for replication to R6, and sends the &lt;T-SID1&gt; labe
l
stack to R6 on interface L36.</t> stack to R6 on interface L36.</t>
</li>
<t>R5 performs NEXT operation on T-SID1 and performs a PUSH <li>
operation for replication to R7 and sends &lt;T-SID1&gt; label <t>R5 performs the NEXT operation on T-SID1, performs a PUSH
operation for replication to R7, and sends the &lt;T-SID1&gt; labe
l
stack to R7 on interface L57.</t> stack to R7 on interface L57.</t>
</li>
<t>R6, as Leaf, performs NEXT operation, pops T-SID1 label and <li>
<t>R6, as a Leaf, performs the NEXT operation, pops the T-SID1 lab
el, and
delivers the payload.</t> delivers the payload.</t>
</li>
<t>R7, as Leaf, performs NEXT operation, pops T-SID1 label and <li>
<t>R7, as a Leaf, performs the NEXT operation, pops the T-SID1 lab
el, and
delivers the payload.</t> delivers the payload.</t>
</list></t> </li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="SRv6"> <name>SRv6</name>
<t>The Replication segment state at nodes R1, R2, R3, R5, R6 and R7 <t>The Replication segment state at nodes R1, R2, R3, R5, R6, and R7
is shown below.</t> is shown below.</t>
<t keepWithNext="true">Replication segment at R1:</t>
<t>Replication segment at R1:</t> <artwork name="" type="" align="left" alt=""><![CDATA[
Replication segment <R1,T-ID,I-ID1,R1>:
<figure>
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R1>:
Replication-SID: 2001:db8:cccc:1:fa:: Replication-SID: 2001:db8:cccc:1:fa::
Replication State: Replication State:
R2: <2001:db8:cccc:2:fa::->L12> R2: <2001:db8:cccc:2:fa::->L12>]]></artwork>
]]></artwork>
</figure>
<t>Replication to R2 steers a packet directly to the node on <t>Replication to R2 steers a packet directly to the node on
interface L12.</t> interface L12.</t>
<t>Replication segment at R2:</t> <t>Replication segment at R2:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R2>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R2>:
Replication-SID: 2001:db8:cccc:2:fa:: Replication-SID: 2001:db8:cccc:2:fa::
Replication State: Replication State:
R2: <Leaf> R2: <Leaf>
R3: <2001:db8:cccc:3:fa::->L23> R3: <2001:db8:cccc:3:fa::->L23>
R5: <2001:db8:cccc:5:fa::->L25>]]></artwork> R5: <2001:db8:cccc:5:fa::->L25>]]></artwork>
</figure> <t>R2 is a Bud node. It performs the role of a Leaf as well as a trans
it
<t>R2 is a Bud node. It performs role of Leaf as well as a transit node replicating to R3 and R5. Replication to R3 steers a packet
node replicating to R3 and R5. Replication to R3, steers a packet directly to the node on L23. Replication to R5 steers a packet
directly to the node on L23. Replication to R5, steers a packet
directly to the node on L25.</t> directly to the node on L25.</t>
<t>Replication segment at R3:</t> <t>Replication segment at R3:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R3>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R3>:
Replication-SID: 2001:db8:cccc:3:fa:: Replication-SID: 2001:db8:cccc:3:fa::
Replication State: Replication State:
R6: <2001:db8:cccc:6:fa::->L36> R6: <2001:db8:cccc:6:fa::->L36>]]></artwork>
]]></artwork> <t>Replication to R6 steers a packet directly to the node on
</figure>
<t>Replication to R6, steers a packet directly to the node on
L36.</t> L36.</t>
<t>Replication segment at R5:</t> <t>Replication segment at R5:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R5>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R5>:
Replication-SID: 2001:db8:cccc:5:fa:: Replication-SID: 2001:db8:cccc:5:fa::
Replication State: Replication State:
R7: <2001:db8:cccc:7:fa::->L57> R7: <2001:db8:cccc:7:fa::->L57>]]></artwork>
]]></artwork> <t>Replication to R7 steers a packet directly to the node on
</figure>
<t>Replication to R7, steers a packet directly to the node on
L57.</t> L57.</t>
<t>Replication segment at R6:</t> <t>Replication segment at R6:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R6>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R6>:
Replication-SID: 2001:db8:cccc:6:fa:: Replication-SID: 2001:db8:cccc:6:fa::
Replication State: Replication State:
R6: <Leaf>]]></artwork> R6: <Leaf>]]></artwork>
</figure>
<t>Replication segment at R7:</t> <t>Replication segment at R7:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure> Replication segment <R1,T-ID,I-ID1,R7>:
<artwork><![CDATA[Replication segment <R1,T-ID,I-ID1,R7>:
Replication-SID: 2001:db8:cccc:7:fa:: Replication-SID: 2001:db8:cccc:7:fa::
Replication State: Replication State:
R7: <Leaf>]]></artwork> R7: <Leaf>]]></artwork>
</figure>
<t>When a packet (A,B2) is steered into the active instance of <t>When a packet (A,B2) is steered into the active instance of
candidate path 1 of SR P2MP Policy at R1 using H.Encaps.Replicate candidate path 1 of the SR P2MP Policy at R1 using the H.Encaps.Replic ate
behavior:</t> behavior:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Since R1 is directly connected to R2, R1 sends replicated <t>Since R1 is directly connected to R2, R1 sends the replicated
copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on
interface L12.</t> interface L12.</t>
</li>
<t>R2, as Leaf, removes outer IPv6 header and delivers the <li>
payload. R2, as a bud node, also replicates the packet. For <t>R2, as a Leaf, removes the outer IPv6 header and delivers the
payload. R2, as a Bud node, also replicates the packet. For
replication to R3, R2 sends (2001:db8::1, 2001:db8:cccc:3:fa::) replication to R3, R2 sends (2001:db8::1, 2001:db8:cccc:3:fa::)
(A,B2) to R3 on interface L23. For replication to R5, R2 sends (A,B2) to R3 on interface L23. For replication to R5, R2 sends
(2001:db8::1, 2001:db8:cccc:5:fa::) (A,B2) to R5 on interface (2001:db8::1, 2001:db8:cccc:5:fa::) (A,B2) to R5 on interface
L25.</t> L25.</t>
</li>
<li>
<t>R3 replicates and sends (2001:db8::1, 2001:db8:cccc:6:fa::) <t>R3 replicates and sends (2001:db8::1, 2001:db8:cccc:6:fa::)
(A,B2) to R6 on interface L36.</t> (A,B2) to R6 on interface L36.</t>
</li>
<li>
<t>R5 replicates and sends (2001:db8::1, 2001:db8:cccc:7:fa::) <t>R5 replicates and sends (2001:db8::1, 2001:db8:cccc:7:fa::)
(A,B2) to R7 on interface L57.</t> (A,B2) to R7 on interface L57.</t>
</li>
<t>R6, as Leaf, removes outer IPv6 header and delivers the <li>
<t>R6, as a Leaf, removes the outer IPv6 header and delivers the
payload.</t> payload.</t>
</li>
<t>R7, as Leaf, removes outer IPv6 header and delivers the <li>
<t>R7, as a Leaf, removes the outer IPv6 header and delivers the
payload.</t> payload.</t>
</list></t> </li>
</ul>
</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"/>,
and <contact fullname="Vishnu Pavan Beeram"/> for their valuable input.</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>
<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><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><country>United States of America</co
untry></postal>
<email>jayant.kotalwar@nokia.com</email>
</address>
</contact>
<contact fullname="Tanmoy Kundu">
<organization>Nokia</organization>
<address>
<postal><city>Mountain View</city><country>United States of America</co
untry></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>Juniper Networks</organization>
<address>
<postal><country>Canada</country></postal>
<email>tsaad@juniper.net</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="Anuj Budhiraja">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal><country>United States of America</country></postal>
<email>abudhira@cisco.com</email>
</address>
</contact>
<contact fullname="Mankamana Mishra">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal><country>United States of America</country></postal>
<email>mankamis@cisco.com</email>
</address>
</contact>
</section>
<!-- [rfced] Throughout the text, the following terminology appears to
be used inconsistently. Please review these occurrences and let
us know if/how they may be made consistent.
a) SR domain (26) vs. SR MPLS domain (1)
Note: is "SR MPLS domain" different than "SR domain"?
If not, should "MPLS" be removed for consistency?
Current:
Failure to protect the SR MPLS domain by correctly provisioning MPLS
support per interface permits attackers from outside the domain to
send packets to receivers of the multipoint services that use the SR
P2MP Policies provisioned within the domain.
b) SR P2MP Policy (72) vs. SR Policy (4)
-->
<!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
locator (LOC)
Path Computation Element Communication Protocol (PCEP)
Penultimate Hop Popping (PHP)
Regional Internet Registry (RIR)
Replication segment identifier (Replication-SID)
Topology Independent Loop-Free Alternate (TI-LFA)
b) As recommended in the Web Portion of the Style Guide
<https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, once an
abbreviation is introduced, the abbreviated form should be used
thereafter. Please consider if you would like to apply this style for
the following terms:
Binding SID (BSID)
candidate path (CP)
P2MP tree instance (PTI)
Penultimate Hop Popping (PHP)
Replication segment identifier (Replication-SID)
Segment Routing (SR)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 307 change blocks. 
805 lines changed or deleted 1108 lines changed or added

This html diff was produced by rfcdiff 1.48.