RFC 7308

Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)

📅 published July 2014, from ietf

RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) 🦋

Okay bestie, this one is by E. Osborne and it's an IETF doc from July 2014, labelled Standards Track 💅. It's RFC 7308, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Abstract

MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).

This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32 🌈

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). If you want more on Internet Standards, check out Section 2 of RFC 5741 🧚

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc7308.

Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 💖

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
2.  Extended Administrative Groups Sub-TLV  . . . . . . . . . . .   3
  2.1.  Packet Format . . . . . . . . . . . . . . . . . . . . . .   4
  2.2.  Admin Group Numbering . . . . . . . . . . . . . . . . . .   4
  2.3.  Backward Compatibility  . . . . . . . . . . . . . . . . .   4
    2.3.1.  AG and EAG Coexistence  . . . . . . . . . . . . . . .   4
    2.3.2.  Desire for Unadvertised EAG Bits  . . . . . . . . . .   5
3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
  6.2.  Informative References  . . . . . . . . . . . . . . . . .   7

1. Introduction ✨

Do we need more than 32 bits? 🤔

The IGP extensions that support MPLS-TE (RFCs 3630 [RFC3630] and 5305 [RFC5305]) define a link TLV called Administrative Group (AG), and it's capped at 32 AGs per link. The idea of Administrative Groups comes from Section 6.2 of RFC 2702 [RFC2702], which calls them Resource Classes. RFCs 3630 [RFC3630] and 5305 [RFC5305] explain how the TLV works and use the term Administrative Groups (sometimes shortened to AGs here too, as this document does) 💜

Networks have been growing, and MPLS-TE has been growing right along with them 📈 Administrative Groups are advertised as fixed-length 32-bit bitmasks, and that is seriously constraining, because you can run out of values really fast 😭 One use case is #5 in Section 6.2 of RFC 2702 [RFC2702], which is using AGs to constrain traffic to specific topological regions of the network. A big network might have way more than 32 geographic regions. One operator builds their network along these lines, using AGs to flag network regions all the way down to the metro scale, e.g., Seattle, San Francisco, Dallas, Chicago, St. Louis, etc. MPLS-TE tunnels then get affinities that include or exclude specific metro regions in their path calculation. Each metro region gets its own bit in the AG bitmask, which means 32 bits can only (cleanly) represent 32 metro areas. It's pretty obvious that 32 might not be enough even for a US-based network, never mind a worldwide one 🌍

Some color reuse might be possible, meaning bit 0x8 could mean 'Seattle' or 'Prague' or 'Singapore' depending on the geography where it's used. In practice, though, coordinating that reuse is fraught with peril, and the reuse ends up being the thing that limits MPLS-TE deployment 💀 With this example, you can't build a Label Switched Path (LSP) that avoids Seattle while including Prague, because they're the same AG value. Not me getting stuck like that 🙈

This document provides Extended Administrative Groups (EAGs). The number of EAGs has no fixed limit. It's only constrained by protocol-specific restrictions, such as Link State Advertisement (LSA) or MTU size. An operator may one day need to go beyond those protocol-specific restrictions, but allowing an arbitrary number of EAGs should easily give the operator hundreds or thousands of bit values, so the number of AGs stops being a blocker for network growth 👑

EAG's intended use case is within a single domain. Because of that, this document doesn't support signaling an EAG at all. It has no analog to the SESSION_ATTRIBUTE of C-Type 1 defined in [RFC3209], and no analog to the LSP Attributes (LSPA) object of the Path Computation Element Communication Protocol (PCEP), defined in [RFC5440]. Since this spec gives no way to signal an LSP's path requirements in reference to the EAG, those constraints can only be applied at the ingress 🦋

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]. These are the official capital-letter words that carry the strict meanings, so watch for them 👀

2. Extended Administrative Groups Sub-TLV 🌸

This document defines the Extended Administrative Group (EAG) sub-TLV for both OSPF [RFC3630] and IS-IS [RFC5305]. The EAG sub-TLV gets used alongside the Administrative Groups when an operator wants to make more than 32 colors available for advertisement in a network. The EAG sub-TLV is optional. How EAG and AG TLVs coexist is covered in Section 2.3.1 of this document 🫶

This document uses the term 'colors' as a shorthand for particular bits within an AG or EAG. The examples in this document use 'red' for the least significant bit in the AG (red == 0x1), and 'blue' for the second bit (blue == 0x2). When we say a link has a given color, or that the specified color is set on the link, we mean the corresponding bit or bits in the link's AG are set to 1 🌈

2.1. Packet Format

The format of the Extended Administrative Groups sub-TLV is the same for both OSPF and IS-IS:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Extended Admin Group                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        ...........                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Extended Admin Group                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Type of the sub-TLV is 26 for OSPF and 14 for IS-IS. The Length is the size of the Extended Admin Group (EAG) value in bytes. The EAG may be of any non-zero length, but it MUST be a multiple of 4 bytes. The only limits on EAG size are the ones imposed by protocol-specific or media-specific constraints (e.g., max packet length) 💖

2.2. Admin Group Numbering

By convention, the existing Administrative Group sub-TLVs are numbered 0 (least significant bit) through 31 (most significant bit). The EAG values are a superset of AG. In other words, bits 0-31 in the EAG have the same meaning and MUST have the same values as an AG flooded for the same link. If an EAG's length is more than 4 bytes, numbering for those additional bytes picks up right where the previous byte left off. For example, the least significant bit in the fifth byte of an 8-byte EAG is referred to as bit 32 🔢

2.3. Backward Compatibility

There are two questions to think about for backward compatibility with existing AG implementations. The first is how AG and EAG coexist. The second is what happens if a node has matching criteria for unadvertised EAG bits 🤷‍♀️

2.3.1. AG and EAG Coexistence

If a node advertises EAG, it MAY also advertise AG.

If a node advertises both AG and EAG, then the first 32 bits of the EAG MUST be identical to the advertised AG.

If both an AG and an EAG are present, a receiving node MUST use the AG as the first 32 bits (0-31) of administrative color, and use the EAG for bits 32 and higher, if present.

A receiving node that notices the AG differs from the first 32 bits of the EAG SHOULD report this mismatch to the operator.

This process lets nodes that don't support EAG still get some link color info from the network, while also allowing for an eventual migration away from AG 🌷

2.3.2. Desire for Unadvertised EAG Bits

The existing AG sub-TLV is optional, so a node may be configured with a preference to include red or exclude blue, and then be faced with a link that isn't advertising a value for either blue or red. What's an implementation supposed to do here? It shouldn't assume that red is set, but it's also arguably incorrect to assume that red is NOT set, because a bit has to exist before it can be set to 0 🤯

Practically speaking, this hasn't been a problem for deployments, since many implementations always advertise the AG bits, often with a default value of 0x00000000. However, this issue may be a bigger concern once EAGs get added to the network. EAGs may exist on some nodes but not others, and the EAG length may be longer for some links than for others 😬

To allow for maximum interoperability, an implementation SHOULD treat desired but unadvertised EAG bits as if they were set to 0. Consider the case where a node only wants to use links where the 127th bit of an EAG is set to 1. If a link is only advertising 64 EAG bits, the setting of the 127th EAG bit isn't known. That is, it's neither explicitly 0 nor 1. The node that wants the 127th EAG bit to be 1 won't use this link when it implements the recommended behavior, since the assumption is that the unadvertised 127th bit is set to 0 🙅‍♀️

That said, each implementation makes its own choices based on necessary constraints, and there might be reasons to provide other strategies for handling this case. A strategy that deviates from the behavior this document recommends SHOULD be configurable so it can use the recommended behavior, in order to provide maximum interoperability 🎀

3. Security Considerations 🚨

This extension adds no new security considerations. Plot twist, but it's true 💅

4. IANA Considerations ✨

okay so bestie, this one is all about paperwork 📋💅 but it's important paperwork! This document registers a sub-TLV allocation in both OSPF and IS-IS, which means the number gets written down in two official registries so everyone's on the same page 🫶

For OSPF, the subregistry is the "Types for sub-TLVs of TE Link TLV (Value 2)" in the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry 🦋

For IS-IS, it's the "Sub-TLVs for TLV 22, 141, and 222" subregistry in the "IS-IS TLV Codepoints" registry 🌸 The value should be marked 'y' for Sub-TLVs 22, 141 and 222, and this is identical to the allocation for the Administrative Group sub-TLV (value 3 in the same subregistry). ngl that's giving consistency 💜

The assigned value from the OSPF registry is 26, and the assigned value from the IS-IS registry is 14. The sub-TLV is called "Extended Administrative Group" ✨👑

5. Acknowledgements 🫶

Thanks to Santiago Alvarez, Rohit Gupta, Liem Nguyen, Tarek Saad, Robert Sawaya, Andy Malis, Les Ginsberg and Adrian Farrel for their review and comments. The squad showed up for this one, periodt 🎀

6. References 📚

6.1. Normative References 🔥

  • [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.
  • [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
  • [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
  • [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.

6.2. Informative References 🌈

  • [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.

Author's Address 🧚

Eric Osborne

EMail: eric.osborne@notcom.com

📦 where this page comes from