RFC 8623
Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
RFC 8623: Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) ✨
Bestie, this one is a whole vibe 🦋 Here's the title block so you know who's behind it:
- Number and title: RFC 8623, Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
- Authors: U. Palle and D. Dhody (Huawei Technologies), Y. Tanaka (NTT Communications), and V. Beeram (Juniper Networks)
- Category: Standards Track 🌸
- ISSN: 2070-1721
- Date: June 2019
- Obsoletes and updates: the title block doesn't list anything this document obsoletes or updates 💅
Abstract
okay so the Path Computation Element (PCE) has been picked as the right tech for figuring out the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs) 🌈 This doc adds the extensions that the Path Computation Element Communication Protocol (PCEP) needs so a stateful PCE can support P2MP TE LSPs. It's giving main character energy ✨
Status of This Memo
This is an Internet Standards Track document 🎀
It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚
For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8623 🔗
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at https://trustee.ietf.org/license-info as they stood on the publication date. Please actually read them, because they explain your rights and restrictions for this document 🙈 Any code components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Supporting P2MP TE LSPs for Stateful PCE . . . . . . . . . . 4
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 5
4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 5
5. Architectural Overview of Protocol Extensions . . . . . . . . 6
5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 6
5.2. Capability Advertisement . . . . . . . . . . . . . . . . 7
5.3. IGP Extensions for Stateful PCE P2MP Capabilities
Advertisement . . . . . . . . . . . . . . . . . . . . . . 7
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 8
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 9
5.6.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 9
5.6.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 9
5.6.3. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . 9
5.6.3.1. P2MP TE LSPs Instantiation . . . . . . . . . . . 9
5.6.3.2. P2MP TE LSPs Deletion . . . . . . . . . . . . . . 10
5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 10
5.6.3.4. P2MP TE LSPs Delegation and Cleanup . . . . . . . 10
6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 11
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 11
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 13
6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 14
6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 15
6.5. The PCInitiate Message . . . . . . . . . . . . . . . . . 16
6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.6.1. P2MP TE LSPs Update Request . . . . . . . . . . . . . 17
6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17
6.6.3. P2MP TE LSPs Initiation Request . . . . . . . . . . . 18
7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 19
7.1. LSP Object Extension . . . . . . . . . . . . . . . . . . 19
7.1.1. P2MP-LSP-IDENTIFIERS TLV . . . . . . . . . . . . . . 19
7.2. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 22
8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 23
8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 23
8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 23
8.3. PCInitiate Fragmentation Procedure . . . . . . . . . . . 24
9. Nonsupport of P2MP TE LSPs for Stateful PCE . . . . . . . . . 24
10. Manageability Considerations . . . . . . . . . . . . . . . . 25
10.1. Control of Function and Policy . . . . . . . . . . . . . 25
10.2. Information and Data Models . . . . . . . . . . . . . . 25
10.3. Liveness Detection and Monitoring . . . . . . . . . . . 25
10.4. Verify Correct Operations . . . . . . . . . . . . . . . 26
10.5. Requirements on Other Protocols . . . . . . . . . . . . 26
10.6. Impact on Network Operations . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 26
11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26
11.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 27
11.4. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . 27
11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28
11.6. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 28
11.7. S2LS Object . . . . . . . . . . . . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 331. Introduction 🌸
okay so, per [RFC4655], the Path Computation Element (PCE) is an entity that can compute a network path or route from a network graph while applying computational constraints. A Path Computation Client (PCC) can ask a PCE to compute paths for it 🫶
[RFC4875] explains how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks 🧚 Then [RFC5671] looks at how well PCE applies to path computation for P2MP TE LSPs.
PCEP is designed as the communication protocol between PCCs and PCEs for point-to-point (P2P) path computations, and it's defined in [RFC5440] 💖 The PCEP extensions for requesting path computation for P2MP TE LSPs are described in [RFC8306] ✨
Stateful PCEs are super helpful in lots of application scenarios, in both MPLS and GMPLS networks, as [RFC8051] illustrates 👑 Those scenarios work just as well for P2P and P2MP TE LSPs. [RFC8231] gives the core PCEP extensions a stateful PCE needs to support general P2P TE LSP functionality, and [RFC8281] adds the extensions for stateful PCE-initiated P2P TE LSPs 🔥
This document picks up where those leave off. It focuses on the PCEP extensions a stateful PCE deployment needs in order to support P2MP TE LSPs 🦋 It describes the setup, maintenance, and teardown of PCE-initiated P2MP LSPs under the stateful PCE model. Bestie, that's the whole plot 💅
1.1. 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 🎀 So lowercase versions are just regular words, but the CAPS ones are the real deal 🙈
2. Terminology 🍓
Terminology used in this document is the same as terminology used in [RFC8231], [RFC8281], and [RFC8306] 💜 No new vocab to memorize, iykyk 🧚
3. Supporting P2MP TE LSPs for Stateful PCE ✨
3.1. Motivation
[RFC8051] presents several use cases where a stateful PCE helps out, like optimization, recovery, and more 🌈 Those are equally applicable to P2MP TE LSPs. [RFC8231] defines the PCEP extensions needed for stateful operation of P2P TE LSPs, and this document builds on that by focusing on what a stateful PCE needs to support P2MP TE LSPs 🫶
Here's the bit I'm obsessed with. Being stateful makes PCEP messages way simpler, because you can refer to an LSP with a PCEP-specific LSP identifier (PLSP-ID) ([RFC8231]) 😭 For P2MP, where messages are much bigger, that's a huge perk. With a stateless PCE, changing an existing P2MP tree means you have to list every leaf and all the path info in the PCEP messages. With a stateful PCE, the messages can use a PLSP-ID to stand in for everything that was already exchanged, so you only need to encode the changes, like new or removed leaf nodes ✨ The PLSP-ID is an index into the LSP-DB at the PCE, and it identifies the LSP at the PCC 💅
In environments where P2MP TE LSP placement needs to change in response to application demands, being able to dynamically create and tear down P2MP TE LSPs is really useful 🔥 A PCE being able to trigger creation of P2MP TE LSPs on demand fits neatly into a controller-based network architecture, where the controller's smarts decide when and where paths get set up 👑 Section 3 of [RFC8281] goes further into the motivation behind PCE-Initiation, which applies to P2MP TE LSPs too 🦋
3.2. Objectives
The objectives for the protocol extensions that support P2MP TE LSPs for stateful PCE are the same as the objectives described in Section 3.2 of [RFC8231] 🌸 Same goals, new lane 🌈
4. Functions to Support P2MP TE LSPs for Stateful PCEs ✨
okay so [RFC8231] already gave us the stateful PCE functions 💅 and says each one can start either from a PCC heading to a PCE (C-E) or from a PCE heading to a PCC (E-C) 🫶. This doc is the glow-up that makes those same functions work for P2MP TE LSPs too 🦋 Here's the list:
- Capability Advertisement (E-C,C-E): Both the PCC and the PCE must announce during PCEP session establishment that they support Stateful PCE extensions for P2MP using mechanisms defined in Section 5.2. 📣
- LSP State Synchronization (C-E): After the session between the PCC and a stateful PCE with P2MP capability is initialized, the PCE must learn the state of a PCC's P2MP TE LSPs before it can perform path computations or update LSP attributes in a PCC. 🧠
- LSP Update Request (E-C): A stateful PCE with P2MP capability requests modification of attributes on a PCC's P2MP TE LSPs. ✏️
- LSP State Report (C-E): A PCC sends an LSP state report to a PCE whenever the state of a P2MP TE LSP changes. 📬
- LSP Control Delegation (C-E,E-C): A PCC grants to a PCE the right to update LSP attributes on one or more P2MP TE LSPs. The PCE becomes the authoritative source of the LSP's attributes as long as the delegation is in effect (See Section 5.7 of [RFC8231]). The PCC may withdraw the delegation, or the PCE may give up the delegation, at any time. 👑
- PCE-initiated LSP instantiation (E-C): A PCE sends an LSP Initiate Message to a PCC to instantiate or delete a P2MP TE LSP [RFC8281]. 🌱
5. Architectural Overview of Protocol Extensions 🏗️
5.1. Extension of PCEP Messages 💌
okay so [RFC8231] defines two new PCEP messages to support stateful PCE for P2P TE LSPs 🎀 In this document, those messages get extended to handle P2MP TE LSPs too, and here's how 🫶
- Path Computation State Report (PCRpt): Each P2MP TE LSP State Report in a PCRpt message contains the actual P2MP TE LSP path attributes, the LSP status, etc. 📊 An LSP State Report carried in a PCRpt message is also used in delegation or revocation of control of a P2MP TE LSP to/from a PCE. The extension of PCRpt messages is described in Section 6.1.
- Path Computation Update Request (PCUpd): Each P2MP TE LSP Update Request in a PCUpd message MUST contain all LSP parameters that a PCE wishes to set for a given P2MP TE LSP. 🔥 An LSP Update Request carried in a PCUpd message is also used to return LSP delegations if at any point the PCE no longer desires control of a P2MP TE LSP. The PCUpd message is described in Section 6.2.
Further, a new PCEP message is defined in [RFC8281] to support stateful PCE instantiation of P2P TE LSPs 🧚 In this document, this message gets extended to support P2MP TE LSPs as well.
- Path Computation LSP Initiate Message (PCInitiate): PCInitiate is a PCEP message sent by a PCE to a PCC to trigger the instantiation or deletion of a P2MP TE LSP. ✨ The PCInitiate message is described in Section 6.5.
The Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages are also extended to support passive stateful PCE for P2P TE LSPs in [RFC8231]. In this document, these messages are extended to support P2MP TE LSPs as well. 🌸
5.2. Capability Advertisement 📣
okay so during the PCEP initialization phase, as per Section 7.1.1 of [RFC8231], PCEP speakers advertise Stateful capability via the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. 🙌 Various flags are defined for the STATEFUL-PCE-CAPABILITY TLV in [RFC8231] and updated in [RFC8281] and [RFC8232].
Three new flags are added in this document: N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), and P (P2MP-LSP-INSTANTIATION-CAPABILITY) 🦋
- N (P2MP-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the N Flag indicates that the PCC is willing to send P2MP LSP State Reports whenever there's a change to the parameters or operational status of the P2MP LSP. If set to 1 by a PCE, the N Flag indicates that the PCE is interested in receiving LSP State Reports whenever there is a parameter or operational status change to the P2MP LSP. The P2MP-CAPABILITY Flag MUST be advertised by both a PCC and a PCE for the P2MP extension (as per this document) of the PCRpt messages to be allowed on a PCEP session. 🔐
- M (P2MP-LSP-UPDATE-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the M Flag indicates that the PCC allows modification of P2MP LSP parameters. If set to 1 by a PCE, the M Flag indicates that the PCE is capable of updating P2MP LSP parameters. The P2MP-LSP-UPDATE-CAPABILITY Flag MUST be advertised by both a PCC and a PCE for the P2MP extension (as per this document) of the PCUpd messages to be allowed on a PCEP session. 🛠️
- P (P2MP-LSP-INSTANTIATION-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the P Flag indicates that the PCC allows instantiation of a P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates that the PCE supports P2MP LSP instantiation. The P2MP-LSP-INSTANTIATION-CAPABILITY flag MUST be set by both PCC and PCE in order to support PCE-initiated P2MP LSP instantiation. 🌈
A PCEP speaker should continue to advertise the basic P2MP capability via mechanisms as described in [RFC8306]. 💜
5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement 🗺️
okay so when the PCC is a Label Switching Router (LSR) participating in the IGP (either OSPF or IS-IS), and PCEs are either LSRs or servers also participating in the IGP, an effective mechanism for PCE discovery within an IGP routing domain is utilizing IGP advertisements 🧭 Extensions for the advertisement of PCE discovery information are defined for OSPF and for IS-IS in [RFC5088] and [RFC5089], respectively.
The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub-TLV used to advertise PCE capabilities. It MAY be present within the PCE Discovery (PCED) TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide the description and processing rules for this sub-TLV when carried within OSPF and IS-IS, respectively. 🫧
The format of the PCE-CAP-FLAGS sub-TLV is included below for easy reference 📋
Type: 5
Length: Multiple of 4
Value: This contains an array of units of 32-bit flags with the most
significant bit as 0. Each bit represents one PCE capability.PCE capability bit flags are defined in [RFC5088]. This document defines new capability bits for the stateful PCE with P2MP as follows 🎯
Bit Capability
13 Active Stateful PCE with P2MP
14 Passive Stateful PCE with P2MP
15 PCE-Initiation with P2MPNote that, while active, passive, or initiation stateful PCE capabilities for P2MP may be advertised during discovery, PCEP Speakers that wish to use stateful PCEP for P2MP TE LSPs MUST advertise stateful PCEP capabilities during PCEP session setup, as specified in the current document. 🚨 A PCC MAY initiate stateful PCEP P2MP capability advertisement at PCEP session setup even if it did not receive any IGP PCE capability advertisements. 💅
5.4. State Synchronization 🔄
State Synchronization operations (described in Section 5.6 of [RFC8231]) are applicable for the P2MP TE LSPs as well. The optimizations described in [RFC8232] can also be applied for P2MP TE LSPs. ✨
5.5. LSP Delegation 🤝
LSP delegation operations (described in Section 5.7 of [RFC8231]) are applicable for P2MP TE LSPs as well. 👑
5.6. LSP Operations 🎬
5.6.1. Passive Stateful PCE 👀
LSP operations for passive stateful PCE (described in Section 5.8.1 of [RFC8231]) are applicable for P2MP TE LSPs as well. 🙈
The PCReq and PCRep message format for P2MP TE LSPs is described in Sections 3.4 and 3.5 of [RFC8306], respectively. 📝
The PCReq and PCRep message for P2MP TE LSPs are extended to support encoding of the LSP object so that it is possible to refer to an LSP with a unique identifier and simplify the PCEP message exchange. For example, in case of modification of one leaf in a P2MP tree, there should be no need to carry the full P2MP tree in a PCReq message. 🍓
The extensions for the Request and Response message for passive stateful operations on P2MP TE LSPs are described in Sections 6.3 and 6.4. The extension for the Path Computation LSP State Report (PCRpt) message is described in Section 6.1. 🌷
5.6.2. Active Stateful PCE 🔥
LSP operations for active stateful PCE (described in Section 5.8.2 of [RFC8231]) are applicable for P2MP TE LSPs as well. 💖
The extension for the Path Computation LSP Update (PCUpd) message for active stateful operations on P2MP TE LSPs is described in Section 6.2. 🧁
5.6.3. PCE-Initiated LSP 🌱
As per Section 5.1 of [RFC8281], the PCE sends a Path Computation LSP Initiate Request (PCInitiate) message to the PCC to suggest instantiation or deletion of a P2P TE LSP. This document extends the PCInitiate message to support P2MP TE LSPs (see details in Section 6.5). 🫶
The instantiation and deletion operations for P2MP TE LSPs are the same as for P2P LSPs as described in Sections 5.3 and 5.4 of [RFC8281]. 🦋
5.6.3.1. P2MP TE LSPs Instantiation 🎀
The instantiation operation of P2MP TE LSPs is the same as the LSP instantiation operation defined in Section 5.3 of [RFC8281]; this includes the handling of the PLSP-ID, SYMBOLIC-PATH-NAME TLV, etc. The processing rules and use of error codes remain unchanged. The N (P2MP) flag (Section 7.1) MUST be set in the LSP object in the PCInitiate message by the PCE to specify that the instantiation is for P2MP TE LSPs. 🚀 Like the PLSP-ID (as per [RFC8281]), the P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be included in the LSP object in PCInitiate messages and MUST be ignored on receipt. 🙅♀️ These identifiers are generated by the PCC on receipt of the PCInitiate message and reported via a PCRpt message to the PCE. 📬
5.6.3.2. P2MP TE LSPs Deletion 🗑️
The deletion operation of P2MP TE LSPs is the same as the LSP deletion operation defined in Section 5.4 of [RFC8281]; this entails sending an LSP Initiate Message with an LSP object carrying the PLSP-ID of the LSP to be removed as well as a Stateful PCE Request Parameter (SRP) object with the R flag set (LSP-REMOVE as per Section 5.2 of [RFC8281]). The processing rules and error codes remain unchanged. 💀
5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP 🌿
The adding of new leaves and pruning of old leaves for the PCE-initiated P2MP TE LSP MUST be carried in a PCUpd message as per Section 6.2 for P2MP TE LSP extensions. 📨 As defined in [RFC8306], leaf type = 1 is used for adding new leaves, and leaf type = 2 is used for pruning old leaves of P2MP END-POINTS Objects. 🍃
PCC MAY use the Incremental State Update mechanism as described in [RFC4875] to signal the adding and pruning of leaves. 🌸
Section 3.10 of [RFC8306] defines the error-handling procedures when adding new leaves to or removing old leaves from the existing P2MP tree for PCReq messages. The same error handling and error codes are also applicable to the stateful PCE messages as described in this document. 🙌
5.6.3.4. P2MP TE LSPs Delegation and Cleanup 🧹
P2MP TE LSPs delegation and cleanup operations are the same as the LSP delegation and cleanup operations defined in Section 6 of [RFC8281]. The processing rules and error codes remain unchanged. 💜
6. PCEP Message Extensions ✨
Okay bestie, let's talk message formats 💌 Everything in this section, like the ones in [RFC8231], [RFC8281], and [RFC5440], is written in Routing Backus-Naur Format (RBNF), as specified in [RFC5511]. 🎀
6.1. The PCRpt Message
So per Section 6.1 of [RFC8231], a PCRpt message is how you report the current state of a P2P TE LSP 🦋 This doc extends PCRpt so it can also report the status of P2MP TE LSPs, periodt 💅
Here's what a PCRpt message looks like:
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>
[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<path>
Where:
<path> ::= <end-point-intended-path-pair-list>
[<actual-attribute-list>
<end-point-actual-path-pair-list>]
[<intended-attribute-list>]
<end-point-intended-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
<intended-path>
[<end-point-intended-path-pair-list>]
<end-point-actual-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
<actual-path>
[<end-point-actual-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<actual-path> ::= (<RRO>|<SRRO>)
[<actual-path>]So <intended-attribute-list> is defined in [RFC5440] and extended by PCEP extensions 🧚 And <actual-attribute-list> holds the actual computed and signaled values of the <BANDWIDTH> and <metric-lists> objects from [RFC5440] ✨
The P2MP END-POINTS object from [RFC8306] is mandatory for listing the addresses of P2MP leaves, and they get grouped by leaf type 🍓 The four leaf types are:
- New leaves to add (leaf type = 1)
- Old leaves to remove (leaf type = 2)
- Old leaves whose path can be modified/reoptimized (leaf type = 3)
- Old leaves whose path must be left unchanged (leaf type = 4)
When you report the status of a P2MP TE LSP, the destinations MUST be grouped in the END-POINTS object based on the operational status (O field in S2LS objects) and leaf type (in END-POINTS objects) 🫶 That way, leaves of the same type with the same operational status can be grouped together. For delegated P2MP TE LSPs, leaf type = 3 gets used, and for nondelegated P2MP TE LSPs, it's leaf type = 4 🌈
For a delegated P2MP TE LSP, configuration changes get reported via a PCRpt message. Like, adding new leaves uses leaf type = 1 in the END-POINTS object, and removing old leaves uses leaf type = 2 😭
Also, the compatibility with the [RFC8231] definition of <state-report> is preserved. At least one instance of <END-POINTS> MUST be present in this message for P2MP LSP 💜
The ordering of <end-point-intended-path-pair-list>, <actual-attribute-list>, <end-point-actual-path-pair-list>, and <intended-attribute-list> is also kept the same so it stays compatible with state reports for P2P LSPs, as per [RFC8231] 👑
During state synchronization, the PCRpt message reports the status of the full P2MP tree 🦋
The S2LS object MUST be carried in a PCRpt message along with the END-POINTS object when the N (P2MP) flag is set in an LSP object for P2P TE LSPs... wait, sorry, P2MP TE LSPs 🙈 If the S2LS object is missing, the receiving PCE MUST send a PCEP Error (PCErr) message with Error-type=6 ("Mandatory Object missing") and Error-value=13 ("S2LS object missing"). If the END-POINTS object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 ("Mandatory Object missing") and Error-value=3 ("END-POINTS object missing") (defined in [RFC5440]. 😬
The S2LS object can be used together with the intended-path (EXPLICIT_ROUTE object or ERO) and the actual-path (RECORD_ROUTE object or RRO) 🎀 For the same leaf, the state encoded in the S2LS object tied to the actual-path MUST be used over the intended-path. Main character energy, no notes ✨
If the E-bit (ERO-Compress bit) is set to 1 in the report, then the path gets formed by an ERO followed by a list of SECONDARY_EXPLICIT_ROUTE Objects (SEROs), or an RRO followed by a list of SECONDARY_RECORD_ROUTE Objects (SRROs) 💖
6.2. The PCUpd Message
As per Section 6.2 of [RFC8231], a PCUpd message is used to update P2P TE LSP attributes. This doc extends PCUpd so you can update the attributes of a P2MP TE LSP 🦋
Here's the format:
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>
[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<path>
Where:
<path> ::= <end-point-path-pair-list>
<intended-attribute-list>
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]<intended-attribute-list> is the attribute-list from [RFC5440], extended by PCEP extensions 🌸 And the compatibility with the [RFC8231] definition of <update-request> is preserved 🫶
The PCC SHOULD use the make-before-break or sub-group-based procedures described in [RFC4875], based on a local policy decision 🔥
The END-POINTS object MUST be carried in a PCUpd message when the N flag is set in the LSP object for a P2MP TE LSP. If the END-POINTS object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 ("Mandatory Object missing") and Error-value=3 ("END-POINTS object missing") (defined in [RFC5440]). 💀
6.3. The PCReq Message
As per Section 3.4 of [RFC8306], a PCReq message is used for a P2MP Path Computation Request 🧚 This doc extends PCReq so a PCC MAY include the LSP object in the PCReq message, as long as the stateful PCE P2MP capability has been negotiated on the PCEP session between the PCC and a PCE ✨
Here's the format:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list>::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<end-point-rro-pair-list>
[<LSP>]
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
<end-point-rro-pair-list>::= <END-POINTS>
[<RRO-List>[<BANDWIDTH>]]
[<end-point-rro-pair-list>]
<RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]6.4. The PCRep Message
As per Section 3.5 of [RFC8306], a PCRep message is used for a P2MP Path Computation Reply 🌈 This doc extends PCRep so a PCE MAY include the LSP object in the PCRep message, as long as the stateful PCE P2MP capability has been negotiated on the PCEP session between the PCC and a PCE 💅
Here's the format:
<PCRep Message>::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<end-point-path-pair-list>]
[<LSP>]
[<NO-PATH>]
[<UNREACH-DESTINATION>]
[<attribute-list>]
<end-point-path-pair-list>::= [<END-POINTS>]
<path>
[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]6.5. The PCInitiate Message
As defined in Section 5.1 of [RFC8281], a PCE sends a PCInitiate message to a PCC to recommend instantiation of a P2P TE LSP 🦋 This doc extends the PCInitiate format so you can create P2MP TE LSPs. Creating and deleting P2MP TE LSPs works the same as for P2P TE LSPs, so no drama there 🫶
Here's the format:
<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>
<end-point-path-pair-list>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Where:
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]<attribute-list> is defined in [RFC5440] and extended by PCEP extensions 🌟
A PCInitiate message with an LSP object that has the N flag (P2MP) set is used to convey an operation on a P2MP TE LSP 💜 The SRP object correlates the initiation requests the PCE sends with the error reports and state reports the PCC sends back, as described in [RFC8231] 🎀
The END-POINTS object MUST be carried in a PCInitiate message when the N flag is set in an LSP object for a P2MP TE LSP. If the END-POINTS object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 ("Mandatory Object missing") and Error-value=3 ("END-POINTS object missing") (defined in [RFC5440]). 😭
6.6. Example
6.6.1. P2MP TE LSPs Update Request
Okay so an LSP Update Request is sent by an active stateful PCE to update the parameters or attributes of P2MP TE LSPs 🧚 Here's an example PCUpd message for P2MP TE LSPs:
Common Header
SRP
LSP with P2MP flag set
END-POINTS for leaf type 3
ERO listIn this example, a stateful PCE asks for an update to the path taken to some of the leaves in a P2MP tree 🌸 The update request uses END-POINT type 3 (modified/reoptimized). The ERO list shows the source-to-leaves path after the modification. And the update message doesn't need to encode the full P2MP tree in this case, which is so efficient, iconic behaviour 👑
6.6.2. P2MP TE LSP Report 🦋
okay so the LSP State Report message is what a PCC sends to report or delegate a P2MP TE LSP 📡. The leaves get grouped into the END-POINTS object by their operational status and leaf type, which is honestly so organized 🗂️✨. Here's a PCRpt message for a delegated P2MP TE LSP that adds new leaves to an existing one:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 1 (add)
S2LS (O=DOWN)
ERO list (empty)Next, here's a PCRpt message for a P2MP TE LSP that prunes leaves from an existing one 💅:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 2 (remove)
S2LS (O=UP)
ERO list (empty)And this one is for a delegated P2MP TE LSP reporting the status of leaves in an existing P2MP TE LSP 🫶:
Common Header
SRP
LSP with P2MP flag set
END-POINTS for leaf type 3 (modify)
S2LS (O=UP)
RRO list
END-POINTS for leaf type 3 (modify)
S2LS (O=DOWN)
ERO list (empty)In this example, the PCRpt message is a response to a PCUpd message 🎀. It includes the matching SRP object and shows that some leaves are up (with the actual path) and some are down, which is a whole mood 🌈.
Last one, for a nondelegated P2MP TE LSP reporting the status of leaves 🍓:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 4 (unchanged)
S2LS (O=ACTIVE)
RRO list
END-POINTS for leaf type 4 (unchanged)
S2LS (O=DOWN)
ERO list (empty)6.6.3. P2MP TE LSPs Initiation Request 🧚
An LSP Initiation Request message is sent by a stateful PCE to create a P2MP TE LSP 🚀. Here's what a PCInitiate message for one looks like:
Common Header
SRP
LSP with P2MP flag set
END-POINT for leaf type 1 (add)
ERO listIn this example, a stateful PCE asks for a P2MP TE LSP to be created 🌸. The initiation request uses END-POINT type 1, which means new leaves 🌟. The ERO list shows the source-to-leaves path, and in this case the initiate message encodes the full P2MP tree 🌳. Main character energy, no cap 👑.
7. PCEP Object Extensions 💜
The new PCEP TLVs defined in this document follow the PCEP TLV format defined in [RFC5440], so they're totally on brand 🙌.
7.1. LSP Object Extension 🎀
The LSP Object is defined in Section 7.3 of [RFC8231] 📦. It carries the PLSP-ID, which uniquely identifies an LSP and stays constant for the whole life of a PCEP session 🔒. For a P2MP tunnel, the PLSP-ID does the same job and uniquely identifies a P2MP TE LSP ✨. This document adds the following flags to the LSP Object:
- N (P2MP flag - 1 bit): If the N flag is set to 1, the message is for a P2MP TE LSP 🌈.
- F (Fragmentation flag - 1 bit): If the F flag is unset (0), the LSP is not fragmented, or it is the last piece of the fragmented LSP 🧩. If the F flag is set to 1, the LSP is fragmented and this isn't the last piece 🫠. The receiver has to wait for more fragments until it gets an LSP with the same PLSP-ID and the F-bit set to 0 ⏳. See Section 8 for further details 👀.
- E (ERO-compression flag - 1 bit): If the E flag is set to 1, the route is in compressed format, which means Secondary Explicit Route Object (SERO) and Secondary Record Route Object (SRRO) objects [RFC8306] are in use 🗜️.
The flags in this section (N, F, and E) are used in PCRpt, PCUpd, or PCInitiate messages 📨. For PCReq and PCRep messages, these flags have no meaning and so MUST be ignored 🙈. The matching flags in the RP (Request Parameters) object are used as described in [RFC8306] 💅.
7.1.1. P2MP-LSP-IDENTIFIERS TLV 🔑
[RFC8231] specifies the LSP-IDENTIFIERS TLVs that go in the LSP object 📚. For P2MP TE LSPs, this document defines P2MP-LSP-IDENTIFIERS TLVs for the LSP object 💖. There are two of them, one for IPv4 and one for IPv6 🌐. The P2MP-LSP-IDENTIFIERS TLV MUST be included in the LSP object in a PCRpt message for P2MP TE LSPs 🚨. If the N bit is set in the LSP object of the PCRpt message but the P2MP-LSP-IDENTIFIER TLV is missing, the PCE MUST respond with a PCErr message carrying error-type 6 ("mandatory object missing") and error-value 14 ("P2MP-LSP-IDENTIFIERS TLV missing"), and then it closes the PCEP session 💀.
The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the PCUpd message for P2MP TE LSPs 🦋. The special value of all zeros in every field of the TLV's value portion is used to refer to all paths that belong to a particular PLSP-ID 🌟. The length of the TLV stays fixed based on the IP version 📏.
The P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be used in a PCInitiate message (see Section 5.6.3.1) 🙅♀️, and it MAY optionally be included in the LSP object in the PCReq and PCRep messages for P2MP TE LSPs 🫧.
Here's the format of the IPV4-P2MP-LSP-IDENTIFIERS TLV 🧾:
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=32 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPV4-P2MP-LSP-IDENTIFIERS TLV FormatThe type (16 bits) of this TLV is 32, and the length (16 bits) has a fixed value of 16 octets 🔢. The value holds these fields 💫:
- IPv4 Tunnel Sender Address: The sender node's IPv4 address, as defined in [RFC3209]. See Section 4.6.2.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Sender Template Object 📍.
- LSP ID: The 16-bit 'LSP ID' identifier defined in [RFC3209]. See Section 4.6.2.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Sender Template Object 🆔.
- Tunnel ID: The 16-bit 'Tunnel ID' identifier defined in [RFC3209]. See Section 4.6.1.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Session Object 🚇.
- Extended Tunnel ID: The 32-bit 'Extended Tunnel ID' identifier defined in [RFC3209]. See Section 4.6.1.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Session Object 🌌.
- P2MP ID: The 32-bit 'P2MP ID' identifier defined in Section 19.1.1 of [RFC4875] for the P2MP LSP Tunnel IPv4 SESSION Object 🌺.
Here's the format of the IPV6-P2MP-LSP-IDENTIFIERS TLV 🪄:
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=33 | Length=40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPV6-P2MP-LSP-IDENTIFIERS TLV FormatThe type (16 bits) of this TLV is 33, and the length (16 bits) has a fixed length of 40 octets 🧮. The value holds these fields 🌷:
- IPv6 Tunnel Sender Address: The sender node's IPv6 address, as defined in [RFC3209]. See Section 4.6.2.2 of [RFC3209] for the LSP_TUNNEL_IPv6 Sender Template Object 🌍.
- LSP ID: The 16-bit 'LSP ID' identifier defined in [RFC3209]. See Section 4.6.2.2 of [RFC3209] for the LSP_TUNNEL_IPv6 Sender Template Object 🏷️.
- Tunnel ID: The 16-bit 'Tunnel ID' identifier defined in [RFC3209]. See Section 4.6.1.2 of [RFC3209] for the LSP_TUNNEL_IPv6 Session Object 🛤️.
- Extended Tunnel ID: The 128-bit 'Extended Tunnel ID' identifier defined in [RFC3209]. See Section 4.6.1.2 of [RFC3209] for the LSP_TUNNEL_IPv6 Session Object 🪐.
- P2MP ID: Defined above under Figure 1 🔁.
- Tunnel ID: Remains constant over the lifetime of a tunnel 💎.
7.2. S2LS Object 💖
okay so the S2LS object is giving "group status report" energy 🫶 It reports the state of one or more destinations (leaves) that are encoded in the END-POINTS object for a P2MP TE LSP. It MUST be carried in a PCRpt message along with an END-POINTS object when the N flag is set in an LSP object 🔥
S2LS Object-Class is 41 ✨
S2LS Object-Types is 1 🎀
Here's the layout of the S2LS object, bestie 👀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: S2LS Object Format
The Flags field is 32 bits, and only one flag is defined so far 🌸
O (Operational - 3 bits): this is the operational status of the group of destinations. The values match the Operational field in the LSP object defined in Section 7.3 of [RFC8231] 💅
Unassigned bits are reserved for future uses. They MUST be set to 0 on transmission and MUST be ignored on receipt. Main character energy for the reserved bits 🧚
When the N flag is set in an LSP object, the O field in the LSP object is the operational status of the full P2MP TE LSP, and the O field in the S2LS object is the operational status of a group of destinations encoded within the END-POINTS object. Two different levels, same vibe ✨ If the two disagree (for example, the LSP's O field says down but the S2LS's O field says up), the PCEP speaker MUST generate an error with error-type 10 ("Reception of an invalid object") and error-value 22 ("Mismatch of O field in S2LS and LSP object"). Not it 💀
Future documents might define optional TLVs that could be included in the S2LS Object 🦋
8. Message Fragmentation 🧩
The total PCEP message length, including the common header, is (2^16)-1 bytes. Sometimes the P2MP report and update request won't fit into a single PCEP message (e.g., initial report or update). That's where the F flag comes in: it's set in the LSP object to signal that the initial report, update, or initiate request was too large for one PCEP message and will be fragmented into multiple messages 🍓 To tie a single report or update together, each message uses the same PLSP-ID. To tie a series of PCInitiate messages into one Initiate, each message uses the same PLSP-ID (in this case 0) and SRP-ID-number 🎀
The fragmentation procedure for report or update messages is similar to [RFC8306], which describes request and response message fragmentation 🔗
8.1. Report Fragmentation Procedure 📦
If the initial report is too large to fit into a single report message, the PCC will split the report over multiple messages. Every message sent to the PCE, except the last one, has the F flag set in the LSP object, which signals that the report was fragmented into multiple messages. To identify a series of report messages as one report, each message uses the same PLSP-ID 💜
The Error-Type value 18 ("P2MP Fragmentation Error") is used to report any error associated with the fragmentation of a P2MP PCEP message. A new error-value 2 indicates "Fragmented report failure", and it's used if a PCE does not receive the last part of the fragmented message 🥲
8.2. Update Fragmentation Procedure 🔄
Once the PCE computes and updates a path for some or all leaves in a P2MP TE LSP, an update message is sent to the PCC. If the update is too large for one update message, the PCE splits it over multiple messages. Every update message the PCE sends, except the last one, has the F flag set in the LSP object to signify that the update was fragmented. To identify a series of update messages as one update, each message uses the same PLSP-ID and SRP-ID-number ✨
The Error-Type value 18 ("P2MP Fragmentation Error") is used to report any error associated with the fragmentation of a P2MP PCEP message. A new error-value 3 indicates "Fragmented update failure", and it's used if a PCC does not receive the last part of the fragmented message 🫠
8.3. PCInitiate Fragmentation Procedure 🚀
Once the PCE starts setting up a P2MP TE LSP, a PCInitiate message is sent to the PCC. If the initiate request is too large for a single PCInitiate message, the PCE splits it over multiple messages. Every PCInitiate message the PCE sends, except the last one, has the F flag set in the LSP object to signify that the PCInitiate was fragmented into multiple messages. To identify a series of PCInitiate messages as one Initiate, each message uses the same PLSP-ID (in this case 0) and SRP-ID-number 🧚♀️
The Error-Type value 18 ("P2MP Fragmentation Error") is used to report any error associated with the fragmentation of a P2MP PCEP message. A new error-value 4 indicates "Fragmented instantiation failure", and it's used if a PCC does not receive the last part of the fragmented message 😭
9. Nonsupport of P2MP TE LSPs for Stateful PCE 🙅♀️
The PCEP extensions described in this document for stateful PCEs with P2MP capability MUST NOT be used if the PCE has not advertised its stateful capability with P2MP as per Section 5.2. If the PCC supports the extensions in this document (it understands the N (P2MP-CAPABILITY) and M (P2MP-LSP-UPDATE-CAPABILITY) flags in the LSP object) but didn't advertise this capability, then when it receives a PCUpd message from the PCE, it SHOULD generate a PCErr with error-type 19 ("Invalid Operation") and error-value 12 ("Attempted LSP Update Request for P2MP if active stateful PCE capability for P2MP was not advertised"), and terminate the PCEP session 💀 If the PCE supports the extensions in this document (it understands the N (P2MP-CAPABILITY) flag in the LSP object) but didn't advertise this capability, then when it receives a PCRpt message from the PCC, it SHOULD generate a PCErr with error-type 19 ("Invalid Operation") and error-value 11 ("Attempted LSP State Report for P2MP if stateful PCE capability for P2MP was not advertised"), and it SHOULD terminate the PCEP session 🫣
If a Stateful PCE receives a P2MP TE LSP report message and doesn't understand the N (P2MP-CAPABILITY) flag in the LSP object (so it doesn't know these extensions), then the Stateful PCE acts as per Section 6.1 of [RFC8231] and considers the PCRpt message invalid 🙈
The PCEP extensions described in this document for PCC or PCE with the PCE-Initiation capability for P2MP TE LSPs MUST NOT be used if the PCC or PCE has not advertised its stateful capability with Instantiation and P2MP as per Section 5.2. If the PCC supports the extensions in this document (it understands the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag) but didn't advertise this capability, then when it receives a PCInitiate message from the PCE, it SHOULD generate a PCErr with error-type 19 ("Invalid Operation") and error-value 13 ("Attempted LSP Instantiation Request for P2MP if stateful PCE instantiation capability for P2MP was not advertised"), and terminate the PCEP session 🌈
10. Manageability Considerations 🛠️
All manageability requirements and considerations listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281] apply to the PCEP extensions defined in this document. On top of that, the requirements and considerations in this section apply too 💅
10.1. Control of Function and Policy 🎛️
A PCE or PCC implementation MUST allow configuration of the stateful PCEP capability, the LSP Update capability, and the LSP Initiation capability for P2MP LSPs. Non-negotiable, bestie ✨
10.2. Information and Data Models 📊
The PCEP YANG module [PCE-PCEP-YANG] can be extended to include advertised P2MP stateful capabilities, P2MP synchronization status, and the delegation status of a P2MP LSP, etc. The statistics module should also count data related to P2MP LSPs 🌸
10.3. Liveness Detection and Monitoring 💓
The mechanisms in this document don't imply any new liveness detection and monitoring requirements beyond the ones already listed in [RFC5440] 🫶
10.4. Verify Correct Operations ✅
The mechanisms in this document don't imply any new operation verification requirements beyond the ones already listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281] 🔍
10.5. Requirements on Other Protocols 🧵
The mechanisms in this document don't imply any new requirements on other protocols. Iconic, no drama 👑
10.6. Impact on Network Operations 🌐
The mechanisms in this document don't have any impact on network operations beyond what's already listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281]. Stateful PCE features for P2MP LSPs would help with network operations, though 🦋
11. IANA Considerations 🗂️
IANA has registered the code points for the protocol elements defined in this document. ✨
11.1. PCE Capabilities in IGP Advertisements 📡
IANA has registered the new bits in the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry, as follows 🎀
Bit Capability Description Reference
13 Active Stateful PCE with P2MP RFC 8623
14 Passive Stateful PCE with P2MP RFC 8623
15 Stateful PCE Initiation with P2MP RFC 862311.2. STATEFUL-PCE-CAPABILITY TLV 🏷️
The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231], and the "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry was created to manage the flags in the TLV. IANA has registered the following code points in that registry 💖
Bit Description Reference
23 P2MP-LSP-INSTANTIATION-CAPABILITY RFC 8623
24 P2MP-LSP-UPDATE-CAPABILITY RFC 8623
25 P2MP-CAPABILITY RFC 862311.3. LSP Object 🧾
The LSP object is defined in [RFC8231], and the "LSP Object Flag Field" subregistry was created to manage the Flags field of the LSP object. IANA has registered the following code points in that registry 🌈
Bit Description Reference
1 ERO-compression RFC 8623
2 Fragmentation RFC 8623
3 P2MP RFC 862311.4. PCEP-ERROR Object 💖
okay so IANA added the new error values to the "PCEP-ERROR Object Error Types and Values" subregistry of the PCEP Numbers registry. here's the whole list 👇
Error-Type Meaning
6 Mandatory Object missing [RFC5440]
Error-value = 13: S2LS object missing
Error-value = 14: P2MP-LSP-IDENTIFIERS TLV missing
10 Reception of an invalid object [RFC5440]
Error-value = 22: Mismatch of O field in S2LS
and LSP object
18 P2MP Fragmentation Error [RFC8306]
Error-value = 2: Fragmented Report failure
Error-value = 3: Fragmented Update failure
Error-value = 4: Fragmented Instantiation failure
19 Invalid Operation [RFC8231]
Error-value = 11: Attempted LSP State Report
for P2MP if stateful PCE capability
for P2MP was not advertised
Error-value = 12: Attempted LSP Update Request
for P2MP if active stateful PCE capability
for P2MP was not advertised
Error-value = 13: Attempted LSP Instantiation
Request for P2MP if stateful PCE
instantiation capability for P2MP was not
advertisedevery new Error-value above points to RFC 8623 as its reference, so bookmark it 🔖✨
11.5. PCEP TLV Type Indicators 🎀
IANA also registered these code points in the existing "PCEP TLV Type Indicators" registry, and they all point right back at RFC 8623 🦋
Value Description Reference
32 P2MP-IPV4-LSP-IDENTIFIERS RFC 8623
33 P2MP-IPV6-LSP-IDENTIFIERS RFC 862311.6. PCEP Object 🌸
next up, the new object-class value and object types went into the "PCEP Objects" subregistry of the PCEP Numbers registry 🧚
Object-Class Value Name Reference
41 S2LS RFC 8623
Object-Type
0: Reserved
1: S2LS11.7. S2LS Object 💜
a brand new subregistry called "S2LS Object Flag Field" now lives inside the "Path Computation Element Protocol (PCEP) Numbers" registry. its job is to manage the 32-bit flag field of the S2LS object 🔥 New values get assigned by Standards Action [RFC8126]. Each bit should be tracked with these three qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
these are the values defined in this document:
Bit Description Reference
0-28 Unassigned
29-31 Operational (3 bits) RFC 862312. Security Considerations 🔐
okay this section is serious bestie 😭 stateful operations on P2MP TE LSPs are way more CPU intensive and also eat up more bandwidth on the wire than P2P TE LSPs (compared to P2P TE LSPs, that is). if a rogue PCC could request unauthorized stateful PCE operations, it could mount a DoS attack against a PCE. that would disrupt the network and deny service to the other PCCs 💀 an attacker could also flood the PCC with PCUpd messages at a rate higher than either the PCC can process them or the network can signal the changes. they could do that by spoofing messages or by compromising the PCE itself.
so it's super important that implementations follow the relevant security requirements below 🫶
- As per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253] as per the recommendations and best current practices in [RFC7525] (unless explicitly set aside in [RFC8253]).
- Security considerations for path computation requests and responses are as per [RFC8306].
- Security considerations for stateful operations (such as state report, synchronization, delegation, update, etc.) are as per [RFC8231].
- Security considerations for the LSP instantiation mechanism are as per [RFC8231].
- Security considerations as stated in Sections 10.1, 10.6, and 10.7 of [RFC5440] continue to apply.
13. References 📚
13.1. Normative References 💅
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and
S. Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and
R. Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
January 2008, <https://www.rfc-editor.org/info/rfc5088>.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and
R. Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) for Point-to-Multipoint Traffic
Engineering Label Switched Paths", RFC 8306,
DOI 10.17487/RFC8306, November 2017,
<https://www.rfc-editor.org/info/rfc8306>.13.2. Informative References 🦋
[PCE-PCEP-YANG]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
draft-ietf-pce-pcep-yang-11, March 2019.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
DOI 10.17487/RFC5671, October 2009,
<https://www.rfc-editor.org/info/rfc5671>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.Acknowledgments 🫶
huge thanks to Quintin Zhao, Avantika, and Venugopal Reddy for the review comments 💖
thank you to Adrian Farrel (and Jonathan Hardwick) for reviewing as document shepherds 👑
thanks to Andy Malis for the RTG-DIR review, Donald Eastlake for the SEC-DIR review, and David Schinazi for the GEN-ART review 🌈
and thanks to Suresh Krishnan, Mirja Kuhlewind, Roman Danyliw, and Benjamin Kaduk for the IESG reviews ✨
Contributors 🧚
Yuji Kamite
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: y.kamite@ntt.comAuthors' Addresses 💜
Udayasree Palle
Huawei Technologies
Email: udayasreereddy@gmail.com
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Yosuke Tanaka
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: yosuke.tanaka@ntt.com
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net📦 where this page comes from
- ietf: rfc8623 2019-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms