idnits 2.17.1 draft-ietf-tewg-te-metric-igp-00.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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 148 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) ** 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-06 == 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') == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-05 -- Possible downref: Normative reference to a draft: ref. 'METRICS' == Outdated reference: A later version (-07) exists of draft-ietf-tewg-diff-te-reqts-02 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-diff-te-reqts (ref. 'DS-TE') -- No information found for draft-vasseur-mpls-path-computation-rsvp- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PATH-COMP' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-lsp-hierarchy-04 Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 5 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: September, 2002 15 Document: draft-ietf-tewg-te-metric-igp-00.txt March, 2002 17 Use of IGP Metric as a second TE Metric 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are 23 Working documents of the Internet Engineering Task Force (IETF), its 24 areas, and its working groups. Note that other groups may also 25 distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This draft describes a common practice on how the existing IGP 40 Metric can be used as an alternative metric to the TE Metric for 41 Constraint Based Routing of MPLS TE Tunnels. This effectively 42 results in the ability to perform Constraint Based Routing with 43 optimization of one metric (e.g. link bandwidth) for some TE Tunnels 44 (e.g. Data Trunks) while optimizing another metric (e.g. propagation 45 delay) for some other TE Tunnels with different requirements (e.g. 46 Voice Trunks). 48 No protocol extensions or modifications are required. This text 49 documents current router implementations and deployment practices. 51 Le Faucheur, et. al 1 53 IGP Metric as second TE Metric March 2002 55 1. Introduction 57 IGP routing protocols (OSPF and IS-IS) as well as MPLS Signaling 58 protocols (RSVP-TE and CR-LDP) have been extended (as specified in 59 [ISIS-TE], [OSPF-TE], [RSVP-TE] and [CR-LDP]) in order to support 60 the traffic engineering functionality as defined in [TE-REQ]. 62 These IGP routing protocol extensions currently include 63 advertisement of a single additional TE Metric to be used for 64 Constraint Based Routing of TE Tunnels. 66 However, the objective of traffic engineering is to optimize the use 67 and the performance of the network. So it seems relevant that TE 68 tunnel placement may be optimized according to different 69 optimization criteria. For example, some Service Providers want to 70 perform traffic engineering of different classes of service 71 separately so that each class of Service is transported on a 72 different TE Tunnel. One example motivation for doing so is to apply 73 different fast restoration policies to the different classes of 74 service. Another example motivation is to take advantage of separate 75 Constraint Based Routing in order to meet the different QoS 76 objectives of each Class of Service. To achieve different QoS 77 objectives may require enforcement by Constraint Based Routing of 78 different bandwidth constraints for the different classes of service 79 as defined in [DS-TE]. In some Service Provider environments, it 80 also requires optimizing on a different metric during Constraint 81 Based Routing. 83 The most common scenario for a different metric calls for 84 optimization of a metric reflecting delay (mainly propagation delay) 85 when Constraint Based Routing TE LSPs that will be transporting 86 voice, while optimizing a more usual metric (e.g. reflecting link 87 bandwidth) when Constraint Based Routing TE LSPs that will be 88 transporting data. 90 [METRICS] proposes extensions so that multiple TE Metrics can be 91 advertised in the IGP. If/once those are fully specified and 92 implemented, they will address the above scenario. However this 93 draft describes how the above scenario is currently addressed in the 94 meantime by existing implementations and deployments, without any 95 additional IGP extensions beyond [ISIS-TE] and [OSPF-TE], by 96 effectively using the IGP Metric as a "second" TE Metric. 98 2. Common Practice 100 In current MPLS TE deployments, network administrators often want 101 Constraint Based Routing of TE LSPs carrying data traffic to be 102 based on the same metric as the metric used for Shortest Path 104 Le Faucheur et. al 2 106 IGP Metric as second TE Metric March 2002 108 Routing. Where this is the case, this practice allows the Constraint 109 Based Routing algorithm running on the Head-End LSR to use the IGP 110 Metric advertised in the IGP to compute paths for data TE LSPs 111 instead of the advertised TE Metric. The TE Metric can then be used 112 to convey another metric (e.g. a delay-based metric) which can be 113 used by the Constraint Based Routing algorithm on the Head-End LSR 114 to compute path for the TE LSPs with different requirements (e.g. 115 Voice TE LSP). 117 In some networks, network administrators configure the IGP metric to 118 a value factoring the link propagation delay. In that case, this 119 practice allows the Constraint Based Routing algorithm running on 120 the Head-End LSR to use the IGP Metric advertised in the IGP to 121 compute paths for delay-sensitive TE LSPs (e.g. Voice TE LSPs) 122 instead of the advertised TE Metric. The TE Metric can then be used 123 to convey another metric (e.g. bandwidth based metric) which can be 124 used by the Constraint Based Routing algorithm to compute paths for 125 the data TE LSPs. 127 More generally, the TE Metric can be used to carry any arbitrary 128 metric that may be useful for Constraint Based Routing of the set of 129 LSPs which need optimization on another metric than the IGP metric. 131 2.1. Head-End LSR Implementation Practice 133 A Head-End LSR implements the current practice by: 135 (i) Allowing configuration, for each TE LSP to be routed, of 136 whether the IGP Metric or the TE Metric is to be used by the 137 Constraint Based Routing algorithm. 139 (ii) Enabling the Constraint Based Routing algorithm to make use 140 of either the TE Metric or the IGP Metric, depending on the 141 above configuration for the considered TE-LSP 143 2.2. Network Deployment Practice 145 A Service Provider deploys this practice by: 147 (i) Configuring, on every relevant link, the TE Metric to reflect 148 whatever metric is appropriate (e.g. delay-based metric) for 149 Constraint Based Routing of some LSPs as an alternative 150 metric to the IGP Metric 152 (ii) Configuring, for every TE LSP, whether this LSP is to be 153 constraint based routed according to the TE Metric or IGP 154 Metric 156 2.3. Constraints 158 The practice described in this document has the following 159 constraints: 161 Le Faucheur et. al 3 163 IGP Metric as second TE Metric March 2002 165 (i) it only allows TE Tunnels to be routed on either of two 166 metrics (i.e. it cannot allow TE Tunnels to be routed on one 167 of three, or more, metrics). [METRICS] proposes extensions 168 which could be used to relax this constraints when necessary. 170 (ii) it can only be used where the IGP Metric is appropriate as 171 one of the two metrics to be used for constraint based 172 routing (i.e. it cannot allow TE Tunnels to be routed on 173 either of two metrics while allowing IGP SPF to be based on a 174 third metric). [METRICS] proposes extensions which could be 175 used to relax this constraint when necessary. 177 (iii) it can only be used on links which support an IGP adjacency 178 so that an IGP Metric is indeed advertised for the link. For 179 example, this practice can not be used on Forwarding 180 Adjacencies (see [LSP-HIER]). 182 Note that, as with [METRICS], this practice does not recommend that 183 the TE Metric and the IGP metric be used simultaneously during path 184 computation for a given LSP. This is known to be an NP-complete 185 problem. 187 2.4. Interoperability 189 Where path computation is entirely performed by the Head-End (e.g. 190 intra-area operations with path computation on Head-end), this 191 practice does not raise any interoperability issue among LSRs since 192 the use of one metric or the other is a matter purely local to the 193 Head-End LSR. 195 Where path computation involves another component than the Head-End 196 (e.g. with inter-area operations where path computation is shared 197 between the Head-End and Area Boundary Routers or a Path Computation 198 Server), this practice requires that which metric to optimize on be 199 signaled along with the other constraints (bandwidth, affinity) for 200 the LSP. See [PATH-COMP] for a proposal on how to signal which 201 metric to optimize to another component involved in path computation 202 when RSVP-TE is used as the protocol to signal path computation 203 information. 205 3. Migration Considerations 207 Service Providers need to consider how to migrate from the current 208 implementation to the new one supporting this practice. 210 Although the head-end routers act independently from each other, 211 some migration scenarios may require that all head-end routers be 212 upgraded to the new implementation to avoid any disruption on 213 existing TE-LSPs before two metrics can effectively be used by TE. 214 The reason is that routers with current implementation are expected 216 Le Faucheur et. al 4 218 IGP Metric as second TE Metric March 2002 220 to always use the TE metric for Constraint Based Routing of all 221 tunnels; so when the TE metric is reconfigured to reflect the 222 "second metric" (say to a delay-based metric) on links in the 223 network, then all TE-LSPs would get routed based on the "second 224 metric" metric, while the intent may be that only the TE-LSPs 225 explicitly configured so should be routed based on the "second 226 metric". 228 A possible migration scenario would look like this: 230 1) upgrade software on all head-end routers in the network to 231 support this practice. 233 2) change the TE-LSPs configuration on the head-end routers to 234 use the IGP metric (e.g. bandwidth-based) for Constraint 235 Based Routing rather than the TE metric. 237 3) configure TE metric on the links to reflect the "second 238 metric" (e.g. delay-based). 240 4) modify the LSP configuration of the subset of TE-LSPs which 241 need to be Constraint Based routed using the "second metric" 242 (e.g. delay-based), and/or create new TE-LSPs with such a 243 configuration. 245 It is desirable that step 2 is non-disruptive (i.e. the routing of a 246 LSP will not be affected in any way, and the data transmission will 247 not be interrupted) by the change of LSP configuration to use "IGP 248 Metric" as long as the actual value of the "IGP Metric" and "TE 249 Metric" are equal on every link at the time of LSP reconfiguration 250 (as would be the case at step 2 in migration scenario above which 251 assumed that TE Metric was initially equal to IGP Metric). 253 4. Security Considerations 255 The practice described in this draft does not raise specific 256 security issues beyond those of existing TE. 258 5. Acknowledgment 260 This document has benefited from discussion with Jean-Philippe 261 Vasseur. 263 References 265 [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 266 MPLS, RFC2702, September 1999. 268 Le Faucheur et. al 5 270 IGP Metric as second TE Metric March 2002 272 [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 273 draft-katz-yeung-ospf-traffic-06.txt, October 2001. 275 [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- 276 ietf-isis-traffic-03.txt, June 2001. 278 [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 279 Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001. 281 [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 282 draft-ietf-mpls-cr-ldp-05.txt, February 2001 284 [METRICS] Fedyk et al, "Multiple Metrics for Traffic Engineering 285 with IS-IS and OSPF", draft-fedyk-isis-ospf-te-metrics-01.txt, 286 November 2000. 288 [DS-TE] Le Faucheur et al, "Requirements for support of Diff-Serv- 289 aware MPLS Traffic Engineering", draft-ietf-tewg-diff-te-reqts- 290 02.txt, November 2001. 292 [PATH-COMP] Vasseur et al, "RSVP Path computation request and reply 293 messages", draft-vasseur-mpls-path-computation-rsvp- 01.txt, 294 November 2001. 296 [LSP-HIER] Kompella et al, "LSP Hierarchy with Generalized MPLS TE", 297 draft-ietf-mpls-lsp-hierarchy-04.txt, February 2002. 299 Authors' Address: 301 Francois Le Faucheur 302 Cisco Systems, Inc. 303 Village d'Entreprise Green Side - Batiment T3 304 400, Avenue de Roumanille 305 06410 Biot-Sophia Antipolis 306 France 307 Phone: +33 4 97 23 26 19 308 Email: flefauch@cisco.com 310 Ramesh Uppili 311 Cisco Systems, Inc. 312 300 Apollo Drive 313 Chelmsford, Massachussets 01824 314 USA 315 Phone: +1 978 244-4949 316 Email: ruppili@cisco.com 318 Alain Vedrenne 319 EQUANT 320 400 Galleria Parkway 321 Atlanta, Georgia 30339 323 Le Faucheur et. al 6 325 IGP Metric as second TE Metric March 2002 327 USA 328 Phone: +1 (678)-346-3466 329 Email: alain.vedrenne@equant.com 331 Pierre Merckx 332 EQUANT 333 1041 route des Dolines - BP 347 334 06906 SOPHIA ANTIPOLIS Cedex 335 FRANCE 336 Phone: +33 (0)492 96 6454 337 Email: pierre.merckx@equant.com 339 Thomas Telkamp 340 Global Crossing 341 Olympia 6 342 1213 NP Hilversum 343 The Netherlands 344 Phone: +31 35 655 651 345 E-mail: telkamp@gblx.net 347 Le Faucheur et. al 7