RFC 3065

Autonomous System Confederations for BGP

📅 published February 2001, from ietf

Autonomous System Confederations for BGP 💖

okay bestie, this is RFC 3065 🎀 It's a Standards Track doc from February 2001, and the authors are P. Traina (Juniper Networks, Inc.), D. McPherson (Amber Networks, Inc.), and J. Scudder (Cisco Systems, Inc.). It's from the Network Working Group, and it obsoletes RFC 1965. No updates are listed. ✨

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 current 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, so go wild 🌈

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract 🦋

okay so BGP (the Border Gateway Protocol) is an inter-autonomous system routing protocol, and it's built for TCP/IP networks 🌸 the big drama is that BGP requires all BGP speakers inside a single autonomous system (AS) to be fully meshed 😭 that's a serious scaling problem, and it's been well documented in a bunch of proposals. 💀

this doc describes a BGP extension that can make a confederation of autonomous systems. the confederation shows up as a single AS to BGP peers outside the confederation, so the "full mesh" requirement is gone ✨ the goal is to help with policy administration and cut down on the management complexity of running a big autonomous system. iconic, honestly 👑

1. Specification of Requirements 🎀

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

2. Introduction 💖

so, as BGP is currently defined, all BGP speakers inside a single AS have to be fully meshed 🙈 for n BGP speakers in an AS, you end up needing n*(n-1)/2 unique IBGP sessions. literally, that does not scale when there are tons of IBGP speakers in the AS, which is super common in networks today 😭

this scaling problem is well documented, and people have made a bunch of proposals to fix it [3,5]. this doc is another option for getting rid of the need for a "full mesh." it's called "Autonomous System Confederations for BGP," or just "BGP Confederations" 🦋 it's also worth saying that BGP Confederations MAY provide improvements in routing policy control. ✨

this doc is a revision of RFC 1965 [4]. it has editorial changes, clarifications, and corrections based on what people learned from deploying BGP Confederations 🌈 those revisions are summarized in Appendix A. 🫶

3. Terms and Definitions 🍓

AS Confederation A collection of autonomous systems advertised as a single AS number to BGP speakers that are not members of the confederation. 💜

AS Confederation Identifier An externally visible autonomous system number that identifies the confederation as a whole. 🧚

Member-AS An autonomous system that is contained in a given AS confederation. 🌸

Member-AS Number An autonomous system number that's visible only internally to a BGP confederation. 🙈

4. Discussion 🌈

it can be useful to split autonomous systems with a very large number of BGP speakers into smaller domains. the reason is controlling routing policy using the information in the BGP AS_PATH attribute 💅 for example, you might choose to treat all BGP speakers in one geographic region as a single entity. 🗺️

besides the routing policy perks, if you don't use techniques like the ones here or in [5], [1] requires BGP speakers in the same autonomous system to set up a full mesh of TCP connections among all speakers, just to exchange exterior routing information 😭 in an AS, the number of intra-domain connections each border router has to maintain can get seriously significant. 💀

splitting up a large autonomous system cuts the total number of intra-domain BGP connections by a lot, because the connectivity requirements simplify to the model already used for inter-domain connections ✨ iconic.

unfortunately, splitting an autonomous system can make routing policy based on AS_PATH information more complicated for everyone on the Internet 🥺 and it also makes the maintenance overhead for coordinating external peering go up whenever the internal topology of that collection of autonomous systems changes.

finally, dividing a large AS can unnecessarily make the sequence portions of the AS_PATH attribute longer. a bunch of common BGP implementations can use the number of "AS hops" needed to reach a destination as part of path selection criteria 👀 this isn't the best way to figure out route preference, but since there's not much other in-band information, it gives a reasonable default that's widely used across the Internet. so splitting an AS into separate systems might hurt optimal routing of packets through the Internet. yikes 😬

BUT, there's usually no need to expose the internal topology of the divided autonomous system. that means you can treat a collection of autonomous systems under common administration as a single entity, or autonomous system, when you look at it from outside the confederation itself 🦋 main character energy.

5. AS_CONFED Segment Type Extension 🎀

okay so currently BGP says the AS_PATH attribute is a well-known mandatory attribute made up of a sequence of AS path segments. each AS path segment is a triple: <path segment type, path segment length, path segment value> 💖

in [1], the path segment type is a 1-octet field, and two values are defined:

Value     Segment Type

   1       AS_SET: unordered set of ASs a route in the
           UPDATE message has traversed

   2       AS_SEQUENCE: ordered set of ASs a route in
           the UPDATE message has traversed

this doc reserves two more segment types:

   3       AS_CONFED_SEQUENCE: ordered set of Member AS Numbers
           in the local confederation that the UPDATE message has
           traversed

   4       AS_CONFED_SET: unordered set of Member AS Numbers in
           the local confederation that the UPDATE message has
           traversed

6. Operation 🧚

a member of a BGP confederation uses its AS Confederation ID in all transactions with peers that are not members of its confederation 💅 this confederation identifier counts as the "externally visible" AS number, and this number is used in OPEN messages and advertised in the AS_PATH attribute. ✨

a member of a BGP confederation uses its Member AS Number in all transactions with peers that are members of the same confederation as that router 🫶

a BGP speaker that receives an AS_PATH attribute containing an autonomous system matching its own confederation shall treat the path the same way it would if it had received a path containing its own AS number. 🌸

a BGP speaker that receives an AS_PATH attribute containing an AS_CONFED_SEQUENCE or AS_CONFED_SET which contains its own Member AS Number shall treat the path the same way it would if it had received a path containing its own AS number. 🔥

6.1. AS_PATH Modification Rules 💖

Section 5.1.2 of [1] is replaced with the following text:

When a BGP speaker propagates a route it learned from another BGP speaker's UPDATE message, it shall modify the route's AS_PATH attribute based on where the BGP speaker that the route will be sent to is located 🎀

a) when a given BGP speaker advertises the route to another BGP speaker located in its own autonomous system, the advertising speaker shall not modify the AS_PATH attribute associated with the route. 🧚

b) when a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system that is a member of the local autonomous system confederation, then the advertising speaker shall update the AS_PATH attribute like this:

  • 1) if the first path segment of the AS_PATH is of type AS_CONFED_SEQUENCE, the local system shall prepend its own AS number as the last element of the sequence (put it in the leftmost position). 🦋
  • 2) if the first path segment of the AS_PATH is not of type AS_CONFED_SEQUENCE, the local system shall prepend a new path segment of type AS_CONFED_SEQUENCE to the AS_PATH, including its own confederation identifier in that segment. 🌈

c) when a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system that is not a member of the current autonomous system confederation, the advertising speaker shall update the AS_PATH attribute like this:

  • 1) if the first path segment of the AS_PATH is of type AS_CONFED_SEQUENCE, that segment and any immediately following segments of the type AS_CONFED_SET or AS_CONFED_SEQUENCE are removed from the AS_PATH attribute, leaving the sanitized AS_PATH attribute to be operated on by steps 2 or 3. 🧹
  • 2) if the first path segment of the remaining AS_PATH is of type AS_SEQUENCE, the local system shall prepend its own confederation ID as the last element of the sequence (put it in the leftmost position). 💅
  • 3) if there are no path segments following the removal of the first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the first path segment of the remaining AS_PATH is of type AS_SET, the local system shall prepend a new path segment of type AS_SEQUENCE to the AS_PATH, including its own confederation ID in that segment. 🫶

when a BGP speaker originates a route, these rules apply:

a) the originating speaker shall include an empty AS_PATH attribute in all UPDATE messages sent to BGP speakers located in its own Member AS Number. (an empty AS_PATH attribute is one whose length field contains the value zero). 🌸

b) the originating speaker shall include its own Member AS Number in an AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all UPDATE messages sent to BGP speakers located in neighboring Member-ASes that are members of the local confederation (i.e., the originating speaker's Member AS Number will be the only entry in the AS_PATH attribute). 💖

c) the originating speaker shall include its own autonomous system in an AS_SEQUENCE segment of the AS_PATH attribute of all UPDATE messages sent to BGP speakers located in neighboring autonomous systems that are not members of the local confederation. (in this case, the autonomous system number of the originating speaker's member confederation will be the only entry in the AS_PATH attribute). 🎀

7. Common Administration Issues 🏡

okay so it's totally reasonable for member ASs inside a confederation to share one administration and the same IGP info for the whole confederation 🫶

It shall be legal for a BGP speaker to advertise an unchanged NEXT_HOP and MULTI_EXIT_DISCRIMINATOR (MED) attribute to peers in a neighboring AS within the same confederation. ✨ On top of that, the old rule that stopped you from sending LOCAL_PREFERENCE to peers in a neighboring AS within the same confederation is gone 🙌 Path selection for info learned from members inside a confederation MUST follow the same rules used for info learned from members inside the same autonomous system, as specified in [1]. no cap, it's giving consistency 💅

8. Compatability Considerations 🎀

bestie, every BGP speaker in a confederation has to recognize the AS_CONFED_SET and AS_CONFED_SEQUENCE segment type extensions to the AS_PATH attribute. 💖

Any BGP speaker that doesn't support these extensions will generate a notification message specifying an "UPDATE Message Error" with a sub-code of "Malformed AS_PATH". 😭

so this compatibility thing means every BGP speaker in a confederation MUST support BGP confederations 🔥 BUT speakers outside the confederation don't need to support these extensions, so they're off the hook 🦋

9. Deployment Considerations 🚀

BGP confederations have been widely deployed across the Internet for years and multiple vendors support them. they're literally iconic 👑

Improper configuration of BGP confederations can cause routing information within an AS to get duplicated for no reason. 💀 That duplication wastes system resources, causes unnecessary route flaps, and delays convergence. not it 🙈

Care should be taken to manually filter duplicate advertisements caused by reachability information being relayed through multiple member autonomous systems, based on the topology and redundancy requirements of the confederation. 🧚

Also, confederations (and route reflectors too) can cause permanent oscillation between candidate routes when the tie breaking rules required by BGP [1] are used. The reason is that they exclude different reachability info from consideration at different locations in a confederation. 😱 Care must be taken when selecting MED values and tie breaking policy to avoid these situations.

One potential way to avoid this is configuring inter-Member-AS IGP metrics higher than intra-Member-AS IGP metrics, and/or using other tie breaking policies so BGP route selection isn't based on incomparable MEDs. 🌈

10. Security Considerations 🔐

This extension to BGP does not change the underlying security issues inherent in the existing BGP, such as those defined in [6]. Those existing BGP security issues stay exactly as they are, so please don't assume this extension fixes them 😤

11. Acknowledgments 🌸

The general concept of BGP confederations was taken from IDRP's Routing Domain Confederations [2]. Some of the introductory text in this document was taken from [5]. 🍓

The authors would like to thank Bruce Cole of Juniper Networks for his implementation feedback and his extensive analysis of the limitations of the protocol extensions described in this document and [5]. They'd also like to thank Srihari Ramachandra of Cisco Systems, Inc., for his feedback. 🫶

Finally, they'd like to thank Ravi Chandra and Yakov Rekhter for their constructive and valuable feedback on earlier versions of this document. ✨

12. References 📚

[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
    1771, March 1995.

[2] Kunzinger, C., Editor, "Inter-Domain Routing Protocol", ISO/IEC
    10747, October 1993.

[3] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
    routing", RFC 1863, October 1995.

[4] Traina, P. "Autonomous System Confederations for BGP", RFC 1965,
    June 1996.

[5] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection An
    Alternative to Full Mesh IBGP", RFC 2796, April 2000.

[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
    Signature Option", RFC 2385, August 1998.

13. Authors' Addresses 📮

Paul Traina
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089 USA

Phone: +1 408 745-2000
EMail: pst+confed@juniper.net


Danny McPherson
Amber Networks, Inc.
48664 Milmont Drive
Fremont, CA 94538

Phone: +1 510.687.5226
EMail:  danny@ambernetworks.com


John G. Scudder
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134

Phone: +1 734.669.8800
EMail: jgs@cisco.com

Appendix A: Comparison with RFC 1965 🔍

The biggest change from [1] is flipping the values of AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to the ones in the "AS_CONFED Segment Type Extension" section. 🔄 Here's the tea: the initial implementation was already widely deployed, and it had them backwards compared to [4]. Subsequent implementations copied that, so to foster interoperability and compliance with deployed implementations, they've been changed here too 🤝

The "Compatibility Discussion" got removed and folded into other discussions in the document. The mention of hierarchical confederations is gone too. And "Routing Domain Identifier" was replaced with Member AS Number. 💅

Finally, the "Deployment Considerations" section got expanded, a few subtle grammar changes were made, and a bit more introductory text was added. ✨

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help implement it, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are: needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed; or as required to translate it into languages other than English. 🌍

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 🦋

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙏

Acknowledgement 🎀

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from