idnits 2.17.00 (12 Aug 2021) /tmp/idnits39148/draft-templin-rtgwg-scalable-bgp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 23, 2019) is 1214 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-rtgwg-atn-bgp-01 == Outdated reference: A later version (-99) exists of draft-templin-intarea-6706bis-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational January 23, 2019 5 Expires: July 27, 2019 7 Scalable De-Aggregation for Overlays Using the Border Gateway Protocol 8 (BGP) 9 draft-templin-rtgwg-scalable-bgp-00.txt 11 Abstract 13 The Border Gateway Protocol (BGP) has well-known limitations in terms 14 of the numbers of routes that can be carried and stability of the 15 routing system. This is especially true when mobile nodes frequently 16 change their network attachment points, which in the past has 17 resulted in excessive announcements and withdrawals of de-aggregated 18 prefixes. This document discusses a means of accommodating scalable 19 de-aggregation of IPv6 prefixes for overlay networks using BGP. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 27, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Overview and Analysis . . . . . . . . . . . . . . . . . . . . 2 57 3. Opportunities and Limitations . . . . . . . . . . . . . . . . 3 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 7.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 The Border Gateway Protocol (BGP) [RFC4271] has well-known 70 limitations in terms of the numbers of routes that can be carried and 71 the stability of the routing system. This is especially true for 72 routing systems that include mobile nodes that frequently change 73 their network attachment points, which in the past have resulted in 74 excessive announcements and withdrawals of de-aggregated prefixes. 75 This document discusses a means of accommodating scalable de- 76 aggregation of IPv6 prefixes [RFC8200] for overlay networks using 77 BGP. 79 2. Overview and Analysis 81 As discussed in [I-D.ietf-rtgwg-atn-bgp] and 82 [I-D.templin-intarea-6706bis], the method for accommodating scalable 83 de-aggregation is to institute an overlay network instance of BGP 84 that is separate and independent from the global Internet BGP routing 85 system. The overlay is presented to the global Internet as a small 86 number of aggregated IPv6 prefixes (also known as Mobility Service 87 Prefixes (MSPs)) that never change. In this way, the Internet BGP 88 routing system sees only stable aggregated MSPs (e.g., 2001:db8::/32) 89 and is completely unaware of any de-aggregation or mobility-related 90 churn that may be occurring within the overlay. 92 The overlay consists of a core Autonomous System (AS) with core AS 93 Border Routers (c-ASBRs) that connect to stub ASes with stub ASBRs 94 (s-ASBRs) in a hub-and-spokes fashion. Mobile nodes associate with 95 nearby (i.e., regional) s-ASBRs for extended timeframes, and change 96 to new s-ASBRs only after significant topological or geographic 97 movements. Mobility-related changes between stub ASes are therefore 98 normally on a long-duration timescale. 100 The s-ASBRs use eBGP to announce de-aggregated Mobile Network 101 Prefixes (MNP) of mobile nodes (e.g., 2001:db8:1:2::/64) to their 102 neighboring c-ASBRs, but do not announce fine-grained mobility events 103 such as a mobile node moving to a new network attachment point. 104 Instead, mobile nodes coordinate with s-ASBRs using mobility 105 protocols such as MIPv6, LISP, AERO, etc. and s-ASBRs accommodate 106 these localized mobility events without disturbing the c-ASBRs. 108 The c-ASBRs originate "default" to their neighboring s-ASBRs but do 109 not announce any MNP routes. In this way, MNP announcements and 110 withdrawals are unidirectional from s-ASBRs to c-ASBRs only, thereby 111 suppressing BGP updates on the reverse path. The c-ASBRs in turn use 112 iBGP to maintain a consistent view of the full topology. 114 We expect that each c-ASBR should be able to carry at least as many 115 routes as can be carried by a typical core router in the global 116 public Internet BGP routing system. Since the number of active 117 routes in the Internet is quickly approaching 1 million (1M), we 118 therefore assume that each set of c-ASBRs can carry at least 1M MNP 119 routes which has been proven even for BGP running on lightweight 120 virtual machines. The method for increasing scaling therefore is to 121 divide the MSP into longer sub-MSPs, and to assign a different set of 122 c-ASBRs for each sub-MSP. 124 For example, the MSP 2001:db8::/32 could be sub-divided into sub-MSPs 125 such as 2001:db8:0010::/44, 2001:db8:0020::/44, 2001:db8:0030::/44, 126 etc. with each sub-MSP assigned to a different set of c-ASBRs. Each 127 s-ASBR peers with at least one member of each c-ASBR set and uses 128 route filters such that BGP updates are only sent to the c-ASBR(s) 129 that aggregate the specific sub-MSP. Then, assuming 1000 or more 130 sub-MSPs (each with its own set of c-ASBRs) the entire BGP overlay 131 routing system should be able to service 1 billion (1B) MSPs or more. 133 3. Opportunities and Limitations 135 Since a lightweight virtual machine (e.g., a Ubuntu linux image 136 running Quagga in the cloud) can service up to 1M MNPs using BGP, it 137 is conceivable that dedicated high-performance router hardware could 138 support even more - perhaps by a factor of 10 or more. With such 139 dedicated high-performance hardware, the numbers of MNPs that can be 140 serviced could be increased further. 142 The deployed numbers of s-ASBRs even for very large overlays should 143 not exceed the c-ASBR's capacity for BGP peering sessions. For 144 example, c-ASBRs should be capable of supporting a few thousands to a 145 few tens of thousands of BGP peering sessions but it is not known 146 whether more could be supported. 148 By the same token, the maximum number of c-ASBR sets should be based 149 on the number of BGP peering sessions each s-ASBR can comfortably 150 accommodate, since each s-ASBR must peer with each c-ASBR set. 152 Packets sent between end systems that associate with different 153 s-ASBRs would initially need to be forwarded through the core AS, 154 which presents a forwarding bottleneck. For this reason, some form 155 of route optimization is needed to significantly reduce congestion in 156 the core and preferably to also allow for direct end system to end 157 system communications without involving s-ASBRs. Since c-ASBRs 158 should be standard commercial off-the-shelf (COTS) dedicated high- 159 performance IPv6 routers, however, they should not be required to 160 participate in any ancillary route optimization signaling. The AERO 161 route optimization function honors this design consideration. 163 Further opportunities and limitations are discussed in more detail in 164 the references [I-D.ietf-rtgwg-atn-bgp][I-D.templin-intarea-6706bis]. 166 4. IANA Considerations 168 This document does not introduce any IANA considerations. 170 5. Security Considerations 172 Security considerations are discussed in the references. 174 6. Acknowledgements 176 This work is aligned with the FAA as per the SE2025 contract number 177 DTFAWA-15-D-00030. 179 This work is aligned with the NASA Safe Autonomous Systems Operation 180 (SASO) program under NASA contract number NNA16BD84C. 182 This work is aligned with the Boeing Information Technology (BIT) 183 MobileNet program. 185 7. References 187 7.1. Normative References 189 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 190 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 191 DOI 10.17487/RFC4271, January 2006, 192 . 194 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 195 (IPv6) Specification", STD 86, RFC 8200, 196 DOI 10.17487/RFC8200, July 2017, 197 . 199 7.2. Informative References 201 [I-D.ietf-rtgwg-atn-bgp] 202 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 203 Moreno, "A Simple BGP-based Mobile Routing System for the 204 Aeronautical Telecommunications Network", draft-ietf- 205 rtgwg-atn-bgp-01 (work in progress), January 2019. 207 [I-D.templin-intarea-6706bis] 208 Templin, F., "Asymmetric Extended Route Optimization 209 (AERO)", draft-templin-intarea-6706bis-03 (work in 210 progress), December 2018. 212 Appendix A. Change Log 214 << RFC Editor - remove prior to publication >> 216 Status as of 01/23/2018: 218 o -00 draft published 220 Author's Address 222 Fred L. Templin (editor) 223 Boeing Research & Technology 224 P.O. Box 3707 225 Seattle, WA 98124 226 USA 228 Email: fltemplin@acm.org