draft-ietf-pce-lsp-control-request-06.txt   draft-ietf-pce-lsp-control-request-07.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: December 27, 2019 J. Karthik Expires: February 1, 2020 J. Karthik
S. Sivabalan S. Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
M. Negi M. Negi
Huawei Technologies Huawei Technologies
June 25, 2019 July 31, 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-06 draft-ietf-pce-lsp-control-request-07
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 December 27, 2019. This Internet-Draft will expire on February 1, 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 40 skipping to change at page 2, line 40
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 . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Stateful Path Computation Element (PCE) communication Protocol (PCEP) Stateful Path Computation Element (PCE) communication Protocol (PCEP)
extensions [RFC8231] specifies a set of extensions to PCEP [RFC5440] extensions [RFC8231] specifies a set of extensions to PCEP [RFC5440]
to enable stateful control of Traffic Engineering Label Switched to enable stateful control of Traffic Engineering Label Switched
skipping to change at page 4, line 7 skipping to change at page 4, line 7
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].
2. Terminology 2. Terminology
The following terminologies are used in this document: This document uses the following terms defined in [RFC5440]:
PCC: Path Computation Client. PCC: Path Computation Client.
PCE: Path Computation Element PCE: Path Computation Element.
PCEP: Path Computation Element communication Protocol. PCEP: Path Computation Element communication Protocol.
PCRpt: Path Computation State Report message. This document uses the following terms defined in [RFC8231]:
PCUpd: Path Computation Update Request message. PCRpt: Path Computation State Report message.
PLSP-ID: A PCEP-specific identifier for the LSP. PCUpd: Path Computation Update Request message.
PLSP-ID: A PCEP-specific identifier for the LSP.
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
skipping to change at page 7, line 50 skipping to change at page 8, line 4
and [RFC8231] apply to PCEP protocol extensions defined in this and [RFC8231] apply to PCEP protocol extensions defined in this
document. In addition, requirements and considerations listed in document. In addition, requirements and considerations listed in
this section apply. this section apply.
8.1. Control of Function and Policy 8.1. Control of Function and Policy
A PCC implementation SHOULD allow the operator to configure the A PCC implementation SHOULD allow the operator to configure the
policy based on which it honors the request to control the LSPs. policy based on which it honors the request to control the LSPs.
This includes the handling of the case where an LSP control request This includes the handling of the case where an LSP control request
is received for an LSP that is currently delegated to some other PCE. is received for an LSP that is currently delegated to some other PCE.
A PCC implementation SHOULD also allow the operator to configure the A PCC implementation SHOULD also allow the operator to configure the
threshold rate based on which it accepts the delegation requests from threshold rate based on which it accepts the delegation requests from
the PCE. Further, the operator MAY be to be allowed to trigger the the PCE. Further, the operator MAY be allowed to trigger the LSP
LSP control request for a particular LSP at the PCE. A PCE control request for a particular LSP at the PCE. A PCE
implementation SHOULD also allow the operator to configure an implementation SHOULD also allow the operator to configure an
exponentially increasing timer to retry the control requests for exponentially increasing timer to retry the control requests for
which the PCE did not get a response. which the PCE did not get a response.
8.2. Information and Data Models 8.2. Information and Data Models
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
include mechanism to trigger the LSP control request. include mechanism to trigger the LSP control request.
8.3. Liveness Detection and Monitoring 8.3. Liveness Detection and Monitoring
skipping to change at page 8, line 44 skipping to change at page 8, line 47
Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP
extensions defined in this document. Further, the mechanism extensions defined in this document. Further, the mechanism
described in this document can help the operator to request control described in this document can help the operator to request control
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 and Haomian Zheng for the review comments. Thanks to Adrian Farrel, Haomian Zheng and Tomonori Takeda for their
valuable comments.
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
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,
skipping to change at page 10, line 20 skipping to change at page 10, line 20
[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>.
[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-11 (work in progress), March 2019. yang-12 (work in progress), July 2019.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
skipping to change at page 12, line 26 skipping to change at page 12, line 26
Canada Canada
EMail: msiva@cisco.com EMail: msiva@cisco.com
Mahendra Singh Negi Mahendra Singh Negi
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: mahendrasingh@huawei.com EMail: mahend.ietf@gmail.com
 End of changes. 18 change blocks. 
16 lines changed or deleted 21 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/