draft-ietf-pce-rfc7150bis-01.txt   rfc7470.txt 
Network Working Group Fatai Zhang Internet Engineering Task Force (IETF) F. Zhang
Internet-Draft Huawei Request for Comments: 7470 Huawei
Intended status: Standards Track A. Farrel Obsoletes: 7150 A. Farrel
Obsoletes: 7150 (if approved) Juniper Networks Category: Standards Track Juniper Networks
ISSN: 2070-1721 March 2015
Expires: January 30, 2015 July 30, 2014
Conveying Vendor-Specific Constraints in the Path
Computation Element communication Protocol
draft-ietf-pce-rfc7150bis-01.txt Conveying Vendor-Specific Constraints
in the Path Computation Element Communication Protocol
Abstract Abstract
The Path Computation Element communication Protocol (PCEP) is used to The Path Computation Element Communication Protocol (PCEP) is used to
convey path computation requests and responses both between Path convey path computation requests and responses both between Path
Computation Clients (PCCs) and Path Computation Elements (PCEs) and Computation Clients (PCCs) and Path Computation Elements (PCEs) and
between cooperating PCEs. In PCEP, the path computation requests between cooperating PCEs. In PCEP, the path computation requests
carry details of the constraints and objective functions that the PCC carry details of the constraints and objective functions that the PCC
wishes the PCE to apply in its computation. wishes the PCE to apply in its computation.
This document defines a facility to carry vendor-specific information This document defines a facility to carry vendor-specific information
in PCEP using a dedicated object and a new Type-Length-Value (TLV) in PCEP using a dedicated object and a new Type-Length-Value (TLV)
that can be carried in any PCEP object that supports TLVs. that can be carried in any PCEP object that supports TLVs.
This document obsoletes RFC 7150. The only changes from that This document obsoletes RFC 7150. The only changes from that
document are a clarification of the use of the new Type-Length-Value document are a clarification of the use of the new Type-Length-Value
and the allocation of a different code point for the VENDOR- and the allocation of a different code point for the VENDOR-
INFORMATION object. INFORMATION object.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7470.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Procedures for the Vendor Information Object ....................5
2.1. Backward Compatibility for the Vendor Information Object ...7
3. Procedures for the Vendor Information TLV .......................7
3.1. Backward Compatibility .....................................8
4. Protocol Elements ...............................................8
5. IANA Considerations .............................................9
5.1. New PCEP Object ............................................9
5.2. New PCEP TLV ...............................................9
6. Management Considerations ......................................10
6.1. Control of Function and Policy ............................10
6.2. Information and Data Models ...............................10
6.3. Liveness Detection and Monitoring .........................10
6.4. Verifying Correct Operation ...............................10
6.5. Requirements on Other Protocols and Functional Components .11
6.6. Impact on Network Operation ...............................11
7. Security Considerations ........................................11
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................12
Acknowledgements ..................................................14
Contributors ......................................................14
Authors' Addresses ................................................14
1. Introduction 1. Introduction
A Path Computation Element (PCE) is an entity (component, A Path Computation Element (PCE) is an entity (component,
application, or network node) that is capable of computing a network application, or network node) that is capable of computing a network
path or route based on a network graph and applying computational path or route based on a network graph and applying computational
constraints. An architecture for the use of PCEs is defined in constraints. An architecture for the use of PCEs is defined in
[RFC4655]. [RFC4655].
The Path Computation Element communication Protocol (PCEP) is defined The Path Computation Element Communication Protocol (PCEP) is defined
in [RFC5440] to exchange path computation requests and responses in [RFC5440] to exchange path computation requests and responses
between Path Computation Clients (PCCs) and PCEs. It is also used between Path Computation Clients (PCCs) and PCEs. It is also used
between cooperating PCEs. between cooperating PCEs.
Path computations performed by a PCE depend on a set of constraints Path computations performed by a PCE depend on a set of constraints
indicated by the PCC. These constraints include the endpoints of the indicated by the PCC. These constraints include the endpoints of the
path to compute (source and destination) and may include other simple path to compute (source and destination) and may include other simple
constraints such as bandwidth requirements and metric maxima (for constraints such as bandwidth requirements and metric maxima (for
example, a maximum threshold for the hop count or the Traffic example, a maximum threshold for the hop count or the Traffic
Engineering (TE) metric of the computed path). Engineering (TE) metric of the computed path).
skipping to change at page 3, line 40 skipping to change at page 4, line 26
text in Sections 2 and 3 describe how implementations handle the text in Sections 2 and 3 describe how implementations handle the
constructs if they understand them, but do not support the embedded constructs if they understand them, but do not support the embedded
Enterprise Number that indicates to which vendor the constructs Enterprise Number that indicates to which vendor the constructs
apply. apply.
When vendor-specific information is used by an implementation, the When vendor-specific information is used by an implementation, the
vendor is encouraged to document the meaning of the information to vendor is encouraged to document the meaning of the information to
encourage wider use and implementation. In particular, when there is encourage wider use and implementation. In particular, when there is
more general interest in a vendor-specific extension, the vendor is more general interest in a vendor-specific extension, the vendor is
encouraged to bring it to the IETF for standardization as a regular encouraged to bring it to the IETF for standardization as a regular
protocol construct moving it out of the vendor-specific space. protocol construct, thereby moving it out of the vendor-specific
space.
This document obsoletes RFC 7150 making two changes to that document: This document obsoletes RFC 7150 [RFC7150], making two changes to
- Clarification that the TLV is available for use in any PCEP object that document:
(existing or future) that supports TLVs.
- The allocation of a different code point for the VENDOR-INFORMATION - Clarification that the TLV is available for use in any PCEP object
object. This change became necessary because of an inadvertant (existing or future) that supports TLVs.
clash with codepoints used in another Internet-Draft that had been
deployed without IANA allocation. The PCE working group has - The allocation of a different code point for the
conducted a survey of implementations and deployments of RFC 7150 VENDOR-INFORMATION object. This change became necessary because
and considers that this change is safe and does not harm early of an inadvertent clash with codepoints used in an Internet-Draft
implementers of RFC 7150. that had been deployed without IANA allocation. The PCE working
group has conducted a survey of implementations and deployments of
RFC 7150 and considers that this change is safe and does not harm
early implementers of RFC 7150.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
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 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Procedures for the Vendor Information Object 2. Procedures for the Vendor Information Object
skipping to change at page 7, line 20 skipping to change at page 8, line 26
A legacy implementation that does not recognize the Vendor A legacy implementation that does not recognize the Vendor
Information TLV in an object will act according to the procedures set Information TLV in an object will act according to the procedures set
out in [RFC5440]. As described in Section 7.1 of [RFC5440], out in [RFC5440]. As described in Section 7.1 of [RFC5440],
unrecognized TLVs MUST be ignored. unrecognized TLVs MUST be ignored.
4. Protocol Elements 4. Protocol Elements
The Vendor Information object and TLV conform to the format for PCEP The Vendor Information object and TLV conform to the format for PCEP
objects and TLVs defined in [RFC5440]. objects and TLVs defined in [RFC5440].
VENDOR-INFORMATION Object-Class xx (TBA by IANA) VENDOR-INFORMATION Object-Class 34
VENDOR-INFORMATION Object-Type 1 VENDOR-INFORMATION Object-Type 1
VENDOR-INFORMATION-TLV Type 7 VENDOR-INFORMATION-TLV Type 7
The format of the VENDOR-INFORMATION object and the format of the The format of the VENDOR-INFORMATION object and the format of the
VENDOR-INFORMATION-TLV are the same and are as shown in Figure 1. VENDOR-INFORMATION-TLV are the same and are as shown in Figure 1.
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
skipping to change at page 8, line 16 skipping to change at page 9, line 23
organization can use the information. organization can use the information.
5. IANA Considerations 5. IANA Considerations
IANA maintains a registry of PCEP parameters called the "Path IANA maintains a registry of PCEP parameters called the "Path
Computation Element Protocol (PCEP) Numbers". Computation Element Protocol (PCEP) Numbers".
5.1. New PCEP Object 5.1. New PCEP Object
IANA had previously allocated the value 32 from the "PCEP Objects" IANA had previously allocated the value 32 from the "PCEP Objects"
subregistry for use as the VENDOR-INFORMATION object. subregistry for use as the VENDOR-INFORMATION object. IANA has
released that value and marked it as "Unassigned".
IANA is requested to release that value and mark it as unassigned.
IANA is requested to assign a new value as follows. IANA is IANA has assigned a new value as follows.
requested to assign the value 34.
Object-Class Value Name Reference Object-Class Value Name Reference
xx VENDOR-INFORMATION [This.I-D] 34 VENDOR-INFORMATION RFC 7470
Object-Type Object-Type
0: Unassigned 0: Unassigned
1: Vendor-Specific Constraints [This.I-D] 1: Vendor-Specific Constraints RFC 7470
2-255: Unassigned 2-15: Unassigned
5.2. New PCEP TLV 5.2. New PCEP TLV
IANA has made an allocation from the "PCEP TLV Type Indicators" IANA had made an allocation from the "PCEP TLV Type Indicators"
subregistry as follows. subregistry, where RFC 7150 was the reference. IANA has updated the
reference as follows to point to this document.
Value Description Reference Value Description Reference
7 VENDOR-INFORMATION-TLV [RFC7150] 7 VENDOR-INFORMATION-TLV RFC 7470
IANA is requested to update the reference to point to this document.
6. Management Considerations 6. Management Considerations
This section follows the guidance of [RFC5706] and [RFC6123]. This section follows the guidance of [RFC5706] and [RFC6123].
6.1. Control of Function and Policy 6.1. Control of Function and Policy
A PCEP implementation SHOULD allow configuring of various parameters A PCEP implementation SHOULD allow configuring of various parameters
as described in [RFC5440]. A PCC implementation that uses vendor- as described in [RFC5440]. A PCC implementation that uses vendor-
specific information MAY make the use of this information specific information MAY make the use of this information
configurable either across the whole PCC, per PCE that the PCC uses, configurable either across the whole PCC, per PCE that the PCC uses,
or per path computation request. A PCE that supports vendor-specific or per path computation request. A PCE that supports vendor-specific
information MAY make the support of this information configurable, information MAY make the support of this information configurable,
and MAY allow configuration of policies for the use of the and MAY allow configuration of policies for the use of the
information. information.
6.2. Information and Data Models 6.2. Information and Data Models
A PCEP MIB module is defined in [PCE-MIB] that describes managed A PCEP MIB module is defined in [RFC7420] that describes managed
objects for modeling of PCEP communications. objects for modeling of PCEP communications.
It is NOT RECOMMENDED that standard MIB modules be extended to It is NOT RECOMMENDED that standard MIB modules be extended to
include detailed information about the content of the Vendor include detailed information about the content of the Vendor
Information object or TLV. However, the standard MIB module MAY be Information object or TLV. However, the standard MIB module MAY be
extended to report the use of the Vendor Information object or TLV extended to report the use of the Vendor Information object or TLV
and the Enterprise Numbers that the objects and TLVs contain. and the Enterprise Numbers that the objects and TLVs contain.
6.3. Liveness Detection and Monitoring 6.3. Liveness Detection and Monitoring
skipping to change at page 10, line 41 skipping to change at page 12, line 10
processing power. The Vendor Information object and TLV may provide processing power. The Vendor Information object and TLV may provide
a vector for this type of attack. It may be protected against by a vector for this type of attack. It may be protected against by
using the authentication and integrity procedures described in using the authentication and integrity procedures described in
[RFC5440]. [RFC5440].
8. References 8. References
8.1. Normative References 8.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://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,
March 2009. March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009. Specifications", RFC 5511, April 2009,
<http://www.rfc-editor.org/info/rfc5511>.
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T.,
Ali, Z., and J. Meuric, "Extensions to the Path Ali, Z., and J. Meuric, "Extensions to the Path
Computation Element Communication Protocol (PCEP) for Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC 6006, September 2010. Paths", RFC 6006, September 2010,
<http://www.rfc-editor.org/info/rfc6006>.
8.2. Informative References 8.2. Informative References
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999,
<http://www.rfc-editor.org/info/rfc2578>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006. August 2006, <http://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, September 2006. Requirements", RFC 4657, September 2006,
<http://www.rfc-editor.org/info/rfc4657>.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "OSPF Protocol Extensions for Path Computation Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, January 2008. Element (PCE) Discovery", RFC 5088, January 2008,
<http://www.rfc-editor.org/info/rfc5088>.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, January 2008. Element (PCE) Discovery", RFC 5089, January 2008,
<http://www.rfc-editor.org/info/rfc5089>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009. Communication Protocol (PCEP)", RFC 5541, June 2009,
<http://www.rfc-editor.org/info/rfc5541>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", RFC Management of New Protocols and Protocol Extensions", RFC
5706, November 2009. 5706, November 2009,
<http://www.rfc-editor.org/info/rfc5706>.
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path
Computation Element (PCE) Working Group Drafts", RFC 6123, Computation Element (PCE) Working Group Drafts", RFC 6123,
February 2011. February 2011, <http://www.rfc-editor.org/info/rfc6123>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013. Guide", RFC 6952, May 2013,
<http://www.rfc-editor.org/info/rfc6952>.
[RFC7150] Zhang, F. and A. Farrel, "Conveying Vendor-Specific [RFC7150] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication Constraints in the Path Computation Element Communication
Protocol", RFC 7150, March 2014. Protocol", RFC 7150, March 2014,
<http://www.rfc-editor.org/info/rfc7150>.
[PCE-MIB] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Protocol (PCEP) Hardwick, "Path Computation Element Communication Protocol
Management Information Base", Work in Progress, February (PCEP) Management Information Base (MIB) Module", RFC
2014. 7420, December 2014,
<http://www.rfc-editor.org/info/rfc7420>.
9. Acknowledgements Acknowledgements
Thanks to Meral Shirazipour, Ramon Casellas, Cyril Margaria, Dhruv Thanks to Meral Shirazipour, Ramon Casellas, Cyril Margaria, Dhruv
Dhody, Julien Meuric, and Robert Sparks for review and comments on Dhody, Julien Meuric, and Robert Sparks for review and comments on
the work that became RFC 7150. the work that became RFC 7150.
Thanks to Robert Varga for raising the issue of the clashing code Thanks to Robert Varga for raising the issue of the clashing code
point and to Dhruv Dhody for helping clarify the use of the TLV. point and to Dhruv Dhody for helping clarify the use of the TLV.
10. Contributors Contributors
Greg Bernstein Greg Bernstein
Grotto Networking Grotto Networking
EMail: gregb@grotto-networking.com EMail: gregb@grotto-networking.com
Ina Minei Ina Minei
Juniper Networks Juniper Networks
EMail: ina@juniper.net EMail: ina@juniper.net
Authors' Addresses Authors' Addresses
 End of changes. 40 change blocks. 
78 lines changed or deleted 109 lines changed or added

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