Skip to main content

Updated Rules for PCEP Object Ordering
draft-dhody-pce-pcep-object-order-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Author Dhruv Dhody
Last updated 2021-10-19
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dhody-pce-pcep-object-order-00
PCE Working Group                                               D. Dhody
Internet-Draft                                       Huawei Technologies
Updates: 5440 (if approved)                              19 October 2021
Intended status: Standards Track                                        
Expires: 22 April 2022

                 Updated Rules for PCEP Object Ordering
                  draft-dhody-pce-pcep-object-order-00

Abstract

   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 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 22 April 2022.

Copyright Notice

   Copyright (c) 2021 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

Dhody                     Expires 22 April 2022                 [Page 1]
Internet-Draft   Updated Rules for PCEP Object Ordering     October 2021

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified 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.  Management Considerations . . . . . . . . . . . . . . . . . .   4
   7.  Other Efforts . . . . . . . . . . . . . . . . . . . . . . . .   4
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   4
     10.2.  Informative References . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   5
   Appendix B.  Examples . . . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

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.

Dhody                     Expires 22 April 2022                 [Page 2]
Internet-Draft   Updated Rules for PCEP Object Ordering     October 2021

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.

Dhody                     Expires 22 April 2022                 [Page 3]
Internet-Draft   Updated Rules for PCEP Object Ordering     October 2021

   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

   [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/info/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/info/rfc5440>.

Dhody                     Expires 22 April 2022                 [Page 4]
Internet-Draft   Updated Rules for PCEP Object Ordering     October 2021

   [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/info/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/info/rfc8174>.

10.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., 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,
              10 January 2014, <https://www.ietf.org/archive/id/draft-
              cmfg-pce-pcep-grammar-02.txt>.

   [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/info/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/info/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.

Dhody                     Expires 22 April 2022                 [Page 5]
Internet-Draft   Updated Rules for PCEP Object Ordering     October 2021

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

   or

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

   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
   India

   Email: dhruv.ietf@gmail.com

Dhody                     Expires 22 April 2022                 [Page 6]