idnits 2.17.1 draft-meyer-rpo-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 192 has weird spacing: '...lies in the t...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7498 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) == Missing Reference: 'RFC 2119' is mentioned on line 34, but not defined == Missing Reference: 'VPLS' is mentioned on line 250, but not defined == Unused Reference: 'EXTCOMM' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC1958' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'VLPS' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 766, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AFI' == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-20 == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-00 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-bgpvpn-auto (ref. 'BGPVPN') -- Possible downref: Non-RFC (?) normative reference: ref. 'CLARK' == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-06 == Outdated reference: A later version (-04) exists of draft-marques-idr-flow-spec-00 -- Possible downref: Normative reference to a draft: ref. 'FLOW' -- Possible downref: Non-RFC (?) normative reference: ref. 'MULLER1999' ** Downref: Normative reference to an Experimental RFC: RFC 1075 ** Obsolete normative reference: RFC 1142 (Obsoleted by RFC 7142) ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 1958 ** Obsolete normative reference: RFC 2138 (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-00 ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Downref: Normative reference to an Informational RFC: RFC 3439 -- Possible downref: Non-RFC (?) normative reference: ref. 'SAFI' == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-vpls-bgp-00 -- Possible downref: Normative reference to a draft: ref. 'VPWS' -- Obsolete informational reference (is this intentional?): RFC 2028 (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 11 errors (**), 0 flaws (~~), 17 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Meyer (Editor) 3 Category Informational 4 Expires: April 2004 October 2003 6 Routing Protocol Overloading -- 7 Issues, Concerns, and Considerations 8 10 Status of this Document 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 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 The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC 2119]. 35 This document is a product of the RPO Design Team. Comments should 36 be addressed to the authors, or the mailing list at 37 rpo@lists.uoregon.edu. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 The Routing Protocol Overloading (RPO) design team was formed to 46 document the concerns and considerations surrounding the use of 47 Internet routing protocols for functions not directly related to 48 routing of IP packets within the Internet and IP networks. This 49 document is the output of that activity. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2. Scope of this Work . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Problem Statement. . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Risk, Interference, and Application Fit . . . . . . . . . . 6 57 3.1.1. Risk: Software Engineering . . . . . . . . . . . . . . . 7 58 3.1.2. Interference: Protocol Specification/Dynamic Behavior . 7 59 3.1.3. Application Fit. . . . . . . . . . . . . . . . . . . . . 7 60 4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.1. Layer 3 Routing Information . . . . . . . . . . . . . . . . 8 62 4.2. Reachability Information. . . . . . . . . . . . . . . . . . 8 63 4.3. Auxiliary (non-routing) Information . . . . . . . . . . . . 8 64 4.4. Address Family Identifier (AFI) . . . . . . . . . . . . . . 9 65 4.5. Subsequent Address Family Identifier (SAFI) . . . . . . . . 9 66 4.6. Network Layer Reachability. . . . . . . . . . . . . . . . . 9 67 4.7. Application . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.8. Routing Protocol. . . . . . . . . . . . . . . . . . . . . . 10 69 4.9. Fate Sharing. . . . . . . . . . . . . . . . . . . . . . . . 10 70 5. Architectural Models . . . . . . . . . . . . . . . . . . . . . 10 71 5.1. General Purpose Transport Infrastructure (GPT) Model. . . . 11 72 5.2. Special Purpose Transport Infrastructure (SPT) Model. . . . 11 73 6. Analyzing Risk and Interference. . . . . . . . . . . . . . . . 12 74 6.1. Risk: Code Impact, and Resource Sharing . . . . . . . . . . 12 75 6.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 13 76 6.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 13 77 6.1.2.1. Resource Sharing and Operating System Level Issues . 14 78 6.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 14 79 7. BGP and TCP Models: Risk and Interference. . . . . . . . . . . 15 80 7.1. Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 7.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 15 82 7.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 16 83 7.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 17 84 7.3. The TCP Model and Interference. . . . . . . . . . . . . . . 17 85 7.4. The BGP Model and Interference. . . . . . . . . . . . . . . 18 86 8. Operational Implications . . . . . . . . . . . . . . . . . . . 18 87 9. Conclusions and Recommendations. . . . . . . . . . . . . . . . 18 88 10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 18 89 11. Design Team . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 91 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 92 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 93 15. References. . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 15.1. Normative References . . . . . . . . . . . . . . . . . . . 21 95 15.2. Informative References . . . . . . . . . . . . . . . . . . 23 96 16. Editor's Address. . . . . . . . . . . . . . . . . . . . . . . 24 97 17. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 24 99 1. Introduction 101 The stability of the global Internet routing system has been the 102 subject of much research (see e.g., [RVBIB]) and discussion on 103 various IETF mailing lists [IETFOL]. Much of the research into the 104 routing system has centered around the analysis of the dynamics and 105 stability of the Border Gateway Protocol Version 4 [BGP] (hereafter 106 referred to as BGP). 108 However, while the theoretical properties of BGP remains a topic of 109 great interest, a more recent discussion has focused on effects of 110 the addition of new types of Network Layer Reachability Information, 111 or NLRI to BGP. In particular, the advent of two BGP attributes, 112 Multiprotocol Reachable NLRI (MP_REACH_NLRI), and Multiprotocol 113 Unreachable NLRI (MP_UNREACH_NLRI) [RFC2858], have made it possible 114 to encode and transport a wide variety of features and their 115 associated signaling using the BGP transport infrastructure. Examples 116 include IPv6 [RFC2460], flow specification rules [FLOW], virtual 117 private LAN services [VPLS], and virtual private Wire Service [VPWS]. 119 Finally, while this document outlines the concerns and issues 120 surrounding using the BGP infrastructure as a generic feature and 121 signaling transport, note that the similar concerns apply to the 122 Interior Gateway Protocols (IGPs) in common use (e.g., ISIS [RFC1142] 123 or OSPF [RFC2328]), although at this time there is no specific 124 material on IGPs. 126 The rest of this document is organized as follows: Section 2 outlines 127 the scope of this work. Section 3 introduces the problem statement 128 which is the focus of this document, section 4 provides definitions, 129 and section 5 outlines the main architectural models that are 130 discussed. The remaining sections discuss the the implications of 131 those models. 133 2. Scope of this Work 135 It is the intention of the RPO design team that this document serve 136 as a guide for both protocol designers and network operators, and 137 that an attempt is being made to shine a neutral light on the 138 implications (in the form of both benefits and offshoots) associated 139 with proceeding to employ routing protocols to enable additional 140 feature sets and functionality, or to design new mechanisms for 141 carriage of that information. 143 The issues, concerns and considerations discussed in this document 144 focus on the implications for BGP [BGP,RFC1771]. It is important to 145 note that similar issues will arise when considering generalizations 146 to the information that the IGPs carry. 148 3. Problem Statement 150 The advent of the MP_REACH_NLRI and MP_UNREACH_NLRI attributes, 151 combined with the resulting generalization to the BGP infrastructure, 152 have created the opportunity to use BGP to transport a wide variety 153 of data types and their associated signaling. The combination of a 154 BGP data type and its associated signaling is frequently called an 155 "application"; example applications include the IPv4 routing system, 156 flow specification rules [FLOW], auto-discovery mechanisms for Layer 157 3 VPNs [BGPVPN], and virtual private LAN services [VPLS]. 159 More recently, the discussion in the IETF community has focused on 160 the use of the BGP as a generalized feature transport infrastructure 161 [IETFOL]. The debate has recently intensified due to the emergence of 162 a new class of application that use the BGP infrastructure to 163 distribute information that is not directly related to inter-domain 164 routing. Examples of such applications include the use of the BGP 165 transport infrastructure to provide auto-discovery for Layer 3 VPNs 166 [BGPVPN] and the virtual private LAN services mentioned above. 168 3.1. Risk, Interference, and Application Fit 170 As mentioned above, much of the debate surrounding these new uses of 171 BGP transport infrastructure has focused on the potential tradeoffs 172 between the stability of the Internet routing system as effected by 173 the deployment of new applications, and the desire on the part of 174 service providers to rapidly deploy these new applications. These 175 tradeoffs have at times been described in terms of risk, 176 interference, and application fit. Risk models the software 177 engineering impact of new applications on a generic implementation, 178 while interference models the impact of new applications on protocol 179 definition and behavior. Finally, application fit models the 180 similarity between application's data and signaling requirements and 181 a specific distribution algorithm. Each is described below. 183 3.1.1. Risk: Software Engineering 185 Risk attempts to assess the robustness tradeoffs inherent in the 186 addition of new applications to a given implementation. In this case, 187 risk models the impact of generic software engineering issues on a 188 given implementation. These issues including the impact of new 189 applications on existing implementations and on the fate sharing 190 properties of those implementations. 192 A second aspect of risk lies in the trade-off of extending an 193 existing protocol (with the risks in 3.1.1), versus designing, 194 implementing, and deploying a new protocol. (more from Kireeti here). 196 3.1.2. Interference: Protocol Specification/Dynamic Behavior 198 Interference, on the other hand, models the potential for a new 199 application to adversely effect the operation of an existing 200 implementation, at the protocol level, by inadvertently introducing a 201 detrimental dependency of some kind. That is, is it possible that we 202 might, by some extension, break something fundamental to a protocol's 203 specification? For example, could we create a new state which 204 introduces an unanticipated deadlock situation to occur? Or could we 205 destabilize the distributed behavior of the protocol? Or might we 206 simply run out of the attributes or bits available (as happened, for 207 example, with RADIUS [RFC2138])? 209 3.1.3. Application Fit 211 Application fit refers to the matching of the requirements of the 212 data to be distributed with the underlying capabilities of a 213 distribution mechanism. Broadcast, multicast and unicast 214 distribution mechanisms in use today. When considering a 215 distribution mechanism (such as BGP), an important issue to address 216 is whether the behavior of the distribution mechanism matches the 217 distribution needs. For example, it is clearly inefficient to 218 broadcast data to all peers that is only required between two peers, 219 just as it is inefficient to create many unicasts of data that is 220 required by all peers when a single broadcast would do. 222 4. Definitions 224 4.1. Layer 3 Routing Information 226 Layer 3 routing information represents either link state information 227 or network reachability information. Link state information 228 represents Layer 3 adjacencies and topology. Link state routing 229 protocols, such as OSPF [RFC2328] and ISIS [RFC1142], flood link 230 state information throughout an IGP domain, so that each 231 participating router maintains an identical copy of a database that 232 is computed to reflect the complete Layer 3 topology. 234 Layer 3 reachability information represents Layer 3 networks that are 235 reachable through gateway routers. Distance/path vector routing 236 protocols, such as BGP, distribute Layer 3 reachability information 237 among routing domains. 239 Routers use both types of Layer 3 routing information (link state and 240 reachability) to produce IP forwarding tables. 242 For purposes of this discussion, "routing information" relates to the 243 Layer 3 inter-domain routing data traditionally carried by BGP. 245 4.2. Reachability Information 247 Reachability information refers to information describing some locale 248 of a network, along with how one can reach it, and perhaps also 249 containing attributes that indicate the suitability of the implied | 250 path to the network locale. An example is VPLS information [VPLS]. 252 4.3. Auxiliary (non-routing) Information 254 Auxiliary Information is any information that is exchanged by routers 255 which is neither Layer 3 routing information, nor reachability 256 information. For example, flow specification [FLOW] is auxiliary 257 information. 259 4.4. Address Family Identifier (AFI) 261 An Address Family contains addresses that share common structure and 262 semantics. An Address Family Identifier (AFI) uniquely identifies 263 each address family. Several routing protocol messages contain a 264 field that represents the AFI. The AFI identifies the address type 265 used by another data item contained in that message. The Routing 266 Information Protocol (RIP) [RFC2453], Distance Vector Multicast 267 Routing Protocol (DVMRP) [RFC1075], and BGP all employ the AFI field. 269 For example, the BGP MP_REACH_NLRI and MP_UNREACH_NLRI attributes 270 contain an AFI field. These BGP attributes also contain a NLRI field 271 that enumerates reachable or unreachable subnetworks corresponding to 272 the associated address family. The AFI field indicates the address 273 type by which reachable subnetworks are identified. When BGP is used 274 to distribute Layer 3 routing information, AFIs can indicate the 275 following address types: IPv4, IPv6, VPNv4 [RFC2547BIS]. When BGP is 276 used to distribute auxiliary information, AFIs can indicate other 277 address families. 279 4.5. Subsequent Address Family Identifier (SAFI) 281 A Subsequent Address Family Identifier (SAFI) is part of the BGP 282 MP_REACH_NLRI and MP_UNREACH_NLRI attributes. These BGP attributes 283 also contain a NLRI field that enumerates reachable or unreachable 284 subnetworks. The SAFI augments the AFI, carrying additional 285 information regarding networks enumerated in the NLRI field. 287 4.6. Network Layer Reachability 289 Network Layer Reachability Information, or NLRI is the data described 290 by the AFI/SAFI fields [AFI,SAFI]. While these concepts were 291 originally described for protocols such as DVMRP [RFC1075], the bulk 292 of the generalization of the NLRI described in this document derive 293 from the introduction to BGP of the MP_REACH_NLRI and MP_UNREACH_NLRI 294 attributes [RFC2858]. 296 4.7. Application 298 The term application is used in this document to refer to the 299 combination of a BGP data type and any signaling data that is carried 300 by BGP in support of the service the data type carries. The data type 301 is typically described an AFI/SAFI, while the actual data is 302 frequently contained in both NLRI and BGP community attributes 303 [RFC1997]. 305 4.8. Routing Protocol 307 A routing protocol is composed of two basic components: a data 308 distribution algorithm and a decision algorithm. A router typically 309 obtains Layer 3 routing information via its data distribution 310 algorithm, and it uses this information to produce an IP forwarding 311 table (by applying the protocol's decision algorithm to the received 312 routing data). Note that it is the use of BGP's data distribution 313 algorithm that is the focus of this document. However, when judging 314 application fit, one may also consider whether the decision 315 algorithms suit the application. 317 4.9. Fate Sharing 319 The fate sharing principle for end to end network protocols was first 320 enunciated by Dave Clark [CLARK]. As applied to software systems, 321 fate sharing refers to the sharing of common resources among a group 322 of applications. In our case, the particular "fate" of most interest 323 is the ability of one application, call it application A, to cause an 324 application with which it is fate sharing, call it application B, to 325 experience one or more faults due to faults in application A. In the 326 case of BGP, one way to reduce fate sharing is to run applications A 327 and B in seprate BGP sessions. 329 5. Architectural Models 331 In this section, we consider the two architectural models which are 332 motivated by salient questions considered in this document, namely: 334 Does the BGP distribution protocol suit a particular 335 application, and if it does, what are the effects on the global 336 routing system (if any) of carrying that application using the 337 BGP distribution protocol? 339 That is: 340 (i). Does the BGP distribution protocol suit a particular application? 342 (ii). What are the effects on the global routing system (if 343 any) of carrying that application using the BGP 344 distribution protocol? 346 These questions must be analyzed in terms of the the cost of protocol 347 and code development, as well as operational expense that may be 348 incurred by utilizing (or not utilizing) the mechanisms already 349 present in BGP. 351 Two models, describing alternate viewpoints, are examined in the 352 following sections. 354 5.1. General Purpose Transport Infrastructure (GPT) Model 356 The GPT model models BGP data distribution infrastructure as a 357 generic application transport mechanism. As such, it focuses on 358 "application fit", and assumes that the tradeoffs, both in terms of 359 risk and interference can be managed in an efficient manner. As a 360 result, the GTP models these issues not in terms of whether the 361 application and signaling data that need to be distributed are part 362 of some particular class (routing, in this case), but rather whether 363 the requirements for the distribution these attributes are similar 364 enough to the distribution mechanisms of BGP. In those cases when 365 they are sufficiently similar, BGP becomes a logical candidate for 366 such a transport infrastructure. Note that this is not because of the 367 nature of information distributed, but rather due to the similarity 368 in the transport requirements. There are other operational 369 considerations that make BGP a logical candidate, including its close 370 to ubiquitous deployment in the Internet (as well as in intra-nets), 371 its policy capabilities, and operator comfort levels with the 372 technology. 374 5.2. Special Purpose Transport Infrastructure (SPT) Model 376 The SPT model, on the other hand, models the BGP infrastructure as a 377 special purpose transport designed specifically to transport inter- 378 domain routing information. As such, it is more sensitive to risk and 379 interference than to application fit. 381 There are two basic arguments supporting the SPT model: The first is 382 based on the perceived risk profile of the fate sharing involved in 383 adding new applications to the BGP transport infrastructure. The 384 concern here is that the new applications being added to BGP will 385 cause software quality degrade, and hence destabilize the global 386 routing system. This position is based upon well understood software 387 engineering principles, and is strengthened long-standing experience 388 that there is a direct correlation between software features and bugs 389 [MULLER1999]. This concern is augmented by the fact that in many 390 cases, the existence of the code for these features, even if unused, 391 can also cause destabilization in the routing system, since in many 392 cases software faults cannot be isolated. 394 A second concern is based on interference arguments, notably that the 395 increase in complexity of BGP due to the number of data types that it 396 carries can also potentially destabilize the global routing system. 397 This concern is based on a wide range of concerns, including that the 398 interaction of BGP dynamics and current deployment practices are 399 poorly understood, and that the addition of non-routing data types 400 may adversely effect convergence and other scaling properties of the 401 global routing system. 403 6. Analyzing Risk and Interference 405 One way to frame the tradeoffs involved in analyzing risk is in terms 406 of the software engineering issues surrounding where an 407 implementation might demultiplex among applications. An 408 implementation's application demultiplexing point directly effects a 409 given implementation's risk profile due to its effects on existing 410 code, and on the system resources it requires to be shared among 411 those applications. 413 6.1. Risk: Code Impact, and Resource Sharing 415 For purposes of this discussion, we consider two models of 416 application demultiplexing: The first model, which we will call the 417 "BGP model", based on the current BGP model, provides a single point 418 for demultiplexing all applications (i.e., the AFI/SAFI). The BGP 419 model is and instantiation of the GPT model. 421 The second model, which we will call the "TCP model", provides an 422 application demultiplexing point above BGP (typically at the TCP port 423 level). In particular, in the BGP model, applications currently share 424 a common transport session, while the TCP model envisions one or more 425 applications per transport session. The TCP model an instantiation of 426 the SPT model. 428 Finally, note that these models can have very risk profiles with 429 respect to code impact and resource sharing. Some of the questions 430 relating to risk assessment are considered below. 432 6.1.1. Code Impact 434 In this section, we outline the high-level questions one might ask in 435 assessing the difference in risk between TCP model and the BGP model 436 based on their effect on an existing code base. 438 o Does the code below the demultiplexing point need to be 439 changed when a new application is added? 441 o Does the code in existing applications have to be changed when 442 a new application is added (that is, to what extent are the 443 applications decoupled)? 445 o Can the code in separate applications be developed, tested, 446 released, debugged and packaged independently from other 447 applications? 449 o Is there significant code below the demultiplexing point that 450 can be shared among all applications? 452 6.1.2. Resource Sharing 454 In this section, we outline the high-level questions one might ask in 455 assessing the difference in risk between TCP model and the BGP model 456 with respect to the requirements and properties of the system 457 resource sharing it they require. 459 o Do applications have to compete for socket buffers, and hence 460 have to potential to block or starve each other (at the TCP 461 port level)? 463 o Do applications have to compete for possible protocol-level 464 transport-related buffers and queues, and hence have the 465 potential to starve or block each other at the protocol 466 send/receive level? 468 o Do applications have to compete for a possible per-connection 469 processing time budget, hence have the potential to starve 470 each other at the intra-process scheduling level? 472 o Do applications have to compete for resources within the 473 network (e.g., bandwidth), when the protocol session spans 474 multiple hops ? 476 6.1.2.1. Resource Sharing and Operating System Level Issues 478 In this section, we outline the high-level questions one might ask in 479 assessing the difference in risk between TCP model and the BGP model 480 based on the effect on resource sharing at the operating system 481 level. 483 o Do applications share a common scheduling context? That is, 484 do applications have to compete for per-process scheduling 485 budgets? 487 o What is the degree of fate sharing between applications? 489 6.2. Interference 491 Interference models the potential for a new application to effect the 492 behavior of an existing application or applications. For example, in 493 the case of the Internet routing system, one might ask if a certain 494 application "interferes" with IPv4 Unicast routing by effecting some 495 aspect of its protocol operation (e.g., convergence time). 497 Interference in the Internet routing system has it is roots in the 498 observation that the routing system itself can be described as highly 499 self-dissimilar, with extremely different scales and levels of 500 abstraction. Complex systems with this property are susceptible 501 "coupling", which RFC 3439 [RFC3439] defines as follows: 503 The Coupling Principle states that as things get larger, they 504 often exhibit increased interdependence between components. 506 COROLLARY: The more events that simultaneously occur, the 507 larger the likelihood that two or more will interact. This 508 phenomenon has also been termed "unforeseen feature 509 interaction" [WILLINGER2002]. 511 That is, interference, if and where it occurs, has its roots protocol 512 complexity and is frequently the result of application coupling. 514 7. BGP and TCP Models: Risk and Interference 516 In this section, we analyze the BGP and TCP models risk and 517 interference. 519 7.1. Risk 521 As mentioned above, risk models the robustness tradeoffs around 522 generic software architecture and engineering associated with 523 protocol implementations, including the impact on impact on existing 524 protocol implementations, and on the fate sharing properties of those 525 implementations. In the following sections we consider these 526 components of risk for both the TCP and BGP models. 528 7.1.1. Code Impact 530 In this section, we outline the answers to the questions posed above. 532 o Does the code below the demultiplexing point need to be 533 changed when a new application is added? 535 Such code changes are unlikely to be required in the TCP model, 536 as the TCP model envisions that a new application will have a 537 new demultiplexing point (port). 539 In theory, the BGP model does not require new code below the 540 demultiplexing point either. Specifically, it is possible 541 to isolate code below the demultiplexing point with suitable 542 abstraction and constructs such as AFI/SAFI API registries. 544 o Does the code in existing applications have to be changed when 545 a new application is added (that is, to what extent are the 546 applications decoupled)? 548 The TCP model envisions application independence with respect 549 to demultiplexing point. As such, it is unlikely to require 550 such changes. However, it is important to note that good 551 software engineering practices encourage code reuse and 552 construction of general purpose libraries. As a result, if 553 applications share libraries and/or other code, the practical 554 independence decreases, and consequently risk increases. The 555 same analysis can be made for the BGP model, since in this case 556 we are already demultiplexing on the AFI/SAFI fields. 558 o Can the code in separate applications be developed, tested, 559 released, debugged and packaged independently from other 560 applications? 562 While this is theoretically possible in the TCP model (and 563 possibly harder in the BGP model) practice and experience has 564 shown that achieving this type of independence is difficult in 565 either model. 567 7.1.2. Resource Sharing 569 In this section, we address the questions raised above to assess the 570 difference in risk between TCP model and the BGP model based on the 571 effect on resource sharing considerations. 573 o Do applications have to compete for socket buffers, and hence 574 have to potential to block or starve each other (at the TCP 575 level)? 577 The TCP model does not require applications to compete for 578 socket level resources. It should also be possible to achieve 579 this type of application independence in the BGP model with 580 multi-session extensions to BGP (i.e., grouping of one or more 581 AFI/SAFI per TCP session). 583 o Do applications have to compete for possible protocol-level 584 transport-related buffers and queues, and hence have the 585 potential to starve or block each other at the protocol 586 send/receive level? 588 Again, while the TCP model does not require competition for 589 transport-level resources, it should be possible to achieve 590 similar behavior with the BGP model and multi-session 591 extensions. 593 o Do applications have to compete for a possible per-connection 594 processing time budget, hence have the potential to starve 595 each other at the intra-process scheduling level? 597 Applications written to the the TCP model should require this 598 type of resource competition. Note, however, that it should be 599 possible in the BGP model with multi-session extensions to 600 BGP. 602 o Do applications have to compete for resources within the 603 network (e.g., bandwidth), when the protocol session spans 604 multiple hops ? 606 Neither the TCP model nor the BGP model (again, with 607 multi-session extensions) should be require competition for 608 network resources in this case. 610 7.2. Interference 612 Interference concerns stem from the possibility that application 613 coupling can lead to the destabilization of the Internet routing 614 system in unanticipated and unexpected ways. In this section we 615 consider interference properties of the TCP and BGP models. 617 7.3. The TCP Model and Interference 618 7.4. The BGP Model and Interference 620 8. Operational Implications 622 9. Conclusions and Recommendations 624 10. Intellectual Property 626 The IETF takes no position regarding the validity or scope of any 627 intellectual property or other rights that might be claimed to 628 pertain to the implementation or use of the technology described in 629 this document or the extent to which any license under such rights 630 might or might not be available; neither does it represent that it 631 has made any effort to identify any such rights. Information on the 632 IETF's procedures with respect to rights in standards-track and 633 standards-related documentation can be found in BCP-11 [RFC2028]. 634 Copies of claims of rights made available for publication and any 635 assurances of licenses to be made available, or the result of an 636 attempt made to obtain a general license or permission for the use of 637 such proprietary rights by implementors or users of this 638 specification can be obtained from the IETF Secretariat. 640 The IETF invites any interested party to bring to its attention any 641 copyrights, patents or patent applications, or other proprietary 642 rights which may cover technology that may be required to practice 643 this standard. Please address the information to the IETF Executive 644 Director. 646 11. Design Team 648 The design team that produced this document consisted of Daniel 649 Awduche (awduche@awduche.com), Ron Bonica (Ronald.P.Bonica@mci.com), 650 Hank Kilmer (hank@rem.com), Kireeti Kompella (kireeti@juniper.net), 651 Chris Lewis (chrlewis@cisco.com), Danny McPherson (danny@tcb.net), 652 David Meyer (dmm@1-4-5.net) and Pete Whiting (pete@sprint.net). 654 12. Acknowledgments 656 David Ball, Eric Rosen, and Mark Townsley made many insightful 657 comments on earlier versions of this draft. 659 13. Security Considerations 661 This document specifies neither a protocol nor an operational 662 practice, and as such, it creates no new security considerations. 664 14. IANA Considerations 666 This document creates a no new requirements on IANA namespaces 667 [RFC2434]. 669 15. References 671 15.1. Normative References 673 [AFI] http://www.iana.org/assignments/address-family- 674 numbers 676 [BGP] Rekhter, Y, T.Li, and S. Hares, "A Border Gateway 677 Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-20.txt, 678 Work in Progress. 680 [BGPVPN] Ould-Brahim, H., E. Rosen, and Y. Rekhter, "Using 681 BGP as an Auto-Discovery Mechanism for 682 Provider-provisioned VPNs", 683 draft-ietf-l3vpn-bgpvpn-auto-00.txt, July, 684 2003. Work in Progress. 686 [CLARK] Clark, D., "Design Philosophy of the DARPA Internet 687 Protocols", Computer Communication Review, volume 688 25, number 1, January 1995. ISSN # 0146-4833. 690 [EXTCOMM] Sangali, S., D. Tappan, and Y. Rekhter, "BGP 691 Extended Communities Attribute", 692 draft-ietf-idr-bgp-ext-communities-06.txt. Work 693 in Progress. 695 [FLOW] Marques, P, et. al., "Dissemination of flow 696 specification rules", 697 draft-marques-idr-flow-spec-00.txt, June, 698 2003. Work in Progress. 700 [MULLER1999] Muller, R. et. al., "Control System Reliability 701 Requires Careful Software Installation 702 Procedures", International Conference on 703 Accelerator and Largeand Large Experimental 704 Physics Systems, 1999, Trieste, Italy. 706 [RFC1075] Waitzman, D., C. Partridge, and S. Deering, 707 "Distance Vector Multicast Routing Protocol", RFC 708 1075, November, 1988. 710 [RFC1142] Oran, D. Editor, "OSI IS-IS Intra-domain Routing 711 Protocol", RFC 1142, February, 1990. 713 [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway 714 Protocol 4 (BGP-4)", RFC 1771, March 1995. 716 [RFC1958] Carpenter, B., "Architectural principles of the 717 Internet", Editor. RFC 1958, June 1996. 719 [RFC1997] Chandra, R., P. Traina, and T. Li, "BGP 720 Communities Attribute", RFC 1997, August, 1996. 722 [RFC2138] Rigney, C., et. al., "Remote Authentication Dial 723 In User Service (RADIUS)", RFC 2138, April, 1997. 725 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April, 1998. 727 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November, 728 1998. 730 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 731 Version 6 (IPv6) Specification", RFC 2460, 732 December, 1998. 734 [RFC2547BIS] Rosen, E., et. al., "BGP/MPLS IP VPNs", 735 draft-ietf-l3vpn-rfc2547bis-00.txt, May, 2003, 736 Work in Progress. 738 [RFC2858] Bates, T., et. al., "Multiprotocol Extensions 739 for BGP-4", RFC 2858, June 2000. 741 [RFC3439] Bush, R. and D. Meyer, "Some Internet 742 Architectural Guidelines and Philosophy", RFC 743 3439, December, 2002. 745 [SAFI] http://www.iana.org/assignments/safi-namespace 747 [VLPS] Kompella, K., et. al. "Virtual Private LAN 748 Service", draft-ietf-l2vpn-vpls-bgp-00.txt, 749 Work in Progress. 751 [VPWS] Kompella, K. et.al. "Layer 2 VPNs Over Tunnels", 752 draft-kompella-ppvpn-l2vpn-03.txt, April 753 2003. Work in Progress. 755 15.2. Informative References 757 [IETFOL] https://www1.ietf.org/mailman/listinfo/routing-discussion 759 [RFC2119] Bradner, S., "Key words for use in RFCs to 760 Indicate Requirement Levels", RFC 2119, March, 761 1997. 763 [RFC2026] Bradner, S., "The Internet Standards Process -- 764 Revision 3", RFC 2026/BCP 9, October, 1996. 766 [RFC2028] Hovey, R. and S. Bradner, "The Organizations 767 Involved in the IETF Standards Process", RFC 768 2028/BCP 11, October, 1996. 770 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 771 Writing an IANA Considerations Section in RFCs", 772 RFC 2434/BCP 26, October 1998. 774 [RVBIB] http://www.routeviews.org/papers 776 [WILLINGER2002] Willinger, W., and J. Doyle, "Robustness and the 777 Internet: Design and evolution", 2002. 779 16. Editor's Address 781 David Meyer 782 Email: dmm@1-4-5.net 784 17. Full Copyright Statement 786 Copyright (C) The Internet Society (2003). All Rights Reserved. 788 This document and translations of it may be copied and furnished to 789 others, and derivative works that comment on or otherwise explain it 790 or assist in its implementation may be prepared, copied, published 791 and distributed, in whole or in part, without restriction of any 792 kind, provided that the above copyright notice and this paragraph are 793 included on all such copies and derivative works. However, this 794 document itself may not be modified in any way, such as by removing 795 the copyright notice or references to the Internet Society or other 796 Internet organizations, except as needed for the purpose of 797 developing Internet standards in which case the procedures for 798 copyrights defined in the Internet Standards process must be 799 followed, or as required to translate it into languages other than 800 English. 802 The limited permissions granted above are perpetual and will not be 803 revoked by the Internet Society or its successors or assigns. 805 This document and the information contained herein is provided on an 806 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 807 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 808 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 809 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 810 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.