idnits 2.17.1 draft-ietf-rtgwg-igp-shortcut-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 5) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 254 has weird spacing: '...for the purpo...' -- 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.) -- The document date (April 2004) is 7315 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Naiming Shen 2 INTERNET DRAFT Redback Networks 3 Category: Informational Henk Smit 4 Expiration Date: October 2004 5 April 2004 7 Calculating IGP Routes Over Traffic Engineering Tunnels 9 draft-ietf-rtgwg-igp-shortcut-00.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 This document describes how conventional hop-by-hop link-state 35 routing protocols interact with new Traffic Engineering capabilities 36 to create IGP shortcuts. In particular this document describes how 37 Dijkstra's SPF algorithm should be adapted so that link-state IGPs 38 will calculate IP routes to forward traffic over tunnels that are 39 set up by Traffic Engineering. 41 3. Introduction 43 Link-state protocols like integrated IS-IS [1] and OSPF [2] use 44 Dijkstra's SPF algorithm to compute a shortest path tree to all nodes 45 in the network. Routing tables are derived from this shortest path 46 tree. The routing tables contain tuples of destination and first-hop 47 information. If a router does normal hop-by-hop routing, the first- 48 hop will be a physical interface attached to the router. 49 New traffic engineering algorithms calculate explicit routes to one 50 or more nodes in the network. At the router that originates explicit 51 routes, such routes can be viewed as logical interfaces which supply 52 Label Switched Paths through the network. In the context of this 53 document we refer to these Label Switched Paths as Traffic 54 Engineering tunnels (TE-tunnels). Such capabilities are specified 55 in [3] and [4]. 57 This document describes how Link-state IGPs can make use of these 58 shortcuts, and how they can install routes in the routing table that 59 point out over these TE-tunnels. Because these tunnels use explicit 60 routes, the path taken by a TE-tunnel is controlled by the router 61 that is the head-end of the tunnel. In the absence of errors, TE- 62 tunnels are guaranteed not to loop. But routers must agree on how to 63 use TE-tunnels. Otherwise traffic might loop via two or more tunnels. 65 4. Enhancement to the Shortest Path First computation 67 During each step of the SPF computation, a router discovers the path 68 to one node in the network. If that node is directly connected to the 69 calculating router, the first-hop information is derived from the 70 adjacency database. If a node is not directly connected to the 71 calculating router, it inherits the first-hop information from the 72 parent(s) of that node. Each node has one or more parents. Each node 73 is the parent of zero or more down-stream nodes. 75 For traffic engineering purposes each router maintains a list of all 76 TE-tunnels that originate at this router. For each of those TE- 77 tunnel, the router at the tail-end is known. 79 During SPF, when a router finds the path to a new node (in other 80 words, this new node is moved from the TENTative list to the PATHS 81 list), the router must determine the first-hop information. There 82 are three possible ways to do this: 84 - Examine the list of tail-end routers directly reachable via a 85 TE-tunnel. If there is a TE-tunnel to this node, we use the 86 TE-tunnel as the first-hop. 88 - If there is no TE-tunnel, and the node is directly connected, we 89 will use the first-hop information from the adjacency database. 91 - If the node is not directly connected, and is not directly 92 reachable via a TE-tunnel, we will copy the first-hop 93 information from the parent node(s) to the new node. 95 The result of this algorithm is that traffic to nodes that are the 96 tail-end of TE-tunnels, will flow over those TE-tunnels. Traffic to 97 nodes that are downstream of the tail-end nodes will also flow over 98 those TE-tunnels. If there are multiple TE-tunnels to different 99 intermediate nodes on the path to destination node X, traffic will 100 flow over the TE-tunnel whose tail-end node is closest to node X. 101 In certain applications, there is a need to carry both the native 102 adjacency and the TE-tunnel next-hop information for the TE-tunnel 103 tail-end and its downstream nodes. The head-end node may 104 conditionally switch the data traffic onto TE-tunnels based on 105 user defined criteria or events; The head-end node may also split 106 flow of traffic towards either types of the next-hops; The head-end 107 node may install the routes with two different types of next-hops 108 into two separate RIBs. Multicast protocols running over physical 109 links may have to perform RPF checks using the native adjacency 110 next-hops rather than the TE-tunnel next-hops. 112 5. Special cases and exceptions 114 The Shortest Path First algorithm will find equal-cost parallel paths 115 to destinations. The enhancement described in this document does not 116 change this. Traffic can be forwarded over one or more native IP 117 paths, over one or more TE-tunnels, or over a combination of native 118 IP paths and TE-tunnels. 120 A special situation occurs in the following topology: 122 rtrA -- rtrB -- rtrC 123 | | 124 rtrD -- rtrE 126 Assume all links have the same cost. Assume a TE-tunnel is set up 127 from rtrA to rtrD. When the SPF calculation puts rtrC on the 128 TENTative list, it will realize that rtrC is not directly connected, 129 and thus it will use the first-hop information from the parent. Which 130 is rtrB. When the SPF calculation on rtrA moves rtrD from the 131 TENTative list to the PATHS list, it realizes that rtrD is the 132 tail-end of a TE-tunnel. Thus rtrA will install a route to rtrD via 133 the TE-tunnel, and not via rtrB. 135 When rtrA puts rtrE on the TENTative list, it realizes that rtrE is 136 not directly connected, and that rtrE is not the tail-end of a TE- 137 tunnel. Therefor rtrA will copy the first-hop information from the 138 parents (rtrC and rtrD) to the first-hop information of rtrE. 139 Traffic to rtrE will now load-balance over the native IP path via 140 rtrA->rtrB->rtrC, and the TE-tunnel rtrA->rtrD. 142 In the case where both parallel native IP paths and paths over TE- 143 tunnels are available, implementations can allow the network 144 administrator to force traffic to flow over only TE-tunnels (or only 145 over native IP paths) or both to be used for load sharing. 147 6. Metric adjustment of IP routes over TE-tunnels 149 When an IGP route is installed in the routing table with a TE-tunnel 150 as next hop, an interesting question is what should be the cost or 151 metric of this route ? The most obvious answer is to assign a metric 152 that is the same as the IGP metric of the native IP path as if the 153 TE-tunnels did not exist. For example, rtrA can reach rtrC over a 154 path with a cost of 20. X is an IP prefix advertised by rtrC. We 155 install the route to X in rtrA's routing table with a cost of 20. 156 When a TE-tunnel from rtrA to rtrC comes up, by default the route is 157 still installed with metric of 20, only the next-hop information for 158 X is changed. 160 While this scheme works well, in some networks it might be useful to 161 change the cost of the path over a TE-tunnel, to make the route over 162 the TE-tunnel less or more preferred than other routes. 164 For instance when equal cost paths exist over a TE-tunnel and over a 165 native IP path, by adjusting the cost of the path over the TE-tunnel, 166 we can force traffic to prefer the path via the TE-tunnel, to prefer 167 the native IP path, or to load-balance among them. Another example is 168 when multiple TE-tunnels go to the same or different destinations. 169 Adjusting TE-tunnel metrics can force the traffic to prefer some TE- 170 tunnels over others regardless of underlining IGP cost to those 171 destinations. 173 Setting a manual metric on a TE-tunnel does not impact the SPF 174 algorithm itself. It only affects comparison of the new route with 175 existing routes in the routing table. Existing routes can be either 176 IP routes to another router that advertises the same IP prefix, or it 177 can be a path to the same router, but via a different outgoing 178 interface or different TE-tunnel. All routes to IP prefixes 179 advertised by the tail-end router will be affected by the TE-tunnel 180 metric. Also the metrics of paths to routers that are downstream of 181 the tail-end router will be influenced by the manual TE-tunnel 182 metric. 184 This mechanism is loop free since the TE-tunnels are source-routed 185 and the tunnel egress is a downstream node to reach the computed 186 destinations. The end result of TE-tunnel metric adjustment is 187 more control over traffic loadsharing. If there is only one way 188 to reach a particular IP prefix through a single TE-tunnel, then no 189 matter what metric is assigned, the traffic has only one path to go. 191 6.1. Absolute and relative metrics 193 It is possible to represent the TE-tunnel metric in two different 194 ways: an absolute (or fixed) metric or a relative metric, which is 195 merely an adjustment of the dynamic IGP metric as calculate by the 196 SPF computation. When using an absolute metric on a TE-tunnel, the 197 cost of the IP routes in the routing table does not depend on the 198 topology of the network. Note that this fixed metric is not only used 199 to compute the cost of IP routes advertised by the router that is the 200 tail-end of the TE-tunnel, but also for all the routes that are 201 downstream of this tail-end router. For example, if we have TE- 202 tunnels to two core routers in a remote POP, and one of them is 203 assigned with absolute metric of 1, then all the traffic going to 204 that POP will traverse this low-metric TE-tunnel. 206 By setting a relative metric, the cost of IP routes in the routing 207 table is based on the IGP metric as calculated by the SPF 208 computation. This relative metric can be a positive or a negative 209 number. Not configuring a metric on a TE-tunnel is a special case of 210 the relative metric scheme. No metric is the same as a relative 211 metric of 0. The relative metric is bounded by minimum and maximum 212 allowed metric values while the positive metric disables the 213 TE-tunnel in the SPF calculation. 215 6.2. Examples of metric adjustment 217 Assume the following topology. X, Y and Z are IP prefixes advertised 218 by rtrC, rtrD and rtrE respectively. T1 is a TE-tunnel from rtrA to 219 rtrC. Each link in the network has an IGP metric of 10. 221 ===== T1 =====> 222 rtrA -- rtrB -- rtrC -- rtrD -- rtrE 223 10 10 | 10 | 10 | 224 X Y Z 226 Without TE-tunnel T1, rtrA will install IP routes X, Y and Z in the 227 routing table with metrics 20, 30 and 40 respectively. When rtrA has 228 brought up TE-tunnel T1 to rtrC, and if rtrA is configured with the 229 relative metric of -5 on tunnel T1, then the routes X, Y, and Z will 230 be installed in the routing table with metrics 15, 25, and 35. If an 231 absolute metric of 5 is configured on tunnel T1, then rtrA will 232 install routes X, Y and Z all with metrics 5, 15 and 25 respectively. 234 7. Security Considerations 236 This document raises no new security issues. 238 8. Acknowledgments 240 The authors would like to thank Christian Hopps for his comments 241 to this document. 243 9. Full Copyright Statement 245 Copyright (C) The Internet Society (2002). All Rights Reserved. 246 This document and translations of it may be copied and furnished to 247 others, and derivative works that comment on or otherwise explain it 248 or assist in its implementation may be prepared, copied, published 249 and distributed, in whole or in part, without restriction of any 250 kind, provided that the above copyright notice and this paragraph are 251 included on all such copies and derivative works. However, this 252 document itself may not be modified in any way, such as by removing 253 the copyright notice or references to the Internet Society or other 254 Internet organizations, except as needed for the purpose of 255 developing Internet standards in which case the procedures for 256 copyrights defined in the Internet Standards process must be 257 followed, or as required to translate it into languages other than 258 English. 260 The limited permissions granted above are perpetual and will not be 261 revoked by the Internet Society or its successors or assigns. 263 This document and the information contained herein is provided on an 264 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 265 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 266 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 267 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 268 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 270 10. References 272 [1] ISO. Information Technology - Telecommunications and 273 Information Exchange between Systems - Intermediate System 274 to Intermediate System Routing Exchange Protocol for 275 Use in Conjunction with the Protocol for Providing the 276 Connectionless-Mode Network Service. ISO, 1990. 278 [2] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet 279 Engineering Task Force, 1998. 281 [3] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, 282 "Requirements for Traffic Engineering Over MPLS", RFC 2702, 283 September 1999. 285 [4] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP 286 tunnels", RFC3029, December 2001. 288 11. Authors' Addresses 290 Naiming Shen 291 Redback Networks, Inc. 292 300 Holger Way 293 San Jose, CA 95134 294 Email: naiming@redback.com 296 Henk Smit 297 Email: hhwsmit@xs4all.nl