Internet-Draft Updated Rules for PCEP Object Ordering October 2021
Dhody Expires 22 April 2022 [Page]
PCE Working Group
5440 (if approved)
Intended Status:
Standards Track
D. Dhody
Huawei Technologies

Updated Rules for PCEP Object Ordering


The 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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months 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."

This Internet-Draft will expire on 22 April 2022.

Table of Contents

1. Introduction

[RFC5440] 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.

[RFC5440] defines several PCEP messages. For each PCEP message type, rules are defined that specify the set of objects that the message can carry using [RFC5511]. Further, [RFC5440] 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 [EID6627]).

This document updates [RFC5440] to relax the strict object ordering requirement.

2. Conventions

The 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Motivation

The mandatory object ordering requirement in [RFC5440] 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.

4. Update to RFC 5440

Section 6 of [RFC5440] states:

   An implementation MUST form the PCEP
   messages using the object ordering specified in this document.

This text is updated to read as follows:

   An implementation SHOULD form the PCEP
   messages using the object ordering specified in this and
   subsequent documents when an ordering can be unambiguously
   determined; an implementation MUST be prepared to receive
   a PCEP message with objects in any order.

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.

5. Compatibility Considerations

While 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 [RFC5440] 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 Section 4. 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 [RFC5440] does not define an Error-Type and Error-value corresponding to this error condition.

6. Management Considerations

Implementations receiving set objects that they consider out of order MAY log this. That could be helpful for diagnosing backward compatibility issues.

7. Other Efforts

In the past there have been effort to consolidate and update the RBNF such as in [I-D.cmfg-pce-pcep-grammar]. 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.

8. Security Considerations

This document does not raise any security issues.

9. IANA Considerations

This document does not require any IANA actions.

10. References

10.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <>.
Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

10.2. Informative References

"Errata ID: 6627", n.d., <>.
Casellas, R., Margaria, C., Farrel, A., Dios, O. G. D., Dhody, D., and X. Zhang, "Current issues with existing RBNF notation for PCEP messages and extensions", Work in Progress, Internet-Draft, draft-cmfg-pce-pcep-grammar-02, , <>.
Sivabalan, S., Ed., Parker, J., Boutros, S., and K. Kumaki, "Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol", RFC 5455, DOI 10.17487/RFC5455, , <>.
Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, , <>.

Appendix A. Acknowledgments

Thanks 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 [I-D.cmfg-pce-pcep-grammar] for highlighting the issue.

Appendix B. Examples

As described in [EID6627], for the PCReq message, the CLASSTYPE object is encoded after the END-POINTS object in [RFC5455]. Where as in [RFC8231], 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.

Author's Address

Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore 560066