Extension for Stateful PCE to allow Optional Processing of PCEP Objects
draft-dhody-pce-stateful-pce-optional-05

Abstract

This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints. The introduction of relaxation in this document updates RFC8231.

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 July 14, 2020.

Copyright Notice

Copyright (c) 2020 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 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
• 1.1. Requirements Language
• 2. Overview
• 2.1. Usage Example
• 3. PCEP Extension
• 3.1. STATEFUL-PCE-CAPABILITY TLV
• 3.2. Handling of P flag
• 3.2.1. The PCRpt message
• 3.2.2. The PCUpd message and the PCInitiate message
• 3.3. Handling of I flag
• 3.3.1. The PCUpd message
• 3.3.2. The PCRpt message
• 3.3.3. The PCInitiate message
• 3.4. Delegation
• 3.5. Unknown Object Handling
• 4. Security Considerations
• 5. IANA Considerations
• 5.1. STATEFUL-PCE-CAPABILITY TLV
• 6. Manageability Considerations
• 6.1. Control of Function and Policy
• 6.2. Information and Data Models
• 6.3. Liveness Detection and Monitoring
• 6.4. Verify Correct Operations
• 6.5. Requirements On Other Protocols
• 6.6. Impact On Network Operations
• 7. Acknowledgments
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A. Contributors
• Authors' Addresses

1. Introduction

[RFC5440] describes the Path Computation Element communication Protocol (PCEP) which enables the communication between a Path Computation Client (PCC) and a Path Control Element (PCE), or between two PCEs based on the PCE architecture [RFC4655].

PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of extensions to PCEP to enable active control of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE-initiated LSPs under the active stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network.

[RFC5440] defined P flag (Processing-Rule) as part of Common Object Header to allow a PCC to specify in a Path Computation Request (PCReq) message sent to a PCE whether the object must be taken into account by the PCE during path computation or is just optional. The I flag (Ignore) is used by a PCE in a Path Computation Reply (PCRep) message to indicate to a PCC whether or not an optional object was processed. Stateful PCE [RFC8231] specified that P and I flags of the PCEP objects defined in [RFC8231] is to be set to zero on transmission and ignored on receipt since they are exclusively related to path computation requests. The behavior for P and I flag in other messages defined in [RFC5440] and other extension was not specified. This document clarifies how the P and I flag could be used in the stateful PCE model to identify optional objects in the Path Computation State Report (PCRpt) [RFC8231], the Path Computation Update Request (PCUpd) [RFC8231], and the LSP Initiate Request (PCInitiate) [RFC8281] message.

This document updates [RFC8231] with respect to usage of P and I flag as well as the handling of unknown objects in the stateful PCEP message exchange.

1.1. Requirements Language

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.

2. Overview

[RFC5440] describes the handling on unknown objects as per the setting of the P flag for the PCReq message. Further [RFC8231] defined the usage of LSP Error Code TLV in PCRpt message in response to failed LSP Update Request via PCUpd message (for example, due to an unsupported object/TLV).

This document clarifies the procedure for marking some objects as 'optional to be processed' by the PCEP peer in the stateful PCEP messages. Furthermore this document updates the procedure for handling unknown objects in the stateful PCEP messages based on the P flag.

2.1. Usage Example

The PCRpt message is used to report the current state of an LSP. As part of the message both the <intended-attribute-list> and <actual-attribute-list> is encoded (see [RFC8231]). For example, the <intended-attribute-list> could include the METRIC object to indicate a limiting constraint (B flag set) for the Path Delay Variation metric [RFC8233]. In some scenarios it would be useful to state that this limiting constraint can be relaxed by the PCE in case it cannot find a path. Similarly in case of an association groups [I-D.ietf-pce-association-group] such as Disjoint Association [I-D.ietf-pce-association-diversity], the PCE may need to completely relax the disjointness constraint in order to provide a path to all the LSPs that are part of the association. In these case it would be useful to mark the objects as 'optional' and it could be ignored by the PCEP peer. Also it would be used for the PCEP speaker to learn if the PCEP peer has relaxed the constraint and ignored the processing of the PCEP object.

Thus, this document simply clarifies, how the already existing P and I flag in the PCEP common object header could be used during the stateful PCEP message exchanges.

3. PCEP Extension

3.1. STATEFUL-PCE-CAPABILITY TLV

A PCEP speaker indicates its ability to support for handling P and I flag during the stateful PCEP message exchanges during the PCEP initialization phase, as follows. When the PCEP session is created, it sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag, the R (RELAX) flag, is introduced to this TLV to indicate support for relaxing the processing of some objects via the use of P and I flag in the PCEP common object header.

R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag indicates that the PCEP Speaker is willing to send and receive PCEP objects with handling of P and I flags in the PCEP common object header for stateful PCE messages. In case the bit is unset, it indicates that the PCEP Speaker would not handle P and I flags in the PCEP common object header for stateful PCE messages.

The R flag MUST be set by both a PCC and a PCE to indicate support for handling of P and I flag in the PCEP common object header to allow relaxing some constraints by marking objects as optional to process. If the PCEP speaker that did not set R flag but receives PCEP objects with P or I bit set, MUST behave as per the processing rule in [RFC8231] i.e., the bits are simply ignored.

3.2. Handling of P flag

3.2.1. The PCRpt message

The P flag in the PCRpt message [RFC8231] allows a PCC to specify to a PCE whether the object must be taken into account by the PCE (during path computation or re-optimization) or is just optional. When the P flag is set in PCRpt message received on a PCEP session on which R bit was set by both peers, the object MUST be taken into account by the PCE. Conversely, when the P flag is cleared, the object is optional and the PCE is free to ignore it. The P flag for the mandatory objects LSP and ERO (intended path) MUST be set in the PCRpt message. If the mandatory object is received with the P flag set incorrectly according to the rules stated above, the receiving peer MUST send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=1 (reception of an object with P flag not set). By default, the PCC SHOULD set the P flag, unless a local configuration or local policy indicates that some constraints (corresponding PCEP objects) can be marked as optional and could be ignored by the PCE.

3.2.2. The PCUpd message and the PCInitiate message

The P flag in the PCUpd message [RFC8231] and the PCInitiate message [RFC8281] allows a PCE to specify to a PCC whether the object must be taken into account by the PCC (during path setup) or is just optional. When the P flag is set in PCUpd/PCInitiate message received on a PCEP session on which R bit was set by both peers, the object MUST be taken into account by the PCC. Conversely, when the P flag is cleared, the object is optional and the PCC is free to ignore it. The P flag for the mandatory objects SRP, LSP and ERO MUST be set in the PCUpd/PCInitiate message. If the mandatory object is received with the P flag set incorrectly according to the rules stated above, the receiving peer MUST send a PCErr message with Error-Type=10 (Reception of an invalid object) and Error-value=1 (reception of an object with P flag not set). By default, the PCE SHOULD set the P flag, unless a local configuration or local policy indicates that some constraints (corresponding PCEP objects) can be marked as optional and could be ignored by the PCC.

3.3. Handling of I flag

3.3.1. The PCUpd message

The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to a PCC whether or not an optional object was processed. The PCE MAY include the ignored optional object in its update request and set the I flag to indicate that the optional object was ignored. When the I flag is cleared, the PCE indicates that the optional object was processed.

3.3.2. The PCRpt message

The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to a PCE whether or not an optional object was processed in response to an LSP Update Request (PCUpd) or LSP Initiate Request (PCInitiate). The PCC MAY include the ignored optional object in its report and set the I flag to indicate that the optional object was ignored at PCC. When the I flag is cleared, the PCC indicates that the optional object was processed. The I flag has no meaning if the PCRpt message is not in response to a PCUpd or PCInitiate message (i.e. without the SRP object in the PCRpt message).

3.3.3. The PCInitiate message

The I flag has no meaning in the PCinitiate message [RFC8281] and is ignored.

3.4. Delegation

Delegation is an operation to grant a PCE temporary rights to modify a subset of LSP parameters on one or more LSPs of a PCC as described in [RFC8051]. Note that for the delegated LSPs, the PCE can update and mark some object as ignored even when the PCC had set the P flag during delegation. Similarly, the PCE can update and mark some object as a must to process even when the PCC had not set the P flag during delegation.

The PCC MUST acknowledge this by sending the PCRpt message with the P flag set as per the PCE expectation for the corresponding object. In case PCC cannot except this, it would react as per the processing rules of unacceptable update in [RFC8231].

3.5. Unknown Object Handling

This document updates the handling of unknown objects in stateful PCEP messages as per the setting of P flag in the common object header in a similar way as [RFC5440], i.e. if a PCEP speaker does not understand an object with the P flag set or understands the object but decides to ignore the object, the entire stateful PCEP message MUST be rejected and the PCE MUST send a PCErr message with Error-Type="Unknown Object" or "Not supported Object" [RFC5440]. In case the P flag is not set, the PCEP speaker is free to ignore the object and continue with the message processing as defined.

[RFC8231] defined LSP Error Code TLV to be carried in PCRpt message in the LSP object to convey error information. This document does not change that procedure.

4. Security Considerations

This documents clarifies how the already existing P and I flag in PCEP common object header could be used during stateful PCEP exchanges. It updates the unknown object error handling in stateful PCEP message exchange. These changes on its own do not add any new security concerns. The security considerations identified in [RFC5440], [RFC8231], and [RFC8281].

As per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253] as per the recommendations and best current practices in [RFC7525] (unless explicitly set aside in [RFC8253]).

5. IANA Considerations

5.1. STATEFUL-PCE-CAPABILITY TLV

[RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA created a "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. IANA is requested to allocate a new bit in the subregistry, as follows:

Bit       Description                 Reference
-------------------------------------------------
TBD1      RELAX bit                   [This-I.D.]

6. Manageability Considerations

6.1. Control of Function and Policy

An operator MUST be allowed to configure the capability to support relaxation of constraints in the stateful PCEP message exchange. They SHOULD also allow configuration of related LSP constraints (or parameters) that are optional to process.

6.2. Information and Data Models

An implementation SHOULD allow the operator to view the capability defined in this document. To serve this purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended in future.

6.3. Liveness Detection and Monitoring

Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].

6.4. Verify Correct Operations

Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].

6.5. Requirements On Other Protocols

Mechanisms defined in this document do not imply any new requirements on other protocols.

6.6. Impact On Network Operations

Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440].

7. Acknowledgments

Thanks to Jonathan Hardwick for discussion and suggestions around this draft.

8. References

8.1. Normative References

8.2. Informative References

Appendix A. Contributors

Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka  560066
India

Email: dhruv.ietf@gmail.com      
    

Authors' Addresses