idnits 2.17.1 draft-stewart-bgp-without-as-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 195: '...mer of this type MAY want to take some...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1997) is 9957 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 259, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 262, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 265, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 268, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 272, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 1787 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 1786 (ref. '5') Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John W. Stewart, III / ISI 3 Enke Chen / MCI 4 January 1997 5 Expire in six months 7 Using BGP Without Consuming a Unique ASN 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months. Internet-Drafts may be updated, replaced or obsoleted by 19 other documents at any time. It is not appropriate to use Internet- 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress." 23 Please check the abstract listing contained in each Internet-Draft 24 directory to learn the current status of this or any other Internet- 25 Draft. 27 Abstract 29 The number of organizations that have more than one Internet 30 connection is increasing significantly with time. In a substantial 31 number of these cases, an organization's multiple connections are 32 from the same ISP; this type of multi-homing is localized to the 33 organization and its single provider, so a globally unique ASN should 34 not be needed. However, many ISPs can only support their customers' 35 reliability and load-sharing requirements by using BGP, which DOES 36 require an ASN. Since the needs of the ISP and its multi-homed 37 customer are contrary to the Internet's need to allocate the ASN 38 space sensibly, this is a problem. A solution to this problem has 39 been proposed which makes use of private ASNs, but it has several 40 disadvantages. This paper documents the existing solution and 41 describes its disadvantages, then presents another solution which 42 doesn't share the same disadvantages. 44 1. Introduction 46 With the increased commercial use of the Internet, there has been an 47 increase in the number of organizations with more than one Internet 48 connection. This document explicitly does NOT apply to cases where 49 the multiple connections are from different Internet Service 50 Providers (ISPs). 52 In a case where the multiple connections are from the same ISP, 53 because those multiple connections are "localized" to the ISP and its 54 customer, the rest of the routing system doesn't need to see routing 55 information for that organization any differently than a singly- 56 connected organization. In other words, with respect to the rest of 57 the routing system the organization is singly-connected, so the 58 complexity of the multiple connections is not relevant in a global 59 sense. Autonomous System Numbers (ASNs) are administrative 60 identifiers used in routing protocols and are needed by routing 61 domains which are bona fide members of the global routing system. 62 Because organizations with multiple connections to the same ISP are 63 tail networks with respect to the global routing mesh, these sites do 64 not need a unique ASN. This is architecturally clean and it 65 preserves the finite ASN space (a two-octet value). 67 Despite the fact that these organizations don't need a unique ASN 68 with respect to the Internet routing system, many ISPs can only 69 support the load-sharing and reliability requirements of a multi- 70 homed customer if that customer exchanges routing information with 71 the Border Gateway Protocol Version 4 (BGP4), which DOES require an 72 ASN. The number of organizations that have multiple connections to a 73 single provider is significant and growing over time, so solving this 74 problem of competing needs could represent a significant savings in 75 the use of the ASN space while at the same time fulfilling the users' 76 needs of reliability and load-sharing. 78 This document describes an existing solution to the problem along 79 with some of the disadvantages of that approach when used by globally 80 unique ASs. Later sections present another solution which doesn't 81 share the same disadvantages along with some of the implications of 82 that solution. 84 2. Using "Private ASN" Space 86 The existing solution proposed to this problem thus far is one which 87 involves the use of ASNs 64512-65535 by organizations multi-homed to 88 a single ISP. (These ASNs were allocated for private use by the 89 Internet Assigned Numbers Authority (IANA) in RFC1930.) 90 Specifically, each ISP has the entire range of private ASN space 91 available to it to assign to customers multi-homed only to them. An 92 ISP peers with this type of customer using a private ASN, so it 93 carries that AS within its Internal-BGP (IBGP) mesh. However, the 94 ISP's border routers strip the private ASs from the AS-path when the 95 routes are advertised to External BGP neighbors. 97 Note that a responsible provider would explicitly inform customers of 98 this type that the ASN they have been delegated is purely for use 99 between their two ASs and that if that customer (1) changes providers 100 or (2) acquires another connection to the Internet, then that 101 customer's network may need to be reconfigured with a different ASN. 103 The end result is that, because BGP is being used, the ISPs are able 104 to support their customers' load-sharing requirements. However, the 105 pool of unique ASNs is not affected (because private ASNs are used) 106 and the rest of the routing system does not see the complexity of 107 multi-homing (because ISPs remove the private ASs from the AS-path 108 before further advertising the routes into the routing system). 110 While this approach does address the problem, we feel that there are 111 several disadvantages. 113 - First, although the ASN used by a customer multi-homed to a 114 single ISP does not have to be GLOBALLY unique, it DOES have 115 to be unique within the scope of the ISP. This requires that 116 ISPs create new systems to track the delegation of the private 117 ASN space. 119 - Second, although the number of private ASNs allocated is 120 reasonably large, it does not scale to an arbitrary number of 121 these types of customers. 123 - Third, and perhaps most operationally significant in the 124 Internet of today, the work of stripping the private ASs from 125 the AS-path needs to be done on already-busy routers (i.e., 126 edge routers which connect to customers and to other providers). 128 - Fourth, in the event of an implementation problem or a 129 misconfiguration with stripping the private ASs from the 130 AS-path, those routes could be subject to filtering elsewhere 131 in the routing system (e.g., similar to the common filtering of 132 RFC1597's private address space). 134 - Fifth, if the ISP's customer breaks the agreement and acquires 135 another connection to the Internet without acquiring a new ASN, 136 the possibility of looping routing announcements exists 137 because some of the AS-path (the mechanism to detect loops) has 138 been removed. 140 Note well that while we do not suggest using the mechanism described 141 above in a transit AS, there are instances where it is appropriate. 142 An example of such an instance is an organization which wants to main 143 administrative boundaries within its routing domain but look like a 144 single AS to the rest of the Internet's routing system. For this 145 reason (as well as the simplest case of a completely disconnected 146 internet), the IANA's allocation of the ASNs for private use was good 147 and useful. 149 3. Using a Dedicated ASN 151 Instead of using private ASN space, we propose that an ISP take a 152 SINGLE ASN which has been assigned to it and use it for all of its 153 customers multiply connected just to it. For example, if MCI was 154 assigned the ASN 4293, and companies Foo and Bar both have 155 connections to MCI (but no other provider), then MCI would instruct 156 both Foo and Bar to use ASN 4293 in their BGP configurations. 158 Logically, this plan results in a provider having many peers with the 159 same AS, although that AS exists in "islands" completely disconnected 160 from one another. 162 This plan satisfies the two requirements: namely that (1) the 163 provider and its customer are able to use BGP for load-sharing and 164 reliability (2) while not having to consume a unique ASN for each of 165 its customers. This plan does not have the same disadvantages of the 166 first proposal. 168 - First, ISPs do not have to track the delegation of private 169 address space, since all of its customers would use the same AS. 171 - Second, there is no limit to the number of customers which an 172 ISP could configure using this scheme. 174 - Third, it is not necessary for any routers to do any extra work 175 to remove ASNs from the AS-path. 177 - Fourth, because the AS being used is perfectly valid to be seen 178 in the global routing system, the possibility of filtering is 179 removed. 181 - Fifth, because the complete AS-path is left in tact, looping is 182 no more likely than today. 184 The disadvantage of this approach is that the customer multiply- 185 connected to the single ISP cannot receive true full routing. The 186 reason for this is that, although the specification allows it, in all 187 current implementations of BGP, ASN x will not accept a route over an 188 external BGP session if ASN x is already in the AS-path. So to be 189 specific, under this proposal a customer multi-homed to an ISP who 190 requested "full routes" would NOT hear routes from other customers 191 using the same dedicated ASN. A result of this is that these types 192 of customers would have to carry a default route. We do not view 193 this as a significant disadvantage, though, because if the customer 194 is connected only to a single provider they should not need true full 195 routes. A customer of this type MAY want to take something close to 196 full routes for the sake of load-sharing (e.g., to hear MULTI-EXIT- 197 DISCRIMINATORS), but it is not necessary to hear 100% of full routes 198 for this and hearing a large percentage of the routes is adequate. 200 Two additional observations can be made about this approach. First, 201 it is possible to merge these two approaches and use a private ASN as 202 the dedicated ASN. We do not recommend this, however, because if the 203 ASN is stripped from the AS-path then the "extra work on busy 204 routers" disadvantage applies, but if the ASN is not stripped the 205 "possibility of filtering" disadvantage applies. The second 206 observation is that it is possible for ALL providers to use the SAME 207 dedicated ASN. This has the advantage of consuming even fewer ASNs 208 and also allows customers to move from one provider to another 209 without reconfiguring their ASN (though it is still required that 210 they be connected to ONLY ONE provider). This is worth serious 211 consideration in the future; we are not proposing it at this point, 212 however, because there is not yet enough wide-scale operational 213 experience with our proposed solution. 215 4. Implications 217 4.1. Change of External Connectivity 219 As noted several times earlier, if an organization that was once 220 multi-homed to a single provider and used that provider's dedicated 221 ASN changes its external connectivity, then it may be necessary for 222 them to reconfigure their network to use a different ASN (either a 223 globally unique one or a dedicated ASN of a different provider). For 224 this reason, organizations (particularly ones with a large number of 225 routers) that know they will eventually be multi-homed to more than 226 one ISP are encouraged to seek a globally unique ASN from the 227 beginning in order to avert a large-scale configuration change. 229 4.2. Issues Related to Routing Registries 231 The registration of routes in the Internet Routing Registry (IRR) by 232 an organization with multiple connections to a single ISP is not 233 special. Specifically, a route is registered with the appropriate 234 ASN as origin, and whether or not that ASN is being used by other 235 organizations doesn't matter. One thing that IS different in these 236 cases is related to route filtering: the way that an ISP selects 237 routes from the IRR to build the list to accept from its BGP 238 customer. In general, the selection of routes from the IRR is based 239 on origin AS. This process WOULD WORK for customers multi-homed to a 240 single provider, but the list of routes would be a super-set of those 241 needed. The reason for this is that the list would contain ALL 242 routes registered by ALL customers using the dedicated ASN. This 243 effectively reduces the control which is the point of route 244 filtering, so it needs to be fixed. The simplest fix is to change 245 the code which generates the list of routes to include the feature of 246 matching on origin ASN AND "mntner" name. 248 5. Security Considerations 250 Security considerations are not discussed in this memo. 252 6. Acknowledgments 254 The authors would like to thank Roy Alcala of MCI for a number of 255 interesting hallway discussions related to this work. 257 7. References 259 [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 260 RFC1771, March 1995. 262 [2] Rekhter, Y., and Gross, P., "Application of the Border Gateway 263 Protocol in the Internet", RFC1772, March 1995. 265 [3] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, 266 April 1995. 268 [4] Hawkinson, J., and Bates, T., "Guidelines for creation, 269 selection, and registration of an Autonomous System (AS)", RFC1930, 270 March 1996. 272 [5] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 273 M. Terpstra, & J. Yu., "Representation of IP Routing Policies in a 274 Routing Registry (ripe-81++)", RFC1786, March 1995. 276 8. Author's Addresses 278 John Stewart 279 USC/ISI 280 4350 North Fairfax Drive 281 Suite 620 282 Arlington, VA 22203 283 phone: +1 703 807 0132 284 email: jstewart@isi.edu 286 Enke Chen 287 MCI 288 2100 Reston Parkway 289 Reston, VA 20191 290 phone: +1 703 715 7087 291 email: enke@mci.net