RFC 5065

Autonomous System Confederations for BGP

📅 published August 2007, from ietf

Autonomous System Confederations for BGP ✨

Okay bestie 💖 so this is RFC 5065, all about Autonomous System Confederations for BGP. It's a Standards Track doc from the Network Working Group, dated August 2007. The authors are P. Traina (Blissfully Retired), D. McPherson (Arbor Networks), and J. Scudder (Juniper Networks) 👑. It obsoletes RFC 3065, so if you see that one floating around, this is the newer version 🫶

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 (C) The IETF Trust (2007) 🎀

Abstract

Okay so BGP (the Border Gateway Protocol) is the inter-autonomous-system routing protocol built for TCP/IP networks 🦋 The annoying part is that BGP says all the BGP speakers inside one autonomous system (AS) must be fully meshed. That's a seriously big scaling problem, and a bunch of proposals have documented it already 😭

This doc describes an extension to BGP that can be used to make a confederation of autonomous systems. From the outside, the whole confederation looks like one single AS to outside BGP peers, which gets rid of the "full mesh" requirement 💅 The goal is to help with policy administration and make it way less of a headache to run a huge autonomous system.

This document obsoletes RFC 3065.

Table of Contents ✨

1. Introduction ....................................................3
   1.1. Specification of Requirements ..............................3
   1.2. Terminology ................................................3
2. Discussion ......................................................4
3. AS_CONFED Segment Type Extension ................................5
4. Operation .......................................................5
   4.1. AS_PATH Modification Rules .................................6
5. Error Handling ..................................................8
   5.1. Error Handling .............................................8
   5.2. MED and LOCAL_PREF Handling ................................8
   5.3. AS_PATH and Path Selection .................................9
6. Compatibility Considerations ...................................10
7. Deployment Considerations ......................................10
8. Security Considerations ........................................10
9. Acknowledgments ................................................11
10. References ....................................................11
   10.1. Normative References .....................................11
   10.2. Informative References ...................................11
Appendix A. Aggregate Routing Information .........................13
Appendix B. Changes from RFC 3065 .................................13

1. Introduction ✨

Okay so originally, BGP required that all BGP speakers inside one AS be fully meshed 🕸️ That means for n BGP speakers in an AS, you need n*(n-1)/2 unique Internal BGP (IBGP) sessions. Honestly, that does NOT scale when there are tons of IBGP speakers in one AS, which is super common in networks today 😩

People have documented this scaling problem for a while, and there have been several proposals to fix it, like [RFC2796] and [RFC1863] (which got made historic by [RFC4223]). This doc brings another option that gets rid of the need for a "full mesh." It's called "Autonomous System Confederations for BGP," or just "BGP confederations" 🦋 It's also been noticed that BGP confederations may improve routing policy control, which is a nice bonus.

This document is a revision of, and obsoletes, [RFC3065], which is itself a revision of [RFC1965]. It includes editorial changes, terminology clarifications, and more explicit protocol specifications, all based on lots of implementation and deployment experience with BGP Confederations 🧚

1.1. Specification of Requirements

Here's the key word thing 🔑 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].

1.2. Terminology

Let's get the vocab down 📚

  • AS Confederation: a collection of autonomous systems that gets represented and advertised as a single AS number to BGP speakers that aren't members of the local BGP confederation.
  • AS Confederation Identifier: an externally visible autonomous system number that identifies a BGP confederation as a whole.
  • Member Autonomous System (Member-AS): an autonomous system that's contained in a given AS confederation. Also, "Member Autonomous System" and "Member-AS" are used entirely interchangeably throughout this document, so no stress 💅
  • Member-AS Number: an autonomous system number identifier that's only visible within a BGP confederation, and it's used to represent a Member-AS inside that confederation.

2. Discussion 💬

It may be useful to split autonomous systems that have a very large number of BGP speakers into smaller domains. The reason is to control routing policy using the information in the BGP AS_PATH attribute 🗺️ For example, you might decide to treat all the BGP speakers in one geographic region as a single entity.

Beyond the routing policy stuff, if techniques like the ones in this doc or in [RFC4456] aren't used, [BGP-4] requires BGP speakers in the same autonomous system to set up a full mesh of TCP connections among all speakers, just to swap exterior routing information. Inside an autonomous system, the number of intra-domain connections each border router has to maintain can get seriously big 😵‍💫

Splitting up a large autonomous system can cut the total number of intra-domain BGP connections by a lot, because the connectivity requirements turn into the same model used for inter-domain connections ✨

Unfortunately, splitting an autonomous system may make routing policy based on AS_PATH information more complicated for everyone on the Internet 😬 On top of that, the split also makes it harder to coordinate external peering whenever the internal topology of that collection of autonomous systems changes.

So, dividing an autonomous system into separate systems may adversely affect optimal routing of packets through the Internet 🥺

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

3. AS_CONFED Segment Type Extension 🌈

Currently, BGP says that the AS_PATH attribute is a well-known mandatory attribute, and it's made up of a sequence of AS path segments. Each AS path segment is represented by a triple <path segment type, path segment length, path segment value> 🧩

In [BGP-4], the path segment type is a 1-octet field, and there are two values defined:

Value     Segment Type

  1       AS_SET: unordered set of autonomous systems that a route in
          the UPDATE message has traversed

  2       AS_SEQUENCE: ordered set of autonomous systems that a route
          in the UPDATE message has traversed

This document adds two more segment types 🎀

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

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

4. Operation 🎬

Okay this is the part where the rules actually get real 🫣 A member of a BGP confederation MUST use its AS Confederation Identifier in all transactions with peers that aren't members of its confederation. This AS Confederation Identifier is 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 MUST use its Member-AS Number in all transactions with peers that are members of the same confederation as the local BGP speaker 🧚

A BGP speaker that gets an AS_PATH attribute containing an autonomous system matching its own AS Confederation Identifier SHALL treat the path the same way it would if it had received a path containing its own AS number 🔥

A BGP speaker that gets an AS_PATH attribute containing an AS_CONFED_SEQUENCE or AS_CONFED_SET that 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 💖

4.1. AS_PATH Modification Rules ✨

Okay bestie, so when you're implementing BGP confederations, Section 5.1.2 of [BGP-4] gets replaced with this text 🎀

AS_PATH is a well-known mandatory attribute 💅 It lists the autonomous systems that the routing info in this UPDATE message has travelled through. Its components can be AS_SETs, AS_SEQUENCEs, AS_CONFED_SETs, or AS_CONFED_SEQUENCES.

When a BGP speaker passes on a route it learned from another speaker's UPDATE message, it changes the route's AS_PATH depending on where the receiving speaker lives 🦋

  • a) When the speaker advertises the route to another BGP speaker in its own Member-AS, the advertising speaker SHALL NOT modify the AS_PATH attribute on that route. Same family, no edits needed 🫶
  • b) When the speaker advertises the route to a BGP speaker in a neighboring autonomous system that is a member of the local confederation, it updates AS_PATH like this:
    • 1) If the first path segment of AS_PATH is AS_CONFED_SEQUENCE, the local system prepends its own Member-AS number as the last element of that sequence (leftmost in terms of the octet positions in the protocol message) 🌸 If prepending would overflow the segment (more than 255 ASs), it SHOULD prepend a new AS_CONFED_SEQUENCE segment and put its own AS number in that new one.
    • 2) If the first path segment of AS_PATH is not AS_CONFED_SEQUENCE, the local system prepends a new AS_CONFED_SEQUENCE segment to AS_PATH, with its own Member-AS number inside it.
    • 3) If AS_PATH is empty, the local system creates an AS_CONFED_SEQUENCE segment, puts its own Member-AS number in it, and puts that segment into AS_PATH.
  • c) When the speaker advertises the route to a BGP speaker in a neighboring autonomous system that is not a member of the local confederation, the advertising speaker SHALL update AS_PATH like this:
    • 1) If any path segments of AS_PATH are AS_CONFED_SEQUENCE or AS_CONFED_SET, those segments MUST be removed from AS_PATH. What's left is the sanitized AS_PATH, which then goes through steps 2, 3, or 4 🧹
    • 2) If the first path segment of the remaining AS_PATH is AS_SEQUENCE, the local system prepends its own AS Confederation Identifier as the last element of that sequence (leftmost in terms of the octet positions in the protocol message). If that would overflow the segment (more than 255 ASs), it SHOULD prepend a new AS_SEQUENCE segment and put its own AS number in the new one.
    • 3) If the first path segment of the remaining AS_PATH is AS_SET, the local system prepends a new AS_SEQUENCE segment to AS_PATH, with its own AS Confederation Identifier inside it.
    • 4) If the remaining AS_PATH is empty, the local system creates an AS_SEQUENCE segment, puts its own AS Confederation Identifier in it, and puts that segment into AS_PATH.

When a BGP speaker originates a route:

  • a) The originating speaker puts its own AS Confederation Identifier in an AS_SEQUENCE path segment in the AS_PATH attribute of every UPDATE sent to BGP speakers in neighboring autonomous systems that are not members of the local confederation. In this case the AS Confederation Identifier is the only entry in that segment, and that segment is the only segment in AS_PATH 🌈
  • b) The originating speaker puts its own Member-AS number in an AS_CONFED_SEQUENCE path segment in the AS_PATH attribute of every UPDATE sent to BGP speakers in neighboring Member Autonomous Systems that are members of the local confederation. Here the Member-AS number is the only entry in that segment, and that segment is the only segment in AS_PATH.
  • c) The originating speaker puts an empty AS_PATH attribute in every UPDATE sent to BGP speakers inside the same Member-AS. (An empty AS_PATH attribute is one whose length field contains the value zero.)

Whenever changing AS_PATH calls for including or prepending the local system's AS Confederation Identifier or Member-AS number, the local system MAY include or prepend more than one instance of that value in AS_PATH. This is controlled via local configuration 🎛️

5. Error Handling 💀

A BGP speaker MUST NOT send updates containing AS_CONFED_SET or AS_CONFED_SEQUENCE attributes to peers that are not members of the local confederation. Don't do it, periodt 🙅‍♀️

It is an error for a BGP speaker to receive an UPDATE message whose AS_PATH attribute contains AS_CONFED_SEQUENCE or AS_CONFED_SET segments from a neighbor that isn't in the same confederation. If a BGP speaker gets such an UPDATE message, it SHALL treat the message as having a malformed AS_PATH, following the procedures of [BGP-4], Section 6.3 ("UPDATE Message Error Handling").

It is an error for a BGP speaker to receive an update message from a confederation peer that isn't in the same Member-AS and whose first segment is not AS_CONFED_SEQUENCE. If a BGP speaker gets such an UPDATE message, it SHALL treat the message as having a malformed AS_PATH, following the procedures of [BGP-4], Section 6.3 ("UPDATE Message Error Handling").

5.1. Common Administrative Issues 🏠

It's reasonable for the Member Autonomous Systems of a confederation to share one administration and Interior Gateway Protocol (IGP) information for the whole confederation. It's also reasonable for each Member-AS to run its own independent IGP. In that second case, NEXT_HOP may need to be set using policy, since by default it stays unchanged 🧠

5.2. MED and LOCAL_PREF Handling 📊

It SHALL be legal for a BGP speaker to advertise an unchanged NEXT_HOP and MULTI_EXIT_DISC (MED) attribute to peers in a neighboring Member-AS of the local confederation ✅

MEDs of two routes SHOULD only be compared if the first autonomous systems in the first AS_SEQUENCE of both routes are the same. In other words, skip all the autonomous systems in the AS_CONFED_SET and AS_CONFED_SEQUENCE. An implementation MAY provide the ability to configure path selection so that MEDs of two routes are comparable if the first autonomous systems in the AS_PATHs are the same, regardless of AS_SEQUENCE or AS_CONFED_SEQUENCE in the AS_PATH.

An implementation MAY compare MEDs received from a Member-AS via multiple paths. An implementation MAY also compare MEDs from different Member Autonomous Systems of the same confederation.

Also, the restriction against sending the LOCAL_PREF attribute to peers in a neighboring autonomous system within the same confederation is removed 🎉

5.3. AS_PATH and Path Selection 🛤️

Path selection criteria for information received from members inside a confederation MUST follow the same rules used for information received from members inside the same autonomous system, as specified in [BGP-4].

On top of that, the following rules SHALL be applied:

  1. If the AS_PATH is internal to the local confederation (meaning there are only AS_CONFED_* segments), consider the neighbor AS to be the local AS 🏡
  2. Otherwise, if the first segment in the path that is not an AS_CONFED_SEQUENCE or AS_CONFED_SET is an AS_SEQUENCE, consider the neighbor AS to be the leftmost AS_SEQUENCE AS.
  3. When comparing routes using AS_PATH length, CONFED_SEQUENCE and CONFED_SETs SHOULD NOT be counted 🙈
  4. When comparing routes using the internal (IBGP learned) versus external (EBGP learned) rules, treat a route learned from a peer in the same confederation (not necessarily the same Member-AS) as "internal" 💜

6. Compatibility Considerations 🤝

All BGP speakers participating as members of a confederation MUST 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" 🚨

Because of this, all BGP speakers participating in a confederation MUST support BGP confederations. However, BGP speakers outside the confederation need not support these extensions 🫧

7. Deployment Considerations 🚀

BGP confederations have been widely deployed across the Internet for years and are supported by multiple vendors. Iconic longevity 👑

Improper configuration of BGP confederations can cause routing information within an AS to be duplicated unnecessarily. That duplication wastes system resources, causes unnecessary route flaps, and delays convergence 😭

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 (as well as route reflectors), by excluding different reachability information from consideration at different locations in a confederation, have been shown [RFC3345] to cause permanent oscillation between candidate routes when using the tie-breaking rules required by BGP [BGP-4]. Care must be taken when selecting MED values and tie-breaking policy to avoid these situations. This one is serious, bestie 🌀

One potential way to avoid this is to configure inter-Member-AS IGP metrics higher than intra-Member-AS IGP metrics, and/or to use other tie-breaking policies that avoid BGP route selection based on incomparable MEDs 🧚

8. Security Considerations 🔐

This extension to BGP does not change the underlying security issues inherent in the existing BGP protocol, such as those described in [RFC2385] and [BGP-VULN]. Not a fix for the old problems, so keep those in mind, fr fr 😬

9. Acknowledgments 💌

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

The authors would like to acknowledge Jeffrey Haas for his extensive feedback on this document. They'd also like to thank Bruce Cole, Srihari Ramachandra, Alex Zinin, Naresh Kumar Paliwal, Jeffrey Haas, Cengiz Alaettinoglu, Mike Hollyman, and Bruno Rijsman for their feedback and suggestions 🫶

Finally, they'd like to acknowledge Ravi Chandra and Yakov Rekhter for providing constructive and valuable feedback on earlier versions of this specification 🌸

10. References 🦋

The reference entries themselves weren't included in the text I was given, so I haven't written any out. I won't make up citations, bestie 🙈

10.1. Normative References

okay so these are the must-reads 📚 the normative refs are the stuff you literally can't skip if you want the spec to make sense 💅

  • [BGP-4] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
  • [RFC1965] Traina, P., "Autonomous System Confederations for BGP", RFC 1965, June 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.

10.2. Informative References

these ones are more like the extra reading list 🧚 still iconic to know they exist 🦋

  • [ISO10747] Kunzinger, C., Editor, "Inter-Domain Routing Protocol", ISO/IEC 10747, October 1993.
  • [RFC1863] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh routing", RFC 1863, October 1995.
  • [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
  • [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
  • [RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic", RFC 4223, October 2005.
  • [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
  • [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006.

Appendix A. Aggregate Routing Information ✨

okay real talk, aggregation (the stuff in [BGP-4], Section 9.2.2.2) is basically NOT something people do inside confederations 🙈 but if someone does do it anyway, the [BGP-4] rules should be followed, and you just swap in the confed versions: AS_SET becomes AS_CONFED_SET and AS_SEQUENCE becomes AS_CONFED_SEQUENCE 🎀

the big rule here is that confederation-type segments (AS_CONFED_SET and AS_CONFED_SEQUENCE) MUST be kept separate from non-confederation segments (AS_SET and AS_SEQUENCE) 🔥 no mixing them up, bestie!!

an implementation could also go a different route, where non-confederation segments get aggregated as described in [BGP-4], Section 9.2.2.2, and confederation-type segments just don't get aggregated at all 🌸

and lowkey the TL;DR is that supporting aggregation of confederation-type segments is not mandatory 💜

Appendix B. Changes from RFC 3065 🦋

the main reason RFC 3065 got an update was AS path segment handling 🎀 like, what do you do when you're talking to BGP peers outside a confederation, and making sure AS_CONFED_[SET|SEQUENCE] segment types don't get propagated to peers outside of a confederation 😭

so the "Error Handling" section up above got added, and it applies not only to BGP confederation speakers but to ALL BGP speakers 👑

everything else is mostly trivial stuff ✨ some clarification, some consistency in terminology, and a note that AS_CONFED_[SET|SEQUENCE] Segment Type handling should be just as it is in the base BGP specification [BGP-4] 🧚

Authors' Addresses 💖

Paul Traina
Blissfully Retired
Email: bgp-confederations@st04.pst.org

Danny McPherson
Arbor Networks
EMail: danny@arbor.net

John G. Scudder
Juniper Networks
EMail: jgs@juniper.net

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 💅

the IETF takes no position on whether any Intellectual Property Rights (or other rights) that might be claimed to pertain to the implementation or use of the technology described in this document are valid or in scope, or whether a license under those rights might or might not be available 🫶 it also doesn't claim it has made any independent effort to find those rights. info on how rights work for RFC documents is in BCP 78 and BCP 79.

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔥

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. send that info to ietf-ipr@ietf.org 💜

Acknowledgement 🎀

funding for the RFC Editor function is currently provided by the Internet Society 🌸✨

📦 where this page comes from