Internet DRAFT - draft-dhody-pce-pcep-object-order
draft-dhody-pce-pcep-object-order
PCE Working Group D. Dhody
Internet-Draft Huawei
Updates: 5440 (if approved) 31 December 2023
Intended status: Standards Track
Expires: 3 July 2024
Updated Rules for PCE Communication Protocol (PCEP) Object Ordering
draft-dhody-pce-pcep-object-order-05
Abstract
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.
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 https://datatracker.ietf.org/drafts/current/.
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 3 July 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Dhody Expires 3 July 2024 [Page 1]
Internet-Draft object-order December 2023
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Update to RFC 5440 . . . . . . . . . . . . . . . . . . . . . 3
5. Compatibility Considerations . . . . . . . . . . . . . . . . 3
6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 4
7. Management Considerations . . . . . . . . . . . . . . . . . . 4
8. Other Efforts . . . . . . . . . . . . . . . . . . . . . . . . 4
9. Security Considerations . . . . . . . . . . . . . . . . . . . 4
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
11.1. Normative References . . . . . . . . . . . . . . . . . . 4
11.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 6
Appendix C. When Order Matters . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. 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.
Dhody Expires 3 July 2024 [Page 2]
Internet-Draft object-order December 2023
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 of the
previously-published RFCs, and all concurrently work in progress in
the form of the internet-drafts. This requirement does not lend
itself for the 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 when possible.
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.
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
Dhody Expires 3 July 2024 [Page 3]
Internet-Draft object-order December 2023
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. 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.
7. Management Considerations
Implementations receiving set objects that they consider out of order
MAY log this. That could be helpful for diagnosing backward
compatibility issues.
8. 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. There have been proposal to consolidate the RBNF for the
PCEP message in a single place in GitHub and use modern data modeling
tools to represent PCEP extensions. They might be taken up in
parallel.
9. Security Considerations
This document does not raise any security issues.
10. IANA Considerations
This document does not require any IANA actions.
11. References
11.1. Normative References
Dhody Expires 3 July 2024 [Page 4]
Internet-Draft object-order December 2023
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/rfc/rfc5440>.
[RFC5511] 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, April
2009, <https://www.rfc-editor.org/rfc/rfc5511>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
11.2. Informative References
[EID6627] "Errata ID: 6627", n.d.,
<https://www.rfc-editor.org/errata/eid6627>.
[I-D.cmfg-pce-pcep-grammar]
Casellas, R., Margaria, C., Farrel, A., de Dios, O. G.,
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,
10 January 2014, <https://datatracker.ietf.org/doc/html/
draft-cmfg-pce-pcep-grammar-02>.
[RFC5455] 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, March 2009,
<https://www.rfc-editor.org/rfc/rfc5455>.
[RFC8231] 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, September 2017,
<https://www.rfc-editor.org/rfc/rfc8231>.
Dhody Expires 3 July 2024 [Page 5]
Internet-Draft object-order December 2023
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.
...<END-POINTS>[<LSP>][<CLASSTYPE>]...
or
...<END-POINTS>[<CLASSTYPE>][<LSP>]...
This update require the receiver to be able to except both of these.
Appendix C. When Order Matters
There are cases where the ordering between objects is important. For
instance PCRpt message [RFC8231] includes <path> with some attributes
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.
Dhody Expires 3 July 2024 [Page 6]
Internet-Draft object-order December 2023
Author's Address
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Dhody Expires 3 July 2024 [Page 7]
