RFC 8092

BGP Large Communities Attribute

📅 published February 2017, from ietf

RFC 8092: BGP Large Communities Attribute 🦋

Okay bestie, this one is from February 2017 and it's from the IETF (the crew that writes the Internet's rulebook 📖). The authors are J. Heitz, Ed. (Cisco), J. Snijders, Ed. (NTT), K. Patel (Arrcus), I. Bagdonas (Equinix), and N. Hilliard (INEX). It's a Standards Track document with ISSN 2070-1721, so it's an actual spec people build on, not just a note. The header doesn't list any Obsoletes or Updates, so it doesn't replace or change an earlier RFC. Iconic 💅

Abstract

Okay so the abstract is the TL;DR 🌸 It describes the BGP Large Communities attribute, which is an extension to BGP-4. It gives you a way to tag routes with opaque info in separate namespaces so routing management is easier. It works with all Autonomous System Numbers (ASNs), including four-octet ones. Main character energy 👑

Status of This Memo

This is an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🎀 If you want more on Internet Standards, check Section 2 of RFC 7841. For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8092.

Copyright (c) 2017 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 were in effect on the date of publication. Please actually read these, bestie, because they explain 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 with no warranty, as the Simplified BSD License describes 🫶

Table of Contents

   1. Introduction ....................................................2
   2. Requirements Language ...........................................3
   3. BGP Large Communities Attribute .................................3
   4. Aggregation .....................................................4
   5. Canonical Representation ........................................4
   6. Error Handling ..................................................5
   7. Security Considerations .........................................5
   8. IANA Considerations .............................................6
   9. References ......................................................6
      9.1. Normative References .......................................6
      9.2. Informative References .....................................6
   Acknowledgments ....................................................7
   Contributors .......................................................7
   Authors' Addresses .................................................8

1. Introduction 🌸

Okay so BGP [RFC4271] implementations usually come with a routing policy language for controlling how routing info gets distributed. Network operators slap BGP communities on routes to attach properties to them. Those properties can be things like where the route came from, or a routing policy action that should happen or already did happen 💖 The tag applies to every route inside a BGP Update Message that includes the Communities Attribute. And since BGP communities are optional transitive BGP attributes, other Autonomous Systems (ASes) on the Internet can act on them or use them in their own routing policies. The way that works is so iconic 🍓

A BGP Communities attribute is variable-length and holds one or more four-octet values, and each value specifies a community [RFC1997]. The common practice is to split that one 32-bit value into two 16-bit halves. The most significant word is read as an Autonomous System Number (ASN), and the least significant word is a locally defined value. The operator of the AS named in the most significant word is the one who decides what that value means 🦋

Here's the catch, though. Since four-octet ASNs showed up [RFC6793], the BGP Communities attribute can't handle that encoding anymore, because a two-octet word just can't fit a four-octet ASN 💀 The BGP Extended Communities attribute [RFC4360] doesn't work either. Its six-octet length rules out the usual move of putting four-octet ASNs in both the Global Administrator and Local Administrator sub-fields 🙈

So this document fixes that. It defines the BGP Large Communities attribute as an unordered set of one or more twelve-octet values. Each one has a four-octet Global Administrator field plus two four-octet operator-defined fields, and each of those can be used to mark properties or actions that matter to whichever AS's operator assigned the value ✨

2. Requirements Language 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way [RFC2119] says. That's the official BCP 14 vibe check, so take them seriously 💅

3. BGP Large Communities Attribute 🧚

This document defines the BGP Large Communities attribute as an optional transitive path attribute with variable length. Every route that has the BGP Large Communities attribute belongs to the communities listed in that attribute 💜

Each BGP Large Community value is a 12-octet quantity, laid out like this:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Global Administrator                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Data Part 1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Data Part 2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's what each piece is:

  • Global Administrator: A four-octet namespace identifier.
  • Local Data Part 1: A four-octet operator-defined value.
  • Local Data Part 2: A four-octet operator-defined value.

The Global Administrator field exists so different ASes can define their BGP Large Communities without stepping on each other 🌈 This field SHOULD be an ASN, and when it is, the Local Data Parts get interpreted however the owner of that ASN defines them. Using Reserved ASNs is NOT RECOMMENDED: that's 0 [RFC7607], plus 65535 and 4294967295 [RFC7300].

The order of the twelve-octet Large Community values inside a Large Communities attribute means nothing. A BGP speaker can send them in any order 🦋

Duplicate BGP Large Community values MUST NOT be transmitted. A receiving speaker MUST silently remove redundant BGP Large Community values from a BGP Large Community attribute 🧹

4. Aggregation 🌷

If a range of routes gets aggregated, the resulting aggregate should have a BGP Large Communities attribute that contains every BGP Large Communities attribute from all of the aggregated routes ✨

5. Canonical Representation 💎

The canonical way to write BGP Large Communities is three separate unsigned integers in decimal notation, in this order: Global Administrator, Local Data 1, Local Data 2. Numbers MUST NOT contain leading zeros, and a zero value MUST be written as a single zero. Each number is separated from the next by a single colon. For example: 64496:4294967295:2, 64496:0:0 🎀

BGP Large Communities SHOULD be represented in the canonical representation. Literally just use the canonical form, bestie 🫶

6. Error Handling 🚨

Here's how BGP Large Communities handles errors:

  • A BGP Large Communities attribute SHALL be considered malformed if the length of the BGP Large Communities Attribute value, in octets, is not a non-zero multiple of 12.
  • A BGP Large Communities attribute SHALL NOT be considered malformed due to presence of duplicate Large Community values.
  • A BGP UPDATE message with a malformed BGP Large Communities attribute SHALL be handled using the approach of "treat-as-withdraw" as described in Section 2 of [RFC7606] 😭

The BGP Large Communities Global Administrator field can hold any value, and a BGP Large Communities attribute MUST NOT be considered malformed just because the Global Administrator field has an unallocated, unassigned, or reserved ASN in it 💅

Part 1 of 2. Part 2 picks up at Section 7 with Security Considerations and wraps up the References 🦋

9.2. Informative References 📚

These are the extra reads that help you get the bigger picture, bestie. Not required, but so good for context 🧚

[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.

[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.

[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.

[RFC7300] Haas, J. and J. Mitchell, "Reservation of Last Autonomous System (AS) Numbers", BCP 6, RFC 7300, DOI 10.17487/RFC7300, July 2014, <http://www.rfc-editor.org/info/rfc7300>.

[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <http://www.rfc-editor.org/info/rfc7454>.

[RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 Processing", RFC 7607, DOI 10.17487/RFC7607, August 2015, <http://www.rfc-editor.org/info/rfc7607>.

Acknowledgments 🫶

The authors would like to thank Ruediger Volk, Russ White, Acee Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas, Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand Duvivier, Barry O'Donovan, Grzegorz Janoszka, Linda Dunbar, Marco Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari, Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer, Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow, Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann, Geoff Huston, Mach Chen, and Alvaro Retana for their support, insightful review, and comments. 💖

Contributors 🌸

The following people contributed significantly to the content of the document:

John Heasley
NTT Communications
Email: heas@shrubbery.net
Adam Simpson
Nokia
Email: adam.1.simpson@nokia.com

Authors' Addresses 🦋

Jakob Heitz (editor)
Cisco
170 West Tasman Drive
San Jose, CA  95054
United States of America

Email: jheitz@cisco.com
Job Snijders (editor)
NTT Communications
Theodorus Majofskistraat 100
Amsterdam  1065 SZ
The Netherlands

Email: job@ntt.net
Keyur Patel
Arrcus, Inc.

Email: keyur@arrcus.com
Ignas Bagdonas
Equinix
80 Cheapside
London  EC2V 6EE
United Kingdom

Email: ibagdona.ietf@gmail.com
Nick Hilliard
INEX
4027 Kingswood Road
Dublin  24
Ireland

Email: nick@inex.ie
📦 where this page comes from