RFC 8697

Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)

📅 published January 2020, from ietf

RFC 8697 💖

Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs) 🦋

Okay bestie, this one's from the IETF, published January 2020, and it's a Standards Track doc 👑 (so it's an actual spec, not just vibes). Its ISSN is 2070-1721. It was written by a whole squad: I. Minei from Google, Inc., E. Crabbe as an individual contributor, S. Sivabalan from Cisco Systems, Inc., H. Ananthakrishnan from Netflix, D. Dhody from Huawei, and Y. Tanaka from NTT Communications Corporation. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Abstract 🌸

This doc introduces a generic way to make a grouping of Label Switched Paths (LSPs) inside a Path Computation Element (PCE). Once you have that group, you can use it to link sets of LSPs together, or to link a set of LSPs to a set of attributes (like config parameters or behaviors) 🧚 It works for both the stateful PCE (active and passive modes) and the stateless PCE, so it's giving versatile ngl 💅

Status of This Memo 📜

Bestie, this part is the official "here's what this doc is" stuff 🫶 It's an Internet Standards Track document, and it's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841.

Errata, the current status, and how to send feedback all live at https://www.rfc-editor.org/info/rfc8697 🎀

Copyright is held by the IETF Trust and the people listed as authors, copyright (c) 2020, all rights reserved 💜 The doc 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 actually read those, because they spell out your rights and restrictions 🙈

If you pull Code Components out of this doc, they have to include the Simplified BSD License text 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
  1.1.  Requirements Language
2.  Terminology
3.  Architectural Overview
  3.1.  Motivations
  3.2.  Relationship to the SVEC List
  3.3.  Operational Overview
  3.4.  Operator-Configured Association Range
4.  Discovery of Supported Association Types
  4.1.  ASSOC-Type-List TLV
    4.1.1.  Procedure
5.  Operator-Configured Association Range TLV
  5.1.  Procedure
6.  ASSOCIATION Object
  6.1.  Object Definition
    6.1.1.  Global Association Source TLV
    6.1.2.  Extended Association ID TLV
    6.1.3.  Association Source
    6.1.4.  Unique Identification for an Association Group
  6.2.  Relationship to the RSVP ASSOCIATION Object
  6.3.  Object Encoding in PCEP Messages
    6.3.1.  Stateful PCEP Messages
    6.3.2.  Request Message
    6.3.3.  Reply Message
  6.4.  Processing Rules
7.  IANA Considerations
  7.1.  PCEP Object
  7.2.  PCEP TLV
  7.3.  Association Flags
  7.4.  Association Type
  7.5.  PCEP-Error Object
8.  Security Considerations
9.  Manageability Considerations
  9.1.  Control of Function and Policy
  9.2.  Information and Data Models
  9.3.  Liveness Detection and Monitoring
  9.4.  Verifying Correct Operation
  9.5.  Requirements on Other Protocols
  9.6.  Impact on Network Operations
10. References
  10.1.  Normative References
  10.2.  Informative References
Appendix A.  Example of an Operator-Configured Association Range
Acknowledgments
Contributors
Authors' Addresses

1. Introduction 🎀

Okay so [RFC5440] describes the Path Computation Element (PCE) Communication Protocol (PCEP) 💖 PCEP is how a Path Computation Client (PCC) and a PCE talk to each other, or how a PCE talks to another PCE. The point is computing characteristics for Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs), and also for Generalized MPLS (GMPLS) ones 🧚

[RFC8231] adds a bunch of extensions to PCEP so you can do stateful control of TE LSPs, both within and across PCEP sessions, following [RFC4657]. It covers LSP State Synchronization between PCCs and PCEs, delegating control of LSPs to PCEs, and PCE control over the timing and sequence of path computations, again within and across sessions. The model where LSPs get initiated from the PCE is described in [RFC8281] 🦋

Now [RFC4872] defines the RSVP ASSOCIATION object. It was made for GMPLS-controlled LSPs, to tie recovery LSPs to the LSP they protect, but it's honestly got broader uses as a way to associate RSVP state. [RFC6780] then explains how the ASSOCIATION object can be applied more generally, by defining the Extended ASSOCIATION object 👑

So this document is the glow-up 💅 It introduces a generic mechanism for grouping LSPs. That group can define associations between sets of LSPs, or between a set of LSPs and a set of attributes (like configuration parameters or behaviors). It's equally good for the stateful PCE (active and passive modes) and the stateless PCE ✨ The associations can be created dynamically and conveyed to a PCEP peer within PCEP, or an operator can configure them by hand on the PCEP peers. Check out Section 3.3 for the details 🍓

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 🫶 So lowercase versions of those words are just normal words, no cap, but the all-caps ones are the real rules.

2. Terminology 📚

Here's what this doc borrows from other docs 🧠

This document uses the following terms defined in [RFC5440]:

  • PCC
  • PCE
  • PCEP Peer
  • Path Computation Request (PCReq)
  • Path Computation Reply (PCRep)
  • PCEP Error (PCErr)

This document uses the following terms defined in [RFC8051]:

  • Stateful PCE
  • Active Stateful PCE
  • Passive Stateful PCE
  • Delegation

This document uses the following terms defined in [RFC8231]:

  • LSP State Report (PCRpt)
  • LSP Update Request (PCUpd)
  • State Timeout Interval

This document uses the following terms defined in [RFC8281]:

  • PCE-initiated LSP
  • LSP Initiate Request (PCInitiate)

3. Architectural Overview 🏛️

3.1. Motivations 💭

A stateful PCE can update existing LSPs and instantiate new ones 💅 Lots of situations need several LSPs to share common info. For example, to support PCE-controlled make-before-break, you want an association between the original path and the reoptimized path. Same vibe for end-to-end protection: an association between working and protection LSPs is required (see [PCE-PROTECTION]). For diverse paths, you can use an association between a group of LSPs (see [PCE-DIVERSITY]). Another use is applying one shared set of configuration parameters or behaviors to a bunch of LSPs 🌈

For a stateless PCE, it might be useful to link a PCReq message to an association group. That way the PCE can attach a shared set of policies, config parameters, or behaviors to the request 🧚

Some associations can be created dynamically, like an association between the working and protection LSPs of a tunnel 🦋 Others can be created manually by the operator, like a policy-based association where an LSP joins an operator-configured existing association 👑

Rather than making a separate mechanism for every use case (iykyk, that would be chaos), this document defines one generic mechanism that can be reused as needed ✨

3.2. Relationship to the SVEC List 🔗

Note that [RFC5440] defines a way to synchronize a set of PCReq messages using the SVEC (Synchronization VECtor) object 🌸 The SVEC object lists the synchronized requests, which can be either dependent or independent. It identifies the relationship between the set of PCReq messages by using "Request-ID-number" in the RP (Request Parameters) object. [RFC6007] goes deeper on using the SVEC list for synchronized path computations when computing dependent requests, and it describes a bunch of usage scenarios for SVEC lists in single-domain and multi-domain environments 💜

Real talk though, the association group in this document and the SVEC object are pretty different, even if some use cases overlap 🙈 PCEP extensions that define a new Association Type should clarify the relationship between the SVEC object and the Association Type, if there is one.

3.3. Operational Overview 🗺️

LSPs get associated with other LSPs they interact with by joining a common association group 💖 Association groups as defined here can apply to LSPs that start at the same headend or at different headends 🍓

Some associations are created dynamically by a PCEP speaker, and then the associations (along with the set of LSPs) get conveyed to a PCEP peer 🧚 Other associations are configured by the operator ahead of time on the PCEP peers in question. A PCEP speaker can then ask an LSP to join the Operator-configured Association. Whether you use dynamic or configured associations usually depends on the type of association 🦋

For Operator-configured Associations, the operator manually configures the association parameters, like the Association Identifier (Association ID), the Association Type, and the Association Source IP address 🎀 For a dynamic association, the PCEP speaker allocates the association parameters, like the Association ID, dynamically. The Association Source is set to the local PCEP speaker address, unless local policy says otherwise. If local policy says otherwise, the Association Source is set based on that local policy 🫶

A dynamically created association can be reported to the PCEP peer through PCEP messages, following the stateful extensions 💅 When the Operator-configured Association is already known to the PCEP peer beforehand, a PCEP peer can ask an LSP to join it through the stateful PCEP messages 👑

Associations are properties of the LSP, so they can be stored in the LSP state database 🌸 A dynamic association exists for as long as the LSP state exists. If the PCEP session terminates, the LSP state cleanup MUST also take care of associations 🙈

Multiple types of associations can exist, and each one has its own Association ID space 🌈 The definitions of the different Association Types and their behaviors are outside the scope of this document 🧚 You can establish and remove the association relationship on a per-LSP basis. An LSP can join multiple association groups, whether they have the same Association Type or different ones ✨

And that's the first chunk, bestie 💖 Next up is the rest of the Architectural Overview, starting with Section 3.4.

3.4. Operator-Configured Association Range ✨

okay so bestie, some Association Types are dynamic 🦋, some are operator configured 🎀, and some could be BOTH 💅. For the types that could be both and use the same Association Source, we need a way to keep the two ranges apart so there are no Association ID clashes within that Association Source 🙈. This document assumes that these two ranges are configured 🌸.

So for each Association Type (and Association Source), there's a range of Association IDs kept aside for the Operator-configured Associations 💖. Dynamic associations MUST NOT use an Association ID from this range 🚫. Hard rule, no exceptions, periodt 💅.

This range, as set at the PCEP speaker (a PCC or PCE, as an Association Source) 🧚, needs to be communicated to a PCEP peer in the Open message 📨. A brand new TLV is defined in this spec for exactly that job (Section 5) ✨. See Appendix A for an example 💜.

The Association ID range for other sources, like a Network Management System (NMS) 🌈, is NOT communicated in PCEP, and how the Operator-configured Association Range settings get handled there is outside the scope of this document 🫶.

4. Discovery of Supported Association Types 👑

this section is all about PCEP extensions so a speaker can advertise which Association Types it supports 🔥. We define a new PCEP ASSOC-Type-List (Association Types list) TLV 💅. It rides inside an OPEN object, so during session setup 🤝, a PCEP speaker can tell its peer the list of Association Types it supports ✨.

4.1. ASSOC-Type-List TLV 🎀

The PCEP ASSOC-Type-List TLV is OPTIONAL 💖. It MAY be carried within an OPEN object sent by a PCEP speaker in an Open message to a PCEP peer, to indicate the list of supported Association Types 🌸.

The format follows the regular PCEP TLV format from [RFC5440] 🦋. So: 2 octets for the type 🍓, 2 octets for the TLV length 📏, then a Value field 💜. The Length field counts only the value portion, in octets 🧮. The whole TLV gets padded to 4-octet alignment, but the padding does NOT count toward Length 🙈. Example: a 3-octet value has a Length of three, but the total TLV size is 8 octets, ngl 😭.

The PCEP ASSOC-Type-List TLV looks like this:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Type                  |            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Assoc-Type #1        |      Assoc-Type #2            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                                                             //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Assoc-Type #N        |       padding                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: The ASSOC-Type-List TLV Format

Here's the breakdown 🔍:

  • Type: 35 🎯
  • Length: N * 2 (where N is the number of Association Types) 🧮
  • Value: a list of 2-byte Association Type code points, identifying the Association Types the sender of the Open message supports 💅
  • Assoc-Type (2 bytes): an Association Type code point identifier. IANA manages the "ASSOCIATION Type Field" code point registry (see Section 7.4) 📋

4.1.1. Procedure 🧠

An ASSOC-Type-List TLV inside an OPEN object in an Open message gets included by a PCEP speaker to advertise one or more supported Association Types 🌈. The ASSOC-Type-List TLV MUST NOT appear more than once in an OPEN object 🚫. If it shows up twice, the PCEP session MUST be rejected with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message) 💀. As specified in [RFC5440], a PCEP peer that doesn't recognize the ASSOC-Type-List TLV will silently ignore it 🙈.

The Association Type spec (coming in future documents) can say whether advertising that type is mandatory 🎀. So the ASSOC-Type-List TLV MUST be included if at least one mandatory Association Type needs advertising, and it MAY be included otherwise 💖. For a mandatory type, if an Assoc-Type is missing from the ASSOC-Type-List TLV (or the whole TLV is missing), that means the PCEP speaker does NOT support that Association Type 🙅‍♀️.

If there's no ASSOC-Type-List TLV in an OPEN object, that MUST be read as "no information about the supported types," NOT as "this type isn't supported" 🫶. In that case the PCEP speaker could still use the ASSOCIATION object 💌. If the peer doesn't support the association, it reacts following the procedure in Section 6.4 🧚.

If the ASSOC-Type-List TLV is being sent because of a mandatory Association Type, then it is RECOMMENDED that the PCEP implementation include ALL supported Association Types (optional ones too) 🌸, so the PCEP peer has an easier time 💅.

5. Operator-Configured Association Range TLV 🦋

This section defines a PCEP extension for advertising the Operator-configured Association Range used for an Association Type by the PCEP speaker (as an Association Source) 🎀.

A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association Range) TLV is defined 🌟. It rides inside an OPEN object, so during session setup, a PCEP speaker can tell its peer the Operator-configured Association Range for an Association Type 💜.

The PCEP OP-CONF-ASSOC-RANGE TLV is OPTIONAL 🫶. It MAY be carried within an OPEN object sent by a PCEP speaker in an Open message to a PCEP peer 📨. It follows the PCEP TLV format from [RFC5440] too: 2 bytes for the type, 2 bytes for the length, then a Value field 🧮. The Length field counts the value portion in bytes 📏.

The layout looks like this 👇:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Type                  |            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             Reserved          |          Assoc-Type #1        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Start-Assoc-ID #1        |           Range #1            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                                                             //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             Reserved          |          Assoc-Type #N        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |      Start-Assoc-ID #N        |           Range #N            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: The OP-CONF-ASSOC-RANGE TLV Format

The fields 🔍:

  • Type: 29 🎯
  • Length: N * 8 (where N is the number of Association Types) 🧮
  • Value: includes the following fields, repeated for each Association Type 🔁
    • Reserved (2 bytes): MUST be set to 0 on transmission and MUST be ignored on receipt 🙈.
    • Assoc-Type (2 bytes): the Association Type (Section 7.4). The Association Types will be defined in future documents ✨.
    • Start-Assoc-ID (2 bytes): the "start association" identifier for the Operator-configured Association Range for that Association Type 🌸. The values 0 and 0xffff MUST NOT be used 🚫. On receipt of these values in the TLV, the session is rejected, and an error message is sent (see Section 5.1) 💀.
    • Range (2 bytes): the number of associations marked for Operator-configured Associations 🧁. Range MUST be greater than 0 🙌, and it MUST be such that (Start-Assoc-ID + Range) does not cross the largest Association ID value of 0xffff 📏. If this condition isn't met, the session is rejected, and an error message is sent (see Section 5.1) 😭.

5.1. Procedure

okay so a PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV inside the OPEN object of an Open message it sends to a PCEP peer 💌. The point is to advertise the Operator-configured Association Range for an Association Type ✨. The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN object 🙅‍♀️. If it shows up more than once, the PCEP session MUST be rejected with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message) 💀.

As specified in [RFC5440], a PCEP peer that doesn't recognize the OP-CONF-ASSOC-RANGE TLV will just silently ignore it 🙈. Very chill of it, honestly.

The Operator-configured Association Range SHOULD be included for each Association Type that could be both dynamic and operator configured 🦋. For Association Types that are only dynamic or only operator configured, this TLV MAY be skipped. If it's skipped, the full range of Association IDs is considered dynamic or operator configured, respectively 🌸. Each Association Type (to be defined in future documents) can specify the default value for its Operator-configured Association Range 🧚.

The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be interpreted as an absence of an explicit Operator-configured Association Range at the PCEP peer. In that case, the default behavior for each Association Type applies. If the Association Source is not a PCEP speaker, the default value for the Operator-configured Association Range is used for the Association Source 🫶.

If the Assoc-Type is not recognized or supported by the PCEP speaker, it MUST ignore that respective (Start-Assoc-ID + Range) 🤷‍♀️. If the Assoc-Type is recognized or supported but Start-Assoc-ID or Range is set incorrectly, the PCEP session MUST be rejected with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message) 😭. The incorrect range includes the case where the (Start-Assoc-ID + Range) crosses the largest Association ID value of 0xffff. Don't let it cross 0xffff, bestie 🚫.

A given Assoc-Type MAY appear more than once in the OP-CONF-ASSOC-RANGE TLV when the Operator-configured Association Range is non-contiguous 🌈. The PCEP speaker that originates this TLV MUST NOT send overlapping ranges for an Association Type. If a PCEP peer receives overlapping ranges for an Association Type, it MUST consider the Open message malformed and MUST reject the PCEP session with Error-Type 1 and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message) 🔥.

There may be cases where an Operator-configured Association was configured at the local PCEP speaker with association parameters (such as an Association ID, Association Type, and Association Source). Then, later, the PCEP session is established with the Association Source and a new operator-configured range is learned during session establishment 👀. At this point, the local PCEP speaker MUST remove any associations that are not in the new operator-configured range. It does this by disassociating any LSPs that are part of them (and notifying the PCEP peer of this change) 🧹. If a PCEP speaker receives an association for an Operator-configured Association, and the Association ID is not in the Operator-configured Association Range for the Association Type and Association Source, it MUST generate an error (as described in Section 6.4) 🚨.

6. ASSOCIATION Object ✨

6.1. Object Definition

Association groups and their memberships are defined using a new ASSOCIATION object 🎀.

The ASSOCIATION Object-Class value is 40 💜.

The ASSOCIATION Object-Type value is 1 for IPv4, and its format is shown in Figure 3 🌸:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reserved              |            Flags            |R|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Association Type         |      Association ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              IPv4 Association Source                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                   Optional TLVs                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: The IPv4 ASSOCIATION Object Format

The ASSOCIATION Object-Type value is 2 for IPv6, and its format is shown in Figure 4 🧚‍♀️:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reserved              |            Flags            |R|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Association Type         |      Association ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                    IPv6 Association Source                    |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                   Optional TLVs                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: The IPv6 ASSOCIATION Object Format

Here's the breakdown of the fields 📝:

  • Reserved (2 bytes): MUST be set to 0 and ignored upon receipt 🫧.
  • Flags (2 bytes): The following flag is currently defined 🚩:
    • R (Removal - 1 bit): When set, the requesting PCEP peer requires the removal of an LSP from the association group. When unset, the PCEP peer indicates that the LSP is added or retained as part of the association group. This flag is used for the ASSOCIATION object in the Path Computation Report (PCRpt) and Path Computation Update (PCUpd) messages. It is ignored in other PCEP messages 🗑️.
  • The unassigned flags MUST be set to 0 on transmission and MUST be ignored on receipt 🙏.
  • Association Type (2 bytes): The Association Type (Section 7.4). The Association Types will be defined in future documents 🔮.
  • Association ID (2 bytes): The identifier of the association group. When combined with other association parameters, such as an Association Type and Association Source, this value uniquely identifies an association group 🆔. The values 0xffff and 0x0 are reserved. The value 0xffff is used to indicate all association groups, and it could be used with the R flag to indicate removal for all associations for the LSP within the scope of the Association Type and Association Source 💅.
  • Association Source: Contains a valid IPv4 address (4 bytes) if the ASSOCIATION Object-Type is 1, or a valid IPv6 address (16 bytes) if the ASSOCIATION Object-Type is 2. The address provides scoping for the Association ID. See Section 6.1.3 for details 📍.
  • Optional TLVs: The optional TLVs follow the PCEP TLV format defined in [RFC5440]. This document defines two optional TLVs. Other documents can define more TLVs in the future 🌟.

6.1.1. Global Association Source TLV

The Global Association Source TLV is an optional TLV for use in the ASSOCIATION object. Its meaning and usage are as per Section 4 of [RFC6780] 🌍.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type                  |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Global Association Source                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: The Global Association Source TLV Format

  • Type: 30
  • Length: Fixed value of 4 bytes.
  • Global Association Source: As defined in Section 4 of [RFC6780].

6.1.2. Extended Association ID TLV

The Extended Association ID TLV is an optional TLV for use in the ASSOCIATION object. Its meaning and usage are as per Section 4 of [RFC6780] 🧩.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type                  |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                Extended Association ID                      //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: The Extended Association ID TLV Format

  • Type: 31
  • Length: Variable.
  • Extended Association ID: As defined in Section 4 of [RFC6780].

6.1.3. Association Source

The Association Source field in the ASSOCIATION object is set to a valid IP address that identifies the node which originated the association 📡. For dynamic associations, the Association Source is usually set as the local PCEP speaker address, unless local policy dictates otherwise. In that case, the Association Source is set based on the local policy 🗺️. With PCE redundancy, local policy could set the source as a virtual IP address that identifies all instances of the PCE 👯‍♀️. For Operator-configured Associations, the Association Source is manually configured. It could be set as one of the PCEP speakers, an NMS, or any other valid IP address that scopes the Association ID for the Association Type 🎯.

6.1.4. Unique Identification for an Association Group

The combination of the mandatory fields Association Type, Association ID, and Association Source in the ASSOCIATION object uniquely identifies the association group 🔑. If the optional TLVs (Global Association Source and Extended Association ID) are included, then they MUST be included in combination with the mandatory fields to uniquely identify the association group 🧷. In this document, all these fields are collectively called "association parameters" 💜.

The ASSOCIATION object MAY include other optional TLVs (not defined in this document) based on the Association Types. Note that these TLVs provide "information" related to the Association Type. This document refers to this information as "association information" ✨.

6.2. Relationship to the RSVP ASSOCIATION Object

The format of the PCEP ASSOCIATION object defined in this document is aligned with the RSVP ASSOCIATION object [RFC6780] 🥰. Various Association Types related to RSVP association are defined in [RFC4872], [RFC4873], and [RFC7551]. The PCEP extensions that define new Association Types should clarify how the PCEP associations would work with RSVP associations, and vice versa 🌷.

6.3. Object Encoding in PCEP Messages

Message formats in this document are expressed using Routing BNF (RBNF) as used in [RFC5440] and defined in [RFC5511] 📐.

6.3.1. Stateful PCEP Messages ✨

Okay so the ASSOCIATION object MAY be carried in PCUpd, PCRpt, and Path Computation Initiate (PCInitiate) messages 💖

When it shows up in a PCRpt message, it's how you tell a stateful PCE which association group(s) an LSP belongs to 🦋. PCRpt is used for initial State Synchronization operations (Section 5.6 of [RFC8231]), and also whenever the state of the LSP changes. If the LSP belongs to an association group, the associations MUST be included during the State Synchronization operations. No exceptions, bestie 🙈

A PCRpt message can also remove an LSP from one or more association groups by setting the R flag to 1 in the ASSOCIATION object 👋

When an LSP is first reported to the PCE, the PCRpt message MUST include all the association groups that it belongs to. Any later PCRpt message SHOULD include only the associations that are being modified or removed 💅

The PCRpt message is defined in [RFC8231] and updated as shown below:

   <PCRpt Message> ::= <Common Header>
                       <state-report-list>

   Where:

         <state-report-list> ::= <state-report>[<state-report-list>]

         <state-report> ::= [<SRP>]
                            <LSP>
                            [<association-list>]
                            <path>

   Where:

         <path>::= <intended-path>
                   [<actual-attribute-list><actual-path>]
                   <intended-attribute-list>

         <association-list> ::= <ASSOCIATION> [<association-list>]

When an LSP is delegated to a stateful PCE, the stateful PCE can create a new association group for this LSP, or associate it with one or more existing association groups. This is done by including the ASSOCIATION object in a PCUpd message. A stateful PCE can also remove a delegated LSP from one or more association groups by setting the R flag to 1 in the ASSOCIATION object 🌸

The PCUpd message SHOULD include the association groups that are being modified or removed. There is no need to include associations that remain unchanged 🧚

The PCUpd message is defined in [RFC8231] and updated as shown below:

    <PCUpd Message> ::= <Common Header>
                        <update-request-list>

   Where:

       <update-request-list> ::= <update-request>[<update-request-list>]

       <update-request> ::= <SRP>
                            <LSP>
                            [<association-list>]
                            <path>

   Where:

       <path>::= <intended-path><intended-attribute-list>

       <association-list> ::= <ASSOCIATION> [<association-list>]

Unless a PCEP speaker wants to delete an association from an LSP or make changes to the association, it does not need to include the ASSOCIATION object in future stateful messages. Easy breezy 🎀

A PCE initiating a new LSP can also include the association groups that this LSP belongs to. This is done by including the ASSOCIATION object in a PCInitiate message. The PCInitiate message MUST include all the association groups that it belongs to. The PCInitiate message is defined in [RFC8281] and updated as shown below:

   <PCInitiate Message> ::= <Common Header>
                            <PCE-initiated-lsp-list>

   Where:

   <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
                                [<PCE-initiated-lsp-list>]

   <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
                                   <PCE-initiated-lsp-deletion>)

   <PCE-initiated-lsp-instantiation> ::= <SRP>
                                         <LSP>
                                         [<END-POINTS>]
                                         <ERO>
                                         [<association-list>]
                                         [<attribute-list>]

   Where:

   <association-list> ::= <ASSOCIATION> [<association-list>]

6.3.2. Request Message 🍓

In the case of a passive (stateful or stateless) PCE, the ASSOCIATION object is OPTIONAL and MAY be carried in the PCReq message. Optional but still allowed, so cute 🌈

When it rides along in a PCReq message, the ASSOCIATION object is used to link the path computation request to an association group. The association (and the other LSPs) should be known to the PCE beforehand. These could be operator configured, or dynamically learned beforehand via stateful PCEP messages. The R flag in the ASSOCIATION object within a PCReq message MUST be set to 0 while sending and ignored on receipt 🙃

The PCReq message is defined in [RFC5440] and updated in [RFC8231]. It is further updated below for association groups:

   <PCReq Message>::= <Common Header>
                      [<svec-list>]
                      <request-list>

   Where:

      <svec-list>::= <SVEC>[<svec-list>]
      <request-list>::= <request>[<request-list>]

      <request>::= <RP>
                   <END-POINTS>
                   [<LSP>]
                   [<LSPA>]
                   [<BANDWIDTH>]
                   [<metric-list>]
                   [<association-list>]
                   [<RRO>[<BANDWIDTH>]]
                   [<IRO>]
                   [<LOAD-BALANCING>]

   Where:

      <association-list> ::= <ASSOCIATION> [<association-list>]

Note that the LSP object MAY be present for the passive stateful PCE mode 🦋

6.3.3. Reply Message 💜

In the case of a passive (stateful or stateless) PCE, the ASSOCIATION object is OPTIONAL and MAY be carried in the PCRep message with the NO-PATH object. The ASSOCIATION object in the PCRep message indicates the association group that caused the PCE to fail to find a path. So that's how the PCE says "it was THIS group that made it impossible" 😭

The PCRep message is defined in [RFC5440] and updated in [RFC8231]. It is further updated below for association groups:

   <PCRep Message> ::= <Common Header>
                       <response-list>

   Where:

      <response-list>::=<response>[<response-list>]

      <response>::=<RP>
                   [<LSP>]
                   [<NO-PATH>]
                   [<association-list>]
                   [<attribute-list>]
                   [<path-list>]

   Where:

      <association-list> ::= <ASSOCIATION> [<association-list>]

Note that the LSP object MAY be present for the passive stateful PCE mode 🌸

6.4. Processing Rules 🎀

Okay so association groups can be configured by the operator on the PCEP speakers that need them, and PCEP speakers can also join existing association groups 💖. On top of that, a PCC or a PCE can create association groups dynamically, and a PCEP speaker can report its associations to its peer through PCEP messages ✨. Operator-configured Associations are made through configurations where every association parameter is set by hand, and they stick around until someone explicitly removes them through configurations 🧚. The PCEP speaker can add LSPs to these configured associations and pass that info along in stateful PCEP messages 💅. Dynamic associations are the ones the PCEP speaker creates on its own, where every association parameter gets filled in dynamically 🦋. The association group is attached to the LSP state, and it lives as long as there's at least one LSP in it 🌸. As Section 6.1.4 explains, the association parameters are the combo of Association Type, Association ID, and Association Source, plus the optional Global Association Source and Extended Association ID TLVs. That whole combo is what uniquely identifies an association group 🔥. The info for each Association Type, encoded in the TLVs of that particular type (which this document doesn't describe), is the association information (Section 6.1.4) 💜.

Now, the error stuff, which is super important bestie 😭. If a PCEP speaker doesn't recognize the ASSOCIATION object in the stateful message, it sends back a PCErr message with Error-Type "Unknown Object", as described in [RFC5440]. For a PCReq message, the PCE reacts based on the P flag, per [RFC5440] 🙈. If a PCEP speaker understands the ASSOCIATION object but doesn't support the Association Type, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 1 "Association Type is not supported" 🚫. If any association parameters are invalid in the ASSOCIATION object, the PCEP speaker treats the object as malformed and processes it as a malformed message [RFC5440] 💀. When a PCEP speaker gets a PCEP message with an ASSOCIATION object and finds that too many LSPs belong to the association group, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 2 "Too many LSPs in the association group" 😤. If a PCEP speaker can't handle a new association, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 3 "Too many association groups" 🥺. These numbers MAY be set by the operator or chosen based on a local policy 🍓.

If a PCE peer is unwilling or unable to process the ASSOCIATION object in the stateful message, it MUST return a PCErr message with the Error-Type "Not supported object" and follow the relevant procedures described in [RFC5440] 🙅‍♀️. For a PCReq message, the PCE reacts based on the P flag, per [RFC5440] 💅. When a PCEP speaker gets a PCEP message with an ASSOCIATION object and couldn't add the LSP to the association group for any reason, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 7 "Cannot join the association group" 😩.

If a PCEP speaker receives an ASSOCIATION object for an Operator-configured Association and the Association ID isn't in the Operator-configured Association Range for that Association Type and Association Source, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 8 "Association ID not in range" 🙃.

If a PCEP speaker receives an ASSOCIATION object in a PCReq message and the association isn't known (it wasn't configured, wasn't created dynamically, and wasn't learned from a PCEP peer), it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 4 "Association unknown" 🫠.

If the association information (the stuff about the association group as a whole) from the peer doesn't match the local operator-configured information, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 5 "Operator-configured association information mismatch" 🚨. When it receives association information (about the group as a whole) that doesn't match what it got earlier from a peer for that same association, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 6 "Association information mismatch" 😵‍💫. Note that the info about each LSP inside the association, carried in the association information TLVs, can be different from LSP to LSP 🌈.

If a PCEP speaker receives an ASSOCIATION object with the R bit set for removal and the association group (identified by its association parameters) isn't known, it MUST return a PCErr message with Error-Type 26 "Association Error" and Error-value 4 "Association unknown" 🗑️.

Now for cleanup, which is lowkey the most dramatic part 🎭. The dynamic associations get cleared along with the LSP state information, as per [RFC8231] ✨. When a PCEP session is terminated, the LSP state linked to that session reverts to the operator-defined default parameters or behaviors, once the State Timeout Interval at the PCC expires. The same procedure applies to association groups 🦋. When a session ends at the PCE and the LSP state reported by the PCC gets cleared, the association groups are cleared too. When an association group has no LSPs left, it's considered empty and gets deleted 🗑️.

If the LSP gets delegated to another PCE when a session fails, the associations (and association information) set by the first PCE stay intact, unless the new PCE that takes over updates them 🫶.

When LSP delegation is revoked, the PCC MAY clear the association created by the PCE. To avoid traffic loss, though, it SHOULD do this in a make-before-break fashion (same as [RFC8231]) 🌸.

7. IANA Considerations 👑

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

7.1. PCEP Object 🧚

The "Path Computation Element Protocol (PCEP) Numbers" registry has a subregistry called "PCEP Objects". IANA has allocated the following code point in the "PCEP Objects" registry 💖.

   +--------------------+-------------+-------------+-----------+
   | Object-Class Value | Name        | Object-Type | Reference |
   +====================+=============+=============+===========+
   | 40                 | ASSOCIATION | 0: Reserved | RFC 8697  |
   |                    |             +-------------+-----------+
   |                    |             | 1: IPv4     | RFC 8697  |
   |                    |             +-------------+-----------+
   |                    |             | 2: IPv6     | RFC 8697  |
   +--------------------+-------------+-------------+-----------+

                        Table 1: PCEP Object

7.2. PCEP TLV 🎀

IANA has allocated the following code points in the "PCEP TLV Type Indicators" registry 🦋.

    +-------+---------------------------------------+-----------+
    | Value | Meaning                               | Reference |
    +=======+=======================================+===========+
    | 29    | Operator-configured Association Range | RFC 8697  |
    +-------+---------------------------------------+-----------+
    | 30    | Global Association Source             | RFC 8697  |
    +-------+---------------------------------------+-----------+
    | 31    | Extended Association ID               | RFC 8697  |
    +-------+---------------------------------------+-----------+

                  Table 2: PCEP TLV Type Indicators

IANA has corrected the capitalization in the meaning for value 31 in the above registry to "Extended Association ID". It was previously listed as "Extended Association Id" 🔤.

IANA has also made a new assignment in the existing "PCEP TLV Type Indicators" registry, as follows 🆕:

               +-------+-----------------+-----------+
               | Value | Meaning         | Reference |
               +=======+=================+===========+
               | 35    | ASSOC-Type-List | RFC 8697  |
               +-------+-----------------+-----------+

                  Table 3: ASSOC-Type-List PCEP TLV
                            Type Indicator

7.3. Association Flags 🏳️‍🌈

Per this document, IANA has created a subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry for the bits carried in the Flags field of the ASSOCIATION object 💜. The subregistry is called "ASSOCIATION Flag Field". New values are assigned by Standards Action [RFC8126]. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)
  • Capability description
  • Defining RFC
                  +-----+-------------+-----------+
                  | Bit | Description | Reference |
                  +=====+=============+===========+
                  | 15  | R (Removal) | RFC 8697  |
                  +-----+-------------+-----------+

                    Table 4: New ASSOCIATION Flag
                                Field

7.4. Association Type 🌟

Per this document, IANA has created a subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry for the Association Type field of the ASSOCIATION object 🍓. The subregistry is called "ASSOCIATION Type Field". New values are assigned by Standards Action [RFC8126]. Each value is tracked with the following qualities:

  • Type
  • Name
  • Reference
                   +------+----------+-----------+
                   | Type | Name     | Reference |
                   +======+==========+===========+
                   | 0    | Reserved | RFC 8697  |
                   +------+----------+-----------+

                       Table 5: New ASSOCIATION
                              Type Field

Values 2-65535 are Unassigned. Future documents should request the assignment of Association Types from this subregistry 🔮.

Okay bestie, picking up right where we left off. Section 7.5 is the error code table, then the security stuff gets serious 🙈

7.5. PCEP-Error Object 💌

okay so IANA has allocated these code points in the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry 🦋 every single one lives under Error-Type 26, which is the Association Error, and they all point back to RFC 8697 💖

     +------------+-------------+------------------------+-----------+
     | Error-Type | Meaning     | Error-value            | Reference |
     +============+=============+========================+===========+
     | 26         | Association | 0: Unassigned          | RFC 8697  |
     |            | Error       +------------------------+-----------+
     |            |             | 1: Association Type is | RFC 8697  |
     |            |             | not supported          |           |
     |            |             +------------------------+-----------+
     |            |             | 2: Too many LSPs in    | RFC 8697  |
     |            |             | the association group  |           |
     |            |             +------------------------+-----------+
     |            |             | 3: Too many            | RFC 8697  |
     |            |             | association groups     |           |
     |            |             +------------------------+-----------+
     |            |             | 4: Association unknown | RFC 8697  |
     |            |             +------------------------+-----------+
     |            |             | 5: Operator-configured | RFC 8697  |
     |            |             | association            |           |
     |            |             | information mismatch   |           |
     |            |             +------------------------+-----------+
     |            |             | 6: Association         | RFC 8697  |
     |            |             | information mismatch   |           |
     |            |             +------------------------+-----------+
     |            |             | 7: Cannot join the     | RFC 8697  |
     |            |             | association group      |           |
     |            |             +------------------------+-----------+
     |            |             | 8: Association ID not  | RFC 8697  |
     |            |             | in range               |           |
     +------------+-------------+------------------------+-----------+

Table 6: PCEP-ERROR Types and Names 📋

8. Security Considerations 🔐

okay bestie, this part is SERIOUS 😭 the security considerations from [RFC8231] and [RFC5440] apply to these extensions too, no skipping 💅 plus there are extra worries about a malicious PCEP speaker 💀 associations can get spoofed and used as an attack vector!! an attacker could try making way too many associations just to overload a PCEP peer, and the peer answers with a PCErr message like Section 6.4 says 🚨 an attacker can also mess with LSP operations by making bogus associations, and association groups could let an adversary eavesdrop on how the LSPs are related 👀

so securing the PCEP session with Transport Layer Security (TLS) [RFC8253], following the recommendations and best current practices in [RFC7525], is RECOMMENDED 🔒✨

Heads up: RECOMMENDED here is the real deal, so it's not a suggestion you can just ignore 🫶

Lowkey the good news is that most of the info in the ASSOCIATION object isn't super sensitive 🌸 it's usually stuff you could already work out from the LSP database, but the association just makes grouping related LSPs and messages way easier 💖 implementations and operators can, and should, use indirect values in the ASSOCIATION object to hide any sensitive business relationships 🧚 that "should" is doing a lot of work, iykyk 💅

9. Manageability Considerations 🛠️

all the manageability requirements in [RFC5440] and [RFC8231] apply to the PCEP extensions in this document too 🎀 on top of that, the stuff in this section also applies 💜

9.1. Control of Function and Policy 👑

a PCE or PCC implementation MUST allow Operator-configured Associations 🔥 and it SHOULD allow setting the Operator-configured Association Range (Section 3.4) as described in this document 💅

9.2. Information and Data Models 📊

the PCEP YANG module is defined in [PCEP-YANG] 🦋 later on, this YANG module should be extended or augmented to give more info about association groups, like the following:

An implementation SHOULD allow the operator to view the associations configured or created dynamically 👀 and future implementations SHOULD allow viewing the associations reported by each peer, plus the current set of LSPs in each association ✨

it might also be useful to know how many associations of each Association Type currently exist, and how many free Association IDs are available for a given Association Type and source 🍓 honestly that's so helpful omg 🙈

9.3. Liveness Detection and Monitoring 💓

mechanisms in this document don't add any new liveness detection and monitoring requirements beyond the ones already in [RFC5440] 🫶

9.4. Verifying Correct Operation ✅

same vibe here: mechanisms in this document don't add any new operation verification requirements beyond the ones already listed in [RFC5440] and [RFC8231] 💖

9.5. Requirements on Other Protocols 🌈

mechanisms in this document don't add any new requirements on other protocols 🧚

9.6. Impact on Network Operations 🌸

the mechanisms in [RFC5440] and [RFC8231] also apply to the PCEP extensions in this document 💅

10. References 📚

10.1. Normative References 💜

10.2. Informative References 🧠

That's the end of part 6 💖 part 7 is coming next, so stay tuned bestie 🦋✨

Appendix A. Example of an Operator-Configured Association Range ✨

okay bestie, let's walk through a worked example 🎀 Say we have an Association Type T1. It allows both dynamic and Operator-configured Associations, and its default range is <0x1000, 0xffff> 💖.

Now the PCE is like "I need more dynamic associations," so it wants to change the Association Range to <0xbffe, 0xffff> instead 🦋. During PCEP session establishment, the PCE advertises that new range. The PCC could skip advertising, because the default values are being used 🌸.

Here's how the IDs get picked:

  • If a PCC is creating a dynamic association (with the PCC as the Association Source), it needs to pick a free Association ID for type T1 in <0x1, 0x0fff> 💅.
  • If a PCE is creating a dynamic association (with the PCE as the Association Source), it needs to pick a free Association ID from <0x1, 0xbffd> 🧚.
  • If an Operator-configured Association is manually configured with the PCC as the Association Source, it should be from <0x1000, 0xffff> 🍓.
  • If the PCE is the Association Source, it should be from <0xbffe, 0xffff> 👑.
  • If the Association Source is not a PCEP peer (for example, an NMS), then the default range of <0x1000, 0xffff> is considered 💜.

Acknowledgments

We would like to thank Yuji Kamite and Joshua George for their contributions to this document 🫶. Thanks also to Venugopal Reddy, Cyril Margaria, Rakesh Gandhi, Mike Koldychev, and Adrian Farrel for their useful comments ✨.

We would like to thank Julien Meuric for shepherding this document and providing comments with text suggestions 🌈.

Thanks to Stig Venaas for the RTGDIR review comments 🦋.

Thanks to Alvaro Retana, Mirja Kühlewind, Martin Vigoureux, Barry Leiba, Eric Vyncke, Suresh Krishnan, and Benjamin Kaduk for the IESG comments 💖.

Contributors

Here are the people who helped build this one, bestie 🌸

Stephane Litkowski
Orange

Email: stephane.litkowski@orange.com
Xian Zhang
Huawei Technologies
F3-1-B RnD Center, Huawei Base
Bantian, Longgang District
Shenzhen, 518129
China

Email: zhang.xian@huawei.com
Mustapha Aissaoui
Nokia

Email: mustapha.aissaoui@nokia.com

Authors' Addresses

And here are the authors, who are absolutely iconic 👑💅

Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America

Email: inaminei@google.com
Edward Crabbe
Individual Contributor

Email: edward.crabbe@gmail.com
Siva Sivabalan
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America

Email: msiva@cisco.com
Hariharan Ananthakrishnan
Netflix

Email: hari@netflix.com
Dhruv Dhody
Huawei
Divyashree Techno Park, Whitefield
Bangalore 560066
KA
India

Email: dhruv.ietf@gmail.com
Yosuke Tanaka
NTT Communications Corporation
Granpark Tower 3-4-1 Shibaura, Minato-ku, Tokyo
108-8118
Japan

Email: yosuke.tanaka@ntt.com

And that's a wrap on RFC 8697, bestie 🌈✨ we did it, we're literally the protocol girlies 😭💖

📦 where this page comes from