RFC 9488

Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP)

📅 published October 2023, from ietf

Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP) ✨

Okay bestie, the title block is giving a lot 🎀 This is RFC 9488, published in October 2023 with ISSN 2070-1721 🦋. It's a Standards Track doc from the IETF (Internet Engineering Task Force) 💅. The authors are A. Stone, M. Aissaoui (Nokia), S. Sidor (Cisco Systems, Inc.), and S. Sivabalan (Ciena Corporation) 👑. It updates RFC 5440, which is the main PCEP spec, and the header doesn't list anything it obsoletes 🫶.

Abstract 🌸

Okay so the abstract is giving clarity 🧚 This doc updates RFC 5440 to clarify how the Local Protection Desired bit signaled in PCEP is used. It also introduces a brand new flag for signaling protection enforcement in PCEP ✨.

Status of This Memo 💜

This is an Internet Standards Track document 💅.

This doc is a product of the IETF. It represents the consensus of the IETF community, it got public review, and it was approved for publication by the IESG (Internet Engineering Steering Group) 🫶. For more on Internet Standards, check Section 2 of RFC 7841. The current status, any errata, and how to send feedback live at https://www.rfc-editor.org/info/rfc9488 🌈.

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this doc 🙈. Code Components extracted from this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License 💀.

Table of Contents 🗂️

   1.  Introduction
   2.  Requirements Language
   3.  Terminology
   4.  Motivation
     4.1.  Implementation Differences
     4.2.  SLA Enforcement
   5.  Protection Enforcement Flag (E Flag)
     5.1.  Backwards Compatibility
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

Okay so PCEP [RFC5440] is the protocol that lets a Path Computation Client (PCC) talk to a PCE, or lets two PCEs talk to each other, based on the PCE architecture in [RFC4655] 🦋.

PCEP [RFC5440] borrows flags, values, and concepts from RSVP-TE Extensions [RFC3209] and Fast Reroute Extensions to RSVP-TE [RFC4090] 🎀. One of those concepts is the Local Protection Desired (L) flag in the LSP Attributes (LSPA) object in [RFC5440], which was originally defined in the Session Attribute object in [RFC3209] 💅. In RSVP, this flag tells downstream routers that they may use a local repair mechanism 🫶. The headend router calculating the path doesn't know whether a downstream router will or won't protect a hop while it's doing that calculation 👀. So the L flag doesn't require the transit router to satisfy protection in order to establish the RSVP-signaled path 😭. In PCEP, this flag is signaled as an attribute of the Label Switched Path (LSP) via the LSPA object 🌸.

PCEP Extensions for Segment Routing [RFC8664] extends PCEP's support for Segment Routing paths 🧚. The path list is encoded with Segment Identifiers (SIDs), and each of those might offer local protection 🌈. The PCE may discover a SID's protection eligibility through the Border Gateway Protocol - Link State (BGP-LS) [RFC9085], and then take protection into consideration as a path constraint 💜.

It's desirable for an operator to be able to define how the protection requirement is enforced 💖.

This doc updates [RFC5440] by further describing the behavior of the Local Protection Desired (L) flag, and it extends that flag with the introduction of the Protection Enforcement (E) flag ✨.

The doc has descriptions in the context of Segment Routing, but the content is agnostic in regard to path setup type and data plane technology 🍓.

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 🧚

This doc uses the following terminology:

  • PROTECTION MANDATORY: The path MUST have protection eligibility on all links.
  • UNPROTECTED MANDATORY: The path MUST NOT have protection eligibility on all links.
  • PROTECTION PREFERRED: The path should have protection eligibility on all links but might contain links that do not have protection eligibility.
  • UNPROTECTED PREFERRED: The path should not have protection eligibility on all links but might contain links that have protection eligibility.
  • PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
  • PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
  • PCEP: Path Computation Element Communication Protocol
  • LSPA: LSP Attributes object [RFC5440]

4. Motivation 💖

4.1. Implementation Differences 🌸

Okay so, per [RFC5440], the way you signal protection enforcement in PCEP is that L flag in the LSPA object 🎀. The name uses the word "Desired," which by definition means "strongly wished for or intended" 💅. This flag came from RSVP, where local protection isn't within the PCE's control 😭. But [RFC5440] does say "[w]hen set, this means that the computed path must include links protected with Fast Reroute as defined in [RFC4090]." Implementations that use PCEP [RFC5440] ended up reading the L flag as either PROTECTION MANDATORY or PROTECTION PREFERRED, and that caused operational differences 💀.

4.2. SLA Enforcement ✨

The L flag is a boolean bit, so it's unable to tell apart PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION PREFERRED, and UNPROTECTED PREFERRED 🙈. Picking one of these options usually depends on the Service Level Agreement (SLA) the operator wants on the LSP 💖. A network may provide transit to multiple SLA definitions over the same base topology, and their behavior could vary, like wanting local protection on some LSPs but not others 🦋. When enforcement is used, the resulting shortest path calculation is impacted 🧚.

Example time 🌈: PROTECTION MANDATORY is for when an operator needs the LSP to follow a path with local protection along the full path. That way, traffic gets fast rerouted at whatever point fails, anywhere along the path 🔥.

Another one 🦋: UNPROTECTED MANDATORY is for when an operator actually prefers that the LSP not be locally protected, so local failures just take the LSP down instead. For example, an LSP might be protected by a secondary diverse LSP 🫶. Each LSP is traffic engineered to follow specific TE criteria that the PCE computed to satisfy the SLA. When a failure happens, if local protection kicks in on the active LSP's traffic, that traffic could briefly run over links that violate the TE requirements, and that could hurt the resources it crosses (like not having enough bandwidth) 😭. Plus, depending on the topology, the PCE might not be able to reroute the LSP while still respecting the TE requirements, which include path diversity. That ends with the LSP being torn down and switched to the protected path anyways 💀. In those cases, it's desirable for the LSP to be torn down immediately and not rerouted through local protection, so traffic can be forwarded through an already-established traffic-engineered secondary path 👑.

Both UNPROTECTED PREFERRED and PROTECTED PREFERRED are relaxations of the protection constraint 🌸. These options can be used when an operator doesn't require protection enforcement 💅. No matter which option is selected, the protection status of a resource doesn't influence whether the link must be pruned during a path calculation 🙈. Picking either one also gives the PCE a priority selection when it has to choose between a protected or unprotected instruction associated with a resource, which keeps PCE behavior consistent across different implementations 🧚.

When used with Segment Routing, an adjacency may have both a protected SID and an unprotected SID 🍓. If UNPROTECTED PREFERRED is selected, the PCE chooses the unprotected SID 🌈. Alternatively, if PROTECTED PREFERRED is selected, the PCE chooses the protected SID 💜.

5. Protection Enforcement Flag (E Flag) 💅

okay bestie, so [RFC5440] Section 7.11 is where the Local Protection Desired (L) flag gets explained. This part adds a sibling called the Protection Enforcement (E) flag that extends L. E lives at bit 6 and L at bit 7 🦋

+=====+==========================+===========+
| Bit | Description              | Reference |
+=====+==========================+===========+
| 6   | Protection Enforcement   | RFC 9488  |
+-----+--------------------------+-----------+
| 7   | Local Protection Desired | RFC 5440  |
+-----+--------------------------+-----------+

  Table 1: Codespace of the Flag Field (LSPA
                  Object)

Here's the whole LSPA object as [RFC5440] defines it, now with the E flag tucked in 🎀

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Exclude-any                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Include-any                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Include-all                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Setup Prio   |  Holding Prio |     Flags |E|L|   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                     Optional TLVs                           //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The flags, bestie 👑

  • L (Local Protection Desired): this one is defined in [RFC5440] and then updated by this document. When it's set to 1, protection is desired. When it's set to 0, protection is not desired. How strictly that gets enforced is decided by the E flag.
  • E (Protection Enforcement): this one controls how strictly the PCE has to apply the L flag. When E is 1, the value of L needs to be respected during resource selection by the PCE. When E is 0, the PCE makes an attempt to respect L, but it could relax or ignore L when computing a path. The rules below spell out what the PCE should prefer when E is 0 combined with each value of L.

Now the four combos, which are so important 🙈

When L and E are both 1, the PCE MUST treat protection eligibility as a PROTECTION MANDATORY constraint. no wiggle room 💀

When L is 1 and E is 0, the PCE MUST treat protection eligibility as a PROTECTION PREFERRED constraint. ✨

When both L and E are 0, the PCE SHOULD treat protection eligibility as an UNPROTECTED PREFERRED constraint, but it MAY treat it as an UNPROTECTED MANDATORY constraint instead. An example of when the second option might be picked is when the PCE has some way (outside the scope of this document) to detect that it's talking to a legacy PCC that expects the old behaviour 🧚

When L is 0 and E is 1, the PCE MUST treat protection eligibility as an UNPROTECTED MANDATORY constraint. 🌸

If a PCE can't work out the protection status of a resource, it MAY use local policy to decide what protected status to assume. When it's computing a Segment Routing path, it is RECOMMENDED that a PCE assume a Node SID is protected. It is also RECOMMENDED that a PCE assume an Adjacency SID is protected if the backup flag advertised with that Adjacency SID is set. 🦋

5.1. Backwards Compatibility

okay so this section covers what happens to the E flag bit when messages go between the PCC and the PCE and one side doesn't support it. The requirements for the PCE and the PCC that do implement this document are at the end 💖

If a PCC or PCE doesn't support this document yet, the E flag gets ignored and set to 0 in PCRpt and/or PCUpd messages. For PCC-initiated LSPs that follows [RFC5440], and for PCE-initiated LSPs it follows [RFC8281]. Also important: [RFC8231] and [RFC8281] allow the LSPA object [RFC5440] to show up in PCUpd messages for both PCC-initiated and PCE-initiated LSPs 👀

For PCC-initiated LSPs, the E flag (and the L flag) in a PCUpd message is an echo of the previous PCRpt message. But the bit value gets ignored by a PCE that took it from that earlier PCRpt, so the E flag in the PCUpd ends up being 0. A PCE that doesn't support this document sends PCUpd messages with E set to 0 for PCC-initiated LSPs, even if E was 1 in the earlier PCReq or PCRpt message. rude 😭

A PCC that doesn't support this document sends PCRpt messages with E set to 0 for PCE-initiated LSPs, even if E was 1 in the earlier PCInitiate or PCUpd message.

For a PCC that does support this document, the E flag MAY be set to 1, depending on local configuration. If it's talking to a PCE that doesn't support this document yet, that PCE follows [RFC5440] and ignores the E flag. So yeah, a computed path might not respect the enforcement constraint 🥲

For PCC-initiated LSPs, the PCC SHOULD ignore the E flag value it gets from the PCE in a PCUpd message, because it might be talking to a PCE that doesn't support this document.

For PCE-initiated LSPs, the PCC MAY process the E flag value it gets from the PCE in a PCUpd message. The PCE SHOULD ignore the E flag value it gets from the PCC in a PCRpt message, because the PCC might not support this document 🫶

6. Security Considerations 🔐

this one's short but it matters, so let's go 🍓

This document clarifies how an existing flag behaves and adds a new flag for more control over that behaviour. Neither the new flag nor the clarification creates any new sensitive information. No additional security measure is required.

⚠️ Still, securing the PCEP session is a big deal. Using Transport Layer Security (TLS) [RFC8253], following the recommendations and best current practices in [RFC9325], is RECOMMENDED. Don't skip it, periodt 💅

7. IANA Considerations 🌈

This document defines a new bit value in the subregistry "LSPA Object Flag Field" inside the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has made the following codepoint allocation ✨

+=====+========================+===========+
| Bit | Description            | Reference |
+=====+========================+===========+
| 6   | Protection Enforcement | RFC 9488  |
+-----+------------------------+-----------+

   Table 2: Addition to LSPA Object Flag
               Field Registry

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgements 🫶

Thanks to Dhruv Dhody, Mike Koldychev, and John Scudder for reviewing this document and giving very valuable feedback and discussions. you're the best 💜

Thanks to Julien Meuric for shepherding this document. ⭐

Authors' Addresses 🎀

Andrew Stone
Nokia
600 March Road
Kanata Ontario K2K 2T6
Canada
Email: andrew.stone@nokia.com


Mustapha Aissaoui
Nokia
600 March Road
Kanata Ontario K2K 2T6
Canada
Email: mustapha.aissaoui@nokia.com


Samuel Sidor
Cisco Systems, Inc.
Eurovea Central 3
Pribinova 10
811 09 Bratislava
Slovakia
Email: ssidor@cisco.com


Siva Sivabalan
Ciena Corporation
385 Terry Fox Drive
Kanata Ontario K2K 0L1
Canada
Email: ssivabal@ciena.com
📦 where this page comes from