idnits 2.17.1 draft-boucadair-idr-constrained-multiple-path-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2010) is 4946 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) == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-04 == Outdated reference: A later version (-16) exists of draft-irtf-rrg-recommendation-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track France Telecom 5 Expires: April 15, 2011 October 12, 2010 7 Constrained Multiple BGP Paths 8 draft-boucadair-idr-constrained-multiple-path-00 10 Abstract 12 It is commonly agreed the continuous increase of routing tables is a 13 sensitive issue which may question the sustainability of the 14 Internet. This document describes a solution which makes use of 15 multiple paths without inducing drastic increase of routing tables. 16 A constrained procedure to install additional paths in the RIB is 17 described. Multiple paths are installed according to rules agreed 18 between adjacent peers and also based on external events (e.g., pro- 19 active detection of link congestion). 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 15, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Contribution of this I-D . . . . . . . . . . . . . . . . . 4 63 2. Extended NLRI Encoding . . . . . . . . . . . . . . . . . . . . 4 64 3. Maximum Path Capability . . . . . . . . . . . . . . . . . . . . 5 65 4. NOTIFICATION Error Code . . . . . . . . . . . . . . . . . . . . 6 66 5. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 [I-D.ietf-idr-add-paths] defines a procedure to support multiple 78 paths. The support of this feature may exacerbate the increase of 79 routing tables which is seen as a critical issue for the 80 sustainability of the overall Internet [I-D.irtf-rrg-recommendation] 81 [I-D.narten-radir-problem-statement]. 83 In the meantime, allowing to store multiple paths in the RIB is 84 motivated in several scenarios such as the following: 86 o Load balancing; 88 o Proactive reaction due to congestion events. As an illustration, 89 Figure 1 shows an architecture where three paths to reach D are 90 received by AS2. After applying the route selection process 91 defined in [RFC4271], only R1 is selected. This route is then 92 propagated to AS1. If AS3 experiences congestion on its link to 93 AS7 for instance, part of the traffic is likely to be lost. If 94 the procedure described in this document is applied, then once a 95 congestion event is observed in AS3 (local to an ASBR, intra- 96 domain links, involved intra-domain routers or on inter-domain 97 links) an UPDATE message is sent by AS3 to AS2 to notify a 98 congestion by means of a dedicated flag in the extended NLRI. 99 Once this UPDATE message is received by AS2, the route selection 100 process is applied and an additional route is installed in the 101 RIB. An UPDATE message including the extended NLRI conveying two 102 paths is then sent to AS1, R1 being tagged as a congested route 103 (See Figure 2). This document focuses on this use case. 105 R1 +---+ 106 /------------|AS3|-------------------\ 107 | +---+ | 108 +---+ R1 +---+ R2 +---+ +---+ +---+ 109 |AS1|-------|AS2|----------|AS4|--------|AS6|----|AS7|--- D 110 +---+ +---+ +---+ +---+ +---+ 111 | R3 +---+ | 112 \------------|AS5| ------------------/ 113 +---+ 115 Figure 1: Example Architecture 117 (R1,C) +---+ 118 /------------|AS3|-------------------\ 119 | +---+ | 120 +---+ (R1,C)+---+ R2 +---+ +---+ +---+ 121 |AS1|-------|AS2|----------|AS4|--------|AS6|----|AS7|--- D 122 +---+ R3 +---+ +---+ +---+ +---+ 123 | R3 +---+ | 124 \------------|AS5| ------------------/ 125 +---+ 127 Figure 2: Congested link 129 1.1. Contribution of this I-D 131 This document proposes a constrained multiple path procedure which 132 allows BGP peers to manage multiple paths towards a given destination 133 in a controlled fashion. 135 This document provides a scenario with congestion. Other use cases 136 could also be considered, such as QoS-inferred route tagging 137 capabilities. 139 This document re-uses some of the encodings proposed in 140 [I-D.ietf-idr-add-paths]. 142 2. Extended NLRI Encoding 144 The current encoding defined in [I-D.ietf-idr-add-paths] does not 145 allow to tag a specific enclosed path described in the Extended NLRI 146 encoding. The NLRI encoding depicted in Figure 3 is used in this 147 document instead of the one specified in [I-D.ietf-idr-add-paths]. 149 +--------------------------------+ 150 | Flag (1 octet) | 151 +--------------------------------+ 152 | Path Identifier (4 octets) | 153 +--------------------------------+ 154 | Length (1 octet) | 155 +--------------------------------+ 156 | Prefix (variable) | 157 +--------------------------------+ 159 Figure 3: Extended NLRI 161 Except the Flag field, the remaining fields are similar to what is 162 defined in Section 3 of [I-D.ietf-idr-add-paths]. 164 The structure of the Flag field is shown in Figure 4. 166 +--------------------------------+ 167 |C| Reserved | 168 +--------------------------------+ 170 Figure 4: Flag 172 The first bit (called C bit) is used to indicate whether the path is 173 congested (C=1) or not (C=0). The remaining bits are set to 0. 175 Further values can be defined in the future if required. 177 3. Maximum Path Capability 179 This section describes a new BGP Capability [RFC5492] called Maximum 180 Path Capability. The format of this new Capability is shown in 181 Figure 5. 183 +------------------------------------------------+ 184 | Multiple Paths Max (1 octet) | 185 +------------------------------------------------+ 186 | Address Family Identifier (2 octets) | 187 +------------------------------------------------+ 188 | Subsequent Address Family Identifier (1 octet) | 189 +------------------------------------------------+ 190 | Send/Receive (1 octet) | 191 +------------------------------------------------+ 193 Figure 5: Multiple Paths Capability 195 Multiple Paths Max field indicates the maximum number of multiple 196 paths to a given destination prefix that can be supported by a given 197 BGP peer. The number of multiple paths that can be exchanged between 198 two BGP peers MUST NOT exceed the Multiple Paths Max threshold. 200 For the remaining fields, the same description as what is specified 201 in Section 4 of [I-D.ietf-idr-add-paths] is assumed. 203 4. NOTIFICATION Error Code 205 This document defines a new NOTIFICATION error code: 207 Error Code Name 208 ---------- ------------ 209 TBA Maximum Path 211 The following error subcode is defined: 213 Error SubCode Name 214 ------------- -------------------- 215 TBA Maximum Path Reached 217 5. Procedure 219 The procedure for exchanging constrained multiple paths is as 220 follows: 222 o During BGP session initialisation, a peer supporting the procedure 223 described in this document includes the Maximum Path Capability in 224 its Capability Set; 226 o A BGP speaker can advertise multiple paths to a BGP peer only if a 227 Maximum Path Capability was included in its Capability Set 228 received from an adjacent peer; 230 o Furthermore, if a BGP peer announces a number of routes towards a 231 destination prefix that exceeds what has been negotiated during 232 the OPEN phase, a NOTIFICATION message MUST be sent and SHOULD 233 include an adequate Error Code/SubCode that corresponds to the 234 exceeded multiple path threshold (See Section 4). 236 o Once the capability negotiation phase is completed, BGP peers 237 adopt the normal BGP behaviour as specified in [RFC5492]; 239 o Each AS would implement means/tools to monitor its intra and 240 inter-domain links. These tools are out of the scope of this 241 document. Once a threshold is reached (e.g., 75% of link 242 utilisation), an event is sent to the ASBRs. These nodes send 243 UPDATE messages to their peers to notify them about the status of 244 advertised routes. C bit is set to 1 when a given route is seen 245 as congested; 247 o Once this UPDATE is received by a BGP peer, it re-computes the 248 routes to be installed in the RIB. If the selected route is 249 congested, a new route is added to the local RIB. Both routes 250 will be advertised using the extended NLRI to adjacent BGP 251 speakers; 253 o This process can be re-iterated until reaching the maximum 254 supported multiple paths. Note that only one route with the flag 255 C set to 0 is installed in the local RIB. A local BGP speaker 256 accept to install a new route if and only if the best route is 257 congested; otherwise only one route is installed in the local RIB. 259 o The removal of alternative path can be undertaken by a BGP speaker 260 according to local or external events. 262 [[Note: The document does not elaborate on load balancing and how the 263 traffic is distributed among available path.]] 265 [[Note: For load banaling purposes, a metric can be conveyd to inform 266 a BGP peer about the BW of the downstream interconnection link (i.e., 267 interconnection links with one hop adjacent ASes.]] 269 6. IANA Considerations 271 This document requests 273 o a new code for the Maximum Path Capability 275 o Maximum Path Error Notification code 276 o Maximum Path Reached error sub-code 278 7. Security Considerations 280 This document does not introduce any security issue other than those 281 elaborated in [RFC4271]. 283 8. Acknowledgements 285 Many thanks to David Binet for his review. 287 9. References 289 9.1. Normative References 291 [I-D.ietf-idr-add-paths] 292 Walton, D., Retana, A., Chen, E., and J. Scudder, 293 "Advertisement of Multiple Paths in BGP", 294 draft-ietf-idr-add-paths-04 (work in progress), 295 August 2010. 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 301 Protocol 4 (BGP-4)", RFC 4271, January 2006. 303 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 304 with BGP-4", RFC 5492, February 2009. 306 9.2. Informative References 308 [I-D.irtf-rrg-recommendation] 309 Li, T., "Recommendation for a Routing Architecture", 310 draft-irtf-rrg-recommendation-14 (work in progress), 311 September 2010. 313 [I-D.narten-radir-problem-statement] 314 Narten, T., "On the Scalability of Internet Routing", 315 draft-narten-radir-problem-statement-05 (work in 316 progress), February 2010. 318 Authors' Addresses 320 Mohamed Boucadair 321 France Telecom 323 Email: mohamed.boucadair@orange-ftgroup.com 325 Christian Jacquenet 326 France Telecom 328 Email: christian.jacquenet@orange-ftgroup.com