RFC 8800

Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling

📅 published July 2020, from ietf

RFC 8800: Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling 🎀

Okay bestie, let's start with the basics 💅 This is RFC 8800, published by the IETF (Internet Engineering Task Force) in July 2020. It's a Standards Track document (ISSN 2070-1721), and four people wrote it: S. Litkowski from Cisco Systems, Inc., S. Sivabalan from Ciena Corporation, C. Barth from Juniper Networks, and M. Negi from RtBrick India. The title block doesn't say it obsoletes or updates anything, so it isn't replacing or patching any earlier RFC 🌈

Abstract ✨

Okay so this doc adds a simple way to group a bunch of Label Switched Paths (LSPs) together using an extension to the Path Computation Element Communication Protocol (PCEP) 🦋 The whole goal is to compute diverse (disjointed) paths for everyone in the group. The extension lets a Path Computation Client (PCC) tell a Path Computation Element (PCE) that a certain LSP belongs to a certain Disjoint Association Group. So the PCE knows that every LSP in that group needs to stay disjoint from the others. Iconic, honestly 👑

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🧚

You can find the current status of this document, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc8800 🔗

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they explain your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶

Table of Contents 🍓

  1.  Introduction
    1.1.  Requirements Language
  2.  Terminology
  3.  Motivation
  4.  Applicability
  5.  Protocol Extension
    5.1.  Association Group
    5.2.  Disjoint TLVs
    5.3.  Disjointness Objective Functions
    5.4.  Relationship to SVEC
      5.4.1.  SVEC and OF
    5.5.  P Flag Considerations
    5.6.  Disjointness Computation Issues
  6.  Security Considerations
  7.  IANA Considerations
    7.1.  Association Type
    7.2.  PCEP TLVs
    7.3.  Objective Functions
    7.4.  NO-PATH-VECTOR Bit Flags
    7.5.  PCEP-ERROR Codes
  8.  Manageability Considerations
    8.1.  Control of Function and Policy
    8.2.  Information and Data Models
    8.3.  Liveness Detection and Monitoring
    8.4.  Verification of Correct Operations
    8.5.  Requirements on Other Protocols
    8.6.  Impact on Network Operations
  9.  References
    9.1.  Normative References
    9.2.  Informative References
  Acknowledgments
  Contributors
  Authors' Addresses

1. Introduction 🌸

Okay so [RFC5440] is the one that describes PCEP, which is how a Path Computation Client (PCC) and a Path Control Element (PCE) chat with each other. It can also be two PCEs talking, based on the PCE architecture in [RFC4655] 💅

The PCEP Extensions for Stateful PCE Model [RFC8231] adds a bunch of extensions so you can actively control MPLS-TE and GMPLS tunnels, which is so main character 🦋 Then [RFC8281] covers setting up and tearing down PCE-initiated LSPs under the active stateful PCE model. The best part is you don't need local configuration on the PCC for that, so the network can stay super dynamic ✨

[RFC8697] brings a generic way to group LSPs in the context of a PCE. You can then link a set of LSPs to a set of attributes (like configuration parameters or behaviors). It works for both the active and passive modes of a stateful PCE [RFC8231], and also for a stateless PCE [RFC4655] 🧚

This document specifies a PCEP extension that signals that a set of LSPs in a particular group should use diverse (disjointed) paths, including the type of diversity that's been requested. Sections 3 and 4 explain what a Disjoint Association Group is and how it gets used 🎀 A PCC can use this extension to tell a PCE that a particular LSP belongs to a particular Disjoint Association Group. When a PCE gets LSP states for the same Disjoint Association Group from some PCCs, the PCE should ensure that the LSPs in that group are disjoint from each other 💖

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 🫶

2. Terminology 📖

The following terminology is used in this document ✨

  • DAT: Disjoint Association Type
  • DAG: Disjoint Association Group
  • MPLS: Multiprotocol Label Switching
  • OF: Objective Function
  • 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
  • PLSP-ID: PCEP-specific identifier for the LSP
  • SRLG: Shared Risk Link Group

3. Motivation 🦋

Path diversity is a super common use case in today's IP/MPLS networks, especially for layer 2 transport over MPLS 💜 A customer may ask the operator to provide two end-to-end disjoint paths across the operator's IP/MPLS core. The customer can use those paths as primary/backup or as an active/active configuration 🍓

There are different levels of disjointness that can be offered 👑

  • Link disjointness: the paths of the associated LSPs should transit different links (but may use common nodes or different links that may have some shared fate).
  • Node disjointness: the paths of the associated LSPs should transit different nodes (but may use different links that may have some shared fate).
  • SRLG disjointness: the paths of the associated LSPs should transit different links that do not share fate (but may use common transit nodes).
  • Node+SRLG disjointness: the paths of the associated LSPs should transit different links that do not have any common shared fate and should transit different nodes.

The associated LSPs may start from the same head end or from different head ends, and they may end at the same tail end or at different tail ends. It's giving flexibility, honestly 🌈

4. Applicability ✨

okay bestie, this section is where we see why any of this matters 💅 picture a customer who wants two disjoint paths, one from CE1 to CE2 and one from CE3 to CE4. They're not sharing any road, lowkey iconic. From the IP/MPLS point of view, the CEs plug into different PEs so they're as far apart as possible 🦋

         _________________________________________
        /                                         \
       /        +------+                           \
      |         | PCE  |                            |
      |         +------+                            |
      |                                             |
      |          ***********************>           |
      | +------+           10             +------+  |
CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
      | +------+       |        |         +------+  |
      |                |        |                   |
      |                |        |                   |
      | +------+       |        |         +------+  |
CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
      | +------+ ***********************> +------+  |
      |                                             |
       \                                           /
        \_________________________________________/

Figure 1: Disjoint Paths with Different Head Ends and Tail Ends

Here's the tea 🫖 when LSPs start from different head ends, computing diverse paths in a distributed way gets messy 😭 A centralized PCE is the one that keeps paths disjoint, correct, and simple. Main character energy for the PCE 👑

Section 5.4 explains how the Disjoint Association Group (DAG) and the Synchronization VECtor (SVEC) object fit together 🧚

The stateful PCE extension [RFC8231] introduced some new PCEP messages: Path Computation Report (PCRpt), Path Computation Update (PCUpd), and Path Computation Initiate (PCInitiate) [RFC8281] 🌸 They identify LSPs using a PLSP-ID in the LSP object. And if you want diversity between LSPs coming from different PCCs, there's a generic grouping mechanism in [RFC8697] that works for both the active and passive modes of a stateful PCE 💜

So this document's PCEP extension has the PCC use the [RFC8697] extension to say "hey, these LSPs need to be disjoint" 🎀 That signal should include the disjointness parameters: the type of disjointness, the Disjoint Association Group identifiers, and any customization parameters from the configured local policy ✨

Heads up, operators: managing Disjoint Association Group IDs is a big deal 🙈 The Association ID field tops out at 65535. The local config of the IPv4/IPv6 Association Source, or the Global Association Source/Extended Association ID, gets you past that limit, as described in [RFC8697] 🔥 When a PCC or PCE starts all the LSPs in one Disjoint Association Group, it can set the IPv4/IPv6 Association Source to one of its own IP addresses. When disjoint LSPs start from different head ends, the Association Source could be the PCE address or any other unique value that identifies the DAG 🍓

Now let's look at the flow, it's giving sequence diagram energy 💖

        Initiate Disjoint LSPs
                 |
                 |                       PCReq/PCRpt
                 V                        {DAG Y}
              +-----+                ----------------> +-----+
   _ _ _ _ _ _| PCE |               |                  | PCE |
  |           +-----+               |      ----------> +-----+
  | PCInitiate                      |     |    PCReq/PCRpt
  |{DAG X}                          |     | {DAG Y}
  |                                 |     |
  |              .-----.            |     |         .-----.
  |             (       )           | +-----+      (       )
  |         .--(         )--.       | |PCC 2|--.--(         )--.
  V        (                 )      | +-----+ (                 )
+---+     (                  )      |        (                  )
|PCC|----(   (G)MPLS network )   +-----+    ( (G)MPLS network   )
+---+    (                   )   |PCC 1|-----(                  )
{DAG X}   (                 )    +-----+      (                )
           '--(         )--'                   (           )--'
               (       )                         (        )
                '-----'                            '-----'

Case 1: Disjointness initiated by PCE and enforced by PCC Case 2: Disjointness initiated by PCC and enforced by PCE

Figure 2: Sample Use Cases for Carrying Disjoint Association Group over PCEP Session

The Disjoint Association Group in PCEP messages is used for two things, babe 👯‍♀️

  • Configuration: tells a PCEP peer what disjoint requirement was configured 🎀
  • Status: tells the peer how well the disjointness actually got computed 📊

5. Protocol Extension 💅

5.1. Association Group 🦋

okay so [RFC8697] says LSPs get linked to the other LSPs they interact with by joining a shared association group 🫶 The group is uniquely identified by the combo of these fields in the ASSOCIATION object: Association Type, Association ID, Association Source, and (if present) Global Association Source or Extended Association ID 🌈

This document adds a brand-new Association type called "Disjoint Association" (2), built on the generic ASSOCIATION object 🎀 It's also called "DAT", short for "Disjoint Association Type" ✨

[RFC8697] explains how PCEP speakers advertise which Association types they support, using an ASSOC-Type-List TLV carried inside an OPEN object 💜 Before you use the disjoint association, the DAT (2) MUST be exchanged this way. So the PCEP speaker MUST include the DAT in the ASSOC-Type-List TLV, AND it MUST receive the same from its PCEP peer before using the Disjoint Association Group (DAG) in PCEP messages. No skipping the handshake, periodt 🙅‍♀️

This Association type counts as both dynamic and operator-configured 🌸 Per [RFC8697], the operator can manually create the association group on the PCEP peers and then send the LSPs belonging to it over PCEP messages. Or the PCEP speaker can create the group dynamically, and then both the group info and its LSPs get sent to the peer 🧚 Either way, the Operator-configured Association Range MUST be set for this association-type. It marks a range of Association Identifiers for operator-configured associations, so nothing clashes within the scope of the Association Source 🔥 (Refer to [RFC8697].)

A Disjoint Association Group can hold two or more LSPs, but a PCE can only juggle so many LSPs when it computes disjointness 😭 If a PCE gets more LSPs in the group than its computation algorithm can handle, it SHOULD apply the disjointness computation to only a subset of them. The PCE decides which subset gets disjoint treatment, as a local policy 🍓 Local polces MAY define how the other LSPs in the group get computed. For example, the PCE might return no path, a shortest path, or a constrained path that relaxes disjointness, etc. ✨ The disjoint status of the computed path gets reported to the PCC through the DISJOINTNESS-STATUS TLV (see Section 5.2) 💖

There are different types of disjointness, and they're flagged by T, S, N, and L in the DISJOINTNESS-CONFIGURATION TLV (see Section 5.2) 🌈 Every LSP in one Disjoint Association Group MUST use the exact same combination of T, S, N, and L flags in that TLV. If a PCEP peer gets a PCEP message for LSPs in the same Disjoint Association Group but with an inconsistent combo of T, S, N, and L flags, it MUST NOT add those LSPs to the group, and it MUST reply with a PCErr carrying Error-Type 26 (Association Error) and Error-value 6 (Association information mismatch) 🙈💀

A particular LSP MAY belong to multiple Disjoint Association Groups. In that case the PCE SHOULD try to consider all of those groups during path computation, if possible 💜 If it can't, a local policy MAY define the computational behavior. And if a PCE doesn't support that kind of path computation, it MUST NOT add the LSP into the association group, and it MUST return a PCErr with Error-Type 26 (Association Error) and Error-value 7 (Cannot join the association group) 😭🫶

5.2. Disjoint TLVs ✨

okay bestie, the Disjoint Association Group (ASSOCIATION object with Association type = 2 for DAT) MUST carry the DISJOINTNESS-CONFIGURATION TLV 💖 It's how we communicate the disjointness configuration parameters, and it applies to every PCEP message that includes a DAG.

The DAT MAY also carry these TLVs, no cap 🫶

  • DISJOINTNESS-STATUS TLV: tells everyone the status of the computed disjointness. This one is only for messages going from a PCE to a PCC (PCUpd, PCInitiate, or PCRep) 🎀
  • VENDOR-INFORMATION-TLV: arbitrary vendor-specific behavioral info, described in [RFC7470] 🧚
  • OF-List TLV: communicates the disjointness objective function. More on that in Section 5.3 💜

Here's the DISJOINTNESS-CONFIGURATION TLV layout 🦋

 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 = 46             |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Flags                               |T|P|S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: DISJOINTNESS-CONFIGURATION TLV

Here's the breakdown, bestie 💅

Type: 46

Length: Fixed value of 4 bytes.

Flags:

  • L (Link Diverse) bit: when set, the computed paths within the Disjoint Association Group MUST NOT have any link in common 🔗
  • N (Node Diverse) bit: when set, the computed paths within the Disjoint Association Group MUST NOT have any node in common 🌸
  • S (SRLG Diverse) bit: when set, the computed paths within the Disjoint Association Group MUST NOT share any SRLG (Shared Risk Link Group) ⚡
  • P (Shortest Path) bit: when set, the computed path of the LSP SHOULD satisfy all the constraints and objective functions first, without considering the diversity constraint. So all the LSPs with the P flag set in the association group get computed first, like the disjointness constraint was never configured. Then, with those LSPs locked in, the other LSPs with the P flag unset get computed with the disjointness constraint in mind. We'll see examples of how the P flag works in Section 5.5 🧠
  • T (Strict Disjointness) bit: when set, if disjoint paths can't be found, the PCE MUST return no path for the LSPs that couldn't be disjoint. When unset, the PCE is allowed to relax disjointness, either by applying a requested objective function (cf. Section 5.3) or by using local policy if no objective function was requested. For example, it could drop to a lower disjoint type (link instead of node) or fully relax the disjointness constraint. See Section 5.6 for the deets 🫠
  • Unassigned bits: these are considered reserved. They MUST be set to 0 on transmission and MUST be ignored on receipt 🙈

If a PCEP speaker receives a Disjoint Association Group (ASSOCIATION object with Association type = 2 for DAT) without the DISJOINTNESS-CONFIGURATION TLV, it SHOULD reply with a PCErr Error-Type 6 (Mandatory Object missing) and Error-value 15 (DISJOINTNESS-CONFIGURATION TLV missing) 😭

The DISJOINTNESS-STATUS TLV uses the same format as the DISJOINTNESS-CONFIGURATION TLV, just with a different type, 47, in the TLV. The L, N, and S flags get set if the matching disjointness criterion was requested and the computed paths meet it ✨ The P flag tells you the computed path is the shortest path, which was computed first without taking the disjointness constraints into account but while still considering the other constraints 🦋

The T flag has no meaning in the DISJOINTNESS-STATUS TLV. It MUST NOT be set while sending, and it MUST be ignored on receipt 💀

Last but not least: any document that defines a new flag for the DISJOINTNESS-CONFIGURATION TLV automatically defines a new flag with the same name, in the same location, in the DISJOINTNESS-STATUS TLV. The semantics of that flag in the DISJOINTNESS-STATUS TLV MUST be specified in the document that specifies the flag in the DISJOINTNESS-CONFIGURATION TLV 📚👑

5.3. Disjointness Objective Functions 🎯

An objective function (OF) MAY be applied to the disjointness computation to steer how the PCE computes things. When that happens, the OF-List TLV (defined in [RFC5541]) is used as an optional TLV in the ASSOCIATION object 🌈 The PCEP OF-List TLV can hold multiple OF-codes, but a sender SHOULD include a single OF-code in the OF-List TLV when it's in the Association Group. The receiver MUST consider only the first OF-code and ignore any others if they're included 💅

To minimize the common shared resources (Node, Link, or SRLG) across a set of paths during path computation, three new OF-codes are defined ✨

MSL

Name: Minimize the number of Shared (common) Links. Objective Function Code: 15

The idea is to find a set of paths that passes through the least number of shared (common) links. Here's the math-y version 🤓

A network comprises a set of N links {Li, (i=1...N)}.
A path P passes through K links {Lpi,(i=1...K)}.
A set of paths {P1...Pm} have L links that are common to
more than one path {Lci,(i=1...L)}.
Find a set of paths such that the value of L is minimized.

MSS

Name: Minimize the number of Shared (common) SRLGs. Objective Function Code: 16

This one finds a set of paths that passes through the least number of shared (common) SRLGs 🔥

A network comprises a set of N links {Li, (i=1...N)}.
A path P passes through K links {Lpi,(i=1...K)} belonging to
unique M SRLGs {Spi,(i=1..M)}.
A set of paths {P1...Pm} have L SRLGs that are common to
more than one path {Sci,(i=1...L)}.
Find a set of paths such that the value of L is minimized.

MSN

Name: Minimize the number of Shared (common) Nodes. Objective Function Code: 17

Here the goal is a set of paths that passes through the least number of shared (common) nodes 🌷

A network comprises a set of N nodes {Ni, (i=1...N)}.
A path P passes through K nodes {Npi,(i=1...K)}.
A set of paths {P1...Pm} have L nodes that are common to
more than one path {Nci,(i=1...L)}.
Find a set of paths such that the value of L is minimized.

If the OF-List TLV is included in the ASSOCIATION object, the first OF-code inside the OF object MUST be one of the disjoint OFs defined in this document. If that isn't met, the PCEP speaker MUST respond with a PCErr message with Error-Type 10 (Reception of an invalid object) and Error-value 32 (Incompatible OF code). Not vibing with that, bestie 🙅‍♀️

5.4. Relationship to SVEC 🫧

Okay, so [RFC5440] already has a way to synchronize a bunch of path computation requests using the SVEC object. That object lists the synchronized requests, which can be either dependent or independent. The SVEC object points at the requests by their Request-ID-number in the RP (Request Parameters) object 💖 [RFC6007] goes further and clarifies how the SVEC list is used for synchronized path computations when you're dealing with dependent requests. It also covers a bunch of usage scenarios for SVEC lists in single-domain and multi-domain setups 🌈

The SVEC object has a Flags field that shows the potential dependency between the set of path computation requests. It works kind of like the Flags field in the TLVs defined in this document 🧚 The path computation request in the Path Computation Request (PCReq) message MAY use both the SVEC and ASSOCIATION objects to identify the related request, as well as the DAG. The PCE MUST try to find a path that meets both constraints. The diversity requirement in the association group can be different from the one in the SVEC object, which is totally possible 🤷‍♀️ So the PCE MUST consider both objects (including the flags set inside them) as per the processing rules, and aim to find a path that meets both of these constraints. If no such path is possible, the PCE MUST send a Path Computation Reply (PCRep) with a NO-PATH object indicating path computation failure, as per [RFC5440] 😭 It should be noted that the LSPs in the association group can be fully the same as, or partially overlapping with, the LSPs grouped by the SVEC object in the PCReq message 🦋

Some examples, so you can see it in action 👀

PCReq with SVEC object with node-diverse bit=1 (LSP1,LSP2) and DAG
with S=1 (LSP1,LSP2) - both node- and SRLG-diverse path between
LSP1 and LSP2.

PCReq with SVEC object with link-diverse bit=1 (LSP1,LSP2) and DAG
with L=1 (LSP1,LSP3) - link-diverse paths between LSP1 and LSP2
and between LSP1 and LSP3.  If the DAG is part of the stateful
database, any future change in LSP3 will have an impact on LSP1.
But any future change in LSP2 will have no impact on LSP1, as LSP2
is part of SVEC object (which is considered once on receipt of the
PCReq message only).

5.4.1. SVEC and OF 🎀

This document defines three new OF-codes in Section 5.3 to maximize diversity as much as possible. In other words, these new OF-codes let you ask for the minimization of common shared resources (Node, Link, or SRLG) across a set of paths during path computation 🔥

It's honestly kinda interesting that the diversity flags in the SVEC object and the OF for diversity can be used together 🧠 Some examples:

SVEC object with node-diverse bit=1 - ensure full node diversity.

SVEC object with node-diverse bit=1 and OF=MSS - full node
diversity with as much SRLG diversity as possible.

SVEC object with domain-diverse bit=1 [RFC8685]; node-diverse
bit=1, and OF=MSS - full domain and node diversity with as much
SRLG diversity as possible.

SVEC object with node-diverse bit=1 and OF=MSN - ensure full node
diversity.

In that last example, "OF" is kind of redundant, because the "SVEC object" already ensures full node diversity 💅 That said, this specification doesn't prohibit redundant constraints when you use "SVEC object" and "OF" together for diversity, so you're allowed to double up if you want to 💖

5.5. P Flag Considerations ✨

okay so, remember how the P flag shows up in Section 5.2? 💖 When it's set, the computed path of the LSP SHOULD satisfy all constraints and objective functions first, without thinking about the diversity constraint yet. 🫶

So an LSP with the P flag set gets placed first, like the disjointness constraint was never configured 🙈. The other LSPs in the association with the P flag unset get placed while taking disjointness into account. Setting the P flag makes the relationship one-sided: LSP 1 with P=0 depends on LSP 2 with P=1, but LSP 2 with P=1 doesn't depend on LSP 1 with P=0. Multiple LSPs in the same Disjoint Association Group can have the P flag set too 🦋. In that case, those LSPs may not be disjoint from each other, but they'll still be disjoint from the other LSPs in the group that have the P flag unset.

This could be needed in some primary/backup setups where the primary path should use the most optimal path available (taking the other constraints into account) 👑. When disjointness is computed, it's really important for the algorithm to know that it should try to optimize the path of one or more LSPs in the group (like the primary path), while the other paths are allowed to be costlier (compared to a similar path without the disjointness constraint). Without that hint, the disjointness algorithm might set a path for all LSPs that doesn't completely fulfill the customer's requirement 💀.

Figure 4 example, with six internal routers 🌸

            _________________________________________
           /                                         \
          /        +------+                           \
         |         | PCE  |                            |
         |         +------+                            |
         |                                             |
         |                                             |
         | +------+           10             +------+  |
   CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
         | +------+       |        |         +------+  |
         |                |        |                   |
         |                |        |                   |
         | +------+       |        |         +------+  |
   CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
         | +------+ \     |               /  +------+  |
         |           \    |     10       /             |
          \           +-- R5 --------- R6             /
           \_________________________________________/

Figure 4: Example Topology with Six Internal Routers

Note: In Figure 4, the cost of all the links is 1, unless explicitly marked otherwise.

In the figure above, a customer has two dual-homed sites (CE1/CE3 and CE2/CE4) 🍓. Let's say this customer wants two link disjoint paths between the two sites. Because of physical meshing, the customer wants to use CE1 and CE2 as the primary (and CE3 and CE4 are hosted in a remote site for redundancy purposes).

Without any hint (constraint) provided, the PCE may compute the two link disjoint LSPs together, leading to PE1->PE2 using the path PE1->R1->R2->PE2 and PE3->PE4 using PE3->R3->R4->PE4. In this case, even though the disjointness constraint is fulfilled, the path from PE1 to PE2 doesn't use the best optimal path available in the network (path delay may be higher), so the customer requirement isn't completely fulfilled 😭.

The usage of the P flag lets the PCE know that a particular LSP should be tied to the best path, as if the disjointness constraint was not requested. 🧚

In our example, if the P flag is set on the LSP PE1->PE2, the PCE should use the path PE1->R1->R3->R4->R2->PE2 for this LSP, while the other LSP should be link disjoint from this path. The second LSP will be placed on PE3->R5->R6->PE4, since it's allowed to be costlier.

Driving the PCE disjointness computation may also be done in other ways, for instance, by setting a metric boundary that reflects a path delay boundary. Other constraints may be used too ✨.

The P flag basically lets you say that the disjointness constraint should not make the LSP worse 💅.

Any constraint added to a path disjointness computation may reduce the chance of finding suitable paths. The P flag, like any other constraint, may prevent finding a disjoint path. In the example above, if router R5 is down and PE1->PE2 has the P flag set, there's no room left to place PE3->PE4 (the link disjointness constraint can't be fulfilled). If PE1->PE2 has the P flag unset, the algorithm may be able to place PE1->PE2 on the R1->R2 link, leaving room for PE3->PE4 on the R3->R4 link. When using the P flag or any additional constraint on top of the disjointness constraint, the user should be aware that there is less chance to fulfill the disjointness constraint 🥺.

Figure 5 example, with four internal routers 🌈

            _________________________________________
           /                                         \
          /        +------+                           \
         |         | PCE  |                            |
         |         +------+                            |
         |                                             |
         |                                             |
         | +------+           10             +------+  |
   CE1 ****| PE 1 | ----- R1 ---- R2 ------- | PE 2 |**** CE2
         | +------+       |  \     |         +------+  |
         |                |   \2   |                   |
         |                |    \   |                   |
         | +------+       |     \  |         +------+  |
   CE3 ****| PE 3 | ----- R3 ---- R4 ------- | PE 4 |**** CE4
         | +------+                          +------+  |
         |                                             |
          \                                           /
           \_________________________________________/

Figure 5: Example Topology with Four Internal Routers

Note: In Figure 5, the cost of all the links is 1, unless explicitly marked otherwise.

In the figure above, we still have the same requirements as before, so the PE1->PE2 LSP should be optimized (P flag set), while PE3->PE4 should be link disjoint and may use a costlier path 🎀.

For PE1->PE2, there are two paths that satisfy the constraints (ECMP): PE1->R1->R4->R2->PE2 (path 1) and PE1->R1->R3->R4->R2->PE2 (path 2). An implementation may choose one of the paths.

If the implementation only elects one path, there's a chance that picking that path may prevent link disjointness. In our example, if path 2 is used for PE1->PE2, there's no room left for PE3->PE4, while if path 1 is used, PE3->PE4 can be placed on the R3->R4 link.

When the P flag is set for an LSP and ECMPs are available, an implementation should aim to select a path that allows disjointness. 🫧

5.6. Disjointness Computation Issues 💀

There may be some cases where the PCE isn't able to provide a set of disjoint paths for one or more LSPs in the association 😩.

When the T flag is set (Strict disjointness) and disjointness can't be ensured for one or more LSPs, the PCE MUST reply to a PCReq with a PCRep message containing a NO-PATH object. For a PCRpt message, the PCE MUST return a PCErr message with Error-Type 26 (Association Error) and Error-value 7 (Cannot join the association group) 🚫.

If a network event makes strict disjointness impossible, the PCE MUST send a PCUpd message containing an empty Explicit Route Object (ERO) to the corresponding PCCs. Along with the empty ERO object, the PCE MAY add the NO-PATH-VECTOR TLV [RFC5440] in the LSP object.

This document adds new bits to the Flags field of the NO-PATH-VECTOR TLV:

  • bit 11: When set, the PCE indicates that it could not find a disjoint path for this LSP.
  • bit 10: When set, the PCE indicates that it does not support the requested disjointness computation.

When the T flag is unset, the PCE is allowed to relax disjointness by applying a requested objective function (Section 5.3), if one is specified. Otherwise, if no objective function is specified, the PCE is allowed to reduce the required level of disjointness as it sees fit 🌸. The actual level of disjointness of the paths the PCE computes can be reported through the DISJOINTNESS-STATUS TLV by setting the appropriate flags in the TLV. While the DISJOINTNESS-CONFIGURATION TLV defines the desired level of disjointness required by configuration, the DISJOINTNESS-STATUS TLV defines the level of disjointness actually achieved 🦋.

There are some cases where the PCE may need to completely relax the disjointness constraint in order to provide a path to all the LSPs that are part of the association. The authors consider a mechanism that lets the PCE fully relax a constraint to be more global to PCEP than to the disjointness use case. As a result, it's considered out of scope for this document. See [PCE-OPTIONAL] for a proposed mechanism 🧠.

6. Security Considerations 🔐

This document defines one new PCEP Association type, which by itself doesn't add any new security concerns beyond those discussed in [RFC5440], [RFC8231], [RFC7470], and [RFC8697]. But adding a spurious LSP into the Disjoint Association Group could lead to recomputation and setup of all LSPs in the group, which could be used to overwhelm the PCE and the network 🚨.

A spurious LSP can have flags that are inconsistent with those of the legitimate LSPs in the group, and so cause LSP allocation for the legitimate LSPs to fail with an error. Also, certain combinations of flags (notably, the 'T' bit) can result in conflicts that can't be resolved 😵.

Also, as stated in [RFC8697], much of the information carried in the ASSOCIATION object reflects information that can also be derived from the LSP database, but association provides a much easier way to group related LSPs and messages. This holds true for the DAT as well, so this could give an adversary the opportunity to eavesdrop on the relationship between the LSPs and work out the network topology 👀.

Thus, securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in BCP 195 [RFC7525], is RECOMMENDED. Please don't skip this one bestie, it's serious 🫶🔒

7. IANA Considerations 📋

7.1. Association Type

This document defines a new Association type, originally described in [RFC8697]. IANA has assigned the following new value in the "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path Computation Element Protocol (PCEP) Numbers" registry 🌷:

              +======+======================+===========+
              | Type | Name                 | Reference |
              +======+======================+===========+
              | 2    | Disjoint Association | RFC 8800  |
              +------+----------------------+-----------+

                    Table 1: ASSOCIATION Type Field

7.2. PCEP TLVs 🎀

Okay so this doc defines two brand new PCEP TLVs, and IANA handed out their numbers in the "PCEP TLV Type Indicators" subregistry inside the "Path Computation Element Protocol (PCEP) Numbers" registry 💅

+==========+============================+===========+
| TLV Type | TLV Name                   | Reference |
+==========+============================+===========+
| 46       | DISJOINTNESS-CONFIGURATION | RFC 8800  |
+----------+----------------------------+-----------+
| 47       | DISJOINTNESS-STATUS        | RFC 8800  |
+----------+----------------------------+-----------+

          Table 2: PCEP TLV Type Indicators

Next up, IANA made a brand new subregistry called "DISJOINTNESS-CONFIGURATION TLV Flag Field" 🦋 It lives in the same "Path Computation Element Protocol (PCEP) Numbers" registry and keeps track of the Flags field in the DISJOINTNESS-CONFIGURATION TLV. New values get assigned by Standards Action [RFC8126], and each bit is tracked with three things:

  • Bit number (count from 0 as the most significant bit)
  • Flag Name
  • Reference

Here's the starter pack for that subregistry 🌸

+======+=========================+===========+
| Bit  | Name                    | Reference |
+======+=========================+===========+
| 31   | L - Link Diverse        | RFC 8800  |
+------+-------------------------+-----------+
| 30   | N - Node Diverse        | RFC 8800  |
+------+-------------------------+-----------+
| 29   | S - SRLG Diverse        | RFC 8800  |
+------+-------------------------+-----------+
| 28   | P - Shortest Path       | RFC 8800  |
+------+-------------------------+-----------+
| 27   | T - Strict Disjointness | RFC 8800  |
+------+-------------------------+-----------+
| 0-26 | Unassigned              |           |
+------+-------------------------+-----------+

   Table 3: DISJOINTNESS-CONFIGURATION TLV
                  Flag Field

7.3. Objective Functions ✨

This doc adds three new objective functions 🧚 IANA put them in the "Objective Function" subregistry (same big PCEP Numbers registry, you know the drill):

+============+=======================+===========+
| Code Point | Name                  | Reference |
+============+=======================+===========+
| 15         | Minimize the number   | RFC 8800  |
|            | of Shared Links (MSL) |           |
+------------+-----------------------+-----------+
| 16         | Minimize the number   | RFC 8800  |
|            | of Shared SRLGs (MSS) |           |
+------------+-----------------------+-----------+
| 17         | Minimize the number   | RFC 8800  |
|            | of Shared Nodes (MSN) |           |
+------------+-----------------------+-----------+

             Table 4: Objective Function

7.4. NO-PATH-VECTOR Bit Flags 🌈

This doc also defines new bits for the NO-PATH-VECTOR TLV, living in the "NO-PATH-VECTOR TLV Flag Field" subregistry of the "Path Computation Element (PCEP) Numbers" registry. IANA made these allocations:

+============+===========================+===========+
| Bit Number | Name                      | Reference |
+============+===========================+===========+
| 11         | Disjoint path not found   | RFC 8800  |
+------------+---------------------------+-----------+
| 10         | Requested disjoint        | RFC 8800  |
|            | computation not supported |           |
+------------+---------------------------+-----------+

        Table 5: NO-PATH-VECTOR TLV Flag Field

7.5. PCEP-ERROR Codes 💀

Two new Error-values are being added inside existing Error-Types that are all about disjoint association 🙈 IANA allocated them in the "PCEP-ERROR Object Error Types and Values" subregistry (yep, same registry family again):

+============+===========+============================+===========+
| Error-Type | Meaning   | Error-value                | Reference |
+============+===========+============================+===========+
| 6          | Mandatory |                            | [RFC5440] |
|            | Object    |                            |           |
|            | missing   |                            |           |
+------------+-----------+----------------------------+-----------+
|            |           | 15: DISJOINTNESS-          | RFC 8800  |
|            |           | CONFIGURATION TLV missing  |           |
+------------+-----------+----------------------------+-----------+
| 10         | Reception |                            | [RFC5440] |
|            | of an     |                            |           |
|            | invalid   |                            |           |
|            | object    |                            |           |
+------------+-----------+----------------------------+-----------+
|            |           | 32: Incompatible OF code   | RFC 8800  |
+------------+-----------+----------------------------+-----------+

         Table 6: PCEP-ERROR Object Error Types and Values

8. Manageability Considerations ✨

8.1. Control of Function and Policy 👑

An operator SHOULD be allowed to configure the Disjoint Association Groups and disjoint parameters at the PCEP peers and tie them to the LSPs. The operator MUST be allowed to set the Operator-configured Association Range 🫶 And the operator SHOULD be allowed to set local policies that define the different disjoint computational behaviour at the PCE.

8.2. Information and Data Models 🦋

An implementation SHOULD let the operator view the disjoint associations that were configured or created dynamically. Also, implementations SHOULD let people view the disjoint associations reported by each peer, plus the current set of LSPs in that association. The PCEP YANG module [PCEP-YANG] includes association group information 🍓

8.3. Liveness Detection and Monitoring 🌸

Mechanisms in this document don't add any new liveness detection and monitoring requirements on top of the ones already listed in [RFC5440] ✨

8.4. Verification of Correct Operations 🔥

Besides the operation verification requirements already listed in [RFC5440], a PCEP implementation SHOULD provide parameters related to disjoint path computation, like the number of DAGs and the number of disjoint path computation failures, etc. 💅 A PCEP implementation SHOULD also log failure events (for example, incompatible Flags) 🙈

8.5. Requirements on Other Protocols 🧚

Mechanisms defined in this document don't add any new requirements on other protocols. Easy 💖

8.6. Impact on Network Operations 🌈

The stuff in Section 8.6 of [RFC5440] also applies to the PCEP extensions defined in this document 🫶 On top of that, a PCEP implementation SHOULD allow a limit to be placed on the number of LSPs that can belong to a DAG 👑

9. References 📚

9.1. Normative References 💜

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
              Objective Functions in the Path Computation Element
              Communication Protocol (PCEP)", RFC 5541,
              DOI 10.17487/RFC5541, June 2009,
              <https://www.rfc-editor.org/info/rfc5541>.

   [RFC7470]  Zhang, F. and A. Farrel, "Conveying Vendor-Specific
              Constraints in the Path Computation Element Communication
              Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
              <https://www.rfc-editor.org/info/rfc7470>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC8685]  Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
              and D. King, "Path Computation Element Communication
              Protocol (PCEP) Extensions for the Hierarchical Path
              Computation Element (H-PCE) Architecture", RFC 8685,
              DOI 10.17487/RFC8685, December 2019,
              <https://www.rfc-editor.org/info/rfc8685>.

   [RFC8697]  Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
              Dhody, D., and Y. Tanaka, "Path Computation Element
              Communication Protocol (PCEP) Extensions for Establishing
              Relationships between Sets of Label Switched Paths
              (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
              <https://www.rfc-editor.org/info/rfc8697>.

9.2. Informative References 📚

These are the extra reads that help you understand the vibe, but they aren't required to implement the spec 💅

Acknowledgments 🙏✨

A huge shoutout to the authors of [RFC8697] 🫶 this document borrows some of their text, which is so iconic of them. The authors would also like to thank Adrian Farrel and Julien Meuric for the super valuable comments 💜

Thanks to Emmanuel Baccelli for the RTGDIR review 🦋

Thanks to Dale Worley for a detailed GENART review 🌸

Thanks to Alvaro Retana, Benjamin Kaduk, Suresh Krishnan, Roman Danyliw, Alissa Cooper, and Éric Vyncke for the IESG review 👑

Contributors 🌈

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

Email: dhruv.ietf@gmail.com

Authors' Addresses 🎀

Stephane Litkowski
Cisco Systems, Inc.

Email: slitkows.ietf@gmail.com


Siva Sivabalan
Ciena Corporation

Email: msiva282@gmail.com


Colby Barth
Juniper Networks

Email: cbarth@juniper.net


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

That's the whole RFC, bestie! 🧚💖 Literally so many brilliant people made this happen. Slay! 💅

📦 where this page comes from