idnits 2.17.1 draft-ietf-idr-as-dedicated-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-19) 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. ** There are 116 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 183 has weird spacing: '...uen for their...' -- 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 (July 1997) is 9775 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: '3' is defined on line 194, 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') == Outdated reference: A later version (-04) exists of draft-ietf-idr-aggregation-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-idr-aggregation-framework (ref. '6') Summary: 14 errors (**), 0 flaws (~~), 4 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 Tony Bates / Cisco 4 Ravi Chandra / Cisco 5 Enke Chen / Cisco 6 July 1997 8 Using a Dedicated AS for Sites Homed to a Single Provider 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute work- 16 ing documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months. Internet-Drafts may be updated, replaced or obsoleted by 20 other documents at any time. It is not appropriate to use Internet- 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 Please check the abstract listing contained in each Internet-Draft 25 directory to learn the current status of this or any other Internet- 26 Draft. 28 Abstract 30 With the increased growth of the Internet, the number of customers 31 using BGP4 has grown significantly. RFC1930 outlines a set of guide- 32 lines for when one needs and should use an AS. However, the customer 33 and service provider (ISP) are left with a problem as a result of 34 this in that while there is no need for an allocated AS under the 35 guidelines, certain conditions make the use of BGP4 a very pragmatic 36 and perhaps only way to connect a customer homed to a single ISP. 37 This paper proposes a solution to this problem in line with recommen- 38 dations set forth in RFC1930. 40 1. Problems 42 With the increased growth of the Internet, the number of customers 43 using BGP4 [1],[2] has grown significantly. RFC1930 [4] outlines a 44 set of guidelines for when one needs and should use an AS. However, 45 the customer and service provider (ISP) are left with a problem as a 46 result of this in that while there is no need for an allocated AS 47 under the guidelines, certain conditions make the use of BGP4 a very 48 pragmatic and perhaps only way to connect a customer homed to a sin- 49 gle ISP. These conditions are as follows: 51 1) Customers multi-homed to single provider 53 Consider the scenario outlined in Figure 1 below. 55 +-------+ +-------+ 56 +----+ | | | 57 +------+ | | ISP A +------+ ISP B | 58 | Cust.+---+ | | | | 59 | X +--------+ | | | 60 +------+ ++-----++\ +-------+ 61 | | \ 62 | | \ +--------+ 63 ++-----++ +-| | 64 | Cust. | | ISP C | 65 | Y | | | 66 +-------+ +--------+ 68 Figure 1: Customers multi-home to a single provider 70 Here both customer X and customer Y are multi-homed to a single 71 provider, ISP A. Because these multiple connections are "local- 72 ized" between the ISP A and its customers, the rest of the routing 73 system (ISP B and ISP C in this case) doesn't need to see routing 74 information for a single multi-homed customer any differently than 75 a singly-homed customer as it has the same routing policy as ISP A 76 relative to ISP B and ISP C. In other words, with respect to the 77 rest of the Internet routing system the organization is singly- 78 homed, so the complexity of the multiple connections is not rele- 79 vant in a global sense. Autonomous System Numbers (AS) are iden- 80 tifiers used in routing protocols and are needed by routing 81 domains as part of the global routing system. However, as [4] 82 correctly outlines, organizations with the same routing policy as 83 their upstream provider do not need an AS. 85 Despite this fact, a problem exists in that many ISPs can only 86 support the load-sharing and reliability requirements of a multi- 87 homed customer if that customer exchanges routing information 88 using BGP-4 which does require an AS as part of the protocol. 90 2) Singly-homed customers requiring dynamic advertisement of NLRI's 92 While this is not a common case as static routing is generally 93 used for this purpose, if a large amount of NLRI's need to be 94 advertised from the customer to the ISP it is often administra- 95 tively easier for these prefixes to be advertised using a dynamic 96 routing protocol. Today, the only exterior gateway protocol (EGP) 97 that is able to do this is BGP. This leads to the same problem 98 outlined in condition 1 above. 100 As can be seen there is clearly a problem with the recommendations 101 set forth in [4] and the practice of using BGP4 in the scenarios 102 above. Section 2 proposes a solution to this problem with following 103 sections describing the implications and application of the proposed 104 solution. 106 It should also be noted that if a customer is multi-homed to more 107 than one ISP then they are advised to obtain an official allocated AS 108 from their allocation registry. 110 2. Solution 112 The solution we are proposing is that all BGP customers homed to the 113 same single ISP use a single, dedicated AS specified by the ISP. 115 Logically, this solution results in an ISP having many peers with the 116 same AS, although that AS exists in "islands" completely disconnected 117 from one another. 119 Several practical implications of this solution are discussed in the 120 next section. 122 3. Implications 124 3.1 Full Routing Table Announcement 126 The solution precludes the ability for a BGP customer using the dedi- 127 cated AS to receive 100% full routes. Because of routing loop detec- 128 tion of AS path, a BGP speaker rejects routes with its own AS number 129 in the AS path. Imagine Customer X and Customer Y maintain BGP peers 130 with Provider A using AS number N. Then, Customer X will not be able 131 to received routes of Customer Y. We do not believe that this would 132 cause a problem for Customer X, though, because Customer X and Cus- 133 tomer Y are both stub networks so default routing is adequate, and 134 the absence of a very small portion of the full routing table is 135 unlikely to have a noticeable impact on traffic patterns guided by 136 MEDs received. 138 A BGP customer using the dedicated AS must carry a default route 139 (preferably receiving from its provider via BGP). 141 3.2 Change of External Connectivity 143 The dedicated AS specified by a provider is purely for use in peering 144 between its customers and the provider. When a customer using the 145 dedicated AS changes its external connectivity, it may be necessary 146 for the customer to reconfigure their network to use a different AS 147 number (either a globally unique one if homed to multiple providers, 148 or a dedicated AS of a different provider). 150 3.3 Aggregation 152 As BGP customers using this dedicated AS are only homed to one ISP, 153 their routes allocated from its providers CIDR block do not need to 154 be announced upstream by its provider as the providers will already 155 be originating the larger block. [6]. 157 3.4 Routing Registries 159 The Internet Routing Registry (IRR) [5] is used by providers to gen- 160 erate route filtering lists. Such lists are derived primarily from 161 the "origin" attribute of the route objects. The "origin" is the AS 162 that originates the route. With multiple customers using the same 163 AS, finer granularity will be necessary to generate the correct route 164 filtering. For example, the "mntner" attribute or the "community" 165 attribute of a route object can be used along with the "origin" 166 attribute in generating the filtering lists. 168 4. Practice 170 The AS number specified by a provider can either be an AS from the 171 private AS space (64512 - 65535) [4], or be an AS previously allo- 172 cated to the provider. With the former, the dedicated AS like all 173 other private AS's should be stripped from its AS path while the 174 route is being propagated to the rest of the Internet routing system. 176 5. Security Considerations 178 Security considerations are not discussed in this memo. 180 6. Acknowledgments 182 The authors would like to thank Roy Alcala of MCI and Arpakorn 183 Boonkongchuen for their input to this document. The members of the 184 IDR Working Group also provided helpful comments. 186 7. References 188 [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 189 RFC1771, March 1995. 191 [2] Rekhter, Y., and Gross, P., "Application of the Border Gateway 192 Protocol in the Internet", RFC1772, March 1995. 194 [3] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, 195 April 1995. 197 [4] Hawkinson, J., and Bates, T., "Guidelines for creation, selec- 198 tion, and registration of an Autonomous System (AS)", RFC1930, March 199 1996. 201 [5] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 202 M. Terpstra, & J. Yu., "Representation of IP Routing Policies in a 203 Routing Registry (ripe-81++)", RFC1786, March 1995. 205 [6] E. Chen, J. Stewart., "A Framework for Inter-Domain Route Aggre- 206 gation", draft-ietf-idr-aggregation-framework-01.txt, July 1997. 208 8. Author's Addresses 210 John Stewart 211 USC/ISI 212 4350 North Fairfax Drive 213 Suite 620 214 Arlington, VA 22203 215 email: jstewart@isi.edu 217 Tony Bates 218 Cisco Systems, Inc. 219 170 West Tasman Drive 220 San Jose, CA 95134 221 email: tbates@cisco.com 223 Ravi Chandra 224 Cisco Systems, Inc. 225 170 West Tasman Drive 226 San Jose, CA 95134 227 email: rchandra@cisco.com 229 Enke Chen 230 Cisco Systems, Inc. 231 170 West Tasman Drive 232 San Jose, CA 95134 233 email: enkechen@cisco.com