idnits 2.17.1 draft-templin-rtgwg-scalable-bgp-01.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 29, 2019) is 1914 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) 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 G. Saccone 4 Intended status: Informational Boeing Research & Technology 5 Expires: August 2, 2019 G. Dawra 6 LinkedIn 7 A. Lindem 8 V. Moreno 9 Cisco Systems, Inc. 10 January 29, 2019 12 Scalable De-Aggregation for Overlays Using the Border Gateway Protocol 13 (BGP) 14 draft-templin-rtgwg-scalable-bgp-01.txt 16 Abstract 18 The Border Gateway Protocol (BGP) has well-known limitations in terms 19 of the numbers of routes that can be carried and stability of the 20 routing system. This is especially true when mobile nodes frequently 21 change their network attachment points, which in the past has 22 resulted in excessive announcements and withdrawals of de-aggregated 23 prefixes. This document discusses a means of accommodating scalable 24 de-aggregation of IPv6 prefixes for overlay networks using BGP. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 2, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Overview and Analysis . . . . . . . . . . . . . . . . . . . . 2 62 3. Opportunities and Limitations . . . . . . . . . . . . . . . . 4 63 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 9.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 The Border Gateway Protocol (BGP) [RFC4271] has well-known 77 limitations in terms of the numbers of routes that can be carried and 78 the stability of the routing system. This is especially true for 79 routing systems that include mobile nodes that frequently change 80 their network attachment points, which in the past have resulted in 81 excessive announcements and withdrawals of de-aggregated prefixes. 82 This document discusses a means of accommodating scalable de- 83 aggregation of IPv6 prefixes [RFC8200] for overlay networks using 84 BGP. 86 2. Overview and Analysis 88 As discussed in [I-D.ietf-rtgwg-atn-bgp] and 89 [I-D.templin-intarea-6706bis], the method for accommodating de- 90 aggregation is to institute an overlay network instance of BGP that 91 is separate and independent from the global Internet BGP routing 92 system. The overlay is presented to the global Internet as a small 93 number of aggregated IPv6 prefixes (also known as Mobility Service 94 Prefixes (MSPs)) that never change. In this way, the Internet BGP 95 routing system sees only stable aggregated MSPs (e.g., 2001:db8::/32) 96 and is completely unaware of any de-aggregation or mobility-related 97 churn that may be occurring within the overlay. 99 The overlay is operated by an Overlay Service Provider (OSP), and 100 consists of a core Autonomous System (AS) with core AS Border Routers 101 (c-ASBRs) that connect to stub ASes with stub ASBRs (s-ASBRs) in a 102 hub-and-spokes fashion. Mobile nodes associate with nearby (i.e., 103 regional) stub ASes for extended timeframes, and change to new stub 104 ASes only after movements of significant topological or geographical 105 distance. Mobility-related changes between stub ASes are therefore 106 normally infrequent. 108 The s-ASBRs use eBGP to announce de-aggregated Mobile Network 109 Prefixes (MNPs) of mobile nodes (e.g., 2001:db8:1:2::/64, etc.) to 110 their neighboring c-ASBRs, but do not announce fine-grained mobility 111 events such as a mobile node moving to a new network attachment 112 point. Instead, mobile nodes coordinate with stub ASes using 113 mobility protocols such as MIPv6, LISP, AERO, etc. and stub ASes 114 accommodate these localized mobility events without disturbing the 115 c-ASBRs. 117 The c-ASBRs originate "default" to their neighboring s-ASBRs but do 118 not announce any MNP routes. In this way, MNP announcements and 119 withdrawals are unidirectional from s-ASBRs to c-ASBRs only, thereby 120 suppressing BGP updates on the reverse path. The c-ASBRs in turn use 121 iBGP to maintain a consistent view of the full topology. BGP Route 122 Reflectors (RRs) [RFC4456] can also be used to support increased 123 c-ASBR scaling. 125 Each c-ASBR should be able to carry at least as many routes as a 126 typical core router in the global public Internet BGP routing system. 127 Since the number of active routes in the Internet is rapidly 128 approaching 1 million (1M), viable c-ASBRs must be capable of 129 carrying at least 1M MNP routes (this has been proven even for BGP 130 running on lightweight virtual machines). The method for increasing 131 scaling therefore is to divide the MSP into longer sub-MSPs, and to 132 assign a different set of c-ASBRs for each sub-MSP. 134 For example, the MSP 2001:db8::/32 could be sub-divided into sub-MSPs 135 such as 2001:db8:0010::/44, 2001:db8:0020::/44, 2001:db8:0030::/44, 136 etc. with each sub-MSP assigned to a different set of c-ASBRs. Each 137 s-ASBR peers with at least one member of each c-ASBR set and uses 138 route filters such that BGP updates are only sent to the c-ASBR(s) 139 that aggregate the specific sub-MSP. Then, assuming 1 thousand (1K) 140 or more sub-MSPs (each with its own set of c-ASBRs) the entire BGP 141 overlay routing system should be able to service 1 billion (1B) MNPs 142 or more. 144 3. Opportunities and Limitations 146 Since a lightweight virtual machine (e.g., a linux image running 147 quagga in the cloud) can service up to 1M MNPs using BGP, it is 148 likely that dedicated high-performance IPv6 router hardware could 149 support even more. With such dedicated high-performance hardware, 150 the number of MNPs could be increased further. 152 The deployed numbers of s-ASBRs even for very large overlays should 153 not exceed a c-ASBR's capacity for BGP peering sessions. For 154 example, c-ASBRs should be capable of servicing1K or more BGP peering 155 sessions, with the upper bound limited by keepalive and update 156 control messaging overhead. Conversely, s-ASBRs should be capable of 157 supporting even more sessions since they only receive keepalives and 158 only send updates for mobile nodes within their local stub ASes. 160 Mobile nodes should refrain from moving rapidly between stub ASes for 161 no good reason, since the objective is only to reduce routing stretch 162 due to movement of significant distances. OSPs could employ 163 disincentives such as surcharge penalties for gratuitous mobility, 164 but intentional abuse would also yield little reward since only the 165 bad actor (i.e., and not others) would be subject to MNP instability. 167 Packets sent between mobile nodes that associate with different stub 168 ASes would initially need to be forwarded through the core AS, which 169 presents a forwarding bottleneck. For this reason, a route 170 optimization function is needed to reduce congestion in the core. 171 Since c-ASBRs should be commercial off-the-shelf (COTS) dedicated 172 high-performance IPv6 routers, however, they should not be required 173 to participate directly in any out-of-band route optimization 174 signaling. Instead, route optimization should be coordinated by stub 175 AS network elements and/or the mobile nodes themselves. 177 4. Use Cases 179 Use cases include Unmanned Air Systems (UAS) in controlled and 180 uncontrolled airspaces, Intelligent Transportation Systems (ITS) in 181 urban air/ground mobility environments, aviation networks, enterprise 182 mobile device users, and cellular network users. Any other use cases 183 in which an OSP services large numbers of mobile nodes are also in 184 scope. 186 5. Implementation Status 188 The arrangement of stub and core ASes described in this document has 189 been implemented using standards-compliant linux operating systems 190 and BGP routing protocol implementations (i.e., quagga). No new code 191 was included, and all requirements were satisfied through standard 192 configuration options. 194 6. IANA Considerations 196 This document does not introduce any IANA considerations. 198 7. Security Considerations 200 Security considerations are discussed in the references. 202 8. Acknowledgements 204 This work is aligned with the FAA as per the SE2025 contract number 205 DTFAWA-15-D-00030. 207 This work is aligned with the NASA Safe Autonomous Systems Operation 208 (SASO) program under NASA contract number NNA16BD84C. 210 This work is aligned with the Boeing Information Technology (BIT) 211 MobileNet program. 213 9. References 215 9.1. Normative References 217 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 218 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 219 DOI 10.17487/RFC4271, January 2006, 220 . 222 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 223 Reflection: An Alternative to Full Mesh Internal BGP 224 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 225 . 227 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 228 (IPv6) Specification", STD 86, RFC 8200, 229 DOI 10.17487/RFC8200, July 2017, 230 . 232 9.2. Informative References 234 [I-D.ietf-rtgwg-atn-bgp] 235 Templin, F., Saccone, G., Dawra, G., Lindem, A., and V. 236 Moreno, "A Simple BGP-based Mobile Routing System for the 237 Aeronautical Telecommunications Network", draft-ietf- 238 rtgwg-atn-bgp-01 (work in progress), January 2019. 240 [I-D.templin-intarea-6706bis] 241 Templin, F., "Asymmetric Extended Route Optimization 242 (AERO)", draft-templin-intarea-6706bis-03 (work in 243 progress), December 2018. 245 Appendix A. Change Log 247 << RFC Editor - remove prior to publication >> 249 Changes from -00 to -01: 251 o added Route Reflectors 253 o introduced term "Overlay Service Provider (OSP)" 255 o removed estimate of number of routes for high-performance routers 257 o revised text on route optimization 259 o added use case and implementation sections 261 Status as of 01/23/2018: 263 o -00 draft published 265 Authors' Addresses 267 Fred L. Templin (editor) 268 Boeing Research & Technology 269 P.O. Box 3707 270 Seattle, WA 98124 271 USA 273 Email: fltemplin@acm.org 275 Greg Saccone 276 Boeing Research & Technology 277 P.O. Box 3707 278 Seattle, WA 98124 279 USA 281 Email: gregory.t.saccone@boeing.com 282 Gaurav Dawra 283 LinkedIn 284 USA 286 Email: gdawra.ietf@gmail.com 288 Acee Lindem 289 Cisco Systems, Inc. 290 USA 292 Email: acee@cisco.com 294 Victor Moreno 295 Cisco Systems, Inc. 296 USA 298 Email: vimoreno@cisco.com