< draft-zhao-pce-pcep-extension-pce-controller-sr-04.txt   draft-zhao-pce-pcep-extension-pce-controller-sr-05.txt >
PCE Working Group Q. Zhao PCE Working Group Q. Zhao
Internet-Draft Z. Li Internet-Draft Z. Li
Intended status: Standards Track M. Negi Intended status: Standards Track M. Negi
Expires: August 9, 2019 Huawei Technologies Expires: January 9, 2020 Huawei Technologies
C. Zhou C. Zhou
Cisco Systems Cisco Systems
February 5, 2019 July 8, 2019
PCEP Procedures and Protocol Extensions for Using PCE as a Central PCEP Procedures and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of SR-LSPs Controller (PCECC) of SR-LSPs
draft-zhao-pce-pcep-extension-pce-controller-sr-04 draft-zhao-pce-pcep-extension-pce-controller-sr-05
Abstract Abstract
The Path Computation Element (PCE) is a core component of Software- The Path Computation Element (PCE) is a core component of Software-
Defined Networking (SDN) systems. It can compute optimal paths for Defined Networking (SDN) systems. It can compute optimal paths for
traffic across a network and can also update the paths to reflect traffic across a network and can also update the paths to reflect
changes in the network or traffic demands. changes in the network or traffic demands.
PCE was developed to derive paths for MPLS Label Switched Paths PCE was developed to derive paths for MPLS Label Switched Paths
(LSPs), which are supplied to the head end of the LSP using the Path (LSPs), which are supplied to the head end of the LSP using the Path
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 9, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 14 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Central Control Instructions . . . . . . . . . . . . . . 14 6.1. Central Control Instructions . . . . . . . . . . . . . . 14
6.1.1. The PCInitiate message . . . . . . . . . . . . . . . 14 6.1.1. The PCInitiate message . . . . . . . . . . . . . . . 14
6.1.2. The PCRpt message . . . . . . . . . . . . . . . . . . 15 6.1.2. The PCRpt message . . . . . . . . . . . . . . . . . . 15
7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 16 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 16
7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 16 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 16
7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 17 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 17
7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 17
7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 19 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
9. Manageability Considerations . . . . . . . . . . . . . . . . 21 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 21
9.1. Control of Function and Policy . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.2. Information and Data Models . . . . . . . . . . . . . . . 21 10. Manageability Considerations . . . . . . . . . . . . . . . . 22
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 10.1. Control of Function and Policy . . . . . . . . . . . . . 22
9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 21 10.2. Information and Data Models . . . . . . . . . . . . . . 22
9.5. Requirements On Other Protocols . . . . . . . . . . . . . 21 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 22
9.6. Impact On Network Operations . . . . . . . . . . . . . . 21 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10.5. Requirements On Other Protocols . . . . . . . . . . . . 23
10.1. PCECC-CAPABILITY TLV . . . . . . . . . . . . . . . . . . 21 10.6. Impact On Network Operations . . . . . . . . . . . . . . 23
10.2. New Path Setup Type Registry . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 22 11.1. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . . . 23
10.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 22 11.2. New Path Setup Type Registry . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 11.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The Path Computation Element (PCE) [RFC4655] was developed to offload The Path Computation Element (PCE) [RFC4655] was developed to offload
path computation function from routers in an MPLS traffic-engineered path computation function from routers in an MPLS traffic-engineered
network. Since then, the role and function of the PCE has grown to 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 cover a number of other uses (such as GMPLS [RFC7025]) and to allow
delegated control [RFC8231] and PCE-initiated use of network delegated control [RFC8231] and PCE-initiated use of network
resources [RFC8281]. resources [RFC8281].
skipping to change at page 6, line 28 skipping to change at page 6, line 31
o PCEP speaker not supporting this draft MUST be able to reject o PCEP speaker not supporting this draft MUST be able to reject
PCECC-SR related message with a reason code that indicates no PCECC-SR related message with a reason code that indicates no
support for PCECC. support for PCECC.
o PCEP procedures MUST provide a means to update (or cleanup) the o PCEP procedures MUST provide a means to update (or cleanup) the
label- map entry to the PCC. label- map entry to the PCC.
o PCEP procedures SHOULD provide a means to synchronize the SR o PCEP procedures SHOULD provide a means to synchronize the SR
labels allocations between PCE to PCC in the PCEP messages. labels allocations between PCE to PCC in the PCEP messages.
o PCEP procedures MAY allow for PCC based label allocations.
5. Procedures for Using the PCE as the Central Controller (PCECC) in 5. Procedures for Using the PCE as the Central Controller (PCECC) in
Segment Routing Segment Routing
5.1. Stateful PCE Model 5.1. Stateful PCE Model
Active stateful PCE is described in [RFC8231]. PCE as a central Active stateful PCE is described in [RFC8231]. PCE as a central
controller (PCECC) reuses existing Active stateful PCE mechanism as controller (PCECC) reuses existing Active stateful PCE mechanism as
much as possible to control the LSP. much as possible to control the LSP.
5.2. New LSP Functions 5.2. New LSP Functions
skipping to change at page 9, line 18 skipping to change at page 9, line 18
+------| | | +------| | |
| PCC +---------+ | | PCC +---------+ |
| 192.0.2.2| | | | 192.0.2.2| | |
+------| | | | +------| | | |
|PCC +----------+ | | |PCC +----------+ | |
|192.0.2.1| | | | |192.0.2.1| | | |
+---------+ | | | +---------+ | | |
| | | | | | | |
|<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map |<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map
| | | CC-ID=X | update | | | CC-ID=X | update
|------- PCRpt,CC-ID=X --------------------------->| |------- PCRpt,CC-ID=X --------------------------->| CCI
|Find | | | |Find | | |
|Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map |Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map
|locally| | CC-ID=Y | update |locally| | CC-ID=Y | update
| |----- PCRpt,CC-ID=Y -------------------->| | |----- PCRpt,CC-ID=Y -------------------->| CCI
| | | | | | | |
| | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map | | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map
| | | CC-ID=Z | update | | | CC-ID=Z | update
| | |---- PCRpt,CC-ID=Z -------------->| | | |---- PCRpt,CC-ID=Z -------------->| CCI
| | | | | | | |
The forwarding behavior and the end result is similar to IGP based The forwarding behavior and the end result is similar to IGP based
"Node-SID" in SR. Thus, from anywhere in the domain, it enforces the "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the
ECMP-aware shortest-path forwarding of the packet towards the related ECMP-aware shortest-path forwarding of the packet towards the related
node. node.
PCE relies on the Node/Prefix Label cleanup using the same PCInitiate PCE relies on the Node/Prefix Label cleanup using the same PCInitiate
message. message.
skipping to change at page 10, line 17 skipping to change at page 10, line 17
+------| | | +------| | |
| PCC +---------+ | | PCC +---------+ |
| 192.0.2.2| | | | 192.0.2.2| | |
+------| | | | +------| | | |
|PCC +----------+ | | |PCC +----------+ | |
|192.0.2.1| | | | |192.0.2.1| | | |
+---------+ | | | +---------+ | | |
| | | | | | | |
|<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map |<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map
| | | CC-ID=X,C=1 | request | | | CC-ID=X,C=1 | request
|------- PCRpt,CC-ID=X,Label ---------------------->| |------- PCRpt,CC-ID=X,Label ---------------------->| CCI
|Find | | | |Find | | |
|Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map |Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map
|locally| | CC-ID=Y,C=0,Label | update |locally| | CC-ID=Y,C=0,Label | update
| |----- PCRpt,CC-ID=Y -------------------->| | |----- PCRpt,CC-ID=Y -------------------->| CCI
| | | | | | | |
| | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map | | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map
| | | CC-ID=Z,C=0,Label | update | | | CC-ID=Z,C=0,Label | update
| | |---- PCRpt,CC-ID=Z -------------->| | | |---- PCRpt,CC-ID=Z -------------->| CCI
| | | | | | | |
It should be noted that in this example, the request is made to the It should be noted that in this example, the request is made to the
node 192.0.2.1 with C bit set in the CCI object to indicate that the node 192.0.2.1 with C bit set in the CCI object to indicate that the
allocation needs to be done by this PCC and it responds with the allocation needs to be done by this PCC and it responds with the
allocated label/SID to the PCE. The PCE would further inform the allocated label/SID to the PCE. The PCE would further inform the
other PCCs in the network about the allocation without setting the C other PCCs in the network about the allocation without setting the C
bit. bit.
5.5.1.2. PCECC SR Adjacency Label allocation 5.5.1.2. PCECC SR Adjacency Label allocation
skipping to change at page 11, line 18 skipping to change at page 11, line 18
+------| | | +------| | |
| PCC +---------+ | | PCC +---------+ |
| 192.0.2.2| | | | 192.0.2.2| | |
+------| | | | +------| | | |
|PCC +----------+ | | |PCC +----------+ | |
|192.0.2.1| | | | |192.0.2.1| | | |
+---------+ | | | +---------+ | | |
| | | | | | | |
|<------ PCInitiate, FEC=198.51.100.1 / --------- | Label Map |<------ PCInitiate, FEC=198.51.100.1 / --------- | Label Map
| | | 198.51.100.2 | update | | | 198.51.100.2 | update
| | | CC-ID=A | | | | CC-ID=A | CCI
|------- PCRpt,CC-ID=A ------------------------->| |------- PCRpt,CC-ID=A ------------------------->|
| | | | | | | |
| |<----- PCInitiate, FEC=198.51.100.2---- | Label Map | |<----- PCInitiate, FEC=198.51.100.2---- | Label Map
| | | 198.51.100.1 | update | | | 198.51.100.1 | update
| | | CC-ID=B | | | | CC-ID=B | CCI
| |----- PCRpt,CC-ID=B ----------------->| | |----- PCRpt,CC-ID=B ----------------->|
| | | | | | | |
The forwarding behavior and the end result is similar to IGP based The forwarding behavior and the end result is similar to IGP based
"Adj-SID" in SR. "Adj-SID" in SR.
The Path Setup Type for segment routing MUST be set for PCECC SR = The Path Setup Type for segment routing MUST be set for PCECC SR =
TBD (see Section 7.2). All PCEP procedures and mechanism are similar TBD (see Section 7.2). All PCEP procedures and mechanism are similar
to [I-D.ietf-pce-segment-routing]. to [I-D.ietf-pce-segment-routing].
skipping to change at page 12, line 17 skipping to change at page 12, line 17
+------| | | +------| | |
| PCC +---------+ | | PCC +---------+ |
| 192.0.2.2| | | | 192.0.2.2| | |
+------| | | | +------| | | |
|PCC +----------+ | | |PCC +----------+ | |
|192.0.2.1| | | | |192.0.2.1| | | |
+---------+ | | | +---------+ | | |
| | | | | | | |
|<------ PCInitiate, FEC=198.51.100.1------------ | Label Map |<------ PCInitiate, FEC=198.51.100.1------------ | Label Map
| | | 198.51.100.2 | request | | | 198.51.100.2 | request
| | | CC-ID=A,C=1 | | | | CC-ID=A,C=1 | CCI
|------- PCRpt,CC-ID=A,Label -------------------->| |------- PCRpt,CC-ID=A,Label -------------------->|
| | | | | | | |
| |<----- PCInitiate, FEC=198.51.100.2---- | Label Map | |<----- PCInitiate, FEC=198.51.100.2---- | Label Map
| | | 198.51.100.1 | request | | | 198.51.100.1 | request
| | | CC-ID=B,C=1 | | | | CC-ID=B,C=1 | CCI
| |----- PCRpt,CC-ID=B,Label------------->| | |----- PCRpt,CC-ID=B,Label------------->|
| | | | | | | |
In this example the request is made to the node 192.0.2.1 with C bit In this example the request is made to the node 192.0.2.1 with C bit
set in the CCI object to indicate that the allocation needs to be set in the CCI object to indicate that the allocation needs to be
done by this PCC for the adjacency (198.51.100.1 - 198.51.100.2) and done by this PCC for the adjacency (198.51.100.1 - 198.51.100.2) and
it responds with the allocated label/SID to the PCE. Similarly, it responds with the allocated label/SID to the PCE. Similarly,
another request is made to the node 192.0.2.2 with C bit set in the another request is made to the node 192.0.2.2 with C bit set in the
CCI object to indicate that the allocation needs to be done by this CCI object to indicate that the allocation needs to be done by this
PCC for the adjacency (198.51.100.2 - 198.51.100.1). PCC for the adjacency (198.51.100.2 - 198.51.100.1).
skipping to change at page 20, line 21 skipping to change at page 20, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Node-ID | | Local Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID | | Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Node-ID | | Remote Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID | | Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Object-Type is 6 'Linklocal IPv6 Adjacency'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FEC objects are as follows: The FEC objects are as follows:
IPv4 Node ID: where IPv4 Node ID is specified as an IPv4 address of IPv4 Node ID: where IPv4 Node ID is specified as an IPv4 address of
the Node. FEC Object-type is 1, and the Object-Length is 4 in this the Node. FEC Object-type is 1, and the Object-Length is 4 in this
case. case.
IPv6 Node ID: where IPv6 Node ID is specified as an IPv6 address of IPv6 Node ID: where IPv6 Node ID is specified as an IPv6 address of
the Node. FEC Object-type is 2, and the Object-Length is 16 in this the Node. FEC Object-type is 2, and the Object-Length is 16 in this
case. case.
skipping to change at page 20, line 43 skipping to change at page 21, line 13
Object-Length is 8 in this case. Object-Length is 8 in this case.
IPv6 Adjacency: where Local and Remote IPv6 address is specified as IPv6 Adjacency: where Local and Remote IPv6 address is specified as
pair of IPv6 address of the adjacency. FEC Object-type is 4, and the pair of IPv6 address of the adjacency. FEC Object-type is 4, and the
Object-Length is 32 in this case. Object-Length is 32 in this case.
Unnumbered Adjacency with IPv4 NodeID: where a pair of Node ID / Unnumbered Adjacency with IPv4 NodeID: where a pair of Node ID /
Interface ID tuples is used. FEC Object-type is 5, and the Object- Interface ID tuples is used. FEC Object-type is 5, and the Object-
Length is 16 in this case. Length is 16 in this case.
Binding ID: TBD Linklocal IPv6 Adjacency: where a pair of (global IPv6 address,
interface ID) tuples is used. FEC object-type is 6, and the Object-
Length is 40 in this case.
8. Security Considerations 8. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
8.1. Huawei's Proof of Concept based on ONOS
The PCE function was developed in the ONOS open source platform.
This extension was implemented on a private version as a proof of
concept for PCECC.
o Organization: Huawei
o Implementation: Huawei's PoC based on ONOS
o Description: PCEP as a southbound plugin was added to ONOS. To
support PCECC-SR, an earlier version of this I-D was implemented.
Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol
o Maturity Level: Prototype
o Coverage: Partial
o Contact: satishk@huawei.com
9. Security Considerations
The security considerations described in The security considerations described in
[I-D.ietf-pce-pcep-extension-for-pce-controller] apply to the [I-D.ietf-pce-pcep-extension-for-pce-controller] apply to the
extensions described in this document. extensions described in this document.
9. Manageability Considerations 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.1. Control of Function and Policy 10. Manageability Considerations
10.1. Control of Function and Policy
A PCE or PCC implementation SHOULD allow to configure to enable/ A PCE or PCC implementation SHOULD allow to configure to enable/
disable PCECC SR capability as a global configuration. disable PCECC SR capability as a global configuration.
9.2. Information and Data Models 10.2. Information and Data Models
[RFC7420] describes the PCEP MIB, this MIB can be extended to get the [RFC7420] describes the PCEP MIB, this MIB can be extended to get the
PCECC SR capability status. PCECC SR capability status.
The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to
enable/disable PCECC SR capability. enable/disable PCECC SR capability.
9.3. Liveness Detection and Monitoring 10.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in [RFC5440]. listed in [RFC5440].
9.4. Verify Correct Operations 10.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in verification requirements in addition to those already listed in
[RFC5440] and [RFC8231]. [RFC5440] and [RFC8231].
9.5. Requirements On Other Protocols 10.5. Requirements On Other Protocols
PCEP extensions defined in this document do not put new requirements PCEP extensions defined in this document do not put new requirements
on other protocols. on other protocols.
9.6. Impact On Network Operations 10.6. Impact On Network Operations
PCEP implementation SHOULD allow a limit to be placed on the rate of PCEP implementation SHOULD allow a limit to be placed on the rate of
PCLabelUpd messages sent by PCE and processed by PCC. It SHOULD also PCLabelUpd messages sent by PCE and processed by PCC. It SHOULD also
allow sending a notification when a rate threshold is reached. allow sending a notification when a rate threshold is reached.
10. IANA Considerations 11. IANA Considerations
10.1. PCECC-CAPABILITY TLV 11.1. PCECC-CAPABILITY sub-TLV
[I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC-
CAPABILITY TLV and requests that IANA creates a registry to manage CAPABILITY sub-TLV and requests that IANA creates a registry to
the value of the PCECC-CAPABILITY TLV's Flag field. IANA is manage the value of the PCECC-CAPABILITY sub-TLV's Flag field. New
requested to allocate a new bit in the PCECC-CAPABILITY TLV Flag values are to be assigned by Standards Action [RFC8126]. Each bit
Field registry, as follows: should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Capability description
o Defining RFC
IANA is requested to allocate a new bit in the PCECC-CAPABILITY sub-
TLV Flag Field registry, as follows:
Bit Description Reference Bit Description Reference
31 S((PCECC-SR-CAPABILITY)) This document 31 S((PCECC-SR-CAPABILITY)) This document
10.2. New Path Setup Type Registry 11.2. New Path Setup Type Registry
IANA is requested to allocate new PST Field in PATH- SETUP-TYPE TLV. [RFC8408] created a sub-registry within the "Path Computation Element
The allocation policy for this new registry should be by IETF Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types".
Consensus. The new registry should contain the following value: IANA is requested to allocate a new code point within this registry,
as follows:
Value Description Reference Value Description Reference
TBD Traffic engineering path is This document TBD Traffic engineering path is This document
setup using PCECC-SR mode setup using PCECC-SR mode
10.3. PCEP Object 11.3. PCEP Object
IANA is requested to allocate new registry for FEC PCEP object. IANA is requested to allocate new code-point for the new FEC object
in "PCEP Objects" sub-registry as follows:
Object-Class Value Name Reference Object-Class Value Name Reference
TBD FEC This document TBD FEC This document
Object-Type : 1 IPv4 Node ID Object-Type : 1 IPv4 Node ID
Object-Type : 2 IPv6 Node ID Object-Type : 2 IPv6 Node ID
Object-Type : 3 IPv4 Adjacency Object-Type : 3 IPv4 Adjacency
Object-Type : 4 IPv6 Adjacency Object-Type : 4 IPv6 Adjacency
Object-Type : 5 Unnumbered Adjacency Object-Type : 5 Unnumbered Adjacency
with IPv4 NodeID with IPv4 NodeID
Object-Type : 6 Linklocal IPv6 Adjacency
10.4. PCEP-Error Object 11.4. PCEP-Error Object
IANA is requested to allocate new error types and error values within IANA is requested to allocate new error types and error values within
the "PCEP-ERROR Object Error Types and Values" sub-registry of the the "PCEP-ERROR Object Error Types and Values" sub-registry of the
PCEP Numbers registry for the following errors: PCEP Numbers registry for the following errors:
Error-Type Meaning Error-Type Meaning
---------- ------- ---------- -------
6 Mandatory Object missing. 6 Mandatory Object missing.
Error-value = TBD : FEC object missing Error-value = TBD : FEC object missing
19 Invalid operation. 19 Invalid operation.
Error-value = TBD : SR capability was Error-value = TBD : SR capability was
not advertised not advertised
11. Acknowledgments 12. Acknowledgments
We would like to thank Robert Tao, Changjing Yan, Tieying Huang and We would like to thank Robert Tao, Changjing Yan, Tieying Huang and
Avantika for their useful comments and suggestions. Avantika for their useful comments and suggestions.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
skipping to change at page 24, line 5 skipping to change at page 25, line 45
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014, RFC 7420, DOI 10.17487/RFC7420, December 2014,
<https://www.rfc-editor.org/info/rfc7420>. <https://www.rfc-editor.org/info/rfc7420>.
[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>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/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, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>. July 2018, <https://www.rfc-editor.org/info/rfc8408>.
12.2. Informative References 13.2. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
skipping to change at page 25, line 32 skipping to change at page 27, line 52
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[I-D.ietf-teas-pcecc-use-cases] [I-D.ietf-teas-pcecc-use-cases]
Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang,
L., Zhou, C., Communications, T., Rachitskiy, A., and A. L., Zhou, C., Communications, T., Rachitskiy, A., and A.
Gulida, "The Use Cases for Path Computation Element (PCE) Gulida, "The Use Cases for Path Computation Element (PCE)
as a Central Controller (PCECC).", draft-ietf-teas-pcecc- as a Central Controller (PCECC).", draft-ietf-teas-pcecc-
use-cases-02 (work in progress), October 2018. use-cases-04 (work in progress), July 2019.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", draft-ietf-pce-pcep- Communications Protocol (PCEP)", draft-ietf-pce-pcep-
yang-09 (work in progress), October 2018. yang-12 (work in progress), July 2019.
[I-D.ietf-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures
and C. Zhou, "PCEP Procedures and Protocol Extensions for and Protocol Extensions for Using PCE as a Central
Using PCE as a Central Controller (PCECC) of LSPs", draft- Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
ietf-pce-pcep-extension-for-pce-controller-00 (work in extension-for-pce-controller-02 (work in progress), July
progress), November 2018. 2019.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-14 (work in progress), draft-ietf-pce-segment-routing-16 (work in progress),
October 2018. March 2019.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for Gredler, H., and B. Decraene, "IS-IS Extensions for
Segment Routing", draft-ietf-isis-segment-routing- Segment Routing", draft-ietf-isis-segment-routing-
extensions-22 (work in progress), December 2018. extensions-25 (work in progress), May 2019.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-27 (work in progress), December 2018. routing-extensions-27 (work in progress), December 2018.
[I-D.litkowski-pce-state-sync] [I-D.litkowski-pce-state-sync]
Litkowski, S., Sivabalan, S., and D. Dhody, "Inter Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter
Stateful Path Computation Element communication Stateful Path Computation Element (PCE) Communication
procedures", draft-litkowski-pce-state-sync-04 (work in Procedures.", draft-litkowski-pce-state-sync-06 (work in
progress), October 2018. progress), July 2019.
[I-D.dhodylee-pce-pcep-ls] [I-D.dhodylee-pce-pcep-ls]
Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for
Distribution of Link-State and TE Information.", draft- Distribution of Link-State and TE Information.", draft-
dhodylee-pce-pcep-ls-12 (work in progress), December 2018. dhodylee-pce-pcep-ls-13 (work in progress), February 2019.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-18 data plane", draft-ietf-spring-segment-routing-mpls-22
(work in progress), December 2018. (work in progress), May 2019.
[I-D.sivabalan-pce-binding-label-sid] [I-D.sivabalan-pce-binding-label-sid]
Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J.,
Previdi, S., and D. Dhody, "Carrying Binding Label/ Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID
Segment-ID in PCE-based Networks.", draft-sivabalan-pce- in PCE-based Networks.", draft-sivabalan-pce-binding-
binding-label-sid-05 (work in progress), October 2018. label-sid-07 (work in progress), July 2019.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
skipping to change at page 27, line 36 skipping to change at page 30, line 36
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Xuesong Geng Xuesong Geng
Huawei Technologies Huawei Technologies
China China
Email: gengxuesong@huawei.com Email: gengxuesong@huawei.com
Udayasree Palle Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: udayasreereddy@gmail.com EMail: udayasreereddy@gmail.com
Katherine Zhao Katherine Zhao
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
EMail: katherine.zhao@huawei.com EMail: katherine.zhao@huawei.com
skipping to change at page 28, line 24 skipping to change at page 31, line 18
EMail: atokar@cisco.com EMail: atokar@cisco.com
Authors' Addresses Authors' Addresses
Quintin Zhao Quintin Zhao
Huawei Technologies Huawei Technologies
125 Nagog Technology Park 125 Nagog Technology Park
Acton, MA 01719 Acton, MA 01719
USA USA
EMail: quintin.zhao@huawei.com EMail: quintinzhao@gmail.com
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
EMail: lizhenbin@huawei.com EMail: lizhenbin@huawei.com
Mahendra Singh Negi Mahendra Singh Negi
 End of changes. 53 change blocks. 
92 lines changed or deleted 193 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/