Internet-Draft PCE Controlled ID Space July 2022
Li, et al. Expires 25 January 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-li-pce-controlled-id-space-12
Published:
Intended Status:
Experimental
Expires:
Authors:
C. Li
Huawei Technologies
H. Shi
Huawei Technologies
A. Wang
China Telecom
W. Cheng
China Mobile
C. Zhou
HPE

Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space

Abstract

The Path Computation Element Communication Protocol (PCEP) provides a mechanisms 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 provide 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 an 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.

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 25 January 2023.

Table of Contents

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 extension 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 extension adds the capability to advertise the range (from SRGB or SRLB of the node) via a PCEP extension.

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

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 Segment Routing Global Block (SRGB) or Segment Routing Local Block (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 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 -

The procedure of ID space control to PCE is shown below:

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

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.

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:

 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)                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            Range (1)                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ......                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            Start (n)                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            Range (n)                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loc Size     | Locator (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 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].

Start(i) (128 bits): indicates the beginning of the Function ID block i.

Range(i) (128 bits): indicates the range of the Function ID block i.

Loc size(8 bits): indicates the bit length of a 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.

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.

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.


 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

10.1. Normative References

[I-D.ietf-pce-segment-routing-ipv6]
Li(Editor), C., Negi, M. S., Sivabalan, S., Koldychev, M., Kaladharan, P., 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-14, , <https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-14.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", DOI 10.17487/RFC2119, BCP 14, RFC 2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5440]
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", DOI 10.17487/RFC5440, RFC 5440, , <https://www.rfc-editor.org/info/rfc5440>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 8126, DOI 10.17487/RFC8126, BCP 26, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", DOI 10.17487/RFC8174, RFC 8174, BCP 14, , <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, , <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, , <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", DOI 10.17487/RFC8281, RFC 8281, , <https://www.rfc-editor.org/info/rfc8281>.
[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, , <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, "Path Computation Element 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-09, , <https://www.ietf.org/archive/id/draft-dhody-pce-pcep-extension-pce-controller-srv6-09.txt>.
[I-D.ietf-pce-binding-label-sid]
Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., and C. L. (editor), "Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.", Work in Progress, Internet-Draft, draft-ietf-pce-binding-label-sid-15, , <https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-15.txt>.
[I-D.ietf-pce-pcep-extension-pce-controller-sr]
Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, "Path Computation Element 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-05, , <https://www.ietf.org/archive/id/draft-ietf-pce-pcep-extension-pce-controller-sr-05.txt>.
[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-03, , <https://www.ietf.org/archive/id/draft-ietf-pce-state-sync-03.txt>.
[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-routing-policy-22, , <https://www.ietf.org/archive/id/draft-ietf-spring-segment-routing-policy-22.txt>.
[RFC4657]
Ash, J., Ed. and J L. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, , <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)", DOI 10.17487/RFC7525, BCP 195, RFC 7525, , <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", DOI 10.17487/RFC8402, RFC 8402, , <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", DOI 10.17487/RFC8664, RFC 8664, , <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, , <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", DOI 10.17487/RFC9050, RFC 9050, , <https://www.rfc-editor.org/info/rfc9050>.

Appendix A. Contributors

   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
Hang Shi
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Aijun Wang
China Telecom
Beiqijia Town,
Beijing
Changping District, 102209
China
Weiqiang Cheng
China Mobile
Chao Zhou
HPE