RFC 8786

RFC 8786: Updated Rules for Processing Stateful PCE Request Parameters Flags 💖

okay bestie, this one is an IETF doc 🎀 Here's the lineup. It's Request for Comments: 8786 from the Internet Engineering Task Force (IETF). Adrian Farrel of Old Dog Consulting wrote it, it's published as a Standards Track document, and the date is May 2020. It's also ISSN 2070-1721 🌸 The big plot point is that it updates RFC 8231 🦋, so it's basically a fix-up for the older spec 🫶

• Series: Internet Engineering Task Force (IETF)
• Number: Request for Comments: 8786
• Author: A. Farrel (Adrian Farrel), Old Dog Consulting
• Updates: 8231
• Category: Standards Track
• Date: May 2020
• ISSN: 2070-1721

---

Abstract

okay so the PCEP extensions for stateful PCEs are defined in RFC 8231 🧚 One of those extensions is the Stateful PCE Request Parameters (SRP) object, and it has a Flags field made of 32 bit flags. RFC 8281 sets up an IANA registry for keeping track of which flags have been assigned 💜 But here's the tea: RFC 8231 never explains how an implementation should set unassigned flags when it sends messages, or how it should handle unassigned, unknown, or unsupported flags when it receives them 😭

This document updates RFC 8231 and spells out the correct behaviors ✨

Status of This Memo

This is an Internet Standards Track document ⭐

It's a product of the Internet Engineering Task Force (IETF) and it reflects the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 🌈

Want the current status, any errata, or a way to send feedback? Go to https://www.rfc-editor.org/info/rfc8786 🎀

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) as they stand on the publication date. Please read these carefully, because they cover your rights and restrictions for this document. Any Code Components pulled out of this document have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🙈

Table of Contents

• 1. Introduction
• 2. Requirements Language
• 3. Updated Procedures
  • 3.1. Advice for Specification of New Flags
  • 3.2. Flags Field of the SRP Object
• 4. Compatibility Considerations
• 5. Management Considerations
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
  • 8.1. Normative References
  • 8.2. Informative References
• Acknowledgements
• Author's Address

---

1. Introduction ✨

okay so [RFC5440] describes PCEP, the Path Computation Element Communication Protocol 🧚 PCEP covers the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCEs. It's how Multiprotocol Label Switching (MPLS) gets computed for Traffic Engineering Label Switched Path (TE LSP) characteristics 🦋

[RFC8231] adds a set of PCEP extensions for stateful control of LSPs, both within and across PCEP sessions, following [RFC4657] 💖 It brings in mechanisms for LSP State Synchronization between PCCs and PCEs, for delegating control of LSPs to PCEs, and for PCE control over the timing and sequence of path computations within and across PCEP sessions. Very iconic 👑

One of the extensions from [RFC8231] is the SRP object. It has a 32 bit Flags field, and RFC 8281 defines an IANA registry for tracking the assigned flags 💜 The problem is that RFC 8231 doesn't say how to set unassigned flags in sent messages, or how to process unassigned or unknown flags in received messages 😭

On top of that, [RFC8231] doesn't guide future spec authors on describing how new flags interact with flags that already exist 🙈

So, again: this document updates RFC 8231 by defining the correct behaviors 🫶

2. Requirements Language

bestie, the key words in this document are the ones below. They're used like this: the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are read as described in BCP 14 [RFC2119] [RFC8174]. They only count when they show up in ALL CAPITALS, exactly as written here 💅

3. Updated Procedures

3.1. Advice for Specification of New Flags

Section 7 of [RFC8231] brings in changes to existing PCEP objects and defines new PCEP objects and TLVs for stateful PCE functionality. It doesn't advise future specs on how to describe the interaction between flags that might get defined 🌸

So Section 7 of [RFC8231] gets updated to read like this:

The PCEP objects defined in this document are compliant with the PCEP object format defined in [RFC5440]. The P and I flags of the PCEP objects defined in the current document MUST be set to 0 on transmission and SHOULD be ignored on receipt since they are exclusively related to path computation requests. The sections that follow define PCEP objects and TLVs that contain Flags fields, and some flag values are defined. Future specifications may define further flags, and each new specification that defines additional flags is expected to describe the interaction between these new flags and any existing flags. In particular, new specifications are expected to explain how to handle the cases when both new and pre-existing flags are set.

3.2. Flags Field of the SRP Object

Section 7.2 of [RFC8231] defines the PCEP SRP object and describes its Flags field like this:

Flags (32 bits): None defined yet.

This document updates that text to read:

Flags (32 bits): This document does not define any flags. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt. Implementations that do not understand any particular flag MUST ignore the flag.

4. Compatibility Considerations

okay so one of the big goals of this document is backward compatibility 🎀 There's still a compatibility question, though, between existing RFC 8231 implementations and implementations that follow this doc 🧚

The good news: the updated text in Section 3 describes what's already common for Flags fields. Lots of implementations, even without guidance from RFC 8231, probably already have a consistent and future-proof approach 🦋 Still, it's worth looking at how behaviors might interact between implementations, just for completeness 💜

SRP objects made by an implementation of this document set every unknown flag bit to zero. So an older implementation won't have problems even if it looks at those bits 🌈 And an implementation of this document won't look at unknown flag bits, so older implementations don't affect it, no matter how they set the flags ✨

There's still a question about how implementations set the flags. An RFC 8231 implementation might set any of the unassigned flags, but a future or current spec, like [RFC8281] or [RFC8741], gives a specific meaning to a flag when it's set. Old implementations can't be fixed by documentation alone. For future specs, the only real fix is obsoleting the Flags field and using a new technique 😭 Fortunately, most implementations were built to set unused flags to zero, which matches this document's behavior. So the risk of bad interactions is small enough that the existing Flags field doesn't need to be obsoleted 💅

5. Management Considerations

Implementations that receive set SRP flags they don't recognize MAY log this. That can help when you're diagnosing backward compatibility issues with future features that use those flags 🔥

6. Security Considerations

[RFC8231] lays out the security considerations for PCEP when it's used to talk to a stateful PCE. This document does not change any of them 🔒

That said, by defining the expected behavior of implementations, this document can improve network stability, which can reduce the attack surface. The point is that if implementations ignore unset bits, attackers can't get much by randomly tweaking bits. And by reminding implementations to leave undefined bits unset, the network stays future-proofed against new definitions of previously undefined bits 🛡️

7. IANA Considerations

IANA maintains a registry called "Path Computation Element Protocol (PCEP) Numbers", which has a subregistry called "SRP Object Flag Field". IANA has updated the reference for that subregistry so it lists this document as well as [RFC8281] 🎀

8. References

8.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>.

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

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

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

8.2. Informative References

[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>.

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

[RFC8741] Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and M. Negi, "Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)", RFC 8741, DOI 10.17487/RFC8741, March 2020, <https://www.rfc-editor.org/info/rfc8741>.

Acknowledgements

Huge thanks to the authors of [RFC8741] for showing everyone that this work was needed 🫶 Thanks also to Dhruv Dhody and Julien Meuric for talking through the solution 💜 Extra thanks to Hariharan Ananthakrishnan for the Shepherd's review, and to Benjamin Kaduk and Alvaro Retana for helpful comments during IESG review 🌈

Author's Address

Adrian Farrel Old Dog Consulting

Email: adrian@olddog.co.uk ✨