Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space
draft-ietf-pce-controlled-id-space-03
| Document | Type | Active Internet-Draft (pce WG) | |
|---|---|---|---|
| Authors | Cheng Li , Hang Shi , Aijun Wang , Weiqiang Cheng , Chao Zhou | ||
| Last updated | 2025-10-20 | ||
| Replaces | draft-li-pce-controlled-id-space | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-pce-controlled-id-space-03
Network Working Group C. Li
Internet-Draft H. Shi
Intended status: Experimental Huawei Technologies
Expires: 23 April 2026 A. Wang
China Telecom
W. Cheng
China Mobile
C. Zhou
HPE
20 October 2025
Path Computation Element Communication Protocol (PCEP) extension to
advertise the PCE Controlled Identifier Space
draft-ietf-pce-controlled-id-space-03
Abstract
The Path Computation Element Communication Protocol (PCEP) provides a
mechanism for the Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
The Stateful PCE extensions allow stateful control of Multiprotocol
Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
(LSPs) using PCEP. Furthermore, PCE can be used for computing paths
in the SR networks.
Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a
model where the PCC delegates control over one or more locally
configured LSPs to the PCE. Further, stateful PCE could also create
and remove PCE-initiated LSPs by itself. A PCE-based Central
Controller (PCECC) simplify the processing of a distributed control
plane by integrating with elements of Software-Defined Networking
(SDN).
In some use cases, such as PCECC provisioning or Binding Segment
Identifier (SID) for Segment Routing (SR) allocation, there are
requirements for a stateful PCE to make allocation of labels, SIDs,
etc. These use cases require PCE to be aware of various identifier
spaces from where to make allocations on behalf of a PCC. This
document defines a generic mechanism by which a PCC can inform the
PCE of the identifier space set aside for the PCE control via PCEP.
The identifier could be an MPLS label, a SID, or any other identifier
that can be allocated and managed by the PCE.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Li, et al. Expires 23 April 2026 [Page 1]
Internet-Draft PCE Controlled ID Space October 2025
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 April 2026.
Copyright Notice
Copyright (c) 2025 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. PCE-based Central Control . . . . . . . . . . . . . . . . 4
3.1.1. PCECC for MPLS/SR-MPLS . . . . . . . . . . . . . . . 5
3.1.2. PCECC for SRv6 . . . . . . . . . . . . . . . . . . . 5
3.2. Binding SID Allocation . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Open Object . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. LABEL-CONTROL-SPACE TLV . . . . . . . . . . . . . . . 8
5.1.2. FUNCT-ID-CONTROL-SPACE TLV . . . . . . . . . . . . . 9
6. Other Considerations . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 12
7.2. LABEL-CONTROL-SPACE TLV's Flag field . . . . . . . . . . 12
7.3. FUNCT-ID-CONTROL-SPACE TLV's Flag field . . . . . . . . . 13
7.4. PCEP-Error . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
Li, et al. Expires 23 April 2026 [Page 2]
Internet-Draft PCE Controlled ID Space October 2025
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Discussion and Resolution on Encoding PCE Controlled
ID-Space in Open Message . . . . . . . . . . . . . . . . 17
Appendix B. Open Discussion . . . . . . . . . . . . . . . . . . 17
Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
[RFC5440] defines the stateless Path Computation Element
Communication Protocol (PCEP) for the Path Computation Elements
(PCEs) to perform path computation in response to Path Computation
Clients (PCCs) requests. For supporting stateful operations,
[RFC8231] specifies a set of extensions to PCEP that enable the
stateful control of LSPs within and across PCEP sessions, in
accordance with [RFC4657]. Furthermore, [RFC8281] defines the setup,
maintenance, and teardown of PCE-initiated LSPs under the stateful
PCE model, without the need for local configuration on the PCC,
enabling a dynamically controlled network that is centrally
controlled and deployed.
[RFC8283] introduces the architecture for PCE as a central
controller, it examines the motivations and applicability for PCEP as
a control protocol in this environment, and introduces the
implications for the protocol. Also, [RFC9050] specifies the
procedures and PCEP extensions for using the PCE as a Central
Controller (PCECC), where LSPs are calculated/set up/initiated and
label forwarding entries are downloaded through extending PCEP.
However, the document assumes that label range to be used by a PCE is
known and set on both PCEP peers. This document adds the capability
to advertise the label range via a PCEP extension. It does so in a
generic fashion to allow various other ID space apart from the MPLS
label can also be advertised.
Similarly, [RFC9050] specifies the procedures and PCEP extensions
when a PCE-based controller is also responsible for configuring the
forwarding actions on the routers (SR SID distribution in this case),
in addition to computing the paths for packet flows in a segment
routing network and telling the edge routers what instructions to
attach to packets as they enter the network. However, the document
assumes that label range to be used by a PCE is known and set on both
PCEP peers. This document adds the capability to advertise the range
from Segment Routing Global Block (SRGB) or Segement Routing Local
Block (SRLB) of the node via a PCEP extension.
Li, et al. Expires 23 April 2026 [Page 3]
Internet-Draft PCE Controlled ID Space October 2025
In addition, [I-D.ietf-pce-pcep-extension-pce-controller-srv6]
specifies the procedures and PCEP extensions of PCECC for SRv6. An
SRv6 SID is represented as LOC:FUNCT:ARG ([RFC8986]) where LOC is the
L most significant bits and FUNCT is the 128-L least significant
bits. The FUNCT part of the SID is an opaque identification of a
local function bound to the SID. This document adds the capability
to advertise the range of Function ID (FUNCT part) via a PCEP
extension.
Once the PCC/node has given control over an ID space (for example
labels), the PCC/node MUST NOT allocate the ID from this ID space.
For example, a PCC/node MUST NOT use these labels from the PCE-
controlled label space to make allocation for VPN Prefix distributed
via BGP or labels used for LDP/RSVP-TE signaling. This is done to
make sure that the PCE control over ID space does not conflict with
the existing node allocation.
The use cases are described in Section 3. The ID space range
information can be advertised via the TLVs in the Open message. The
detailed procedures are described in Section 4, and the TLV format is
specified in Section 5.
2. Terminology
This memo makes use of the terms defined in [RFC5440], [RFC8231],
[RFC8283] and [RFC8402].
2.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.
3. Use cases
3.1. PCE-based Central Control
A PCE-based Central Controller (PCECC) can simplify the processing of
a distributed control plane by integrating with elements of SDN.
Thus, the LSP/SR path can be calculated/set up/initiated and the
label/SID forwarding entries can also be downloaded through a
centralized PCE server to each network devices along the path while
leveraging the existing PCE technologies as much as possible.
Li, et al. Expires 23 April 2026 [Page 4]
Internet-Draft PCE Controlled ID Space October 2025
3.1.1. PCECC for MPLS/SR-MPLS
[RFC9050] describes a mode where LSPs are provisioned as explicit
label instructions at each hop on the end-to-end path. Each router
along the path must be told what label forwarding instructions to
program and what resources to reserve. The controller uses PCEP to
communicate with each router along the path of the end-to-end LSP.
For this to work, the PCE-based controller will take responsibility
for managing some part of the MPLS label space for each router that
it controls as described in section 3.1.2. of [RFC8283]. A mechanism
for a PCC to inform the PCE of such a label space to control is
needed within PCEP.
[RFC8664] specifies extensions to PCEP that allow a stateful PCE to
compute, update or initiate SR-TE paths. [RFC9050] describes the
mechanism for PCECC to allocate and distribute the node/prefix/
adjacency label (SID) via PCEP. To make such allocation, PCE needs
to be aware of the label space from SRGB or SRLB [RFC8402] of the
node that it can control. A mechanism for a PCC to inform the PCE of
such label space to control is needed within PCEP. The full SRGB/
SRLB of a node could be learned via existing IGP or BGP-LS mechanism.
3.1.2. PCECC for SRv6
[I-D.ietf-pce-pcep-extension-pce-controller-srv6] describes the
mechanism for PCECC to allocate and provision the SRv6 SID via PCEP.
An SRv6 SID is represented as LOC:FUNCT:ARG ([RFC8986]) where LOC is
the L most significant bits, followed by F bits of function (FUNCT)
and A bits of arguments (ARG). The FUNCT part of the SID is an
opaque identification of a local function bound to the SID. To make
such allocation, PCE needs to be aware of the Function ID space
(FUNCT part) of the node that it controls. A mechanism for a PCC to
inform the PCE of such a Function ID space to control is needed
within PCEP.
3.2. Binding SID Allocation
The headend of an SR Policy binds a Binding SID (BSID) [RFC9604] to
its policy [RFC9256]. The instantiation of which may involve a list
of SIDs. The Binding SID can be allocated by the node as described
in [RFC9604], but there is an inherent advantage in the Binding SID
to be allocated by a PCE to allow SR policies to be dynamically
created, updated according to the network status and operations.
This is described in [RFC9050]. Therefore, a PCE needs to obtain the
authority and control to allocate Binding SID actively from the PCC's
label space as described in the above use case.
Li, et al. Expires 23 April 2026 [Page 5]
Internet-Draft PCE Controlled ID Space October 2025
This is applicable for all binding segment irrespective of the path
setup type (PST).
4. Overview
During PCEP Initialization Phase [RFC5440], Open messages are
exchanged between the PCCs and the PCEs. The OPEN object may also
contain a set of TLVs used to convey the capabilities in the Open
message. The term 'ID' in this document, could be a MPLS label, SRv6
Function ID or any other future ID space for PCE to control and
allocate from. A PCC MAY include a corresponding ID-CONTROL-SPACE
TLVs in the OPEN Object to inform the corresponding ID space
information that it wants the PCE to control. This TLV MUST NOT be
included by the PCE and MUST be ignored on receipt by a PCC. This is
an optional TLV, the PCE MAY also be aware of the ID space via some
other means outside of PCEP.
For delegating multiple types of ID space, multiple TLVs
corresponding to each ID type MUST be included in an Open message.
The ID type can be MPLS label or other type of ID. The following ID-
CONTROL-SPACE TLV is defined in this document -
* LABEL-CONTROL-SPACE TLV - for MPLS Labels (including for SR-MPLS)
* FUNCTION-ID-CONTROL-SPACE TLV - for SRv6 SID Function ID
The procedure of ID space control to PCE is shown below:
Li, et al. Expires 23 April 2026 [Page 6]
Internet-Draft PCE Controlled ID Space October 2025
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| Open msg (LABEL-CONTROL-SPACE,etc) |
| |
|-------- |
| \ Open msg |
| \ -----------------------------|
| \/ |
| /\ |
| / ---------------------------->|
| / |
|<------- Keepalive |
| -----------------------------|
|Keepalive / |
|-------- / |
| \/ |
| /\ |
|<------- ------------------------------>|
| |
Figure 1: ID space control to PCE
If the ID space control procedure is successful, the PCE will return
a KeepAlive message to the PCC. If there is an error in processing
the corresponding TLV, an Error (PCErr) message will be sent to the
PCC with Error-Type=1 (PCEP session establishment failure) and Error-
value=TBD3 (ID space control failure).
After this process, a stateful PCE can learn the PCE-controlled ID
spaces of a node (PCC) under its control. A PCE can then allocate
IDs within the controlled-ID space. For example, a PCE can actively
allocate labels and download forwarding instructions for the PCECC
LSP as described in [RFC9050]. A PCE can also allocate labels from
the PCE-controlled portion of the SRGB/SRLB for PCECC-SR [RFC9050].
The full SRGB/SRLB of a node could be learned via the existing IGP or
BGP-LS mechanism.
The procedure for handling the FUNCTION-ID-CONTROL-SPACE TLV is the
same as above.
Note that this information is advertised at the session
initialization phase and thus if there is a change in ID space, the
session needs to be restarted.
Li, et al. Expires 23 April 2026 [Page 7]
Internet-Draft PCE Controlled ID Space October 2025
5. Objects
5.1. Open Object
For advertising the PCE-controlled ID space to a PCE, this document
defines several TLVs within the OPEN object.
5.1.1. LABEL-CONTROL-SPACE TLV
For a PCC to inform the label space under the PCE control, this
document defines a new LABEL-CONTROL-SPACE TLV.
The LABEL-CONTROL-SPACE TLV is an optional TLV in the OPEN object,
and its format is shown in the following figure:
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=TBD1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Block | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start_1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range_1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start_n | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range_n | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LABEL-CONTROL-SPACE TLV
The type (16 bits) of the TLV is TBD1. The length field (16 bits)
has a variable value.
Num of Block (8 bits): the number of ID blocks. The range of a block
is described by a start field and a range field.
Flags (24 bits): No flag is currently defined. The unassigned bits
of the Flags field MUST be set to 0 on transmission and MUST be
ignored on receipt.
Li, et al. Expires 23 April 2026 [Page 8]
Internet-Draft PCE Controlled ID Space October 2025
Start_i (24 bits): indicates the beginning of the label block i.
Range_i (24 bits): indicates the range of the label block i.
Reserved: MUST be set to 0 on transmission and MUST be ignored on
reception.
LABEL-CONTROL-SPACE TLV SHOULD be included only once in an Open
Message. On receipt, only the first instance is processed and others
MUST be ignored.
A stateful PCE can actively allocate labels and download forwarding
instructions for the PCECC LSP as described in [RFC9050]. A PCE can
also allocate labels from SRGB/SRLB for PCECC-SR
[I-D.ietf-pce-pcep-extension-pce-controller-sr]. The Binding
Segments can also be selected for the PCE-controlled space [RFC9050].
5.1.2. FUNCT-ID-CONTROL-SPACE TLV
For a PCC to inform the SRv6 SID Function ID space under the PCE
control, this document defines a new FUNCT-ID-CONTROL-SPACE TLV.
The FUNCT-ID-CONTROL-SPACE TLV is an optional TLV for use in the OPEN
object, and its format is shown in the following figure:
Li, et al. Expires 23 April 2026 [Page 9]
Internet-Draft PCE Controlled ID Space October 2025
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=TBD2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block | Flags |L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID |
| Structure |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start_1 (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range_1 (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start_n (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range_n (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loc Size | Locator_1 (variable)... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator_n (variable)... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: FUNCT-ID-CONTROL-SPACE TLV
The type (16 bits) of the TLV is TBD2. The length field (16 bits)
has a variable value.
Block(8 bits): the number of ID blocks. The range of a block is
described by a start field and a range field.
Flags (24 bits): Following flags are currently defined
* L-flag: Locator flag, set when the locator information is included
in this TLV. If L-flag is unset, Loc Size and variable Locator
field MUST NOT be included in this TLV, and the Function ID spaces
apply to all Locators.
The unassigned bits of Flags field MUST be set to 0 on transmission
and MUST be ignored on receipt.
SID Structure: 64-bit field formatted as per "SID Structure" in
[RFC9603].
Li, et al. Expires 23 April 2026 [Page 10]
Internet-Draft PCE Controlled ID Space October 2025
Start_i (variable length): indicates the beginning of the Function ID
block i. The length is specified in the Fun. Length field of SID
Structure (SRv6 SID Function length in bits).
Range_i (variable length): indicates the range of the Function ID
block i. The length is specified in the Fun. Length field of SID
Structure.
Loc size (8 bits): indicates the number of Locator. Appears only
when the L-flag is set.
Locator (variable length): the value of a Locator. The Function ID
spaces specified in this TLV are associated with this locator. The
length equals to LB length + LN length in the SID Structure where LB
Length is the SRv6 SID Locator Block length in bits and LN Length is
the SRv6 SID Locator Node length in bits. Note that there may exists
multiple locator sharing the same FUNC ID space.
As per [RFC5440], the value portion of the PCEP TLV needs to be
4-bytes aligned, so a FUNCT-ID-CONTROL-SPACE TLV is padded with
trailing zeros to a 4-byte boundary.
Multiple FUNCT-ID-CONTROL-SPACE TLVs MAY be included in an OPEN
object to specify Function ID space specific to each locator.
A stateful PCE can actively allocate SRv6 SID and download SIDs for
the PCECC-SRv6 as described in
[I-D.ietf-pce-pcep-extension-pce-controller-srv6].
Note that SRv6 SID allocation involves LOC:FUNCT:ARG; the LOC is
assumed to be known at PCE and FUNCT is allocated from the PCE-
controlled Function ID block.
6. Other Considerations
In case of multiple PCEs, a PCC MAY decide to give control over
different ID space to each instance of the PCE. In case a PCC
includes the same ID space to multiple PCEs, the PCE MUST use
synchronization mechanism between PCEs to avoid issues described in
[I-D.ietf-pce-state-sync].
The PCE would allocate ID from the PCE controlled ID space. The PCC
would not allocate ID by itself from this space as long as it has an
active PCEP session to a PCE to which it has given control over the
ID space.
Li, et al. Expires 23 April 2026 [Page 11]
Internet-Draft PCE Controlled ID Space October 2025
Note that if there is any change in the ID space, the PCC needs to
bring the session down and re-establish the session with new TLVs. A
future specification could specify a mechanism to update this
information without bringing down the session. During state
synchronization the PCE would need to consider the new ID space into
consideration and needs to re-establish the LSP/SR-paths if needed.
The PCC can regain control of the ID space by closing the PCEP
session and require new session without ID space TLVs specified in
this document.
7. IANA Considerations
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
registry group. This document requests IANA actions to allocate code
points for the protocol elements defined in this document.
7.1. PCEP TLV Type Indicators
IANA maintains a registry called "PCEP TLV Type Indicators". IANA is
requested to make an assignment from this registry as follows:
Value | Meaning | Reference
--------+------------------------------+-------------
TBD1 | LABEL-CONTROL-SPACE TLV | [This.I-D]
TBD2 | FUNCT-ID-CONTROL-SPACE TLV | [This.I-D]
7.2. LABEL-CONTROL-SPACE TLV's Flag field
This document defines the LABEL-CONTROL-SPACE TLV and requests that
IANA to create a new registry to manage the value of the LABEL-
CONTROL-SPACE TLV's 24-bits Flag field. New values are to be
assigned by IETF Review [RFC8126]. Each bit should be tracked with
the following qualities:
* Bit number (counting from bit 0 as the most significant bit)
* Capability description
* Defining RFC
Currently, there is no allocation in this registry.
Bit | Name | Reference
--------+------------------------------+-------------
0-23 | Unassigned | [This.I-D]
Li, et al. Expires 23 April 2026 [Page 12]
Internet-Draft PCE Controlled ID Space October 2025
7.3. FUNCT-ID-CONTROL-SPACE TLV's Flag field
This document defines the FUNCT-ID-CONTROL-SPACE TLV and requests
that IANA to create a new registry to manage the value of the FUNCT-
ID-CONTROL-SPACE TLV's 24-bits Flag field. New values are to be
assigned by IETF Review [RFC8126]. Each bit should be tracked with
the following qualities:
* Bit number (counting from bit 0 as the most significant bit)
* Capability description
* Defining RFC
Currently, there is no allocation in this registry.
Bit | Name | Reference
--------+------------------------------+-------------
23 | L-Bit | [This.I-D]
0-22 | Unassigned | [This.I-D]
7.4. PCEP-Error
IANA is requested to allocate a error values within the "PCEP- ERROR
Object Error Types and Values" registry:
Error-Type | Meaning |Error-value | Reference
------------+----------------+--------------+----------
1 | PCEP session | TBD3: ID | [This.I-D]
| establishment | space control|
| failure | failure |
8. Security Considerations
The security considerations described in [RFC9050],
[I-D.ietf-pce-pcep-extension-pce-controller-sr], and
[I-D.ietf-pce-pcep-extension-pce-controller-srv6] and apply to the
extensions described in this document.
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 [RFC9325] (unless explicitly set aside in
[RFC8253]).
Li, et al. Expires 23 April 2026 [Page 13]
Internet-Draft PCE Controlled ID Space October 2025
9. Acknowledgements
Thanks to Adrian Farrel, Ran Chen, Shengnan Yue, Boris Hassanov,
Samuel Sidor, and Gyan Mishra for review comments.
10. References
10.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>.
[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>.
[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>.
[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>.
[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>.
Li, et al. Expires 23 April 2026 [Page 14]
Internet-Draft PCE Controlled ID Space October 2025
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>.
[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
and Y. Zhu, "Path Computation Element Communication
Protocol (PCEP) Extensions for IPv6 Segment Routing",
RFC 9603, DOI 10.17487/RFC9603, July 2024,
<https://www.rfc-editor.org/info/rfc9603>.
10.2. Informative References
[I-D.ietf-pce-pcep-extension-pce-controller-sr]
Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, "PCE
Communication Protocol (PCEP) Extensions for Using PCE as
a Central Controller (PCECC) for Segment Routing (SR) MPLS
Segment Identifier (SID) Allocation and Distribution.",
Work in Progress, Internet-Draft, draft-ietf-pce-pcep-
extension-pce-controller-sr-11, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-extension-pce-controller-sr-11>.
[I-D.ietf-pce-pcep-extension-pce-controller-srv6]
Li, Z., Peng, S., Geng, X., and M. S. Negi, "PCE
Communication Protocol (PCEP) Extensions for Using the PCE
as a Central Controller (PCECC) for Segment Routing over
IPv6 (SRv6) Segment Identifier (SID) Allocation and
Distribution.", Work in Progress, Internet-Draft, draft-
ietf-pce-pcep-extension-pce-controller-srv6-05, 5
September 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-pce-pcep-extension-pce-controller-srv6-05>.
[I-D.ietf-pce-state-sync]
Zheng, H., Litkowski, S., Sivabalan, S., and C. Li,
"Procedures for Communication between Stateful Path
Computation Elements", Work in Progress, Internet-Draft,
draft-ietf-pce-state-sync-12, 29 May 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
state-sync-12>.
Li, et al. Expires 23 April 2026 [Page 15]
Internet-Draft PCE Controlled ID Space October 2025
[I-D.stone-pce-update-open]
Stone, A., Li, C., and S. Sidor, "PCE Communication
Protocol (PCEP) extensions for updating Open Message
content", Work in Progress, Internet-Draft, draft-stone-
pce-update-open-01, 25 February 2025,
<https://datatracker.ietf.org/doc/html/draft-stone-pce-
update-open-01>.
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
Li, et al. Expires 23 April 2026 [Page 16]
Internet-Draft PCE Controlled ID Space October 2025
[RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based
Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024,
<https://www.rfc-editor.org/info/rfc9604>.
Appendix A. Discussion and Resolution on Encoding PCE Controlled ID-
Space in Open Message
During the WG adoption process, concerns were raised about using the
Open message to convey the PCE-controlled ID-Space from the PCC to
the PCE. These concerns were discussed during the IETF 120 meeting,
and it was concluded that the Open message would continue to be used
to encode the PCE-controlled ID space. It was also suggested that a
generic notification mechanism could be developed to update
parameters exchanged during the Open message, which would fall
outside the scope of this document. One such proposal is outlined in
[I-D.stone-pce-update-open].
Appendix B. Open Discussion
* Should there be separate TLV for SRGB and SRLB? - No, the SRGB and
SRLB configurations of the node is done independently, it is
advertised independently via IGP/BGP-LS. The label range that is
set aside is orthogonal to it.
Appendix C. Contributors
Li, et al. Expires 23 April 2026 [Page 17]
Internet-Draft PCE Controlled ID Space October 2025
Dhruv Dhody
Huawei
India
EMail: dhruv.ietf@gmail.com
Mach Chen
Huawei Technologies
China
EMail: Mach.chen@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
EMail: lizhenbin@huawei.com
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
EMail: jie.dong@huawei.com
Authors' Addresses
Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: c.l@huawei.com
Li, et al. Expires 23 April 2026 [Page 18]
Internet-Draft PCE Controlled ID Space October 2025
Hang Shi
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: shihang9@huawei.com
Aijun Wang
China Telecom
Beiqijia Town,
Beijing
Changping District, 102209
China
Email: wangaj3@chinatelecom.cn
Weiqiang Cheng
China Mobile
Email: chengweiqiang@chinamobile.com
Chao Zhou
HPE
Email: chaozhou_us@yahoo.com
Li, et al. Expires 23 April 2026 [Page 19]