idnits 2.17.00 (12 Aug 2021) /tmp/idnits13068/draft-white-rppract-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 411. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (March 12, 2008) is 5176 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: 'BGP' is mentioned on line 299, but not defined == Missing Reference: 'A' is mentioned on line 273, but not defined == Missing Reference: 'OSPF' is mentioned on line 309, but not defined == Missing Reference: 'IS-IS' is mentioned on line 309, but not defined == Unused Reference: 'BGP-MD5' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 352, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. 'BGP-MD5') (Obsoleted by RFC 5925) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. White 3 Internet-Draft Cisco Systems 4 Expires: September 13, 2008 J. Burns 5 Wachovia 6 March 12, 2008 8 Common Practices in Routing Protocols Deployment 9 draft-white-rppract-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 13, 2008. 36 Abstract 38 This document discusses common practices used in deploying routing 39 protocols in both public and private networks. The focus is not to 40 describe how routing protocols should be deployed, but rather how 41 they are generally deployed, to provide those working on 42 specifications which impact the operation of routing protocols with 43 guidance in what will likely be deployed, or what will likely not be 44 deployed. The focus in thie document will be ionterdomain routing, 45 but it will cover aspects of intradomain routing, as well. 47 1. Background 49 When considering new extensions to existing routing protocols, it's 50 useful to consider them in the context of existing usage of these 51 protocols. Various questions come to mind, such as: 53 o Common Underlying Principles of Network Designs 54 o Common Practices in Route Origination 55 o Common Practices in Routing Database Management 56 o Common Practices in Aggregation 57 o Common Practices in Peering 58 o Common Practices in Security 59 o .... 61 Each of these topics will be covered in a separate section below. 63 2. Common Underlying Principles of Network Designs 65 There are a number of underlying principles most network designers 66 take into account when designing networks which don't fit neatly into 67 any single category below; these are covered in this section. Most 68 of these principles apply across multiple layers, and with many 69 different protocols, so while examples are given, these principles 70 can be found in many parts of any given network design, in ways that 71 may not be immediately obvious or apparent. 73 2.1. Network Growth 75 Networks always grow, through organic growth and through mergers and 76 aquisitions. To counter this, network design is often focused on the 77 removal of information from the routing database. There are three 78 types of information which are commonly removed from the routing 79 database: 81 o Fine grained reachability information is often replaced with more 82 gross levels of reachability information. 83 o State changes are often hidden at various points within the 84 network. 85 o Topology information is often reduced from a fine grain view of 86 the network to a single point of reachability. 88 One mechanism used to remove these types of information from the 89 routing database is the aggregation of routing data. Common 90 techniques used to aggregate routing data are covered in greater 91 detail in a later section. Removing information from the routing 92 database through aggregation virtually always causes suboptimal 93 routing. The corollary to this is that for finer grained traffic 94 control, more state is always required, hence traffic engineering 95 must always be balanced with stability in network design. 97 Another mechanism commonly used to remove information from the 98 routing database is virtualization, or splitting the network into two 99 pieces vertically, throughout the entire physical topology. One 100 instance of this is using BGP to carry external routes while carrying 101 an IGP to carry internal routes. This splits the database into two 102 pieces, based on the characteristics of the information, and carries 103 them separately. While the traffic being routed is carried along the 104 same topologies, the control plane data is split, or virtualized. 106 2.2. Deterministic Behaviour 108 Network designs often favor deterministic behaviour in the face of 109 failures or changes over non-deterministic behaviour. This is 110 generally supported by the observation that the Mean Time To Repair 111 is virtually always a larger component of network downtime than the 112 Mean Time Between Failures. Deterministic behaviour is a tremendous 113 aid in troubleshooting, which can decrease the Mean Time To Repair 114 dramatically. Some examples of designing for deterministic behaviour 115 include: 117 o Link metrics are normally manually engineered to select a primary 118 and alternate path through the network for any given source/ 119 destination pair, rather than allowing the routing protocol to 120 naturally process the paths, and build paths which might fail over 121 in non-deterministic ways. 122 o Trees for routing multicast routing may be manually configured 123 throughout a network, to control the paths and backup paths 124 available to certain classes of traffic 126 2.3. Convergence Verses Network Stability 128 Newer classes of traffic place a great deal of load on network 129 convergence. At one time, a convergence time of 3 to 9 minutes was 130 considered acceptable, as witnessed by the default timers and 131 operation of early distance-vector protocols. Networks now must 132 contend with very high speed links, across which loops with durations 133 in the 100s of milliseconds can lead to a total failure of sections 134 of the network. Networks must also contend with applications which 135 cannot accept any loss of connectivity above the 100s of 136 milliseconds, and some applications which cannot tolerate any packet 137 loss. 139 The primary problem with these sorts of requirements is that 140 extermely high network convergence speeds allow no time for dampening 141 rapid changes in the network, and, in fact, can amplify rapid network 142 changes, reducing network stability, sometimes to the point where the 143 network fails to converge. Network design thus must be built around 144 converging quickly while maintaining stability, a sometimes difficult 145 balance to achieve. Some of the techniques designers use to balance 146 between stability and convergence speed include: 148 o Pushing detection as close to the hardware as possible. For 149 instance, point-to-point links are used where possible, so the 150 physical media state is tied directly to the logical media state. 151 o When logical state doesn't track physical state directly, using 152 layer 2 mechanisms where possible to detect circuit outages. 153 o Using exponential backoff and other dampening mechanisms to 154 prevent a positive feedback loop from forming, adversely impacting 155 network performance. 157 3. Common Practices in Route Origination 159 Interior and exterior gateway protocols have a number of ways in 160 which they classify routing information, the primary of which is the 161 way in which destinations have been injected into the protocol. 163 3.1. Interior Gateway Protocols 165 For interior gateway protocols, routing information is normally 166 classified as originating either from within the protocol, or from a 167 source which is external to the protocol. Destinations which are 168 learned of through a direct connection, such as a connection to a 169 subnet on a router running the protocol, are called internal routes. 170 Destinations which are learned of through some other means, outside 171 the protocol, are called external routes. 173 Virtually all routing information is injected into interior gateway 174 protocols as internal routing information, unless there is a specific 175 reason for injecting external information into the IGP routing 176 domain. Some specific reasons might include: 178 When multiple routing protocols are being used in the same 179 network. Generally, this occurs when two networks are merged, or 180 when a part of the network runs a different routing protocol for 181 policy or design reasons. 182 When interaction is occuring with a network not under the local 183 administrator's control. Generally, injecting external live 184 routing information between interior gateway protocols between 185 routing domains is not encouraged, but there are instances when 186 this occurs. 188 To inject manually configured reachability information into the 189 protocol. This generally occurs along the edges of a network, to 190 provide reachability to destinations not within the network 191 itself. 192 To provide reachability across some form of layer 3 virtual 193 private network, when no mechanism is deployed or supported to 194 provide the transport of native routing information across the 195 VPN. 197 Generally, injection of external routing information is avoided where 198 possible in network designs, unless there is a specific policy or 199 design related reason to do so. 201 3.2. Exterior Gateway Protocols 203 For exterior gateway protocols, the distinction between internal and 204 external routing information is blurred, as all information is 205 considered to be external. There is an indicator of where a specific 206 piece of routing information originated, but this information is used 207 very low on the decision process, and so it's generally not 208 considered a factor in route choice. 210 However, there is another aspect of route origination which is a 211 common concern in exterior gateway protocols, such as [BGP]--how 212 routing information is locally originated on a given router. In all 213 implementations of [BGP], routing information can either be 214 originated from the local routing table, or it can be originated from 215 a local manually configured route. Generally, to improve network 216 stability, routes are injected into BGP by manually configuring a 217 local static route, and injecting the manually configured route into 218 the protocol, rather than by pulling information from the dynamic 219 routing table. 221 4. Common Practices in Routing Database Management 223 When managing policies and filters in the routing database, explicit 224 and obvious mechanisms are generally preferred over implicit, or less 225 obvious, mechanisms. Some examples of this include: 227 o When redistribution between routing protocols, route tags are 228 preferred over lists of redistributed routes to prevent routing 229 loops from forming. 230 o When filtering at an AS boundary in [BGP], filtering based on the 231 AS Path length is generally preferred over filtering on 232 communities, or other attributes, because the AS Path is obvious 233 and well known, while a lot of network engineers will not examine 234 other attributes. 236 5. Common Practices in Aggregation 238 Aggregation of reachability information in a network occurs both in 239 the IGP and the the EGP, and there are different common practices for 240 each one. The two section below discuss these practices. In a third 241 section, the common practice of allowing longer prefixes matches 242 through an aggregation point is discussed. 244 5.1. Aggregation Practices in IGPs 246 Normally, aggregation in IGP is performed through manual 247 configuration, and the aggregate route information is pulled from the 248 local RIB. Quite often, the metric of the resulting aggregate route 249 is forced to remain constant (which prevents state changes in one 250 part of the network from impacting other parts of the network) 251 through the use of a virtual interface, or a manually configured 252 metrics attached to the aggregation configuration. 254 5.2. Aggregation Practices in EGPs 256 While aggregation commands are available in most implementations of 257 [BGP], and there are extensive rules covering how to aggregation the 258 various attributes of a set of aggregated routes, aggregation is not 259 used in most BGP deployments. Instead, it is much more common for a 260 manually configured route to originated into BGP to advertise an 261 aggregate. Filters are normally used in conjunction with these 262 manually originated routes to prevent components of the aggregate 263 from being leaked to peering routers. 265 5.3. Allowing Components Through Aggregation 267 It is common to allow components to be advertised along with 268 aggregated routing information to provide optimal routing to specific 269 destinations. To provide an example: 271 +----[B]---10.1.2.0/24 272 | | 273 [A] +----10.1.3.0/24 274 | | 275 +----[C]---10.1.4.0/24 277 In this network, the network designer might want to reduce the amount 278 of routing data and state flowing to A. In order to do this, manual 279 summaries can be configured at B and C, so only a shorter prefix 280 covering all the reachable destinations is advertised. However, as 281 noted earlier, the consequence of configuring this manual aggregation 282 of routing information would be the introduction of suboptimal 283 routing in the network, from A, towards 10.1.2.0/24 and 10.1.4.0/24. 285 To counter this, the network engineer might opt to leak these two 286 specific routes through the aggregate. 288 What is seen from the outside as a "multihoming" problem is, then, 289 actually a traffic engineering problem. Most often providing two 290 alternate paths in any network will result in the desire to optimally 291 route traffic through those paths, whether they are equal cost or 292 not. In most cases, leaking more specific reachability information 293 is the quickest and most obvious way to reach the right balance of 294 routing information verses optimal routing. 296 6. Common Practices In Peering 298 Many network design problems need to be taken into account when 299 setting up peering, both for IGPs and for [BGP]. Common practices in 300 this area include: 302 eBGP peers are normally set up for fast down detection where 303 possible, which is generally only possible with sessions over 304 point-to-point links. 305 eBGP sessions are generally manually configured not to accept a 306 TCP keepalive timer less than 10 or 15 seconds, to prevent the 307 peering router from negotiating very low TCP keepalive timers, 308 which consumes processor. 309 [OSPF] designated routers and [IS-IS] Designated Intermediate 310 Systems are normally chosen through manual configuration. 311 Deterministic behaviour is the goal in all cases where one router 312 within a set is chosen for a role or a specific set of processing. 314 7. Common Practices in Security 316 Security practices generally center around preventing state changes 317 and false routing information from entering the network, and 318 preventing access to infrastructure devices, including routers, 319 within the network. Some commonly used techniques in this area 320 include: 322 o Filtering reachability information at network edges so 323 infrastructure devices are not reachable outside the network. 324 o Configuring packet filters at network edges to directly prevent 325 infrastructure devices from being reached from outside the 326 network. 327 o Filtering reachability information at network edges to prevent the 328 injection of private routes, bogus routes, or routes used for 329 internal infrastructure. 331 o Route count limiters at the network edge where live routing data 332 is accepted from an outside network, to prevent overflowing local 333 routing tables. 335 Cryptographic secuirity mechanisms, such as MD5, are not generally 336 configured for various reasons, including: 338 o Processing requirements cryptographic mechanisms are generally 339 high, which can produce generally undesirable side effects. 340 o Key management for cryptographic mechanisms is generally difficult 341 to imeplement and manage. 343 8. Acknowledgements 345 .... 347 9. Informative References 349 [BGP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 350 Signature Option", RFC 2385, August 1998. 352 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 353 Protocol 4 (BGP-4)", RFC 4271, January 2006. 355 Authors' Addresses 357 Russ White 358 Cisco Systems 360 Phone: 361 Fax: 362 Email: riw@cisco.com 363 URI: 365 John Burns 366 Wachovia 368 Phone: 369 Fax: 370 Email: john.burns1@wachovia.com 371 URI: 373 Full Copyright Statement 375 Copyright (C) The IETF Trust (2008). 377 This document is subject to the rights, licenses and restrictions 378 contained in BCP 78, and except as set forth therein, the authors 379 retain all their rights. 381 This document and the information contained herein are provided on an 382 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 383 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 384 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 385 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 386 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 387 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 389 Intellectual Property 391 The IETF takes no position regarding the validity or scope of any 392 Intellectual Property Rights or other rights that might be claimed to 393 pertain to the implementation or use of the technology described in 394 this document or the extent to which any license under such rights 395 might or might not be available; nor does it represent that it has 396 made any independent effort to identify any such rights. Information 397 on the procedures with respect to rights in RFC documents can be 398 found in BCP 78 and BCP 79. 400 Copies of IPR disclosures made to the IETF Secretariat and any 401 assurances of licenses to be made available, or the result of an 402 attempt made to obtain a general license or permission for the use of 403 such proprietary rights by implementers or users of this 404 specification can be obtained from the IETF on-line IPR repository at 405 http://www.ietf.org/ipr. 407 The IETF invites any interested party to bring to its attention any 408 copyrights, patents or patent applications, or other proprietary 409 rights that may cover technology that may be required to implement 410 this standard. Please address the information to the IETF at 411 ietf-ipr@ietf.org.