Updated Rules for PCE Communication Protocol (PCEP) Object Ordering
Internet-Draft draft-dhody-pce-pcep-object-order-06
Dhruv Dhody
Huawei
IN
dhruv.ietf@gmail.com
Routing
PCE Working Group
The PCE Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a PCE, or among PCEs. Such interactions 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
[RFC5440] describes the PCE Communication Protocol (PCEP). PCEP defines the communication between a Path Computation Client (PCC) and a 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 Routing Backus-Naur Form (RBNF) [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.
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.
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 of the previously published RFCs, and all concurrently work in progress in the form of the internet-drafts. This requirement does not lend itself to the extensibility of PCEP.
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 when possible.

This update does not aim to take away the object ordering completely. The PCEP speaker is expected to follow the object order as specified unless there are valid reasons to ignore it. It is also likely that the receiver can understand the object's meaning irrespective of the order unambiguously.
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 behaviour 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 behaviours 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.
Open Questions
- Should a new flag or a TLV in Open Message be added to exchange this capability? Not sure if this is strictly needed if we can live with Section 5.
Management Considerations
Implementations receiving set objects that they consider out of order MAY log this. That could be helpful for diagnosing backward compatibility issues.
Other Efforts
In the past, there have been efforts 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. There have been proposals to consolidate the RBNF for the PCEP message in a single place in GitHub and use modern data modelling tools to represent PCEP extensions. They might be taken up in parallel.
Security Considerations
This document does not raise any security issues.
IANA Considerations
This document does not require any IANA actions.
References
Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC5440]

Path Computation Element (PCE) Communication Protocol (PCEP)
JP. Vasseur, Ed.
JL. Le Roux, Ed.
March 2009
RFC 5440
DOI 10.17487/RFC5440
[RFC5511]

Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications
A. Farrel
April 2009
RFC 5511
DOI 10.17487/RFC5511
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC5455]

Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol
S. Sivabalan, Ed.
J. Parker
S. Boutros
K. Kumaki
March 2009
RFC 5455
DOI 10.17487/RFC5455
[RFC8231]

Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
E. Crabbe
I. Minei
J. Medved
R. Varga
September 2017
RFC 8231
DOI 10.17487/RFC8231
[I-D.cmfg-pce-pcep-grammar]

Current issues with existing RBNF notation for PCEP messages and extensions
Ramon Casellas
CTTC
Cyril Margaria
Coriant
Adrian Farrel
Old Dog Consulting
Oscar Gonzalez de Dios
Dhruv Dhody
Huawei Technologies
Xian Zhang
Huawei Technologies
10 January 2014
Internet-Draft draft-cmfg-pce-pcep-grammar-02
[EID6627]

Errata ID: 6627
n.d.
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.
Examples
As described in [EID6627], for the PCReq message, the CLASSTYPE object is encoded after the END-POINTS object in [RFC5455]. Whereas in [RFC8231], the LSP object is encoded just after the END-POINTS object. So it is not known which of the below orders is expected.

...<END-POINTS>[<LSP>][<CLASSTYPE>]...

or

...<END-POINTS>[<CLASSTYPE>][<LSP>]...

This update requires the receiver to be able to accept both of these.
When Order Matters
There are cases where the ordering between objects is important. For instance, PCRpt message [RFC8231] includes <path> with some attributes that say BANDWIDTH can be part of both <actual-attribute-list> and <intended-attribute-list>.

    Where:
      <path>::= <intended-path>
                [<actual-attribute-list><actual-path>]
                <intended-attribute-list>

An important factor to distinguish between the actual and intended attribute list is the presence of RRO (i.e. <actual-path>) and the order of objects in the PCRpt message.
If the RRO is present, any attributes encoded before it, are to be considered as part of <actual-attribute-list> and those after it, as part of <intended-attribute-list>.
If the RRO is absent, all attributes are part of <intended-attribute-list>.
Thus the approach taken by this document is to say that ordering is relaxed in cases where there is no ambiguity.