RFC 8012

Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs)

📅 published November 2016, from ietf

RFC 8012: Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) ✨

Okay bestie, let's talk about RFC 8012 🦋 It's a real IETF Standards Track document, so this is an actual spec people build against 💅 It was published in November 2016 under ISSN 2070-1721, and the authors are N. Akiya (Big Switch Networks), G. Swallow, C. Pignataro (Cisco), A. Malis (Huawei Technologies), and S. Aldrin (Google) 🫶 It doesn't list anything it obsoletes, but it updates RFC 6790 🌸 So if you're reading RFC 6790, you need this one too, periodt 💜

Abstract

Okay so the abstract is giving main character energy ✨ MPLS LSP ping and traceroute are the tools you use to test ECMP (Equal-Cost Multipath) paths 🛤️ Ping is the connectivity check, and traceroute is the fault-isolation one, as described in RFC 4379 🔍

Here's the drama 😭 When an LSP is signaled with the Entropy Label (EL) from RFC 6790, ping and traceroute can lose the ability to find and exercise those ECMP paths, if the Label Switching Routers (LSRs) are using different load-balancing techniques. Two examples: some LSRs do EL-based load balancing while others do non-EL stuff like IP-based, or an EL-based LSP gets stitched with another LSP that might or might not be EL-based. Not iconic 💀

So this doc steps in 🔥 It extends the MPLS LSP ping and traceroute multipath mechanisms from RFC 6424 so you can actually exercise LSPs that use the EL. It also updates RFC 6790 🎀

Status of This Memo

This is an Internet Standards Track document 💖

It's a product of the Internet Engineering Task Force (IETF), which means it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 If you want more on Internet Standards, check out Section 2 of RFC 7841 📚

For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc8012 🌈

Copyright (c) 2016 IETF Trust and the people listed as the document's authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info. The version in effect is the one on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🙈

One important bit: any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come without warranty, as described in the Simplified BSD License 🫶

Table of Contents

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................5
           1.1.1. Requirements Language ...............................6
      1.2. Background .................................................6
   2. Multipath Type {9} ..............................................7
   3. Pseudowire Tracing ..............................................7
   4. Entropy Label FEC ...............................................8
   5. DS Flags: L and E ...............................................9
   6. New Multipath Information Type {10} ............................10
   7. Initiating LSR Procedures ......................................12
   8. Responder LSR Procedures .......................................14
      8.1. IP-Based Load Balancer That Does Not Push ELI/EL ..........15
      8.2. IP-Based Load Balancer That Pushes ELI/EL .................15
      8.3. Label-Based Load Balancer That Does Not Push ELI/EL .......16
      8.4. Label-Based Load Balancer That Pushes ELI/EL ..............17
      8.5. Flow-Aware MS-PW Stitching LSR ............................18
   9. Supported and Unsupported Cases ................................18
   10. Security Considerations .......................................20
   11. IANA Considerations ...........................................21
      11.1. Entropy Label FEC ........................................21
      11.2. DS Flags .................................................21
      11.3. Multipath Type ...........................................21
   12. References ....................................................22
      12.1. Normative References .....................................22
      12.2. Informative References ...................................22
   Acknowledgements ..................................................23
   Contributors ......................................................23
   Authors' Addresses ................................................23

1. Introduction ✨

Okay so here's the basics 🧚 [RFC4379] describes LSP traceroute as an operation where the initiating LSR sends a series of MPLS echo requests toward the same destination. The first packet in the series has the TTL set to 1. When the echo reply comes back from the LSR one hop away, the second echo request gets sent with the TTL set to 2. For every extra echo request, the TTL goes up by one until a response comes back from the intended destination 🛤️ The initiating LSR finds and exercises ECMP by grabbing Multipath Information from each transit LSR and then using either a specific destination IP address or a specific entropy label 💅

Quick notation check 📝 From here on, {x, y, z} means Multipath Information Types x, y, or z. Those types are defined in Section 3.3 of [RFC4379].

The LSR starting the LSP ping sends an MPLS echo request with the Multipath Information. That info lives in the echo request's DDMAP TLV, and it can hold a set of IP addresses or a set of labels. Types {2, 4, 8} carry IP addresses, and Type {9} carries labels 🌸 The responder LSR (the one that receives the MPLS echo request) figures out which subset of the initiator's Multipath Information load balances to each downstream (outgoing) interface. Then it sends back an MPLS echo reply with the resulting Multipath Information for each downstream (outgoing) interface to the initiating LSR. Now the initiating LSR can use a specific IP destination address or a specific label to exercise one exact ECMP path on the responder LSR 🎀

But the current behavior is kinda problematic 😭 It breaks in these scenarios:

  • The initiating LSR sends IP Multipath Information, but the responder LSR load balances on labels.
  • The initiating LSR sends Label Multipath Information, but the responder LSR load balances on IP addresses.
  • The initiating LSR sends the existing Multipath Information to an LSR that pushes ELI/EL into the label stack. The initiating LSR can only keep discovering and exercising specific ECMP paths if that ELI/EL-pushing LSR replies with both the IP addresses and the associated EL for each IP address. Why? Because:
    • An ELI/EL-pushing LSR that is a stitching point will load balance based on the IP address.
    • Downstream LSR(s) of an ELI/EL-pushing LSR may load balance based on ELs.
  • The initiating LSR sends existing Multipath Information to an ELI/EL-pushing LSR. The initiating LSR can only keep discovering and exercising specific ECMP paths if the ELI/EL-pushing LSR replies with both the labels and the associated EL for each label. Why? Because:
    • An ELI/EL-pushing LSR that is a stitching point will load balance based on the EL from the previous LSP and then push a new EL.
    • Downstream LSR(s) of an ELI/EL-pushing LSR may load balance based on the new ELs.

Those scenarios show that the existing Multipath Information just isn't enough when LSP traceroute runs on an LSP with entropy labels [RFC6790] 😤 So this document defines a new Multipath Information Type for the DDMAP of MPLS echo request/reply packets on [RFC6790] LSPs 💜

The responder LSR can reply with empty Multipath Information if it gets no IP address set or no label set along with the Multipath Information. An empty return can also happen if the initiating LSR sends one type (IP Address or Label) and the responder LSR load balances on the other type. To tell those two empty results apart, this document adds new flags to the DDMAP TLV so the responder LSR can describe the load-balancing technique it's using 🔍

For this enhanced method to work end-to-end, all LSRs along the LSP need to understand the new flags and the new Multipath Information Type 🫶 Mechanisms to verify that condition are out of scope for this document. The rest of the requirements are spelled out in the initiating LSR and responder LSR procedures. Two additional DS Flags get defined for the DDMAP TLV in Section 6, and the responder LSR uses those two flags to describe its load-balancing behavior on a received MPLS echo request ✨

Heads up: "IP-Based Load Balancer" and "Label-Based Load Balancer" are defined in terms of how a received MPLS echo request gets handled by the responder LSR 🙈

1.1. Terminology

Here's the vocab you need 📚 The following abbreviations and terms are used in this document:

  • MPLS: Multiprotocol Label Switching.
  • LSP: Label Switched Path.
  • Stitched LSP: Stitched Label Switched Paths combine several LSPs so that a single end-to-end LSP is realized. [RFC6424] describes LSP ping for Stitched LSPs.
  • LSR: Label Switching Router.
  • FEC: Forwarding Equivalence Class.
  • ECMP: Equal-Cost Multipath.
  • EL: Entropy Label.
  • ELI: Entropy Label Indicator.
  • GAL: Generic Associated Channel Label.
  • MS-PW: Multi-Segment Pseudowire.
  • Initiating LSR: An LSR that sends an MPLS echo request.
  • Responder LSR: An LSR that receives an MPLS echo request and sends an MPLS echo reply.
  • IP-Based Load Balancer: An LSR that load balances on fields from an IP header (and possibly fields from upper layers) and does not consider an entropy label from an MPLS label stack (i.e., flow label [RFC6391] or entropy label [RFC6790]) for load-balancing purposes. 💅
  • Label-Based Load Balancer: An LSR that load balances on an entropy label from an MPLS label stack (i.e., flow label or entropy label) and does not consider fields from an IP header (and possibly fields from upper layers) for load-balancing purposes. 🦋
  • Label and IP-Based Load Balancer: An LSR that load balances on both entropy labels from an MPLS label stack and fields from an IP header (and possibly fields from upper layers). 👑

1.1.1. Requirements Language

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] 🎀

1.2. Background ✨

okay so MPLS implementations are lowkey all over the place when it comes to which fields they hash as load-balancing "keys" 🔀. The mechanisms in [RFC4379], updated by [RFC6424], only give multipath support for a subset of those techniques. This document is here to add multipath support for the supported techniques that get messed up by ELs [RFC6790] 💅. Section 9 covers the supported and unsupported cases, so it's giving "read this first" energy 📖.

The Downstream Detailed Mapping (DDMAP) TLV [RFC6424] carries Multipath Information 🗺️, which an LSP ping initiator can use to trace and validate ECMP paths between an ingress and egress. The Multipath Information encodings from [RFC6424] are honestly enough when every LSR along the path(s) between ingress and egress uses the same set of "keys" as load-balancing input, e.g., all IP based or all label based 🫧.

Then [RFC6790] came along and now some LSRs load balance on labels while others go IP based 😭. That means an LSP ping initiator can't trace and validate all the ECMP paths in these scenarios:

  • One or more transit LSRs along an LSP with ELI/EL in the label stack do not perform ECMP load balancing based on EL (hashes based on "keys" including the IP destination address). This scenario is not only possible but quite common, because transit LSRs might not implement [RFC6790], or they implement [RFC6790] but skip the suggested transit LSR behavior in Section 4.3 of [RFC6790] 🙈.
  • Two or more LSPs stitched together, with at least one of those LSPs pushing ELI/EL into the label stack 🧵.

These scenarios are super common because deployments of [RFC6790] usually have a mix of nodes that support ELI/EL and nodes that don't. There's also usually a mix of areas that support ELI/EL and areas that don't 🌈.

As [RFC6790] points out, the procedures of [RFC4379] (and therefore of [RFC6424]) for Multipath Information Type {9} are incomplete 🥲. But [RFC6790] doesn't actually update [RFC4379]. Also, the specific EL location isn't clearly defined, especially for Flow-Aware Pseudowires [RFC6391] 🤷‍♀️. So this document defines a new FEC Stack sub-TLV for the entropy label 🎀. Section 2 of this document updates the procedures for Multipath Information Type {9} that are described in [RFC4379] and apply to [RFC6424]. The rest of the document describes the extensions needed to restore ECMP discovery and tracing for the scenarios above 🦋.

[RFC4379], [RFC6424], and this document will support IP-based load balancers, and label-based load balancers that limit their hash to the first (top-most) or only entropy label in the label stack ✨. Other use cases (refer to Section 9) are out of scope 🙅‍♀️.

2. Multipath Type {9}

okay so [RFC4379] defined Multipath Type {9} for tracing LSPs where label-based load balancing is used 🔍. But as [RFC6790] pointed out, the procedures for using this type are incomplete, because the specific location of the label was never defined 🥴. The assumption was that having Multipath Type {9} meant the value of the bottom-of-stack label should be varied by the values in the multipath to figure out each outgoing interface 🧠.

Section 4 defines a new FEC-Stack sub-TLV to indicate an entropy label 💖. These labels MAY appear anywhere in a label stack 🫶.

Multipath Type {9} applies to the first label in the label stack that corresponds to an EL-FEC. If no such label is found, it applies to the label at the bottom of the label stack 👑.

3. Pseudowire Tracing

this section is all about the procedures for tracing Pseudowires 🧚. These procedures pertain to the use of Multipath Information Type {9} as well as Type {10}. In every case below, when a control word is in use, the N flag in the DDMAP MUST be set 💅. Heads up: when a control word is not in use, the returned DDMAPs may not be accurate 🙈.

To trace a Pseudowire that is not flow aware, the initiator includes an EL-FEC instead of the appropriate PW FEC at the bottom of the FEC Stack. Tracing this way makes compliant routers return the proper outgoing interface ✨. Just know this procedure only traces to the end of the MPLS LSP under test, and it will NOT verify the PW FEC 🙅‍♀️. To actually verify the PW FEC, or, in the case of an MS-PW, to figure out the next Pseudowire label value, the initiator MUST repeat that step of the trace (i.e., repeating the TTL value used) but with the FEC Stack modified to contain the appropriate PW FEC 🔁. These procedures apply to scenarios where the initiator can vary the bottom label (i.e., the Pseudowire label) 🎯. Possible scenarios are tracing multiple Pseudowires that are not flow aware on the same endpoints, or tracing a Pseudowire that is not flow-aware but is provisioned with multiple Pseudowire labels 🦄.

To trace a flow-aware Pseudowire [RFC6391], the initiator includes an EL FEC at the bottom of the FEC Stack and pushes the appropriate PW FEC onto the FEC Stack 🌸.

To trace through routers that aren't compliant, the initiator forms an MPLS echo request message and includes a DDMAP with the Multipath Type {9} 📨. For a Pseudowire that is not flow aware, it includes the appropriate PW FEC in the FEC Stack. For a flow-aware Pseudowire, the initiator includes a Nil FEC at the bottom of the FEC Stack and pushes the appropriate PW FEC onto the FEC Stack 💜.

4. Entropy Label FEC

the ELI is a reserved label with no associated explicit FEC, and its label value is 7, taken from the reserved range 🧊. To account for ELI in a Target FEC Stack TLV, use the Nil FEC as the Target FEC Stack sub-TLV 🫧.

The EL is a special-purpose label whose label value is discretionary (i.e., the label value is not from the reserved range) 🌷. For LSP verification mechanics to do their job, a Target FEC Stack sub-TLV has to clearly describe the EL 📋. This matters most when the label stack doesn't carry ELI (e.g., a flow-aware Pseudowire [RFC6391]) 😤. So this document defines an EL FEC sub-TLV (33, see Section 11.1) that lets a Target FEC Stack sub-TLV be added to the Target FEC Stack to account for EL 🍓.

The Length is 4. Labels are 20-bit values treated as numbers 🔢.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Label                 |          MBZ          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Entropy Label FEC 🖼️

"Label" is the actual label value inserted in the label stack. The "MBZ" field MUST be zero when sent and ignored on receipt 🫶.

5. DS Flags: L and E

two flags, L and E, get added to the DS Flags field of the DDMAP TLV 🎉. Both flags MUST NOT be set in echo request packets when sending, and they SHOULD be ignored when received 🙈. Zero, one, or both of the new flags MUST be set in echo reply packets 💅.

    DS Flags
    --------

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |  MBZ  |L|E|I|N|
       +-+-+-+-+-+-+-+-+
    Flag  Name and Meaning
    ----  ----------------
       L  Label-based load balance indicator
          This flag MUST be cleared in the echo request.  An LSR
          that performs load balancing on a label MUST set this
          flag in the echo reply.  An LSR that performs load
          balancing on IP MUST NOT set this flag in the echo
          reply.

       E  ELI/EL push indicator
          This flag MUST be cleared in the echo request.  An LSR
          that pushes ELI/EL MUST set this flag in the echo
          reply.  An LSR that does not push ELI/EL MUST NOT set
          this flag in the echo reply.

the two flags give us four load-balancing techniques that the echo reply generating LSR can indicate 🦋:

  • {L=0, E=0} LSR load balances based on IP and does not push ELI/EL. 🌈
  • {L=0, E=1} LSR load balances based on IP and pushes ELI/EL. 🌸
  • {L=1, E=0} LSR load balances based on labels and does not push ELI/EL. 🍓
  • {L=1, E=1} LSR load balances based on labels and pushes ELI/EL. 👑

6. New Multipath Information Type {10} ✨

Okay so this is the new one, bestie 🦋 One new Multipath Information Type gets added for use in the DDMAP TLV, and it's value is 10. Here's the table:

     Key   Type                  Multipath Information
     ---   ----------------      ---------------------
     10    IP and Label set      IP addresses and label prefixes

Multipath Information Type {10} is made of three sections 💅 The first one describes the IP address set. The second one describes the label set. The third one describes another label set, and it's linked to either the IP address set or the label set from the other sections. Main character energy 👑

Here's the format:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPMultipathType|     IP Multipath Length       | Reserved(MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|                  (IP Multipath Information)                   |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LbMultipathType|    Label Multipath Length     | Reserved(MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|                 (Label Multipath Information)                 |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assoc. Label Multipath Length |         Reserved(MBZ)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|            (Associated Label Multipath Information)           |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Multipath Information Type {10}

Here's what each field is giving:

  • IPMultipathType
    • 0 when "IP Multipath Information" is omitted. Otherwise, it's one of the IP Multipath Information values: {2, 4, 8}.
  • IP Multipath Information
    • This section is omitted when IPMultipathType is 0. Otherwise, it reuses the IP Multipath Information from [RFC4379]. Specifically, Multipath Information for values {2, 4, 8} can be used.
  • LbMultipathType
    • 0 when the Label Multipath Information is omitted. Otherwise, it's the Label Multipath Information value {9}.
  • Label Multipath Information
    • This section is omitted when LbMultipathType is 0. Otherwise, it reuses the Label Multipath Information from [RFC4379]. Specifically, the Multipath Information for value {9} can be used.
  • Associated Label Multipath Information
    • "Associated Label Multipath Length" is a 16-bit field of Multipath Information that tells you the length in octets of the Associated Label Multipath Information.
    • "Associated Label Multipath Information" is a list of labels, with each label described in 24 bits 🧚 This section MUST be omitted in an MPLS echo request message. A midpoint that pushes ELI/EL labels SHOULD include "Associated Label Multipath Information" in its MPLS echo reply message, along with either "IP Multipath Information" or "Label Multipath Information". Each associated label in this section maps to one specific IP address or label described in the "IP Multipath Information" section or the "Label Multipath Information" section. For example, if three IP addresses are specified in the "IP Multipath Information" section, then there MUST be three labels described in this section. The first label maps to the first IP address, the second label maps to the second IP address, and the third label maps to the third IP address. Organized 🎀

When a section is omitted, the length for that section MUST be set to zero. No exceptions, periodt 💀

7. Initiating LSR Procedures 🔥

This procedure is explained in terms of an EL_LSP boolean that the initiating LSR keeps track of. This value controls which Multipath Information Type gets used in the echo request packets it sends. When the initiating LSR sends an echo request packet with DDMAP and a non-zero Multipath Information Type, the EL_LSP boolean MUST be consulted to figure out which Multipath Information Type to use.

On top of the procedures in [RFC4379] (as updated by Section 2) and [RFC6424], the initiating LSR MUST also follow these:

  • When the initiating LSR pushes ELI/EL, initialize EL_LSP=True. Else, set EL_LSP=False.
  • When the initiating LSR is sending a non-zero Multipath Information Type:
    • If (EL_LSP), the initiating LSR MUST use the Multipath Information Type {10}, unless the responder LSR cannot handle Type {10}. When the initiating LSR is sending Multipath Information Type {10}, both "IP Multipath Information" and "Label Multipath Information" MUST be included, and "Associated Label Multipath Information" MUST be omitted (NULL).
    • Else, the initiating LSR MAY use the Multipath Information Type {2, 4, 8, 9, 10}. When the initiating LSR is sending Multipath Information Type {10} in this case, "IP Multipath Information" MUST be included, and "Label Multipath Information" and "Associated Label Multipath Information" MUST be omitted (NULL).
  • When the initiating LSR receives an echo reply with {L=0, E=1} in the DS Flags and the contents are valid, set EL_LSP=True.

Sometimes the initiating LSR may have lost the ability to use specific ECMP paths 🥺 In these cases, it MAY keep going with "best effort":

  • Received echo reply contains empty Multipath Information.
  • Received echo reply contains {L=0, E=<any>} DS Flags, but does not contain IP Multipath Information.
  • Received echo reply contains {L=1, E=<any>} DS Flags, but does not contain Label Multipath Information.
  • Received echo reply contains {L=<any>, E=1} DS Flags, but does not contain Associated Label Multipath Information.
  • IP Multipath Information Types {2, 4, 8} sent, and received echo reply with {L=1, E=0} in DS Flags.
  • Multipath Information Type {10} sent, and received echo reply with Multipath Information Type other than {10}.

8. Responder LSR Procedures 🌈

Common Procedures:

  • The responder LSR receiving an MPLS echo request packet MUST first figure out whether or not the initiating LSR supports this LSP ping and traceroute extension for entropy labels 🔍 If either of the following conditions is met, the responder LSR SHOULD decide that the initiating LSR does support this LSP ping and traceroute extension for entropy labels:
    1. Received MPLS echo request contains the Multipath Information Type {10}.
    2. Received MPLS echo request contains a Target FEC Stack TLV that includes the entropy label FEC.

If the initiating LSR is decided not to support this LSP ping and traceroute extension for entropy labels, then the responder LSR MUST NOT follow the further procedures described in this section. Specifically, MPLS echo reply packets:

  • MUST have the following DS Flags cleared (i.e., not set): "ELI/EL push indicator" and "Label-based load balance indicator".
  • MUST NOT use the Multipath Information Type {10}.
  • The responder LSR receiving an MPLS echo request packet with the Multipath Information Type {10} MUST validate the following contents. Any deviation MUST result in the responder LSR treating the packet as malformed and returning code 1 ("Malformed echo request received") in the MPLS echo reply packet 🚫
    • IP Multipath Information MUST be included.
    • Label Multipath Information MAY be included.
    • Associated Label Multipath Information MUST be omitted (NULL).

The following subsections describe the expected responder LSR procedures when the echo reply is supposed to include DDMAP TLVs, based on the local load balance technique being used. If the responder LSR runs deviating load balance techniques on a per-downstream basis, the appropriate procedures matched to each downstream load balance technique MUST be followed. ✨

8.1. IP-Based Load Balancer That Does Not Push ELI/EL

  • The responder MUST set {L=0, E=0} in the DS Flags.
  • If the Multipath Information Type {2, 4, 8} is received, the responder MUST comply with [RFC4379] and [RFC6424].
  • If the Multipath Information Type {9} is received, the responder MUST reply with Multipath Type {0}.
  • If the Multipath Information Type {10} is received, the following procedures are used:
    • The responder MUST reply with the Multipath Information Type {10}.
    • The "Label Multipath Information" and "Associated Label Multipath Information" sections MUST be omitted (NULL).
    • If no matching IP address is found, then the IPMultipathType field MUST be set to the Multipath Information Type {0}, and the "IP Multipath Information" section MUST also be omitted (NULL).
    • If at least one matching IP address is found, then the IPMultipathType field MUST be set to the appropriate Multipath Information Type {2, 4, 8}, and the "IP Multipath Information" section MUST be included. 🦋

8.2. IP-Based Load Balancer That Pushes ELI/EL 💅

  • okay so the responder MUST set {L=0, E=1} in DS Flags 🎀
  • if the Multipath Information Type {9} shows up, the responder MUST reply with Multipath Type {0} 🦋
  • if the Multipath Type {2, 4, 8, 10} gets received, here's the vibe:
    • the responder MUST respond with Multipath Type {10}. See Section 6 for the deets on Multipath Type {10} ✨
    • the "Label Multipath Information" section MUST be omitted (aka it is not there) 🙈
    • the IP address set in the received IP Multipath Information MUST be used to figure out the returned IP/Label pairs 💖
    • if the received Multipath Information Type was {10}, the received "Label Multipath Information" sections MUST NOT be used to determine the associated label portion of the returned IP/Label pairs 🚫
    • if there's no matching IP address, then the IPMultipathType field MUST be set to Multipath Information Type {0} and the "IP Multipath Information" section MUST be omitted. Also, the Associated Label Multipath Length MUST be set to 0, and the "Associated Label Multipath Information" section MUST also be omitted 💀
    • if there's at least one matching IP address, then the IPMultipathType field MUST be set to the right Multipath Information Type {2, 4, 8} and the "IP Multipath Information" section MUST be included. The "Associated Label Multipath Information" section MUST be filled with a list of labels, one for each IP address in the "IP Multipath Information" section. And Associated Label Multipath Length MUST be set to the length in octets of the "Associated Label Multipath Information" field 🌈

8.3. Label-Based Load Balancer That Does Not Push ELI/EL 🧚

  • the responder MUST set {L=1, E=0} in DS Flags 🍓
  • if the Multipath Information Type {2, 4, 8} is received, the responder MUST reply with Multipath Type {0} 🙅‍♀️
  • if the Multipath Information Type {9} is received, the responder MUST comply with [RFC4379] and [RFC6424] as updated by Section 2 📜
  • if the Multipath Information Type {10} is received, here's the flow:
    • the responder MUST reply with Multipath Information Type {10} 🫶
    • the "IP Multipath Information" and "Associated Label Multipath Information" sections MUST be omitted (NULL) 🫥
    • if there's no matching label, then the LbMultipathType field MUST be set to Multipath Information Type {0} and the "Label Multipath Information" section MUST also be omitted (NULL) 😭
    • if there's at least one matching label, then the LbMultipathType field MUST be set to the right Multipath Information Type {9} and the "Label Multipath Information" section MUST be included ✨

8.4. Label-Based Load Balancer That Pushes ELI/EL 👑

  • the responder MUST set {L=1, E=1} in DS Flags 💜
  • if the Multipath Information Type {2, 4, 8} is received, the responder MUST reply with Multipath Type {0} 🌸
  • if the Multipath Type {9, 10} is received, here's the vibe:
    • the responder MUST respond with Multipath Type {10} 🎀
    • the "IP Multipath Information" section MUST be omitted 🙈
    • the label set in the received Label Multipath Information MUST be used to determine the returned Label/Label pairs 🔥
    • if the received Multipath Information Type was {10}, the "Label Multipath Information" sections MUST NOT be used to determine the associated label portion of the returned Label/Label pairs 🚫
    • if there's no matching label, then the LbMultipathType field MUST be set to Multipath Information Type {0} and the "Label Multipath Information" section MUST be omitted. The Associated Label Multipath Length MUST be set to 0, and the "Associated Label Multipath Information" section MUST also be omitted 💀
    • if there's at least one matching label, then the LbMultipathType field MUST be set to the right Multipath Information Type {9} and the "Label Multipath Information" section MUST be included. The "Associated Label Multipath Information" section MUST be filled with a list of labels, one for each label in the "Label Multipath Information" section. The Associated Label Multipath Length MUST be set to the length in octets of the "Associated Label Multipath Information" field 🌈

8.5. Flow-Aware MS-PW Stitching LSR 🦋

okay so a stitching LSR that cross-connects flow-aware Pseudowires can act in one of two ways:

  • it load balances on the previous flow label and carries over the same flow label. In this case, the stitching LSR is to behave as described in Section 8.3 🫶
  • it load balances on the previous flow label and replaces the flow label with a newly computed label. In this case, the stitching LSR is to behave as described in Section 8.4 ✨

9. Supported and Unsupported Cases 🌈

Real talk, the MPLS architecture doesn't set strict rules for how implementations pick their hash "keys" for load balancing. So implementations can end up as any of these load balancer types:

  1. IP-based load balancer.
  2. Label-based load balancer.
  3. Label- and IP-based load balancer.

For cases (2) and (3), an implementation can use different sets of labels from the label stack for load balancing. That gives us these sub-cases:

a. Entire label stack. b. Top N labels from label stack where the number of labels in label stack is > N. c. Bottom N labels from label stack where the number of labels in label stack is > N.

If there's one flow label or entropy label in the label stack, these extra cases are possible for (2b), (2c), (3b), and (3c):

  1. N labels from label stack include flow label or entropy label.
  2. N labels from label stack do not include flow label or entropy label.

Also, if there are multiple entropy labels in the label stack, implementations can get creative in different ways:

  • search for entropy stops at the first entropy label
  • search for entropy includes any entropy label found plus continues to search for entropy in the label stack

Reserved (aka special) labels are a whole other vibe, because implementations handle them differently too:

  • reserved labels are used in the hash as any other label would be (not a recommended practice) 🙃
  • reserved labels are skipped over and, for implementations limited to N labels, the reserved labels do not count towards the limit of N
  • reserved labels are skipped over and, for implementations limited to N labels, the reserved labels count towards the limit of N

This matters because the presence of GAL will affect those implementations that include reserved labels for load-balancing purposes. Keep that in mind, bestie 👀

As you can see, there are a LOT of possible load-balancing implementations. Trying to get any Operations, Administration, and Maintenance (OAM) tools to support ECMP discovery and traversal over all of them would need pretty complex procedures. And complexity in OAM tools doesn't buy much if most implementations only use a small subset of these cases 😮‍💨

  • Section 4.3 of [RFC6790] says that, for load-balancing purposes, parsing beyond the label stack after finding an entropy label has "limited incremental value". So most implementations are expected to be "IP-based load balancer" or "Label-based load balancer" types 💅
  • Section 2.4.5.1 of [RFC7325] recommends that searching for entropy labels in the label stack should stop once the first entropy label is found. So implementations are expected to include only the first (top-most) entropy label when there are multiple entropy labels in the label stack 🎀
  • in most cases, the number of labels in the label stack is not expected to go over the number of labels (N) that implementations can include for load balancing 🌸
  • labels in the label stack, besides the flow label and entropy label, are expected to stay constant for the lifetime of a single LSP multipath traceroute operation. So deviating load-balancing implementations with respect to reserved labels should not affect this tool 🧚

So yeah, [RFC4379], [RFC6424], and this document support cases (1) and (2a1), where only the first (top-most) entropy label is included when there are multiple entropy labels in the label stack. Periodt 💖

10. Security Considerations 🔐

Okay, bestie, this part is serious. While [RFC4379] and [RFC6424] already let you discover and exercise ECMP paths, this document takes LSP ping and traceroute further, so you can more precisely discover and exercise ECMP paths when an LSP uses ELI/EL in the label stack. And sourcing or inspecting LSP ping packets can be used for network reconnaissance 👀🚨

The extended capability in this document needs a little extra processing for the responder and initiator nodes. The responder node that pushes ELI/EL will need to compute and return multipath data, including the associated EL. The initiator node will need to store and handle both IP Multipath and Label Multipath Information. It also needs to include destination IP addresses and/or ELs in MPLS echo request packets, as well as in the Multipath Information sent to downstream nodes. The security considerations of [RFC4379] already cover Denial-of-Service attacks by regulating LSP ping traffic going to the control plane 🛡️

Finally, the security measures described in [RFC4379], [RFC6424], and [RFC6790] apply here too. [RFC6424] gives guidelines if a network operator wants to prevent tracing or doesn't want to expose details of the tunnel, and [RFC6790] gives guidance on the use of the EL 🫶

11. IANA Considerations 🦋

11.1. Entropy Label FEC 🌷

IANA has assigned a new sub-TLV from the "Sub-TLVs for TLV Types 1, 16, and 21" section of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry under "TLVs" ([IANA-MPLS-LSP-PING]). Slay 💅

    Sub-Type Sub-TLV Name          Reference
    -------- ------------          ---------
       33     Entropy label FEC     this document

11.2. DS Flags 🌈

IANA has assigned new bit numbers from the "DS Flags" subregistry, which lives in the "TLVs" section of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry ([IANA-MPLS-LSP-PING]).

Note: The "DS Flags" subregistry was created by [RFC7537].

    Bit number Name                                        Reference
    ---------- ----------------------------------------    ---------
        5       E: ELI/EL push indicator                    this document
        4       L: Label-based load balance indicator       this document

11.3. Multipath Type 🦋

okay so IANA assigned a new value in the "Multipath Type" subregistry, which lives under the "TLVs" section of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry 💅 ([IANA-MPLS-LSP-PING]).

Note: the "Multipath Type" subregistry was created by [RFC7537]. 🫶
    Value      Meaning                                  Reference
    ---------- ---------------------------------------- ---------
      10       IP and label set                         this document

12. References 📚

12.1. Normative References ✨

12.2. Informative References 🌈

Acknowledgements 🙈

The authors would like to thank Loa Andersson, Curtis Villamizar, Daniel King, Sriganesh Kini, Victor Ji, Acee Lindem, Deborah Brungard, Shawn M Emery, Scott O. Bradner, and Peter Yee for performing thorough reviews and providing very valuable comments. 🫶✨

Carlos Pignataro would like to acknowledge his lifetime friend Martin Rigueiro, with deep gratitude and esteem, for sharing his contagious passion for engineering and sciences, and for selflessly teaching so many lessons. 🥹💖

Contributors 🎀

Nagendra Kumar Cisco Systems, Inc. Email: naikumar@cisco.com

Authors' Addresses 👑

Nobo Akiya Big Switch Networks Email: nobo.akiya.dev@gmail.com

George Swallow Cisco Systems, Inc. Email: swallow@cisco.com

Carlos Pignataro Cisco Systems, Inc. Email: cpignata@cisco.com

Andrew G. Malis Huawei Technologies Email: agmalis@gmail.com

Sam Aldrin Google Email: aldrin.ietf@gmail.com

📦 where this page comes from