idnits 2.17.1 draft-raszuk-mi-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 (October 22, 2018) is 2011 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: 'RFC2119' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-advisory' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-transport-instance' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC4684' is defined on line 343, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-08) exists of draft-raszuk-idr-bgp-auto-discovery-05 -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group R. Raszuk, Ed. 3 Internet-Draft Bloomberg LP 4 Intended status: Standards Track October 22, 2018 5 Expires: April 25, 2019 7 Multi Instance BGP 8 draft-raszuk-mi-bgp-00 10 Abstract 12 As the number of operational use cases of BGP grows there is demand 13 to increase the level of separation and processing independence 14 between various address families carried by BGP today. This document 15 augments base BGP specification in allowing local configuration of 16 BGP port number by the operator to run parallel fully disjoined BGP 17 instances allowing full processing separation between them. 19 While local BGP implementation may already assure BGP process or 20 thread robustnes the general aim here is to allow similar level of 21 groups of BGP address families independence when running BGP code on 22 general purpose hardware as well as x86 based route reflectors. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 25, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Today's operation . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Related work . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Multi Instance Proposal . . . . . . . . . . . . . . . . . . . 4 63 5.1. Protocol changes . . . . . . . . . . . . . . . . . . . . 5 64 5.2. BGP Identifier BGP peering address . . . . . . . . . . . 5 65 6. Summary of benefits . . . . . . . . . . . . . . . . . . . . . 5 66 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Security considerations . . . . . . . . . . . . . . . . . . . 6 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 11.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Contributors 77 The current document has been created based on parent document 78 Transport Instance BGP. Below is the list of contributors who 79 contributed to the previous document: 81 Keyur Patel, Arrcus Inc., 2077 Gateway Place Suite 400, San Jose, 82 CA, 95119, US, Email: keyur@arrcus.com 84 Bruno Decraene, France Telecom, 38 rue du General Leclerc, Issy 85 Moulineaux cedex 9, France, Email: bruno.decraene@orange- 86 ftgroup.com 88 Jakob Heitz, Cisco, 170 Tasman Dr, San Jose, CA 95134, US Email: 89 jheitz@cisco.com 91 Thomas D. Nadeau 93 Jie Dong, Huawei Technologies Co.,Ltd, KuiKe Building, No.9 Xinxi 94 Rd., Beijing, Hai-Dian District, 100085, P.R. China, Email: 95 dongjie_dj@huawei.com 96 Yoshinobu Matsuzaki, Internet Initiative Japan Inc., Jinbocho 97 Mitsui Bldg., 1-105 Kanda Jinbo-cho, Tokyo, Chiyoda-ku, Japan, 98 Email: maz@iij.ad.jp 100 2. Introduction 102 BGP4 [RFC4271] protocol is practically a single standard today for 103 the distribution of an inter-domain routing information. Under many 104 applications it is also used as the protocol of choice when 105 disseminating various application-based information intra-domain. 106 It's popularity and it's wide use has been effectively provided by 107 it's extensibility, reliable transport, session protection as well as 108 built in loop prevention mechanisms. 110 It has been observed in both intra-domain as well as inter-domain 111 applications that reliable information distribution is an extremely 112 desired tool for many applications. The introduction of 113 Multiprotocol extensions to BGP [RFC4760] made it appealing for new 114 kinds of information to be carried over BGP4. 116 While these extensions have proven to be useful, they however have 117 increased the load of information as well as the type of information 118 that BGP was originally envisioned to carry. As example carrying 119 link state LSDB and TED databases with BGP-LS RFC7752 [RFC5512] with 120 all its extensions. 122 This draft proposes to group together similar classes of information 123 carried in BGP and execute it by separate process on a per AFI/SAFI 124 basis. Each such BGP process would be fully independent from each 125 other and will listen on the TCP port as chosen by local 126 configuration by the operator. 128 This draft proposes that the current BGP infrastructure will continue 129 to be used to disseminate Internet routing related information and 130 will continue to listen on BGP TCP port 179. Non Internet routing 131 information or private routing data are recommended to be handled by 132 parallel BGP processes listening on their own TCP ports. 134 Another point of view in favor of BGP instance separation is the 135 aspect of service protection. One could see BGP process responsible 136 for global routing due to it's global nature much more exposed to 137 control plane errors and attacks then potentially private only BGP 138 instance contained to one or few ASes, possibly under common 139 administration. In the same way one could also observe that by fully 140 separating global Internet BGP from any local BGP based services the 141 Internet itself can be fully isolated from any issues caused by local 142 service provider's services. 144 3. Today's operation 146 In today's networks BGP4 operates per BGP specification [RFC4271]. 147 This model of operation has proven to have number of disadvantages 148 when it comes to concurrent support of multiple applications when 149 amount of transported number of entries is already non trivial, when 150 is not bounded by application architecture and when it is 151 continuously growing. 153 There are many examples where major router vendors recommend to 154 separate route reflectors into disjoined clusters so Internet routes 155 are not affected by L3VPN routes or BGP-LS data. To put things into 156 right perspective one needs to observe that local per box scaling 157 numbers have already reached millions of VPN routes. BGP-LS is 158 carrying more and more IGP and TE data almost every day. 160 4. Related work 162 To address the session separation without forcing users to manually 163 bound each session or group of session to a different BGP peering 164 address Multisession BGP [I-D.ietf-idr-bgp-multisession] solution has 165 been proposed. It is our opinion that Multisession BGP is a tool to 166 automatically bound group of applications to different TCP sessions 167 however code complexity of handling this automation has resulted in 168 significant complications and in number of BGP code bases has been 169 disabled or even removed. 171 Observation also needs to be made that in this model all BGP OPEN 172 messages would still end up going to the same BGP TCP port number 173 179. Furthermore, all the incoming sessions would be handled by the 174 same BGP process. Number of applications BGP carries data for today 175 call for much stronger separation including not just session but 176 processing isolation and operator's control. 178 Multisession if still required could be applicable within each major 179 BGP instance by providing fine granularity of session separation 180 within a given instance. 182 5. Multi Instance Proposal 184 In order to minimize impact between different classes of applications 185 carried today or to be carried by BGP in the future to those of 186 critical nature for Internet connectivity, this document proposes to 187 run separate instances of BGP for each of them. 189 The separation of concurrent, but not necessarily congruent BGP 190 instances will be complete. Each such instance can run the same or 191 different bgp code base. 193 5.1. Protocol changes 195 The proposed here Multi Instance BGP does not require any changes to 196 BGP4 protocol mechanism, state machine, error handling or operation. 197 The exact same procedures and semantics apply in the same way for 198 routing instance as well as for other instances of BGP. The 199 operational advantage in the instance separation is the ability to 200 apply different process level parameters and tuning for each launched 201 instance precisely fitting to the operator's needs. 203 The only protocol change proposed in this document is the ability to 204 specify locally TCP port number given BGP instance will be listening 205 on. 207 5.2. BGP Identifier BGP peering address 209 When running both independent instances on the same platform question 210 arises on the recommended choice for BGP Identifier [RFC6286] as well 211 as BGP peering address to be used. 213 It needs to be observed that since via different BGP OPEN TCP port 214 number and then different session ports if only implementation allows 215 there is no requirement this specification would enforce to make any 216 of those different between any instances. 218 Another advantage of sharing the same peering address of BGP sessions 219 between instances is that in the event of operator's choice to use 220 fast failure detection tools like BFD [RFC5880] the same event can be 221 passed to both instances without any additional need to run two 222 parallel and independent BFD sessions. 224 6. Summary of benefits 226 Below is a combined list of main benefits provided by Multi Instance 227 BGP: 229 Isolation and independence from protocol or process failures 230 caused by any instance. 232 Independence in: CPU usage, memory space and internal platform's 233 resources. 235 Different port for BGP OPEN messages allowing the same BGP 236 router_id or peering address sharing between instances. 238 Different and fully isolated TCP sessions between instances. Each 239 instance may still benefit from multisessions BGP proposal within 240 each instance. 242 Possibility of different IP precedence BGP message marking for 243 more fair and accurate PHB treatment. 245 7. Applications 247 Recent BGP extensions RFC7752 [RFC7752] define a way to carry link 248 state information over BGP transport. Fate sharing of such new type 249 of data with existing BGP address families is mutually risky. While 250 originally intended to be physically separated operational experience 251 proves that very often it is used just as an "add-on" to existing 252 data already carried over BGP including being handled by the same set 253 of BGP infrastructure (ex: route reflectors). Separating BGP-LS to 254 travel over disjoined TCP sessions will not only reduce mutual 255 impact, but also enable separate processing of it (ex: pinning to 256 different CPU core) even on the same BGP hardware. 258 Another group of potential candidates for Multi Instance BGP could be 259 any type of auto discovery mechanism for other applications or for 260 BGP itself [I-D.raszuk-idr-bgp-auto-discovery]. Other examples may 261 include: L2VPN/VPLS or MVPN Auto Discovery [RFC6513] as possible 262 candidates. 264 Another class of applications perfectly fitting the separate BGP 265 instance model for it's global information distribution authors 266 foresee a mapping plane of identifiers to locators in the new 267 evolving internet architecture. As example LISP-ALT [RFC6836] is 268 already calling to use BGP as a mapping plane protocol to simplify 269 initial deployment. While it is foreseen that in the future those 270 may migrate to better distribution schemes for example LISP-DHT to 271 get enough of initial traction and momentum a Multi Instance BGP 272 seems like a very good match to the mapping plane requirements. 274 One may observe that Service Providers may choose to deploy a new 275 instances of BGP to carry their critical services (example L3VPNs) 276 over it for full isolation from Internet BGP. In such application 277 they will be able to prioritize such instance according to their 278 internal policy and offered services prioritization. 280 8. Security considerations 282 Multi Instance BGP proposed in this document does not introduce any 283 new security concerns as compared to base BGP4 specification 284 [RFC4271]. Also all security work applicable to base routing 285 instance BGP does also apply as is to transport instance BGP. 287 9. IANA Considerations 289 This document presents no requirements to IANA. 291 10. Acknowledgments 293 The authors would like to thank Randy Bush, Tom Scholl and Joel 294 Halpern for their valuable comments provided to the parent document - 295 BGP Transport Instance. 297 11. References 299 11.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, 303 DOI 10.17487/RFC2119, March 1997, 304 . 306 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 307 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 308 DOI 10.17487/RFC4271, January 2006, 309 . 311 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 312 "Multiprotocol Extensions for BGP-4", RFC 4760, 313 DOI 10.17487/RFC4760, January 2007, 314 . 316 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 317 IANA Considerations Section in RFCs", RFC 5226, 318 DOI 10.17487/RFC5226, May 2008, 319 . 321 11.2. Informative References 323 [I-D.ietf-idr-advisory] 324 Scholl, T., Scudder, J., Steenbergen, R., and D. Freedman, 325 "BGP Advisory Message", draft-ietf-idr-advisory-00 (work 326 in progress), October 2009. 328 [I-D.ietf-idr-bgp-multisession] 329 Scudder, J., Appanna, C., and I. Varlashkin, "Multisession 330 BGP", draft-ietf-idr-bgp-multisession-07 (work in 331 progress), September 2012. 333 [I-D.ietf-ospf-transport-instance] 334 Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Transport 335 Instance Extensions", draft-ietf-ospf-transport- 336 instance-11 (work in progress), June 2014. 338 [I-D.raszuk-idr-bgp-auto-discovery] 339 Raszuk, R., Mitchell, J., Kumari, W., Patel, K., and J. 340 Scudder, "BGP Auto Discovery", draft-raszuk-idr-bgp-auto- 341 discovery-05 (work in progress), May 2016. 343 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 344 R., Patel, K., and J. Guichard, "Constrained Route 345 Distribution for Border Gateway Protocol/MultiProtocol 346 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 347 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 348 November 2006, . 350 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 351 Subsequent Address Family Identifier (SAFI) and the BGP 352 Tunnel Encapsulation Attribute", RFC 5512, 353 DOI 10.17487/RFC5512, April 2009, 354 . 356 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 357 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 358 . 360 [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP 361 Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, 362 June 2011, . 364 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 365 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 366 2012, . 368 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 369 "Locator/ID Separation Protocol Alternative Logical 370 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 371 January 2013, . 373 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 374 S. Ray, "North-Bound Distribution of Link-State and 375 Traffic Engineering (TE) Information Using BGP", RFC 7752, 376 DOI 10.17487/RFC7752, March 2016, 377 . 379 Author's Address 381 Robert Raszuk (editor) 382 Bloomberg LP 383 731 Lexington Ave 384 New York, NY 10022 385 US 387 Email: robert@raszuk.net