< draft-ietf-pce-pcep-extension-for-pce-controller-01.txt   draft-ietf-pce-pcep-extension-for-pce-controller-02.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 LSPs Controller (PCECC) of LSPs
draft-ietf-pce-pcep-extension-for-pce-controller-01 draft-ietf-pce-pcep-extension-for-pce-controller-02
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 12 skipping to change at page 2, line 12
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 2, line 44 skipping to change at page 2, line 44
3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5
4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5
5. Procedures for Using the PCE as the Central Controller 5. Procedures for Using the PCE as the Central Controller
(PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 (PCECC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6
5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6
5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7
5.4. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 5.4. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Basic PCECC LSP Setup . . . . . . . . . . . . . . . . 8 5.4.1. Basic PCECC LSP Setup . . . . . . . . . . . . . . . . 8
5.4.2. Central Control Instructions . . . . . . . . . . . . 12 5.4.2. Central Control Instructions . . . . . . . . . . . . 12
5.4.2.1. Label Download . . . . . . . . . . . . . . . . . 12 5.4.2.1. Label Download CCI . . . . . . . . . . . . . . . 12
5.4.2.2. Label Cleanup . . . . . . . . . . . . . . . . . . 12 5.4.2.2. Label Cleanup CCI . . . . . . . . . . . . . . . . 12
5.4.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 13 5.4.3. PCE Initiated PCECC LSP . . . . . . . . . . . . . . . 13
5.4.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 15 5.4.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 15
5.4.5. Re Delegation and Cleanup . . . . . . . . . . . . . . 17 5.4.5. Re Delegation and Cleanup . . . . . . . . . . . . . . 17
5.4.6. Synchronization of Central Controllers Instructions . 17 5.4.6. Synchronization of Central Controllers Instructions . 17
5.4.7. PCECC LSP State Report . . . . . . . . . . . . . . . 17 5.4.7. PCECC LSP State Report . . . . . . . . . . . . . . . 17
5.4.8. PCC Based Allocations . . . . . . . . . . . . . . . . 18 5.4.8. PCC Based Allocations . . . . . . . . . . . . . . . . 18
5.4.9. Binding Label . . . . . . . . . . . . . . . . . . . . 18 5.4.9. Binding Label . . . . . . . . . . . . . . . . . . . . 18
6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 19 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. The PCInitiate message . . . . . . . . . . . . . . . . . 19 6.1. The PCInitiate message . . . . . . . . . . . . . . . . . 19
6.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 21 6.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 21
7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 21 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 22
7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 22 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 22
7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 22 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 22
7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 23 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 23
7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 24 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
8.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 26
9. Manageability Considerations . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9.1. Control of Function and Policy . . . . . . . . . . . . . 26 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Information and Data Models . . . . . . . . . . . . . . . 26 10. Manageability Considerations . . . . . . . . . . . . . . . . 27
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 26 10.1. Control of Function and Policy . . . . . . . . . . . . . 27
9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 26 10.2. Information and Data Models . . . . . . . . . . . . . . 27
9.5. Requirements On Other Protocols . . . . . . . . . . . . . 26 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 27
9.6. Impact On Network Operations . . . . . . . . . . . . . . 27 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10.5. Requirements On Other Protocols . . . . . . . . . . . . 27
10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27 10.6. Impact On Network Operations . . . . . . . . . . . . . . 27
10.2. New Path Setup Type Registry . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 27 11.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 27
10.4. CCI Object Flag Field . . . . . . . . . . . . . . . . . 27 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 28
10.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 28 11.3. New Path Setup Type Registry . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11.4. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.5. CCI Object Flag Field . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 11.6. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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 5, line 16 skipping to change at page 5, line 16
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Terminology 2. Terminology
Terminologies used in this document is same as described in the draft Terminologies used in this document is same as described in the draft
[RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. [RFC8283].
3. Basic PCECC Mode 3. Basic PCECC Mode
In this mode LSPs are provisioned as explicit label instructions at 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 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 told what label forwarding instructions to program and what resources
to reserve. The controller uses PCEP to communicate with each router to reserve. The controller uses PCEP to communicate with each router
along the path of the end-to-end LSP. along the path of the end-to-end LSP.
Note that the PCE-based controller will take responsibility for Note that the PCE-based controller will take responsibility for
skipping to change at page 6, line 18 skipping to change at page 6, line 18
3. PCEP speaker MUST provide a means to identify PCECC based LSP in 3. PCEP speaker MUST provide a means to identify PCECC based LSP in
the PCEP messages. the PCEP messages.
4. PCEP procedures SHOULD provide a means to update (or cleanup) the 4. PCEP procedures SHOULD provide a means to update (or cleanup) the
label- download entry to the PCC. label- download entry to the PCC.
5. PCEP procedures SHOULD provide a means to synchronize the labels 5. PCEP procedures SHOULD provide a means to synchronize the labels
between PCE to PCC in PCEP messages. between PCE to PCC in PCEP messages.
6. PCEP procedures MAY allow for PCC based label allocations.
5. Procedures for Using the PCE as the Central Controller (PCECC) 5. Procedures for Using the PCE as the Central Controller (PCECC)
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
This document defines the following new PCEP messages and extends the This document defines the following new PCEP messages and extends the
existing messages to support PCECC: existing messages to support PCECC:
(PCRpt): a PCEP message described in [RFC8231]. PCRpt message is
used to send PCECC LSP Reports. It is also extended to report the
set of Central Controller's Instructions (CCI) (label forwarding
instructions in the context of this document) received from the
PCE. See Section 5.4.6 for more details.
(PCInitiate): a PCEP message described in [RFC8281]. PCInitiate (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate
message is used to setup PCE-Initiated LSP based on PCECC message is used to setup PCE-Initiated LSP based on PCECC
mechanism. It is also extended for Central Controller's mechanism. It is also extended for Central Controller's
Instructions (CCI) (download or cleanup the Label forwarding Instructions (CCI) (download or cleanup the Label forwarding
instructions in the context of this document) on all nodes along instructions in the context of this document) on all nodes along
the path. the path.
(PCRpt): a PCEP message described in [RFC8231]. PCRpt message is
used to send PCECC LSP Reports. It is also extended to report the
set of Central Controller's Instructions (CCI) (label forwarding
instructions in the context of this document) received from the
PCE. See Section 5.4.6 for more details.
(PCUpd): a PCEP message described in [RFC8231]. PCUpd message is (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is
used to send PCECC LSP Update. used to send PCECC LSP Update.
The new LSP functions defined in this document are mapped onto the The new LSP functions defined in this document are mapped onto the
messages as shown in the following table. messages as shown in the following table.
+----------------------------------------+--------------------------+ +----------------------------------------+--------------------------+
| Function | Message | | Function | Message |
+----------------------------------------+--------------------------+ +----------------------------------------+--------------------------+
| PCECC Capability advertisement | Open | | PCECC Capability advertisement | Open |
| Label entry Add | PCInitiate | | Label entry Add | PCInitiate |
| Label entry Cleanup | PCInitiate | | Label entry Cleanup | PCInitiate |
| PCECC Initiated LSP | PCInitiate | | PCECC Initiated LSP | PCInitiate |
| PCECC LSP Update | PCUpd | | PCECC LSP Update | PCUpd |
| PCECC LSP State Report | PCRpt | | PCECC LSP State Report | PCRpt |
| PCECC LSP Delegation | PCRpt | | PCECC LSP Delegation | PCRpt |
| PCECC Label Report | PCRpt | | PCECC Label Report | PCRpt |
+----------------------------------------+--------------------------+ +----------------------------------------+--------------------------+
This document specify a new object CCI (see Section 7.3) for the This document specify a new PCEP object called CCI (see Section 7.3)
encoding of central controller's instructions. In the scope of this for the encoding of central controller's instructions. In the scope
document this is limited to Label forwarding instructions. The CC-ID of this document this is limited to Label forwarding instructions.
is the unique identifier for the central controller's instructions in Future documents can create new CCI object-type for other types of
PCEP. The PCEP messages are extended in this document to handle the central control instructions. The CC-ID is the unique identifier for
PCECC operations. the central controller's instructions in PCEP. The PCEP messages are
extended in this document to handle the PCECC operations.
5.3. PCECC Capability Advertisement 5.3. PCECC Capability Advertisement
During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
advertise their support of PCECC extensions. advertise their support of PCECC extensions.
This document defines a new Path Setup Type (PST) [RFC8408] for This document defines a new Path Setup Type (PST) [RFC8408] for
PCECC, as follows: PCECC, as follows:
o PST = TBD: Path is setup via PCECC mode. o PST = TBD: Path is setup via PCECC mode.
A PCEP speaker MUST indicate its support of the function described in A PCEP speaker MUST indicate its support of the function described in
this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN
object with this new PST included in the PST list. object with this new PST included in the PST list.
This document also defines the PCECC Capability sub-TLV This document also defines the PCECC Capability sub-TLV
Section 7.1.1. PCEP speakers use this sub-TLV to exchange Section 7.1.1. PCEP speakers use this sub-TLV to exchange
information about their PCECC capability. If a PCEP speaker includes information about their PCECC capability. If a PCEP speaker includes
PST=TBD in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it PST=TBD in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it
MUST also include the PCECC Capability sub-TLV inside the PATH-SETUP- MUST also include the PCECC Capability sub-TLV inside the PATH-SETUP-
TYPE-CAPABILITY TLV. TYPE-CAPABILITY TLV. If the sub-TLV is absent, then the PCEP speaker
MUST send a PCErr message with Error-Type 10 (Reception of an invalid
object) and Error-Value TBD (Missing PCECC Capability sub-TLV) and
MUST then close the PCEP session. If a PCEP speaker receives a PATH-
SETUP-TYPE-CAPABILITY TLV with a SR-PCE-CAPABILITY sub-TLV, but the
PST list does not contain PST=1, then the PCEP speaker MUST ignore
the SR-PCE-CAPABILITY sub- TLV.
The presence of the PST and PCECC Capability sub-TLV in PCC's OPEN The presence of the PST and PCECC Capability sub-TLV in PCC's OPEN
Object indicates that the PCC is willing to function as a PCECC Object indicates that the PCC is willing to function as a PCECC
client. client. The presence of the PST and PCECC Capability sub-TLV in
PCE's OPEN message indicates that the PCE is interested in function
The presence of the PST and PCECC Capability sub-TLV in PCE's OPEN as a PCECC server.
message indicates that the PCE is interested in function as a PCECC
server.
The PCEP protocol extensions for PCECC MUST NOT be used if one or The PCEP protocol extensions for PCECC MUST NOT be used if one or
both PCEP Speakers have not included the PST or the PCECC Capability both PCEP Speakers have not included the PST or the PCECC Capability
sub-TLV in their respective OPEN message. If the PCEP Speakers sub-TLV in their respective OPEN message. If the PCEP Speakers
support the extensions of this draft but did not advertise this support the extensions of this draft but did not advertise this
capability then a PCErr message with Error-Type=19(Invalid Operation) capability then a PCErr message with Error-Type=19(Invalid Operation)
and Error-Value=TBD (Attempted PCECC operations when PCECC capability and Error-Value=TBD (Attempted PCECC operations when PCECC capability
was not advertised) will be generated and the PCEP session will be was not advertised) will be generated and the PCEP session will be
terminated. terminated.
A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and A PCC or a PCE MUST include both PCECC-CAPABILITY sub-TLV and
STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with I flag set [RFC8281]) STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with I flag set [RFC8281])
in OPEN Object to support the extensions defined in this document. in OPEN Object to support the extensions defined in this document.
If PCECC-CAPABILITY sub-TLV is advertised and STATEFUL-PCE-CAPABILITY If PCECC-CAPABILITY sub-TLV is advertised and STATEFUL-PCE-CAPABILITY
TLV is not advertised in OPEN Object, it SHOULD send a PCErr message TLV is not advertised in OPEN Object, it MUST send a PCErr message
with Error-Type=19 (Invalid Operation) and Error-value=TBD (stateful with Error-Type=19 (Invalid Operation) and Error-value=TBD (stateful
PCE capability was not advertised) and terminate the session. PCE capability was not advertised) and terminate the session. This
error is also triggered if PCECC-CAPABILITY sub-TLV is advertised and
I flag is not set.
5.4. LSP Operations 5.4. LSP Operations
The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE
TLV [RFC8408] in the SRP object to clearly identify the PCECC LSP is TLV [RFC8408] in the SRP object to clearly identify the PCECC LSP is
intended. intended.
5.4.1. Basic PCECC LSP Setup 5.4.1. Basic PCECC LSP Setup
In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate In order to setup a LSP based on PCECC mechanism, a PCC MUST delegate
skipping to change at page 8, line 46 skipping to change at page 8, line 50
Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the LSP Section 7.2) and D (Delegate) flag (see [RFC8231]) set in the LSP
object. object.
LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the tuple uniquely LSP-IDENTIFIER TLV MUST be included for PCECC LSP, the tuple uniquely
identifies the LSP in the network. The LSP object is included in identifies the LSP in the network. The LSP object is included in
central controller's instructions (label download) to identify the central controller's instructions (label download) to identify the
PCECC LSP for this instruction. The PLSP-ID is the original PCECC LSP for this instruction. The PLSP-ID is the original
identifier used by the ingress PCC, so the transit LSR could have identifier used by the ingress PCC, so the transit LSR could have
multiple central controller instructions that have the same PLSP-ID. multiple central controller instructions that have the same PLSP-ID.
The PLSP-ID in combination with the source (in LSP-IDENTIFIER TLV) The PLSP-ID in combination with the source (in LSP-IDENTIFIER TLV)
MUST be unique. The PLSP-ID is included for maintainability reasons. MUST be unique. The PLSP-ID is included for maintainability reasons
As per [RFC8281], the LSP object could include SPEAKER-ENTITY-ID TLV to ease debugging. As per [RFC8281], the LSP object could include
to identify the PCE that initiated these instructions. Also the CC- SPEAKER-ENTITY-ID TLV to identify the PCE that initiated these
ID is unique on the PCEP session as described in Section 7.3. instructions. Also the CC-ID is unique on the PCEP session as
described in Section 7.3.
When a PCE receives PCRpt message with D flags and PST Type set, it When a PCE receives PCRpt message with D flags and PST Type set, it
calculates the path and assigns labels along the path; and set up the calculates the path and assigns labels along the path; and set up the
path by sending PCInitiate message to each node along the path of the path by sending PCInitiate message to each node along the path of the
LSP. The PCC generates a Path Computation State Report (PCRpt) and LSP. The PCC generates a Path Computation State Report (PCRpt) and
include the central controller's instruction (CCI) and the identified include the central controller's instruction (CCI) and the identified
LSP. The CC-ID is uniquely identify the central controller's LSP. The CC-ID is uniquely identify the central controller's
instruction within PCEP. The PCC further responds with the PCRpt instruction within a PCEP session. The PCC further responds with the
messages including the CCI and LSP objects. PCRpt messages including the CCI and LSP objects.
The Ingress node would receive one CCI object with O bit (out-label) The Ingress node would receive one CCI object with O bit (out-label)
set. The transit node(s) would receive two CCI object with the in- set. The transit node(s) would receive two CCI object with the in-
label CCI without O bit set and the out-label CCI with O bit set. label CCI without O bit set and the out-label CCI with O bit set.
The egress node would receive one CCI object without O bit set. A The egress node would receive one CCI object without O bit set. A
node can determine its role based on the setting of the O bit in the node can determine its role based on the setting of the O bit in the
CCI object(s). CCI object(s).
Once the central controller's instructions (label operations) are Once the central controller's instructions (label operations) are
completed, the PCE SHOULD send the PCUpd message to the Ingress PCC. completed, the PCE MUST send the PCUpd message to the Ingress PCC.
The PCUpd message is as per [RFC8231] SHOULD include the path This PCUpd message is as per [RFC8231] SHOULD include the path
information as calculated by the PCE. information as calculated by the PCE.
Note that the PCECC LSPs MUST be delegated to a PCE at all times. Note that the PCECC LSPs MUST be delegated to a PCE at all times.
LSP deletion operation for PCECC LSP is same as defined in [RFC8231]. LSP deletion operation for PCECC LSP is same as defined in [RFC8231].
If the PCE receives PCRpt message for LSP deletion then it does Label If the PCE receives PCRpt message for LSP deletion then it does Label
cleanup operation as described in Section 5.4.2.2 for the cleanup operation as described in Section 5.4.2.2 for the
corresponding LSP. corresponding LSP.
The Basic PCECC LSP setup sequence is as shown below. The Basic PCECC LSP setup sequence is as shown below.
skipping to change at page 10, line 18 skipping to change at page 10, line 18
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| Transit| | | | Transit| | |
+------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP +------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP
|PCC +--------+ | | |PCC +--------+ | |
|Egress | | | | |Egress | | | |
+--------+ | | | +--------+ | | |
| | | | | | | |
|<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label
| | | L1,O=0 | download | | | L1,O=0 | download
|------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI
| | | | | | | |
| |<----- PCInitiate,PLSP-ID=1, ------------- | Labels | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels
| | | CC-ID=Y1,O=0,L2 | download | | | CC-ID=Y1,O=0,L2 | download
| | | CC-ID=Y2,O=1,L1 | | | | CC-ID=Y2,O=1,L1 | CCI
| |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>| | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------>|
| | | | | | | |
| | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label
| | | L2,O=1 | download | | | L2,O=1 | download
| | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI
| | | | | | | |
| | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP | | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP
| | | | Update | | | | Update
| | | | | | | |
Figure 2: Basic PCECC LSP setup Figure 2: Basic PCECC LSP setup
The PCECC LSP are considered to be 'up' by default (on receipt of The PCECC LSP are considered to be 'up' by default (on receipt of
PCUpd message from PCE). The Ingress MAY further choose to deploy a PCUpd message from PCE). The Ingress MAY further choose to deploy a
data plane check mechanism and report the status back to the PCE via data plane check mechanism and report the status back to the PCE via
PCRpt message. PCRpt message.
In case where the label allocation are made by the PCC itself (see In case where the label allocation are made by the PCC itself (see
Section 5.4.8), the PCE could still request an allocation to be made Section 5.4.8), the PCE could request an allocation to be made by the
by the PCC, and where the PCC would send a PCRpt with the allocated PCC, and where the PCC would send a PCRpt with the allocated label
label encoded in the CC-ID object as shown below - encoded in the CC-ID object as shown below -
+-------+ +-------+ +-------+ +-------+
|PCC | | PCE | |PCC | | PCE |
|Ingress| +-------+ |Ingress| +-------+
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| Transit| | | | Transit| | |
+------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP +------| | |-- PCRpt,PLSP-ID=1, PST=TBD, D=1---->| PCECC LSP
|PCC +--------+ | | |PCC +--------+ | |
|Egress | | | | |Egress | | | |
+--------+ | | | +--------+ | | |
| | | | | | | |
|<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label
| | | C=1 | download | | | C=1 | download
|------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| |------- PCRpt,CC-ID=X,PLSP-ID=1 ----------------->| CCI
| | | Label=L1 | | | | Label=L1 |
| |<----- PCInitiate,PLSP-ID=1, ------------- | Labels | |<----- PCInitiate,PLSP-ID=1, ------------- | Labels
| | | CC-ID=Y1,C=1 | download | | | CC-ID=Y1,C=1 | download
| | | CC-ID=Y2,C=0,L1 | | | | CC-ID=Y2,C=0,L1 | CCI
| |----- PCRpt,PLSP-ID=1 ------------------>| | |----- PCRpt,PLSP-ID=1 ------------------>|
| | | CC-ID=Y1, Label=L2 | | | | CC-ID=Y1, Label=L2 |
| | | CC-ID=Y2 | | | | CC-ID=Y2 |
| | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 - | Label
| | | C=0,L2 | download | | | C=0,L2 | download
| | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------>| CCI
| | | | | | | |
| | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP | | |<-- PCUpd,PLSP-ID=1,PST=TBD, D=1-----| PCECC LSP
| | | | Update | | | | Update
| | | | | | | |
- The O bit is set as before (and thus not included) - The O bit is set as before (and thus not included)
Figure 3: Basic PCECC LSP setup (PCC allocation) Figure 3: Basic PCECC LSP setup (PCC allocation)
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
skipping to change at page 12, line 12 skipping to change at page 12, line 12
C bit is unset towards the ingress to complete all the label C bit is unset towards the ingress to complete all the label
allocation for the PCECC LSP. allocation for the PCECC LSP.
5.4.2. Central Control Instructions 5.4.2. Central Control Instructions
The new central controller's instructions (CCI) for the label The new central controller's instructions (CCI) for the label
operations in PCEP is done via the PCInitiate message, by defining a operations in PCEP is done via the PCInitiate message, by defining a
new PCEP Objects for CCI operations. Local label range of each PCC new PCEP Objects for CCI operations. Local label range of each PCC
is assumed to be known at both the PCC and the PCE. is assumed to be known at both the PCC and the PCE.
5.4.2.1. Label Download 5.4.2.1. Label Download CCI
In order to setup an LSP based on PCECC, the PCE sends a PCInitiate In order to setup an LSP based on PCECC, the PCE sends a PCInitiate
message to each node along the path to download the Label instruction message to each node along the path to download the Label instruction
as described in Section 5.4.1. as described in Section 5.4.1.
The CCI object MUST be included, along with the LSP object in the The CCI object MUST be included, along with the LSP object in the
PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in LSP PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in LSP
object. The SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object. object. The SPEAKER-ENTITY-ID TLV SHOULD be included in LSP object.
If a node (PCC) receives a PCInitiate message which includes a Label If a node (PCC) receives a PCInitiate message which includes a Label
skipping to change at page 12, line 36 skipping to change at page 12, line 36
the SRP object to specify the error is for the corresponding label the SRP object to specify the error is for the corresponding label
update via PCInitiate message. If a PCC receives a PCInitiate update via PCInitiate message. If a PCC receives a PCInitiate
message but failed to download the Label entry, it MUST send a PCErr message but failed to download the Label entry, it MUST send a PCErr
message with Error-type=TBD (PCECC failure) and Error-value=TBD message with Error-type=TBD (PCECC failure) and Error-value=TBD
(instruction failed) and MUST include the SRP object to specify the (instruction failed) and MUST include the SRP object to specify the
error is for the corresponding label update via PCInitiate message. error is for the corresponding label update via PCInitiate message.
New PCEP object for central control instructions (CCI) is defined in New PCEP object for central control instructions (CCI) is defined in
Section 7.3. Section 7.3.
5.4.2.2. Label Cleanup 5.4.2.2. Label Cleanup CCI
In order to delete an LSP based on PCECC, the PCE sends a central In order to delete an LSP based on PCECC, the PCE sends a central
controller instructions via a PCInitiate message to each node along controller instructions via a PCInitiate message to each node along
the path of the LSP to cleanup the Label forwarding instruction. the path of the LSP to cleanup the Label forwarding instruction.
If the PCC receives a PCInitiate message but does not recognize the If the PCC receives a PCInitiate message but does not recognize the
label in the CCI, the PCC MUST generate a PCErr message with Error- label in the CCI, the PCC MUST generate a PCErr message with Error-
Type 19(Invalid operation) and Error-Value=TBD, "Unknown Label" and Type 19(Invalid operation) and Error-Value=TBD, "Unknown Label" and
MUST include the SRP object to specify the error is for the MUST include the SRP object to specify the error is for the
corresponding label cleanup (via PCInitiate message). corresponding label cleanup (via PCInitiate message).
skipping to change at page 13, line 18 skipping to change at page 13, line 18
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| Transit| | | | Transit| | |
+------| | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1--->| PCECC LSP +------| | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1,R=1--->| PCECC LSP
|PCC +--------+ | | remove |PCC +--------+ | | remove
|Egress | | | | |Egress | | | |
+--------+ | | | +--------+ | | |
| | | | | | | |
|<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label |<------ PCInitiate,CC-ID=X,PLSP-ID=1 ------------ | Label
| | | R=1 | cleanup | | | R=1 | cleanup
|------- PCRpt,CC-ID=X,PLSP-ID=1 ------------------>| |------- PCRpt,CC-ID=X,PLSP-ID=1 ------------------>| CCI
| | | | | | | |
| |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1 -- | Label | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1 -- | Label
| | | R=1 | cleanup | | | R=1 | cleanup
| |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------->| | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=1 ------->| CCI
| | | | | | | |
| | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 -- | Label | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=1 -- | Label
| | | R=1 | cleanup | | | R=1 | cleanup
| | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------->| | | |---- PCRpt,CC-ID=Z,PLSP-ID=1 ------->| CCI
| | | | | | | |
As per [RFC8281], following the removal of the Label forwarding As per [RFC8281], following the removal of the Label forwarding
instruction, the PCC MUST send a PCRpt message. The SRP object in instruction, the PCC MUST send a PCRpt message. The SRP object in
the PCRpt MUST include the SRP-ID-number from the PCInitiate message the PCRpt MUST include the SRP-ID-number from the PCInitiate message
that triggered the removal. The R flag in the SRP object MUST be that triggered the removal. The R flag in the SRP object MUST be
set. set.
In case where the label allocation are made by the PCC itself (see In case where the label allocation are made by the PCC itself (see
Section 5.4.8), the removal procedure remains the same. Section 5.4.8), the removal procedure remains the same.
skipping to change at page 14, line 32 skipping to change at page 14, line 32
+------| | | +------| | |
| PCC +-------+ | | PCC +-------+ |
| Transit| | | | Transit| | |
+------| | |<--PCInitiate,PLSP-ID=0,PST=TBD,D=1---| PCECC LSP +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD,D=1---| PCECC LSP
|PCC +--------+ | | Initiate |PCC +--------+ | | Initiate
|Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP |Egress | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | PCECC LSP
+--------+ | | (GOING-UP) | +--------+ | | (GOING-UP) |
| | | | | | | |
|<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label |<------ PCInitiate,CC-ID=X,PLSP-ID=2 -------------- | Label
| | | | download | | | | download
|------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| |------- PCRpt,CC-ID=X,PLSP-ID=2 ------------------>| CCI
| | | | | | | |
| |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label | |<----- PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2 --- | Label
| | | | download | | | | download
| |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| | |----- PCRpt,CC-ID=Y1,Y2,PLSP-ID=2 ------->| CCI
| | | | | | | |
| | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label | | |<--- PCInitiate,CC-ID=Z,PLSP-ID=2 --- | Label
| | | | download | | | | download
| | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| | | |---- PCRpt,CC-ID=Z,PLSP-ID=2 ------->| CCI
| | | | | | | |
| | |<-- PCUpd, PLSP-ID=2, PST=TBD, D=1--- | PCECC LSP | | |<-- PCUpd, PLSP-ID=2, PST=TBD, D=1--- | PCECC LSP
| | | (UP) | Update | | | (UP) | Update
| | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> | | | |--- PCRpt,PLSP-ID=2,P=1,D=1,C=1---> |
| | | (UP) | | | | (UP) |
Once the label operations are completed, the PCE SHOULD send the Once the label operations are completed, the PCE SHOULD send the
PCUpd message to the Ingress PCC. The PCUpd message is as per PCUpd message to the Ingress PCC. The PCUpd message is as per
[RFC8231]. [RFC8231].
skipping to change at page 16, line 21 skipping to change at page 16, line 21
|PCC +--------+ | | |PCC +--------+ | |
|Egress | | | | |Egress | | | |
+--------+ | | | +--------+ | | |
| | | | New Path | | | | New Path
|<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 ----------- | for LSP
| | | | trigger | | | | trigger
|------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI |------- PCRpt,CC-ID=XX,PLSP-ID=1 ---------------->| new CCI
| | | | | | | |
| |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label | |<----- PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label
| | | | download | | | | download
| |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| | |----- PCRpt,CC-ID=YY1,YY2,PLSP-ID=1 ---->| CCI
| | | | | | | |
| | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label | | |<--- PCInitiate,CC-ID=ZZ,PLSP-ID=1 - | Label
| | | | download | | | | download
| | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| | | |---- PCRpt,CC-ID=ZZ,PLSP-ID=1 ----->| CCI
| | | | | | | |
| | |<-- PCUpd, PLSP-ID=1, PST=TBD, D=1-- | PCECC | | |<-- PCUpd, PLSP-ID=1, PST=TBD, D=1-- | PCECC
| | | SRP=S | LSP Update | | | SRP=S | LSP Update
| | | | | | | |
| | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1 -->| Trigger | | |-- PCRpt,PLSP-ID=1,PST=TBD,D=1 -->| Trigger
| | | (SRP=S) | Delete old | | | (SRP=S) | Delete old
| | | | CCI | | | | CCI
| | | | | | | |
|<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label |<------ PCInitiate,CC-ID=X, PLSP-ID=1 ----------- | Label
| | | R=1 | cleanup | | | R=1 | cleanup
|------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| |------- PCRpt,CC-ID=X, PLSP-ID=1 ---------------->| CCI
| | | | | | | |
| |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label | |<----- PCInitiate,CC-ID=Y1,Y2, PLSP-ID=1 - | Label
| | | R=1 | cleanup | | | R=1 | cleanup
| |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| | |----- PCRpt,CC-ID=Y1,Y2, PLSP-ID=1 ----->| CCI
| | | | | | | |
| | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label | | |<--- PCInitiate,CC-ID=Z, PLSP-ID=1 - | Label
| | | R=1 | cleanup | | | R=1 | cleanup
| | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| | | |---- PCRpt,CC-ID=Z, PLSP-ID=1 ----->| CCI
| | | | | | | |
The modified PCECC LSP are considered to be 'up' by default. The The modified PCECC LSP are considered to be 'up' by default. The
Ingress MAY further choose to deploy a data plane check mechanism and Ingress MAY further choose to deploy a data plane check mechanism and
report the status back to the PCE via PCRpt message. report the status back to the PCE via PCRpt message.
In case where the label allocation are made by the PCC itself (see In case where the label allocation are made by the PCC itself (see
Section 5.4.8), the procedure remains similar. Section 5.4.8), the procedure remains similar.
5.4.5. Re Delegation and Cleanup 5.4.5. Re Delegation and Cleanup
skipping to change at page 18, line 41 skipping to change at page 18, line 41
5.4.9. Binding Label 5.4.9. Binding Label
As per [I-D.sivabalan-pce-binding-label-sid], when a stateful PCE is As per [I-D.sivabalan-pce-binding-label-sid], when a stateful PCE is
deployed for setting up TE paths, it may be desirable to report the deployed for setting up TE paths, it may be desirable to report the
binding label to the stateful PCE for the purpose of enforcing end- binding label to the stateful PCE for the purpose of enforcing end-
to-end TE. In case of PCECC, the binding label may be allocated by to-end TE. In case of PCECC, the binding label may be allocated by
the PCE itself as described in this section. This procedure is thus the PCE itself as described in this section. This procedure is thus
applicable for all path setup types including PCECC. applicable for all path setup types including PCECC.
A P flag in LSP object is introduced in [I-D.li-pce-sr-path-segment] A P flag in LSP object is introduced in [I-D.li-pce-sr-path-segment]
to indicate the allocation needs to be made by the PCE. The same to indicate the allocation needs to be made by the PCE. This flag is
flag can also be used to indicate that the allocation needs to be used to indicate that the allocation needs to be made by the PCE. A
made by the PCE. A PCC would set this bit to 1 (and carry the TE- PCC would set this bit to 1 (and carry the TE-PATH-BINDING TLV
PATH-BINDING TLV [I-D.sivabalan-pce-binding-label-sid] in LSP object) [I-D.sivabalan-pce-binding-label-sid] in LSP object) to request for
to request for allocation of the binding label by the PCE in the allocation of the binding label by the PCE in the PCReq or PCRpt
PCReq or PCRpt message. A PCE would also set this bit to 1 to message. A PCE would also set this bit to 1 to indicate that the
indicate that the binding label is allocated by PCE and encoded in binding label is allocated by PCE and encoded in the PCRep, PCUpd or
the PCRep, PCUpd or PCInitiate message (the TE-PATH-BINDING TLV is PCInitiate message (the TE-PATH-BINDING TLV is present in LSP
present in LSP object). Further, a PCE would set this bit to 0 to object). Further, a PCE would set this bit to 0 to indicate that the
indicate that the allocation is done by the PCC instead. allocation is done by the PCC instead.
The ingress PCC could request the binding label to be allocated by The ingress PCC could request the binding label to be allocated by
the PCE via PCRpt message as per [RFC8231]. The delegate flag the PCE via PCRpt message as per [RFC8231]. The delegate flag
(D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST (D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MUST
be included with no Binding Value. The PCECC would allocated the be included with no Binding Value. The PCECC would allocated the
binding label and further respond to Ingress PCC with PCUpd message binding label and further respond to Ingress PCC with PCUpd message
as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in a LSP as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in a LSP
object. The P flag in the LSP object would be set to 1 to indicate object. The P flag in the LSP object would be set to 1 to indicate
that the allocation is made by the PCE. that the allocation is made by the PCE.
skipping to change at page 22, line 22 skipping to change at page 22, line 22
Object for PCECC capability advertisement in PATH-SETUP-TYPE- Object for PCECC capability advertisement in PATH-SETUP-TYPE-
CAPABILITY TLV. Advertisement of the PCECC capability implies CAPABILITY TLV. Advertisement of the PCECC capability implies
support of LSPs that are setup through PCECC as per PCEP extensions support of LSPs that are setup through PCECC as per PCEP extensions
defined in this document. defined in this document.
Its format is shown in the following figure: Its format is shown in the following figure:
0 1 2 3 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 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=TBD | Length=4 | | Type=TBD | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type of the TLV is TBD and it has a fixed length of 4 octets. The type of the TLV is TBD and it has a fixed length of 4 octets.
The value comprises a single field - Flags (32 bits). The value comprises a single field - Flags (32 bits).
No flags are assigned right now. No flags are assigned right now.
skipping to change at page 23, line 21 skipping to change at page 23, line 21
CCI Object-Class is TBD. CCI Object-Class is TBD.
CCI Object-Type is 1 for the MPLS Label. CCI Object-Type is 1 for the MPLS Label.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID | | CC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |C|O| | Reserved | Flags |C|O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Reserved | | Label | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV // // Optional TLV //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the CCI object are as follows: The fields in the CCI object are as follows:
skipping to change at page 25, line 39 skipping to change at page 25, line 8
0 1 2 3 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 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=TBD | Length = 8 | | Type=TBD | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node-ID | | Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LINKLOCAL-IPV6-ID-ADDRESS TLV:
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=TBD | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The address TLVs are as follows: The address TLVs are as follows:
IPV4-ADDRESS TLV: an IPv4 address. IPV4-ADDRESS TLV: an IPv4 address.
IPV6-ADDRESS TLV: an IPv6 address. IPV6-ADDRESS TLV: an IPv6 address.
UNNUMBERED-IPV4-ID-ADDRESS TLV: a pair of Node ID / Interface ID UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple.
tuples.
8. Security Considerations LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address,
interface ID) tuples.
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, 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 [RFC8231] and [RFC8281] The security considerations described in [RFC8231] and [RFC8281]
apply to the extensions described in this document. Additional apply to the extensions described in this document. Additional
considerations related to a malicious PCE are introduced. considerations related to a malicious PCE are introduced.
8.1. Malicious PCE 9.1. Malicious PCE
PCE has complete control over PCC to update the labels and can cause PCE has complete control over PCC to update the labels and can cause
the LSP's to behave inappropriate and cause cause major impact to the the LSP's to behave inappropriate and cause cause major impact to the
network. As a general precaution, it is RECOMMENDED that these PCEP network. As a general precaution, it is RECOMMENDED that these PCEP
extensions only be activated on authenticated and encrypted sessions extensions only be activated on authenticated and encrypted sessions
across PCEs and PCCs belonging to the same administrative authority, across PCEs and PCCs belonging to the same administrative authority,
using Transport Layer Security (TLS) [RFC8253], as per the using Transport Layer Security (TLS) [RFC8253], as per the
recommendations and best current practices in [RFC7525]. recommendations and best current practices in [RFC7525].
9. Manageability Considerations 10. Manageability Considerations
9.1. Control of Function and Policy 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 capability as a global configuration. disable PCECC 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 capability status. PCECC 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 capability. enable/disable PCECC 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 extensions defined in this document do not put new requirements PCEP extensions defined in this document do not put new requirements
on network operations. on network operations.
10. IANA Considerations 11. IANA Considerations
10.1. PCEP TLV Type Indicators 11.1. PCEP TLV Type Indicators
IANA is requested to confirm the early allocation of the following IANA is requested to allocate the following TLV Type Indicator values
TLV Type Indicator values within the "PCEP TLV Type Indicators" sub- within the "PCEP TLV Type Indicators" sub- registry of the PCEP
registry of the PCEP Numbers registry, and to update the reference in Numbers registry:
the registry to point to this document, when it is an RFC:
Value Meaning Reference Value Meaning Reference
TBD PCECC-CAPABILITY This document
TBD IPV4-ADDRESS TLV This document TBD IPV4-ADDRESS TLV This document
TBD IPV6-ADDRESS TLV This document TBD IPV6-ADDRESS TLV This document
TBD UNNUMBERED-IPV4-ID-ADDRESS TLV This document TBD UNNUMBERED-IPV4-ID-ADDRESS TLV This document
TBD LINKLOCAL-IPV6-ID-ADDRESS TLV This document
10.2. New Path Setup Type Registry 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
IANA is requested to allocate new PST Field in PATH- SETUP-TYPE TLV. [I-D.ietf-pce-segment-routing] requested creation of "PATH-SETUP-
The allocation policy for this new registry should be by IETF TYPE-CAPABILITY Sub-TLV Type Indicators" sub-registry. Further IANA
Consensus. The new registry should contain the following value: is requested to allocate the following code-point:
Value Meaning Reference
TBD PCECC-CAPABILITY This document
11.3. New Path Setup Type Registry
[RFC8408] created a sub-registry within the "Path Computation Element
Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types".
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 mode setup using PCECC mode
10.3. PCEP Object 11.4. PCEP Object
IANA is requested to allocate new registry for CCI PCEP object. IANA is requested to allocate new code-point in the "PCEP Objects"
sub-registry for the CCI object as follows:
Object-Class Value Name Reference Object-Class Value Name Reference
TBD CCI Object-Type This document TBD CCI Object-Type This document
0 Reserved
1 MPLS Label 1 MPLS Label
10.4. CCI Object Flag Field 11.5. CCI Object Flag Field
IANA is requested to create a registry to manage the Flag field of IANA is requested to create a new sub-registry to manage the Flag
the CCI object. field of the CCI object called "CCI Object Flag Field". New values
are to be assigned by Standards Action [RFC8126]. Each bit should be
tracked with the following qualities:
One bit to be defined for the CCI Object flag field in this document: o Bit number (counting from bit 0 as the most significant bit)
Codespace of the Flag field (CCI Object) o Capability description
Bit Description Reference
7 Specifies label This document
is out label
10.5. PCEP-Error Object o Defining RFC
Two bits to be defined for the CCI Object flag field in this document
as follows:
Bit Description Reference
0-13 Unassigned This document
14 C Bit - PCC allocation This document
15 O Bit - Specifies label This document
is out label
11.6. 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
---------- ------- ---------- -------
10 Reception of an invalid object.
Error-value = TBD : Missing PCECC
Capability sub-TLV
19 Invalid operation. 19 Invalid operation.
Error-value = TBD : Attempted PCECC Error-value = TBD : Attempted PCECC
operations when operations when
PCECC capability PCECC capability
was not advertised was not advertised
Error-value = TBD : Stateful PCE Error-value = TBD : Stateful PCE
capability was not capability was not
advertised advertised
Error-value = TBD : Unknown Label Error-value = TBD : Unknown Label
skipping to change at page 28, line 37 skipping to change at page 29, line 46
Error-value = TBD : CCI object missing Error-value = TBD : CCI object missing
TBD PCECC failure. TBD PCECC failure.
Error-value = TBD : Label out of range. Error-value = TBD : Label out of range.
Error-value = TBD : Instruction failed. Error-value = TBD : Instruction failed.
Error-value = TBD : Invalid CCI. Error-value = TBD : Invalid CCI.
Error-value = TBD : Unable to allocate Error-value = TBD : Unable to allocate
the specified CCI. the specified CCI.
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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
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>.
skipping to change at page 29, line 22 skipping to change at page 30, line 31
(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, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[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>.
skipping to change at page 30, line 5 skipping to change at page 31, line 16
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
[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>.
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
Margaria, "Requirements for GMPLS Applications of PCE", Margaria, "Requirements for GMPLS Applications of PCE",
RFC 7025, DOI 10.17487/RFC7025, September 2013, RFC 7025, DOI 10.17487/RFC7025, September 2013,
<https://www.rfc-editor.org/info/rfc7025>. <https://www.rfc-editor.org/info/rfc7025>.
skipping to change at page 30, line 27 skipping to change at page 31, line 38
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014,
<https://www.rfc-editor.org/info/rfc7399>. <https://www.rfc-editor.org/info/rfc7399>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015, DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>. <https://www.rfc-editor.org/info/rfc7491>.
[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>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the "PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control", Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017, RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>. <https://www.rfc-editor.org/info/rfc8283>.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-16 (work in progress),
March 2019.
[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.zhao-pce-pcep-extension-pce-controller-sr] [I-D.zhao-pce-pcep-extension-pce-controller-sr]
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 SR-LSPs", Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep-
draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work extension-pce-controller-sr-04 (work in progress),
in progress), June 2018. February 2019.
[I-D.li-pce-controlled-id-space] [I-D.li-pce-controlled-id-space]
Li, C., Chen, M., Dong, J., Li, Z., and A. Wang, "PCE Li, C., Chen, M., Dong, J., Li, Z., Wang, A., Cheng, W.,
Controlled ID Space", draft-li-pce-controlled-id-space-01 and C. Zhou, "PCE Controlled ID Space", draft-li-pce-
(work in progress), December 2018. controlled-id-space-03 (work in progress), June 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.
[I-D.li-pce-sr-path-segment] [I-D.li-pce-sr-path-segment]
Li, C., Chen, M., Dhody, D., Cheng, W., Dong, J., Li, Z., Li, C., Chen, M., Cheng, W., Dong, J., Li, Z., Gandhi, R.,
and R. Gandhi, "Path Computation Element Communication and Q. Xiong, "Path Computation Element Communication
Protocol (PCEP) Extension for Path Segment in Segment Protocol (PCEP) Extension for Path Segment in Segment
Routing (SR)", draft-li-pce-sr-path-segment-03 (work in Routing (SR)", draft-li-pce-sr-path-segment-05 (work in
progress), October 2018. progress), March 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 32, line 36 skipping to change at page 34, 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 Futurewei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
EMail: katherine.zhao@huawei.com EMail: katherine.zhao@futurewei.com
Boris Zhang Boris Zhang
Telus Ltd. Telus Ltd.
Toronto Toronto
Canada Canada
EMail: boris.zhang@telus.com EMail: boris.zhang@telus.com
Alex Tokar Alex Tokar
Cisco Systems Cisco Systems
Slovak Republic Slovak Republic
EMail: atokar@cisco.com EMail: atokar@cisco.com
 End of changes. 86 change blocks. 
154 lines changed or deleted 262 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/