< draft-ietf-pce-lsp-setup-type-08.txt   draft-ietf-pce-lsp-setup-type-09.txt >
PCE Working Group S. Sivabalan PCE Working Group S. Sivabalan
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track J. Tantsura Intended status: Standards Track J. Tantsura
Expires: July 19, 2018 Individual Expires: September 28, 2018 Individual
I. Minei I. Minei
Google, Inc. Google, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
J. Hardwick J. Hardwick
Metaswitch Networks Metaswitch Networks
January 15, 2018 March 27, 2018
Conveying path setup type in PCEP messages Conveying path setup type in PCEP messages
draft-ietf-pce-lsp-setup-type-08 draft-ietf-pce-lsp-setup-type-09
Abstract Abstract
A Path Computation Element can compute Traffic Engineering (TE) paths A Path Computation Element (PCE) can compute Traffic Engineering (TE)
through a network that are subject to various constraints. paths through a network that are subject to various constraints.
Currently, TE paths are Label Switched Paths (LSPs) which are set up Currently, TE paths are Label Switched Paths (LSPs) which are set up
using the RSVP-TE signaling protocol. However, other TE path setup using the RSVP-TE signaling protocol. However, other TE path setup
methods are possible within the PCE architecture. This document methods are possible within the PCE architecture. This document
proposes an extension to PCEP to allow support for different path proposes an extension to the PCE communication protocol (PCEP) to
setup methods over a given PCEP session. allow support for different path setup methods over a given PCEP
session.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 19, 2018. This Internet-Draft will expire on September 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 23 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4 3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4
4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5 4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Manageability Considerations . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.2. New Path Setup Type Registry . . . . . . . . . . . . . . 8 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 8
7.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 8 8.2. New Path Setup Type Registry . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element communication [RFC5440] describes the Path Computation Element communication
Protocol (PCEP) for communication between a Path Computation Client Protocol (PCEP) for communication between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between a PCE and a (PCC) and a Path Computation Element (PCE), or between a PCE and a
PCE. A PCC requests a path subject to various constraints and PCE. A PCC requests a path subject to various constraints and
optimization criteria from a PCE. The PCE responds to the PCC with a optimization criteria from a PCE. The PCE responds to the PCC with a
hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the
ERO to set up the path in the network. ERO to set up the path in the network.
skipping to change at page 5, line 38 skipping to change at page 5, line 47
CAPABILITY TLV in its OPEN object. CAPABILITY TLV in its OPEN object.
If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
TLV, it MUST ignore the TLV in accordance with ([RFC5440]). TLV, it MUST ignore the TLV in accordance with ([RFC5440]).
4. Path Setup Type TLV 4. Path Setup Type TLV
When a PCEP session is used to set up TE paths using different When a PCEP session is used to set up TE paths using different
methods, the corresponding PCE and PCC must be aware of the path methods, the corresponding PCE and PCC must be aware of the path
setup method used. That means, a PCE must be able to specify paths setup method used. That means, a PCE must be able to specify paths
in the correct format and a PCC must be able take control plane and in the correct format and a PCC must be able to take control plane
forwarding plane actions appropriate to the PST. and forwarding plane actions appropriate to the PST.
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 (28) | Length (4) | | Type (28) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PST | | Reserved | PST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PATH-SETUP-TYPE TLV Figure 2: PATH-SETUP-TYPE TLV
skipping to change at page 7, line 27 skipping to change at page 7, line 38
The PCC MUST include the SRP object in the PCRpt message if the PST The PCC MUST include the SRP object in the PCRpt message if the PST
is not RSVP-TE, even when the SRP-ID-number is the reserved value of is not RSVP-TE, even when the SRP-ID-number is the reserved value of
0x00000000. If the PCRpt message is triggered by a PCUpd or 0x00000000. If the PCRpt message is triggered by a PCUpd or
PCInitiate message, then the PST that the PCC indicates in the PCRpt PCInitiate message, then the PST that the PCC indicates in the PCRpt
MUST match the PST that the stateful PCE intended in the PCUpd or MUST match the PST that the stateful PCE intended in the PCUpd or
PCInitiate. If it does not, then the PCE MUST send a PCErr message PCInitiate. If it does not, then the PCE MUST send a PCErr message
with Error-Type = 21 (Invalid traffic engineering path setup type) with Error-Type = 21 (Invalid traffic engineering path setup type)
and Error-Value = 2 (Mismatched path setup type) and close the PCEP and Error-Value = 2 (Mismatched path setup type) and close the PCEP
session. session.
6. Security Considerations 6. Manageability Considerations
This document generalises PCEP to allow path setup methods other than
RSVP-TE to be used by the network. It is possible that, in a given
network, multiple path setup methods will be used. It is also
possible that not all devices will support the same set of path setup
methods. Managing networks that combine multiple path setup methods
may therefore raise some challenges from a configuration and
observability point of view.
Each document that introduces a new path setup type to PCEP must
include a manageability section. The manageability section must
explain how operators can manage PCEP with the new path setup type.
It must address the following questions, which are generally
applicable when working with multiple path setup types in PCEP.
o What are the criteria for when devices will use the new path setup
type in PCEP, and how can the operator control this?
o How can the network be migrated to the new path setup type, and
are there any backwards compatibility issues that operators need
to be aware of?
o Are paths set up using the new path setup type intended to coexist
with other paths over the long term and, if so, how is this
situation managed with PCEP?
o How can operators verify the correct operation of PCEP in the
network with respect to the new path setup type? Which fault
conditions must be reported to the operators?
o Are there any existing management interfaces (such as YANG models)
that must be extended to model the operation of PCEP in the
network with respect to the new path setup type?
See [RFC6123] for further guidance on how to write manageability
sections in PCEP standards-track documents.
7. Security Considerations
The security considerations described in [RFC5440] and [RFC8281] are The security considerations described in [RFC5440] and [RFC8281] are
applicable to this specification. No additional security measure is applicable to this specification. No additional security measure is
required. required.
7. IANA Considerations 8. IANA Considerations
7.1. PCEP TLV Type Indicators 8.1. PCEP TLV Type Indicators
IANA is requested to confirm the early allocation of the following IANA is requested to confirm the early allocation of the following
code point in the PCEP TLV Type Indicators registry. code point in the PCEP TLV Type Indicators registry.
Value Description Reference Value Description Reference
28 PATH-SETUP-TYPE This document 28 PATH-SETUP-TYPE This document
IANA is requested to allocate a new code point for the following TLV IANA is requested to allocate a new code point for the following TLV
in the PCEP TLV Type Indicators registry. in the PCEP TLV Type Indicators registry.
skipping to change at page 8, line 8 skipping to change at page 9, line 8
Value Description Reference Value Description Reference
TBD1 PATH-SETUP-TYPE-CAPABILITY This document TBD1 PATH-SETUP-TYPE-CAPABILITY This document
Note to IANA: The above TLV type was not part of the early code point Note to IANA: The above TLV type was not part of the early code point
allocation that was done for this draft. It was added to the draft allocation that was done for this draft. It was added to the draft
after the early code point allocation had taken place. Please assign after the early code point allocation had taken place. Please assign
a code point from the indicated registry and replace each instance of a code point from the indicated registry and replace each instance of
"TBD1" in this document with the allocated code point. "TBD1" in this document with the allocated code point.
7.2. New Path Setup Type Registry 8.2. New Path Setup Type Registry
IANA is requested to create a new sub-registry within the "Path IANA is requested to create a new sub-registry within the "Path
Computation Element Protocol (PCEP) Numbers" registry called "PCEP Computation Element Protocol (PCEP) Numbers" registry called "PCEP
Path Setup Types". The allocation policy for this new registry Path Setup Types". The allocation policy for this new registry
should be by IETF Consensus. The new registry should contain the should be by IETF Review. The new registry should contain the
following value: following value:
Value Description Reference Value Description Reference
0 Path is setup using the RSVP- This document 0 Path is setup using the RSVP- This document
TE signaling protocol. TE signaling protocol.
7.3. PCEP-Error Object 8.3. PCEP-Error Object
IANA is requested to confirm the early allocation of the following IANA is requested to confirm the early allocation of the following
code-points in the PCEP-ERROR Object Error Types and Values registry. code-points in the PCEP-ERROR Object Error Types and Values registry.
Error-Type Meaning Error-Type Meaning
10 Reception of an invalid object 10 Reception of an invalid object
Error-value=11: Malformed object Error-value=11: Malformed object
Error-Type Meaning Error-Type Meaning
skipping to change at page 8, line 44 skipping to change at page 9, line 44
Error-value=0: Unassigned Error-value=0: Unassigned
Error-value=1: Unsupported path setup type Error-value=1: Unsupported path setup type
Error-value=2: Mismatched path setup type Error-value=2: Mismatched path setup type
Note to IANA: the early allocation for Error-Type=10, Error-value=11 Note to IANA: the early allocation for Error-Type=10, Error-value=11
was originally done by draft-ietf-pce-segment-routing. However, we was originally done by draft-ietf-pce-segment-routing. However, we
have since moved its definition into this document. Therefore, have since moved its definition into this document. Therefore,
please update the reference for this Error-value in the indicated please update the reference for this Error-value in the indicated
registry to point to RFC.ietf-pce-lsp-setup-type. registry to point to RFC.ietf-pce-lsp-setup-type.
8. Contributors 9. Contributors
The following people contributed to this document: The following people contributed to this document:
- Jan Medved - Jan Medved
- Edward Crabbe - Edward Crabbe
9. Acknowledgements 10. Acknowledgements
We like to thank Marek Zavodsky for valuable comments. We like to thank Marek Zavodsky for valuable comments.
10. References 11. References
10.1. Normative References 11.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 9, line 35 skipping to change at page 10, line 35
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>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
10.2. Informative References 11.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>.
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>. 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123,
DOI 10.17487/RFC6123, February 2011,
<https://www.rfc-editor.org/info/rfc6123>.
Authors' Addresses Authors' Addresses
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Email: msiva@cisco.com Email: msiva@cisco.com
Jeff Tantsura Jeff Tantsura
Individual Individual
 End of changes. 21 change blocks. 
32 lines changed or deleted 78 lines changed or added

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