RFC 5521

Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions

📅 published April 2009, from ietf

Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions ✨

🎀 okay so this is RFC 5521, a Standards Track doc from April 2009 (Network Working Group). The authors are E. Oki (University of Electro-Communications), T. Takeda (NTT), and A. Farrel (Old Dog Consulting). The header doesn't list anything it obsoletes or updates. 💅

Status of This Memo 🧾

bestie, this is an Internet standards track protocol spec for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright (c) 2009 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, as they stood on the publication date. Please read those carefully, because they spell out your rights and restrictions for this doc 📖 (the link is http://trustee.ietf.org/license-info).

Some of the material in here may have come from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get a proper license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌈

Abstract 🦋

okay so the Path Computation Element (PCE) handles path computation for traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks 🧚

When a Path Computation Client (PCC) asks a PCE for a route, it can be super useful for the PCC to add constraints. Those constraints can name abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that get explicitly excluded from the computed route. These are called "route exclusions" 🔥

The PCE Communication Protocol (PCEP) is built as the communication protocol between PCCs and PCEs, and this doc brings in PCEP extensions for route exclusions 💜

Table of Contents 📚

   1.  Introduction ................................................. 3
       1.1.  Conventions Used in This Document .......................3
   2.  Protocol Procedures and Extensions ........................... 4
       2.1.  Exclude Route Object (XRO) ............................. 4
             2.1.1.  Definition ..................................... 4
             2.1.2.  Processing Rules ............................... 8
       2.2.  Explicit Route Exclusion ............................... 9
             2.2.1.  Definition ..................................... 9
             2.2.2.  Processing Rules .............................. 10
   3.  Exclude Route with Confidentiality .......................... 11
       3.1.  Exclude Route Object (XRO) Carrying Path-Key .......... 11
             3.1.1.  Definition .................................... 11
             3.1.2.  Processing Rules .............................. 12
   4.  IANA Considerations ......................................... 13
       4.1.  PCEP Objects .......................................... 13
       4.2.  New Subobject for the Include Route Object ............ 13
       4.3.  Error Object Field Values ............................. 13
       4.4.  Exclude Route Flags ................................... 14
   5.  Manageability Considerations ................................ 14
   6.  Security Considerations ..................................... 14
   7.  References .................................................. 15
       7.1.  Normative References .................................. 15
       7.2.  Informative References ................................ 15
   Acknowledgements ................................................ 16

1. Introduction 🌸

so the Path Computation Element (PCE) from [RFC4655] is an entity that can compute a network path or route based on a network graph, and it can apply computational constraints. A Path Computation Client (PCC) can send requests to a PCE asking for paths to get computed 🫶

When a PCC asks a PCE for a route, it can be really useful for the PCC to name abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that should be explicitly excluded from the route ✨

For example, disjoint paths for inter-domain Label Switched Paths (LSPs) can be computed through cooperation between PCEs, where each one computes the segments across its own domain. To get a secondary (backup) path, a PCE can act as a PCC and ask another PCE for a route that has to be node/link/SRLG disjoint from the primary (working) path. Another example is when a network operator wants a path to dodge specific nodes for administrative reasons, maybe because those nodes are going out of service soon 🥹

[RFC4657] lays out generic requirements for a communication protocol between PCCs and PCEs. The generic constraints in [RFC4657] include route exclusions for links, nodes, and SRLGs. Basically, the need for route exclusions inside the PCC-PCE communication protocol is already settled 💅

The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs, and it's defined in [RFC5440]. This doc adds PCEP extensions to meet the route exclusion requirements in Sections 5.1.4 and 5.1.16 of [RFC4657] 🦋

Also, MPLS-TE and GMPLS signaling extensions for sharing route exclusions between network nodes for specific Label Switched Paths (LSPs) are described in [RFC4874]. You can set route exclusions during provisioning requests for specific LSPs by setting the mplsTunnelHopInclude object of MPLS-TE-STD-MIB, defined in [RFC3812], to false (2) 🍓

1.1. Conventions Used in This Document 🔑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. Protocol Procedures and Extensions 👑

This section walks through the procedures a PCE follows when it gets a path computation request with route exclusions from a PCC, and it defines how those exclusions get encoded 🧚

There are two types of route exclusion described in [RFC4874]:

  1. Exclusion of certain abstract nodes or resources from the whole path. This set of abstract nodes is called the Exclude Route List.
  2. Exclusion of certain abstract nodes or resources between a specific pair of abstract nodes present in an explicit path. These specific exclusions are called an Explicit Route Exclusion.

This doc defines protocol extensions so a PCC can specify both types of route exclusions to a PCE in a path computation request 💖

There's a new PCEP object, the Exclude Route Object (XRO), which carries the Exclude Route List. The existing Include Route Object (IRO) in PCEP [RFC5440] gets modified by adding a new IRO subobject, the Explicit Exclusion Route subobject (EXRS), which carries Explicit Route Exclusions 🌈

2.1. Exclude Route Object (XRO) 🎀

2.1.1. Definition

okay so the XRO is totally OPTIONAL bestie 🎀 and it MAY ride along inside Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages ✨

when it shows up in a PCReq, the XRO is basically a hit list of network resources that the PCE is being asked to keep OUT of the path it computes 🙈 each list member comes with flags that tell the PCE whether the resource MUST be excluded, or whether the PCE should just make best efforts to leave it out 💅

the XRO MAY be used on a PCRep that carries the NO-PATH object (aka the "oops, no path found" message 💀) to show which elements of the original XRO are the reason the PCE couldn't find a path 😭

the XRO MAY also be used on a PCRep for a successful path computation when the PCE wants to hand over a set of exclusions that get signaled during LSP setup, using the extensions to Resource Reservation Protocol (RSVP)-TE [RFC4874] 🦋

The XRO Object-Class is 17 🌸

The XRO Object-Type is 1 🌸

Here's the body layout, it's giving very neat 🎀

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Reserved               |   Flags                     |F|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: XRO Body Format ✨

Reserved: 16 bits - the rule is it MUST be set to zero on transmission and SHOULD be ignored on receipt 🫶

Flags: 16 bits - these are the flags currently defined:

  • F (Fail - 1 bit): when this is set, the requesting PCC needs a brand new path for an existing TE LSP that has failed 😭 If the F bit is set, the path of the existing TE LSP MUST be provided in the PCReq message using a Record Route Object (RRO) defined in [RFC5440]. This lets the PCE factor in the old path and the reserved resources so it doesn't double-book bandwidth, in case the Traffic Engineering Database (TED) hasn't been updated yet or the resources haven't been released yet 🧚 This is usually paired with excluding the failed resource that caused the LSP to die 💜

Subobjects: the XRO is made of one or more subobject(s) 💖 An XRO with no subobjects MUST NOT be sent and SHOULD be ignored on receipt 💀

In the subobject definitions below, a few fields mean the same thing every time, so here's the tea 🍓

X The X-bit says whether the exclusion is mandatory or just desired 👑 0 means the resource specified MUST be excluded from the path the PCE computes. 1 means the resource specified SHOULD be excluded from the computed path, but it MAY be included if PCE policy allows it and there's no viable path that meets the other constraints and avoids the resource 🥺

Type The type of the subobject. These subobject types are defined:

Type           Subobject
-------------+-------------------------------
1              IPv4 prefix
2              IPv6 prefix
4              Unnumbered Interface ID
32             Autonomous system number
34             SRLG

Length The length of the subobject, including the Type and Length fields 📏

Prefix Length Where it's present, this field can be used to indicate a set of addresses matching a prefix 🌈 If the subobject points at a single address, the prefix length MUST be set to the full length of the address 💅

Attribute The Attribute field tells you how the exclusion subobject is supposed to be interpreted 🔥

0 Interface The subobject is interpreted as an interface or a set of interfaces. All interfaces it identifies get excluded from the computed path according to the X-bit setting 🦋 This value is valid only for subobject types 1, 2, and 3.

1 Node The subobject is interpreted as a node or a set of nodes. All nodes it identifies get excluded from the computed path according to the X-bit setting 🧚 This value is valid only for subobject types 1, 2, 3, and 4.

2 SRLG The subobject either identifies an SRLG explicitly or means all of the SRLGs tied to the resource or resources it identifies 🌸 Any resource that shares an SRLG with those identified gets excluded from the computed path according to the X-bit setting ✨ This value is valid for all subobjects.

Reserved Reserved fields inside subobjects MUST be transmitted as zero and SHOULD be ignored on receipt 🫶

The subobjects are encoded like this, and yes it's a whole mood 🎀

IPv4 prefix Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 1   |     Length    | IPv4 address (4 bytes)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4 address (continued)      | Prefix Length |   Attribute   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 prefix Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 2   |     Length    | IPv6 address (16 bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv6 address (continued)      | Prefix Length |   Attribute   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unnumbered Interface ID Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 3   |     Length    |    Reserved   |  Attribute    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        TE Router ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Interface ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The TE Router ID and Interface ID fields are as defined in [RFC3477] 🌈

Autonomous System Number Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 4   |     Length    |      2-Octet AS Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that, as in other PCEP objects [RFC5440] and RSVP-TE objects [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is provided 🥺 It is anticipated that, as 4-octet AS Numbers become more common, both PCEP and RSVP-TE will be updated in a consistent way to add this support 🔥

SRLG Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 5   |     Length    |       SRLG Id (4 bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SRLG Id (continued)      |    Reserved   |  Attribute    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Attribute SHOULD be set to two (2) and SHOULD be ignored on receipt 💖

2.1.2. Processing Rules

so a PCC builds an XRO to encode everything it wants the PCE to exclude from the path it's asking for 🎀 For each exclusion, the PCC clears the X-bit to say the PCE is required to exclude the resources, or sets the X-bit to say the PCC just really wants them excluded 💅 For each exclusion, the PCC also sets the Attribute field to tell the PCE how to read the exclusion subobject 🧚

When a PCE gets a PCReq, it looks for an XRO to see if exclusions are needed 👀 If the PCE finds more than one XRO, it MUST use the first one in the message and MUST ignore the subsequent instances 💀

If the PCE doesn't recognize the XRO, it MUST return a PCErr message with Error-Type "Unknown Object" as described in [RFC5440] 😭

If the PCE is unwilling or unable to process the XRO, it MUST return a PCErr message with the Error-Type "Not supported object" and follow the relevant procedures described in [RFC5440] 🙈

If the PCE processes the XRO and attempts to compute a path, it MUST adhere to the requested exclusions as expressed in the XRO 🫶 That means the returned path MUST NOT include any resources encoded with the X-bit clear, and SHOULD NOT include any with the X-bit set unless alternate paths that match the other constraints expressed in the PCReq are unavailable 🌸

When a PCE returns a path in a PCRep, it MAY also supply an XRO 🦋 An XRO in a PCRep message with the NO-PATH object indicates that the set of elements of the original XRO prevented the PCE from finding a path ✨ On the other hand, if an XRO is present in a PCRep message without a NO-PATH object, the PCC SHOULD apply the contents using the same rules as in [RFC4874], and the PCC or a corresponding LSR SHOULD signal an RSVP-TE XRO to indicate the exclusions that downstream LSRs should apply 🌈 This may be particularly useful in per-domain path computation scenarios [RFC5152] 👑

2.2. Explicit Route Exclusion

2.2.1. Definition ✨

Okay bestie, Explicit Route Exclusion is how you tell the PCE which network elements must not or should not be used on the path between two abstract nodes or resources that are explicitly listed in the Include Route Object (IRO) [RFC5440]. 💖 The way it works is that we define a brand-new subobject for the IRO. 🦋

The new IRO subobject is the Explicit Exclusion Route subobject (EXRS), and it has type 33 (see Section 4). 💅 An EXRS holds one or more subobjects of its own. An EXRS MUST NOT be sent with no subobjects, and if one arrives with no subobjects, it MUST be ignored. 🙈

Here's the layout of the EXRS 👇

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|    Type     |     Length    |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                One or more EXRS subobjects                  //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Now the fields, one by one:

  • L MUST be set to zero on transmission and MUST be ignored on receipt.
  • Reserved MUST be set to zero on transmission and SHOULD be ignored on receipt.

The EXRS subobject can carry any of the subobjects defined for inclusion in the XRO by this document or by future documents. 🌈 The meanings of the XRO subobject fields stay exactly the same when those subobjects live inside an EXRS, with one twist: the scope of the exclusion is limited to the single hop between the previous and subsequent elements in the IRO. 🎀

2.2.2. Processing Rules 💜

A PCC that gives a PCE a partial explicit route in an IRO MAY also specify explicit exclusions by including one or more EXRSs in the IRO. ✨

If a PCE that does not support the use of EXRS gets an IRO in a PCReq message that contains an EXRS, it will respond according to the rules for a malformed object as described in [RFC5440]. 💀 The PCE MAY also include the IRO in the PCErr to indicate in which case the IRO SHOULD be terminated immediately after the unrecognized EXRS.

If a PCE that supports the EXRS in an IRO parses an IRO and runs into an EXRS containing a subobject it doesn't support or recognize, it MUST act according to the setting of the X-bit in that subobject. 🔥 If the X-bit is clear, the PCE MUST respond with a PCErr with Error-Type "Unrecognized EXRS subobject" and set the Error-Value to the EXRS subobject type code (see Section 4). If the X-bit is set, the PCE MAY respond with a PCErr as already stated, or MAY ignore the EXRS subobject. Honestly, this choice is a local policy decision. 🧚

If a PCE parses an IRO and finds an EXRS subobject that it recognizes, it MUST act according to the requirements expressed in the subobject. 👑 That means that if the X-bit is clear, the PCE MUST NOT produce a path that includes any resource identified by the EXRS subobject in the path between the previous abstract node in the IRO and the next abstract node in the IRO. If the X-bit is set, the PCE SHOULD NOT produce a path that includes any resource identified by the EXRS subobject in that same segment, unless it is not possible to construct a path that avoids that resource while still complying with the other constraints expressed in the PCReq message. 🫶

A successful path computation reported in a PCRep message MUST include an ERO to specify the path that has been computed as specified in [RFC5440]. That ERO MAY contain specific route exclusions using the EXRS as specified in [RFC4874]. 🌸

If the path computation fails and a PCErr is returned with a NO-PATH object, the PCE MAY include an IRO to report the hops that could not be complied with as described in [RFC5440], and that IRO MAY include EXRSs. 😭

3. Exclude Route with Confidentiality 🔐

3.1. Exclude Route Object (XRO) Carrying Path-Key 🗝️

3.1.1. Definition 🌟

In PCE-based inter-domain diverse path computation, an XRO may be used to find a backup (secondary) path. ✨ A sequential path computation approach may be applied for this purpose, where a working (primary) path route is computed first and a backup path route that must be a node/link/SRLG disjoint route from the working path is then computed [RFC5298]. Backward Recursive Path Computation (BRPC) may be used for inter-domain path computation [RFC5441]. 🦋

In some cases of inter-domain computation (e.g., where domains are administered by different service providers), confidentiality must be kept. 🤫 For primary path computation, to preserve confidentiality, instead of explicitly expressing the computed route, Path-Key Subobjects (PKSs) [RFC5520] are carried in the Explicit Route Object (ERO) in the PCRep Message. 💜

Therefore, during inter-domain diverse path computation, it may be necessary to request diversity from a path that is not fully known and where a segment of the path is represented by a PKS. 🎀 This means that a PKS may be present as a subobject of the XRO on a PCReq message.

The format and definition of PKS when it appears as an XRO subobject are as defined in [RFC5520], except for the definition of the L bit. ⚠️ The L bit of the PKS subobject in the XRO MUST be ignored.

3.1.2. Processing Rules 🧠

Picture this: BRPC is applied for both working and backup path computation, one after the other. 💅 First, the PCC asks a PCE to compute a working path. After BRPC processing has completed, the PCC receives the results of the working-path computation expressed in an ERO in a PCRep message. The ERO may include PKSs if certain segments of the path are to be kept confidential. 🔒

For backup path computation, when the PCC builds a PCReq Message, it includes the entire working-path in the XRO so that the computed path is node/link disjoint from the working path. 🌈 The XRO may also include SRLGs to ensure SRLG diversity from the working path. If the working path ERO includes PKS subobjects, these are also included in the XRO so the PCE can make sure the diversity holds up. ✨

A set of PCEs for backup path computation may be the same as the ones for working path computation, or they may be different. 👯

  • Identical PCEs

In the case where the same PCEs are used for both path computations, the processing goes like this. During the process of BRPC for backup path computation, a PCE may encounter a PKS as it processes the XRO when it creates a virtual path tree (VPT) in its own domain. The PCE retrieves the PCE-ID from the PKS, recognizes itself, and converts the PKS into a set of XRO subobjects that it uses for the local calculation to create the VPT. The XRO subobjects created in this way MUST NOT be shared with other PCEs. Other operations are the same as BRPC. 🙌

  • Different PCEs

In the case where the set of PCEs for backup path computation is different from the ones used for working path computation, the processing goes like this. If a PCE encounters a PKS in an XRO when it is creating a virtual path tree in its own domain, the PCE retrieves the PCE-ID from the PKS and sends a PCReq message to the identified PCE to expand the PKS. The PCE computing the VPT treats the path segment in the response as a set of XRO subobjects in performing its path computation. The XRO subobjects determined in this way MUST NOT be shared with other PCEs. 🫠

4. IANA Considerations 📋

4.1. PCEP Objects 🎀

The "PCEP Parameters" registry contains a subregistry "PCEP Objects". IANA has made the following allocations from this registry.

   Object   Name                                          Reference
   Class
   17       XRO                                           [RFC5521]
              Object-Type
                1: Route exclusion

This object should be registered as being allowed to carry the following subobjects:

   Subobject Type                                         Reference
     1  IPv4 prefix                                       [RFC3209]
     2  IPv6 prefix                                       [RFC3209]
     4  Unnumbered Interface ID                           [RFC3477]
    32  Autonomous system number                          [RFC3209]
    34  SRLG                                              [RFC4874]
    64  Path-Key with 32-bit PCE ID                       [RFC5520]
    65  Path-Key with 128-bit PCE ID                      [RFC5520]

4.2. New Subobject for the Include Route Object 🦋

The "PCEP Parameters" registry contains a subregistry "PCEP Objects" with an entry for the Include Route Object (IRO).

IANA added a further subobject that can be carried in the IRO as follows:

Subobject Type                                         Reference

33  Explicit Exclusion Route subobject (EXRS)          [RFC4874]

4.3. Error Object Field Values 🙈

The "PCEP Parameters" registry contains a subregistry "Error Types and Values". IANA made the following allocations from this subregistry.

Error
Type  Meaning                                            Reference

11    Unrecognized EXRS subobject                        [RFC5521]

4.4. Exclude Route Flags 🚩

IANA created a subregistry of the "PCEP Parameters" for the bits carried in the Flags field of the Exclude Route Object (XRO). The subregistry is called "XRO Flag Field".

New bits may be allocated only by an IETF Consensus action. 🔐

The field contains 16 bits numbered from bit 0 as the most significant bit.

Bit      Name    Description                          Reference

15       F-bit   Fail                                 [RFC5221]

5. Manageability Considerations 🛠️

A MIB module for management of the PCEP is being specified in a separate document [PCEP-MIB]. That MIB module allows examination of individual PCEP messages, in particular requests, responses and errors. 👀

The MIB module MUST be extended to include the ability to view the route exclusion extensions defined in this document. 💖

Several local policy decisions should be made at the PCE. Firstly, the exact behavior with regard to desired exclusions must be available for examination by an operator and may be configurable. Second, the behavior on receipt of an unrecognized XRO or EXRS subobject with the X-bit set should be configurable and must be available for inspection. The inspection and control of these local policy choices may be part of the PCEP MIB module. 🧚

6. Security Considerations 🚨

⚠️ Okay, this part is serious, so read it carefully!

The new exclude route mechanisms defined in this document allow finer and more specific control of the path computed by a PCE. Such control increases the risk if a PCEP message is intercepted, modified, or spoofed, because it allows the attacker to exert control over the path that the PCE will compute or to make the path computation impossible. 💀 Therefore, the security techniques described in [RFC5440] are considered more important.

Note, however, that the route exclusion mechanisms also provide the operator with the ability to route around vulnerable parts of the network and may be used to increase overall network security. 🛡️✨

7. References 📚

(The reference list keeps going in the next part, bestie! 🦋)

7.1. Normative References

okay bestie, these are the big foundation docs 🧱✨ the ones you literally have to read before the rest makes sense, no cap. Here they are:

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
  • [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
  • [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
  • [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
  • [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009.

7.2. Informative References

ooh, and these are the extra reading 📚💅 handy for context, but the spec doesn't lean on them the same way. Lowkey iconic reading list:

  • [PCEP-MIB] Koushik, A. S. K., and E. Stephan, "PCE Communication Protocol(PCEP) Management Information Base", Work in Progress, November 2008.
  • [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
  • [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
  • [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
  • [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
  • [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
  • [RFC5298] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP. Vasseur, "Analysis of Inter-Domain Label Switched Path (LSP) Recovery", RFC 5298, August 2008.

Acknowledgements 🫶

the authors wanted to give a shoutout to Fabien Verhaeghe 💖 for super valuable comments on the subobject formats, and thanks to Magnus Westerlund, Dan Romascanu, Tim Polk, and Dave Ward for their comments during IESG review. so grateful, literally a whole squad 🌈

Authors' Addresses 💌

and here are the people behind it, with their contact deets 🦋

Eiji Oki
University of Electro-Communications
1-5-1 Chofugaoka
Chofu, Tokyo  182-8585
JAPAN

EMail: oki@ice.uec.ac.jp

Tomonori Takeda
NTT
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
EMail: takeda.tomonori@lab.ntt.co.jp

Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk

that's the whole RFC, bestie 🌈👑 you made it through!!

📦 where this page comes from