idnits 2.17.1 draft-ietf-tewg-te-metric-igp-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 462 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 152 has weird spacing: '...hatever metri...' -- 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: 'DS-TE' is mentioned on line 82, but not defined == Unused Reference: 'DIFF-TE' is defined on line 299, 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-07 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-reqts-05 -- No information found for draft-vasseur-mpls-path-computation-rsvp - is the name correct? == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-07 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Francois Le Faucheur 3 Ramesh Uppili 4 Cisco Systems, Inc. 6 Alain Vedrenne 7 Pierre Merckx 8 Equant 10 Thomas Telkamp 11 Global Crossing 13 IETF Internet Draft 14 Expires: March, 2003 15 Document: draft-ietf-tewg-te-metric-igp-02.txt September, 2002 17 Use of Interior Gateway Protocol (IGP) Metric as a second 18 MPLS Traffic Engineering Metric 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. Internet-Drafts are 24 Working documents of the Internet Engineering Task Force (IETF), its 25 areas, and its working groups. Note that other groups may also 26 distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document describes a common practice on how the existing metric 41 of Interior Gateway Protocols (IGP) can be used as an alternative 42 metric to the Traffic Engineering (TE) metric for Constraint Based 43 Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering 44 tunnels. This effectively results in the ability to perform 45 Constraint Based Routing with optimization of one metric (e.g. link 46 bandwidth) for some Traffic Engineering tunnels (e.g. Data Trunks) 47 while optimizing another metric (e.g. propagation delay) for some 48 other tunnels with different requirements (e.g. Voice Trunks). 50 Le Faucheur, et. al 1 52 IGP Metric as second TE Metric September 2002 54 No protocol extensions or modifications are required. This text 55 documents current router implementations and deployment practices. 57 1. Introduction 59 Interior Gateway Protocol (IGP) routing protocols (OSPF and IS-IS) 60 as well as MultiProtocol Label Switching (MPLS) signaling protocols 61 (RSVP-TE and CR-LDP) have been extended (as specified in [ISIS-TE], 62 [OSPF-TE], [RSVP-TE] and [CR-LDP]) in order to support the Traffic 63 Engineering (TE) functionality as defined in [TE-REQ]. 65 These IGP routing protocol extensions currently include 66 advertisement of a single additional MPLS TE metric to be used for 67 Constraint Based Routing of TE tunnels. 69 However, the objective of traffic engineering is to optimize the use 70 and the performance of the network. So it seems relevant that TE 71 tunnel placement may be optimized according to different 72 optimization criteria. For example, some Service Providers want to 73 perform traffic engineering of different classes of service 74 separately so that each class of Service is transported on a 75 different TE tunnel. One example motivation for doing so is to apply 76 different fast restoration policies to the different classes of 77 service. Another example motivation is to take advantage of separate 78 Constraint Based Routing in order to meet the different Quality of 79 Service (QoS) objectives of each Class of Service. Depending on QoS 80 objectives one may require either (a) enforcement by Constraint 81 Based Routing of different bandwidth constraints for the different 82 classes of service as defined in [DS-TE], or (b) optimizing on a 83 different metric during Constraint Based Routing or (c) both. This 84 document discusses how optimizing on a different metric can be 85 achieved during Constraint Based Routing. 87 The most common scenario for a different metric calls for 88 optimization of a metric reflecting delay (mainly propagation delay) 89 when Constraint Based Routing TE Label Switched Paths (LSPs) that 90 will be transporting voice, while optimizing a more usual metric 91 (e.g. reflecting link bandwidth) when Constraint Based Routing TE 92 LSPs that will be transporting data. 94 Additional IGP protocol extensions could be defined so that multiple 95 TE metrics could be advertised in the IGP (as proposed for example 96 in [METRICS]) and would thus be available to Constraint Based 97 Routing in order to optimize on a different metric. However this 98 document describes how optimizing on a different metric can be 99 achieved today by existing implementations and deployments, without 100 any additional IGP extensions beyond [ISIS-TE] and [OSPF-TE], by 101 effectively using the IGP metric as a "second" TE metric. 103 2. Common Practice 105 Le Faucheur et. al 2 107 IGP Metric as second TE Metric September 2002 109 In current MPLS TE deployments, network administrators often want 110 Constraint Based Routing of TE LSPs carrying data traffic to be 111 based on the same metric as the metric used for Shortest Path 112 Routing. Where this is the case, this practice allows the Constraint 113 Based Routing algorithm running on the Head-End LSR to use the IGP 114 metric advertised in the IGP to compute paths for data TE LSPs 115 instead of the advertised TE metric. The TE metric can then be used 116 to convey another metric (e.g. a delay-based metric) which can be 117 used by the Constraint Based Routing algorithm on the Head-End LSR 118 to compute path for the TE LSPs with different requirements (e.g. 119 Voice TE LSP). 121 In some networks, network administrators configure the IGP metric to 122 a value factoring the link propagation delay. In that case, this 123 practice allows the Constraint Based Routing algorithm running on 124 the Head-End LSR to use the IGP metric advertised in the IGP to 125 compute paths for delay-sensitive TE LSPs (e.g. Voice TE LSPs) 126 instead of the advertised TE metric. The TE metric can then be used 127 to convey another metric (e.g. bandwidth based metric) which can be 128 used by the Constraint Based Routing algorithm to compute paths for 129 the data TE LSPs. 131 More generally, the TE metric can be used to carry any arbitrary 132 metric that may be useful for Constraint Based Routing of the set of 133 LSPs which need optimization on another metric than the IGP metric. 135 2.1. Head-End LSR Implementation Practice 137 A Head-End LSR implements the current practice by: 139 (i) Allowing configuration, for each TE LSP to be routed, of 140 whether the IGP metric or the TE metric is to be used by the 141 Constraint Based Routing algorithm. 143 (ii) Enabling the Constraint Based Routing algorithm to make use 144 of either the TE metric or the IGP metric, depending on the 145 above configuration for the considered TE-LSP 147 2.2. Network Deployment Practice 149 A Service Provider deploys this practice by: 151 (i) Configuring, on every relevant link, the TE metric to reflect 152 whatever metric is appropriate (e.g. delay-based metric) for 153 Constraint Based Routing of some LSPs as an alternative 154 metric to the IGP metric 156 (ii) Configuring, for every TE LSP, whether this LSP is to be 157 constraint based routed according to the TE metric or IGP 158 metric 160 Le Faucheur et. al 3 162 IGP Metric as second TE Metric September 2002 164 2.3. Constraints 166 The practice described in this document has the following 167 constraints: 169 (i) it only allows TE tunnels to be routed on either of two 170 metrics (i.e. it cannot allow TE tunnels to be routed on one 171 of three, or more, metrics). Extensions (for example such as 172 those proposed in [METRICS]) could be defined in the future 173 if necessary to relax this constraints, but this is outside 174 the scope of this document. 176 (ii) it can only be used where the IGP metric is appropriate as 177 one of the two metrics to be used for constraint based 178 routing (i.e. it cannot allow TE tunnels to be routed on 179 either of two metrics while allowing IGP SPF to be based on a 180 third metric). Extensions (for example such as those proposed 181 in [METRICS]) could be defined in the future if necessary to 182 relax this constraints, but this is outside the scope of this 183 document. 185 (iii) it can only be used on links which support an IGP adjacency 186 so that an IGP metric is indeed advertised for the link. For 187 example, this practice can not be used on Forwarding 188 Adjacencies (see [LSP-HIER]). 190 Note that, as with [METRICS], this practice does not recommend that 191 the TE metric and the IGP metric be used simultaneously during path 192 computation for a given LSP. This is known to be an NP-complete 193 problem. 195 2.4. Interoperability 197 Where path computation is entirely performed by the Head-End (e.g. 198 intra-area operations with path computation on Head-end), this 199 practice does not raise any interoperability issue among LSRs since 200 the use of one metric or the other is a matter purely local to the 201 Head-End LSR. 203 Where path computation involves another component than the Head-End 204 (e.g. with inter-area operations where path computation is shared 205 between the Head-End and Area Boundary Routers or a Path Computation 206 Server), this practice requires that which metric to optimize on, be 207 signaled along with the other constraints (bandwidth, affinity) for 208 the LSP. See [PATH-COMP] for an example proposal on how to signal 209 which metric to optimize, to another component involved in path 210 computation when RSVP-TE is used as the protocol to signal path 211 computation information. 213 3. Migration Considerations 215 Le Faucheur et. al 4 217 IGP Metric as second TE Metric September 2002 219 Service Providers need to consider how to migrate from the current 220 implementation to the new one supporting this practice. 222 Although the head-end routers act independently from each other, 223 some migration scenarios may require that all head-end routers be 224 upgraded to the new implementation to avoid any disruption on 225 existing TE-LSPs before two metrics can effectively be used by TE. 226 The reason is that routers with current implementation are expected 227 to always use the TE metric for Constraint Based Routing of all 228 tunnels; so when the TE metric is reconfigured to reflect the 229 "second metric" (say to a delay-based metric) on links in the 230 network, then all TE-LSPs would get routed based on the "second 231 metric" metric, while the intent may be that only the TE-LSPs 232 explicitly configured so should be routed based on the "second 233 metric". 235 A possible migration scenario would look like this: 237 1) upgrade software on all head-end routers in the network to 238 support this practice. 240 2) change the TE-LSPs configuration on the head-end routers to 241 use the IGP metric (e.g. bandwidth-based) for Constraint 242 Based Routing rather than the TE metric. 244 3) configure TE metric on the links to reflect the "second 245 metric" (e.g. delay-based). 247 4) modify the LSP configuration of the subset of TE-LSPs which 248 need to be Constraint Based routed using the "second metric" 249 (e.g. delay-based), and/or create new TE-LSPs with such a 250 configuration. 252 It is desirable that step 2 is non-disruptive (i.e. the routing of a 253 LSP will not be affected in any way, and the data transmission will 254 not be interrupted) by the change of LSP configuration to use "IGP 255 metric" as long as the actual value of the "IGP metric" and "TE 256 metric" are equal on every link at the time of LSP reconfiguration 257 (as would be the case at step 2 in migration scenario above which 258 assumed that TE metric was initially equal to IGP metric). 260 4. Security Considerations 262 The practice described in this document does not raise specific 263 security issues beyond those of existing TE. Those are discussed in 264 the respective security sections of [TE-REQ], [RSVP-TE] and [CR- 265 LDP]. 267 5. Acknowledgment 269 Le Faucheur et. al 5 271 IGP Metric as second TE Metric September 2002 273 This document has benefited from discussion with Jean-Philippe 274 Vasseur. 276 6. Normative References 278 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 279 MPLS, RFC2702, September 1999. 281 [OSPF-TE] Katz et al, Traffic Engineering Extensions to OSPF Version 282 2, draft-katz-yeung-ospf-traffic-07.txt, August 2002. 284 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 285 ietf-isis-traffic-04.txt, August 2001. 287 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 288 Tunnels", RFC3209, December 2001. 290 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 291 RFC3212, January 2002 293 7. Informative References 295 [METRICS] Fedyk et al, "Multiple Metrics for Traffic Engineering 296 with IS-IS and OSPF", draft-fedyk-isis-ospf-te-metrics-01.txt, 297 November 2000. 299 [DIFF-TE] Le Faucheur et al, "Requirements for support of Diff-Serv- 300 aware MPLS Traffic Engineering", draft-ietf-tewg-diff-te-reqts- 301 05.txt, June 2002. 303 [PATH-COMP] Vasseur et al, "RSVP Path computation request and reply 304 messages", draft-vasseur-mpls-path-computation-rsvp-03.txt, June 305 2002. 307 [LSP-HIER] Kompella et al, "LSP Hierarchy with Generalized MPLS TE", 308 draft-ietf-mpls-lsp-hierarchy-07.txt, June 2002. 310 Authors' Address: 312 Francois Le Faucheur 313 Cisco Systems, Inc. 314 Village d'Entreprise Green Side - Batiment T3 315 400, Avenue de Roumanille 316 06410 Biot-Sophia Antipolis 317 France 318 Phone: +33 4 97 23 26 19 319 Email: flefauch@cisco.com 321 Ramesh Uppili 323 Le Faucheur et. al 6 325 IGP Metric as second TE Metric September 2002 327 Cisco Systems, Inc. 328 300 Apollo Drive 329 Chelmsford, Massachussets 01824 330 USA 331 Phone: +1 978 244-4949 332 Email: ruppili@cisco.com 334 Alain Vedrenne 335 EQUANT 336 400 Galleria Parkway 337 Atlanta, Georgia 30339 338 USA 339 Phone: +1 (678)-346-3466 340 Email: alain.vedrenne@equant.com 342 Pierre Merckx 343 EQUANT 344 1041 route des Dolines - BP 347 345 06906 SOPHIA ANTIPOLIS Cedex 346 FRANCE 347 Phone: +33 (0)492 96 6454 348 Email: pierre.merckx@equant.com 350 Thomas Telkamp 351 Global Crossing 352 Oudkerkhof 51 353 3512 GJ Utrecht 354 The Netherlands 355 Phone: +31 30 238 1250 356 E-mail: telkamp@gblx.net 358 Le Faucheur et. al 7