RFC 5640

RFC 5640: Load-Balancing for Mesh Softwires 🎀

Okay bestie, this is RFC 5640, published August 2009 by the Network Working Group as a Standards Track doc. The authors are Clarence Filsfils, Pradosh Mohapatra, and Carlos Pignataro, all from Cisco Systems 💅 It doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Abstract 💖

So a Softwire mesh service (set up through the BGP Encapsulation SAFI info exchange) often carries a bunch of identifiable, distinct flows 🦋 Sometimes you want to spread those flows across the equal cost multiple paths (ECMPs) in the packet switched network. The problem is that only the ingress and egress routers can read the payload of a packet entering the Softwire 😭 So a core router only gets to decide based on the encapsulating header, which has way less entropy than the payload or the encapsulated header, because the Softwire encapsulation works like a tunnel. This doc describes a method to get load-balancing that's just as efficient as it would be without the encapsulation, for networks carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) 🌈

Status of This Memo 🌸

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

Copyright Notice 🧚

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

---

Table of Contents 📋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 2
2.  Load-Balancing Block sub-TLV  . . . . . . . . . . . . . . . . . 2
  2.1.  Applicability to Tunnel Types . . . . . . . . . . . . . . . 3
  2.2.  Encapsulation Considerations  . . . . . . . . . . . . . . . 4
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5

---

1. Introduction 🦋

Picture this: router R1 wraps a packet P into a Softwire that's bound to router R3 💫 R2 sits on the shortest path from R1 to R3, and R2's shortest path to R3 has equal cost multiple paths (ECMPs). The goal is for R2 to pick its path based on the full entropy of packet P, and that's the whole point 🎀

Here's how we get there: the encapsulation header carries a signature of the inner header, which boosts the entropy of the flows the core routers see. That signature rides in one of the fields of the encapsulation header. To keep things clear, the doc uses the generic term "load-balancing field" for a value specific to an encapsulation type. For L2TPv3-over-IP [RFC3931] encapsulation, the load-balancing field is the Session Identifier (Session ID). For GRE [RFC2784] encapsulation, the Key field [RFC2890] is the load-balancing field, if it's present. This mechanism assumes core routers base their load-balancing decisions on a flow definition that includes the load-balancing field. Honestly it's an obvious, generic feature: for L2TPv3-over-IP tunnels, the Session ID sits at the same well-known constant offset as the TCP/UDP ports in the encapsulating header 🧠

The Encapsulation SAFI [RFC5512] gets extended so that a contiguous block of the load-balancing field is bound to the Softwire advertised by a BGP next-hop. For each inner flow, the ingress Provider Edge (PE) picks one value of the load-balancing field from that block. This keeps per-flow ordering intact and still boosts entropy across flows 👑

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

2. Load-Balancing Block sub-TLV 💅

This doc defines a new sub-TLV for the Tunnel Encapsulation Attribute defined in [RFC5512]. It's called the "Load-Balancing Block sub-TLV", and it MAY be included in any Encapsulation SAFI UPDATE message where load-balancing is desired 🌈

The sub-TLV type is 5, and the sub-TLV length is 2 octets. The value is the length of the block in bits, and it MUST NOT exceed the size of the load-balancing field. The format is basically like variable-length subnet masking (VLSM) for IP addresses, which lets you have prefixes of any length 🦋 The block is the initial sequence of 'block size' bits pulled from the load-balancing field.

If a load-balancing field isn't signaled (for example, the encapsulation sub-TLV isn't in an advertisement, like GRE without a Key), then the Load-Balancing Block sub-TLV MUST NOT be included 🙈

Here's the tradeoff: the smaller the value field, the more room there is for per-flow identification. That means better entropy for load-balancing in the core, and less polarization when flows get mapped to ECMP paths 💜 But shrinking the block eats up more L2TPv3 Session IDs or GRE Keys, so you may end up with fewer supported services. A typical deployment has to arbitrate between the two ⚖️

Let's do an example 🎀 Say there's a Softwire between R1 and R3 with the L2TPv3-over-IP tunnel type. R3 encodes the Session ID with value 0x1234ABCD in the encapsulation sub-TLV, and it also includes the Load-Balancing Block sub-TLV with the value 24. Here's what that means:

• If an ingress router doesn't understand the Load-Balancing Block sub-TLV, it keeps using Session ID 0x1234ABCD and encapsulates every packet with that Session ID.
• If an ingress router does understand the Load-Balancing Block sub-TLV, it takes the first 24 bits of the Session ID (0x1234AB) as the block, then fills in the lower-order 8 bits with a per-flow identifier. For example, that identifier can come from the inner packet's source and destination addresses and TCP/UDP ports. This keeps per-flow ordering of packets intact 💖

This requirement and solution apply equally to GRE, where the Key plays the same role as the Session ID does in L2TPv3 🍓

And obviously, if an egress router doesn't support the Load-Balancing Block sub-TLV, the Softwire keeps working with a single load-balancing field that all ingress routers encapsulate with 🫶

2.1. Applicability to Tunnel Types 🔥

The Load-Balancing Block sub-TLV applies to tunnel types that define a load-balancing field. This doc defines load-balancing fields for tunnel types 1 (L2TPv3 over IP) and 2 (GRE) like this:

• L2TPv3 over IP - Session ID. You have to be careful to always create a non-zero Session ID 😭 When an egress router includes a Load-Balancing Block sub-TLV, it MUST encode the Session ID field of the encapsulation sub-TLV so that the most significant bits of the Session ID, after the block is extracted, are non-zero.
• GRE - GRE Key

This doc does NOT define a load-balancing field for the IP-in-IP tunnel type (tunnel type 7). Future tunnel types that want to use the Load-Balancing Block sub-TLV MUST define a load-balancing field that's part of the encapsulating header 👑

Wait, I'm making sure I didn't sneak a capital into the wrong place: "does not" above is lowercase in the original spec, so the word "NOT" in that line is not a key word. Keep it casual, bestie 💀

2.2. Encapsulation Considerations 🧚

Fields in the encapsulation header other than the load-balancing field aren't affected by the Load-Balancing Block sub-TLV. All the other encapsulation fields are shared between variations of the load-balancing field. For example, with the L2TPv3-over-IP tunnel type, if the egress router includes the optional cookie in the encapsulation sub-TLV during Softwire signaling, that cookie applies to every "Session ID" value the ingress router derives after applying the load-balancing block 🌸

3. IANA Considerations 📋

IANA has assigned the value 5 for the Load-Balancing Block sub-TLV in the BGP Tunnel Encapsulation Attribute Sub-TLVs registry. That registry's number space was created when [RFC5512] was published:

    Sub-TLV name                            Value
    -------------                           -----
    Load-Balancing Block                      5

4. Security Considerations 🔐

This doc defines a new sub-TLV for the BGP Tunnel Encapsulation Attribute. The security considerations for the BGP Encapsulation SAFI and the BGP Tunnel Encapsulation Attribute are covered in [RFC5512]. There are no additional security risks introduced by this design 😤

5. Acknowledgements 🫶

The authors would like to thank Stewart Bryant, Mark Townsley, Rajiv Asati, Kireeti Kompella, and Robert Raszuk for their review and comments 💖

6. Normative References 📚

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
• [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
• [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
• [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009.

---

Authors' Addresses 🌈

Clarence Filsfils
Cisco Systems
Brussels,
Belgium

EMail: cfilsfil@cisco.com


Pradosh Mohapatra
Cisco Systems
170 W. Tasman Drive
San Jose, CA  95134
USA

EMail: pmohapat@cisco.com


Carlos Pignataro
Cisco Systems
7200 Kit Creek Road, PO Box 14987
Research Triangle Park, NC  27709
USA

EMail: cpignata@cisco.com