idnits 2.17.00 (12 Aug 2021) /tmp/idnits16805/draft-mplste-intedomain-ecmp-tie-breaking-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 (March 1, 2012) is 3732 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3471' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC3784' is defined on line 381, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4726 -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group P. Jain 3 Internet-Draft K. Singh 4 Intended status: Standards Track S. Venkataraman 5 Expires: September 2, 2012 Alcatel-Lucent, Inc. 6 March 1, 2012 8 RSVP-TE Extensions for ECMP Tie-Breaking of Inter-Domain TE LSPs 9 draft-mplste-intedomain-ecmp-tie-breaking-00 11 Abstract 13 This document specifies RSVP-TE extensions that will communicate to 14 all the ABRs that they need to explicitly perform a tie-breaking 15 process to select a particular path if path calculation results in 16 multiple equal-cost paths across different TE-Domains. This will 17 help is efficient utilization of end-to-end network resources for 18 Inter-Domain TE LSPs 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 2, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Establishment and Inability of End-to-End Load Balancing 59 of Inter-Domain Contigous TE LSP . . . . . . . . . . . . . . . 6 61 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 10 65 6. Management Considerations . . . . . . . . . . . . . . . . . . 11 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 9.1. IANA Considerations for RSVP-TE . . . . . . . . . . . . . 14 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC2119 [RFC2119]. 83 When used in lower case, these words convey their typical use in 84 common language, and are not to be interpreted as described in 85 RFC2119 [RFC2119]. 87 1. Introduction 89 If multiple equal-cost paths exists for a constraint TE-LSP, then we 90 typically use tie-breaking process to select a particular path. This 91 tie-breaking process is executed at the Head-End node where 92 Constrained Shortest Path First (CSPF) computation is exercised. 94 In case of RSVP Inter-Domain TE-LSPs of type Contiguous LSP RFC4726 95 [RFC4726] and RFC5151 [RFC5151] each ABR is specified as loose hop 96 and each ABR along the path whose next hop is specified as a loose 97 hop triggers a path computation (also referred to as an ERO 98 expansion), before forwarding the RSVP Path message downstream. 99 Thus, each ABR is responsible for calculating path within its TE- 100 Domain. 102 Every node that triggers path computation for its TE-Domain can have 103 multiple equal-cost paths and has to chose one of them. Since there 104 are multiple nodes that perform path computation (w.r.t. their 105 respective TE-Domains), hence there is no common selection criteria 106 for tie-breaking to be followed by each node performing ERO 107 expansion. 109 This document specifies RSVP-TE extensions that will communicate to 110 all the nodes doing ERO expansion that they need to explicitly 111 perform common tie-breaking process to select a particular path if 112 path calculation results in multiple equal-cost paths across its TE- 113 Domain. By doing this we achieve uniform path selection criteria for 114 Inter-Domain TE LSPs. 116 2. Terminology 118 Terminology used in this document: 120 CSPF: Constrained Shortest Path First. 122 TE LSP: Traffic Engineering Label Switched Path. 124 ERO: Explicit Route Object. 126 TE: Traffic Engineering. 128 IGP: Interior Gateway Protocol. 130 OSPF: Open Shortest Path First. 132 IS-IS: Intermediate System-to-Intermediate System. 134 LSR: Label Switching Router. 136 TE LSP head-end: head/source of the TE LSP. 138 ABR: Area Border Router. 140 Intra-domain TE LSP: A TE LSP whose path does not transit across 141 areas. 143 Inter-domain TE LSP: A TE LSP whose path transits across at least two 144 different IGP areas. 146 3. Establishment and Inability of End-to-End Load Balancing of Inter- 147 Domain Contigous TE LSP 149 The aim of this section is purely to summarize the mechanisms 150 involved in the establishment of a loosely routed TE LSP, based on 151 RSVP as specified in RFC3209 [RFC3209], RFC4726 [RFC4726] and RFC5151 152 [RFC5151]. 154 In the context of this document, a loosely routed Inter-Domain TE LSP 155 is defined as one that does not contain a full, explicit route 156 identifying each LSR along the path of the LSP at the time it is 157 signaled by the ingress LSR. Such an LSP is signaled with an ERO 158 that contains at least one loose hop that identifies ABR node. Each 159 LSR along the path whose next hop is specified as a loose hop 160 triggers a path computation (also referred to as an ERO expansion), 161 before forwarding the RSVP Path message downstream. The computed 162 path may be either partial (up to the next loose hop) or complete 163 (set of strict hops up to the TE LSP destination). 165 Note that although the examples in the rest of this document are 166 provided in the context of MPLS Inter-Domain TE, the proposed 167 mechanism applies equally to loosely routed paths within a single 168 routing domain and across multiple Autonomous Systems. The examples 169 below are provided with OSPF as the IGP, but the described set of 170 mechanisms similarly apply to IS-IS. 172 An example of an explicit loosely routed TE LSP signaling follows. 174 Assumptions. 175 <-area 1-><-area 0-><-area 2-> 177 R1---R2---R3---R6----R8---R10 178 | / | \ | / | | 179 | / | \ | / | | 180 | / | \ | / | | 181 R4-------R5---R7----R9---R11 183 o R3, R5, R8, and R9 are ABRs. 185 o The path of an Inter-Domain TE LSP T1 from R1 (head-end LSR) to 186 R11 (tail-end LSR) is defined on R1 as the following loosely 187 routed path: R1-R3(loose)-R8(loose)-R11(loose). R3, R8, and R11 188 are defined as loose hops. 190 o Step 1: R1 determines that the next hop (R3) is a loose hop (not 191 directly connected to R1) and then performs an ERO expansion 192 operation to reach the next loose hops R3. The new ERO could 193 become: R2(S)-R3(S)-R8(L)-R11(L) or R4(S)-R3(S)-R8(L)-R11(L), 194 where S is a strict hop (L=0) and L is a loose hop (L=1). Both 195 the paths R1-R2-R3 and R1-R4-R3 are equal-cost paths and satisfies 196 T1's set of constraints. 198 o Step 2: The RSVP Path message is then forwarded by R1 following 199 the path specified in the ERO object and reaches R3 with the 200 following content: R8(L)-R11(L). 202 o Step 3: R3 determines that the next hop (R8) is a loose hop (not 203 directly connected to R3) and then performs an ERO expansion 204 operation to reach the next loose hops R8. The new ERO could 205 become: R6(S)-R8(S)-R11(L) or R7(S)-R8(S)-R11(L). Both paths R3- 206 R6-R8 and R3-R7-R8 are equal-cost paths and satisfies T1's set of 207 constraints. 209 o Step 4: The same procedure is repeated by R8 to reach T1's 210 destination (R11) and which may also lead to two equal-cost paths 211 R8-R10-R11 and R8-R9-R11. 213 In the above example we see that there are two equal-cost paths that 214 results from path computation done by ingress node (R1) and 215 subsequent ABRs (R3 and R8) for their TE-Domain. In order of 216 efficiently using the links as desired by network administrator only 217 the ingress node can know about the tie-breaking process to be use as 218 part of the TE-LSP configuration, which may lead to efficient use of 219 the links in area-1 (or domain 1) only. However there is no way to 220 communicate that subsequent ABRs (R3 and R8) also needs to use common 221 tie-breaking process so as to efficiently use the link in their 222 subsequent domains. 224 This document defines mechanisms that would allow each ABR to know 225 what tie-breaking process to use among equal-cost paths when doing 226 path computation for their respective TE-domain. 228 4. RSVP-TE Extensions 230 There are following well known and understood techniques followed by 231 various routing vendors used for tie-breaking in case multiple equal- 232 cost paths exists. 234 o Least-Fill. 236 o Most-Fill. 238 o Random. 240 Most known and deployed implementations employ a consistent 241 definition of above three Path Selection tie-breaking schemes, and 242 the specifications of each tie-breaking load balancing algorithms is 243 outside the scope of this document. This document only lays down the 244 mechanism for signaling what type of tie-breaking process is intended 245 to be used for a given Inter-Domain TE LSP. Such that all the nodes 246 along the Inter-Domain TE LSP which does path computations can factor 247 such constraints and help in signaling end-to-end TE-LSP which is 248 efficiently using links as desired by network administrator spanning 249 across multiple TE-Domains. 251 In order to indicate nodes (e.g ABRs) that are participating ERO 252 expansion for Inter-Domain Contiguous TE LSP to exercise either 253 Least-Fill or Most-Fill type of tie-breaking procedure for equal-cost 254 paths, this document defines new set of flag values in the Attribute 255 Flags TLV, which are carried in LSP_ATTRIBUTES Object RFC5420:. 257 o Bit Number (to be assigned by IANA, recommended bit one) : Least- 258 Fill Bit. 260 o Bit Number (to be assigned by IANA, recommended bit two) : Most- 261 Fill Bit. 263 Both the bits would together can be referred as ECMP tie-breaking 264 bits. Both the proposed bits would have meaning only in Path 265 message. 267 If Least-Fill Bit is set, then the node responsible for Path 268 expansion MUST use the Least-Fill process for tie-breaking of ECMP 269 paths. 271 If Most-Fill Bit is set, then the node responsible for Path expansion 272 MUST use the Most-Fill process for tie-breaking of ECMP paths. 274 If none of the Bit (Least-Fill Bit or Most-Fill Bit) is set, then the 275 node responsible for Path expansion can use the default process for 276 tie-breaking of ECMP paths. This could be Random or whatever is 277 configured as default tie-breaking process on the node. 279 The rules of the processing of the Attribute Flags TLV are not 280 changed. 282 5. Signaling Procedures 284 If it is desired to perform uniform way of tie-breaking process (with 285 could be Least-Fill, Most-Fill or Random) across all domains for 286 Inter-Domain TE-LSP, then head-end node is responsible for setting 287 Least-Fill or Most-Fill Bit in the Attribute Flags TLV which is 288 carried in LSP_ATTRIBUTES Object. 290 When a node receives a Path message which carries an LSP_ATTRIBUTES 291 Object with either Least-Fill or Most-Fill Bit set in Attribute Flags 292 TLV, then :-. 294 If the node is going to perform the ERO expansion (e.g ABR node), 295 then it MUST use the appropriate method as what is been signaled 296 (Least-Fill or Most-Fill) to perform tie-breaker of ECMP paths. If 297 both Least-Fill and Most-Fill bits are unset, then node can use the 298 default process for breaking the tie-breaker of ECMP paths. This 299 could be Random or whatever is configured as default tie-breaking 300 process on the node. 302 If the node does not need to perform the path expansion (e.g non-ABR 303 node), it should do regular Path message processing as defined in 304 RFC2205 [RFC2205] and RFC3209 [RFC3209]. 306 If the node does not support Least-Fill or Most-Fill process of tie- 307 breaking of ECMP paths, then it MUST send PathErr to reject the Path 308 message with the defined error code ''Policy Control 309 Failure''/''Inter- domain policy failure''. 311 6. Management Considerations 313 None 315 7. Security Considerations 317 The function described in this document does not create any new 318 security issues for RSVP-TE protocol. 320 8. Acknowledgements 322 The editors gratefully acknowledge the useful inputs of Mustapha 323 Aissaoui of Alcatel-Lucent, Inc 325 9. IANA Considerations 327 9.1. IANA Considerations for RSVP-TE 329 IANA will assign two Bits in Attribute Flags TLV, which is carried in 330 an LSP_ATTRIBUTES Object RFC5420 [RFC5420]. First bit would 331 communicate Least-Fill, and the second bit would communicate Most- 332 Fill type of tie-breaking procedure for equal-cost paths. 334 Following Bit values for Attribute Flags TLV are suggested:- 336 Bit Tie-Breaking Method Reference 337 ------------- ------------------- --------------- 338 1 (suggested) Least-Fill (this document) 340 2 (suggested) Most-Fill (this document) 342 10. References 344 10.1. Normative References 346 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 347 Inter-Domain Multiprotocol Label Switching Traffic 348 Engineering", RFC 4726, November 2006. 350 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 351 MPLS and GMPLS Traffic Engineering -- Resource Reservation 352 Protocol-Traffic Engineering (RSVP-TE) Extensions", 353 RFC 5151, February 2008. 355 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 356 Ayyangarps, "Encoding of Attributes for MPLS LSP 357 Establishment Using Resource Reservation Protocol Traffic 358 Engineering (RSVP-TE)", RFC 5420, February 2009. 360 10.2. Informative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 366 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 367 Functional Specification", RFC 2205, September 1997. 369 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 370 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 371 Tunnels", RFC 3209, December 2001. 373 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 374 (GMPLS) Signaling Functional Description", RFC 3471, 375 January 2003. 377 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 378 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 379 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 381 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 382 System (IS-IS) Extensions for Traffic Engineering (TE)", 383 RFC 3784, June 2004. 385 Authors' Addresses 387 Pradeep Jain 388 Alcatel-Lucent, Inc. 389 701 E Middlefield Rd 390 Mountain View, CA 94040 391 USA 393 Email: pradeep.jain@alcatel-lucent.com 395 Kanwar Singh 396 Alcatel-Lucent, Inc. 397 701 E Middlefield Rd 398 Mountain View, CA 94040 399 USA 401 Email: kanwar.singh@alcatel-lucent.com 403 Srikrishnan Venkataraman 404 Alcatel-Lucent, Inc. 405 701 E Middlefield Rd 406 Mountain View, CA 94040 407 USA 409 Email: Srikrishnan.Venkataraman@alcatel-lucent.com