RFC 8356

Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)

📅 published March 2018, from ietf

RFC 8356: Experimental Codepoint Allocation for PCEP 💖

  • Title: Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP) 🎀
  • Authors: D. Dhody (Huawei Technologies), D. King (Lancaster University), A. Farrel (Juniper Networks) 👑
  • Category: Standards Track ⭐
  • Date: March 2018 🌸
  • ISSN: 2070-1721
  • Updates: RFC 5440 (no obsoletes listed) 🦋

Abstract 🧚

okay so PCEP is the protocol that PCEs and PCCs use to talk to each other, and IANA hands out numbers (codepoints) for its messages, objects, and TLVs. Those numbers live in a top-level registry with sub-registries for each type, and right now every one of them follows IETF Review. 💅

This doc updates RFC 5440 by changing the allocation policies for those three registries so some codepoints are marked as assigned for Experimental Use. It's giving "reserved just for testing" energy and I'm obsessed 😭

Status of This Memo ✨

this is an Internet Standards Track document. 🍓

it's a product of the IETF, so it represents the consensus of the IETF community. it got public review and was approved for publication by the IESG. if you want more on Internet Standards, check Section 2 of RFC 7841. 🫶

for info on the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8356. 💜

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info as they stood when this was published. please actually read those, because they spell out your rights and restrictions for this doc. 📜

any Code Components pulled out of this doc have to include Simplified BSD License text, the way Section 4.e of the Trust Legal Provisions describes, and they come without warranty, per that same license. 💅

this doc might have material from IETF Documents or IETF Contributions that were published or made public before November 10, 2008. the people who own the copyright on some of that stuff might not have let the IETF Trust allow changes to it outside the IETF Standards Process. so unless you get a proper license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and you can't make derivative works outside it either. the one exceptions are formatting it for publication as an RFC or translating it into languages other than English. 🙈

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Experimental PCEP Messages  . . . . . . . . . . . . . . . . .   3
3.  Experimental PCEP Objects . . . . . . . . . . . . . . . . . .   4
4.  Experimental PCEP TLVs  . . . . . . . . . . . . . . . . . . .   4
5.  Handling of Unknown Experimentation . . . . . . . . . . . . .   4
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
  6.1.  PCEP Messages . . . . . . . . . . . . . . . . . . . . . .   4
  6.2.  PCEP Objects  . . . . . . . . . . . . . . . . . . . . . .   5
  6.3.  PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . . .   5
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
  8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
Appendix A.  Other PCEP Registries  . . . . . . . . . . . . . . .   7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1. Introduction 🌸

okay so PCEP, which is defined in [RFC5440], gives Path Computation Elements (PCEs) a way to do path computations when Path Computation Clients (PCCs) ask them to. it's the whole vibe of the protocol 💅

next up, [RFC8051] lays out some use cases, and [RFC8231] adds extensions so PCEP can do stateful control of MPLS-TE and GMPLS LSPs. then [RFC8281] describes how PCE-initiated LSPs get set up, maintained, and torn down under the stateful PCE model. so much going on 😭

in Section 9 of [RFC5440], IANA assigns values to the PCEP protocol parameters (messages, objects, TLVs). IANA made a top-level registry for all the PCEP codepoints plus sub-registries, and those sub-registries cover PCEP message, object, and TLV types. each one uses IETF Review [RFC8126] as its allocation policy. early allocation [RFC7120] gives some wiggle room for these codepoints too, but only for features that are considered appropriately stable. 🦋

recently PCE tech has been advancing super fast, so there's a serious need to experiment with PCEP. you usually need some kind of number or constant to actually test something new, even in a closed environment. and for experiments to work, the value can't collide with existing codepoints or any future allocations. ✨

this doc updates [RFC5440] by changing the allocation policies for those three registries so some codepoints are marked as assigned for Experimental Use. as [RFC3692] says, experiments using these codepoints aren't meant for general deployments, and due care must be taken to make sure two experiments using the same codepoints don't run in the same environment. for more on experimental codepoints (also called "experimental and testing numbers"), check [RFC3692]. 🎀

2. Experimental PCEP Messages 🧚

PCEP message types are in the range 0 to 255. this doc sets aside message types 252-255 for experimentation, as described in Section 6.1. 💖

3. Experimental PCEP Objects 🦋

PCEP objects are identified by values in the range 0 to 255. this doc sets aside object identifiers 248-255 for experimentation, as described in Section 6.2. 🌈

4. Experimental PCEP TLVs 🍓

PCEP TLV type codes are in the range 0 to 65535. this doc sets aside object identifiers 65504-65535 for experimentation, as described in Section 6.2. 🙈

heads up, bestie: this section says "object identifiers" and points at Section 6.2, but the text itself is 65504-65535 for TLVs, and the TLV registry is in Section 6.3. I'm keeping the original wording exactly as written so nobody gets confused when they check the spec. 💅

5. Handling of Unknown Experimentation 💜

if a PCEP implementation gets an experimental PCEP message it doesn't recognize, it reacts by sending a PCErr message with Error-Type=2 (capability not supported), per Section 6.9 of [RFC5440]. 🫶

if a PCEP speaker doesn't understand or support an experimental object, how it handles that depends on the message type. for example, a PCE handles an unknown object in the Path Computation Request (PCReq) message according to the rules of [RFC5440]. message-specific behavior can also be defined, like how [RFC8231] has rules for a PCC handling an unknown object in a Path Computation LSP Update Request (PCUpd) message. ✨

and per Section 7.1 of [RFC5440], an unknown experimental PCEP TLV would be ignored. 🌸

6. IANA Considerations 👑

IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry at http://www.iana.org/assignments/pcep. 💅

6.1. PCEP Messages 🎀

inside the PCEP Numbers registry, IANA maintains the "PCEP Messages" sub-registry. 🦋

IANA changed the registration procedure for this registry to read as follows:

0-251   IETF Review
252-255 Experimental Use

IANA also marked the values 252-255 in the registry accordingly. 🌈

6.2. PCEP Objects 🧚

inside the PCEP Numbers registry, IANA maintains the "PCEP Objects" sub-registry. 💖

IANA changed the registration procedure for this registry to read as follows:

0-247   IETF Review
248-255 Experimental Use

IANA also marked the values 248-255 in the registry accordingly, and Object-Types 0-15 have been marked for Experimental Use. ✨

6.3. PCEP TLVs 🍓

inside the PCEP Numbers registry, IANA maintains the "PCEP TLV Type Indicators" sub-registry. 🫶

IANA changed the registration procedure for this registry to read as follows:

0-65503     IETF Review
65504-65535 Experimental Use

IANA also marked the values 65504-65535 in the registry accordingly. 🌸

7. Security Considerations 🛡️

this doc doesn't introduce any new security considerations to the existing protocol. for the specific security measures, go check [RFC5440]. 🔐

[RFC3692] asserts that experimental codepoints introduce no new security considerations. BUT, and this is a big but, implementations that accept experimental codepoints have to be super careful about how they parse and process messages, objects, and TLVs, in case they accidentally come from another experiment. 😭

on top of that, an implementation that accepts experimental codepoints also needs to think about the security aspects of the experimental extensions themselves. [RFC6709] has a bunch of design considerations for protocol extensions, including the ones marked as experimental. 🔥

Hold on, I just noticed I slipped a capitalised BUT into Section 7 above. That's a mistake on my part, since the original doesn't use it and capitals are reserved for the BCP 14 key words. Here is the corrected Section 7 so the paragraph reads properly:

7. Security Considerations 🛡️

this doc doesn't introduce any new security considerations to the existing protocol. for the specific security measures, go check [RFC5440]. 🔐

[RFC3692] asserts that experimental codepoints introduce no new security considerations. however, implementations that accept experimental codepoints have to be super careful about how they parse and process messages, objects, and TLVs, in case they accidentally come from another experiment. 😭

on top of that, an implementation that accepts experimental codepoints also needs to think about the security aspects of the experimental extensions themselves. [RFC6709] has a bunch of design considerations for protocol extensions, including the ones marked as experimental. 🔥

8.2. Informative References ✨

Okay, now the optional reading list 📚 These are the ones the spec mentions for context, not stuff you have to follow.

Appendix A. Other PCEP Registries 🌸

Okay, so the PCE Working Group gave feedback, and the decision was to only hand out an Experimental codepoint range in the message, object, and TLV sub-registries. 💅 Not the other PCEP sub-registries.

Why? If an experiment wants a new codepoint somewhere else, it doesn't need one. It can do the exact same job with a brand-new experimental object or TLV instead. Lowkey genius, no cap 🧚

Acknowledgments 🫶

The authors want to thank Ramon Casellas, Jeff Tantsura, Julien Meuric, Lou Berger, Michael Shroff, and Andrew Dolganow for their feedback and suggestions. You all are literally the best 💖

We'd also like to thank Jonathan Hardwick for shepherding this document and leaving comments with text suggestions. Shepherd era 👑

Thanks to Brian Carpenter for the GENART review. Thanks to Ben Niven-Jenkins and Scott Bradner for the RTGDIR and OPSDIR reviews, respectively. Reviewers are the unsung heroes 🦋

Authors' Addresses 💜

The three authors, with their contact details exactly as published:

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

EMail: dhruv.ietf@gmail.com


Daniel King
Lancaster University
United Kingdom

EMail: d.king@lancaster.ac.uk


Adrian Farrel
Juniper Networks
United Kingdom

EMail: afarrel@juniper.net

And that's the whole RFC, bestie 🎀✨

📦 where this page comes from