RFC 8668

Advertising Layer 2 Bundle Member Link Attributes in IS-IS

📅 published December 2019, from ietf

okay bestie, let's get into it ✨ This is RFC 8668, titled "Advertising Layer 2 Bundle Member Link Attributes in IS-IS", published by the Internet Engineering Task Force (IETF) as a Request for Comments. It's on the Standards Track 🔥, dated December 2019, with ISSN 2070-1721. The title block doesn't list any Obsoletes or Updates entries, so it doesn't replace or change any other RFC 💅

The editor is L. Ginsberg, Ed. of Cisco Systems, Inc. Co-authors are A. Bashandy (Unaffiliated), C. Filsfils (Cisco Systems, Inc.), M. Nanduri (Oracle), and E. Aries (Arrcus Inc.) 👑

Abstract ✨

okay so picture this: some deployments have a Layer 3 interface running IS-IS that is actually a Layer 2 interface bundle 🧚 Right now, IS-IS advertisements only carry link attributes for the Layer 3 interface itself. But if something outside IS-IS wants to steer traffic over the individual physical links inside that bundle, it needs attribute info about each bundle member, and that's the gap this doc fills 🦋

This document lets IS-IS advertise the link attributes of Layer 2 (L2) Bundle Members 💖

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. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8668 🔗

Copyright (c) 2019 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 📖

  • 1. Introduction
  • 2. Requirements Language
  • 3. L2 Bundle Member Attributes TLV
    • 3.1. Parallel L3 Adjacencies
    • 3.2. Shared Attribute Sub-TLVs
  • 4. Advertising L2 Bundle Member Adj-SIDs
    • 4.1. L2 Bundle Member Adjacency Segment Identifier Sub-TLV
    • 4.2. L2 Bundle Member LAN Adjacency SID Sub-TLV
  • 5. IANA Considerations
  • 6. Security Considerations
  • 7. References
    • 7.1. Normative References
    • 7.2. Informative References
  • Appendix A. Example Encoding
  • Acknowledgements
  • Contributors
  • Authors' Addresses

1. Introduction ✨

okay so there are deployments where the Layer 3 interface that an IS-IS adjacency runs on is a Layer 2 interface bundle, like a Link Aggregation Group (LAG) [IEEE802.1AX] 🍓 This cuts down on how many adjacencies the routing protocol has to maintain when neighbors have parallel links between them 💅 Things outside IS-IS, like Path Computation Elements (PCEs) [RFC4655], might want to control traffic on individual members of that Layer 2 bundle. To do that, they need link attribute info for each bundle member, and this doc has the extensions that make that advertising possible 🫶

This document introduces a new TLV that advertises link attribute information for each L2 Bundle Member making up the Layer 3 interface IS-IS runs on 🌸

[RFC8667] brings in a new link attribute, the adjacency segment identifier (Adj-SID), which can act as an instruction to forwarding to send traffic over a specific link ✨ This doc adds more sub-TLVs to advertise Adj-SIDs for L2 Bundle Members 🦋

Heads up: the new advertisements here are meant for entities outside IS-IS. The following things are intentionally not defined here and are out of scope:

  • What link attributes will be advertised. That's decided by what the external entities need.
  • A minimum or default set of link attributes.
  • How these attributes get configured.
  • How the advertisements get used.
  • What impact these advertisements might have on traffic flow in the network.
  • How the advertisements get passed to external entities.

2. Requirements Language 💜

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document mean what BCP 14 [RFC2119] [RFC8174] says they mean, but only when they're in ALL CAPS, just like shown here 🙈 Lowercase versions are just regular words, no cap 🫶

3. L2 Bundle Member Attributes TLV 🎀

okay this is the main event 💖 A new TLV is introduced to advertise L2 Bundle Member attributes. A lot of the info is the same as, and uses the same sub-TLVs as, Extended IS Neighbor advertisements (TLVs 22 and 222). But the new TLV is its own thing, so changes to L2 Bundle Member link attributes don't trigger unnecessary work in the [ISO10589] Decision Process. Iconic behavior, honestly 👑

Seeing this info means the identified link is a member of the L2 Bundle tied to the identified Parent L3 Neighbor, and that the member link is operationally up 🌈 So, advertisements MUST be withdrawn if the link goes operationally down or stops being a member of the identified L2 Bundle 🚨

This new TLV uses the sub-TLV space already defined for TLVs 22, 23, 141, 222, and 223 ✨ Here's the layout:

      L2 Bundle Member Attributes

      Type: 25

      Length: Number of octets to follow

      Parent L3 Neighbor Descriptor

         L3 Neighbor System ID + pseudonode ID (7 octets)

         Flags:  1-octet field of the following flags:

             0 1 2 3 4 5 6 7
            +-+-+-+-+-+-+-+-+
            |P|             |
            +-+-+-+-+-+-+-+-+

            where:

            P-Flag:  When set to 1, one of the sub-TLVs described in
                     Section 3.1 immediately follows the flags field.
                     If the P-Flag is set to 0, then none of the sub-
                     TLVs described in Section 3.1 are present.

            Other bits:  MUST be zero when originated and ignored when
                     received.

      One or more L2 Bundle Attribute Descriptors (as defined below).

         Length of L2 Bundle Attribute Descriptor (1 octet)

            NOTE: This includes all fields described below.

         Number of L2 Bundle Member Descriptors (1 octet)

         L2 Bundle Member Link Local Identifiers
         (4 * Number of L2 Bundle Member Descriptors octets)

            NOTE: An L2 Bundle Member Descriptor is a Link Local
            Identifier as defined in [RFC4202].

         Sub-TLV(s)
         A sub-TLV may define an attribute common to all of the bundle
         members listed, or it may define an attribute unique to each
         bundle member.  Use of these two classes of sub-TLVs is
         described in the following sections.

      NOTE: Only one Parent L3 Neighbor Descriptor is present in a given
      TLV.  Multiple L2 Bundle Attribute Descriptors may be present in a
      single TLV.

Quick rundown of the fields 🍭 The Parent L3 Neighbor Descriptor is the L3 Neighbor System ID + pseudonode ID, 7 octets. Then there's a 1-octet Flags field. Only the top bit, P, has a job here. When the P-Flag is set to 1, one of the sub-TLVs from Section 3.1 comes right after the flags. When it's 0, none of those sub-TLVs show up 💅 The other bits MUST be zero when originated and ignored when received 💀

After that you get one or more L2 Bundle Attribute Descriptors. Each one has a 1-octet Length (which includes every field in the descriptor), a 1-octet Number of L2 Bundle Member Descriptors, and then the L2 Bundle Member Link Local Identifiers, which are 4 octets times the number of descriptors. Each member descriptor is a Link Local Identifier as defined in [RFC4202] 🧚 Sub-TLVs can be common to every bundle member listed, or unique to each one 🌸

Note that only one Parent L3 Neighbor Descriptor shows up in a TLV, but multiple L2 Bundle Attribute Descriptors can fit in a single TLV 🎀

3.1. Parallel L3 Adjacencies 🦋

When there are several L3 adjacencies to the same neighbor, you need extra info to uniquely identify each L3 Neighbor 🍓 One and only one of these three sub-TLVs gets used to do that:

  • IPv4 Interface Address (sub-TLV 6 defined in [RFC5305])
  • IPv6 Interface Address (sub-TLV 12 defined in [RFC6119])
  • Link Local/Remote Identifiers (sub-TLV 4 defined in [RFC5307])

When the P-Flag is set in the flags field of the Parent L3 Neighbor Descriptor, one and only one of the sub-TLVs above MUST be present. The chosen sub-TLV MUST come right after the flags field described in Section 3 ✨

These sub-TLVs MAY be left out if there are no parallel adjacencies to the neighbor 💖

3.2. Shared Attribute Sub-TLVs 🌈

These sub-TLVs advertise a single copy of an attribute, like link bandwidth 🍭 That attribute applies to every L2 Bundle Member in the set advertised under the preceding L2 Bundle Member Attribute Descriptor. No more than one copy of a given sub-TLV from this category can show up in the sub-TLVs under that preceding descriptor. If multiple copies of the same sub-TLV are present, all copies MUST be ignored 🚫 Bestie, that's a strict one 😭

Because of that, the set of L2 Bundle Member Descriptors you can put under a single L2 Bundle Member Attribute Descriptor is limited to bundle members that share the same set of attributes from the shared attribute sub-TLVs 🫶

All existing sub-TLVs in the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 count as shared attribute sub-TLVs, unless this document says otherwise 👑

4. Advertising L2 Bundle Member Adj-SIDs 💅

okay so [RFC8667] defines sub-TLVs to advertise Adj-SIDs for L3 adjacencies 🧚 The catch is that those sub-TLVs only support advertising one Adj-SID each 😬 Since each L2 Bundle Member will usually have its own unique Adj-SIDs in lots of deployments, it makes sense to have a new sub-TLV that encodes a whole set of Adj-SIDs in one go 🌸

So this doc introduces two new sub-TLVs for advertising Adj-SIDs for L2 Bundle Members 🦋 They look a lot like the ones for L3 adjacencies, but they're tuned so one sub-TLV can carry an Adj-SID for each bundle member 🍓

The two new sub-TLVs covered in the following sections do not fall into the category of shared attribute sub-TLVs ✨

to be continued in part 2 🎀💖

4.1. L2 Bundle Member Adjacency Segment Identifier Sub-TLV

okay bestie, this sub-TLV is how we advertise Adj-SIDs for L2 Bundle Members that hang off a parent L3 adjacency which is point-to-point 🦋✨

Here's the format:

  • Type: 41 (1 octet) 💖
  • Length: variable (1 octet) 🌸
  • Flags: a 1-octet field, and it's giving bit-level drama 💅
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|*|V|L|S|P|   |
+-+-+-+-+-+-+-+-+

where each flag is:

  • F-Flag (Address-Family Flag): if it's unset, the Adj-SID refers to an L2 Bundle Member with outgoing IPv4 encapsulation. if it's set, the Adj-SID refers to an L2 Bundle Member with outgoing IPv6 encapsulation 🌈
  • V-Flag (Value Flag): if it's set, the Adj-SID carries a value. by default, the flag is SET 🔥
  • L-Flag (Local Flag): if it's set, the value/index carried by the Adj-SID has local significance. by default, the flag is SET ✨
  • S-Flag (Set Flag): when it's set, the S-Flag tells you the Adj-SID refers to a set of L2 Bundle Members (and so it MAY be assigned to other L2 Bundle Members as well) 🧚
  • P-Flag (Persistent Flag): when it's set, the P-Flag tells you the Adj-SID is persistently allocated, which means the Adj-SID value stays consistent across router restart and/or interface flap 🦋

Other bits are the no-drama zone: they MUST be zero when originated and ignored when received 🙈

NOTE: the flags are deliberately kept congruent to the flags in the L3 ADJ-SID defined in [RFC8667]. * marks a flag used in the L3 Adj-SID sub-TLV, but one that is NOT used in this sub-TLV. these bits SHOULD be sent as 0 and MUST be ignored on receipt 💀
  • Weight: 1 octet. the value represents the weight of the Adj-SID for the purpose of load balancing. the use of the weight is defined in [RFC8402] ⭐

NOTE: flags and weight are shared by all L2 Bundle Members listed in the L2 Bundle Attribute Descriptor, so they're one squad 🫶

L2 Bundle Member Adj-SID Descriptors: there MUST be one descriptor for each of the L2 Bundle Members advertised under the preceding L2 Bundle Member Attribute Descriptor. each descriptor consists of one of the following fields 💜

SID/Index/Label: depending on the V- and L-Flags, it contains either:

  • A 3-octet local label where the 20 rightmost bits are used for encoding the label value. in this case, the V- and L-Flags MUST be set 🎀
  • A 4-octet index defining the offset in the SID/Label space advertised by this router. see [RFC8667]. in this case, the V- and L-Flags MUST be unset 🍓

4.2. L2 Bundle Member LAN Adjacency SID Sub-TLV

this sub-TLV is for advertising Adj-SIDs for L2 Bundle Members that are tied to a parent L3 adjacency which is a LAN adjacency 🌸 so picture a LAN: the Designated Intermediate System (DIS) gets elected and originates the Pseudonode-LSP (PN-LSP), which includes all neighbors of the DIS 👑

when Segment Routing is used, each router in the LAN MAY advertise the Adj-SID of each of its neighbors on the LAN. similarly, for each L2 Bundle Member, a router MAY advertise an Adj-SID to each neighbor on the LAN. it's giving group project energy 🧚✨

here's the format:

  • Type: 42 (1 octet) 💖
  • Length: variable (1 octet) 🌸
  • Neighbor System ID: 6 octets 🦋
  • Flags: a 1-octet field, same vibe as before 💅
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|*|V|L|S|P|   |
+-+-+-+-+-+-+-+-+

where each flag is:

  • F-Flag (Address-Family Flag): if it's unset, the Adj-SID refers to an L2 Bundle Member with outgoing IPv4 encapsulation. if it's set, the Adj-SID refers to an L2 Bundle Member with outgoing IPv6 encapsulation 🌈
  • V-Flag (Value Flag): if it's set, the Adj-SID carries a value. by default, the flag is SET 🔥
  • L-Flag (Local Flag): if it's set, the value/index carried by the Adj-SID has local significance. by default, the flag is SET ✨
  • S-Flag (Set Flag): when it's set, the S-Flag tells you the Adj-SID refers to a set of L2 Bundle Members (and so it MAY be assigned to other L2 Bundle Members as well) 🧚
  • P-Flag (Persistent Flag): when it's set, the P-Flag tells you the Adj-SID is persistently allocated, which means the Adj-SID value stays consistent across router restart and/or interface flap 🦋

Other bits: MUST be zero when originated and ignored when received 🙈

NOTE: the flags are deliberately kept congruent to the flags in the L3 LAN Adjacency SID defined in [RFC8667]. * marks a flag used in the L3 Adj-SID sub-TLV, but one that is NOT used in this sub-TLV. these bits SHOULD be sent as 0 and MUST be ignored on receipt 💀
  • Weight: 1 octet. the value represents the weight of the Adj-SID for the purpose of load balancing. the use of the weight is defined in [RFC8402] ⭐

NOTE: flags and weight are shared by all L2 Bundle Members listed in the L2 Bundle Attribute Descriptor 🫶

L2 Bundle Member LAN Adjacency SID Descriptors: there MUST be one descriptor for each of the L2 Bundle Members advertised under the preceding L2 Bundle Member Attribute Descriptor. each descriptor consists of one of the following fields 💜

SID/Index/Label: depending on the V- and L-Flags, it contains either:

  • A 3-octet local label where the 20 rightmost bits are used for encoding the label value. in this case, the V- and L-Flags MUST be set 🎀
  • A 4-octet index defining the offset in the SID/Label space advertised by this router. see [RFC8667]. in this case, the V- and L-Flags MUST be unset 🍓

5. IANA Considerations 🎀

Okay, IANA time 🦋 This document adds one brand-new TLV to the IS-IS "TLV Codepoints Registry" 💅

Value: 25

Name: L2 Bundle Member Attributes

The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include sub-TLV 25, so it's giving main character glow-up 🌈 An extra column was added to show which sub-TLVs can show up in the new L2 Bundle Member Attributes TLV. The TLV 25 column uses one of these three values ✨

  • y: sub-TLV may appear in TLV 25 but MUST NOT be shared by multiple L2 Bundle Members 🙈
  • y(s): sub-TLV may appear in TLV 25 and MAY be shared by multiple L2 Bundle Members 💜
  • n: sub-TLV MUST NOT appear in TLV 25 💀

Here's the table with the settings for every sub-TLV defined so far, for use in the new TLV 25 🍓

+-------+-------------------------------------------+--------+
| Value | Description                               | TLV 25 |
+=======+===========================================+========+
| 3     | Administrative group (color)              | y(s)   |
+-------+-------------------------------------------+--------+
| 4     | Link Local/Remote Identifiers             | y(s)   |
+-------+-------------------------------------------+--------+
| 6     | IPv4 interface address                    | y(s)   |
+-------+-------------------------------------------+--------+
| 8     | IPv4 neighbor address                     | y(s)   |
+-------+-------------------------------------------+--------+
| 9     | Maximum link bandwidth                    | y(s)   |
+-------+-------------------------------------------+--------+
| 10    | Maximum reservable link bandwidth         | y(s)   |
+-------+-------------------------------------------+--------+
| 11    | Unreserved bandwidth                      | y(s)   |
+-------+-------------------------------------------+--------+
| 12    | IPv6 Interface Address                    | y(s)   |
+-------+-------------------------------------------+--------+
| 13    | IPv6 Neighbor Address                     | y(s)   |
+-------+-------------------------------------------+--------+
| 14    | Extended Administrative Group             | y(s)   |
+-------+-------------------------------------------+--------+
| 18    | TE Default metric                         | y(s)   |
+-------+-------------------------------------------+--------+
| 19    | Link-attributes                           | y(s)   |
+-------+-------------------------------------------+--------+
| 20    | Link Protection Type                      | y(s)   |
+-------+-------------------------------------------+--------+
| 21    | Interface Switching Capability Descriptor | y(s)   |
+-------+-------------------------------------------+--------+
| 22    | Bandwidth Constraints                     | y(s)   |
+-------+-------------------------------------------+--------+
| 23    | Unconstrained TE LSP Count (sub-)TLV      | y(s)   |
+-------+-------------------------------------------+--------+
| 24    | remote AS number                          | n      |
+-------+-------------------------------------------+--------+
| 25    | IPv4 remote ASBR Identifier               | n      |
+-------+-------------------------------------------+--------+
| 26    | IPv6 remote ASBR Identifier               | n      |
+-------+-------------------------------------------+--------+
| 27    | Interface Adjustment Capability           | y(s)   |
|       | Descriptor (IACD)                         |        |
+-------+-------------------------------------------+--------+
| 28    | MTU                                       | n      |
+-------+-------------------------------------------+--------+
| 29    | SPB-Metric                                | y(s)   |
+-------+-------------------------------------------+--------+
| 30    | SPB-A-OALG                                | y(s)   |
+-------+-------------------------------------------+--------+
| 33    | Unidirectional Link Delay                 | y      |
+-------+-------------------------------------------+--------+
| 34    | Min/Max Unidirectional Link Delay         | y      |
+-------+-------------------------------------------+--------+
| 35    | Unidirectional Delay Variation            | y      |
+-------+-------------------------------------------+--------+
| 36    | Unidirectional Link Loss                  | y      |
+-------+-------------------------------------------+--------+
| 37    | Unidirectional Residual Bandwidth         | y      |
+-------+-------------------------------------------+--------+
| 38    | Unidirectional Available Bandwidth        | y      |
+-------+-------------------------------------------+--------+
| 39    | Unidirectional Utilized Bandwidth         | y      |
+-------+-------------------------------------------+--------+
| 40    | RTM Capability                            | n      |
+-------+-------------------------------------------+--------+

Table 1 ✨

This document also adds the following new sub-TLVs to the registry above, and it's giving organized 📋

+------+--------------------------+----+----+----+-----+-----+-----+
| Type | Description              | 22 | 23 | 25 | 141 | 222 | 223 |
+======+==========================+====+====+====+=====+=====+=====+
|  41  | L2 Bundle Member Adj-SID | n  | n  | y  |  n  |  n  |  n  |
+------+--------------------------+----+----+----+-----+-----+-----+
|  42  | L2 Bundle Member LAN     | n  | n  | y  |  n  |  n  |  n  |
|      | Adj-SID                  |    |    |    |     |     |     |
+------+--------------------------+----+----+----+-----+-----+-----+

Table 2 💜

6. Security Considerations 🔥

Okay, security is serious bestie, so let's get into it 🙈 The IS-IS protocol has supported the advertisement of link attribute information, including link identifiers, for many years ⭐ The advertisements defined in this document are identical to existing advertisements defined in [RFC4202], [RFC5305], [RFC8570], and [RFC8667], but they're associated with L2 links that are part of a bundle interface where the IS-IS protocol runs 🫶 So there are no new security issues introduced by the extensions in this document ✅

As always, if the protocol is used in an environment where unauthorized access to the physical links on which IS-IS Protocol Data Units (PDUs) are sent occurs, then attacks are possible 😭 The use of authentication as defined in [RFC5304] and [RFC5310] is recommended to prevent such attacks. Please don't skip this one, it's giving "lock your door" energy 🔐

7. References 📚

7.1. Normative References

7.2. Informative References

Appendix A. Example Encoding ✨

okay bestie, this is the worked example and it's so satisfying 🎀 We've got two parallel adjacencies to the same neighbor, system-id 1234.1234.1234.00, and each one has its own L2 bundle with its own set of attributes 🦋

L3 Adjacency #1 has the local link address 192.0.2.1 (L3 IPv4 local link address: 192.0.2.1) and four bundle members:

        +-----+---------------+-----------+----------------+
        | Num | Link Local ID | Bandwidth | Adj-SID/Weight |
        +=====+===============+===========+================+
        |  1  |   0x11111111  |     1G    |   0x11111/1    |
        +-----+---------------+-----------+----------------+
        |  2  |   0x11112222  |     1G    |   0x11112/1    |
        +-----+---------------+-----------+----------------+
        |  3  |   0x11113333  |    10G    |   0x11113/1    |
        +-----+---------------+-----------+----------------+
        |  4  |   0x11114444  |    10G    |   0x11114/1    |
        +-----+---------------+-----------+----------------+

Table 3

L3 Adjacency #2 is at 192.0.2.2 (L3 IPv4 local link address: 192.0.2.2) and has three bundle members:

        +-----+---------------+-----------+----------------+
        | Num | Link Local ID | Bandwidth | Adj-SID/Weight |
        +=====+===============+===========+================+
        |  1  |   0x22221111  |    10G    |    22221/1     |
        +-----+---------------+-----------+----------------+
        |  2  |   0x22222222  |    10G    |    22222/1     |
        +-----+---------------+-----------+----------------+
        |  3  |   0x22223333  |    10G    |    22223/1     |
        +-----+---------------+-----------+----------------+

Table 4

So that's two TLVs, one for each L3 adjacency 💖 Here's how they come together.

TLV for Adjacency #1:

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type(25)     | Length(64)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parent L3 Neighbor Descriptor 🌸

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor System-ID octets 1-4: 1234.1234                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System-ID octets 5-6: 1234    | P-node: 00    |1|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4 Interface Address Sub-TLV 🦋

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type(6)      | Length(4)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address: 192.0.2.1                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L2 Bundle Attribute Descriptors (for members #1 and #2) ✨

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Len:9+6+10 = 25| # Desc: 2     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier Bundle Member #1: 0x11111111            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier Bundle Member #2: 0x11112222            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Maximum Link Bandwidth Sub-TLV (1G/8) 🔥

 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(9)       | Length(4)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Value: 1G/8                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L2 Bundle Member Adj-SID Sub-TLV (for members #1 and #2) 👑

 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(41)     | Length(8)     |0|0|1|1|0|0|0|0| Weight: 1     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Label Bundle Member #1: 0x11111         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Label Bundle Member #2: 0x11112         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L2 Bundle Attribute Descriptors (for members #3 and #4) 💅

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Len:9+6+10 = 25| # Desc: 2     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier Bundle Member #3: 0x11113333            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier Bundle Member #4: 0x11114444            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Maximum Link Bandwidth Sub-TLV (10G/8) 🌈

 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(9)       | Length(4)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Value: 10G/8                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L2 Bundle Member Adj-SID Sub-TLV (for members #3 and #4) 🧚

 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(41)     | Length(8)     |0|0|1|1|0|0|0|0| Weight: 1     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Label Bundle Member #3: 0x11113         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Label Bundle Member #4: 0x11114         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLV for Adjacency #2:

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type(25)     | Length(46)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parent L3 Neighbor Descriptor 🍓

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor System-ID octets 1-4: 1234.1234                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System-ID octets 5-6: 1234    | P-node: 00    |1|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4 Interface Address Sub-TLV 💜

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Type(6)      | Length(4)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address: 192.0.2.2                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L2 Bundle Attribute Descriptors (for all three members) ⭐

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Len:13+6+13=32 | # Desc: 3     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier Bundle Member #1: 0x22221111            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier Bundle Member #2: 0x22222222            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier Bundle Member #3: 0x22223333            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Maximum Link Bandwidth Sub-TLV (10G/8) 🎀

 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(9)       | Length(4)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Value: 10G/8                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

L2 Bundle Member Adj-SID Sub-TLV (for all three members) 🦋

 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(41)     | Length(11)    |0|0|1|1|0|0|0|0| Weight: 1     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Label Bundle Member #1: 0x22221         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Label Bundle Member #2: 0x22222         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Label Bundle Member #3: 0x22223         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Acknowledgements

The authors would like to thank Jon Mitchell for his careful review 🫶

Contributors

The following people gave a substantial contribution to the content of this document and should be considered coauthors 💖

Stefano Previdi
Huawei Technologies
Italy

Email: stefano@previdi.net

Authors' Addresses

Here are the people who wrote this one, with their contact details 💅

Les Ginsberg (editor)
Cisco Systems, Inc.

Email: ginsberg@cisco.com


Ahmed Bashandy
Unaffiliated
United States of America

Email: abashandy.ietf@gmail.com


Clarence Filsfils
Cisco Systems, Inc.

Email: cf@cisco.com


Mohan Nanduri
Oracle

Email: mohan.nanduri@oracle.com


Ebben Aries
Arrcus Inc.
2077 Gateway Place, Suite #400
San Jose, CA 95119
United States of America

Email: exa@arrcus.com
📦 where this page comes from