Network Working Group H. Bidgoli, Ed.
Internet-Draft Nokia
Intended status: Standards Track V. Voyer
Expires: 23 August 2025 Bell Canada
A. Budhiraja
Cisco System
R. Parekh
Arrcus
S. Sivabalan
Ciena
19 February 2025
PCEP extensions for P2MP SR Policy
draft-ietf-pce-sr-p2mp-policy-11
Abstract
Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of
policies that enable architecture for P2MP service delivery. This
document specifies extensions to the Path Computation Element
Communication Protocol (PCEP) that allow a stateful PCE to compute
and initiate P2MP paths from a Root to a set of Leaf nodes.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 August 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bidgoli, et al. Expires 23 August 2025 [Page 1]
Internet-Draft PCEP p2mp sr policy February 2025
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
4. Overview of PCEP Operation in SR P2MP Network . . . . . . . . 6
4.1. Related and Inherited Documents . . . . . . . . . . . . . 6
4.2. Overview of SR P2MP Policy Objects . . . . . . . . . . . 7
4.2.1. SR P2MP Policy and Candidate Path Identification . . 9
4.2.2. Replication Segment Identification . . . . . . . . . 9
4.2.3. PCECC Use in Replication Segment . . . . . . . . . . 10
4.3. PCEP Prodecures . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. PCE-Init Procedure . . . . . . . . . . . . . . . . . 10
4.3.2. PCC-Init Procedure . . . . . . . . . . . . . . . . . 11
4.3.3. Common Procedures . . . . . . . . . . . . . . . . . . 11
4.3.3.1. Replicatoin Segment Instantiation . . . . . . . . 12
4.3.3.2. New Candidate Path Creation . . . . . . . . . . . 12
4.3.3.3. Adding new Leaf nodes . . . . . . . . . . . . . . 13
4.3.3.4. Conveying active state and cleanup . . . . . . . 13
4.3.4. Global Optimization of the Candidate Path . . . . . . 14
4.3.5. local optimizatoin . . . . . . . . . . . . . . . . . 14
4.3.6. Fast Reroute . . . . . . . . . . . . . . . . . . . . 15
4.3.7. Connecting Replication Segment via Segment List . . . 16
4.3.8. Tree Deletion . . . . . . . . . . . . . . . . . . . . 16
4.3.8.1. PCC Initiated . . . . . . . . . . . . . . . . . . 17
4.3.8.2. PCE Initiated . . . . . . . . . . . . . . . . . . 17
4.3.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 17
4.4. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 17
4.4.1. SR P2MP Policy . . . . . . . . . . . . . . . . . . . 17
4.4.2. Replication Segment . . . . . . . . . . . . . . . . . 20
4.4.3. Considerations . . . . . . . . . . . . . . . . . . . 23
4.4.3.1. Path Attribute Object . . . . . . . . . . . . . . 24
4.4.3.2. CCI Object . . . . . . . . . . . . . . . . . . . 24
5. Object Format . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Open Message Extension . . . . . . . . . . . . . . . . . 24
5.2. PCE Capabliity SubTLV . . . . . . . . . . . . . . . . . . 25
5.3. Association Type Capability . . . . . . . . . . . . . . . 25
5.4. Symbolic Name TLV . . . . . . . . . . . . . . . . . . . . 26
5.5. SR P2MP Policy . . . . . . . . . . . . . . . . . . . . . 26
Bidgoli, et al. Expires 23 August 2025 [Page 2]
Internet-Draft PCEP p2mp sr policy February 2025
5.5.1. P2MP Policy Association Group . . . . . . . . . . . . 26
5.5.1.1. Extended Association ID TLV . . . . . . . . . . . 27
5.5.2. P2MP-END-POINTS Object . . . . . . . . . . . . . . . 27
5.6. P2MP Policy and Replication Segment Identifier Object and
TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.6.1. Extension of the LSP Object, SR-P2MP-LSPID-TLV . . . 29
5.7. Replication Segment . . . . . . . . . . . . . . . . . . . 32
5.7.1. Message format . . . . . . . . . . . . . . . . . . . 32
5.7.2. CCI Object . . . . . . . . . . . . . . . . . . . . . 33
5.7.3. SR-ERO Rules . . . . . . . . . . . . . . . . . . . . 34
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 34
6.1. PCEP P2MP Association type . . . . . . . . . . . . . . . 34
6.2. Endpoint Type . . . . . . . . . . . . . . . . . . . . . . 35
6.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 35
6.4. New CCI Object Type . . . . . . . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Manageability Considerations . . . . . . . . . . . . . . . . 37
8.1. Control of Function and Policy . . . . . . . . . . . . . 37
8.2. Information and Data Models . . . . . . . . . . . . . . . 37
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 37
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 37
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 37
8.6. Impact On Network Operations . . . . . . . . . . . . . . 37
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Normative References . . . . . . . . . . . . . . . . . . 38
11.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Packet Examples . . . . . . . . . . . . . . . . . . 40
A.1. Report for Leaf Add . . . . . . . . . . . . . . . . . . . 40
A.2. P2MP Policy Candidate path Init . . . . . . . . . . . . . 41
A.3. Replication segment PCE Initiated on Transit and
LEaves . . . . . . . . . . . . . . . . . . . . . . . . . 45
Appendix B. Example Workflows . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction
The document [draft-ietf-pim-sr-p2mp-policy] defines a variant of the
SR Policy that uses [RFC9256] for constructing a Point-to-Multipoint
(P2MP) segment to support multicast service delivery.
A P2MP SR Policy is constructed using one or more Replication
segments ([RFC9524]) from a Root node to a set of Leaf nodes,
optionally through a set of intermediate transit nodes that perform
replication.
Bidgoli, et al. Expires 23 August 2025 [Page 3]
Internet-Draft PCEP p2mp sr policy February 2025
A Replication segment [RFC9524], corresponds to the forwarding state
of a P2MP segment on a particular node and provide forwarding
instructions for the segment.
A SR P2MP Policy is installed only on the Root node of a P2MP tree
and consists of one or more Candidate paths. Each Candidate path is
made up of path-instances, and each path-instance is constructed in
the network via Replication segments. Replication segments are
installed on the Root node, Leaf nodes, and optionally, intermediate
replication nodes.
Replication segments may be directly or indirectly connected within
an SR Domain. One or more SR segments are used to steer traffic
between adjacent and non-adjacent replicating nodes.
There are two types of a P2MP Tree: Ingress Replication and
Replication tree.
A P2MP service delivery could be via Ingress Replication [RFC7988].
Dataplane packet replication only occurs on the Root, which forwards
individual copies of traffic to each leaf directly over a segment
routed path. The corresponding SR P2MP Policy consists of
Replication segments only for the Root node and the Leaf nodes.
A P2MP service delivery could be via Downstream Replication, known as
Replication Tree. The corresponding SR P2MP policy consists of
Replication segments on the Root, Leaf, and Transit nodes which exist
in the topology between the Root and Leaf nodes. The Root and
Transit nodes perform dataplane packet replication along the tree as
a packet traverses from the root towards each leaf.
The PCE discovers the root and the leaves via different methods. As
an example, the leaves and the root can be explicitly configured on
the PCE or PCC can update the PCE with the identity of the root and
the leaves when it discovers them via multicast protocols like MP-BGP
and MVPN procedures [RFC6513] or PIM. Once the controller is
informed of the Root node and Leaf nodes, it can calculate the SR
P2MP Policy and any of the required Replication segments from the
Root node to the Leaf nodes. The computation may include traffic
engineering criteria and any additional Service Leave Agreements
(SLAs) that is used to construct the tree.
This document defines PCEP objects, TLVs and the procedures to
instantiate a P2MP Policy and Replication Segments.
Only Stateful PCE is within scope of this document and Stateless PCE
only is out of scope.
Bidgoli, et al. Expires 23 August 2025 [Page 4]
Internet-Draft PCEP p2mp sr policy February 2025
2. Terminology
This section defines terms used frequently in this document. Refer
to Terminology sections of [RFC9256], and [RFC9524] for other terms
used in Segment Routing.
* Unicast Segment Routing (SR): Standard Segment Routing constructs,
capabilities and behavior which is not multicast or replication
aware.
* Replication segment: A segment in SR domain that replicates
packets. See [RFC9524], for details.
* Replication node: A node in SR domain which replicates packets
based on Replication segment.
* Downstream nodes: A Replication segment replicates packets to a
set of nodes. These nodes are Downstream nodes.
* Replication state: State held for a Replication segment at a
Replication node. It is conceptually a list of replication
branches to Downstream nodes. The list can be empty.
* Replication SID: Data plane identifier of a Replication segment.
This is a SR-MPLS label or SRv6 Segment Identifier (SID).
* Point-to-Multipoint Service: A service that has one ingress node
and one or more egress nodes. A packet is delivered to all the
egress nodes
* Transit node: alternative name for Replication node
* Root node: An ingress node of a P2MP service,
* Leaf node: An egress node of a P2MP service.
* Bud node: A node that is both a Replication node and a Leaf node.
3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Bidgoli, et al. Expires 23 August 2025 [Page 5]
Internet-Draft PCEP p2mp sr policy February 2025
4. Overview of PCEP Operation in SR P2MP Network
After discovering the Root node and Leaf nodes, the PCE programs the
PCCs with relevant information needed to create a P2MP Tree.
As per document [draft-ietf-pim-sr-p2mp-policy] a P2MP Policy is
defined by Root-ID, Tree-ID and a set of leaves. A SR P2MP policy is
a variant of SR policy as such it inherits similar concept as draft
[draft-ietf-pce-segment-routing-policy-cp]. A P2MP policy is
composed of a collection of SR P2mp Candidate Paths. Candidate paths
are computed by the PCE and can be used for P2MP Tree redundancy.
Only a single candidate path may be active at each time. Each
candidate paths can be globally optimized, therefore it consists of
multiple path-instances. A path-instance can be considered as a P2MP
LSP. If a candidate path needs to be globally optimized two path-
instances can be programmed from the root the leaves and via make
before break procedures the candidate path can be switched from path-
instance one to the second path-instance. The forwarding states of
these path-instances are build via replication segments. Each path-
instance initiated on the root has its own set of replication
segments on the Root, Transit and Leaf nodes.
A replication segment is set of forwarding instructions on a specific
node. Each instruction may be a PUSH or SWAP operation before
forwarding out of an interface, or a POP action on bud and leaf
nodes.
PCE MAY also calculate and download additional information for the
replication segments, such as protections next-hops for link
protection.
4.1. Related and Inherited Documents
* [RFC8231] The bases for a stateful PCE, and reuses the following
objects or a variant of them
- <SRP Object>
- <LSP Object>
- A variation of the LSP identifier TLV is defined in this draft,
to support P2MP LSP Identifier
* [RFC8306] P2MP capabilities advertisement
Bidgoli, et al. Expires 23 August 2025 [Page 6]
Internet-Draft PCEP p2mp sr policy February 2025
* [draft-ietf-pce-segment-routing-policy-cp] Candidate paths for SR
P2MP Policy is used for Tree Redundancy. As an example, a P2MP
Policy can have multiple candidate paths. Each protecting the
primary candidate path. The active path is chosen via the
preference of the candidate path.
* [RFC3209] Defines the instance-ID, instance-ID is used for global
optimization of a candidate path with in a P2MP policy. Each
Candidate path can have 2 path-instances. These path-instances
are equivalent to sub-lsps (instance-IDs). There are used for MBB
and global optimization procedures. instance-ID is equivalent to
LSP ID
* [RFC9256] Segment-list, used for connecting two non-adjacent
replication policy via a unicast binding SID or Segment-list.
* [RFC8306] P2MP End Point objects, used for the PCC to update the
PCE with discovered Leaves.
* [RFC9050] for programming and identifying the Replication Segment.
A new PCE CC Capability sub Tlv is introduced to indicated the
support to handle PCE CC based label download for SR P2MP.
* [draft-ietf-pce-pcep-extension-pce-controller-sr]defines CCI
object-type for SR-MPLS. This document redefines a new version of
the SR-MPLS CCI object-type.
* [draft-ietf-pce-multipath] Forwarding instruction for a P2MP LSP
is defined by a set of SR-ERO sub-objects in the ERO object, ERO-
ATTRIBUTES object and MULTIPATH-BACKUP TLV as defined in this
draft.
* [RFC8664] SR-ERO Sub Object used in the multipath.
It should be noted that the [draft-hb-spring-sr-p2mp-policy-yang] can
provide further details of the high level P2MP Policy Model.
4.2. Overview of SR P2MP Policy Objects
* SR P2MP Policy
- Is only relevant on the Root of the P2MP tree and is a policy
on PCE. It is downloaded only on the root node and is
identified via <Root-ID, Tree-ID> It contains the following
information:
o Root node of the P2MP Segment
Bidgoli, et al. Expires 23 August 2025 [Page 7]
Internet-Draft PCEP p2mp sr policy February 2025
o Set of Leaf nodes of the P2MP Segment
o Tree-ID, which is a unique identifier of the P2MP tree on
the Root
o A set of Candidate paths belonging to the policy
o Optional Constraints used to build these candidate paths
* Candidate Path:
- Is used for P2MP Tree redundancy where the candidate path with
the highest preference is the active path.
- Each Candidate Path can contain two path-instance for global
optimization procedures (i.e. make before break)
- Contains information regarding originator, discriminator,
preference, path-instances
* Path-instance:
- Is used for global optimization of the candidate path.
Multiple path-instance can be present under a candidate path
but only a single path instance is active at a time.
- A path instance is identified via <Root-ID, Tree-ID, Instance-
ID>
* Replication Segment:
- Is the forwarding information needed on each replication node
for building the forwarding path for each path-instance of the
P2MP Candidate path.
- Explained further in upcoming sections, there are 2 ways to
identify the replication segment, depending on the type of
replication segment (shared replication segment or non-shared
replication segment)
o It is identified via Tree-ID and Root-ID and path-instance
for non-shared replication segment.
o It is identified via Node-ID, Replication-ID, for shared
replication segment. As per [draft-ietf-pim-sr-p2mp-policy]
a shared replication segment is not associated to a tree and
is used for constructing by-pass tunnels.
Bidgoli, et al. Expires 23 August 2025 [Page 8]
Internet-Draft PCEP p2mp sr policy February 2025
o Contains forwarding instructions, in the form of a list of
outgoing segments each of which may be a segment list or a
single replication segment with next-hop information.
o On the forwarding plane the Replication Segment is
identified via the incoming Replication SID.
o Is established on every node that may replicate (e.g., Root,
Transit, Bud) or receive (e.g., Leaf) the packet in an SR
P2MP tree.
4.2.1. SR P2MP Policy and Candidate Path Identification
A SR P2MP Policy and its candidate path can be identified on the root
via the P2MP LSP Object. This Object is a variation of the LSP ID
Object defined in [RFC8231] and is as follow:
* PLSP-ID: [RFC8231], is assigned by PCC and is unique per candidate
path. It is constant for the lifetime of a PCEP session. Each
additional Candidate path is assigned a new PLSP-ID by PCC.
Multiple Candidate paths can co-exist but only one is active.
* Root-ID: is equivalent to the first node on the SR P2MP path.
* Tree-ID: an identifier that is unique in context of the Root node.
This value may be assigned manually on the Root node or advertised
via the Provider Tunnel Association(PTA) in a multicast BGP Auto-
Discovery(AD) route.
* Instance-ID: serves as the path-instance identifier and is
assigned by the PCE. A candidate path can have up to two path
instances for global optimization. Instance-IDs are unique within
the SR P2MP policy and are assigned by the PCE per path instance.
While different P2MP policies may use the same Instance-ID for
their path instances, each path instance within a candidate path
of an SR P2MP policy should use the same Instance-ID across the
Root, Transit, and Leaf nodes when programming its replication
segments on the PCC.
4.2.2. Replication Segment Identification
The key to identify a replication segment is also a P2MP LSP Object.
With varying encoding rules for the SR-P2MP-LSP- IDENTIFIER TLV which
will be explained in later sections.
Bidgoli, et al. Expires 23 August 2025 [Page 9]
Internet-Draft PCEP p2mp sr policy February 2025
4.2.3. PCECC Use in Replication Segment
PCECC and a variant of CCI object is used in Replication Segment to
identify a cross connect. A cross connect is a incoming SID and set
of outgoing interfaces and their corresponding SID or SID List. The
CCI objects contains the incoming SID and the outgoing interfaces
which are presented via the ERO objects, which each may contain a
segment list.
4.3. PCEP Prodecures
A SR P2MP policy on the Root can be either PCE-initiated or PCC-
initiated, depending on how the Root and Leaf nodes are discovered.
A PCE-initiated SR P2MP policy is configured directly on the PCE,
while a PCC-initiated SR P2MP policy may be triggered by the PCC,
sourced from local configuration or discovered with multicast
protocols such as MVPN (see [RFC6513]), PIM, IGMP etc. In both
cases, PCE-initiated mechanisms are used to install Replication
segments on Transit, Bud and Leaf nodes.
Note: Algorithms and techniques to compute the P2MP tree replicating
nodes are out of scope of this document.
4.3.1. PCE-Init Procedure
* PCE is informed through its API or configuration mechanism to
instantiate a SR P2MP Policy. PCE is configured with the Root and
a set of Leaf nodes.
* PCE computes a P2MP tree from the Root node to all Leaf nodes
which satisfy the configured constraints.
* PCE sends a PcInitiate message to the Root. The PcInitiate
message is configured with a unique Instance-ID for the path-
instance within the SR P2MP Policy. The PcInitiate message sent
to the root MUST set the Tree-ID to 0. The endpoint-object MAY
optionally be included in the PcInitiate message for providing
list of Leaf nodes to the PCC for informational purposes.
* In response to the PcInitiate message, the PCC will assign the
PLSP-ID and Tree-ID for the Candidate path. The PCC uses the
Instance-ID defined in the PcInitiate message for the Path
Instance contained within the Candidate Path. The PCC sends a
PcRpt back to PCE containing the PLSP-ID, Tree-ID and Instance-ID.
PCC MAY optionally include additional Leaf nodes that were also
discovered by multicast procedures
Bidgoli, et al. Expires 23 August 2025 [Page 10]
Internet-Draft PCEP p2mp sr policy February 2025
* PCE will send a PCInitiate message to the Root, Transit and the
Leaf nodes to download the Replication Segment information. These
messages will utilize the CCI object to identify the p2mp cross
connect and encode the forwarding instruction information.
* PCE then sends a PCUpdate to the Root node indicating the
association information (Candidate path) and implicitly binds the
Candidate path to the installed CCI information.
4.3.2. PCC-Init Procedure
* Root node PCC discovers the leaf nodes via MVPN procedures or
other mechanism
* Root sends a PCRpt message for SR P2MP policy to PCE including the
Root-ID, Tree-ID, PLSP-ID, symbolic-path-name, association object
and any leaf nodes discovered. In addition:
* - Since the instance-id is set by the PCE, the root will set the
instance-id to value to 0 in the RCRpt message
- For the association object, root will fill the association type
according to the association type defined in this document.
The association ID SHOULD be set to value 1 similar to
[draft-ietf-pce-segment-routing-policy-cp]. The association
source is set to the Root PCC Address.
* PCE receives the PcRpt and generates a unique Instance-ID for this
path-instance of the candidate path and compute the P2MP Policy
and its replication segments.
- PCE will send a PCInitiate message to the Root, Transit and the
Leaf nodes to download the Replication Segment information.
These messages will utilize the CCI object to encode the
forwarding instruction information.
- PCE will then send a PCUpdate to the root indicating the
association information (Candidate path) , and implicitly
indicate it to bind to the latest CCI information downloaded.
4.3.3. Common Procedures
The following procedures are the same for PCE-init or PCC-init SR
P2MP Policy.
Bidgoli, et al. Expires 23 August 2025 [Page 11]
Internet-Draft PCEP p2mp sr policy February 2025
4.3.3.1. Replicatoin Segment Instantiation
* PCE distributes the Replication segments for each Candidate path
path-instance to all Transit, Bud and Leaf nodes in the SR P2MP
Tree using a PcInitiate message.
* - PLSP-ID: value MUST be set to zero and will be assigned by PCC.
- Symbolic path name: generated by PCE, MUST be unique for the
each candidate path on PCC.
- Root-ID: the same value of the SR P2MP Policy
- Tree-ID: it is RECOMMENDED the Tree-ID be set to the same Tree-
ID defined on the Root node (which was assigned by the Root
node PCC).
- Instance-ID: set to the same value of path-instance on the
Root.
* The PcInitiate message includes the EROs and utilizes the CCI
object to encode the Replication segment forwarding instruction
information.
* In response to the PcInitiate message, each Transit, Bud and Leaf
node PCC generates a local PLSP-ID and sends a PcRpt to PCE
informing PCE of the Replication segment state.
4.3.3.2. New Candidate Path Creation
* Any new Candidate path for the SR P2MP Policy is downloaded by PCE
to the Root by sending a PcInitiate message.
- PLSP-ID: value MUST be set to zero and will be assigned by PCC.
- Symbolic path name: generated by PCE, MUST be unique for each
candidate path on PCC.
- Root-ID: the same value of the SR P2MP Policy
- Tree-ID: the same value of the SR P2MP Policy
- Instance-ID: value MUST be set to zero. The PCC generates the
Path Instance-ID of the candidate path
Bidgoli, et al. Expires 23 August 2025 [Page 12]
Internet-Draft PCEP p2mp sr policy February 2025
* The PCE distributes the necessary Replication segment for the
Candidate path and its path-instances to the Root, Leaf nodes and
the Transit nodes as described in section "Replication Segment
Instantiation".
* Any update to the Candidate paths or Replication segments is
performed via the PCUpd message. Association object MUST be
present for Candidate path PCUpdate and PCRpt message. CCI object
MUST be present in the Replication segment updates.
4.3.3.3. Adding new Leaf nodes
* New Leaf nodes may be locally configured or discovered via
multicast protocol procedures. New Replication segments may be
instantiated or existing one updated to reach new Leaf nodes.
- If the new Leaf nodes reside on routers that are part of the
existing SR P2MP Tree, then PCUpd is sent from PCE to necessary
PCCs (Leaf, Bud or Root nodes) with the existing PLSP-ID,
Instance-ID, Tree-ID and CC-ID.
- If the new Leaf nodes are residing on routers that are not part
of the existing SR P2MP Tree, then a PcInitiate message is sent
from PCE to each new Leaf and any necessary Transit nodes
following section "Replication Segment Instantiation".
4.3.3.4. Conveying active state and cleanup
The active Candidate path is indicated by the PCC through the
operational bits(Up/Active) of the LSP object in the PCRpt message.
If a Candidate path needs to be removed, PCE sends PC Initiate
message, setting the R-flag in the LSP object and R bit in the SRP-
object.
A Candidate path is made active based on the preference of the path.
If the Root is programed with multiple Candidate paths from different
sources, as an example PCE and CLI, based on its tie-breaking rules,
if it selects the CLI path, it will send a report to PCE for the PCE
path indicating the status of label-download and sets operational bit
of the LSP object to UP and Not Active. At any instance, only one
path is permitted be active
To remove a single candidate path, PCE sends PC Initiate message,
setting the R-flag in the LSP object and R bit in the SRP-object.
To remove the entire P2MP-LSP, PCE needs to send PcInitiate remove
messages for every Candidate path of the SR P2MP Policy to the Root
and send PcInitiate remove messages for every Replication segment on
Bidgoli, et al. Expires 23 August 2025 [Page 13]
Internet-Draft PCEP p2mp sr policy February 2025
all the PCCs in the SR P2MP Tree. The R bit in the LSP Object as
defined in [RFC8231], refers to the removal of the LSP as identified
by the SR-P2MP-INSTANCE-ID-TLV (defined in this document). An all
zero (SR-P2MP-LSP-ID-TLV defines to remove all the state of the
corresponding PLSP-ID.
4.3.4. Global Optimization of the Candidate Path
When a P2MP LSP needs to be optimized for any reason (i.e. it is
taking a FRR tunnel or new routers are added to the network) a global
optimization of the candidate path is possible.
Each Candidate Path MAY contain two Path-Instances. The current
unoptimized Path-Instance is the active instance and its replication
segments are forwarding the multicast packets from the root to the
leaves. However the second optimized Path-Instance will be setup
with its own unique Replication Segments throughout the network, from
the Root to the leaf nodes. These two Path-Instances MAY co-exist.
The two Path-Instances are uniquely identified by their Instance-ID
in the SR-P2MP-INSTANCE-ID-TLV (defined in this document).
After the optimized Path-Instance has been downloaded successfully,
PCC MUST send two reports, reporting UP of the new path indicating
the new LSP-ID, and a second reporting the tear down of the old path
with the R bit of the LSP Object SET with the old Instance-ID in the
SR-P2MP-INSTANCE-ID-TLV. This MBB procedure will move the multicast
PDUs to the optimized Path-Instance.
The transit and leaf nodes SHOULD be able to accept traffic from both
Path-Instances to minimize the traffic outage by the Make Before
Break process.
It is recommended for the optimized Path-Instance to be setup up by
PCE from the leaf nodes to transit nodes and finally the root nodes
to ensure the entire Path-Instance is programmed before the MBB
procedure is initiated.
4.3.5. local optimizatoin
When one of the PCCs involved in the LSP lacks the capability to
support more than one instance, the possibility of achieving global
make before break (MBB) is not feasible. However, with knowledge of
the PCCs' advertised capabilities, the PCE can detect this limitation
and instead opt for local re-optimization of the Candidate path. In
such cases, the PCE can compute the optimized LSP by send the PCUpd
message using the existing Instance for Candidate path, specifically
targeting the PCCs where the optimized LSP triggers a change in
forwarding state.
Bidgoli, et al. Expires 23 August 2025 [Page 14]
Internet-Draft PCEP p2mp sr policy February 2025
4.3.6. Fast Reroute
This document identifies Facility Fast Reroute (FRR) procedures.
Only Link Protection procedures are defined. How the Facility Path
is computed and instantiated is outside of scope of this document.
R
| |
T
|
---
| |
L1 L2
Figure 1: Redundant directly connected interfaces
As an example, in figure 1 both R and T are configured with
replication segments. There are two interface between R and T. One
can be used as primary and second as a bypass in case the primary
interface is down. There can be 2 method to protect the primary
interface.
* The two replication segments on R and T can take advantage of
unicast SR to connect to each other. In this case the LFA of
unicast SR can be utilize to protect the primary interface between
R and T.
* The replication segment provides protection nexthop, the
protection nexthop can be programmed to take the alternate
interface between R and T to protect the primary interface.
R---F1
| |
T---F2
|
---
| |
L1 L2
Figure 2: Protection through alternative network path
Bidgoli, et al. Expires 23 August 2025 [Page 15]
Internet-Draft PCEP p2mp sr policy February 2025
As a second example, in Figure 2 R and T connected directly and via
network F1..F2. In this example as per example 1, unicast SR can be
used to connect the two Replication segments, including using SR LFA
or R-LFA or TI-LFA to protect the direct link between R-T via F1. If
no unicast SR is available within the network, the PCE optionally can
establish a shared replication point on F1 and F2 and protect all
path-instances that are traversing R-T via this shared Replication
segment.
In addition, Penultimate Hop Popping (PHP) and implicit null label on
the bypass path can be implemented to reduce the PCE programming on
the merge point (MP) PCC.
4.3.7. Connecting Replication Segment via Segment List
There could be many nodes between two Replication Segments that do
not support P2MP Policy or Replication Segment. It is possible to
connect two non-adjacent Replication segments via a unicast SR path
using a SID list and rely on IGP forwarding. The SID list can be
comprised of any IGP supported segment types (ex: Binding, Adjacency,
Node). This information is encoded via the SR-ERO sub-objects and
ERO-attributes objects. The last segment in an encoding SID list
MUST be a Replication segment
4.3.8. Tree Deletion
The P2MP policy and its replication segment can be delete by the PCC
or by the PCE. to delete the P2MP policy all the Candidate paths
associated to that P2MP policy need to be deleted. The last
Candidate path that is being deleted, will delete the P2MP Policy
Instance as well on the PCE or PCC.
To delete Candidate paths there are two methods:
1. The Candidate paths can be deleted by deleting all the path-
instances associated with them and the last path-instance that is
deleted will trigger the Candidate path to be deleted.
2. The Candidate path can be deleted entirely and this will delete
all the associated path-instances for that candidate path as
well.
Bidgoli, et al. Expires 23 August 2025 [Page 16]
Internet-Draft PCEP p2mp sr policy February 2025
4.3.8.1. PCC Initiated
For PCC to delete a Candidate path, Root send a PCRpt message with
the R bit of the LSP object set and all the fields of the SR-P2MP-
LSP-ID TLV set to 0 (indicating to remove all state and path-
instances associated with this P2MP tunnel). The PCE in response
sends a PcInitiate message with R bit in the SRP object set to all
nodes along the path to indicate deletion of the entries. In this
case the Instance-ID can be set 0 with the R bit set to indicate
removing the entire Candidate path and all its path-instances.
For PCC to delete a path-instance, Root send a PCRpt message with the
R bit of the LSP object set and all the fields of the SR-P2MP- LSP-ID
TLV set to 0 but the instance-id value (indicating to remove the
specific path-instances associated with this P2MP tunnel). The PCE
in response sends a PCInitiate message with R bit in the SRP object
SET to all nodes along the path to indicate deletion of the entries.
Note in this case the instance-id has to be set accordingly with the
R bit set to indicate removing the specific path-instances. This is
useful for the global optimization case where after downloading the
optimize path-instance and ensuring the path-instance is operational
the PCC removed that old path-instance.
4.3.8.2. PCE Initiated
When PCE is deleting a Candidate path or a path instance it should
delete all the replication segments of that Candidate path or path-
instance as well before it moves to the next Candidate path or path
instance.
4.3.9. Fragmentation
The Fragmentation bit in the LSP object (F bit) can be used to
indicate a fragmented PCEP message.
4.4. PCEP Messages
The objects and TLV's defined in this document can be included in
PCRpt, PcInitiate and PCUpd messages. The inclusion of the Objects
and TLVs differ between SR P2MP Policy and Replication segment.
4.4.1. SR P2MP Policy
The format of the PCRpt message is updated as follows:
Bidgoli, et al. Expires 23 August 2025 [Page 17]
Internet-Draft PCEP p2mp sr policy February 2025
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::=
<state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
[<association-list>]
[<end-point-list>]
where:
<SRP> is defined in RFC8231
<LSP> is defined in [RFC8231] section 5.5.1
<association-list> ::=
<ASSOCIATION> [<association-list>]
<end-point-list> ::= [<P2MP-END-POINTS>]
Where:
<ASSOCIATION>
is described in this doc
<P2MP-END-POINTS>
is described in this doc
The format of the PCUpd message is updated as follows:
Bidgoli, et al. Expires 23 August 2025 [Page 18]
Internet-Draft PCEP p2mp sr policy February 2025
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>
[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
[<end-point-list>]
Where:
<SRP> is defined in [RFC8231]
<LSP> is defined in [RFC8231]section 5.5.1
<end-point-list> ::= [<P2MP-END-POINTS>]
Where:
<P2MP-END-POINTS> is described in this doc
The format of the PCInitiate message is updated as follows:
Bidgoli, et al. Expires 23 August 2025 [Page 19]
Internet-Draft PCEP p2mp sr policy February 2025
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::=
<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
<association-list>
<end-point-list>
Where:
<SRP> is defined in RFC8231
<LSP> is defined in [RFC8231] in section 5.5.1
<association-list> ::=
<ASSOCIATION> [<association-list>]
<end-point-list> ::= [<P2MP-END-POINTS>]
Where:
<ASSOCIATION> is described in this doc
<P2MP-END-POINTS> is described in in this doc
4.4.2. Replication Segment
The Replication Segment can be constructed via the following PCRpt,
PCUpd and PCInitiate messages
NOTE:
* Replication segment does not use a association object
The format of the PCRpt message is updated as follows:
Bidgoli, et al. Expires 23 August 2025 [Page 20]
Internet-Draft PCEP p2mp sr policy February 2025
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::=
<state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<CCI>
<intended-path>
Where:
<SRP> is defined in [RFC8231]
<LSP> is defined in [RFC8231] section 5.5.1
<CCI> is defined in this doc
<intended-path> ::=
((<PATH-ATTRIB><ERO>)[<intended-path>])
Where:
<PATH-ATTRIB-ERO> is defined in [draft-ietf-pce-multipath]
<ERO> is defined in [RFC8664]
The format of the PCUpd message is updated as follows:
Bidgoli, et al. Expires 23 August 2025 [Page 21]
Internet-Draft PCEP p2mp sr policy February 2025
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>
[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<CCI>
<intended-path>
Where:
<SRP> is defined in [RFC8231]
<LSP> is defined in [RFC8231] section 5.5.1
<CCI> is defined in this doc
<intended-path> ::=
((<PATH-ATTRIB><ERO>)[<intended-path>])
Where:
<PATH-ATTRIB-ERO> is defined in [draft-ietf-pce-multipath]
<ERO> is defined in [RFC8664]
The format of the PCInitiate message is updated as follows:
Bidgoli, et al. Expires 23 August 2025 [Page 22]
Internet-Draft PCEP p2mp sr policy February 2025
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::=
(<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<CCI>]
[<intended-path>]
Where:
<SRP> is defined in RFC8231
<LSP> is defined in [RFC8231] section 5.5.1
<CCI> is defined in section 4.4.3.3
<intended-path> ::=
((<PATH-ATTRIB><ERO>)[<intended-path>])
Where:
<PATH-ATTRIB-ERO> is defined in [draft-ietf-pce-multipath]
<ERO> is defined in [RFC8664]
<PCE-initiated-lsp-deletion> is as per [RFC8281].
<attribute-list> is as per [RFC8281].
4.4.3. Considerations
A SR P2MP Policy supports add, remove, and full replace of Leaf nodes
in a message, described further in section 5.5.2 and with an example
in section 8.1. However, a Candidate Path and Replication Segment
MUST NOT carry delta information. Every PcRpt, PcInitiate and PCUpd
message MUST contain the full list of the Leaf nodes, and Segment
forwarding information that is needed to build the Candidate path and
its Replication segments. This is necessary to ensure that PCE or
any new PCE is in sync with the PCC.
Bidgoli, et al. Expires 23 August 2025 [Page 23]
Internet-Draft PCEP p2mp sr policy February 2025
4.4.3.1. Path Attribute Object
This document uses [draft-ietf-pce-multipath] to identify each out-
going interface in the Replication Segment. In addition each out-
going interface can be protected by a backup path. The Path
Attributes Object is used to provide the relation between the primary
path and its backup path as per draft [draft-ietf-pce-multipath].
Note: Multipath weight TLV MUST NOT be used and SHOULD be ignored
when revived. Composite Candidate Path TLV SHOULD NOT be present and
SHOULD BE ignored if present.
When a replication segment is being updated or new out-going
interfaces are added to a specific replication segment, the PCRpt,
PCInitiate and PCUpd messages sent via PCEP, maintains the previous
ERO Path IDs and generates new Path IDs for new instructions. The
PATH IDs are maintained for each specific forwarding instructions
until the instructions are deleted. For example: When the first leaf
is added, the PCE will update with Path ID 1 to the PCC. When the
second leaf is added, according to the path calculated, PCE might
just append the existing instruction Path ID 1 with a new Path ID 2
to construct the new PCUpd message.
4.4.3.2. CCI Object
The Central Control Instruction (CCI) Object is used to identify the
entire cross connect of Explicit Route Object (ERO) which consist of
incoming Replication SID and the set of outgoing Interfaces and their
corresponding SIDs and/or SID lists. Any modification to this
instruction should use this CCI ID to identify the cross connect
uniquely. Leaf nodes and their corresponding Path IDs can be removed
from the cross connect identified via the CCI. The CC-ID is assigned
by the PCE.
The CCI Object used by the PCE to specify the controller instructions
is defined in [RFC9050].
[draft-ietf-pce-pcep-extension-pce-controller-sr] defines CCI object-
type for SR-MPLS. This document redefines a new version of the SR-
MPLS CCI object-type for SR P2MP Policy in upcoming sections.
5. Object Format
5.1. Open Message Extension
A PCEP speaker indicates its ability to support SR P2MP Policy and
Replication Segment during the PCEP initialization phase. Speakers
which support SR P2MP Policy and Replication segment object MUST
include SR-P2MP-POLICY-CAPABILITY TLV in the OPEN Object.
Bidgoli, et al. Expires 23 August 2025 [Page 24]
Internet-Draft PCEP p2mp sr policy February 2025
This draft defines a new SR-P2MP capability TLV with type TBD
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Instances | number of replication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD
Length: 4
Number of Instances 16 bits - Number of instances the advertising
PCEP speaker supports. This is meaningful for PCEs. PCEs can
determine the least number of instances that could be created for a
SR P2MP policy.
Number of replication 16 bits - number of out going interfaces that
the system is capable of having per multicast state.
Flags 16 bits - No Flags currently defined
Upon the receipt of an Open message, the receiving PCEP peer MUST
determine whether the suggested PCEP session characteristics (leaf-
types) are acceptable. If the suggested leaf-types are not
acceptable to the receiving peer, it MUST send an PCEP Error message
(PCErr) with Error-Type=2 (Capability not supported) and error-value
X (new error type assigned by IANA incompatible SR P2MP leaf types)
(See Section 5.5.2 for leaf-types)
5.2. PCE Capabliity SubTLV
If a PCEP speaker advertises SR P2MP Policy Capability then it MUST
include the PST = 1 in the PATH-SETUP-TYPE-CAPABILITY TLV as per
[RFC8664]
5.3. Association Type Capability
A Assoc-Type-List TLV as per [RFC8697] section 3.4 should be send via
PCEP open object with following association type
Bidgoli, et al. Expires 23 August 2025 [Page 25]
Internet-Draft PCEP p2mp sr policy February 2025
+-------------------+----------------------------+------------------+
| Association Type | Association Name | Reference |
| Value | | |
+-------------------+----------------------------+------------------+
| TBD1 | P2MP SR Policy Association | This document |
+-------------------+----------------------------+------------------+
OP-CONF-Assoc-RANGE (Operator-configured Association Range)should not
be set for this association type and must be ignored.
5.4. Symbolic Name TLV
This document reuses symbolic path name from [RFC8231] section 7.3.2.
For P2MP Policy a symbolic path is unique for a Candidate Path of the
P2MP Policy on the PCC. It is RECOMMENDED for the symbolic path name
to be Root-ID, Tree-ID and Candidate path Discriminator values.
5.5. SR P2MP Policy
5.5.1. P2MP Policy Association Group
Two ASSOCIATION object types for IPv4 and IPv6 are defined in
[RFC8697]. The ASSOCIATION object includes "Association type"
indicating the type of the association group. This document adds a
new Association type. Association type = TBD1 "P2MP SR Policy
Association Type" for SR Policy Association Group (P2MP SRPAG).
For PCC-initiated SR P2MP Policy, the ASSOCIATION object is present
in the first PCRpt message that is sent by the PCC to PCE to indicate
the existence of the SR P2MP Policy and its Candidate path. This
first PCRpt message does not have a corresponding PCUpdate message
but it does include the Association object accordingly.
The Association Source SHOULD be set to the root address of the P2MP
tree.
In par with [draft-ietf-pce-segment-routing-policy-cp] section 4.2,
P2MP policy reuses the four TLVs used in the SRPA object. P2MP
policy also redefines the extended association ID TLV:
1. SRPOLICY-POL-NAME TLV: (optional) encodes P2MP SR Policy Name
2. SRPOLICY-CPATH-ID TLV: (mandatory) encodes P2MP SR Policy
Candidate path Identifier
3. SRPOLICY-CPATH-NAME TLV: (optional) encodes P2MP SR Policy
Candidate path name.
Bidgoli, et al. Expires 23 August 2025 [Page 26]
Internet-Draft PCEP p2mp sr policy February 2025
4. SRPOLICY-CPATH-PREFRENCE TLV: (optional) encodes P2MP SR Policy
Candidate path preference value.
5. In addition to above the extended association ID TLV has been
modified to address the P2MP Policy
5.5.1.1. Extended Association ID TLV
In par with [draft-ietf-pce-segment-routing-policy-cp] the Extended
Association ID TLV MUST be included and it MUST be in the following
format for the P2MP Policy
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 31 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TREE-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 4 byte
Tree-ID: identifies the P2MP Tree which the Replication segment is
part of
5.5.2. P2MP-END-POINTS Object
In order for the Root node to indicate operations of its Leaf nodes
(Add/Remove/Replace-all), the PcRpt and PcInit messages are extended
to include P2MP End Point <P2MP End-points> Object which is defined
in [RFC8306]
The absence of the P2MP-END-POINTS Object means that there is no
change in the leaf endpoint of the policy and the PCEP speaker MUST
NOT consider the absence of the object as an indication of removal of
the endpoints.
Bidgoli, et al. Expires 23 August 2025 [Page 27]
Internet-Draft PCEP p2mp sr policy February 2025
IPV4-P2MP END-POINTS:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPV6-P2MP END-POINTS:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Leaf type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Leaf Types (derived from [RFC8306] section 3.3.2) :
1. New leaves to add (leaf type = 1)
2. Old leaves to remove (leaf type = 2)
3. the entire pce leaf list is overwritten and replaced with the new
leaf list (leaf type = 5)
Note a PCE speaking node MUST NOT combine leaf type 1 and 2 with leaf
type 5.
Bidgoli, et al. Expires 23 August 2025 [Page 28]
Internet-Draft PCEP p2mp sr policy February 2025
Note a PCE speaking node SHOULD NOT have the same node present in the
leaf type 1 and 2 if both leaf types are present.
A given P2MP END-POINTS object gathers the Leaf nodes of a given
type. A SR P2MP PcRpt MAY mix different types of Leaf nodes by
including several P2MP END-POINTS objects. The END-POINTS object
body has a variable length. These are multiples of 4 bytes for IPv4,
multiples of 16 bytes, plus 4 bytes, for IPv6.
5.6. P2MP Policy and Replication Segment Identifier Object and TLV
Both P2MP Policy and Replication Segment are identified via the LSP
object and more precisely via the SR-P2MP-LSPID-TLV
The P2MP Policy uses the PLSP-ID to identify the Candidate Paths and
the Instance-ID to identify a Path-Instance with in the Candidate
path.
A Replication Segment uses the SR-P2MP-LSPID-TLV to identify and
correlate a Replication Segment to a P2MP Policy
As it was noted previously, for the Root the P2MP Policy and the
Replication Segment is downloaded via the same PCUpd message.
5.6.1. Extension of the LSP Object, SR-P2MP-LSPID-TLV
The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies
the PLSP-ID to uniquely identify an LSP that is constant for the life
time of a PCEP session. Similarly, for a P2MP Policy, the PLSP-ID
identify a Candidate Path uniquely with in the P2MP policy.
The LSP Object MUST include the new SR-P2MP-INSTANCE-ID-TLV (IPV4/
IpV6) defined in this document below. This is a variation to the
P2MP object defined in [draft-ietf-pce-stateful-pce-p2mp]
Bidgoli, et al. Expires 23 August 2025 [Page 29]
Internet-Draft PCEP p2mp sr policy February 2025
IPV4-SR-P2MP-INSTANCE-ID-TLV:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance-ID | Reserved | Flags |R|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6-SR-P2MP-INSTANCE-ID-TLV :
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Root |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance-ID | Reserved | Flags |R|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type (16-bit) of the TLV is TBD (need allocation by IANA).
Root: Source Router IP Address
Tree-ID: Unique Identifier of this P2MP LSP on the Root.
Instance-ID : Contains 32 Bit instance ID. Instance-id 0 is
reserved.
Reserved: 8 bits reserved for future use.
Flags: 8 bits, A - Activate the Instance-ID, R - Remove the Instance-
ID
Bidgoli, et al. Expires 23 August 2025 [Page 30]
Internet-Draft PCEP p2mp sr policy February 2025
At any given time, only one instance MUST be active. Activating one
instance entails deactivating all other instances, with the condition
that the active instance MUST have a non-zero value.
The (A) flag is meaningful for Root PCC and PCE. PCE MUST be setting
(A) flag in the PCUpd containing SR-P2MP-INSTANCE-ID TLV for
activating the instance. The decision regarding when to set the (A)
flag can be made locally on the PCE. E.g., this decision can be
based on factors such as receiving PCRpt messages from all PCCs for
the new instance or utilizing a timer-based approach to ensure that
the data plane is completely configured on all PCCs. It's important
to note that determining the appropriate timing for activating the
new instance is not within the scope of this document. After the
activation of the P2MP Policy any PCUpd MUST include the (A) flag in
the P2MP-Instance TLV.
Root PCC MUST set the (A) flag in the PCRpt as a response to
receiving a PCUpd message with the (A) flag set.
If a PCE receives a PCRpt with the (A) flag set in response to a
PCUpd message that did not have the (A) flag set, then PCE MUST treat
this as an error. In such a case, PCE MUST send an PCEP Error
message (PCErr) with Error-Type=10 (Reception of an Invalid Object)
and error-value (X) (Invalid active instance).
For Transit or Leaf PCCs, receipt of a PCUpd message with the (A)
flag MUST be treated as an error. Transit or Leaf PCCs MUST send an
PCEP Error message (PCErr) with Error-Type=19 (Invalid Operation) and
error-value (X) (Attempted activating instance on Transit or leaf
PCC).
Figure 3 presents an example exchange of SR-P2MP-LSPID-TLV.
Bidgoli, et al. Expires 23 August 2025 [Page 31]
Internet-Draft PCEP p2mp sr policy February 2025
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
1) LSP state Report | -------- PCRpt ------> |
With PLSP-ID and | (SRP, |
Instance ID | LSP (SR-P2MP-LSPID), |
| P2MP-END-POINT) |
| |
| <------- PCUpd ------- |2) PCUpd message sent
| (SRP, | to the PCC with
| LSP (SR-P2MP-LSPID), | Path info and activating
| Association, | instance.
| P2MP SR Pol. ID TLV, |
| CPATH_ID TLV, |
| P2MP-END-POINT, |
| CCI, PATH_ATTRIB, |
| SR-ERO) |
| |
| |
3) LSP State Report |---- PCRpt message ---->|
(echoing Instance | |
Active) | |
| |
5.7. Replication Segment
As per [RFC9524] a replication segment has a next-hop-group which MAY
contain a single outgoing replication SID or a list of SIDs (sr-
policy-sid-list) In either case there needs to be a replication SID
identifying the replication state on a downstream replication node.
Two replication segments can be directly connected or connected via a
unicast SR domain.
5.7.1. Message format
The format of a Replication Segment message encoding is similar to
P2MP Policy. However, the P2MP Policy contains the association
object and the replication segment message does not contain the
association object. In addition, the replication segment carries the
CCI object to identify a P2MP cross connect. The Replication segment
is distributed individually to the Root, Transit and Leaf nodes
without the P2MP Policy. The replication segment uses SR-P2MP-LSPID-
TLV as its identifier. The TLV is coded differently for shared and
non-shared case
Bidgoli, et al. Expires 23 August 2025 [Page 32]
Internet-Draft PCEP p2mp sr policy February 2025
5.7.2. CCI Object
The CCI Object as defined in [RFC9050] is used to identify a
forwarding instruction in the Replication Segment. A forwarding
instruction is incoming SID and a set of outgoing branches.
The CCI Object can be include in Reports, initiate and Update
messages for Replication Segments.
This document redefines a new version of the SR-MPLS CCI object-type
[draft-ietf-pce-pcep-extension-pce-controller-sr] for P2MP Policy.
The label in the CCI Object is the incoming SID. The outgoing SIDs
are defined by the ERO Objects.
CCI Object-Type is TBD6 for SR P2MP Policy.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | Algorithm | role | flags |V|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index |
+---------------------------------------------------------------+
| |
// Optional TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags:
The V and the L flags are defined as per
[draft-ietf-pce-pcep-extension-pce-controller-sr]
The node action and role of ingress, transit, leaf or bud, is
indicated via the 4 bit roles field
* Head, role type = 1
* Transit, role type = 2
* Leaf, role type = 3
* Bud, role type = 4
Bidgoli, et al. Expires 23 August 2025 [Page 33]
Internet-Draft PCEP p2mp sr policy February 2025
5.7.3. SR-ERO Rules
Forwarding information of a replication segment can be configured and
steered via many different mechanisms. RFC [RFC8664] defines the NAI
types.
As an example a replication SID can be steered via:
1. Replication SID steered with an IPv4/IPv6 directly connected
nexthop (RFC 8664 NAI type 3, 4, 6 (adjacency))
* In this case there will two SR-ERO in the ERO Object, with the
Replication SID SR-ERO at the bottom and the IPv4/IPv6 SR-ERO
on the top.
2. Replication SID steered with an IPv4/IPv6 loopback address that
reside on the directly connected router. (NAI type 1..2 (node))
* In this case there will two SR-ERO in the ERO Object, with the
Replication SID SR-ERO at the bottom and the IPv4/IPv6 SR-ERO
on the top.
3. Replication SID steered with unnumbered IPv4/IPv6 directly
connected Interface (NAI type 5 (adjacency unnumbered)
4. Replication SID steered via a SR adjacency or node SID
* In this case even a sid-list can be used to traffic engineer
the path between two Replication Segment
* The Replication SID SR-ERO is at the bottom while the segments
describing the path are on top in order.
6. IANA Consideration
6.1. PCEP P2MP Association type
This draft defines a new Association type for P2MP SR Policy. IANA
is requested to allocate a new value from the existing IANA Registry
"ASSOCIATION TYPE Field" within the "Path Computation Element
Protocol (PCEP) Numbers" registry group.
+----------+----------------------------+-----------------+
| Type | Name | Reference |
+----------+----------------------------+-----------------+
| TBD1 | P2MP SR Policy Association | This document |
+----------+----------------------------+-----------------+
Bidgoli, et al. Expires 23 August 2025 [Page 34]
Internet-Draft PCEP p2mp sr policy February 2025
6.2. Endpoint Type
[RFC8306] specified the P2MP END-POINTS object but did not create a
registry for the 32-bit Leaf type field. This document establishes
the registry and populates it with values from [RFC8306] and adds a
new Leaf type. IANA is requested to create a new "Endpoint Leaf
Types" registry with the allocation policy as IETF Review [RFC8126].
This new registry contains the following values:
+----------+----------------------------+-----------------+
| Value | Description | Reference |
+----------+----------------------------+-----------------+
| 0 | Reserved | This document |
+----------+----------------------------+-----------------+
| 1 | New leaves to add | RFC 8306 |
+----------+----------------------------+-----------------+
| 2 | Old leaves to remove | RFC 8306 |
+----------+----------------------------+-----------------+
| 3 | Old leaves whose path can | RFC 8306 |
| | be modified/reoptimized | |
+----------+----------------------------+-----------------+
| 4 | Old leaves whose path must | RFC 8306 |
| | be left unchanged | |
+----------+----------------------------+-----------------+
| 5 | All old leaves overwritten | This document |
| | and replaced with the new | |
+----------+----------------------------+-----------------+
To keep it consistent with the Generalized Endpoint Types [RFC8779],
this draft defines a new Endpoint Type in the "Generalized Endpoint
Types" registry as follows:
+-----------+---------------------+-----------------+
| Value | Type | Reference |
+-----------+---------------------+-----------------+
| TBD2 | Point-to-Multipoint | This document |
| | with leaf type 5 | |
+-----------+---------------------+-----------------+
The Authors are requesting value 5 for this new endpoint type.
6.3. PCEP TLV Type Indicators
This draft extends the PCEP OPEN object by defining a new optional
TLV to indicate the PCE's capability to perform SR-P2MP path
computation.
Bidgoli, et al. Expires 23 August 2025 [Page 35]
Internet-Draft PCEP p2mp sr policy February 2025
Further, this draft defines two new TLVs for Identifying the P2MP
Policy and the Replication segment with IPv4 or IPv6 root address.
IANA is requested to allocate a new value from the IANA Registry
"PCEP TLV Type Indicators"
+------------+------------------------------+----------------+
| TLV Type | Description | Reference |
| Value | | |
+------------+------------------------------+----------------+
| TBD3 | SR-P2MP-POLICY-CAPABILITY | This document |
+------------+------------------------------+----------------+
| TBD4 | IPV4-SR-P2MP-INSTANCE-ID TLV | This document |
+------------+------------------------------+----------------+
| TBD5 | IPV6-SR-P2MP-INSTANCE-ID TLV | This document |
+------------+------------------------------+----------------+
6.4. New CCI Object Type
This draft defines a new CCI Object type SR P2MP Policy.
IANA is requested to allocate new codepoints in the "PCEP Objects"
sub-registry as follows:
+-------------+----------------------+----------------+
| Object Class| Name | Reference |
| Value | | |
+-------------+----------------------+----------------+
| 44 | CCI Object | |
| | Object-Type | |
| | TBD6: SR P2MP Policy | This document |
+-------------+----------------------+----------------+
7. Security Considerations
The security considerations described in [RFC5440], [RFC8231],
[RFC8281], [RFC8664], [RFC8697], [RFC9256] and [RFC9524] are
applicable to this specification.
As per [RFC8231], it is RECOMMENDED that these PCEP extensions can
only be activated on authenticated and encrypted sessions across PCEs
and PCCs belonging to the same administrative authority, using
Transport Layer Security (TLS) [RFC8253].
No additional security measures are required for SR P2MP Policy.
Bidgoli, et al. Expires 23 August 2025 [Page 36]
Internet-Draft PCEP p2mp sr policy February 2025
8. Manageability Considerations
All manageability requirements and considerations listed in
[RFC5440], [RFC8231], [RFC8664], and [RFC9256] apply to PCEP protocol
extensions defined in this document. In addition, requirements and
considerations listed in this section apply.
8.1. Control of Function and Policy
TBD
8.2. Information and Data Models
TBD
8.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440], [RFC8664] and [RFC9256].
8.4. Verify Correct Operations
Operation verification requirements already listed in [RFC5440],
[RFC8231], [RFC8664], [RFC9256] are applicable to mechanisms defined
in this document.
An implementation MUST allow the operator to view SR P2MP Policy
Identifier and each SR Replication segment Candidate path Identifier
advertised in PCEP.
An implementation SHOULD allow the operator to view the capabilities
defined in this document.
An implementation SHOULD allow the operator to view each Replication
segment Candidate path associated with specific SR P2MP Policy.
8.5. Requirements On Other Protocols
The PCEP extensions defined in this document do not imply any new
requirements on other protocols.
8.6. Impact On Network Operations
The mechanisms defined in [RFC5440], [RFC8231], [RFC9256] also apply
to the PCEP extensions defined in this document.
Bidgoli, et al. Expires 23 August 2025 [Page 37]
Internet-Draft PCEP p2mp sr policy February 2025
9. Acknowledgments
The authors would like to thank Tanmoy Kundu and Stone Andrew at
Nokia and Tarek Saad at Cisco for their feedback and major
contribution to this draft.
10. Contributors
Tarek Saad
Cisco Systems
Email: tsaad.net@gmail.com
Saranya Rajarathinam
Saranya Rajarathinam
Nokia
Email: saranya.Rajarathinam@nokia.com
11. References
11.1. Normative References
[draft-ietf-pce-multipath]
"M. Koldychev, S. Sivabalan, T. Saad, H. Bidgoli, B.
Yadav, S. Peng, G. Mishra "PCEP Extensions for Signaling
Multipath Information"", November 2022.
[draft-ietf-pim-sr-p2mp-policy]
"D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang,
"Segment Routing Point-to-Multipoint Policy"", October
2019.
[RFC2119] ""Key words for use in RFCs to Indicate Requirement
Levels"", March 1997.
[RFC3209] "D. Awduche, L. Berger, T. Li, V. Srinivasan, G. Swallow
"RSVP-TE: Extensions to RSVP for LSP Tunnels"", December
2001.
[RFC5440] "JP. Vasseur, JL. Le Roux "Path Computation Element (PCE)
Communication Protocol (PCEP)"", March 2009.
[RFC6513] "E. Rosen, R. Aggerwal "Multicast in MPLS/BGP IP VPNs"",
February 2012.
[RFC7988] "E. Rosen, K. Subramanian, Z. Zhang "Ingress Replication
Tunnels in Multicast VPN"", October 2016.
Bidgoli, et al. Expires 23 August 2025 [Page 38]
Internet-Draft PCEP p2mp sr policy February 2025
[RFC8126] "M. Cotton, B. Leiba, T. Narten "Guidelines for Writing an
IANA Considerations Section in RFCs"", June 2017.
[RFC8174] ""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
Words"", May 2017.
[RFC8231] "E. Crabbe, I. Minei, J. Medved, R. Varga "PCEP Extensions
for Stateful PCE"", September 2017.
[RFC8253] "D. Lopez, Q. Wu. D.Dhody "Usage of TLS to Provide a
Secure Transport for the PCEP"", October 2017.
[RFC8281] "E. Crabbe, I. Minei, S. Sivabalan, R. Varga "PCEP
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model"", December 2017.
[RFC8306] "Q. Zhao, D. Dhody, R. Palleti, D.King "PCEP for Point-to-
Multipoint Traffic Engineering Label Switched Paths"",
November 2017.
[RFC8664] "S. Sivabalan, C. Filsfils, J. Tantsura, W. Henderickx, J.
Hardwick "PCEP Extensions for Segment Routing"", December
2019.
[RFC8697] "I. Minei, E. Crabbe, S. Sivabalan, H. Ananthakrishnan, D.
Dhody, Y. Tanaka "PCEP Extensions for Establishing
Relationships between Sets of LSPs"", January 2020.
[RFC8779] "C. Margaria, O. Gonzalez, F. Zhang "PCEP extensions for
GMPLS"", July 2020.
[RFC9050] "Z. Li, S. Peng, M. Negi, Q. Zhao, C. Zhou "PCEP
Procedures and Extensions for Using the PCECC"", July
2021.
[RFC9256] "C. Filsfils, K. Talaulikar, D. Voyer, A. Bogdanov, P.
Mattes "Segment Routing Policy Architecture"", July 2022.
[RFC9524] "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, "SR
Replication Segment for Multi-point Service Delivery"",
July 2020.
11.2. Informative References
[draft-hb-spring-sr-p2mp-policy-yang]
"H.Bidgoli, D. Yoyer, R. Parekh, T.Saad, T.kundu "YANG
Data Model for p2mp sr policy"", October 2020.
Bidgoli, et al. Expires 23 August 2025 [Page 39]
Internet-Draft PCEP p2mp sr policy February 2025
[draft-ietf-pce-pcep-extension-pce-controller-sr]
"Z. Li, S. Peng, M. negi, Q. Zhao, C. Zhau "PCEP
Extensions for Using PCE as a PCECC for SR MPLS SID"".
[draft-ietf-pce-segment-routing-policy-cp]
"M. Koldychev, S. Sivabalan, C. Barth, S. Peng, H. Bidgoli
"PCEP extension to support Segment Routing Policy
Candidate Paths", October 2022.
[draft-ietf-pce-stateful-pce-p2mp]
"U. Palle, D. Dhody, Y.Tanaka, V. Beeram "Protocol
Extensions for Stateful PCE usage for Point-to-Multipoint
Traffic Engineering Label"", April 2019.
Appendix A. Packet Examples
A.1. Report for Leaf Add
This is an example of PCC initiated P2MP Policy. The PCC will send a
Report message to the PCE to initiat a P2MP Policy with a set of
leaves that are discovered via Next Generation MVPN procedures as per
[RFC6513].
In addition, since the PCC is initiating the P2MP Policy, it does
populate the PLSP-ID for the candidate path. PCC will leave the
instance-id for the Path-Instance to 0 and the instance-id is
assigned by the PCE.
Bidgoli, et al. Expires 23 August 2025 [Page 40]
Internet-Draft PCEP p2mp sr policy February 2025
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 28 (PathSetupType)| TLV Len = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PST = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<LSP OBJECT>
| PLSP-ID = 1 | A:1,D:1,N:1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=17 | Length=<var> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| symbolic path name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root = A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-ID = Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance-ID = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<P2MP END POINT OBJECT>
| Leaf type = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address = A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address = D |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address = E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2. P2MP Policy Candidate path Init
The following packet is the PCE creating the candidate path for the
P2MP Policy and downloading the replication segment with the same
message on the root.
It should be noted combining the P2MP Policy candidate path creation
and replication segment only is possible on the root.
As such this message contains both association object and the CCI
object. The CCI Object contains the incoming Binding SID and wraps
all the Path Attribute messages and their corresponding EROs.
Bidgoli, et al. Expires 23 August 2025 [Page 41]
Internet-Draft PCEP p2mp sr policy February 2025
The PLSP-ID are populated with the same ID as the previous PCC report
message and the Instance-ID is assigned by the PCE.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 28 (PathSetupType)| TLV Len = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PST = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<LSP OBJECT>
| PLSP-ID = 1 | A:1,D:1,N:1,C:0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=17 | Length=<var> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| symbolic path name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root =A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-ID = Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance-ID = L1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<ASSOCIATION OBJECT>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association type= SR-P2MP-PAG | Association ID = z |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source = <pce-address> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=P2MP SR Policy ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root = A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TREE-ID = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=P2MP SR Policy Name | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ P2MP SR Policy Name ~
| |
Bidgoli, et al. Expires 23 August 2025 [Page 42]
Internet-Draft PCEP p2mp sr policy February 2025
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=P2MP SR Pol Cand-path ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ProtOrigin 10 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originator Address = <pce-address> |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=P2MP SR Pol Cand-path Name| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ P2MP SR Policy Candidate Path Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=P2MP SR Pol Cand-Path Pre | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference = 100 <default> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<P2MP END POINT OBJECT>
| Leaf type = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address = A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address = D |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address = E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<CCI OBJECT>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Flags |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label = 0 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<PATH-ATTRIBUTES OBJECT>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Oper|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bidgoli, et al. Expires 23 August 2025 [Page 43]
Internet-Draft PCEP p2mp sr policy February 2025
| ERO-path Id = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Path Count = 1 | Flags |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Path ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=Node Role | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Role = ingress | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<ERO-OBJECT>
<SR-ERO-SUB OBJECT>
|L| Type=36 | Length | NT= 1| Flags |0|0|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipv4-address = NHD1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=36 | Length | NT= 0| Flags |0|1|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID = d1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<PATH-ATTRIBUTES OBJECT>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Oper|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERO-path Id = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Path Count = 0 | Flags |1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Role = ingress | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<ERO-OBJECT>
<SR-ERO-SUB OBJECT>
|L| Type=36 | Length | NT= 1| Flags |0|0|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipv4-address = NHD2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=36 | Length | NT= 0| Flags |0|1|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID = d2 |
Bidgoli, et al. Expires 23 August 2025 [Page 44]
Internet-Draft PCEP p2mp sr policy February 2025
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.3. Replication segment PCE Initiated on Transit and LEaves
The following packet examples shows the replication segment
initiation via a PCE on transit nodes and/or leaves node.
Note:
1. This packet is generated from PCE to instantiate the replication
segment, as such the PLSP-ID is set to zero. PCC will assign
these value and report them back to PCE.
2. The instance-id was assigned by the PCE for the entire path-
instance (P2MP tree)
3. This is a replication segment instantiation as such there is no
association object.
4. The LSP Object Root A and Tree-ID Y associates this replication
segment to the corresponding Candidate path and path instance on
the root node.
there is no association object present in the packet.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 28 (PathSetupType)| TLV Len = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PST = TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<LSP OBJECT>
| PLSP-ID = 0 | A:1,D:1,N:1,C:0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=17 | Length=<var> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| symbolic path name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root =A |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-ID = Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bidgoli, et al. Expires 23 August 2025 [Page 45]
Internet-Draft PCEP p2mp sr policy February 2025
| Instance-ID = L1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<CCI OBJECT>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID = X |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Flags |0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label = d1 | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<PATH-ATTRIBUTES OBJECT>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Oper|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERO-path Id = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Path Count = 1 | Flags |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Path ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Role | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<ERO-OBJECT>
<SR-ERO-SUB OBJECT>
|L| Type=36 | Length | NT= 1| Flags |0|0|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipv4-address = NHE1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=36 | Length | NT= 0| Flags |0|1|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID = e1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<PATH-ATTRIBUTES OBJECT>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Oper|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERO-path Id = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bidgoli, et al. Expires 23 August 2025 [Page 46]
Internet-Draft PCEP p2mp sr policy February 2025
| Backup Path Count = 0 | Flags |1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Role | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<ERO-OBJECT>
<SR-ERO-SUB OBJECT>
|L| Type=36 | Length | NT= 1| Flags |0|0|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ipv4-address = NHE2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=36 | Length | NT= 0| Flags |0|1|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID = e2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B. Example Workflows
+-------+ +-------+
|PCC | | PCE |
|Root | +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | |---PCRpt,PLSP-ID=1,SRP-ID=1--------->| PCECC LSP
|PCC +--------+ | N=1,root-addr,Tree-ID=a, | SR-Policy
| | | | Instance-ID =0, | Report to
|Leaf | | | P2MP-end-points(LeafType=5)(optnl)| PCE
+--------+ | | association-obj |
| | | |
| | |<--PCUpdate,PLSP-ID=1, SRP-ID =1, | Update
| | | root-addr,Tree-ID=a,Instance-ID=b,| CP
| | | P2MP-end-points, association-obj |
| | | |
| | |-------PCRpt,PLSP-ID=1, SRP-ID = 1,->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | P2MP-end-points(LeafType=5) |
| | | association-object |
| | | |
|<---------------PcInitiate,PLSP-ID=0, -------------| Download
| | | root-addr,Tree-ID=a,Instance-ID=b,| Leaf
| | | CC-ID=Z,C=0, | Replication
| | | O=0,L=z,path-attribute,ERO,SR-ERO | Segment(RS)
| | | |
|---------------------PCRpt,PLSP-ID=1-------------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
Bidgoli, et al. Expires 23 August 2025 [Page 47]
Internet-Draft PCEP p2mp sr policy February 2025
| | | CC-ID=Z,Label=z,O=0, |
| | | path-attribute,ERO,SR-ERO |
| | | |
| |<-------PcInitiate,PLSP-ID=0, -------------| Download
| | | root-addr,Tree-ID=a,Instance-ID=b,| Transit
| | | CC-ID=Y,C=0, | RS
| | | O=0,L=y,path-attribute,ERO,SR-ERO |
| | | |
| |-------------PCRpt,PLSP-ID=2-------------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=Y,Label=y,O=0, |
| | | path-attribute,ERO,SR-ERO |
| | | |
| | |<--PcInitiate,PLSP-ID=1, | Download
| | | root-addr,Tree-ID=a,Instance-ID=b,| Root
| | | CC-ID=X,C=0, | RS
| | | O=0,L=x,P2MP-end- |
| | | points(LeafType=5),path-attribute,|
| | | ERO,SR-ERO |
| | | |
| | |-------PCRpt,PLSP-ID=1-------------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=X,Label=x,O=0, |
| | | P2MP-end-points(LeafType=5) |
| | | path-attriute,ERO,SR-ERO |
| | | |
| | |<--PCUpdate,PLSP-ID=1, SRP-ID =2, |
| | | root-addr,Tree-ID=a,Instance-ID=b,| Activate
| | | P2MP-end-points | CP to last
| | | | RS
| | |-------PCRpt,PLSP-ID=1, SRP-ID =2, ->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | P2MP-end-points(LeafType=5) |
| | | |
Note that on transit / leaf Initiate is with PLSP-ID = 0. Therefore
PLSP-ID is locally unique to a node. It should be noted that the CC-
ID does not need to be constant across all nodes that make up the
path.
PCE-Initiated workflow
+-------+ +-------+
|PCC | | PCE |
|Root | +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
Bidgoli, et al. Expires 23 August 2025 [Page 48]
Internet-Draft PCEP p2mp sr policy February 2025
+------| | | | PCECC LSP
|PCC +--------+ | |
| | | | |
|Leaf | | | |
+--------+ | | |
| | |<--PcInitiate,PLSP-ID=0, | Initiate
| | | root-addr,Tree-ID=0,Instance-ID=b,| CP
| | | P2MP-end-points, association-obj |
| | | |
| | |-------PCRpt,PLSP-ID=1,------------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | P2MP-end-points(LeafType=5) |
| | | association-object, |
| | | |
| | |<--PCUpdt,PLSP-ID=1, | Download
| | | root-addr,Tree-ID=a,Instance-ID=b,| Root RS
| | | CC-ID=X,C=0, |
| | | O=0,L=x,P2MP-end- |
| | | points(LeafType=5),path-attribute,|
| | | ERO,SR-ERO |
| | | |
| | |-------PCRpt,PLSP-ID=1-------------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=X,Label=x,O=0, |
| | | P2MP-end-points(LeafType=5) |
| | | path-attriute,ERO,SR-ERO |
| | | |
|<---------------PcInitiate,PLSP-ID=0, -------------| Download
| | | root-addr,Tree-ID=a,Instance-ID=b,| Leaf RS
| | | CC-ID=Z,C=0, |
| | | O=0,L=z,path-attribute,ERO,SR-ERO |
| | | |
|---------------------PCRpt,PLSP-ID=1-------------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=Z,Label=z,O=0, |
| | | path-attribute,ERO,SR-ERO |
| | | |
| |<-------PcInitiate,PLSP-ID=0, -------------| Download
| | | root-addr,Tree-ID=a,Instance-ID=b,| Transit RS
| | | CC-ID=Y,C=0, |
| | | O=0,L=y,path-attribute,ERO,SR-ERO |
| | | |
| |-------------PCRpt,PLSP-ID=2-------------->|
| | | root-addr,Tree-ID=a,Instance-ID=c,|
| | | CC-ID=Y,Label=y,O=0, |
| | | path-attribute,ERO,SR-ERO |
| | | |
| |<-------PcInitiate,PLSP-ID=0, -------------|
Bidgoli, et al. Expires 23 August 2025 [Page 49]
Internet-Draft PCEP p2mp sr policy February 2025
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=Y,C=0, |
| | | O=0,L=y,path-attribute,ERO,SR-ERO |
| | | |
| |-------------PCRpt,PLSP-ID=2-------------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=Y,Label=y,O=0, |
| | | path-attribute,ERO,SR-ERO |
| | | |
| | |<--PCUpdate,PLSP-ID=1, SRP-ID =1, | Bind and
| | | root-addr,Tree-ID=a,Instance-ID=b,| Activate
| | | P2MP-end-points, | CP to last
| | | | RS
| | |-------PCRpt,PLSP-ID=1, SRP-ID = 1,->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | P2MP-end-points(LeafType=5) |
MBB Workflow:
Common (PCE-INIT, PCC-INIT) MBB
+-------+ +-------+
|PCC | | PCE |
|Root | +-------+
+------| | |
| PCC +-------+ |
| Transit| | |
+------| | | | PCECC LSP
|PCC +--------+ | |
| | | | |
|Leaf | | | |
+--------+ | | |
|<---------------PcInitiate,PLSP-ID=1, -------------| Download
| | | root-addr,Tree-ID=a,Instance-ID=b,| new RS on
| | | CC-ID=Z1,C=0, | Leaf
| | | O=0,L=z1,path-attribute,ERO,SR-ERO |
| | | |
|---------------------PCRpt,PLSP-ID=1-------------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=Z1,Label=z1,O=0, |
| | | path-attribute,ERO,SR-ERO |
| | | |
| |<-------PcInitiate,PLSP-ID=2, -------------| Download
| | | root-addr,Tree-ID=a,Instance-ID=b,| new RS on
| | | CC-ID=Y1,C=0, | Transit
| | | O=0,L=y1,path-attribute,ERO,SR-ERO |
| | | |
| |-------------PCRpt,PLSP-ID=2-------------->|
Bidgoli, et al. Expires 23 August 2025 [Page 50]
Internet-Draft PCEP p2mp sr policy February 2025
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=Y1,Label=y1,O=0, |
| | | path-attribute,ERO,SR-ERO |
| | | |
| | |<--PcInitiate,PLSP-ID=1, | Download
| | | root-addr,Tree-ID=a,Instance-ID=b,| new RS on
| | | CC-ID=X1,C=0, | Root
| | | O=0,L=x1,P2MP-end- |
| | | points(LeafType=5),path-attribute,|
| | | ERO,SR-ERO |
| | | |
| | |-------PCRpt,PLSP-ID=1-------------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=X1,Label=x1,O=0, |
| | | P2MP-end-points(LeafType=5) |
| | | path-attriute,ERO,SR-ERO |
| | | |
| | |<--PCUpdate,PLSP-ID=1, SRP-ID =1, | Bind and
| | | root-addr,Tree-ID=a,Instance-ID=b,| Activate
, | | | P2MP-end-points, | CP to last
| | | | RS
| | |-------PCRpt,PLSP-ID=1, SRP-ID = 1,->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | P2MP-end-points(LeafType=5) |
| | | |
| | |<--PcInitiate,PLSP-ID=1,R=1 | Remove
| | | root-addr,Tree-ID=a,Instance-ID=b,| the old RS
| | | CC-ID=X1,C=0 | from Leaf
| | | O=0,L=x1,P2MP-end- |
| | | points(LeafType=5),path-attribute,|
| | | ERO,SR-ERO |
| | | |
| | |-------PCRpt,PLSP-ID=1, R=1--------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=X1,Label=x1,O=0, |
| | | P2MP-end-points(LeafType=5) |
| | | path-attriute,ERO,SR-ERO |
| | | |
| |<-------PcInitiate,PLSP-ID=2, R=1----------| Remove the
| | | root-addr,Tree-ID=a,Instance-ID=b,| old RS from
| | | CC-ID=Y1,C=0, | Transit
| | | O=0,L=y1,path-attribute,ERO,SR-ERO |
| | | |
| |-------------PCRpt,PLSP-ID=2, R=1--------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=Y1,Label=y1,O=0, |
| | | path-attribute,ERO,SR-ERO |
| | | |
Bidgoli, et al. Expires 23 August 2025 [Page 51]
Internet-Draft PCEP p2mp sr policy February 2025
|<---------------PcInitiate,PLSP-ID=1,R=1-----------| Remove the
| | | root-addr,Tree-ID=a,Instance-ID=b,| old RS from
| | | CC-ID=Z1,C=0, | Root
| | | O=0,L=z1,path-attribute,ERO,SR-ERO |
| | | |
|---------------------PCRpt,PLSP-ID=1,R=1---------->|
| | | root-addr,Tree-ID=a,Instance-ID=b,|
| | | CC-ID=Z1,Label=z1,O=0, |
| | | path-attribute,ERO,SR-ERO |
Authors' Addresses
Hooman Bidgoli (editor)
Nokia
Ottawa
Canada
Email: hooman.bidgoli@nokia.com
Daniel Voyer
Bell Canada
Montreal
Canada
Email: daniel.voyer@bell.ca
Anuj Budhiraja
Cisco System
San Jose,
United States of America
Email: abudhira@cisco.com
Rishabh
Arrcus
San Jose,
United States of America
Email: rishabh@arrcus.com
Siva Sivabalan
Ciena
Ottawa
Canada
Email: ssivabal@ciena.com
Bidgoli, et al. Expires 23 August 2025 [Page 52]