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