PCE Communication Protocol (PCEP) extensions for updating Open Message content
draft-stone-pce-update-open-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Andrew Stone , Cheng Li , Samuel Sidor | ||
| Last updated | 2024-08-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-stone-pce-update-open-00
PCE Working Group A. Stone
Internet-Draft Nokia
Intended status: Standards Track C. Li
Expires: 20 February 2025 Huawei
S. Sidor
Cisco
19 August 2024
PCE Communication Protocol (PCEP) extensions for updating Open Message
content
draft-stone-pce-update-open-00
Abstract
This document describes extensions to the Path Computation Element
(PCE) Communication Protocol (PCEP) to permit a PCEP Speaker to
update information previously exchanged during PCEP session
establishment via the Open message.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Path Computation
Element Working Group mailing list (pce@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/pce/.
Source for this draft and an issue tracker can be found at
https://github.com/astone282/draft-stone-pce-update-open.
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.
Stone, et al. Expires 20 February 2025 [Page 1]
Internet-Draft PCEP-UPDATE-OPEN August 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operational Considerations . . . . . . . . . . . . . . . . . 4
3.1. Capability Change . . . . . . . . . . . . . . . . . . . . 4
3.2. Node-wide Property Change . . . . . . . . . . . . . . . . 4
3.3. Frequency of Open Refresh . . . . . . . . . . . . . . . . 4
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Capability Advertisement . . . . . . . . . . . . . . . . 5
4.2. Open Refresh . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Adding/removing values or Sub-TLVs . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Managability Considerations . . . . . . . . . . . . . . . . . 6
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8.1. Open Object Flag Field . . . . . . . . . . . . . . . . . 6
8.2. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 6
8.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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).
Stone, et al. Expires 20 February 2025 [Page 2]
Internet-Draft PCEP-UPDATE-OPEN August 2024
[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.
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. Terminology
Open Refresh: The act of modifying content previously exchanged
during PCEP Open Message in an ad-hoc manner without terminating the
PCEP session.
Stone, et al. Expires 20 February 2025 [Page 3]
Internet-Draft PCEP-UPDATE-OPEN August 2024
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.
3.1. Capability Change
One use case of the Open message is to exchange device software
capabilities and feature enablement to determine whether a PCEP
Speaker may support a given operation defined in PCEP extensions. If
a PCEP speaker supports removal of a capability using Open Refresh,
then all states related to the capability MUST be reset and removed
and MUST follow the guidelines set out by the capability should the
other PCEP speaker no longer support the capability. This may impact
device-wide state and network traffic. For example, [RFC8281]
defines the STATEFUL-PCE-CAPABILITY-TLV to indicate support for PCE-
Initiated LSPs. The removal of this capability would result in PCE-
Initiated LSPs being deleted from each PCEP Speaker.
3.2. Node-wide Property Change
One use case of the Open message is to exchange device-level
configurations or settings. In the case of statefully delegated LSPs
([RFC8231], the modification of these values may trigger path
calculations for established LSPs with a possibility of LSP tear
down.
3.3. Frequency of Open Refresh
A PCEP implementation should consider the impact on the entire
network before sending frequent Open Refresh Notifications. It could
consider applying some form of dampening or back-off mechanism.
4. Procedures
Stone, et al. Expires 20 February 2025 [Page 4]
Internet-Draft PCEP-UPDATE-OPEN August 2024
4.1. Capability Advertisement
A PCEP Speaker indicates support of Open Refresh during the PCEP
Initialization phase ([RFC5440]). As per [RFC5440], a PCEP Speaker
sends an Open Message with exactly one OPEN object. This document
defines a new flag, OPEN-REFRESH-CAPABILITY (R-bit), in the Open
Message Flags field to indicate the support of the Open Refresh
feature.
* R (OPEN-REFRESH-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP
speaker, the PCEP speaker indicates that the PCEP speaker supports
updating the information in the Open message without resetting the
session.
If a PCEP speaker receives an Open Message that does not set the
OPEN-REFRESH-CAPABILITY flag, the PCEP Speaker MUST NOT send Open
Refresh messages to the remote PCEP speaker.
4.2. Open Refresh
An Open Refresh is transmitted by sending a PCNtf Message ([RFC5440])
containing a NOTIFICATION Object with Notification-type=TBD2 (Open-
Refresh):
* Notification-value=1: Refresh the Open information. The
NOTIFICATION Object encodes any TLV that can be encoded in an OPEN
Object. The NOTIFICATION Object contains a snapshot of all
unmodified and modified TLVs. Upon receiving an Open-Refresh
Notification message, the PCEP Speaker compares the newly received
TLVs with the previously received TLVs to determine what has
changed. An omission of a TLV MUST be treated as a removal of the
TLV and perform a necessary side effect(s) to the system state as
if the TLV was never exchanged during session establishment via
Open message.
4.2.1. Adding/removing values or Sub-TLVs
If the PCEP Speaker determines it cannot support the Open-Refresh
differential change(s), the PCEP Speaker generates a PCEP Error
(PCErr) with Error-type=TBD3 (Unsupported-Open-Refresh) and error-
value TBD4 and it SHOULD terminate the PCEP session.
5. Security Considerations
TODO Security
Stone, et al. Expires 20 February 2025 [Page 5]
Internet-Draft PCEP-UPDATE-OPEN August 2024
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
8.1. Open Object Flag Field
IANA is requested to allocate a new bit value in the "Open Object
Flag Field" registry:
+======+=========================+===============+
| Bit | Description | Reference |
+======+=========================+===============+
| TBD1 | OPEN-REFRESH-CAPABILITY | This document |
+------+-------------------------+---------------+
Table 1
8.2. NOTIFICATION Object
IANA is requested to allocate a new Notification-type value in the
"Notification Object" registry:
Stone, et al. Expires 20 February 2025 [Page 6]
Internet-Draft PCEP-UPDATE-OPEN August 2024
+===================+====================+===============+
| Notification-type | Name | Reference |
+===================+====================+===============+
| TBD2 | Open-Refresh | This document |
+-------------------+--------------------+---------------+
| | Notification-value | |
+-------------------+--------------------+---------------+
| | 1: Refresh the | |
| | Open information | |
+-------------------+--------------------+---------------+
Table 2
8.3. PCEP Error
IANA is requested to allocate a new Error-type value in the "PCEP-
ERROR Object Error Types and Values" registry:
+============+====================+==================+===========+
| Error-type | Meaning | Error-value | Reference |
+============+====================+==================+===========+
| TBD3 | Open-Refresh Error | 1: Open-Refresh | This |
| | | is not supported | document |
+------------+--------------------+------------------+-----------+
Table 3
9. References
9.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/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>.
[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>.
9.2. Informative References
Stone, et al. Expires 20 February 2025 [Page 7]
Internet-Draft PCEP-UPDATE-OPEN August 2024
[I-D.ietf-pce-controlled-id-space]
Li, C., Shi, H., Wang, A., Cheng, W., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
extension to advertise the PCE Controlled Identifier
Space", Work in Progress, Internet-Draft, draft-ietf-pce-
controlled-id-space-00, 4 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
controlled-id-space-00>.
[I-D.ietf-pce-state-sync]
Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter
Stateful Path Computation Element (PCE) Communication
Procedures.", Work in Progress, Internet-Draft, draft-
ietf-pce-state-sync-07, 17 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
state-sync-07>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/rfc/rfc7942>.
[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>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/rfc/rfc8281>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/rfc/rfc8408>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/rfc/rfc8664>.
Stone, et al. Expires 20 February 2025 [Page 8]
Internet-Draft PCEP-UPDATE-OPEN August 2024
Acknowledgments
The authors would like to acknowledge Dhruv Dhody for the discussion
and ideas related to this document.
Authors' Addresses
Andrew Stone
Nokia
Email: andrew.stone@nokia.com
Cheng Li
Huawei
Email: c.l@huawei.com
Samuel Sidor
Cisco
Email: ssidor@cisco.com
Stone, et al. Expires 20 February 2025 [Page 9]