Updated Rules for PCEP Object OrderingHuawei TechnologiesDivyashree Techno Park, WhitefieldBangalore560066INdhruv.ietf@gmail.comPCE Working GroupThe Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. Such interactions include include path computation requests and path computation replies defined in RFC 5440. As per RFC 5440, these message are required to follow strict object ordering.This document updates RFC 5440 by relaxing the strict object ordering requirement in the PCEP messages.Introduction describes the Path Computation Element Communication Protocol (PCEP). PCEP defines the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCEs, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics. defines several PCEP messages. For each PCEP message type, rules are defined that specify the set of objects that the message can carry using . Further, states that the object ordering is mandatory. This causes confusion when multiple extensions add new objects in the PCEP messages and the respective order of these new objects is not specified (see ).This document updates to relax the strict object ordering requirement.ConventionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.MotivationThe mandatory object ordering requirement in is shown to result in exponential complexity in terms of what each new PCEP extension needs to cope with in terms of reconciling all previously-published RFCs, and all concurrently work in progress internet drafts. This requirement does not lend itself for extensibility of PCEP.Update to RFC 5440 states:This text is updated to read as follows:This update does not aim to take away the object ordering completely. It is expected that the PCEP speaker will follow the object order as specified unless there are valid reasons to ignore. It is also expected that the receiver is able to unambiguously understand the object meaning irrespective of the order.TODO: Scan all PCEP extensions to see if any other text needs to be updated related to object ordering.Compatibility ConsiderationsWhile one of the main objectives of the changes made by this document is to enable backward compatibility between PCEP extensions, there remains an issue of compatibility between existing implementations of and implementations that are consistent with this document.It should be noted that common behavior for checking object ordering in received PCEP messages is as described by the updated text presented in . Thus, many implementations, will still have implemented a consistent and future-proof approach. However, for completeness, it is worth noting how behaviors might interact between implementations.The messages generated by an implementation of this document when received by a legacy implementation with a strict interpretation of object ordering MAY lead to error handling. It is interesting to note that the does not define an Error-Type and Error-value corresponding to this error condition.Management ConsiderationsImplementations receiving set objects that they consider out of order MAY log this. That could be helpful for diagnosing backward compatibility issues.Other EffortsIn the past there have been effort to consolidate and update the RBNF such as in . This document document relaxes the object ordering only, it does not take on the various other issues or the need to consolidate the RBNF for all PCEP extensions. They might be taken up in parallel.Security ConsiderationsThis document does not raise any security issues.IANA ConsiderationsThis document does not require any IANA actions.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Path Computation Element (PCE) Communication Protocol (PCEP)This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol SpecificationsSeveral protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Diffserv-Aware Class-Type Object for the Path Computation Element Communication ProtocolThis document specifies a CLASSTYPE object to support Diffserv-Aware Traffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE). [STANDARDS-TRACK]Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCEThe Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.Current issues with existing RBNF notation for PCEP messages and extensions The PCEP protocol has been defined in [RFC5440] and later extended in
several RFCs. This document aims at documenting inconsistencies when
implementing a set of extensions and at providing a reference,
complete and formal RBNF grammar for PCEP messages, including object
ordering and precedence rules.
Errata ID: 6627AcknowledgmentsThanks to John Scudder for the motivation behind this document. Thanks to Oscar Gonzalez de Dios and Cyril Margaria for raising errata on this topic. Thanks to the author of for highlighting the issue.ExamplesAs described in , for the PCReq message, the CLASSTYPE object is encoded after the END-POINTS object in . Where as in , the LSP object is encoded just after the END-POINTS object. So it is not known which of the below order is expected.This update require the receiver to be able to except both of these.