draft-ietf-pce-rfc7150bis-00.txt   draft-ietf-pce-rfc7150bis-01.txt 
Network Working Group Fatai Zhang Network Working Group Fatai Zhang
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track A. Farrel Intended status: Standards Track A. Farrel
Obsoletes: 7150 (if approved) Juniper Networks Obsoletes: 7150 (if approved) Juniper Networks
Expires: January 22, 2015 July 22, 2014 Expires: January 30, 2015 July 30, 2014
Conveying Vendor-Specific Constraints in the Path Conveying Vendor-Specific Constraints in the Path
Computation Element communication Protocol Computation Element communication Protocol
draft-ietf-pce-rfc7150bis-00.txt draft-ietf-pce-rfc7150bis-01.txt
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-Variable that in PCEP using a dedicated object and a new Type-Length-Value (TLV)
can be carried in any existing PCEP object. that can be carried in any PCEP object that supports TLVs.
This document obsoletes RFC 7150. The only change from that document This document obsoletes RFC 7150. The only changes from that
is the allocation of a different code point for the document are a clarification of the use of the new Type-Length-Value
VENDOR-INFORMATION object. and the allocation of a different code point for the VENDOR-
INFORMATION object.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 3, line 20 skipping to change at page 3, line 20
has scope for the definition of new, standardized metrics, but no has scope for the definition of new, standardized metrics, but no
facility for the definition of vendor-specific metrics. At the same facility for the definition of vendor-specific metrics. At the same
time, there is no mechanism in PCEP for carrying other, more complex, time, there is no mechanism in PCEP for carrying other, more complex,
vendor-specific information. vendor-specific information.
This document defines a new PCEP object, the Vendor Information This document defines a new PCEP object, the Vendor Information
object that can be used to carry arbitrary, proprietary information object that can be used to carry arbitrary, proprietary information
such as vendor-specific constraints. such as vendor-specific constraints.
This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV
that can be used to carry arbitrary information within any PCEP that can be used to carry arbitrary information within any existing
object that supports TLVs. or future PCEP object that supports TLVs.
It should be noted that by the very definition of "vendor-specific", It should be noted that by the very definition of "vendor-specific",
the inclusion of either a Vendor Information object or the VENDOR- the inclusion of either a Vendor Information object or the VENDOR-
INFORMATION-TLV implies an inability to interoperate at a functional INFORMATION-TLV implies an inability to interoperate at a functional
level with implementations from other vendors unless there is some level with implementations from other vendors unless there is some
cooperation agreement between vendors. Sections 2.1 and 3.1 discuss cooperation agreement between vendors. Sections 2.1 and 3.1 discuss
backward compatibility, which indicates how these protocol constructs backward compatibility, which indicates how these protocol constructs
are handled by implementations that do not support them at all, while are handled by implementations that do not support them at all, while
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 moving it out of the vendor-specific space.
This document obsoletes RFC 7150. The only change from that document This document obsoletes RFC 7150 making two changes to that document:
is the allocation of a different code point for the - Clarification that the TLV is available for use in any PCEP object
VENDOR-INFORMATION object. This change became necessary because of (existing or future) that supports TLVs.
an inadvertant clash with codepoints used in another Internet-Draft - The allocation of a different code point for the VENDOR-INFORMATION
that had been deployed without IANA allocation. The PCE working object. This change became necessary because of an inadvertant
group has conducted a survey of implementations and deployments of clash with codepoints used in another Internet-Draft that had been
RFC 7150 and considers that this change is safe and does not harm deployed without IANA allocation. The PCE working group has
early implementers of RFC 7150. 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 12, line 25 skipping to change at page 12, line 25
Hardwick, "Path Computation Element Protocol (PCEP) Hardwick, "Path Computation Element Protocol (PCEP)
Management Information Base", Work in Progress, February Management Information Base", Work in Progress, February
2014. 2014.
9. Acknowledgements 9. 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
point and to Dhruv Dhody for helping clarify the use of the TLV.
10. Contributors 10. 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
 End of changes. 7 change blocks. 
17 lines changed or deleted 23 lines changed or added

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