PCE Working Group Z. Li
Internet-Draft S. Peng
Intended status: Standards Track X. Geng
Expires: August 25, 2021 Huawei Technologies
M. Negi
RtBrick Inc
February 21, 2021
PCEP Procedures and Protocol Extensions for Using PCE as a Central
Controller (PCECC) for P2MP LSPs
draft-dhody-pce-pcep-extension-pce-controller-p2mp-06
Abstract
The Path Computation Element (PCE) is a core component of Software-
Defined Networking (SDN) systems. It can compute optimal paths for
traffic across a network and can also update the paths to reflect
changes in the network or traffic demands.
The PCE has been identified as an appropriate technology for the
determination of the paths of point-to-multipoint (P2MP) TE Label
Switched Paths (LSPs).
PCE was developed to derive paths for MPLS P2MP LSPs, which are
supplied to the head end (root) of the LSP using PCEP. PCEP has been
proposed as a control protocol to allow the PCE to be fully enabled
as a central controller.
A PCE-based Central Controller (PCECC) can simplify the processing of
a distributed control plane by blending it with elements of SDN and
without necessarily completely replacing it. Thus, the P2MP LSP can
be calculated/set up/initiated and the label forwarding entries can
also be downloaded through a centralized PCE server to each network
device along the P2MP path, while leveraging the existing PCE
technologies as much as possible.
This document specifies the procedures and PCEP extensions for using
the PCE as the central controller for P2MP TE LSP by provisioning
labels along the path of the static P2MP LSP.
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
Li, et al. Expires August 25, 2021 [Page 1]
Internet-Draft PCECC February 2021
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 August 25, 2021.
Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5
4. Procedures for Using the PCE as a Central Controller (PCECC)
for P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6
4.2. PCECC Capability Advertisement . . . . . . . . . . . . . 6
4.3. LSP Operations . . . . . . . . . . . . . . . . . . . . . 6
4.3.1. PCE-Initiated PCECC LSP . . . . . . . . . . . . . . . 7
4.3.2. PCC-Initiated PCECC LSP . . . . . . . . . . . . . . . 7
4.3.3. Central Control Instructions . . . . . . . . . . . . 8
4.3.3.1. Label Download CCI . . . . . . . . . . . . . . . 8
4.3.3.2. Label Clean up CCI . . . . . . . . . . . . . . . 9
4.3.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 10
4.3.5. Re-Delegation and Clean up . . . . . . . . . . . . . 10
4.3.6. Synchronization of Central Controllers Instructions . 10
4.3.7. PCECC LSP State Report . . . . . . . . . . . . . . . 10
4.3.8. PCC-Based Allocations . . . . . . . . . . . . . . . . 10
5. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 10
6. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 10
Li, et al. Expires August 25, 2021 [Page 2]
Internet-Draft PCECC February 2021
6.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 10
6.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 11
6.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Manageability Considerations . . . . . . . . . . . . . . . . 12
8.1. Control of Function and Policy . . . . . . . . . . . . . 12
8.2. Information and Data Models . . . . . . . . . . . . . . . 12
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 13
8.6. Impact On Network Operations . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . . . 13
9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The Path Computation Element (PCE) [RFC4655] was developed to offload
the path computation function from routers in an MPLS traffic-
engineered network. Since then, the role and function of the PCE has
grown to cover a number of other uses (such as GMPLS [RFC7025]) and
to allow delegated control [RFC8231] and PCE-initiated use of network
resources [RFC8281].
According to [RFC7399], Software-Defined Networking (SDN) refers to a
separation between the control elements and the forwarding components
so that software running in a centralized system, called a
controller, can act to program the devices in the network to behave
in specific ways. A required element in an SDN architecture is a
component that plans how the network resources will be used and how
the devices will be programmed. It is possible to view this
component as performing specific computations to place traffic flows
within the network given knowledge of the availability of network
resources, how other forwarding devices are programmed, and the way
that other flows are routed. This is the function and purpose of a
PCE, and the way that a PCE integrates into a wider network control
system (including an SDN system) is presented in [RFC7491].
In early PCE implementations, where the PCE was used to derive paths
for MPLS Label Switched Paths (LSPs), paths were requested by network
elements (known as Path Computation Clients (PCCs)), and the results
Li, et al. Expires August 25, 2021 [Page 3]
Internet-Draft PCECC February 2021
of the path computations were supplied to network elements using the
Path Computation Element Communication Protocol (PCEP) [RFC5440].
This protocol was later extended to allow a PCE to send unsolicited
requests to the network for LSP establishment [RFC8281].
[RFC8283] introduces the architecture for PCE as a central controller
as an extension of the architecture described in [RFC4655] and
assumes the continued use of PCEP as the protocol used between PCE
and PCC. [RFC8283] further examines the motivations and
applicability for PCEP as a Southbound Interface (SBI), and
introduces the implications for the protocol.
A PCE-based Central Controller (PCECC) can simplify the processing of
a distributed control plane by blending it with elements of SDN and
without necessarily completely replacing it. Thus, the LSP can be
calculated/setup/initiated and the label 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.
[I-D.ietf-pce-pcep-extension-for-pce-controller] specify the
procedures and PCEP extensions for using the PCE as the central
controller for static P2P LSPs, where LSPs can be 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 PCE-based controller
keeps a view of the network and determines the paths of the end-to-
end LSPs, and the controller uses PCEP to communicate with each
router along the path of the end-to-end LSP.
[RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic
Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The
PCE has been identified as a suitable application for the computation
of paths for P2MP TE LSPs ([RFC5671]). The extensions of PCEP to
request path computation for P2MP TE LSPs are described in [RFC8306].
Further [RFC8623] specify the extensions that are necessary in order
for the deployment of stateful PCEs to support P2MP TE LSPs as well
as the setup, maintenance and teardown of PCE-initiated P2MP LSPs
under the stateful PCE model.
This document extends
[I-D.ietf-pce-pcep-extension-for-pce-controller] to specify the
procedures and PCEP extensions for using the PCE as the central
controller for static P2MP LSPs, where LSPs can be provisioned as
explicit label instructions at each hop on the end-to-end path with
an added functionality of a P2MP branch node. As per [RFC4875], a
branch node is an LSR that replicates the incoming data on to one or
Li, et al. Expires August 25, 2021 [Page 4]
Internet-Draft PCECC February 2021
more outgoing interfaces. [I-D.ietf-teas-pcecc-use-cases] describes
the use cases for P2MP in PCECC architecture.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
Terminologies used in this document is the same as described in the
draft [RFC8283] and [I-D.ietf-teas-pcecc-use-cases].
3. Basic PCECC Mode
As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], in
this mode 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.
Note that the PCE-based controller will take responsibility for
managing some part of the MPLS label space for each of the routers
that it controls, and may taker wider responsibility for partitioning
the label space for each router and allocating different parts for
different uses. As per
[I-D.ietf-pce-pcep-extension-for-pce-controller], the PCC must not
make allocations from the label space set aside for the PCE to avoid
overlap and collisions of label allocations. This is also described
in section 3.1.2. of [RFC8283]. For the purpose of this document, it
is assumed that the label range to be used by a PCE is known and set
on both PCEP peers. A future extension could add the capability to
advertise the range via possible PCEP extensions as well (see
[I-D.li-pce-controlled-id-space]). The rest of the processing is
similar to the existing stateful PCE mechanism.
This document extends the functionality to include support for
central control instruction for replication at the branch nodes.
The rest of the processing is similar to the existing stateful PCE
mechanism for P2MP [RFC8623].
Li, et al. Expires August 25, 2021 [Page 5]
Internet-Draft PCECC February 2021
4. Procedures for Using the PCE as a Central Controller (PCECC) for
P2MP
4.1. Stateful PCE Model
Active stateful PCE is described in [RFC8231] and extended for P2MP
[RFC8623]. PCE as a Central Controller (PCECC) reuses the existing
active stateful PCE mechanism as much as possible to control the
LSPs.
[I-D.ietf-pce-pcep-extension-for-pce-controller] extends PCEP
messages - PCRpt, PCInitiate message for the Central Controller's
Instructions (CCI) (label forwarding instructions in the context of
this document). This document specify the procedure for additional
instruction for branch node needed for P2MP.
4.2. PCECC Capability Advertisement
As per [I-D.ietf-pce-pcep-extension-for-pce-controller], during PCEP
Initialization Phase, PCEP Speakers (PCE or PCC) advertise their
support of the PCECC extensions by sending a PATH-SETUP-TYPE-
CAPABILITY TLV in the OPEN object with this PST=TBD
[I-D.ietf-pce-pcep-extension-for-pce-controller] included in the PST
list.
[I-D.ietf-pce-pcep-extension-for-pce-controller] also defines the
PCECC Capability sub-TLV. A new M-bit is added in the PCECC-
CAPABILITY sub-TLV to indicate support for PCECC-P2MP. A PCC MUST
set M-bit in the PCECC-CAPABILITY sub-TLV and include STATEFUL-PCE-
CAPABILITY TLV with the P2MP bits set ([RFC8623]) in the OPEN Object
to support the PCECC P2MP extensions defined in this document. If
the M-bit is set in PCECC-CAPABILITY sub-TLV and N-bit in the
STATEFUL-PCE-CAPABILITY TLV is not set in the OPEN Object, the PCE
SHOULD send a PCErr message with Error-Type=19 (Invalid Operation)
and Error-value=TBD2 (P2MP capability was not advertised) and
terminate the session.
The rest of the processing is as per
[I-D.ietf-pce-pcep-extension-for-pce-controller].
4.3. LSP Operations
The PCEP messages pertaining to a PCECC includes the PATH-SETUP-TYPE
TLV [RFC8408] with PST=TBD
[I-D.ietf-pce-pcep-extension-for-pce-controller] in the SRP object to
identify the PCECC LSP is intended as per
[I-D.ietf-pce-pcep-extension-for-pce-controller].
Li, et al. Expires August 25, 2021 [Page 6]
Internet-Draft PCECC February 2021
4.3.1. PCE-Initiated PCECC LSP
The LSP Instantiation operation is the same as defined in [RFC8281]
and [RFC8623].
In order to set up a PCE-Initiated P2MP LSP based on the PCECC
mechanism, a PCE sends PCInitiate message with Path Setup Type set to
TBD for PCECC ([I-D.ietf-pce-pcep-extension-for-pce-controller]) to
the ingress PCC (root node).
P2MP-LSP-IDENTIFIER TLV [RFC8623] MUST be included for the PCECC P2MP
LSPs, the tuple uniquely identifies the P2MP LSP in the network. As
per [I-D.ietf-pce-pcep-extension-for-pce-controller], the LSP object
is included in the central controller's instructions (label download)
to identify the PCECC P2MP LSP for this instruction. The handling of
PLSP-ID is as per [I-D.ietf-pce-pcep-extension-for-pce-controller].
The ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C
(Create) flag (see [RFC8281]) in the LSP object of the PCRpt message.
The PCC responds with a PCRpt message with the status set to "GOING-
UP" and carrying the assigned PLSP-ID. As per
[I-D.ietf-pce-pcep-extension-for-pce-controller] when the PCE
receives this PCRpt message with the PLSP-ID, it assigns labels along
the path; and sets up the path by sending a PCInitiate message to
each node along the path of the P2MP Tree as per the PCECC technique.
The CC-ID uniquely identifies the central controller instruction
within a PCEP session. Each PCC further responds with the PCRpt
messages including the central controller instruction (CCI) and the
LSP objects.
As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], the
label forwarding instructions from PCECC are sent after the initial
PCInitiate and PCRpt exchange. This is done so that the PLSP-ID and
other LSP identifiers can be obtained from the ingress and can be
included in the label forwarding instruction in the next PCInitiate
message.
4.3.2. PCC-Initiated PCECC LSP
In order to set up a P2MP LSP based on the PCECC mechanism where the
LSP is configured at the PCC, a PCC MUST delegate the P2MP LSP by
sending a PCRpt message with PST set for PCECC and D (Delegate) flag
(see [RFC8623]) set in the LSP object.
When a PCE receives the initial PCRpt message with the D flags and
PST Type set to TBD, it SHOULD calculate the P2MP tree and assigns
labels along the P2MP tree; and set up the P2MP LSP by sending
PCInitiate message to each node along the path of the P2MP LSP as per
Li, et al. Expires August 25, 2021 [Page 7]
Internet-Draft PCECC February 2021
[I-D.ietf-pce-pcep-extension-for-pce-controller]. The new extension
required is the instructions on the branch nodes for replications to
more than one outgoing interface with the respective label. The rest
of the operations remains the same as
[I-D.ietf-pce-pcep-extension-for-pce-controller] and [RFC8623].
4.3.3. Central Control Instructions
The central controller's instructions (CCI) for the label operations
in PCEP is done via the PCInitiate message as described in
[I-D.ietf-pce-pcep-extension-for-pce-controller], by defining a PCEP
Objects for CCI operations. The local label range of each PCC is
assumed to be known by both the PCC and the PCE.
4.3.3.1. Label Download CCI
In order to set up an LSP based on PCECC, the PCE sends a PCInitiate
message to each node along the path to download the Label instruction
as described in Section 4.3.1 and Section 4.3.2.
The CCI object MUST be included, along with the LSP object in the
PCInitiate message. As per
[I-D.ietf-pce-pcep-extension-for-pce-controller], there are at most 2
instances of CCI object in the PCInitiate message. For PCECC-P2MP
operations, multiple instances of CCI object for out-labels is
allowed. Similarly to acknowledge the central controller
instructions, the PCRpt message allows multiple instances of CCI
object for PCECC-P2MP operations.
The LSP-IDENTIFIER TLV MUST be included in the LSP object. The
SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object.
As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], if
a node (PCC) receives a PCInitiate message which includes a Label to
download, as part of CCI, that is out of the range set aside for the
PCE, it send a PCErr message with Error-type=TBD (PCECC failure) and
Error-value=TBD (Label out of range) (defined in
[I-D.ietf-pce-pcep-extension-for-pce-controller]). If a PCC receives
a PCInitiate message but fails to download the Label entry, it sends
a PCErr message with Error-type=TBD (PCECC failure) and Error-
value=TBD (Instruction failed) (defined in
[I-D.ietf-pce-pcep-extension-for-pce-controller]).
Consider the example in the [I-D.ietf-teas-pcecc-use-cases] -
Li, et al. Expires August 25, 2021 [Page 8]
Internet-Draft PCECC February 2021
+----------+
| R1 | Root node of the P2MP TE LSP
+----------+
|6000
+----------+
Transit Node | R2 |
branch +----------+
* | * *
9001* | * *9002
* | * *
+-----------+ | * +-----------+
| R4 | | * | R5 | Transit Nodes
+-----------+ | * +-----------+
* | * * +
9003* | * * +9004
* | * * +
+-----------+ +-----------+
| R3 | | R6 | Leaf Node
+-----------+ +-----------+
9005|
+-----------+
| R8 | Leaf Node
+-----------+
PCECC would provision each node along the path and assign incoming
and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000},
{6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003,
R3, 9005}, {9004, R6}, {9005, R8}. The operations on all nodes except
R2 are same as [I-D.ietf-pce-pcep-extension-for-pce-controller]. The
branch node (R2) needs to be instructed to replicate two copies of
the incoming packet, and sent towards R4 and R5 with 9001 and 9002
labels respectively). This done via including 3 instances of CCI
objects in the PCEP messages, one for each label in the example, 6000
for incoming and 9001/9002 for outgoing (along with remote nexthop).
The message and procedure remains exactly as
[I-D.ietf-pce-pcep-extension-for-pce-controller] with only
distinction that more than one outgoing CCI MAY be present for the
P2MP LSP.
4.3.3.2. Label Clean up CCI
In order to delete a P2MP LSP based on PCECC, the PCE sends a central
controller instructions via a PCInitiate message to each node along
the path of the P2MP tree to clean up the Label forwarding
instruction as per [I-D.ietf-pce-pcep-extension-for-pce-controller].
In case of branch nodes, all instances of CCIs needs to be present in
the PCEP message.
Li, et al. Expires August 25, 2021 [Page 9]
Internet-Draft PCECC February 2021
4.3.4. PCECC LSP Update
In case of a modification of PCECC P2MP LSP with a new path, the
procedure, and instructions as described in
[I-D.ietf-pce-pcep-extension-for-pce-controller] apply.
4.3.5. Re-Delegation and Clean up
In case of a re-delegation and clean up of PCECC P2MP LSP, the
procedure, and instructions as described in
[I-D.ietf-pce-pcep-extension-for-pce-controller] apply.
4.3.6. Synchronization of Central Controllers Instructions
The procedure and instructions are as per
[I-D.ietf-pce-pcep-extension-for-pce-controller].
4.3.7. PCECC LSP State Report
An ingress PCC MAY choose to apply any OAM mechanism to check the
status of LSP in the Data plane and MAY further send its status in
PCRpt message (as per [RFC8623]) to the PCE.
4.3.8. PCC-Based Allocations
The PCE can request the PCC to allocate the label using the
PCInitiate message. The procedure and instructions are as per
[I-D.ietf-pce-pcep-extension-for-pce-controller].
5. PCEP Messages
[I-D.ietf-pce-pcep-extension-for-pce-controller] specify the
extension to PCInitiate and PCRpt message for PCECC. For P2P LSP,
only two instances of CCI objects can be included. In the case of
the P2MP LSP, multiple CCI objects are allowed. The message format
and other procedures continue to apply.
6. PCEP Objects
6.1. OPEN Object
6.1.1. PCECC Capability sub-TLV
The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN
Object for PCECC capability advertisement in PATH-SETUP-TYPE-
CAPABILITY TLV as specified in
[I-D.ietf-pce-pcep-extension-for-pce-controller].
Li, et al. Expires August 25, 2021 [Page 10]
Internet-Draft PCECC February 2021
This document adds a new flag (M-bit) in the PCECC-CAPABILITY sub-TLV
to indicate the support for P2MP in PCECC.
M (PCECC-P2MP-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP
speaker, it indicates that the PCEP speaker is capable of PCECC-P2MP
capability.
A PCC MUST set the M-bit in the PCECC-CAPABILITY sub-TLV and set the
N (P2MP-CAPABILITY), the M (P2MP-LSP-UPDATE-CAPABILITY), and the P
(P2MP-LSP-INSTANTIATION-CAPABILITY) bits (as per [RFC8623]) in the
STATEFUL-PCE-CAPABILITY TLV [RFC8231] to support the PCECC-P2MP
extensions defined in this document. If the M-bit is set in PCECC-
CAPABILITY sub-TLV and the P2MP bits (in the STATEFUL-PCE-CAPABILITY
TLV) are not set in the OPEN Object, a PCEP speaker SHOULD send a
PCErr message with Error-Type=19 (Invalid Operation) and Error-
value=TBD2 (P2MP capability was not advertised) and terminate the
session.
6.2. PATH-SETUP-TYPE TLV
The PATH-SETUP-TYPE TLV is defined in [RFC8408];
[I-D.ietf-pce-pcep-extension-for-pce-controller] defines a PST value
for PCECC, which is applicable for P2MP LSP as well.
6.3. CCI Object
The Central Control Instructions (CCI) Object
[I-D.ietf-pce-pcep-extension-for-pce-controller] is used by the PCE
to specify the forwarding instructions (Label information in the
context of this document) to the PCC, and optionally carried within
PCInitiate or PCRpt message for label download/report. The CCI
Object Type 1 for MPLS Label is defined in
[I-D.ietf-pce-pcep-extension-for-pce-controller], which is used for
the P2MP LSPs as well. The address TLVs are defined in
[I-D.ietf-pce-pcep-extension-for-pce-controller], they associate the
next-hop information in case of an outgoing label.
If a node (PCC) receives a PCInitiate message with more than one CCI
with O-bit set for the outgoing label and the node does not support
the P2MP branch/replication capability, it MUST respond with PCErr
message with Error-Type=2 (Capability not supported) (defined in
[RFC5440]).
The rest of the processing is same as
[I-D.ietf-pce-pcep-extension-for-pce-controller].
Li, et al. Expires August 25, 2021 [Page 11]
Internet-Draft PCECC February 2021
7. Security Considerations
As per [RFC8283], the security considerations for a PCE-based
controller is a little different from those for any other PCE system.
That is, the operation relies heavily on the use and security of
PCEP, so consideration should be given to the security features
discussed in [RFC5440] and the additional mechanisms described in
[RFC8253]. It further lists the vulnerability of a central
controller architecture, such as a central point of failure, denial-
of-service, and a focus for interception and modification of messages
sent to individual NEs.
The security considerations described in [RFC8231], [RFC8281],
[RFC8623], and [I-D.ietf-pce-pcep-extension-for-pce-controller] 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]).
8. Manageability Considerations
8.1. Control of Function and Policy
A PCE or PCC implementation SHOULD allow to configure to enable/
disable PCECC-P2MP capability as a global configuration.
8.2. Information and Data Models
[RFC7420] describes the PCEP MIB, this MIB can be extended to get the
PCECC capability status.
The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to
enable/disable PCECC-P2MP capability.
8.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440].
Li, et al. Expires August 25, 2021 [Page 12]
Internet-Draft PCECC February 2021
8.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[RFC5440] and [RFC8231].
8.5. Requirements On Other Protocols
PCEP extensions defined in this document do not put new requirements
on other protocols.
8.6. Impact On Network Operations
PCEP extensions defined in this document do not put new requirements
on network operations.
9. IANA Considerations
9.1. PCECC-CAPABILITY sub-TLV
[I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC-
CAPABILITY sub-TLV and requests that IANA creates a registry to
manage the value of the PCECC-CAPABILITY sub-TLV's Flag field. IANA
is requested to allocate a new bit in the PCECC-CAPABILITY sub-TLV
Flag Field registry, as follows:
Bit Description Reference
TBD1 P2MP This document
9.2. PCEP-Error Object
IANA is requested to allocate a new error value within the "PCEP-
ERROR Object Error Types and Values" sub-registry of the PCEP Numbers
registry for the following errors:
Error-Type Meaning
---------- -------
19 Invalid operation.
Error-value = TBD2 : P2MP capability was
not advertised
The Reference is marked as "This document".
Li, et al. Expires August 25, 2021 [Page 13]
Internet-Draft PCECC February 2021
10. Acknowledgments
11. References
11.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>.
[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>.
[RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful
Path Computation Element (PCE) Protocol Extensions for
Usage with Point-to-Multipoint TE Label Switched Paths
(LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,
<https://www.rfc-editor.org/info/rfc8623>.
Li, et al. Expires August 25, 2021 [Page 14]
Internet-Draft PCECC February 2021
[I-D.ietf-pce-pcep-extension-for-pce-controller]
Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP
Procedures and Protocol Extensions for Using PCE as a
Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-10 (work in progress),
January 2021.
11.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4857] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4
Regional Registration", RFC 4857, DOI 10.17487/RFC4857,
June 2007, <https://www.rfc-editor.org/info/rfc4857>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
DOI 10.17487/RFC5671, October 2009,
<https://www.rfc-editor.org/info/rfc5671>.
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
Margaria, "Requirements for GMPLS Applications of PCE",
RFC 7025, DOI 10.17487/RFC7025, September 2013,
<https://www.rfc-editor.org/info/rfc7025>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014,
<https://www.rfc-editor.org/info/rfc7399>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>.
Li, et al. Expires August 25, 2021 [Page 15]
Internet-Draft PCECC February 2021
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[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>.
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) for Point-to-Multipoint Traffic
Engineering Label Switched Paths", RFC 8306,
DOI 10.17487/RFC8306, November 2017,
<https://www.rfc-editor.org/info/rfc8306>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[I-D.ietf-teas-pcecc-use-cases]
Li, Z., Khasanov, B., Dhody, D., Zhao, Q., Ke, Z., Fang,
L., Zhou, C., Communications, T., Rachitskiy, A., and A.
Gulida, "The Use Cases for Path Computation Element (PCE)
as a Central Controller (PCECC).", draft-ietf-teas-pcecc-
use-cases-06 (work in progress), September 2020.
[I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-15 (work in progress), October 2020.
[I-D.li-pce-controlled-id-space]
Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE
Controlled ID Space", draft-li-pce-controlled-id-space-07
(work in progress), October 2020.
Li, et al. Expires August 25, 2021 [Page 16]
Internet-Draft PCECC February 2021
Appendix A. Contributor Addresses
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: dhruv.ietf@gmail.com
Udayasree Palle
EMail: udayasreereddy@gmail.com
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
EMail: lizhenbin@huawei.com
Shuping Peng
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
EMail: pengshuping@huawei.com
Xuesong Geng
Huawei Technologies
China
EMail: gengxuesong@huawei.com
Li, et al. Expires August 25, 2021 [Page 17]
Internet-Draft PCECC February 2021
Mahendra Singh Negi
RtBrick Inc
N-17L, 18th Cross Rd, HSR Layout
Bangalore, Karnataka 560102
India
EMail: mahend.ietf@gmail.com
Li, et al. Expires August 25, 2021 [Page 18]