draft-ietf-pce-lsp-control-request-07.txt   draft-ietf-pce-lsp-control-request-08.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 1, 2020 J. Karthik Expires: February 25, 2020 J. Karthik
S. Sivabalan S. Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
M. Negi M. Negi
Huawei Technologies Huawei Technologies
July 31, 2019 August 24, 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-07 draft-ietf-pce-lsp-control-request-08
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 1, 2020. This Internet-Draft will expire on February 25, 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 39 skipping to change at page 3, line 39
load. The PCEs could use proprietary algorithm to decide which LSPs load. The PCEs could use proprietary algorithm to decide which LSPs
to be assigned to the new vPCE. Thus having a mechanism for the PCE to be assigned to the new vPCE. Thus having a mechanism for the PCE
to request control of some LSPs is needed. to request control of some LSPs is needed.
In some deployments, the operator would like to use stateful PCE for In some deployments, the operator would like to use stateful PCE for
global optimization algorithms but would still like to keep the global optimization algorithms but would still like to keep the
control of the LSP at the PCC. In such cases, a stateful PCE could control of the LSP at the PCC. In such cases, a stateful PCE could
request to take control during the global optimization and return the request to take control during the global optimization and return the
delegation once done. delegation once done.
Note that [RFC8231] specify a mechanism for a PCC to delegate an Note that [RFC8231] specifies a mechanism for a PCC to delegate an
orphaned LSP to another PCE. The mechanism defined in this document orphaned LSP to another PCE. The mechanism defined in this document
can be used in conjunction to [RFC8231]. Ultimately, it is the PCC can be used in conjunction to [RFC8231]. Ultimately, it is the PCC
that decides which PCE to delegate the orphaned LSP. that decides which PCE to delegate the orphaned LSP.
This specification provides a simple extension, by using this a PCE This specification provides a simple extension, by using this a PCE
can request control of one or more LSPs from any PCC over the can request control of one or more LSPs from any PCC over the
stateful PCEP session. The procedures for granting and relinquishing stateful PCEP session. The procedures for granting and relinquishing
control of the LSPs are specified in accordance with the control of the LSPs are specified in accordance with the
specification [RFC8231]. specification [RFC8231].
skipping to change at page 5, line 23 skipping to change at page 5, line 23
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 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,
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)).
skipping to change at page 6, line 6 skipping to change at page 6, line 6
support this extension would trigger the error condition as specified support this extension would trigger the error condition as specified
in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and
error-value 1 (Attempted LSP Update Request for a non-delegated LSP)) error-value 1 (Attempted LSP Update Request for a non-delegated LSP))
as the D Flag would be unset in this update request. Further, in as the D Flag would be unset in this update request. Further, in
case of PLSP-ID of 0, the error condition as specified in [RFC8231] case of PLSP-ID of 0, the error condition as specified in [RFC8231]
(a PCErr with Error-type=19 (Invalid Operation) and error-value 3 (a PCErr with Error-type=19 (Invalid Operation) and error-value 3
(Attempted LSP Update Request for an LSP identified by an unknown (Attempted LSP Update Request for an LSP identified by an unknown
PSP-ID)) would be triggered. PSP-ID)) would be triggered.
[RFC8281] describes the setup, maintenance and teardown of PCE- [RFC8281] describes the setup, maintenance and teardown of PCE-
initiated LSPs under the stateful PCE model. It also specify how a initiated LSPs under the stateful PCE model. It also specifies how a
PCE MAY obtain control over an orphaned LSP that was PCE-initiated. PCE MAY obtain control over an orphaned LSP that was PCE-initiated.
A PCE implementation can apply the mechanism described in this A PCE implementation can apply the mechanism described in this
document in conjunction with those in [RFC8281]. document in conjunction with those in [RFC8281].
5. Implementation Status 5. Implementation Status
[Note to the RFC Editor - remove this section before publication, as [Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.] well as remove the reference to RFC 7942.]
This section records the status of known implementations of the This section records the status of known implementations of the
skipping to change at page 7, line 13 skipping to change at page 7, line 13
o Maturity Level: Prototype o Maturity Level: Prototype
o Coverage: Full o Coverage: Full
o Contact: satishk@huawei.com o Contact: satishk@huawei.com
6. Security Considerations 6. Security Considerations
The security considerations listed in [RFC8231] and [RFC8281] apply The security considerations listed in [RFC8231] and [RFC8281] apply
to this document as well. However, this document also introduces a to this document as well. However, this document also introduces a
new attack vector. An attacker may flood the PCC with request to new attack vector. An attacker may flood the PCC with request to
delegate all its LSPs at a rate which exceeds the PCC's ability to delegate all of its LSPs at a rate which exceeds the PCC's ability to
process them, either by spoofing messages or by compromising the PCE process them, either by spoofing messages or by compromising the PCE
itself. The PCC SHOULD be configured with a threshold rate for the itself. The PCC SHOULD be configured with a threshold rate for the
delegation requests received from the PCE. If threshold is reached, delegation requests received from the PCE. If the threshold is
it is RECOMMENDED to log the issue. reached, it is RECOMMENDED to log the issue.
As per [RFC8231], it is RECOMMENDED that these PCEP extensions only As per [RFC8231], it is RECOMMENDED that these PCEP extensions only
be activated on authenticated and encrypted sessions across PCEs and be activated on authenticated and encrypted sessions across PCEs and
PCCs belonging to the same administrative authority, using Transport PCCs belonging to the same administrative authority, using Transport
Layer Security (TLS) [RFC8253], as per the recommendations and best Layer Security (TLS) [RFC8253], as per the recommendations and best
current practices in [RFC7525] (unless explicitly set aside in current practices in [RFC7525] (unless explicitly excluded in
[RFC8253]). [RFC8253]).
7. IANA Considerations 7. IANA Considerations
7.1. SRP Object Flags 7.1. SRP Object Flags
IANA maintains a registry called the "Path Computation Element IANA maintains a registry called the "Path Computation Element
Protocol (PCEP) Numbers" registry. It contains a subregistry called Protocol (PCEP) Numbers" registry. It contains a subregistry called
the "SRP Object Flag Field" registry. This document requests IANA to the "SRP Object Flag Field" registry. This document requests IANA to
allocate following code point in the "SRP Object Flag Field" allocate following code point in the "SRP Object Flag Field"
skipping to change at page 9, line 5 skipping to change at page 8, line 50
of the LSPs at a particular PCE. of the LSPs at a particular PCE.
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.
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. 11 change blocks. 
11 lines changed or deleted 13 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/