Skip to main content

Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space
draft-li-pce-controlled-id-space-16

Document Type Active Internet-Draft (individual)
Authors Cheng Li , Hang Shi , Aijun Wang , Weiqiang Cheng , Chao Zhou
Last updated 2024-01-25
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-li-pce-controlled-id-space-16
Network Working Group                                              C. Li
Internet-Draft                                               H. Shi, Ed.
Intended status: Experimental                        Huawei Technologies
Expires: 28 July 2024                                            A. Wang
                                                           China Telecom
                                                                W. Cheng
                                                            China Mobile
                                                                 C. Zhou
                                                                     HPE
                                                         25 January 2024

  Path Computation Element Communication Protocol (PCEP) extension to
             advertise the PCE Controlled Identifier Space
                  draft-li-pce-controlled-id-space-16

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 or Binding Segment Identifier (SID)
   for Segment Routing (SR), there are requirements for a stateful PCE
   to make allocation of labels, SIDs, etc.  These use cases require PCE
   aware of various identifier spaces from where to make allocations on
   behalf of a PCC.  This document describes a generic mechanism for a
   PCC to 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 to-be-defined 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 28 July 2024                  [Page 1]
Internet-Draft           PCE Controlled ID Space            January 2024

   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 28 July 2024.

Copyright Notice

   Copyright (c) 2024 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
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13

Li, et al.                Expires 28 July 2024                  [Page 2]
Internet-Draft           PCE Controlled ID Space            January 2024

   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

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 to enable stateful
   control of LSPs within and across PCEP sessions in compliance with
   [RFC4657].  Furthermore, [RFC8281] describes the setup, maintenance,
   and teardown of PCE-initiated LSPs under the stateful PCE model,
   without the need for local configuration on the PCC, thus allowing
   for a dynamic 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 documnet 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 28 July 2024                  [Page 3]
Internet-Draft           PCE Controlled ID Space            January 2024

   In addition, [I-D.dhody-pce-pcep-extension-pce-controller-srv6]
   specifies the procedures and PCEP extensions of PCECC for SRv6.  An
   SRv6 SID is represented as LOC:FUNCT ([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 28 July 2024                  [Page 4]
Internet-Draft           PCE Controlled ID Space            January 2024

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.dhody-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)
   [I-D.ietf-pce-binding-label-sid] to its policy
   [I-D.ietf-spring-segment-routing-policy].  The instantiation of which
   may involve a list of SIDs.  The Binding SID can be allocated by the
   node as described in [I-D.ietf-pce-binding-label-sid], 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

Li, et al.                Expires 28 July 2024                  [Page 5]
Internet-Draft           PCE Controlled ID Space            January 2024

   allocate Binding SID actively from the PCC's label space as described
   in the above use case.

   This is applicable for all binding segment allocated to the SR-MPLS
   or SRv6 path.

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 can 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 could be aware of the ID space from 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 28 July 2024                  [Page 6]
Internet-Draft           PCE Controlled ID Space            January 2024

              +-+-+                                     +-+-+
              |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=TBD (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 28 July 2024                  [Page 7]
Internet-Draft           PCE Controlled ID Space            January 2024

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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  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.

   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 28 July 2024                  [Page 8]
Internet-Draft           PCE Controlled ID Space            January 2024

   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 28 July 2024                  [Page 9]
Internet-Draft           PCE Controlled ID Space            January 2024

      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
   [I-D.ietf-pce-segment-routing-ipv6].

Li, et al.                Expires 28 July 2024                 [Page 10]
Internet-Draft           PCE Controlled ID Space            January 2024

   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.

   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.  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.dhody-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 (such as [I-D.ietf-pce-state-sync]) to
   avoid allocating the same ID.

   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 28 July 2024                 [Page 11]
Internet-Draft           PCE Controlled ID Space            January 2024

   Note that if there is any change in the ID space, the PCC MUST bring
   the session down and re-establish the session with new TLVs.  During
   state synchronization the PCE would need to consider the new ID space
   into consideration and SHOULD 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.  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 subregistry called "PCEP TLV Type Indicators".  IANA
   is requested to make an assignment from this subregistry 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 sub-registry to manage the value of the LABEL-
   CONTROL-SPACE TLV's 24-bits Flag field.  New values are to be
   assigned by Standards Action [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.

Li, et al.                Expires 28 July 2024                 [Page 12]
Internet-Draft           PCE Controlled ID Space            January 2024

    Bit    | Name                         | Reference
   --------+------------------------------+-------------
    0-23   | Unassigned                   | [This.I-D]

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 sub-registry to manage the value of the
   FUNCT-ID-CONTROL-SPACE TLV's 24-bits Flag field.  New values are to
   be assigned by Standards Action [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]

8.  Security Considerations

   The security considerations described in [RFC9050],
   [I-D.ietf-pce-pcep-extension-pce-controller-sr], and
   [I-D.dhody-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 [RFC7525] (unless explicitly set aside in
   [RFC8253]).

9.  Acknowledgements

   TBD.

10.  References

Li, et al.                Expires 28 July 2024                 [Page 13]
Internet-Draft           PCE Controlled ID Space            January 2024

10.1.  Normative References

   [I-D.ietf-pce-segment-routing-ipv6]
              Li, C., Kaladharan, P., Sivabalan, S., Koldychev, M., and
              Y. Zhu, "Path Computation Element Communication Protocol
              (PCEP) Extensions for Segment Routing leveraging the IPv6
              dataplane", Work in Progress, Internet-Draft, draft-ietf-
              pce-segment-routing-ipv6-20, 8 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              segment-routing-ipv6-20>.

   [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 28 July 2024                 [Page 14]
Internet-Draft           PCE Controlled ID Space            January 2024

   [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>.

10.2.  Informative References

   [I-D.dhody-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-
              dhody-pce-pcep-extension-pce-controller-srv6-10, 15
              January 2023, <https://datatracker.ietf.org/doc/html/
              draft-dhody-pce-pcep-extension-pce-controller-srv6-10>.

   [I-D.ietf-pce-binding-label-sid]
              Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
              and C. Li, "Carrying Binding Label/Segment Identifier
              (SID) in PCE-based Networks.", Work in Progress, Internet-
              Draft, draft-ietf-pce-binding-label-sid-16, 27 March 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              binding-label-sid-16>.

   [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-08, 1 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              pcep-extension-pce-controller-sr-08>.

   [I-D.ietf-pce-state-sync]
              Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter
              Stateful Path Computation Element (PCE) Communication
              Procedures.", Work in Progress, Internet-Draft, draft-
              ietf-pce-state-sync-06, 2 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              state-sync-06>.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", Work in
              Progress, Internet-Draft, draft-ietf-spring-segment-

Li, et al.                Expires 28 July 2024                 [Page 15]
Internet-Draft           PCE Controlled ID Space            January 2024

              routing-policy-22, 22 March 2022,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              segment-routing-policy-22>.

   [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>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", RFC 7525, DOI 10.17487/RFC7525, May 2015,
              <https://www.rfc-editor.org/info/rfc7525>.

   [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>.

Appendix A.  Contributors

Li, et al.                Expires 28 July 2024                 [Page 16]
Internet-Draft           PCE Controlled ID Space            January 2024

      Dhruv Dhody
      Huawei Technologies
      Divyashree Techno Park, Whitefield
      Bangalore, Karnataka 560066
      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

   Hang Shi (editor)
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.

Li, et al.                Expires 28 July 2024                 [Page 17]
Internet-Draft           PCE Controlled ID Space            January 2024

   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 28 July 2024                 [Page 18]