idnits 2.17.1 draft-raszuk-ti-bgp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 24, 2010) is 5147 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 437, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 447, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgp-identifier-11 -- Obsolete informational reference (is this intentional?): RFC 5512 (Obsoleted by RFC 9012) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 K. Patel, Ed. 4 Intended status: Standards Track Cisco Systems 5 Expires: September 25, 2010 March 24, 2010 7 Transport Instance BGP 8 draft-raszuk-ti-bgp-01 10 Abstract 12 BGP4 protocol is a well established single standard of an inter- 13 domain routing and non-routing information distribution today. For 14 many applications it is also the protocol of choice to disseminate 15 various application based information intra-domain. It's popularity 16 and it's wide use has been effectively provided by it's reliable 17 transport, session protection as well as loop free build in 18 mechanism. 20 It has been observed in both intra-domain as well as inter-domain 21 applications that reliable information distribution is an extremely 22 desired tool for many services. Introduction of Multiprotocol 23 Extensions to BGP even further attracted various sorts of new 24 information to be carried over BGP4. 26 The observation proves that amount and nature of information carried 27 by BGP increases and diverges from the original goal of 28 interconnection for IP Internet Autonomous Systems at a rather fast 29 pace. 31 This draft proposes BGP to divide information into two broad 32 categories: Internet routing critical and non Internet routing 33 critical that would also include information carried by BGP which is 34 not related directly to routing. For the purpose of this document we 35 will refer to the latter case as second BGP instance. 37 This draft proposes that the current BGP infrastructure will continue 38 to be used to disseminate Internet routing related information while 39 non routing information or private routing data is recommended to be 40 carried by independent transport instance BGP. 42 Status of this Memo 44 This Internet-Draft is submitted to IETF in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF), its areas, and its working groups. Note that 49 other groups may also distribute working documents as Internet- 50 Drafts. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 The list of current Internet-Drafts can be accessed at 58 http://www.ietf.org/ietf/1id-abstracts.txt. 60 The list of Internet-Draft Shadow Directories can be accessed at 61 http://www.ietf.org/shadow.html. 63 This Internet-Draft will expire on September 25, 2010. 65 Copyright Notice 67 Copyright (c) 2010 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the BSD License. 80 Table of Contents 82 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 3. Today's operation . . . . . . . . . . . . . . . . . . . . . . 5 85 4. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 5. Transport Instance Proposal . . . . . . . . . . . . . . . . . 6 87 5.1. Router's resource separation . . . . . . . . . . . . . . . 7 88 5.2. Protocol changes . . . . . . . . . . . . . . . . . . . . . 7 89 5.3. AFI/SAFI numbering . . . . . . . . . . . . . . . . . . . . 7 90 5.4. BGP Identifier & BGP peering address . . . . . . . . . . . 8 91 5.5. IP Precedence . . . . . . . . . . . . . . . . . . . . . . 8 92 6. Summary of benefits . . . . . . . . . . . . . . . . . . . . . 9 93 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 9 94 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 96 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 98 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 99 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 102 1. Contributors 104 The below is the list of contributors to this document: 106 Bruno Decraene, France Telecom, 38 rue du General Leclerc, Issy 107 Moulineaux cedex 9, France, Email: 108 bruno.decraene@orange-ftgroup.com 110 Jakob Heitz, Ericsson, 100 Headquarters Dr., San Jose, CA 95134, 111 US Email: jheitz@redback.com 113 Thomas D. Nadeau, BT, 81 Newgate Street, London, EC1A 7AJ, United 114 Kingdom, Email: tom.nadeau@bt.com 116 Jie Dong, Huawei Technologies Co.,Ltd, KuiKe Building, No.9 Xinxi 117 Rd., Beijing, Hai-Dian District, 100085, P.R. China, Email: 118 dongjie_dj@huawei.com 120 Yoshinobu Matsuzaki, Internet Initiative Japan Inc., Jinbocho 121 Mitsui Bldg., 1-105 Kanda Jinbo-cho, Tokyo, Chiyoda-ku, Japan, 122 Email: maz@iij.ad.jp 124 2. Introduction 126 BGP4 [RFC4271] protocol is practically a single standard today for 127 the distribution of an inter-domain routing information. Under many 128 applications it is also used as the protocol of choice when 129 disseminating various application-based information intra-domain. 130 It's popularity and it's wide use has been effectively provided by 131 it's extensibility, reliable transport, session protection as well as 132 built in loop prevention mechanisms. 134 It has been observed in both intra-domain as well as inter-domain 135 applications that reliable information distribution is an extremely 136 desired tool for many applications. The introduction of 137 Multiprotocol extensions to BGP [RFC4760] made it appealing for new 138 kinds of information to be carried over BGP4. 140 While these extensions have proven to be useful, they however have 141 increased the load of information as well as the type of information 142 that BGP was originally envisioned to carry. 144 This draft proposes BGP to divide information into two broad 145 categories: Internet routing critical and non Internet routing 146 critical. The latter would also include information carried by BGP 147 which is not related directly to routing. For the purpose of this 148 document we will refer to the latter case as second BGP instance. 150 This draft proposes that the current BGP infrastructure will continue 151 to be used to disseminate Internet routing related information while 152 non Internet routing information or private routing data are 153 recommended to be carried by independent transport instance BGP. 155 For all currently defined and deployed AFI/SAFIs the mapping on which 156 plane of BGP (routing or transport) such information may be carried 157 is left to the choice of the implementation flexibility and the 158 operator's decision. For all subsequent new AFI/SAFIs it is 159 RECOMMENDED that implementations would have them supported on both 160 instances and that authors of new specifications provide a guidance 161 on which BGP plane they should be carried. It is expected that both 162 instances while running independently from each other will be 163 executed from the same bgp code base. 165 Authors would like to also observe that the idea of separation 166 routing from non routing related information to be carried over 167 routing protocol is not only limited to BGP. As example one could 168 notice proposed OSPF Transport Instance document 169 [I-D.acee-ospf-transport-instance] where the idea of safely reusing 170 reliable flooding has been recently proposed. We do admit that it 171 has also been some form of inspiration for this proposal. 173 Another point of view in favor of BGP instance separation is the 174 aspect of service protection. One could see BGP process responsible 175 for global routing due to it's global nature much more exposed to 176 control plane errors and attacks then potentially private only BGP 177 instance contained to one or few ASes, possibly under common 178 administration. In the same way one could also observe that by fully 179 separating global Internet BGP from any local BGP based services the 180 Internet itself can be fully isolated from any issues caused by local 181 service provider's services. 183 3. Today's operation 185 In today's networks BGP4 operates per BGP specification [RFC4271]. 186 This model of operation has proven to have number of disadvantages 187 when it comes to concurrent support of multiple applications when 188 amount of transported number of entries is already non trivial, when 189 is not bounded by application architecture and when it is 190 continuously growing. 192 There are many examples where major router vendors recommend to 193 separate route reflectors into disjoined clusters so Internet routes 194 are not affected by L3VPN routes and vice-versa. To put things into 195 right perspective one needs to observe that local per box scaling 196 numbers have already reached millions of VPN routes. Such scaling 197 provides real challenge for CPU as well as addressable memory space 198 in 32-bit operating systems when all of such applications use single 199 instance of BGP. 201 Another common complain is that by default all address families are 202 carried today over single TCP session and any major protocol error or 203 local system failure may results in full BGP instance reset affecting 204 all applications carried between such pair of BGP speakers. 206 4. Related work 208 To address the session separation without forcing users to manually 209 bound each session or group of session to a different BGP peering 210 address Multisession BGP [I-D.scudder-bgp-multisession] solution has 211 been proposed. It is our opinion that Multisession BGP is an 212 excellent tool to automatically bound selected group of applications 213 to different TCP BGP sessions. But this is only limited to session 214 separation. 216 All BGP OPEN messages would still end up going to the same BGP TCP 217 port number 179. Furthermore, all the incoming sessions are handled 218 by the same BGP process. Even in distributed BGP systems today 219 single speaker is still tasked to handle all address families 220 exchanged with a set of peers it is serving. 222 Multisession is an excellent way to easily separate different address 223 families and bound them to different TCP sessions within each BGP 224 instance. Such separation would be done at the micro level (session 225 level) while separation of BGP instances could be seen as macro level 226 division (BGP process/thread, memory space, internal queuing and 227 buffering etc ...). 229 5. Transport Instance Proposal 231 In order to minimize impact between different classes of applications 232 carried today or to be carried by BGP in the future to those of 233 critical nature for Internet connectivity, this draft proposes to run 234 two separate instances of BGP one for each of them. 236 The separation of concurrent, but not necessarily congruent BGP 237 instances will be complete. It will include both the router side and 238 network side. 240 5.1. Router's resource separation 242 There are many ways in modern router's operating systems to separate 243 threads or processes running under single operating system from each 244 other. 246 We will leave the details to the implementation, but it is assumed 247 that any implementation which complies with this document will allow 248 to differentiate the amount of control plane CPU processing time 249 allowed for specific BGP instance in it's scheduler's prioritization. 250 It is recommended that prioritization of one instance over another in 251 terms of CPU processing will be left to the local operator's 252 decision. The proposed separation may also very much allow to run 253 each BGP instance on separate core of multi core CPU or different RP 254 where applicable. 256 It is also observed that such instance isolation will allow to use 257 memory separation as well as different LC/RP communication channels/ 258 queues resulting in even greater instance isolation and minimizing 259 any potential impact between one another. 261 5.2. Protocol changes 263 The proposed here Transport Instance BGP does not require any changes 264 to BGP4 protocol mechanism, state machine, error handling or 265 operation. The exact same procedures and semantics apply in the same 266 way for routing instance as well as transport instance BGP. The 267 operational advantage in the instance separation is the ability to 268 apply different Hold Time interval in each instance fitting to the 269 operator's needs. 271 The only protocol change proposed in this document is the new TCP 272 port number Transport Instance BGP will be waiting on for BGP OPEN 273 Messages. Such new port number is to be allocated by IANA. 275 5.3. AFI/SAFI numbering 277 With the introduction of MP-BGP extension to BGP [RFC4760] protocol 278 has been enhanced with the ability to carry different sets of 279 information each separated by it's own AFI/SAFI value as listed in 280 IANA's Subsequent Address Family Identifiers (SAFI) registry. 282 For Transport Instance BGP authors decided not to create a new IANA 283 registry which would specify new SAFI pool. Instead we recommend 284 that single AFI/SAFI pool to be used by both BGP instances. 286 The main motivation for this choice is to prevent any confusion on 287 which SAFIs are allowed to be transported over which BGP instance as 288 well as to allow for customer configuration choice based on the 289 actual network needs and amount of information carried in each 290 address family. 292 Another valid reason for single SAFI pool and no SAFI bonding to any 293 particular BGP instance is the easy migration requirement from one 294 instance to the other in smooth and not service impacting fashion. 295 In order to perform such migration between instances operator will be 296 free to run during a migration window given address family on both 297 instances and when the target instance already populates the 298 application database with the data terminate the originally deployed 299 distribution of such information. Such process is bi-directional ie. 300 rollback can be also supported gracefully. 302 5.4. BGP Identifier & BGP peering address 304 When running both independent instances on the same platform question 305 arises on the recommended choice for BGP Identifier 306 [I-D.ietf-idr-bgp-identifier] as well as BGP peering address to be 307 used. 309 It needs to be observed that since via different BGP OPEN TCP port 310 number and then different session ports if only implementation allows 311 there is no requirement this specification would enforce to make any 312 of those different between both instances. 314 Never the less this draft would like to encourage that such freedom 315 of choice is given to the network administrator and that any dual 316 instance BGP implementation should accommodate it. 318 Another advantage of sharing the same peering address of BGP sessions 319 between instances is that in the event of operator's choice to use 320 fast failure detection tools like BFD [I-D.ietf-bfd-base] the same 321 event can be passed to both instances without any additional need to 322 run two parallel and independent BFD sessions. 324 5.5. IP Precedence 326 On the network side all today's BGP messages are send with IP 327 precedence value of Internetwork Control of 110000, which is used for 328 high-priority routing traffic. 330 Transport Instance BGP SHOULD use as default the same IP precedence, 331 but implementations MAY allow configuring a different one to reflect 332 the real purpose of the new BGP instance. 334 6. Summary of benefits 336 Below is a combined list of main benefits provided by Transport 337 Instance BGP: 339 Mutual isolation and independence from protocol or process 340 failures caused by any instance. 342 Independence in: CPU usage, memory space and internal router 343 buffering. 345 Different port for BGP OPEN messages allowing the same BGP 346 router_id or peering address sharing between instances. 348 Different and fully isolated TCP sessions between instances. Each 349 instance may still benefit from multisessions BGP proposal within 350 each instance. 352 Possibility of different IP precedence BGP message marking for 353 more fair and accurate PHB treatment. 355 Open platform for carrying non Internet routing information or 356 easy migration path with minimized risk to current BGP 357 infrastructure in new emerging Internet architecture's 358 hierarchical model. 360 The technique here is quite general. If, in the future, it is found 361 that there is a clearly definable need for yet more separate 362 transports, additional RFCs can be written defining the applicability 363 and the TCP/SCTP port number to be used. 365 7. Applications 367 As examples one may notice that carrying router names for easy 368 operational enhancement, carrying free form ADVISORY 369 [I-D.scholl-idr-advisory] Messages or adding flexibility to auto 370 discover IBGP peers [I-D.raszuk-idr-ibgp-auto-mesh] fit nicely into 371 Transport Instance BGP. 373 Another group of potential candidates for Transport Instance BGP 374 could be any type of auto discovery mechanism for other applications. 375 For example: L2VPN/VPLS or MVPN Auto Discovery 376 [I-D.ietf-l3vpn-2547bis-mcast] are possible candidates. 378 Along the same lines a service provider may also choose to use 379 Transport Instance BGP to distribute information about L3VPN route 380 targets as described in RFC4684 [RFC4684]. 382 Another class of applications perfectly fitting the separate BGP 383 instance model for it's global information distribution authors 384 foresee a mapping plane of identifiers to locators in the new 385 evolving internet architecture. As example LISP-ALT 386 [I-D.fuller-lisp-alt] or APT [I-D.jen-apt] are already calling to use 387 BGP as a mapping plane protocol to simplify initial deployment. 388 While it is foreseen that in the future those may migrate to better 389 distribution schemes for example LISP-DHT to get enough of initial 390 traction and momentum a Transport Instance BGP seems like a very good 391 match to the mapping plane requirements. 393 One may observe that Service Providers may choose to deploy a new 394 instance of BGP to carry their critical services (example L3VPNs) 395 over it for full isolation from Internet BGP. In such application 396 they will be able to prioritize such instance according to their 397 internal policy and offered services prioritization. 399 Last, but not least to recommend to be enabled on transport instance 400 BGP is RFC5512 [RFC5512] BGP Encapsulation SAFI and BGP Tunnel 401 Encapsulation Attribute. 403 8. Security considerations 405 Transport Instance BGP proposed in this document does not introduce 406 any new security concerns as compared to base BGP4 specification 407 [RFC4271]. Also all security work applicable to base routing 408 instance BGP does also apply as is to transport instance BGP. 410 9. IANA Considerations 412 The new TCP port number for Transport Instance BGP are to be 413 allocated by IANA from WELL KNOWN PORT NUMBERS registry. 415 bgp-ti xxx/tcp BGP Transport Instance 417 While routing instance BGP has also been allocated UDP port 179 418 authors see no particular reason for UDP port allocation for BGP. 420 The new SCTP port number for Transport Instance BGP are to be 421 allocated by IANA from WELL KNOWN PORT NUMBERS registry. 423 bgp-ti xxx/sctp BGP Transport Instance 425 Specification to use BGP over SCTP can be found here 426 [I-D.zhiyfang-fecai-bgp-over-sctp] 428 10. Acknowledgments 430 The authors would like to thank Randy Bush, Tom Scholl and Joel 431 Halpern for their valuable comments. 433 11. References 435 11.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, March 1997. 440 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 441 Protocol 4 (BGP-4)", RFC 4271, January 2006. 443 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 444 "Multiprotocol Extensions for BGP-4", RFC 4760, 445 January 2007. 447 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 448 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 449 May 2008. 451 11.2. Informative References 453 [I-D.acee-ospf-transport-instance] 454 Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Transport 455 Instance Extensions", 456 draft-acee-ospf-transport-instance-03 (work in progress), 457 February 2009. 459 [I-D.fuller-lisp-alt] 460 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 461 Alternative Topology (LISP+ALT)", draft-fuller-lisp-alt-05 462 (work in progress), February 2009. 464 [I-D.ietf-bfd-base] 465 Katz, D. and D. Ward, "Bidirectional Forwarding 466 Detection", draft-ietf-bfd-base-11 (work in progress), 467 January 2010. 469 [I-D.ietf-idr-bgp-identifier] 470 Chen, E. and J. Yuan, "AS-wide Unique BGP Identifier for 471 BGP-4", draft-ietf-idr-bgp-identifier-11 (work in 472 progress), February 2010. 474 [I-D.ietf-l3vpn-2547bis-mcast] 475 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 476 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 477 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work 478 in progress), January 2010. 480 [I-D.jen-apt] 481 Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 482 L. Zhang, "APT: A Practical Transit Mapping Service", 483 draft-jen-apt-01 (work in progress), November 2007. 485 [I-D.raszuk-idr-ibgp-auto-mesh] 486 Raszuk, R., "IBGP Auto Mesh", 487 draft-raszuk-idr-ibgp-auto-mesh-00 (work in progress), 488 June 2003. 490 [I-D.scholl-idr-advisory] 491 Scholl, T. and J. Scudder, "BGP Advisory Message", 492 draft-scholl-idr-advisory-00 (work in progress), 493 March 2009. 495 [I-D.scudder-bgp-multisession] 496 Scudder, J. and C. Appanna, "Multisession BGP", 497 draft-scudder-bgp-multisession-00 (work in progress), 498 November 2003. 500 [I-D.zhiyfang-fecai-bgp-over-sctp] 501 Fang, K. and F. Cai, "BGP-4 message transport over SCTP", 502 draft-zhiyfang-fecai-bgp-over-sctp-00 (work in progress), 503 May 2009. 505 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 506 R., Patel, K., and J. Guichard, "Constrained Route 507 Distribution for Border Gateway Protocol/MultiProtocol 508 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 509 Private Networks (VPNs)", RFC 4684, November 2006. 511 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 512 Subsequent Address Family Identifier (SAFI) and the BGP 513 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 515 Authors' Addresses 517 Robert Raszuk (editor) 518 Cisco Systems 519 170 West Tasman Drive 520 San Jose, CA 95134 521 US 523 Email: raszuk@cisco.com 525 Keyur Patel (editor) 526 Cisco Systems 527 170 West Tasman Drive 528 San Jose, CA 95134 529 US 531 Email: keyupate@cisco.com