idnits 2.17.1 draft-vasseur-mpls-loose-path-reopt-02.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 661 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 255: '...better path can be found, the LSR MUST...' RFC 2119 keyword, line 258: '...s point, the LSR MAY decide to clear t...' RFC 2119 keyword, line 311: '...the Head-end LSR MUST perform a make b...' RFC 2119 keyword, line 327: '...h exists)). The Head-end LSR MUST then...' RFC 2119 keyword, line 339: '...he ERO expansion MUST perform the foll...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 38 has weird spacing: '...path is a pat...' == Line 252 has weird spacing: '...pansion is tr...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'METRIC' is mentioned on line 139, but not defined == Unused Reference: 'TE-REQ' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'METRICS' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'DS-TE' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'MULTI-AREA-TE' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'INTER-AS-TE' is defined on line 433, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-05 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-03 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') -- Possible downref: Normative reference to a draft: ref. 'METRICS' == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-reqts-01 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-diff-te-reqts (ref. 'DS-TE') == Outdated reference: A later version (-04) exists of draft-kompella-mpls-multiarea-te-03 -- Possible downref: Normative reference to a draft: ref. 'MULTI-AREA-TE' == Outdated reference: A later version (-05) exists of draft-vasseur-mpls-computation-rsvp-03 -- Possible downref: Normative reference to a draft: ref. 'PATH-COMP' == Outdated reference: A later version (-09) exists of draft-ietf-tewg-interas-mpls-te-req-00 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-interas-mpls-te-req (ref. 'INTER-AS-TE-REQS') == Outdated reference: A later version (-01) exists of draft-vasseur-inter-as-te-00 -- Possible downref: Normative reference to a draft: ref. 'INTER-AS-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'REFRESH-REDUCTION' Summary: 11 errors (**), 0 flaws (~~), 19 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Jean-Philippe Vasseur(Editor) 2 Cisco Systems, Inc. 3 Yuichi Ikejiri 4 NTT Communications Corporation 6 IETF Internet Draft 7 Expires: December, 2003 8 June, 2003 10 draft-vasseur-mpls-loose-path-reopt-02.txt 12 Reoptimization of MPLS Traffic Engineering loosely routed explicit LSP 13 paths 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC2026. Internet-Drafts are 19 Working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-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 material 26 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. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Vasseur and Ikejiri 1 34 Abstract 36 The aim of this document is to propose a mechanism for the 37 reoptimization of MPLS Traffic Engineering loosely routed explicit LSP 38 paths. A loosely routed explicit LSP path is a path specified as a 39 combination of strict and loose hop(s) that contains at least one loose 40 hop and zero or more strict hop(s). The path calculation (which implies 41 ERO expansion) to reach a loose hop is made on the previous hop defined 42 in the TE LSP path. This draft proposes a mechanism that allows: 44 - The TE LSP Head-end LSR to trigger a new ERO expansion on every 45 hop having a next hop defined as a loose hop, 47 - An LSR to signal to the TE LSP head-end that a better path exists 48 to reach a loose hop (than the current path in use). A better path 49 is defined as a path with a lower cost, where the cost is determined 50 by the metric used to compute the path. 52 This primarily applies to inter-area TE LSPs and inter-AS TE LSPs when 53 the path is defined as a list of loose hops (generally the loose hops 54 are the ABRs/ASBRs) but the following mechanism is also applicable to 55 any loosely routed explicit path within a single routing domain. 57 1. Establishment of a loosely routed explicit TE LSP path 59 A loosely routed explicit path is as a path specified as a combination 60 of strict and loose hop(s) that contains at least one loose hop and 61 zero or more strict hop(s). Loose hops are listed in the ERO object of 62 the RSVP Path message with the L flag of the Ipv4 prefix sub-object 63 set, as defined in [RSVP-TE]. In this case, each LSR along path can 64 perform a partial route computation to reach the next loose hop and 65 then performs an ERO expansion, before forwarding the RSVP Path message 66 downstream. 68 Note that the examples in the rest of this draft will be provided in 69 the context of MPLS inter-area TE but the proposed mechanism also 70 applies to loosely routed path within a single routing domain. 71 Furthermore, this mechanism could also be used in the context of 72 loosely routed paths in the context of TE LSPs spanning several 73 autonomous systems and as such abides by the requirements for inter-AS 74 TE define in [INTER-AS-TE-REQS] 75 The examples below will be provided with OSPF as the IGP but the 76 described mechanisms similarly apply to IS-IS. 78 An example of an explicit loosely routed TE LSP signalling (see also 79 [MULTI-AREA-TE scenario 1] 81 <---area 1--><-area 0--><-area 2-> 83 R1---R2----R3---R6 R8-----R10 85 Vasseur and Ikejiri 2 86 | | | / |\ | 87 | | | -- | --\ | 88 | | |/ | \| 89 |---R4----R5---R7----R9-----R11 91 Assumptions 92 - R3, R5, R8 and R9 are ABRs 93 - A TE LSP1 from R1 (Head-End LSR) to R11 (Tail-end LSR) is defined 94 with the following loosely routed path: R1-R3(loose)-R8(loose)- 95 R11(loose):R3, R8 and R11 are defined as loose hops. 97 Step 1: LSP 1's Head-end (R1) builds the following ERO object: R1(S)- 98 R2(S)-R3(S)-R8(L)-R11(L) 99 where: 100 S: Strict hop (L=0) 101 L: Loose hop (L=1) 102 The R1-R2-R3 path obeys the TE LSP1's set of constraints 104 Step 2: the RSVP Path message is then forwarded by R1 following the ERO 105 path and reaches R3 with the following content: R8(L)-R11(L) 107 Step 3: R3 determines that the next hop (R8) is a loose hop (not 108 directly connected to R3) and then performs an ERO expand operation to 109 reach the next loose hops R8. The new ERO becomes: R6(S)-R7(S)-R8(S)- 110 R11(L). 112 Step 4: the same procedure applies at R8. 113 ... 115 2. Reoptimization of a loosely routed explicit TE LSP path 117 Once the TE LSP is set up, it is maintained through normal RSVP 118 procedures. Then a more optimal path might appear between an LSR and 119 its next loose hop (suppose in the example above that a link between R6 120 and R8 is added that provides a shorter path between R3 and R8 (R3-R6- 121 R8) than the existing R3-R6-R7-R8 path). Currently, if the better path 122 is not visible from the Head-end LSR, it cannot make use of this better 123 path (and perform a make before break) when appropriate. This is for 124 instance the case in the example above as the better path does not 125 appear in the Head-end area. 127 This draft proposes a mechanism that allows: 129 - The TE LSP Head-end LSR to trigger on every LSR whose next 130 hop is a loose hop the re evaluation of the current path in 131 order to detect a potential more optimal path, 133 - An LSR whose next hop is a loose-hop to signal (using a new 134 ERROR-SPEC sub code carried in a Path Error Notify message) to 136 Vasseur and Ikejiri 3 137 the TE LSP head-end that a better path exists (a path with a 138 lower cost, where the cost is defined by the metric used to 139 compute the path - see [SEC-METRIC], [METRIC]). 141 Then once the existence of a better path is notified to the Head-end 142 LSR, it can perform a make before break. This allows the Head-end LSR 143 to reoptimize a TE LSP making use of the non disruptive make before 144 break procedure if and only if a better path exists. 146 3. Signalling extensions 148 3.1. ERO expansion signaling request 150 The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and 7) 151 is defined: 153 ERO Expansion request: 0x20 155 This flag indicates that a new ERO expansion is requested. 157 Note: in case of link bundling for instance, although the resulting ERO 158 might be identical, this might give the opportunity for a mid-point to 159 locally select another link within a bundle, although strictly 160 speaking, the ERO has not changed. 162 3.2. New Path Error sub-code 164 The format of a Path Error is the following: 166 ::= [ ] 168 170 [ ...] 172 [ ] 174 ::= (see earlier definition) 176 IPv4 ERROR_SPEC object: Class = 6, C-Type = 1 178 +-------------+-------------+-------------+-------------+ 179 | IPv4 Error Node Address (4 bytes) | 180 +-------------+-------------+-------------+-------------+ 181 | Flags | Error Code | Error Value | 182 +-------------+-------------+-------------+-------------+ 184 Vasseur and Ikejiri 4 185 Various Error Codes and Error values have been defined in RFC2205 and 186 RFC3209. 188 The ERROR-CODE 25 corresponds to a Path Error - Notify Error. We 189 propose to add three new sub-codes: 190 6 Better path exists 191 7 Local link maintenance required 192 8 Local node maintenance required 194 See details about Local maintenance required modes in section 4.3.2 196 4. Mode of operation 198 4.1. TE LSP reroute 200 The notification process of a better path is by nature de-correlated 201 from the reoptimization operation. In other words, the location where a 202 potentially more optimal path is discovered does not have to be where 203 the TE LSP is actually reoptimized. In particular, when a better path 204 is discovered one could conceivably envisage reoptimizing the TE LSP on 205 a mid-point LSR or on the Head-end LSR of the TE LSP. In the former 206 case, this would require some RSVP extensions but more importantly this 207 may not be desirable in some circumstances: indeed, the reoptimization 208 process inevitably generates some jitter, potentially packet 209 reordering. By the way, the only LSR having the complete view of the 210 end to end path and TE LSP set of attributes/constraints is the Head- 211 end LSR. For those reasons, this draft applies to the context of a 212 head-end LSR reoptimization. It is just worth mentioning that in some 213 other contexts, mid-point reoptimization may also be desirable. 214 4.2. Reoptimization triggers 216 There are two possible reoptimization triggers: 218 - Timer-based: a reoptimization is triggered (process 219 evaluating whether a more optimal path can be found) when a 220 configurable timer expires, 222 - Event-driven: a reoptimization is triggered when a 223 particular network event occurs (such as a "Link-UP" event). 225 4.3. Head-end reoptimization request versus mid-point reoptimization 226 indication 228 This draft defines two modes: 230 - The request for a new path evaluation of an explicit loosely 231 routed TE LSP is requested by the Head-end LSR. 233 Vasseur and Ikejiri 5 234 - A mid-point LSR having determined that a better path (than 235 the current path is use) exists or having the desire to perform 236 a link/node local maintenance explicitly notifies the head-end 237 LSR which will in turn perform a make before break. 239 4.3.1. Head-end reoptimization request 241 In this mode, when a timer-based reoptimization is triggered on the 242 head-end LSR or the operator manually requests a reoptimization, the 243 head-end LSR immediately sends a Path message with the "ERO Expansion 244 request" bit of the SESSION_ATTRIBUTE object set. This bit is then 245 cleared in subsequent RSVP path messages sent downstream. 247 Upon receiving a Path message with the "ERO expansion request" bit of 248 the SESSION_ATTRIBUTE object set, every LSR for which the next abstract 249 node contained in the ERO is defined as a loose hop, must perform the 250 following set of actions: 252 - A new ERO expansion is triggered and the newly computed path 253 is compared to the existing path: 255 - If a better path can be found, the LSR MUST 256 immediately send a Path Error to the head-end (Error 257 code 25 (Notify), sub-code=6 (better path exists)). At 258 this point, the LSR MAY decide to clear the ERO 259 expansion request bit of the SESSION-ATTRIBUTE object 260 in subsequent RSVP Path messages sent downstream: this 261 mode is the recommended mode. Indeed, the sending of a 262 Path Error Notify message "Better path exists" to the 263 Head-end LSR will trigger a Head-end reoptimization so 264 triggering ERO expansions on downstream nodes is 265 unnecessary. The only motivation to forward subsequent 266 RSVP Path messages with the "Expansion request bit" of 267 the SESSION-ATTRIBUTE object set would be to trigger 268 path re-evaluation on downstream nodes that could in 269 turn cache some potentially better paths downstream 270 with the objective to reduce the signaling delay of the 271 reoptimized TE LSP. 273 - No better path can be found: as previously stated, 274 the recommended mode is for an LSR to relay the request 275 (by setting the ERO expansion bit of the SESSION- 276 ATTRIBUTE object in RSVP path message sent downstream) 277 only if no better path has been found on this LSR. 279 Note: by better path, we mean a path having a lower cost. By default, 280 an LSR uses the IGP metric in their CSPF to detect the shortest path 281 that obeys a set of constraints. Note that the head-end might use the 282 METRIC-TYPE object (defined in [PATH-COMP]) in its path message to 284 Vasseur and Ikejiri 6 285 request the LSR having a next hop defined as a loose hop in the ERO to 286 use the TE metric to determine the best path. 288 Example 2: 290 Let call Ln the list of LSRs defined as loose hops in the ERO sent in 291 the Path message by the Head-end LSR: Ln=. Let's now 292 call Pn= the list of LSRs pi such that li is a next 293 (loose) hop of pi for i=1...n 295 <---area 1--><-area 0--><-area 2-> 297 R1---R2----R3---R6 R8-----R10 298 | | | / |\ | 299 | | | -- | --\ | 300 | | |/ | \| 301 |---R4----R5---R7----R9-----R11 303 A TE LSP1 from R1 (Head-End LSR) to R11 (Tail-end LSR) is defined with 304 the following loosely routed path: R1-R3(loose)-R8(loose)-R11(loose). 305 R3, R8 and R11 are defined as loose hops. 307 Ln= 308 Pn= 310 As soon as a positive response is received from an LSR pi (sub-code=6, 311 "Better path exists"), the Head-end LSR MUST perform a make before 312 break. 314 Note that if the Path message with the ERO expansion request bit set of 315 the SESSION-ATTRIBUTE object is lost, then the next request will be 316 sent when the reoptimization event will trigger on the Head-end LSR. 317 The solution to handle RSVP reliable messaging has been defined in 318 [REFRESH-REDUCTION]. 320 4.3.2. Mid-point reoptimization indication 322 In this mode, an LSR whose next abstract node is a loose hop can 323 locally trigger an ERO expansion (when a configurable timer expires or 324 on event-driven basis (link-up event for example) or the user 325 explicitly requests it). If a better path is found compared to the 326 existing one, the LSR sends a Path Error to the head-end (Error code 25 327 (Notify), sub-code=6 (better path exists)). The Head-end LSR MUST then 328 immediately perform a make before break. 330 There are other circumstance by which a mid-point may send an RSVP Path 331 Error Notify message with the objective for the TE LSP to be rerouted 332 by its Head-end LSR: when a link or a node will go down for local 333 maintenance reasons. In this case, the mid-point on which the local 335 Vasseur and Ikejiri 7 336 maintenance must be performed is responsible for sending an RSVP Path 337 Error Notify message with the sub-code=7 or 8 depending on the affected 338 network element (link or node). Then the first upstream node having 339 performed the ERO expansion MUST perform the following set of actions: 341 - The link (sub-code=7) or the node (sub-code=8) must be 342 locally registered for further reference (the TE database must 343 be updated) 345 - The RSVP Path Error message MUST be immediately forwarded 346 unchanged upstream to the Head-end LSR. 348 Upon, receiving a Path Error Notify message with sub-code 7 or 8, the 349 Head-end LSR MUST perform a make before break. 351 Note that those modes are not exclusive: both the timer and even-driven 352 reoptimization triggers can be implemented on the Head-end and/or any 353 mid-point LSR with potentially different timer values for the timer 354 driven reoptimization case. 356 4.3.3. ERO caching 358 Once a mid-point LSR has determined that a better path exists (after a 359 reoptimization request has been received by the Head-end LSR or the 360 reoptimization timer on the mid-point has fired), the more optimal path 361 MAY be cached on the mid-point for a limited amount of time to avoid 362 having to recompute a route once the Head-LSR performs a make before 363 break. This mode is optional. 365 5. Interoperability 367 An LSR non supporting the "ERO expansion request" bit of the SESSION- 368 ATTRIBUTE object SHOULD just ignore it. 370 Any Head-end LSR non supporting this draft receiving a Path Error 371 Notify message with sub-code = 6, 7 or 8MUST just silently ignore the 372 Path message. 374 6. Security Considerations 376 The practice described in this draft does not raise specific security 377 issues beyond those of existing TE. 379 7. Acknowledgment 381 Vasseur and Ikejiri 8 382 The authors would like to thank Carol Iturralde, Miya Kohno, Francois 383 Le Faucheur, Philip Matthews and Jim Gibson for their useful and 384 valuable comments. 386 8. Intellectual Property 388 The contributor represents that he has disclosed the existence of any 389 proprietary or intellectual property rights in the contribution that 390 are reasonably and personally known to the contributor. The 391 contributor does not represent that he personally knows of all 392 potentially pertinent proprietary and intellectual property rights 393 owned or claimed by the organization he represents (if any) or third 394 parties. 396 References 398 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over MPLS, 399 RFC2702, September 1999. 401 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft- 402 katz-yeung-ospf-traffic-05.txt, June 2001. 404 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 405 ietf-isis-traffic-03.txt, June 2001. 407 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 408 RFC3209, December 2001. 410 [METRICS] Fedyk et al, "Multiple Metrics for Traffic Engineering with 411 IS-IS and OSPF", draft-fedyk-isis-ospf-te-metrics-01.txt, November 412 2000. 414 [DS-TE] Le Faucheur et al, "Requirements for support of Diff-Serv-aware 415 MPLS Traffic Engineering", draft-ietf-tewg-diff-te-reqts-01.txt, June 416 2001. 418 [MULTI-AREA-TE] Kompella at all, "Multi-area MPLS Traffic Engineering", 419 draft-kompella-mpls-multiarea-te-03.txt, June 2002. 421 [PATH-COMP] Vasseur et al, "RSVP Path computation request and reply 422 messages", draft-vasseur-mpls-computation-rsvp-03.txt, June 2002. 424 [SEC-METRIC] Le Faucheur et all," Use of Interior Gateway Protocol 425 (IGP) Metric as a second MPLS Traffic Engineering Metric", draft-ietf- 426 tewg-te-metric-igp-02.txt, September, 2002. 428 [INTER-AS-TE-REQS] Zhang et al, "MPLS Inter-AS Traffic Engineering 429 requirements", draft-ietf-tewg-interas-mpls-te-req-00.txt, June 2003, 430 Work in progress. 432 Vasseur and Ikejiri 9 433 [INTER-AS-TE] Vasseur and Zhang, "MPLS Inter-AS Traffic Engineering", 434 draft-vasseur-inter-as-te-00.txt, February 2003, work in progress. 436 [REFRESH-REDUCTION] Berger et al, "RSVP Refresh Overhead Reduction 437 Extensions", April 2001 439 Authors' addresses: 441 Jean Philippe Vasseur 442 Cisco Systems, Inc. 443 300 Beaver Brook Road 444 Boxborough , MA - 01719 445 USA 446 Email: jpv@cisco.com 448 Yuichi Ikejiri 449 NTT Communications Corporation 450 1-1-6, Uchisaiwai-cho, Chiyoda-ku 451 Tokyo 100-8019 452 JAPAN 453 Email: y.ikejiri@ntt.com 455 Vasseur and Ikejiri 10