idnits 2.17.1 draft-ietf-grow-rift-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 199 has weird spacing: '...lies in the t...' == Line 205 has weird spacing: '...ference model...' -- 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 (January 2004) is 7378 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 33, but not defined == Missing Reference: 'VPLS' is mentioned on line 234, but not defined == Missing Reference: 'SOFTNOTIFY' is mentioned on line 437, but not defined == Missing Reference: 'REFRESH' is mentioned on line 798, but not defined == Unused Reference: 'EXTCOMM' is defined on line 876, but no explicit reference was found in the text == Unused Reference: 'L2TPv3' is defined on line 886, but no explicit reference was found in the text == Unused Reference: 'RFC1958' is defined on line 931, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'VLPS' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 980, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 984, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 987, 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-23 == 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' == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-11 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'MULLER1999' -- Possible downref: Normative reference to a draft: ref. 'MULTISESSION' == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-09 -- Possible downref: Normative reference to a draft: ref. 'RTCONST' ** 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) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** 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-02 -- Unexpected draft version: The latest known version of draft-kompella-ppvpn-l2vpn is -03, but you're referring to -04. -- 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: 12 errors (**), 0 flaws (~~), 25 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Meyer (Editor) 2 Category Informational 3 Expires: July 2004 January 2004 5 Operational Concerns and Considerations for Routing Protocol 6 Design -- Risk, Interference, and Fit (RIFT) 7 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC 2119]. 34 This document is a product of the RIFT Design Team. Comments should 35 be addressed to the authors, or the mailing list at 36 grow@lists.uoregon.edu. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 The Risk, Interference, and Fit (RIFT) design team was formed to 45 document the concerns and considerations surrounding the use of 46 Internet routing protocols for functions not directly related to 47 routing of IP packets within the Internet and IP networks. This 48 document is the output of that activity. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2. Scope of this Work . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Problem Statement. . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. Risk, Interference, and Application Fit (RIFT) . . . . . . 6 56 3.1.1. Risk: Software Engineering . . . . . . . . . . . . . . . 7 57 3.1.2. Interference: Protocol Specification/Dynamic Behavior . 7 58 3.1.3. Application Fit: Distribution Topology . . . . . . . . . 7 59 4. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.1. Reachability Information. . . . . . . . . . . . . . . . . . 8 61 4.2. Layer 3 Routing Information . . . . . . . . . . . . . . . . 8 62 4.3. Auxiliary (non-routing) Information . . . . . . . . . . . . 9 63 4.4. Address Family Identifier (AFI) . . . . . . . . . . . . . . 9 64 4.5. Subsequent Address Family Identifier (SAFI) . . . . . . . . 9 65 4.6. Network Layer Reachability. . . . . . . . . . . . . . . . . 9 66 4.7. Application . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.8. Routing Protocol. . . . . . . . . . . . . . . . . . . . . . 10 68 4.9. Fate Sharing. . . . . . . . . . . . . . . . . . . . . . . . 10 69 5. Architectural Models . . . . . . . . . . . . . . . . . . . . . 11 70 5.1. General Purpose Transport Infrastructure (GPT) Model. . . . 11 71 5.2. Special Purpose Transport Infrastructure (SPT) Model. . . . 12 72 6. Analyzing Risk and Interference. . . . . . . . . . . . . . . . 12 73 6.1. Risk: Code Impact, and Resource Sharing . . . . . . . . . . 13 74 6.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 13 75 6.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 13 76 6.1.2.1. Resource Sharing and Operating System Level Issues . 14 77 6.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 14 78 7. GTP and SPT Models: Risk and Interference. . . . . . . . . . . 15 79 7.1. Risk. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 7.1.1. Code Impact. . . . . . . . . . . . . . . . . . . . . . . 15 81 7.1.2. Resource Sharing . . . . . . . . . . . . . . . . . . . . 16 82 7.1.3. Multisession BGP . . . . . . . . . . . . . . . . . . . . 17 83 7.2. Interference. . . . . . . . . . . . . . . . . . . . . . . . 18 84 7.2.1. Multisession BGP . . . . . . . . . . . . . . . . . . . . 19 85 8. Application Fit. . . . . . . . . . . . . . . . . . . . . . . . 19 86 8.1. RFC 2547 Style VPNs . . . . . . . . . . . . . . . . . . . . 19 87 8.2. VPWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 8.3. VPLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 9. Operational Implications . . . . . . . . . . . . . . . . . . . 22 90 10. Other Models. . . . . . . . . . . . . . . . . . . . . . . . . 22 91 11. Conclusions and Recommendations . . . . . . . . . . . . . . . 22 92 12. Intellectual Property . . . . . . . . . . . . . . . . . . . . 22 93 13. Design Team . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 95 15. Security Considerations . . . . . . . . . . . . . . . . . . . 24 96 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 97 17. References. . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 17.1. Normative References . . . . . . . . . . . . . . . . . . . 25 99 17.2. Informative References . . . . . . . . . . . . . . . . . . 27 100 18. Editor's Address. . . . . . . . . . . . . . . . . . . . . . . 29 101 19. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 29 103 1. Introduction 105 The stability of the global Internet routing system has been the 106 subject of much research (see e.g., [RVBIB]) and discussion on 107 various IETF mailing lists [IETFOL]. Much of the research into the 108 routing system has centered around the analysis of the dynamics and 109 stability of the Border Gateway Protocol Version 4 [BGP] (hereafter 110 referred to as BGP). 112 However, while the theoretical properties of BGP remains a topic of 113 great interest, a more recent discussion has focused on effects of 114 the addition of new types of Network Layer Reachability Information, 115 or NLRI to BGP. In particular, the advent of two BGP attributes, 116 Multiprotocol Reachable NLRI (MP_REACH_NLRI), and Multiprotocol 117 Unreachable NLRI (MP_UNREACH_NLRI) [RFC2858], have made it possible 118 to encode and transport a wide variety of features and their 119 associated signaling using the BGP transport infrastructure. Examples 120 include include IPv6 [RFC2460], flow specification rules [FLOW], IP 121 VPNs [RFC2547BIS], Virtual Private LAN services [VPLS], Virtual 122 Private Wire Service [VPWS], and auto-discovery mechanisms for VPNs 123 in general [BGPVPN], 125 This document outlines the concerns and issues surrounding using the 126 BGP infrastructure as a generic feature and signaling transport. 127 However, the similar concerns apply to the Interior Gateway Protocols 128 (IGPs) in common use (e.g., ISIS [RFC1142] or OSPF [RFC2328]). 130 The rest of this document is organized as follows: Section 2 outlines 131 the scope of this work. Section 3 introduces the problem statement 132 which is the focus of this document, section 4 provides definitions, 133 and section 5 outlines the main architectural models that are 134 discussed. The remaining sections discuss the the implications of 135 those models. 137 2. Scope of this Work 139 It is the intention of the RIFT design team that this document serve 140 as a guide for both protocol designers and network operators. The 141 goal is to outline the implications associated with employing 142 existing routing protocols to enable additional feature sets and 143 functionality, as contrasted with designing new mechanisms to carry 144 those feature sets and functionalities. 146 The issues, concerns and considerations discussed in this document 147 focus on the implications for BGP [BGP,RFC1771]. It is important to 148 note that similar issues will arise when considering generalizations 149 to the information that the IGPs carry. 151 3. Problem Statement 153 The advent of the MP_REACH_NLRI and MP_UNREACH_NLRI attributes, 154 combined with the resulting generalization to the BGP infrastructure, 155 have created the opportunity to use BGP to transport a wide variety 156 of data types and their associated signaling. The combination of a 157 BGP data type and its associated signaling is frequently called an 158 "application"; example applications include the IPv4 and IPv6 159 [RFC2460] routing systems, flow specification rules [FLOW], auto- 160 discovery mechanisms for Layer 3 VPNs [BGPVPN], virtual private LAN 161 services [VPLS], and virtual private Wire Service [VPWS]. 163 More recently, the discussion in the IETF community has focused on 164 the use of the BGP as a generalized feature transport infrastructure 165 [IETFOL]. The debate has recently intensified due to the emergence of 166 a new class of application that uses the BGP infrastructure to 167 distribute information that is not directly related to inter-domain 168 routing. Examples of such applications include the use of the BGP 169 transport infrastructure to provide auto-discovery for IP VPNs 170 [RFC2547BIS], the virtual private LAN services mentioned above [VPLS] 171 and VPNs in general [BGPVPN]. 173 3.1. Risk, Interference, and Application Fit (RIFT) 175 As mentioned above, much of the debate surrounding these new uses of 176 the BGP transport infrastructure has focused on the potential 177 tradeoffs between the stability of the Internet routing system, as 178 effected by the deployment of new applications, and the desire on the 179 part of service providers to rapidly deploy these new applications, 180 and to reduce the operational cost by re-using existing protocols. 182 These tradeoffs have at times been described in terms of risk, 183 interference, and application fit. Risk models the software 184 engineering impact of new applications on a generic implementation, 185 while interference models the impact of new applications on protocol 186 definition and behavior. Finally, application fit models the 187 similarity between an application's data and signaling requirements 188 and a specific distribution algorithm. Each is described below. 190 3.1.1. Risk: Software Engineering 192 Risk attempts to assess the robustness tradeoffs inherent in the 193 addition of new applications to a given implementation. That is, risk 194 models the impact of generic software engineering issues on a given 195 implementation. These issues include the impact of new applications 196 on existing implementations and on the fate sharing properties of 197 those implementations. 199 A second aspect of risk lies in the trade-off of extending an 200 existing protocol versus designing, implementing, and deploying a new 201 protocol. 203 3.1.2. Interference: Protocol Specification/Dynamic Behavior 205 Interference models the potential for a new application to adversely 206 effect the operation of an existing implementation at the protocol 207 level, by inadvertently introducing a detrimental dependency of some 208 kind. That is, an application is said to "interfere" with an existing 209 application if, by virtue of the application's protocol extension(s), 210 one or more fundamental properties of the protocol's operation are 211 detrimentally altered. For example, could we create a new state which 212 introduces an unanticipated deadlock situation to occur? Or could we 213 destabilize the distributed behavior of the protocol? Or might we 214 simply run out of the attributes or bits available (as happened, for 215 example, with RADIUS [RFC2138])? 217 3.1.3. Application Fit: Distribution Topology 219 Application fit refers to how closely the requirements of the data to 220 be distributed match the underlying capabilities of a distribution 221 mechanism. For example, it is clearly inefficient to broadcast data 222 to all peers that is only required between two peers, just as it is 223 inefficient to unicast (replicate) data that is required by all peers 224 when a single broadcast would do. 226 4. Definitions 228 4.1. Reachability Information 230 Reachability information refers to information describing some part 231 of a network, along with how one can reach it, and perhaps also 232 containing attributes of the implied path to the network locale. 233 Typically, this information pertains to IP routing information; an 234 example of non-IP reachability is VPLS information [VPLS]. 236 4.2. Layer 3 Routing Information 238 Layer 3 routing information represents either link state information 239 or network reachability information. Link state information 240 represents Layer 3 adjacencies and topology. Link state routing 241 protocols, such as OSPF [RFC2328] and ISIS [RFC1142], flood link 242 state information throughout an IGP domain, so that each 243 participating router maintains an identical copy of a database that 244 is computed to reflect the complete Layer 3 topology. 246 Layer 3 reachability information expressed as an IP address prefix 247 represents the set of destinations (systems) whose IP addresses are 248 contained in the IP address prefix. Distance/path vector routing 249 protocols, such as BGP, distribute Layer 3 reachability information 250 among routing domains. 252 Routers use both types of Layer 3 routing information (link state and 253 reachability) to produce IP forwarding tables. That, is, for purposes 254 of this discussion, "routing information" relates to the Layer 3 255 inter-domain routing data traditionally carried by BGP. 257 Finally, if one defines routing information as "information used to 258 forward packets", combined with the above definition of reachability 259 information, then we can consider information such as described in 260 [FLOW] (for example) to be routing information (since it is 261 attempting to add a level of granularity to how an 'aggregate' is 262 defined). That is, [FLOW] intends to complement to the existing 263 routing information, and the flow information is dependent on IP4 264 unicast reachability advertised by the same neighbor. 266 4.3. Auxiliary (non-routing) Information 268 Auxiliary Information is any information that is exchanged by routers 269 which is neither Layer 3 routing information, nor reachability 270 information. IS-IS hostname TLVs are an example of Axillary 271 information [RFC1142]. 273 4.4. Address Family Identifier (AFI) 275 An Address Family contains addresses that share common structure and 276 semantics. An Address Family Identifier (AFI) uniquely identifies 277 each address family. Several routing protocol messages contain a 278 field that represents the AFI. The AFI identifies the address type 279 used by another data item contained in that message. The Routing 280 Information Protocol (RIP) [RFC2453], Distance Vector Multicast 281 Routing Protocol (DVMRP) [RFC1075], and BGP all employ the AFI field. 283 For example, the BGP MP_REACH_NLRI and MP_UNREACH_NLRI attributes 284 contain an AFI field. These BGP attributes also contain a NLRI field 285 that enumerates reachable or unreachable subnetworks corresponding to 286 the associated address family. The AFI field indicates the address 287 type by which reachable subnetworks are identified. When BGP is used 288 to distribute Layer 3 routing information, AFIs can indicate the 289 following address types: IPv4, IPv6, VPNv4 [RFC2547BIS]. When BGP is 290 used to distribute auxiliary information, AFIs can indicate other 291 address families. 293 4.5. Subsequent Address Family Identifier (SAFI) 295 A Subsequent Address Family Identifier (SAFI) is part of the BGP 296 MP_REACH_NLRI and MP_UNREACH_NLRI attributes. These BGP attributes 297 also contain a NLRI field that enumerates reachable or unreachable 298 subnetworks. The SAFI augments the AFI, carrying additional 299 information regarding networks enumerated in the NLRI field. 301 4.6. Network Layer Reachability 303 Network Layer Reachability Information, or NLRI is the data described 304 by the AFI/SAFI fields [AFI,SAFI]. While these concepts were 305 originally described for protocols such as DVMRP [RFC1075], the bulk 306 of the generalization of the NLRI described in this document derives 307 from the introduction of the MP_REACH_NLRI and MP_UNREACH_NLRI 308 attributes to BGP [RFC2858]. 310 4.7. Application 312 The term application is used in this document to refer to the 313 combination of a BGP data type and any signaling data that is carried 314 by BGP in support of the service the data type carries. The data type 315 is typically described in an AFI/SAFI, while the actual data is 316 frequently contained in both NLRI and BGP community attributes 317 [RFC1997]. 319 4.8. Routing Protocol 321 A routing protocol is composed of two basic components: a data 322 distribution algorithm and a decision algorithm. A router typically 323 obtains Layer 3 routing information via its data distribution 324 algorithm, and it uses this information to produce an IP forwarding 325 table (by applying the protocol's decision algorithm to the received 326 routing data). Note that it is the use of BGP's data distribution 327 algorithm that is the focus of this document. However, when judging 328 application fit, one may also consider whether the decision 329 algorithms suit the application. 331 4.9. Fate Sharing 333 The fate sharing principle for end to end network protocols was first 334 enunciated by Dave Clark [CLARK]. As applied to software systems, 335 fate sharing refers to the sharing of common resources among a group 336 of applications. In our case, the particular "fate" of most interest 337 is the ability of one application, call it application A, to cause an 338 application with which it is fate sharing, call it application B, to 339 experience one or more faults due to faults in application A. Fate- 340 sharing can exist at many levels, including between modules on a 341 system, between routing protocols, between sessions of a routing 342 protocols such as BGP, or between applications within a routing 343 protocol. 345 5. Architectural Models 347 In this section, we consider the two architectural models which are 348 motivated by salient questions considered in this document, namely: 350 (i). Does the BGP distribution protocol suit a particular 351 application (i.e., does an application fit the BGP 352 distribution protocol)? 354 (ii). What are the effects on the global routing system (if 355 any) of carrying that application using the BGP distribution 356 protocol? 358 These questions must be analyzed in terms of the cost of protocol and 359 code development, as well as in terms of the operational expense that 360 may be incurred by utilizing (or not utilizing) the mechanisms 361 already present in BGP. 363 Two models, describing alternate viewpoints, are examined in the 364 following sections. 366 5.1. General Purpose Transport Infrastructure (GPT) Model 368 The GPT model models BGP data distribution infrastructure as a 369 generic application transport mechanism. As such, it focuses on 370 application fit, and assumes that the tradeoffs, both in terms of 371 risk and interference can be managed in an efficient manner. As a 372 result, the GTP models these issues not in terms of whether the 373 application and signaling data that need to be distributed are part 374 of some particular class (routing, in this case), but rather whether 375 the requirements for the distribution these attributes are similar 376 enough to the distribution mechanisms of BGP. In those cases when 377 distribution requirements are sufficiently similar, BGP can be a 378 logical candidate for a transport infrastructure. Note that this is 379 not because of the nature of information distributed, but rather due 380 to the similarity in the transport requirements. There are of course 381 other operational considerations that make BGP a logical candidate, 382 including its close to ubiquitous deployment in the Internet (as well 383 as in intra-nets), its policy capabilities, and operator comfort 384 levels with the technology. 386 5.2. Special Purpose Transport Infrastructure (SPT) Model 388 The SPT model, on the other hand, models the BGP infrastructure as a 389 special purpose transport designed specifically to transport inter- 390 domain routing information. As such, it is more sensitive to risk and 391 interference than to application fit. 393 There are two basic arguments supporting the SPT model: The first is 394 based on the perceived risk profile involved in adding new 395 applications to the BGP transport infrastructure or new features to 396 existing BGP applications. The concern here is that changes to BGP 397 implementations will cause software quality to degrade, and hence 398 destabilize the global routing system. This position is based upon 399 well understood software engineering principles, and is strengthened 400 by long-standing experience that there is a direct correlation 401 between software features and software stability [MULLER1999]. This 402 concern is augmented by the fact that in many cases, the existence of 403 the code for these features, even if unused, can also cause 404 destabilization in the routing system, since in many cases software 405 faults cannot be isolated. 407 A second concern is based on interference arguments, notably that the 408 increase in complexity of BGP due to the number of data types that it 409 carries can also potentially destabilize the global routing system. 410 This concern is based on a wide range of concerns, including the fact 411 that the interaction of BGP dynamics and current deployment practices 412 are poorly understood, and that the addition of non-routing data 413 types may adversely effect convergence and other scaling properties 414 of the global routing system. 416 6. Analyzing Risk and Interference 418 One way to frame the tradeoffs involved in a model's risk profile is 419 in terms of the software engineering issues surrounding where an 420 implementation might demultiplex among applications. The important 421 point here is that an implementation's choice of demultiplexing point 422 directly affects the implementation's risk profile due to its effects 423 on existing code, and on the system resources it requires to be 424 shared among those applications. 426 6.1. Risk: Code Impact, and Resource Sharing 428 For purposes of this discussion, then, we consider the risk profile 429 of the SPT and GPT models with respect to their application 430 demultiplexing point. The GPT model typically provides a single point 431 for demultiplexing all applications (i.e., the AFI/SAFI). On the 432 other hand, the SPT model, provides an application demultiplexing 433 point above BGP (typically at the TCP port level). That is, in the 434 GPT model, applications typically share a common transport session, 435 while the SPT model generally envisions one or more applications per 436 transport session (see section 7.1.3 for a discussion of the impact 437 of multisession BGP [MULTISESSION,SOFTNOTIFY] on this taxonomy). 439 Finally, note that these models can have very different risk profiles 440 with respect to code impact and resource sharing. Some of the 441 questions relating to risk assessment are considered below. 443 6.1.1. Code Impact 445 In this section, we outline the high-level questions one might ask in 446 assessing the difference in risk between GPT model and the SPT model 447 based on their effect on an existing code base. 449 o Does the code below the demultiplexing point need to be 450 changed when a new application is added? 452 o Does the code in existing applications have to be changed when 453 a new application is added (that is, to what extent are the 454 applications decoupled)? 456 o Can the code in separate applications be developed, tested, 457 released, debugged and packaged independently from other 458 applications? 460 o Is there significant code below the demultiplexing point that 461 can be shared among all applications? 463 6.1.2. Resource Sharing 465 In this section, we outline the high-level questions one might ask in 466 assessing the difference in risk between GPT model and the SPT model 467 with respect to the requirements and properties of the system 468 resource sharing they require. In particular: 470 o Do applications have to compete for socket buffers, and hence 471 have the potential to block or starve each other (at the TCP 472 port level)? 474 o Do applications have to compete for possible protocol-level 475 transport-related buffers and queues, and hence have the 476 potential to starve or block each other at the protocol 477 send/receive level? 479 o Do applications have to compete for a possible per-connection 480 processing time budget, hence have the potential to starve 481 each other at the intra-process scheduling level? 483 6.1.2.1. Resource Sharing and Operating System Level Issues 485 In this section, we outline the high-level questions one might ask in 486 assessing the difference in risk between GPT model and the SPT model 487 based on the affect on resource sharing at the operating system 488 level. In particular: 490 o Do applications share a common scheduling context? That is, 491 do applications have to compete for per-process scheduling 492 budgets? 494 o What is the degree of fate sharing between applications? 496 6.2. Interference 498 Interference models the potential for an application to affect the 499 behavior of an existing application or applications. For example, in 500 the case of the Internet routing system, one might ask if a certain 501 application "interferes" with IPv4 Unicast routing by affecting some 502 aspect of its protocol operation (e.g., convergence time). 504 Interference in the Internet routing system has its roots in the 505 observation that the routing system itself can be described as highly 506 self-dissimilar, with extremely different scales and levels of 507 abstraction. Complex systems with this property are susceptible to 508 "coupling", which RFC 3439 [RFC3439] defines as follows: 510 The Coupling Principle states that as things get larger, they 511 often exhibit increased interdependence between components. 513 COROLLARY: The more events that simultaneously occur, the larger 514 the likelihood that two or more will interact. This phenomenon 515 has also been termed "unforeseen feature interaction" 516 [WILLINGER2002]. 518 That is, interference, if and where it occurs, has its roots in 519 complexity and is frequently the result of application coupling. 521 7. GTP and SPT Models: Risk and Interference 523 In this section, we analyze the risk and interference profiles of the 524 SPT and GPT models. 526 7.1. Risk 528 As mentioned above, risk models the robustness tradeoffs around 529 generic software architecture and engineering associated with 530 protocol implementations, including the impact on existing protocol 531 implementations, and on the fate sharing properties of those 532 implementations. In the following sections we consider these 533 components of risk for both the GPT and SPT models. 535 7.1.1. Code Impact 537 In this section, we outline the answers to the questions posed above. 539 o Does the code below the demultiplexing point need to be 540 changed when a new application is added? 542 In theory, such code changes are unlikely to be required in 543 the SPT model, as the SPT model envisions that a new 544 application will have a new demultiplexing point (port). 546 The GPT model does not by definition require new code below 547 the demultiplexing point either. Specifically, it should in 548 theory be possible to isolate code below the demultiplexing 549 point with suitable abstraction and constructs such as 550 AFI/SAFI API registries. 552 o Does the code in existing applications have to be changed when 553 a new application is added (that is, to what extent are the 554 applications decoupled)? 556 The SPT model envisions application independence with respect to 557 demultiplexing point. As such, it is unlikely to require such 558 changes. However, it is important to note that good software 559 engineering practices encourage code reuse and construction of 560 general purpose libraries. As a result, if applications share 561 libraries and/or other code, the practical independence 562 decreases, and consequently risk increases. The same analysis 563 can be made for the GPT model, since in this case we are already 564 demultiplexing on the AFI/SAFI fields. 566 o Can the code in separate applications be developed, tested, 567 released, debugged and packaged independently from other 568 applications? 570 While this is theoretically possible in the SPT model (and 571 possibly more difficult in the GPT model) practice and 572 experience has shown that achieving this type of independence is 573 difficult in either model. 575 7.1.2. Resource Sharing 577 In this section, we address the questions raised above to assess the 578 difference in risk between GPT model and the SPT model based on the 579 effect on resource sharing considerations. 581 o Do applications have to compete for socket buffers, and hence 582 have the potential the to block or starve each other (at the GPT 583 level)? 585 The SPT model does not require applications to compete for 586 socket level resources. It should also be possible to achieve 587 this type of application independence in the GPT model with 588 multisession BGP. 590 o Do applications have to compete for possible protocol-level 591 transport-related buffers and queues, and hence have the 592 potential to starve or block each other at the protocol 593 send/receive level? 595 Again, while the SPT model does not require competition for 596 transport-level resources, it should be possible to achieve 597 similar behavior with multisession BGP. 599 o Do applications have to compete for a possible per-connection 600 processing time budget, hence have the potential to starve 601 each other at the intra-process scheduling level? 603 Applications written to the the SPT model should not require 604 this type of resource competition. It should also be possible to 605 reduce this type of resource competition with multisession BGP. 607 o Do applications have to compete for resources within the 608 network (e.g., bandwidth), when the protocol session spans 609 multiple hops ? 611 Neither the SPT model nor the GPT model (again, with 612 multisession BGP) should require competition for network 613 resources in this case. 615 7.1.3. Multisession BGP 617 Suppose that one makes the simplifying assumption that a GPT 618 implementation's risk profile is dominated by the probability that an 619 error in one AFI/SAFI stream will cause some subset of the other 620 AFI/SAFI streams to malfunction (e.g., reset). In this case, risk 621 might be characterized as a function of the model and the number of 622 AFI/SAFI carried. Given this simplification, the risk profile looks 623 loosely like 625 Risk = f(Model, |{AFI,SAFI}|) 627 where 629 f:{GPT, SPT} X |{AFI, SAFI}| -> N 631 Note that we assume that 633 f(SPT,n) = O(f(GPT,n)) 634 where 636 O(f) = {g:N->R | there exists c > 0 and n such that g(n) < c*f(n)} 638 That is, that the SPT risk profile is bounded by the GPT risk 639 profile. Clearly, the existence of such an upper bound is an integral 640 aspect of any argument favoring the SPT model. 642 Note that for the SPT model, we can think of the number of AFI/SAFI 643 that a single session carries as a small constant, call it k. k will 644 typically be small (close to 1), since by definition the SPT model 645 envisions a small number of AFI/SAFI per session (e.g., for AFI/SAFI 646 IPv4/unicast and IPv6/unicast, k = 2). 648 When formulated in this way, one can see that one objective of 649 multisession BGP is to find a value, call it g, such that 651 f(GPT, g) ~ f(SPT,k), for small values of k (i.e., k close to 1) 653 where 655 A(n) ~ B(k) ==> A(n) = B(k) + h(n), h(n) >= 0 657 That is, A(n) is approaches B(k) 659 In this case, g is the size of the multisession AFI/SAFI grouping, 660 and for small values of g, multisession BGP can have a risk profile 661 that looks very much like the SPT risk profile. In particular, for g 662 = 1, both models would have similar risk profiles. Of course, there 663 are many other components of risk that that are not considered by 664 this analysis, such as collateral issues resulting from the existence 665 of faulty shared code, operating system process and memory structure, 666 etc. 668 7.2. Interference 670 Interference concerns stem from the possibility that application 671 coupling can lead to the destabilization of the Internet routing 672 system in unanticipated and unexpected ways. In this section we 673 consider interference properties of the GPT and SPT models. 675 7.2.1. Multisession BGP 677 Multisession BGP also seeks to reduce the interference profile of the 678 GPT model by eliminating one potential source of interference, 679 namely, the potential interference due to presence of multiple 680 AFI/SAFIs in a single BGP session. Following the analysis presented 681 in section 7.1.3, we can see that for small groupings (described as 682 small values of g in section 7.1.3), the interference profiles of 683 both models converge. 685 8. Application Fit 687 In the following sub-sections, application fit is examined from the 688 perspective of analyzing the data distribution needs of three 689 representative classes of application, namely: 691 RFC 2547 Style VPNs 692 VPWS 693 VPLS 695 8.1. RFC 2547 Style VPNs 697 First, it is useful to review the distribution mechanisms available 698 in BGP, in particular, in i-BGP. i-BGP has been described loosely as 699 a broadcast mechanism since an i-BGP speaker sends information to all 700 its peers. This is typically achieved by means of one or more route 701 reflectors; a more direct but less scalable means is for each i-BGP 702 speaker to have a BGP session with each i-BGP peer. 704 However, it is more accurate to characterize i-BGP as a constrained 705 broadcast mechanism. This is because the use of communities in 706 conjunction with import and export policies allows an i-BGP speaker 707 to effectively limit its communication to a subset of the full set of 708 i-BGP peers; the efficiency of constrained broadcast can be improved 709 by techniques such as described in [ORF] and [RTCONST]. 711 There are five classes of information that need to be distributed for 712 RFC 2547 style VPNs: 714 (a). Membership (auto-discovery) 715 (b). Prefixes 716 (c). Labels 717 (d). BGP nexthop, and 718 (e). Path selection attributes 720 The first of these, membership or auto-discovery, must be sent to all 721 peers, as a BGP speaker does not know a priori which of its peers are 722 members of a given VPN. Membership of a given VPN is recognized by 723 the use of certain extended communities called Route Targets. BGP is 724 clearly eminently well-suited for this mode of distribution. 726 The next three of these constitute the reachability information. 727 They say what part of a given VPN (b) is reachable, and how it is to 728 be reached (c and d). The final piece of information is used for 729 selection if there are multiple paths to a given prefix of a VPN, as 730 in the case of multi-homing. All of these pieces of information need 731 only be distributed to members of the VPN, i.e., they require a 732 constrained broadcast mechanism. BGP is reasonably well-suited for 733 this mode of distribution using import and export NLRI filtering. 734 The addition of the mechanism in [RTCONST] makes BGP even better 735 suited to this. 737 The encoding of this information as defined in [RFC2547BIS] puts all 738 of this information in a single NLRI. This seems to imply that a 739 broadcast mechanism has to be used for the distribution of RFC 2547 740 VPN information. However, the combination of [RTCONST] and [RFC2918] 741 allow BGP to distribute this information correctly yet efficiently. 743 Finally, it is useful to observe that standard BGP path selection 744 mechanisms (local pref, MED, AS path length, etc.) can be applied to 745 the information in (e). 747 The conclusion is that BGP is quite well-suited to this application, 748 and, with the addition of mechanisms such as [RTCONST] and [RFC2918], 749 the fit is even closer. 751 8.2. VPWS 753 A VPN based on a Virtual Private Wire Service [VPWS] connects a 754 number of sites by virtual wires (or pseudo-wires). The information 755 needed to create such a VPN comprises: 757 (a). Membership (auto-discovery) 758 (b). VPN site identification 759 (c). Labels 760 (d). BGP nexthop 761 (e). Path selection attributes, and 762 (f). Per-wire information 764 The analysis of the first five items is exactly as for RFC 2547 VPNs, 765 with the slight change that the definition of a 'part of a VPN' is no 766 longer an IP prefix, but is a VPN site identifier, which can be 767 viewed as the VPWS prefix. The distribution requirements and the fit 768 with BGP distribution mechanisms is identical to RFC 2547. 770 The one major change is the potential for 'per-wire' attributes, such 771 as bandwidth for a given site-to-site connection. This information 772 should be distributed on a point-to-point basis. BGP mechanisms are 773 not efficient for point-to-point distribution. However, it is an 774 open question whether such 'per-wire' attributes really need to be 775 exchanged, as evidenced by the fact that LDP signaling for pseudo- 776 wires [MARTINI] has not defined any such attributes. If per-wire 777 information is indeed not necessary, BGP distribution mechanisms are 778 as well-suited for VPWS VPNs as for RFC 2547 VPNs. 780 Note that existing BGP path selection mechanisms can be used as is 781 for VPWS, and can prove useful for multi-homed sites. 783 8.3. VPLS 785 A VPLS connects a number of sites by an emulated LAN segment. The 786 information needed to create a VPLS consists of: 788 (a). Membership (auto-discovery) 789 (b). VPLS site identification 790 (c). Labels 791 (d). BGP nexthop, and 792 (e). Path selection attributes 794 The notion of 'VPLS site identification' is analogous to a VPN site 795 identifier for VPWS. The analysis of the distribution needs of these 796 five items is exactly as for RFC 2547 VPNs, and the conclusion is 797 that BGP is reasonably well-suited for this application, and with the 798 addition of [RTCONST] and [REFRESH], the fit is even better. 800 Note that existing BGP path selection mechanisms can be used as is 801 for VPLS, and can prove useful for multi-homed sites. 803 9. Operational Implications 805 10. Other Models 807 11. Conclusions and Recommendations 809 12. Intellectual Property 811 The IETF takes no position regarding the validity or scope of any 812 intellectual property or other rights that might be claimed to 813 pertain to the implementation or use of the technology described in 814 this document or the extent to which any license under such rights 815 might or might not be available; neither does it represent that it 816 has made any effort to identify any such rights. Information on the 817 IETF's procedures with respect to rights in standards-track and 818 standards-related documentation can be found in BCP-11 [RFC2028]. 819 Copies of claims of rights made available for publication and any 820 assurances of licenses to be made available, or the result of an 821 attempt made to obtain a general license or permission for the use of 822 such proprietary rights by implementors or users of this 823 specification can be obtained from the IETF Secretariat. 825 The IETF invites any interested party to bring to its attention any 826 copyrights, patents or patent applications, or other proprietary 827 rights which may cover technology that may be required to practice 828 this standard. Please address the information to the IETF Executive 829 Director. 831 13. Design Team 833 The design team that produced this document consisted of Daniel 834 Awduche (awduche@awduche.com), Ron Bonica (Ronald.P.Bonica@mci.com), 835 Hank Kilmer (hank@rem.com), Kireeti Kompella (kireeti@juniper.net), 836 Chris Lewis (chrlewis@cisco.com), Danny McPherson (danny@tcb.net), 837 David Meyer (dmm@1-4-5.net) and Peter Whiting 838 (pwhiting@vericenter.com). 840 14. Acknowledgments 842 David Ball, Peter Gutierrez, Susan Harris, Pedro Marques, Eric Rosen, 843 Pekka Savola, and Mark Townsley have all made many insightful 844 comments on earlier versions of this document. 846 15. Security Considerations 848 This document specifies neither a protocol nor an operational 849 practice, and as such, it creates no new security considerations. 851 16. IANA Considerations 853 This document creates a no new requirements on IANA namespaces 854 [RFC2434]. 856 17. References 858 17.1. Normative References 860 [AFI] http://www.iana.org/assignments/address-family-numbers 862 [BGP] Rekhter, Y, T.Li, and S. Hares, "A Border Gateway 863 Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-23.txt. 864 Work in progress. 866 [BGPVPN] Ould-Brahim, H., E. Rosen, and Y. Rekhter, "Using 867 BGP as an Auto-Discovery Mechanism for 868 Provider-provisioned VPNs", 869 draft-ietf-l3vpn-bgpvpn-auto-00.txt. Work in 870 progress. 872 [CLARK] Clark, D., "Design Philosophy of the DARPA Internet 873 Protocols", Computer Communication Review, volume 874 25, number 1, January 1995. ISSN # 0146-4833. 876 [EXTCOMM] Sangali, S., D. Tappan, and Y. Rekhter, "BGP 877 Extended Communities Attribute", 878 draft-ietf-idr-bgp-ext-communities-06.txt. Work 879 in progress. 881 [FLOW] Marques, P, et. al., "Dissemination of flow 882 specification rules", 883 draft-marques-idr-flow-spec-00.txt. Work in 884 progress. 886 [L2TPv3] Lau, J., M. Townsley and I. Goyret (Editors), 887 "Layer Two Tunneling Protocol (Version 888 3)", draft-ietf-l2tpext-l2tp-base-11.txt. Work in 889 progress. 891 [MARTINI] Martini, L., E.Rosen, and T. Smith, "Pseudowire 892 Setup and Maintenance using LDP", 893 draft-ietf-pwe3-control-protocol-05.txt. Work in 894 progress. 896 [MULLER1999] Muller, R. et. al., "Control System Reliability 897 Requires Careful Software Installation 898 Procedures", International Conference on 899 Accelerator and Largeand Large Experimental 900 Physics Systems, 1999, Trieste, Italy. 902 [MULTISESSION] Scudder, J. and C. Appanna, "Multisession BGP, 903 draft-scudder-bgp-multisession-00.txt. Work in 904 progress. 906 [ORF] Chen, E., and Rekhter, Y., "Cooperative Route 907 Filtering Capability for BGP-4", 908 draft-ietf-idr-route-filter-09.txt. Work in 909 progress. 911 [RTCONST] Bonica, R. et al, "Constrained VPN route 912 distribution", 913 draft-marques-ppvpn-rt-constrain-01.txt. Work in 914 progress. 916 [SOFTNOTIFY} Nalawade, G., K. Patel, J. Scudder, and D. Ward, 917 "BGPv4 Soft-Notification Message", 918 draft-nalawade-bgp-soft-notify-00.txt., Work in 919 progress. 921 [RFC1075] Waitzman, D., C. Partridge, and S. Deering, 922 "Distance Vector Multicast Routing Protocol", RFC 923 1075, November, 1988. 925 [RFC1142] Oran, D. Editor, "OSI IS-IS Intra-domain Routing 926 Protocol", RFC 1142, February, 1990. 928 [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway 929 Protocol 4 (BGP-4)", RFC 1771, March 1995. 931 [RFC1958] Carpenter, B., "Architectural principles of the 932 Internet", Editor. RFC 1958, June 1996. 934 [RFC1997] Chandra, R., P. Traina, and T. Li, "BGP 935 Communities Attribute", RFC 1997, August, 1996. 937 [RFC2138] Rigney, C., et. al., "Remote Authentication Dial 938 In User Service (RADIUS)", RFC 2138, April, 1997. 940 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April, 1998. 942 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November, 943 1998. 945 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, 946 Version 6 (IPv6) Specification", RFC 2460, 947 December, 1998. 949 [RFC2547BIS] Rosen, E., et. al., "BGP/MPLS IP VPNs", 950 draft-ietf-l3vpn-rfc2547bis-00.txt. Work in 951 progress. 953 [RFC2858] Bates, T., et. al., "Multiprotocol Extensions 954 for BGP-4", RFC 2858, June 2000. 956 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", 957 RFC 2918, September 2000. 959 [RFC3036] Anderson, L., et. al., "LDP Specification", RFC 960 3036, January 2001. 962 [RFC3439] Bush, R. and D. Meyer, "Some Internet 963 Architectural Guidelines and Philosophy", RFC 964 3439, December, 2002. 966 [SAFI] http://www.iana.org/assignments/safi-namespace 968 [VLPS] Kompella, K., et. al. "Virtual Private LAN 969 Service", draft-ietf-l2vpn-vpls-bgp-02.txt. 970 Work in progress. 972 [VPWS] Kompella, K. et.al. "Layer 2 VPNs Over Tunnels", 973 draft-kompella-ppvpn-l2vpn-04.txt. Work in 974 progress. 976 17.2. Informative References 978 [IETFOL] https://www1.ietf.org/mailman/listinfo/routing-discussion 980 [RFC2119] Bradner, S., "Key words for use in RFCs to 981 Indicate Requirement Levels", RFC 2119, March, 982 1997. 984 [RFC2026] Bradner, S., "The Internet Standards Process -- 985 Revision 3", RFC 2026/BCP 9, October, 1996. 987 [RFC2028] Hovey, R. and S. Bradner, "The Organizations 988 Involved in the IETF Standards Process", RFC 989 2028/BCP 11, October, 1996. 991 [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for 992 Writing an IANA Considerations Section in RFCs", 993 RFC 2434/BCP 26, October 1998. 995 [RVBIB] http://www.routeviews.org/papers 997 [WILLINGER2002] Willinger, W., and J. Doyle, "Robustness and the 998 Internet: Design and evolution", 2002. 1000 18. Editor's Address 1002 David Meyer 1003 Email: dmm@1-4-5.net 1005 19. Full Copyright Statement 1007 Copyright (C) The Internet Society (2004). All Rights Reserved. 1009 This document and translations of it may be copied and furnished to 1010 others, and derivative works that comment on or otherwise explain it 1011 or assist in its implementation may be prepared, copied, published 1012 and distributed, in whole or in part, without restriction of any 1013 kind, provided that the above copyright notice and this paragraph are 1014 included on all such copies and derivative works. However, this 1015 document itself may not be modified in any way, such as by removing 1016 the copyright notice or references to the Internet Society or other 1017 Internet organizations, except as needed for the purpose of 1018 developing Internet standards in which case the procedures for 1019 copyrights defined in the Internet Standards process must be 1020 followed, or as required to translate it into languages other than 1021 English. 1023 The limited permissions granted above are perpetual and will not be 1024 revoked by the Internet Society or its successors or assigns. 1026 This document and the information contained herein is provided on an 1027 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1028 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1029 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1030 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1031 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1033 Meyer, et. al.