draft-ietf-pce-lsp-control-request-08.txt   draft-ietf-pce-lsp-control-request-09.txt 
PCE Working Group A. Raghuram PCE Working Group A. Raghuram
Internet-Draft A. Goddard Internet-Draft A. Goddard
Intended status: Standards Track AT&T Intended status: Standards Track AT&T
Expires: February 25, 2020 J. Karthik Expires: March 16, 2020 J. Karthik
S. Sivabalan S. Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
M. Negi M. Negi
Huawei Technologies Huawei Technologies
August 24, 2019 September 13, 2019
Ability for a Stateful Path Computation Element (PCE) to request and Ability for a Stateful Path Computation Element (PCE) to request and
obtain control of a Label Switched Path (LSP) obtain control of a Label Switched Path (LSP)
draft-ietf-pce-lsp-control-request-08 draft-ietf-pce-lsp-control-request-09
Abstract Abstract
A Stateful Path Computation Element (PCE) retains information about A Stateful Path Computation Element (PCE) retains information about
the placement of Multiprotocol Label Switching (MPLS) Traffic the placement of Multiprotocol Label Switching (MPLS) Traffic
Engineering Label Switched Paths (TE LSPs). When a PCE has stateful Engineering Label Switched Paths (TE LSPs). When a PCE has stateful
control over LSPs it may send indications to LSP head-ends to modify control over LSPs it may send indications to LSP head-ends to modify
the attributes (especially the paths) of the LSPs. A Path the attributes (especially the paths) of the LSPs. A Path
Computation Client (PCC) has set up LSPs under local configuration Computation Client (PCC) has set up LSPs under local configuration
may delegate control of those LSPs to a stateful PCE. may delegate control of those LSPs to a stateful PCE.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 February 25, 2020. This Internet-Draft will expire on March 16, 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 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. LSP Control Request Flag . . . . . . . . . . . . . . . . . . 4 3. LSP Control Request Flag . . . . . . . . . . . . . . . . . . 4
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
5.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 6 5.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. SRP Object Flags . . . . . . . . . . . . . . . . . . . . 7 7.1. SRP Object Flags . . . . . . . . . . . . . . . . . . . . 7
8. Manageability Considerations . . . . . . . . . . . . . . . . 7 8. Manageability Considerations . . . . . . . . . . . . . . . . 7
8.1. Control of Function and Policy . . . . . . . . . . . . . 7 8.1. Control of Function and Policy . . . . . . . . . . . . . 8
8.2. Information and Data Models . . . . . . . . . . . . . . . 8 8.2. Information and Data Models . . . . . . . . . . . . . . . 8
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 8 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 8
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 8 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 8
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 8 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 8
8.6. Impact On Network Operations . . . . . . . . . . . . . . 8 8.6. Impact On Network Operations . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 11 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 11
skipping to change at page 4, line 23 skipping to change at page 4, line 23
PCEP: Path Computation Element communication Protocol. PCEP: Path Computation Element communication Protocol.
This document uses the following terms defined in [RFC8231]: This document uses the following terms defined in [RFC8231]:
PCRpt: Path Computation State Report message. PCRpt: Path Computation State Report message.
PCUpd: Path Computation Update Request message. PCUpd: Path Computation Update Request message.
PLSP-ID: A PCEP-specific identifier for the LSP. PLSP-ID: A PCEP-specific identifier for the LSP.
SRP: Stateful PCE Request Parameters.
Readers of this document are expected to have some familiarity with
[RFC8231].
2.1. Requirements Language 2.1. Requirements Language
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.
3. LSP Control Request Flag 3. LSP Control Request Flag
The Stateful PCE Request Parameters (SRP) object is defined in The Stateful PCE Request Parameters (SRP) object is defined in
[RFC8231], it includes a Flags field. Section 7.2 of [RFC8231], it includes a Flags field.
A new flag, the "LSP-Control Request Flag" (C), is introduced in the A new flag, the "LSP-Control Request Flag" (C), is introduced in the
SRP object. On a PCUpd message, a PCE sets the C Flag to 1 to SRP object. On a PCUpd message, a PCE sets the C Flag to 1 to
indicate that, it wishes to gain control of LSPs. The LSPs are indicate that it wishes to gain control of LSPs. The LSPs are
identified by the LSP object. A PLSP-ID of value other than 0 and identified by the LSP object. A PLSP-ID of value other than 0 and
0xFFFFF is used to identify the LSP for which the PCE requests 0xFFFFF is used to identify the LSP for which the PCE requests
control. The PLSP-ID value of 0 indicates that the PCE is requesting control. The PLSP-ID value of 0 indicates that the PCE is requesting
control of all LSPs originating from the PCC that it wishes to control of all LSPs originating from the PCC that it wishes to
delegate. The C Flag has no meaning in the PCRpt and PCInitiate delegate. The C Flag has no meaning in other PCEP messages that
message and MUST be set to 0 on transmission and MUST be ignored on carry SRP object and the flag MUST be set to 0 on transmission and
receipt. MUST be ignored on receipt.
4. Operation 4. Operation
During normal operation, a PCC that wishes to delegate the control of During normal operation, a PCC that wishes to delegate the control of
an LSP sets the D Flag (delegate) to 1 in all PCRpt messages an LSP sets the D Flag (delegate, Section 7.3 of [RFC8231]) to 1 in
pertaining to the LSP. The PCE confirms the delegation by setting D all PCRpt messages pertaining to the LSP. The PCE confirms the
Flag to 1 in all PCUpd messages pertaining to the LSP. The PCC delegation by setting D Flag to 1 in all PCUpd messages pertaining to
revokes the control of the LSP from the PCE by setting D Flag to 0 in the LSP. The PCC revokes the control of the LSP from the PCE by
PCRpt messages pertaining to the LSP. If the PCE wishes to setting D Flag to 0 in PCRpt messages pertaining to the LSP. If the
relinquish the control of the LSP, it sets D Flag to 0 in all PCUpd PCE wishes to relinquish the control of the LSP, it sets D Flag to 0
messages pertaining to the LSP. in all PCUpd messages pertaining to the LSP.
If a PCE wishes to gain control over an LSP, it sends a PCUpd message If a PCE wishes to gain control over an LSP, it sends a PCUpd message
with C Flag set to 1 in SRP object. The LSP for which the PCE with C Flag set to 1 in SRP object. The LSP for which the PCE
requests control is identified by the PLSP-ID. The PLSP-ID of 0 requests control is identified by the PLSP-ID. The PLSP-ID of 0
indicates that the PCE wants control over all LSPs originating from indicates that the PCE wants control over all LSPs originating from
the PCC. A PCC that receives a PCUpd message with C Flag set to 1 the PCC. A PCC that receives a PCUpd message with C Flag set to 1
and PLSP-ID of 0 MUST NOT trigger the error condition for unknown and PLSP-ID of 0 MUST NOT trigger the error condition for unknown
PLSP-ID in an LSP update request as per [RFC8231]. The D Flag and C PLSP-ID in an LSP update request as per [RFC8231]. The D Flag and C
Flag are mutually exclusive in PCUpd message. The PCE SHOULD NOT Flag are mutually exclusive in PCUpd message. The PCE SHOULD NOT
send control request for LSP which is already delegated to the PCE, send control request for LSP which is already delegated to the PCE,
i.e. if the D Flag is set in the PCUpd message, then C Flag SHOULD i.e. if the D Flag is set in the PCUpd message, then C Flag SHOULD
NOT be set. If a PCC receives a PCUpd message with D Flag set in the NOT be set. If a PCC receives a PCUpd message with D Flag set in the
LSP object (i.e. LSP is already delegated) and the C Flag is also LSP object (i.e. LSP is already delegated) and the C Flag is also
set (i.e. PCE is making a control request), the PCC MUST ignore the set (i.e. PCE is making a control request), the PCC MUST ignore the
C Flag. A PCC can decide to delegate the control of the LSP at its C Flag. A PCC can decide to delegate the control of the LSP at its
own discretion. If the PCC grants or denies the control, it sends a own discretion. If the PCC grants or denies the control, it sends a
PCRpt message with D Flag set to 1 and 0 respectively in accordance PCRpt message with D Flag set to 1 and 0 respectively in accordance
with stateful PCEP [RFC8231]. If the PCC does not grant the control, with stateful PCEP [RFC8231]. If the PCC does not grant the control,
it MAY choose to not respond, and the PCE MAY choose to retry it MAY choose to not respond, and the PCE MAY choose to retry
requesting the control preferably using exponentially increasing requesting the control preferably using exponentially increasing
timer. A PCE ignores the C Flag on the PCRpt message. Note that, timer. A PCE ignores the C Flag on the PCRpt message. Note that, if
the PCUpd message with C Flag set is received for a currently non- the PCUpd message with C Flag set is received for a currently non-
delegated LSP (for which the PCE is requesting delegation), this MUST delegated LSP (for which the PCE is requesting delegation), this MUST
NOT trigger the error handling as specified in [RFC8231] (a PCErr NOT trigger the error handling as specified in [RFC8231] (a PCErr
with Error-type=19 (Invalid Operation) and error-value 1 (Attempted with Error-type=19 (Invalid Operation) and error-value 1 (Attempted
LSP Update Request for a non-delegated LSP)). LSP Update Request for a non-delegated LSP)).
As per [RFC8231], a PCC cannot delegate an LSP to more than one PCE As per [RFC8231], a PCC cannot delegate an LSP to more than one PCE
at any time. If a PCE requests control of an LSP that has already at any time. If a PCE requests control of an LSP that has already
been delegated by the PCC to another PCE, the PCC MAY ignore the been delegated by the PCC to another PCE, the PCC MAY ignore the
request, or MAY revoke the delegation to the first PCE before request, or MAY revoke the delegation to the first PCE before
skipping to change at page 9, line 5 skipping to change at page 9, line 10
9. Acknowledgements 9. Acknowledgements
Thanks to Jonathan Hardwick to remind the authors to not use Thanks to Jonathan Hardwick to remind the authors to not use
suggested values in IANA section. suggested values in IANA section.
Thanks to Adrian Farrel, Haomian Zheng and Tomonori Takeda for their Thanks to Adrian Farrel, Haomian Zheng and Tomonori Takeda for their
valuable comments. valuable comments.
Thanks to Shawn M. Emery for security directorate's review. Thanks to Shawn M. Emery for security directorate's review.
Thanks to Francesca Palombini for GENART review.
10. References 10. References
10.1. Normative References 10.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
 End of changes. 13 change blocks. 
19 lines changed or deleted 26 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/