PCE Communication Protocol (PCEP) extensions for updating Open Message content

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 20 February 2025.¶

Copyright Notice

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

The Path Computation Element (PCE) Communication Protocol (PCEP) [RFC5440] provides mechanisms for PCEs to perform path computations in response to requests from Path Computation Clients (PCCs).¶

[RFC5440] outlines the message exchange procedures that PCEP Speakers must follow upon initial connection to establish a PCEP Session. This procedure includes sending an Open Message containing an OPEN Object, which conveys various session characteristics such as protocol timers. The OPEN Object can be extended with TLVs to convey additional session characteristics, such as PCE capabilities (e.g., [RFC8408]) or specific values and ranges (e.g., [RFC8664] and [I-D.ietf-pce-controlled-id-space]). This information is exchanged only once per session and cannot be dynamically modified without tearing down and re-establishing the PCEP session, which can be operationally disruptive.¶

Additionally, [RFC5440] specify a Notification Message (PCNtf) containing a NOTIFICATION Object, which a PCEP Speaker may use to notify the other speaker of an event.¶

This document proposes a generic mechanism allowing a PCEP Speaker (PCC or PCE) to update previously exchanged Open Message information using a PCNtf Message with a new notification called "Open Refresh". This approach mitigates the need to terminate the session to modify any exchanged information.¶

Note that [I-D.ietf-pce-controlled-id-space] also proposes using PCNtf Message to relay Open Messages between PCEs about each PCE's connected peers. It is anticipated that [I-D.ietf-pce-state-sync] will use a similar notification mechanism with a unique notification type, as the semantics of a PCEP Speaker exchanging its information differ from exchanging information related to a connected state-sync PCEs.¶

This document describes a generic extension and mechanism to update Open Object content but future documents MAY describe further semantics on a per TLV basis.¶

2. Terminology

Open Refresh: The act of modifying content previously exchanged during PCEP Open Message in an ad-hoc manner without terminating the PCEP session.¶

Open Refresh Notification message: An Open Refresh notification message is a new Notification Type to be used in the PCNtf Message ([RFC5440]) that will also contain the open information to be refreshed.¶

3. Operational Considerations

This section discusses some high-level considerations that should be considered when supporting Open Refresh. While scenarios described here exist in present-day PCEP, they require explicitly tearing down the PCEP session which gives a clear indication of potential system impact. With ad-hoc manipulation of open information, the impact of a possible change may not be evident so this section attempts to describe some of these considerations.¶

4. Procedures

5. Security Considerations

TODO Security¶

6. Managability Considerations

TODO¶

7. Implementation Status

[Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.]¶

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶

8. IANA Considerations

9. References

Acknowledgments

The authors would like to acknowledge Dhruv Dhody for the discussion and ideas related to this document.¶

Authors' Addresses