RFC 9604

Carrying Binding Label/SID in PCE-Based Networks

📅 published August 2024, from ietf

RFC 9604: Carrying Binding Label/SID in PCE-Based Networks ✨

Okay bestie, let's get into this one 🦋 RFC 9604 is a Standards Track document, which basically means it's an actual Internet standard and not just a vibe. It was written by S. Sivabalan (Ciena Corporation), C. Filsfils (Cisco Systems, Inc.), J. Tantsura (Nvidia), S. Previdi (no affiliation listed), and C. Li, Ed. (Huawei Technologies). It was published in August 2024 and its ISSN is 2070-1721. 💅

Quick note on the title block: this RFC doesn't list anything it obsoletes or updates, so there's nothing it replaces or patches. It's a brand new extension 🌸

The whole point is PCEP (the Path Computation Element Communication Protocol) getting a glow-up so a PCC can report the binding label/SID it allocated to a PCE, and a PCE can ask a PCC to allocate a specific one. 🧚

Status of This Memo 🎀

This is an Internet Standards Track document, so it's officially part of the Internet standards line-up 👑

It's a product of the IETF, it represents consensus from the IETF community, it got public review, and the IESG approved it for publication. If you want more on Internet Standards, check out Section 2 of RFC 7841. And for errata, feedback, and the current status, head to https://www.rfc-editor.org/info/rfc9604 🫶

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. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License. ⚖️💖

Table of Contents 📖

1.  Introduction
  1.1.  Motivation and Example
  1.2.  Summary of the Extension
2.  Requirements Language
3.  Terminology
4.  Path Binding TLV
  4.1.  SRv6 Endpoint Behavior and SID Structure
5.  Operation
6.  Binding SID in SR-ERO
7.  Binding SID in SRv6-ERO
8.  PCE Allocation of Binding Label/SID
9.  Security Considerations
10. Manageability Considerations
  10.1.  Control of Function and Policy
  10.2.  Information and Data Models
  10.3.  Liveness Detection and Monitoring
  10.4.  Verify Correct Operations
  10.5.  Requirements on Other Protocols
  10.6.  Impact on Network Operations
11. IANA Considerations
  11.1.  PCEP TLV Type Indicators
    11.1.1.  TE-PATH-BINDING TLV
  11.2.  LSP Object
  11.3.  PCEP Error Type and Value
12. References
  12.1.  Normative References
  12.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🌸

A Path Computation Element (PCE) can work out Traffic Engineering (TE) paths through a network, where those paths have to follow various constraints 💅 Right now, TE paths get set up with either the RSVP-TE signaling protocol or Segment Routing (SR). In this document we call them "RSVP-TE paths" and "SR-TE paths", respectively ✨

As per [RFC8402], SR lets a head-end node steer a packet flow along a given path via an SR Policy. And as per [RFC9256], an SR Policy is a framework for setting up an ordered list of segments on a node, so it can carry out a source routing policy with a specific traffic steering intent from that node 🧚

As described in [RFC8402], a Binding SID (BSID) is bound to an SR Policy, and setting that policy up might involve a list of Segment Identifiers (SIDs). Any packet that arrives with an active segment equal to a BSID gets steered onto the bound SR Policy 🦋 A BSID can be either local (from the SR Local Block (SRLB)) or global (from the SR Global Block (SRGB)). As per Section 6.4 of [RFC9256], a BSID can also be tied to any type of interface or tunnel, so a non-SR interface or tunnel can be used as a segment in a SID list 🌈 In this document, "binding label/SID" is the umbrella term for allocating a binding value for both SR and non-SR paths. Iconic generalization, honestly 👑

[RFC5440] describes PCEP for communication between a Path Computation Client (PCC) and a PCE, or between a pair of PCEs as per [RFC4655]. [RFC8231] adds PCEP extensions that let a PCC delegate its Label Switched Paths (LSPs) to a stateful PCE. A stateful PCE can then update the state of the LSPs delegated to it 🎀 [RFC8281] gives a PCE a way to dynamically instantiate an LSP on a PCC by sending it the path and its characteristics. This document adds a PCEP extension to manage the binding of a label/SID, which can be applied to SR, RSVP-TE, and other path setup types. Main character energy 💖

[RFC8664] gives a PCE (acting as a network controller) a way to instantiate SR-TE paths (candidate paths) for an SR Policy onto a head-end node (acting as a PCC) using PCEP. For more on the SR Policy Architecture, see [RFC9256] 🫶

1.1. Motivation and Example 🍓

A binding label/SID has local significance to the ingress node of the corresponding TE path. So when a stateful PCE is set up for TE paths, a binding label/SID that the PCC reports to it is super useful for enforcing an end-to-end TE/SR policy 😭 Figure 1 shows a sample Data Center (DC) and IP/MPLS WAN use case with a multi-domain PCE. In the IP/MPLS WAN, the PCE sets up an SR-TE LSP with the SID list {A, B, C, D}. The gateway Node-1 (the PCC) allocates a binding SID X and reports it to the PCE. Then, in the MPLS DC network, an end-to-end SR-TE LSP gets established. For the access node to steer traffic toward Node-1 and over the SR-TE path in the WAN, the PCE passes the SID stack {Y, X} to the access node, where Y is the node SID of gateway Node-1 and X is the BSID 💅 Without the BSID X, the PCE would have to pass {Y, A, B, C, D} to the access node instead. This example also shows the extra perk of using a binding label/SID: it cuts down how many SIDs the access nodes have to impose, which helps the ones with limited forwarding capacity 🧚

        SID stack
        {Y, X}              +--------------+
                            | Multi-domain |
 _ _ _ _ _ _ _ _ _ _ _ _ _ _|     PCE      |
|                           +--------------+
|                              ^
|                              | Binding
|           .-----.            | SID (X)     .-----.
|          (       )           |            (       )
V       .--(         )--.      |        .--(         )--.
+------+  (                 )  +-------+  (                 )  +-------+
|Access|_(  MPLS DC Network  )_|Gateway|_(    IP/MPLS WAN    )_|Gateway|
| Node | (  ==============>  ) |Node-1 | ( ================> ) |Node-2 |
+------+  (    SR-TE path   )  +-------+  (    SR-TE path   )  +-------+
           '--(         )--'    Node       '--(         )--'
               (       )        SID of         (       )
                '-----'         Node-1          '-----'
                                is Y            SIDs for SR-TE LSP:
                                                {A, B, C, D}

              Figure 1: A Sample Use Case of Binding SID

Using the extension in this document, a PCC can report the binding label/SID it allocated to the stateful PCE in a Path Computation LSP State Report (PCRpt) message. A stateful PCE can also ask a PCC to allocate a specific binding label/SID by sending a Path Computation LSP Update Request (PCUpd) message. If the PCC can successfully allocate the requested binding value, it reports that value back to the PCE. If it can't, the PCC sends an error message to the PCE that explains why it failed 🥺 A local policy or configuration at the PCC SHOULD dictate whether a binding label/SID needs to be assigned 🌸

1.2. Summary of the Extension 🦋

To make the PCEP changes happen, this document introduces a new OPTIONAL TLV. It lets a PCC report the binding label/SID associated with a TE LSP, or lets a PCE ask a PCC to allocate any binding label/SID value or a specific one 🎀 The TLV is meant for TE LSPs set up with RSVP-TE, SR-TE, or any other future method. For SR-TE LSPs, the TLV can carry a binding label (for SR-TE paths using the MPLS data plane) or a binding IPv6 SID (for example an IPv6 address, for SR-TE paths using the IPv6 data plane). Throughout this document, "binding value" means either an MPLS label or a SID 💜

There's another way to use this extension too. To support PCE-based central controller [RFC8283] operation, where the PCE takes charge of managing some part of the MPLS label space for each router it controls, the PCE can make the binding label/SID allocation itself and tell the PCC about it. Check Section 8 for the details 🧚

On top of defining the new TLV, this document also spells out how and when a PCC and PCE can use it, how they can allocate a binding label/SID, and how errors get handled ✨

2. 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 🫶

3. Terminology 📖

The following terms are used in this document 🌈

  • BSID: Binding SID
  • binding label/SID: a generic term used for the binding segment for both SR and non-SR paths
  • binding value: a generic term used for the binding segment as it can be encoded in various formats (as per the Binding Type (BT))
  • LSP: Label Switched Path
  • PCC: Path Computation Client
  • PCEP: Path Computation Element Communication Protocol
  • RSVP-TE: Resource Reservation Protocol - Traffic Engineering
  • SID: Segment Identifier
  • SR: Segment Routing

Part 1 of 5. Sections 4 onward are coming next, so stay tuned, bestie 🌸💅

4. Path Binding TLV ✨

okay bestie, this is where we get to the TE-PATH-BINDING TLV 💖. It's an optional TLV (type-length-value chunk) that carries the binding label/SID for a TE path. It's tied to the LSP object from [RFC8231], and it can also show up in the PCEP-ERROR object from [RFC5440] when something goes wrong 🙈. You can have multiple instances in both the LSP and PCEP-ERROR objects, which is allowed (MAY, not required). The type is 55 and the length is variable.

      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 = 55           |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      BT       |    Flags      |            Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~            Binding Value (variable length)                    ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2: TE-PATH-BINDING TLV

The TE-PATH-BINDING TLV is generic, so it can carry a binding label/SID, meaning either an MPLS label or an SRv6 SID. It follows the formatting rules in [RFC5440]. The value part is made up of:

  • Binding Type (BT): a one-octet field that says what kind of binding is in the TLV. This document defines these BT values:
    • BT = 0: the binding value is a 20-bit MPLS label. The TLV is padded to 4-byte alignment. The Length MUST be set to 7 (padding isn't counted in the length, as per Section 7.1 of [RFC5440]), and the first 20 bits encode the MPLS label.
    • BT = 1: the binding value is a 32-bit MPLS Label Stack Entry as per [RFC3032], with Label, Traffic Class (TC) [RFC5462], S, and TTL values encoded. The receiver MAY choose to override the TC, S, and TTL values according to its local policy. The Length MUST be set to 8.
    • BT = 2: the binding value is an SRv6 SID in the form of a 16-octet IPv6 address, representing the binding SID for SRv6. The Length MUST be set to 20.
    • BT = 3: the binding value is a 24-octet field, defined in Section 4.1, that holds the SRv6 SID along with its Behavior and Structure. The Length MUST be set to 28.

Section 11.1.1 defines the IANA registry used to maintain these binding types, plus any future ones. Multiple TE-PATH-BINDING TLVs with the same or different binding types MAY be present for the same LSP. A PCEP speaker could allocate several TE-PATH-BINDING TLVs (of the same BT) and use different binding values in different domains or use cases, based on local policy.

  • Flags: 1 octet of flags. The following flag is defined in the "TE-PATH-BINDING TLV Flag field" registry, as described in Section 11.1.1:
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R|             |
+-+-+-+-+-+-+-+-+

                         Figure 3: Flags

Where:

  • R (Removal - 1 bit): when set, the requesting PCEP peer requires the removal of the binding value for the LSP. When unset, the PCEP peer indicates that the binding value is added or retained for the LSP. This flag is used in the PCRpt and PCUpd messages and is ignored in other PCEP messages.
  • The unassigned flags MUST be set to 0 while sending and ignored on receipt.
  • Reserved: MUST be set to 0 while sending and ignored on receipt.
  • Binding Value: a variable-length field, padded with trailing zeros to a 4-octet boundary. When the BT is 0, the 20 bits represent the MPLS label. When the BT is 1, the 32 bits represent the MPLS label stack entry as per [RFC3032]. When the BT is 2, the 128 bits represent the SRv6 SID. When the BT is 3, the binding value also contains the SRv6 Endpoint Behavior and SID Structure, defined in Section 4.1. In this document, the TE-PATH-BINDING TLV is considered to be empty if no binding value is present. In that case, the length of the TLV would be 4.

4.1. SRv6 Endpoint Behavior and SID Structure

This section specifies the format of the binding value in the TE-PATH-BINDING TLV when the BT is set to 3, for the SRv6 Binding SIDs [RFC8986]. Here's the layout 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                 SRv6 Binding SID (16 octets)                  |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reserved              |      Endpoint Behavior        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    LB Length  |    LN Length  | Fun. Length   |  Arg. Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4: SRv6 Endpoint Behavior and SID Structure

The Binding Value is made up of:

  • SRv6 Binding SID: 16 octets. This is the 128-bit IPv6 address representing the binding SID for SRv6.
  • Reserved: 2 octets. It MUST be set to 0 on transmit and ignored on receipt.
  • Endpoint Behavior: 2 octets. This is the Endpoint Behavior code point for this SRv6 SID, as defined by the "SRv6 Endpoint Behaviors" registry [RFC8986]. When the field is set to 0, the Endpoint Behavior is considered unknown.
  • [RFC8986] defines an SRv6 SID as LOC:FUNCT:ARG, where the locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). A locator may be written as B:N, where B is the SRv6 SID locator block (the IPv6 prefix the operator allocated for SRv6 SIDs) and N is the identifier of the parent node instantiating the SID, called the "locator node". The following fields advertise the length of each part of the SRv6 SID:
    • LB Length: 1 octet. SRv6 SID Locator Block length in bits.
    • LN Length: 1 octet. SRv6 SID Locator Node length in bits.
    • Function Length: 1 octet. SRv6 SID Function length in bits.
    • Arguments Length: 1 octet. SRv6 SID Arguments length in bits.

The total of the locator block, locator node, function, and arguments lengths MUST be less than or equal to 128 bits. If this condition isn't met, the corresponding TE-PATH-BINDING TLV is considered invalid. Also, if the Endpoint Behavior is found to be unknown or inconsistent, it's considered invalid. In those cases, a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 37 ("Invalid SRv6 SID Structure") MUST be sent 🚨.

The SRv6 SID Structure could be used by the PCE for ease of operations and monitoring. For example, this info could help validate SRv6 SIDs being instantiated in the network and check them for conformance with the SRv6 SID allocation scheme the operator chose, as described in Section 3.2 of [RFC8986]. In the future, the PCE could also be used for verification and for automatically securing the SRv6 domain by provisioning filtering rules at SR domain boundaries, as described in Section 5 of [RFC8754]. The details of these potential applications are outside the scope of this document 💅.

5. Operation ✨

Okay so the binding value is usually allocated by the PCC and then reported to a PCE through a PCRpt message 💅 (see Section 8 for when the PCE does the allocation 🫶). If a PCE doesn't recognize the TE-PATH-BINDING TLV, it would just ignore the TLV, per [RFC5440] 🙈. But if a PCE does recognize the TLV and just doesn't support it, it MUST send a PCErr with Error-Type = 2 ("Capability not supported") 💀.

Multiple TE-PATH-BINDING TLVs are allowed in the same LSP object 🦋. That means the LSP has multiple binding SIDs, which is very main character energy. When there are multiple TE-PATH-BINDING TLVs, the existing instances of them MAY be included in the LSP object. If there's an error, the whole message gets rejected 😭, and the resulting PCErr MAY include the offending TE-PATH-BINDING TLV in the PCEP-ERROR object.

If a PCE recognizes an invalid binding value (for example, a label value from the reserved MPLS label space), it MUST send a PCErr with Error-Type = 10 ("Reception of an invalid object") and Error-value = 2 ("Bad label value"), as specified in [RFC8664] 🚫.

For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV by setting BT to 3 ✨. This lets the sender be in control of the SRv6 Endpoint Behavior and SID Structure, which is so iconic. A sender MAY choose to set the BT to 2 instead. In that case, the receiving implementation decides how to interpret the SRv6 Endpoint Behavior and SID Structure based on its local policy 🧚.

If a PCC wants to withdraw a binding value it previously reported, it MUST send a PCRpt message with that specific TE-PATH-BINDING TLV and the R flag set to 1 🥀. If a PCC wants to modify a previously reported binding, it MUST withdraw the former binding value (with the R flag set in the former TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING TLV containing the new binding value 🔄. Note that other instances of TE-PATH-BINDING TLVs that are unchanged MAY also be included. If the unchanged instances are not included, they will remain associated with the LSP 🫶.

If a PCE needs a PCC to allocate one (or several) specific binding value(s), it may do so by sending a PCUpd or PCInitiate message containing one or more TE-PATH-BINDING TLVs 🎀. If the values can be successfully allocated, the PCC reports the binding values to the PCE. If the PCC considers the binding value specified by the PCE invalid, it MUST send a PCErr with Error-Type = 32 ("Binding label/SID failure") and Error-value = 1 ("Invalid SID") 🙅‍♀️. If the binding value is valid but the PCC can't allocate it, it MUST send a PCErr with Error-Type = 32 ("Binding label/SID failure") and Error-value = 2 ("Unable to allocate the specified binding value") 😩. Note that, in case of an error, the PCC rejects the PCUpd or PCInitiate message in its entirety, and it can include the offending TE-PATH-BINDING TLV in the PCEP-ERROR object.

If a PCE wants to request the withdrawal of a previously reported binding value, it MUST send a PCUpd message with that specific TE-PATH-BINDING TLV and the R flag set to 1 🥺. If a PCE wants to modify a previously requested binding value, it MUST request the withdrawal of the former binding value (with the R flag set in the former TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING TLV containing the new binding value 💫. If a PCC receives a PCUpd message with a TE-PATH-BINDING TLV where the R flag is set to 1, but either the binding value is missing (an empty TE-PATH-BINDING TLV) or the binding value is incorrect, it MUST send a PCErr with Error-Type = 32 ("Binding label/SID failure") and Error-value = 4 ("Unable to remove the binding value") 💔.

Sometimes a stateful PCE wants the PCC to allocate a binding value of the PCC's own choosing 🌈. It asks for that by sending a PCUpd message containing an empty TE-PATH-BINDING TLV, meaning no binding value is specified, which sets the Length field of the TLV to 4 🍓. A PCE can also ask for a binding value to be allocated at the time of initiation by sending a PCInitiate message with an empty TE-PATH-BINDING TLV. Only one such instance of an empty TE-PATH-BINDING TLV per BT SHOULD be included in the LSP object, and others should be ignored on receipt 👀. If the PCC can't allocate a new binding value for the specified BT, it MUST send a PCErr with Error-Type = 32 ("Binding label/SID failure") and Error-value = 3 ("Unable to allocate a new binding label/SID") 😤.

As mentioned before, if a message contains an invalid TE-PATH-BINDING TLV that leads to an error condition, the whole message is rejected, including any other valid TE-PATH-BINDING TLVs in it 🗑️. The resulting error message MAY include the offending TE-PATH-BINDING TLV in the PCEP-ERROR object.

If a PCC receives a TE-PATH-BINDING TLV in any message other than PCUpd or PCInitiate, it MUST close the corresponding PCEP session with the reason "Reception of a malformed PCEP message" (according to [RFC5440]) 🚪. Similarly, if a PCE receives a TE-PATH-BINDING TLV in any message other than a PCRpt, or if the TE-PATH-BINDING TLV is associated with any object other than an LSP or PCEP-ERROR object, the PCE MUST close the corresponding PCEP session with the reason "Reception of a malformed PCEP message" (according to [RFC5440]) 🛑.

If a TE-PATH-BINDING TLV is absent in the PCRpt message and no binding values were previously reported, the PCE MUST assume that the corresponding LSP does not have any binding 🤷‍♀️. Similarly, if a TE-PATH-BINDING TLV is absent in the PCUpd message and no binding values were previously reported, the PCC's local policy dictates how the binding allocations are made for that LSP 📋.

Some binding types have similar information but different binding value formats 🧩. For example, BT=(2 or 3) is used for the SRv6 SID, and BT=(0 or 1) is used for the MPLS Label. If a PCEP speaker receives multiple TE-PATH-BINDING TLVs with the same SRv6 SID or MPLS Label but different BT values, it MUST send a PCErr with Error-Type = 32 ("Binding label/SID failure") and Error-value = 5 ("Inconsistent binding types") 🙃.

6. Binding SID in SR-ERO 🌸

In PCEP messages, LSP route information is carried in the Explicit Route Object (ERO), which is made up of a sequence of subobjects 🧵. [RFC8664] defines the "SR-ERO subobject", which can carry a SID as well as the identity of the Node or Adjacency Identifier (NAI) that the SID represents 🦋. The NAI Type (NT) field indicates the type and format of the NAI contained in the SR-ERO. For a binding SID, the NAI MUST NOT be included and the NT MUST be set to zero 🙅‍♀️. Section 5.2.1 of [RFC8664] specifies bit settings and error handling for the case when NT=0 📖.

7. Binding SID in SRv6-ERO 🧚

[RFC9603] defines the "SRv6-ERO subobject" for an SRv6 SID 💜. Just like with the SR-ERO (Section 6), the NAI MUST NOT be included and the NT MUST be set to zero 🫶. Section 5.2.1 of [RFC8664] specifies bit settings and error handling for the case when NT=0 ✨.

8. PCE Allocation of Binding Label/SID 🦋

okay bestie, Section 5 already covers the case where a PCE asks a PCC to allocate a specific binding value by sending a PCUpd or PCInitiate message with a TE-PATH-BINDING TLV 💅. This section is about an OPTIONAL feature where the PCE allocates the binding label/SID all on its own ✨. That only works when the PCE also controls the label space of the PCC and can do the allocation itself, as described in [RFC8283]. Also, asking for a specific binding value (Section 5) is NOT the same thing as the PCE allocating a binding label/SID (this section) 🙈.

[RFC8283] introduces the PCE as a central controller architecture, which extends the one described in [RFC4655]. It keeps PCEP as the protocol between the PCE and the PCC 🌸. [RFC9050] covers the procedures and PCEP extensions for using the PCE as a central controller. It assumes the exclusive label range the PCE uses is already known and set on both PCEP peers. A future extension could let this range be advertised through a possible PCEP extension too (see [PCE-ID-SPACE]).

When PCE as a Central Controller (PCECC) operations are supported as per [RFC9050], the binding label/SID MAY also be allocated by the PCE itself 💖. Before the PCE can allocate the binding label/SID on its own, both peers need to exchange the PCECC capability, as described in [RFC9050] 🫶.

A new P flag in the LSP object [RFC8231] tells everyone that the allocation has to be done by the PCE 🔥. Heads up, the P flag could also be used for other kinds of allocations in the future, like path segments [PCEP-SR] 🧚.

P (PCE-allocation): If the bit is set to 1, it indicates that the PCC requests that the PCE make allocations for this LSP. The TE- PATH-BINDING TLV in the LSP object identifies that the allocation is for a binding label/SID. A PCC MUST set this bit to 1 and include a TE-PATH-BINDING TLV in the LSP object if it wishes to request an allocation for a binding label/SID by the PCE in the PCEP message. A PCE MUST also set this bit to 1 and include a TE- PATH-BINDING TLV to indicate that the binding label/SID is allocated by PCE and encoded in the PCEP message towards the PCC. Further, if the binding label/SID is allocated by the PCC, the PCE MUST set this bit to 0 and follow the procedure described in Section 5.

Okay so the P flag works like this 👑. If it's set to 1, the PCC is asking the PCE to make allocations for this LSP 💅. The TE-PATH-BINDING TLV in the LSP object says the allocation is for a binding label/SID 🎀. A PCC MUST set the bit to 1 and include a TE-PATH-BINDING TLV in the LSP object when it wants the PCE to allocate a binding label/SID in the PCEP message 😭. A PCE MUST ALSO set the bit to 1 and include a TE-PATH-BINDING TLV to say the binding label/SID was allocated by the PCE and is encoded in the PCEP message going to the PCC 🌈. And if the PCC is the one allocating the binding label/SID, the PCE MUST set the bit to 0 and follow the procedure in Section 5 💀.

Wait, I need to keep those keywords exact, so I'm rewriting the last line properly: a PCE MUST set the bit to 0 when the PCC does the allocating, then follow Section 5 💀.

Note that:

  • A PCE could allocate the binding label/SID of its own accord for a PCE-initiated or PCE-delegated LSP, and tell the PCC about it in the PCInitiate or PCUpd message by setting P=1 and including a TE-PATH-BINDING TLV in the LSP object 🍓.
  • To let the PCC allocate the binding label/SID, a PCE MUST set P=0 and include an empty TE-PATH-BINDING TLV (i.e., no binding value is specified) in the LSP object in the PCInitiate/PCUpd message 🌸.
  • To ask the PCE to allocate the binding label/SID, a PCC MUST set P=1 and D=1, and include an empty TE-PATH-BINDING TLV in the PCRpt message 🦋. The PCE will try to allocate it and reply to the PCC with a PCUpd message. That message has the allocated binding label/SID in the TE-PATH-BINDING TLV, plus P=1 and D=1 in the LSP object 💖. If the PCE can't allocate the binding label/SID, it MUST send a PCErr message with Error-Type = 32 ("Binding label/SID failure") and Error-value = 3 ("Unable to allocate a new binding label/SID") 😭.
  • If one or both speakers (PCE and PCC) haven't indicated support and willingness to use the PCEP extensions for PCECC as per [RFC9050], and a PCEP peer receives P=1 in the LSP object, they MUST:
    • send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-value = 16 ("Attempted PCECC operations when PCECC capability was not advertised"), and
    • terminate the PCEP session 💀.
  • A legacy PCEP speaker that doesn't recognize the P flag in the LSP object will just ignore it, per [RFC8231] 🫶.

It's assumed the label range the PCE uses is known and set on both PCEP peers 🌈. The exact mechanism for that is outside the scope of [RFC9050] and this document 🧚. Also, the specific BSID could come from either the PCE-controlled or the PCC-controlled label space ✨. The PCE can allocate a label straight from the PCE-controlled label space using P=1, as described above 🔥. The PCE can also ask for a specific BSID from the PCC-controlled label space with P=0, as described in Section 5 👑.

Note that the P flag in the LSP object SHOULD NOT be set to 1 without the presence of a TE-PATH-BINDING TLV or any other future TLV defined for PCE allocation 🙈. When a receiver gets an LSP object like that, the P flag is ignored 💅. The TE-PATH-BINDING TLV with P=1 says the allocation is for the binding label/SID 🎀. Later on, some other TLV (like one defined in [PCEP-SR]) could be used alongside P=1 to indicate allocation of a different attribute 🌸. A future document should not give semantics to P=1 unless it limits the scope to something both PCEP peers can agree on 🫶.

9. Security Considerations 💀

The security considerations described in [RFC5440], [RFC8231], [RFC8281], [RFC8664], and [RFC9050] apply to this specification 🔒. No additional security measure is required 💅.

As described in [RFC8402] and [RFC8664], SR inherently involves an entity (whether that's the head-end or a central network controller) controlling and instantiating paths in the network without the involvement of other nodes along those paths 😭. Binding SIDs are basically shorthand aliases for longer path representations, and only the node acting on one really knows how the alias expands 🙈. In this document, the expansion of the alias is shared between the PCC and the PCE. That means rogue actions by either one could shift or misdirect traffic in ways other nodes have a hard time detecting 🚨. Especially when a PCE passes along paths like {A, B, BSID} to other entities, the BSID values are opaque. A rogue PCE can swap in a BSID from a different LSP, moving traffic around without the recipient of the path knowing where it really ends up 💀.

BT=3 opens up extra chances for shady behaviour, because it's supposed to convey information about the internal SRv6 SID Structure 👀. There's no mechanism defined to validate this internal structure information. If someone mischaracterizes how the bits are divided into locator block, locator node, function, and argument, the PCC and PCE could end up interpreting the bits differently 😱. The biggest danger is that shifting bits into or out of the "argument" is a direct way to change processing, though other attacks are possible too 🔥.

So, as per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs that belong to the same administrative authority 🔐. Use Transport Layer Security (TLS) [RFC8253] to do that, following the recommendations and best current practices in RFC 9325 [BCP195], unless [RFC8253] explicitly sets them aside 🫶.

10. Manageability Considerations 🎀

All manageability requirements and considerations listed in [RFC5440], [RFC8231], and [RFC8664] apply to the PCEP protocol extensions defined in this document 💖. On top of that, the requirements and considerations in this section apply too ✨.

10.1. Control of Function and Policy 👑

A PCC implementation SHOULD allow the operator to configure the policy the PCC applies when it allocates the binding label/SID 🌸.

If BT is set to 2, the operator needs to have local policy set to decide the SID structure and the SRv6 Endpoint Behavior of the BSID 🧚.

10.2. Information and Data Models 📚

The PCEP YANG module [PCEP-YANG] will be extended to include policy configuration for binding label/SID allocation 🍓.

10.3. Liveness Detection and Monitoring 💜

The mechanisms defined in this document don't imply any new liveness detection and monitoring requirements beyond the ones already listed in [RFC5440] 🫶.

10.4. Verify Correct Operations ✅

The mechanisms defined in this document don't imply any new operation verification requirements beyond the ones already listed in [RFC5440], [RFC8231], and [RFC8664] 🌈.

10.5. Requirements on Other Protocols 🌷

The mechanisms defined in this document don't imply any new requirements on other protocols 💅.

10.6. Impact on Network Operations 🦋

The mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply to the PCEP extensions defined in this document 🔥.

11. IANA Considerations 📋

IANA has allocated code points for the protocol elements described in this document in the "Path Computation Element Protocol (PCEP) Numbers" registry group 🎉.

11.1. PCEP TLV Type Indicators 🏷️

This document defines a new PCEP TLV 🧚. IANA has allocated the following in the "PCEP TLV Type Indicators" registry within the PCEP Numbers registry group 💖:

                  +=======+=================+===========+
                  | Value | Description     | Reference |
                  +=======+=================+===========+
                  |   55  | TE-PATH-BINDING | RFC 9604  |
                  +-------+-----------------+-----------+

                                  Table 1

11.1.1. TE-PATH-BINDING TLV 🌸

IANA has created the "TE-PATH-BINDING TLV BT Field" registry to manage the values of the binding type field in the TE-PATH-BINDING TLV 🦋. The initial values are shown below. New values are assigned by Standards Action [RFC8126] 💅.

       +=======+======================================+===========+
       | Value | Description                          | Reference |
       +=======+======================================+===========+
       |   0   | MPLS Label                           | RFC 9604  |
       +-------+--------------------------------------+-----------+
       |   1   | MPLS Label Stack Entry               | RFC 9604  |
       +-------+--------------------------------------+-----------+
       |   2   | SRv6 SID                             | RFC 9604  |
       +-------+--------------------------------------+-----------+
       |   3   | SRv6 SID with Behavior and Structure | RFC 9604  |
       +-------+--------------------------------------+-----------+
       | 4-255 | Unassigned                           |           |
       +-------+--------------------------------------+-----------+

                                 Table 2

IANA has also created a new "TE-PATH-BINDING TLV Flag Field" registry to manage the Flag field in the TE-PATH-BINDING TLV 🎀. New values are to be assigned by Standards Action [RFC8126] 🫶. Each bit should be tracked with these qualities:

  • Bit number (count from 0 as the most significant bit)
  • Description
  • Reference
                     +=====+=============+===========+
                     | Bit | Description | Reference |
                     +=====+=============+===========+
                     |  0  | R (Removal) | RFC 9604  |
                     +-----+-------------+-----------+
                     | 1-7 | Unassigned  |           |
                     +-----+-------------+-----------+

                                  Table 3

11.2. LSP Object

okay so IANA gave the new P flag its own spot in the "LSP Object Flag Field" registry 💅 bit 0 is PCE-allocation and it's defined in RFC 9604 ✨

                   +=====+================+===========+
                   | Bit | Description    | Reference |
                   +=====+================+===========+
                   |  0  | PCE-allocation | RFC 9604  |
                   +-----+----------------+-----------+

                                 Table 4

11.3. PCEP Error Type and Value

this document adds a brand new Error-Type plus a whole family of Error-values for the PCErr message 🦋 IANA put them in the "PCEP-ERROR Object Error Types and Values" registry, which lives in the PCEP Numbers registry group. look at this glow-up 🌈

     +============+================+===========================+
     | Error-Type | Meaning        | Error-value               |
     +============+================+===========================+
     | 32         | Binding label/ | 0: Unassigned             |
     |            | SID failure    +---------------------------+
     |            |                | 1: Invalid SID            |
     |            |                +---------------------------+
     |            |                | 2: Unable to allocate the |
     |            |                | specified binding value   |
     |            |                +---------------------------+
     |            |                | 3: Unable to allocate a   |
     |            |                | new binding label/SID     |
     |            |                +---------------------------+
     |            |                | 4: Unable to remove the   |
     |            |                | binding value             |
     |            |                +---------------------------+
     |            |                | 5: Inconsistent binding   |
     |            |                | types                     |
     +------------+----------------+---------------------------+

                                  Table 5

12. References

12.1. Normative References

12.2. Informative References

Acknowledgements ✨

huge thanks to Milos Fabian, Mrinmoy Das, Andrew Stone, Tom Petch, Aijun Wang, Olivier Dugeon, and Adrian Farrel for their valuable comments 🫶

  • Thanks to Julien Meuric for shepherding.
  • Thanks to John Scudder for the AD review.
  • Thanks to Theresa Enghardt for the GENART review.
  • Thanks to Martin Vigoureux, Benjamin Kaduk, Éric Vyncke, Lars Eggert, Murray Kucherawy, and Erik Kline for the IESG reviews.

Contributors 💜

Jonathan Hardwick Microsoft United Kingdom Email: jonhardwick@microsoft.com

Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore 560066 Karnataka India Email: dhruv.ietf@gmail.com

Mahendra Singh Negi RtBrick India N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 Bangalore 560102 Karnataka India Email: mahend.ietf@gmail.com

Mike Koldychev Cisco Systems, Inc. 2000 Innovation Drive Kanata Ontario K2K 3E8 Canada Email: mkoldych@cisco.com

Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com

Authors' Addresses 🎀

Siva Sivabalan Ciena Corporation Email: msiva282@gmail.com

Clarence Filsfils Cisco Systems, Inc. Pegasus Parc De Kleetlaan 6a 1831 Brabant Belgium Email: cfilsfil@cisco.com

Jeff Tantsura Nvidia Email: jefftant.ietf@gmail.com

Stefano Previdi Huawei Technologies Email: stefano@previdi.net

Cheng Li (editor) Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: c.l@huawei.com

📦 where this page comes from