INTERNET-DRAFT John W. Stewart, III / ISI <draft-stewart-bgp-without-as-00.txt> Enke Chen / MCI January 1997 Expire in six months Using BGP Without Consuming a Unique ASN <draft-stewart-bgp-without-as-00.txt> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the abstract listing contained in each Internet-Draft directory to learn the current status of this or any other Internet- Draft. Abstract The number of organizations that have more than one Internet connection is increasing significantly with time. In a substantial number of these cases, an organization's multiple connections are from the same ISP; this type of multi-homing is localized to the organization and its single provider, so a globally unique ASN should not be needed. However, many ISPs can only support their customers' reliability and load-sharing requirements by using BGP, which DOES require an ASN. Since the needs of the ISP and its multi-homed customer are contrary to the Internet's need to allocate the ASN space sensibly, this is a problem. A solution to this problem has been proposed which makes use of private ASNs, but it has several disadvantages. This paper documents the existing solution and describes its disadvantages, then presents another solution which doesn't share the same disadvantages. Stewart & Chen [Page 1]
INTERNET-DRAFT BGP For Load-Sharing Without Unique AS January 1997 1. Introduction With the increased commercial use of the Internet, there has been an increase in the number of organizations with more than one Internet connection. This document explicitly does NOT apply to cases where the multiple connections are from different Internet Service Providers (ISPs). In a case where the multiple connections are from the same ISP, because those multiple connections are "localized" to the ISP and its customer, the rest of the routing system doesn't need to see routing information for that organization any differently than a singly- connected organization. In other words, with respect to the rest of the routing system the organization is singly-connected, so the complexity of the multiple connections is not relevant in a global sense. Autonomous System Numbers (ASNs) are administrative identifiers used in routing protocols and are needed by routing domains which are bona fide members of the global routing system. Because organizations with multiple connections to the same ISP are tail networks with respect to the global routing mesh, these sites do not need a unique ASN. This is architecturally clean and it preserves the finite ASN space (a two-octet value). Despite the fact that these organizations don't need a unique ASN with respect to the Internet routing system, many ISPs can only support the load-sharing and reliability requirements of a multi- homed customer if that customer exchanges routing information with the Border Gateway Protocol Version 4 (BGP4), which DOES require an ASN. The number of organizations that have multiple connections to a single provider is significant and growing over time, so solving this problem of competing needs could represent a significant savings in the use of the ASN space while at the same time fulfilling the users' needs of reliability and load-sharing. This document describes an existing solution to the problem along with some of the disadvantages of that approach when used by globally unique ASs. Later sections present another solution which doesn't share the same disadvantages along with some of the implications of that solution. 2. Using "Private ASN" Space The existing solution proposed to this problem thus far is one which involves the use of ASNs 64512-65535 by organizations multi-homed to a single ISP. (These ASNs were allocated for private use by the Internet Assigned Numbers Authority (IANA) in RFC1930.) Specifically, each ISP has the entire range of private ASN space Stewart & Chen [Page 2]
INTERNET-DRAFT BGP For Load-Sharing Without Unique AS January 1997 available to it to assign to customers multi-homed only to them. An ISP peers with this type of customer using a private ASN, so it carries that AS within its Internal-BGP (IBGP) mesh. However, the ISP's border routers strip the private ASs from the AS-path when the routes are advertised to External BGP neighbors. Note that a responsible provider would explicitly inform customers of this type that the ASN they have been delegated is purely for use between their two ASs and that if that customer (1) changes providers or (2) acquires another connection to the Internet, then that customer's network may need to be reconfigured with a different ASN. The end result is that, because BGP is being used, the ISPs are able to support their customers' load-sharing requirements. However, the pool of unique ASNs is not affected (because private ASNs are used) and the rest of the routing system does not see the complexity of multi-homing (because ISPs remove the private ASs from the AS-path before further advertising the routes into the routing system). While this approach does address the problem, we feel that there are several disadvantages. - First, although the ASN used by a customer multi-homed to a single ISP does not have to be GLOBALLY unique, it DOES have to be unique within the scope of the ISP. This requires that ISPs create new systems to track the delegation of the private ASN space. - Second, although the number of private ASNs allocated is reasonably large, it does not scale to an arbitrary number of these types of customers. - Third, and perhaps most operationally significant in the Internet of today, the work of stripping the private ASs from the AS-path needs to be done on already-busy routers (i.e., edge routers which connect to customers and to other providers). - Fourth, in the event of an implementation problem or a misconfiguration with stripping the private ASs from the AS-path, those routes could be subject to filtering elsewhere in the routing system (e.g., similar to the common filtering of RFC1597's private address space). - Fifth, if the ISP's customer breaks the agreement and acquires another connection to the Internet without acquiring a new ASN, the possibility of looping routing announcements exists because some of the AS-path (the mechanism to detect loops) has been removed. Stewart & Chen [Page 3]
INTERNET-DRAFT BGP For Load-Sharing Without Unique AS January 1997 Note well that while we do not suggest using the mechanism described above in a transit AS, there are instances where it is appropriate. An example of such an instance is an organization which wants to main administrative boundaries within its routing domain but look like a single AS to the rest of the Internet's routing system. For this reason (as well as the simplest case of a completely disconnected internet), the IANA's allocation of the ASNs for private use was good and useful. 3. Using a Dedicated ASN Instead of using private ASN space, we propose that an ISP take a SINGLE ASN which has been assigned to it and use it for all of its customers multiply connected just to it. For example, if MCI was assigned the ASN 4293, and companies Foo and Bar both have connections to MCI (but no other provider), then MCI would instruct both Foo and Bar to use ASN 4293 in their BGP configurations. Logically, this plan results in a provider having many peers with the same AS, although that AS exists in "islands" completely disconnected from one another. This plan satisfies the two requirements: namely that (1) the provider and its customer are able to use BGP for load-sharing and reliability (2) while not having to consume a unique ASN for each of its customers. This plan does not have the same disadvantages of the first proposal. - First, ISPs do not have to track the delegation of private address space, since all of its customers would use the same AS. - Second, there is no limit to the number of customers which an ISP could configure using this scheme. - Third, it is not necessary for any routers to do any extra work to remove ASNs from the AS-path. - Fourth, because the AS being used is perfectly valid to be seen in the global routing system, the possibility of filtering is removed. - Fifth, because the complete AS-path is left in tact, looping is no more likely than today. The disadvantage of this approach is that the customer multiply- connected to the single ISP cannot receive true full routing. The reason for this is that, although the specification allows it, in all Stewart & Chen [Page 4]
INTERNET-DRAFT BGP For Load-Sharing Without Unique AS January 1997 current implementations of BGP, ASN x will not accept a route over an external BGP session if ASN x is already in the AS-path. So to be specific, under this proposal a customer multi-homed to an ISP who requested "full routes" would NOT hear routes from other customers using the same dedicated ASN. A result of this is that these types of customers would have to carry a default route. We do not view this as a significant disadvantage, though, because if the customer is connected only to a single provider they should not need true full routes. A customer of this type MAY want to take something close to full routes for the sake of load-sharing (e.g., to hear MULTI-EXIT- DISCRIMINATORS), but it is not necessary to hear 100% of full routes for this and hearing a large percentage of the routes is adequate. Two additional observations can be made about this approach. First, it is possible to merge these two approaches and use a private ASN as the dedicated ASN. We do not recommend this, however, because if the ASN is stripped from the AS-path then the "extra work on busy routers" disadvantage applies, but if the ASN is not stripped the "possibility of filtering" disadvantage applies. The second observation is that it is possible for ALL providers to use the SAME dedicated ASN. This has the advantage of consuming even fewer ASNs and also allows customers to move from one provider to another without reconfiguring their ASN (though it is still required that they be connected to ONLY ONE provider). This is worth serious consideration in the future; we are not proposing it at this point, however, because there is not yet enough wide-scale operational experience with our proposed solution. 4. Implications 4.1. Change of External Connectivity As noted several times earlier, if an organization that was once multi-homed to a single provider and used that provider's dedicated ASN changes its external connectivity, then it may be necessary for them to reconfigure their network to use a different ASN (either a globally unique one or a dedicated ASN of a different provider). For this reason, organizations (particularly ones with a large number of routers) that know they will eventually be multi-homed to more than one ISP are encouraged to seek a globally unique ASN from the beginning in order to avert a large-scale configuration change. 4.2. Issues Related to Routing Registries The registration of routes in the Internet Routing Registry (IRR) by an organization with multiple connections to a single ISP is not special. Specifically, a route is registered with the appropriate Stewart & Chen [Page 5]
INTERNET-DRAFT BGP For Load-Sharing Without Unique AS January 1997 ASN as origin, and whether or not that ASN is being used by other organizations doesn't matter. One thing that IS different in these cases is related to route filtering: the way that an ISP selects routes from the IRR to build the list to accept from its BGP customer. In general, the selection of routes from the IRR is based on origin AS. This process WOULD WORK for customers multi-homed to a single provider, but the list of routes would be a super-set of those needed. The reason for this is that the list would contain ALL routes registered by ALL customers using the dedicated ASN. This effectively reduces the control which is the point of route filtering, so it needs to be fixed. The simplest fix is to change the code which generates the list of routes to include the feature of matching on origin ASN AND "mntner" name. 5. Security Considerations Security considerations are not discussed in this memo. 6. Acknowledgments The authors would like to thank Roy Alcala of MCI for a number of interesting hallway discussions related to this work. 7. References [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC1771, March 1995. [2] Rekhter, Y., and Gross, P., "Application of the Border Gateway Protocol in the Internet", RFC1772, March 1995. [3] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, April 1995. [4] Hawkinson, J., and Bates, T., "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC1930, March 1996. [5] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, & J. Yu., "Representation of IP Routing Policies in a Routing Registry (ripe-81++)", RFC1786, March 1995. Stewart & Chen [Page 6]
INTERNET-DRAFT BGP For Load-Sharing Without Unique AS January 1997 8. Author's Addresses John Stewart USC/ISI 4350 North Fairfax Drive Suite 620 Arlington, VA 22203 phone: +1 703 807 0132 email: jstewart@isi.edu Enke Chen MCI 2100 Reston Parkway Reston, VA 20191 phone: +1 703 715 7087 email: enke@mci.net Stewart & Chen [Page 7]