idnits 2.17.00 (12 Aug 2021) /tmp/idnits21696/draft-shen-nhop-fastreroute-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: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 61 has weird spacing: '... detect misco...' == Line 400 has weird spacing: '... not to preve...' == Line 599 has weird spacing: '...for the purpo...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This object with C-type of 1 is used in PATH message and C-type of 2 is used in RESV message. They are called Request and Acknowledgement Objects. The Request Bypass Nexthop object MUST only be inserted into PATH message by the head-end of the NFRR LSP node , and MUST not be changed by downstream LSRs. The Ack Bypass Nexthop object MUST only be inserted into RESV message by the tail-end of the NFRR LSP node, and MUST not be changed by the upstream LSRs. -- 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 (December 2003) is 6732 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) -- Looks like a reference, but probably isn't: 'R3' on line 202 ** Downref: Normative reference to an Experimental RFC: RFC 3029 (ref. '1') -- Unexpected draft version: The latest known version of draft-pan-rsvp-fastreroute is -00, but you're referring to -03. -- Possible downref: Normative reference to a draft: ref. '2' -- No information found for draft-hsmit-shen-mpls-igp-spf - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Naiming Shen 3 Internet Draft Redback Networks 4 Ping Pan 5 Expiration Date: June 2004 Ciena Corp 6 December 2003 8 Nexthop Fast ReRoute for IP and MPLS 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 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 Abstract 35 This document describes a mechanism called NFRR (Nexthop 36 Fast ReRoute) to perform fast re-route for any type of traffic 37 in the event of a link/node failure or a nexthop unreachable. 38 The protected traffic can be IP, MPLS, unicast or multicast. 39 The re-routed traffic can either be destined to the nexthop 40 router or to the next-nexthop router. RSVP explicitly routed LSPs 41 are used as a tool to perform the local patch for minimizing 42 the packet loss. 44 1. Introduction 46 This document describes a simple mechanism to quickly re-direct IP 47 and/or MPLS traffic away from a local link or a nexthop failure. 48 The mechanism presented is mainly to facilitate the needs 49 of real-time IP applications over native IP unicast/multicast 50 networks or LDP based MPLS networks. The goal is to limit the IP 51 packet loss duration in the network to 10s of milliseconds in the 52 event of link/node failures. RSVP [1] signaled LSP is used with 53 explicitly routed path as the re-direct tunnel, while the protected 54 traffic can be either MPLS traffic engineered LSPs, LDP based LSPs, 55 IP unicast, IP multicast traffic or the mix of them. This mechanism 56 can be applied to both point-to-point links and multi-access links 57 in the cases of the link protection and node protection. 59 An optional RSVP Bypass Nexthop object is defined to allow a 60 modified RPF checks for re-directed IP multicast data traffic. It 61 can also be used to detect misconfigured re-direct LSPs. 63 The node failure fast protection of native IP traffic is also 64 described in this document. Link State IGP can be used to make 65 the IP prefixes association with Next-NextHop nodes and the 66 re-direct LSPs configured towards them. For node protection of 67 LDP and multicast IP traffic, extension for both protocols are 68 needed and is beyond the scope of this document. 70 The re-direct LSP is no different from any other RSVP explicitly 71 routed LSPs, except that it does not carry data traffic under 72 normal condition. It is pre-built to reach the nexthop or the 73 next-nexthop router in the case of the protected link/node fails 74 or the nexthop over that protected link is unreachable. Any type 75 of data traffic intended to use this nexthop may be switched onto 76 this re-direct LSP. Since the LSP is built to protect local links 77 or adjacent nodes, the explicit path can be easily calculated 78 either statically or dynamically. 80 2. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC2119 [5]. 86 LSP - An MPLS Label Switched Path. In this document, an LSP 87 will always refer to an explicitly routed LSP. 89 LDP LSP - LSP signaled by LDP protocol. 91 RSVP LSP - LSP signaled by RSVP protocol. 93 NFRR - Nexthop Fast ReRoute Scheme 95 NFRR LSP - Nexthop Fast ReRoute LSP, which is same as bypass 96 LSP or re-direct LSP in this document. 98 PLR - Point of Local Repair. The head-end LSR of a bypass LSP. 100 MP - Merge Point. The tail-end LSR of a bypass LSP. 102 Nexthop Node - The router is directly connected to the PLR node. 104 Next-Nexthop Node - The router is the Nexthop node of PLR's 105 Nexthop node. 107 3. Motivations 109 IP applications such as VoIP and PWE3 are highly desirable to 110 have the packet loss with less than 10s of milliseconds during 111 network elements failure. Currently there are three approaches 112 in practice or proposed to speed up the recovery from such 113 failures as discussed below. 115 First, MPLS LSP Fast ReRoute mechanism [2] is used to quickly 116 re-route the RSVP LSP traffic onto a detour or bypass LSP when 117 a local link failure is detected. Since the detour or bypass LSPs 118 are pre-built before the local link failure, this re-route 119 operation can be accomplished within 10s of milliseconds. If the 120 IP backbone deploys network-wide MPLS TE, this MPLS Fast ReRoute 121 approach is the best solution. The Fast ReRoute is just 122 another application using the existing MPLS infrastructure. 123 This mechanism does not offer protection of IP, LDP or multicast 124 data traffic. 126 Second, IGP fast convergence is another mechanism in reducing the 127 packet loss time in network element failure. This mechanism also 128 includes the improvement of LDP convergence. Comparing with the 129 first solution, the recovery time is usually an order of magnitude 130 higher, which is in the 100s of milliseconds range. For certain 131 real-time applications, that duration is still acceptable and 132 this is a big improvement over "normal" IGP convergence time of 133 seconds or even 10s of seconds. Since this mechanism is purely 134 based on the control plane convergence in the network, there is 135 no guarantee for the convergence to be limited under 100s of 136 milliseconds. 138 Third, pre-calculated alternative nexthops are downloaded into 139 forwarding engines. As in the first mechanism, when a local 140 link failure is detected, those alternative nexthops are used to 141 continue forwarding the data traffic. If an alternative nexthop 142 does exist, then the re-route time can be accomplished within 143 10s of milliseconds. There are a couple of shortcoming of this 144 approach. There may not exist such an alternative nexthop for 145 the IP destinations along with the links it intends to protect. 146 When such alternative nexthops do exist, if there are many IGP 147 interfaces and adjacencies on the node, this requires to run 148 many instances of SPF in order to find a loop-free alternative. 149 This scheme can not be used to protect MPLS TE LSPs since they 150 are not constructed from the native IP routing. Last, if the 151 local link failure is shortly after some network events and 152 the IGP on the node is busy calculating those SPFs, then the 153 alternative nexthop picture is incomplete at that time and the 154 re-route action may not be reliable. 156 There is obviously a need for providers to protect not only the 157 RSVP based LSP traffic, but also any data traffic in general; 158 there is a need for providers not only to protect traffic in 159 the case of link failure, but also with node failure for any 160 type of traffic; there is a need for providers not only to protect 161 native IP unicast traffic, but also the IP multicast data traffic. 162 The Nexthop Fast ReRoute mechanism does not make any assumption of 163 the protected traffic is MPLS tunneled or not. If a network-wide 164 MPLS traffic engineering is not the goal of the network design, 165 the network can either stay with native IP or LDP LSPs but 166 still get the reliable Fast ReRoute benefits for link/node 167 protection. In this scheme, RSVP signaled LSP will be used as 168 the re-direct tunnel for protected links/nodes. Those LSPs are 169 explicitly routed to get around the intended failure points. In 170 this scheme, the LSP is used in the network as a tool to fast 171 re-direct data traffic. If a network has an external Frame Relay 172 circuit in replacement for the RSVP based LSP, this Nexthop Fast 173 ReRoute will also work as specified in this document. 175 4. Nexthop Fast ReRoute(NFRR) Operation Scheme 177 Over a point-to-point there will be only one nexthop in general. 178 There are multiple nexthops over a LAN interface. The NFRR 179 is used to re-route traffic around the IP nexthop over the 180 protected interface. Assume there is an alternative path to 181 reach that nexthop node other than the protected link, we can 182 always pre-build an explicitly routed LSP to the node which owns 183 this nexthop address. If the local link is down, or the nexthop 184 is unreachable, the PLR router can quickly re-direct the data 185 traffic intended for this nexthop onto the NFRR LSP for that 186 nexthop node. Thus any traffic can be fast re-routed 187 in a loop-free fashion using NFRR. Over a LAN, the nexthop 188 unreachable status can possibly be quickly detected using some 189 link level aliveness protocols, and this is beyond the scope of 190 this document. When using NFRR protecting MPLS traffic, global 191 label space scheme is assume on the MP node. The NFRR for link 192 protection is assumed in this section. Node protection is 193 described in section 5. 195 The below network diagram will be used in this document as an 196 example topology for discussion purpose: 198 lsp1 199 +-----[R6]---+ 200 | | 201 | V 202 | ||==>b[R3] X 203 [R1]====>[R2]a=|| / 204 | | ||==>c[R4]===>d[R5]-- Y 205 | | ^ ^ 206 | | | | 207 | +--[R7]----+ | 208 | lsp2 |lsp3 209 +---------------------+ 211 R2 is the PLR router. 212 R2, R3 and R4 share a LAN connection with "a", "b" and 213 "c" belong to the same prefix. 214 R5 is a Next-Nexthop node from the PLR through R4. 216 lsp1 is sourced from R2 and explicitly route through R6 217 to reach R3. lsp1 is configured to protect "b" over 218 interface "a". 220 lsp2 is sourced from R2 to reach R4. lsp2 is configured 221 to protect "c" over interface "a". 223 lsp3 is sourced from R2 to reach R5. lsp3 is configured 224 to protect "c" or node R4 over interface "a". 226 Figure 1: An example of NFRR 228 4.1 NFRR to protect LDP LSPs 230 When the protected traffic is LDP LSPs, LDP process can 231 pre-build the association of the NFRR tunnel and the LDP LSPs 232 which use this particular nexthop. When the link is down or 233 the nexthop is unreachable, the forwarding engine can quickly 234 switch the traffic onto that NFRR tunnel by pushing an outbound 235 label and send it out. This is no different from re-directing 236 MPLS TE LSPs as described section 4.5 only without any RSVP 237 signaling involved in the LDP case. 239 4.2 NFRR to protect IP unicast traffic 241 The PLR node can pre-build the association of the NFRR tunnel 242 and the IP prefixes which use that same nexthop in the route 243 lookup. When the nexthop failure is detected, the forwarding 244 engine will be able to re-route the IP traffic to those 245 affected destinations onto the NFRR tunnel. The only difference 246 from the LDP case is that, it only has one label on the label 247 stack of the packet when being switch out to the NFRR LSP. 249 4.3 NFRR to protect IP multicast traffic 251 Similar to the IP unicast case, the PLR node can pre-build the 252 association of the NFRR tunnel and the (S, G) entries on the 253 protected interface. In the point-to-point case, there needs 254 to be only one NFRR tunnel to be referenced in the (S, G) 255 entries of the protected interface. In the LAN case, multiple 256 NFRR tunnel references can exist in the (S, G) entries. 257 When the protected interface is down, or one of the multicast 258 forwarding downstream neighbor is unreachable, all or part of 259 the NFRR tunnels can be applied to re-route multicast traffic 260 to the downstream nodes. In the example in Figure 1, assume 261 R2 has both R3 and R4 as downstream for some (S, G)s, when 262 the link "a" is down, the references in those (S, G)s should 263 point to both lsp1 and lsp2 as its "new" downstream interfaces. 264 R2 needs to forward the multicast traffic through both LSPs. 266 This document defines a new RSVP Bypass Nexthop object 267 which can be optionally inserted into the PATH message by the 268 head-end of the NFRR LSP and the RESV message by the tail-end 269 of the NFRR LSP. The bypassed link nexthop IP address of the 270 NFRR tunnel can be conveyed to the tail-end node using this 271 new RSVP object. Multicast RPF check algorithm can be modified 272 to accept the multicast traffic for the (S, G)s on the 273 alternative inbound interface even though the RPF check may 274 currently point to the protected link which has that nexthop 275 IP address. 277 4.4 NFRR to protect IPv6 traffic 279 The same NFRR LSP can protect native IPv6 traffic going to 280 the same neighbor node over the protected interface. In 281 this case, an IPv6 nexthop address can be configured along 282 with the NFRR LSP. The same operation for unicast and multicast 283 of IPv4 traffic mentioned above applies here. 285 4.5 NFRR to protect MPLS TE LSPs 287 When some of the protected traffic to the nexthop belongs to 288 MPLS TE LSPs, the mechanism is the same as described in [2] 289 as facility based link-protection bypass tunnel scheme. All 290 the RSVP signaling extension described in that document 291 applies here. NFRR only explicitly extends this into the 292 protection of a nexthop to deal with multi-access case 293 instead of protection of local link only, but The technique 294 used is identical. 296 4.6 Protocol packets over the protected link 298 There are two types of protocol packets with regard to this scheme. 299 One requires an IP route lookup such as BGP, OSPF VL or RSVP packets; 300 The other is sent directly over a local interface to neighbors 301 such as ISIS, OSPF, PIM or LDP adjacency packets. When the 302 protected link is down or the protected nexthop is unreachable, 303 the affected routable protocol packets MUST be re-routed over the 304 NFRR tunnel while the directly transported protocol packets SHOULD 305 be dropped in order to time out the protocol adjacency (even if 306 those protocol packets are re-directed over the NFRR LSPs, they 307 will be dropped by the neighbors due to inbound interface does 308 not match the protocol packets). The link/node down event will 309 be eventually propagated across the network and the entire network 310 can converge into a new topology. 312 5. Node Protection 314 The NFRR scheme described in section 4 is for link and nexthop 315 failure protection. This section describe the technique to use 316 NFRR for node protection. 318 5.1 Node Protection for IP Unicast Traffic 320 As described in section 4, we make the association from the route 321 nexthop to the NFRR LSP. When the link or nexthop fails, the 322 forwarding engine switches the traffic using this route nexthop 323 onto the NFRR LSP. In the node protection case, as long as we 324 have the knowledge of which routes using this nexthop also going 325 to the Next-Nexthop node, we are able to make the same association 326 to re-direct the traffic onto the NFRR LSP which has the 327 Next-Nexthop node as the tail-end. 329 For IP unicast traffic, this knowledge of routes association with 330 nexthop and Next-Nexthop nodes can be easily obtained from link 331 state IGPs. IGP Shortcut [4] is a technique to dynamically direct 332 IP traffic through TE LSPs. In the NFRR node protection case, 333 the PLR can use those shortcuts not for normal IP traffic, it will 334 only be used when the nexthop element fails. In other words, this 335 shortcut to the Next-Nexthop node is suddenly enabled by forwarding 336 engine when it detects the link, nexthop or nexthop node failure. 337 Those IGP shortcut LSPs can also be called conditional IGP 338 shortcuts with the conditions being the nexthop link or node failure. 340 In the example of Figure 1, lsp3 is a NFRR LSP source from PLR R2 341 with destination of R5 to protect node R4 as well as link "a" and 342 nexthop "c". IGP uses modified shortcut technique to associated 343 prefixes X and Y with nexthop "c1" over interface "a". The IGP 344 also installs a modified shortcut lsp3 to be associated with 345 nexthop "c1". The nexthop "c1" is just like "c", but it contains 346 the NFRR LSP lsp3 reference information. Basically if R4 has N 347 nexthop nodes, R2 will have "c1" through "cn" nexthops, each 348 references a NFRR LSP to it's Next-Nexthop node. The IP traffic 349 to X and Y normally is forwarded to R4, in the event of "a", "c" 350 or R4 node failure, the traffic is re-directed to lsp3 into R5. 352 The algorithm for IGP Shortcut described in section 4 of [4] 353 has three possible ways to determine the first-hop information. 354 The first way can be modified for NFRR conditional shortcut as 355 follows: 357 - Examine the list of tail-end routers directly reachable via a 358 NFRR-tunnel. If there is a NFRR-tunnel to this node, we will 359 copy the first-hop information from the parent node(s) to 360 the this node. We also attach the NFRR-tunnel information to 361 the first-hop information on this node. 363 This first-hop information of the node can be used to construct 364 the nexthop and its association with the NFRR LSP destined to 365 that node. The rest of the NFRR operation is the same as in 366 link protection case as described in section 4.2. 368 5.2 Node Protection for Other Traffic 370 NFRR Node Protection for MPLS TE LSP is the same as described 371 in [2] as facility based node-protection bypass tunnel scheme. 372 NFRR only explicitly extends this capability into the multi-access 373 case. The technique used is the same. 375 NFRR Node Protection for LDP LSP and IP multicast traffic will 376 be covered by two separate documents using the NFRR technique and 377 is out side the scope of this document. 379 6. RSVP Bypass Nexthop Object 381 A NFRR LSP is just like any explicitly routed LSP defined in [1] 382 and it is used by the PLR to fast re-route traffic to the same 383 neighbor over alternative interfaces. As mentioned in section 4.3, 384 re-routed multicast traffic will be dropped if the neighbor 385 does not aware certain multicast traffic can come in an alternative 386 interface. This Bypass Nexthop object is used to dynamically pass 387 this information from the head-end NFRR node to the tail-end node 388 so that the RPF check on that protected interface can be modified 389 to accept with an alternative interface. The tail-end node can 390 send back the same object to indicate whether the requested 391 operation is supported. 393 If NFRR LSP is used to protect the link failure, it is useful to 394 know if the NFRR tail-end owns this bypassed nexthop address; 395 When in node protection case, it is also useful to know the NFRR 396 tail-end does not own this bypassed nexthop address; For IP 397 multicast re-route application, the bypassed nexthop address needs 398 to be local to the tail-end node in both link and node protections. 399 This object can be inserted by the tail-end node in RESV message 400 to confirm the acknowledged address is local or not to prevent 401 NFRR LSP mis-configuration. 403 The Bypass Nexthop object has the following format: 405 Class = TBD (use form 11bbbbbb for compatibility) 406 C-Type = 1 or 2 408 0 1 2 3 409 +-------------+-------------+-------------+-------------+ 410 | Length (bytes) | Class-Num | C-Type | 411 +-------------+-------------+-------------+-------------+ 412 | Reserved | Service Option Bits | 413 +-------------+-------------+-------------+-------------+ 414 // (Subobjects) // 415 +-------------+-------------+-------------+-------------+ 417 Subobject 1: Nexthop IPv4 address 419 0 1 2 3 420 +-------------+-------------+-------------+-------------+ 421 | Type | Length | IPv4 address (4 bytes) | 422 +-------------+-------------+-------------+-------------+ 423 | IPv4 address (continued) |Prefix Length| Pad | 424 +-------------+-------------+-------------+-------------+ 426 Subobject 2: Nexthop IPv6 address 428 +-------------+-------------+-------------+-------------+ 429 | Type | Length | IPv6 address (16 bytes) | 430 +-------------+-------------+-------------+-------------+ 431 | IPv6 address (continued) | 432 +-------------+-------------+-------------+-------------+ 433 | IPv6 address (continued) | 434 +-------------+-------------+-------------+-------------+ 435 | IPv6 address (continued) | 436 +-------------+-------------+-------------+-------------+ 437 | IPv6 address (continued) |Prefix Length| Pad | 438 +-------------+-------------+-------------+-------------+ 440 This object with C-type of 1 is used in PATH message and C-type 441 of 2 is used in RESV message. They are called Request and 442 Acknowledgement Objects. The Request Bypass Nexthop object 443 MUST only be inserted into PATH message by the head-end of 444 the NFRR LSP node , and MUST not be changed by downstream LSRs. 445 The Ack Bypass Nexthop object MUST only be inserted into RESV 446 message by the tail-end of the NFRR LSP node, and MUST not be 447 changed by the upstream LSRs. 449 Only two bits are currently defined for Service Option Bits field 450 in this document as following (position from the right most to 451 left most): 453 Bits Description 455 1 Request/Ack this bypass nexthop address to be 456 local to the NFRR LSP tail-end node. The head-end LSR 457 sets this bit in PATH message requesting the information; 458 the tail-end LSR responds with RESV message by setting 459 or clearing this bit depends on the bypass nexthop 460 address is local to the LSR or not. 462 2 Request/Ack this bypass nexthop address to be 463 used to support modified multicast RPF checks as 464 defined in section 4.3. If the tail-end LSR does not 465 support this extension, then the multicast data 466 traffic SHOULD NOT be switched over to the NFRR LSP 467 in the event of link/node failure. 469 7. Forwarding Entry Update and NFRR LSP Reversion 471 The link down or nexthop unreachable event will eventually reach 472 the protocols such as OSPF or LDP. Regardless of IGP fast 473 convergence is used or not, the new forwarding entry downloading 474 should be hold for a little longer than the expected network 475 convergence time. This is to guarantee all the nodes in the 476 routing area have converged onto the new topology to avoid the 477 possibility of forwarding loops. It is safe to send traffic over 478 the NFRR LSP even after the network is converged. Since before the 479 link failure, the PLR was using the nexthop node to reach some 480 IP destination; it will be highly unlikely that the nexthop node 481 sends the traffic back to the PLR after the adjacent link/node 482 fails in network steady state. 484 Since the NFRR scheme is nexthop entry based, when those entries 485 are updated after the NFRR re-route takes place, the re-route 486 action for those entries will be reverted to normal operation. 487 In the example in Figure 1, R2 used to reach prefix X and Y through 488 nexthop "c" of R4. When "a" or "c" is down, the traffic towards 489 X and Y will be tunneled in lsp2 to use the same R4 for further 490 forwarding. After the holdown time expires and R2 decides to 491 use R7 as the new IP nexthop for X and Y. When R2 downloads the 492 X and Y into the forwarding engine, this update will revert the 493 re-route operation for traffic to X and Y. If the link "a" comes 494 up before the holdown time expires, R2 will use "c" as the nexthop 495 for X and Y again. The reversion time and operation is the same 496 in both cases. 498 Fast convergence of IGP will improve the network performance 499 even with the NFRR presents. It can help to quickly reach the more 500 optimal forwarding state in the routing domain with topology 501 changes. 503 8. Operational Considerations 505 8.1 ECMP Cases 507 The NFRR scheme is independent of ECMP case and the loadsharing 508 algorithm should be the same. THe NFRR LSP is used to protect 509 one particular nexthop, only the portion of traffic used to 510 use this nexthop will be re-routed in the failure event. 512 8.2 Bandwidth Reservation 514 Even in the case the network does not use MPLS TE for normal 515 traffic, bandwidth reservation for NFRR LSPs can still be 516 applied. The RSVP interface bandwidth will reflect the amount 517 of link bandwidth reserved for re-routed traffic purpose. 519 8.3 Type of Traffic To Be Re-routed. 521 Since NFRR can be applied to any traffic in link protection 522 case, it is an implementation or configuration issue to decide 523 which type of traffic will be applied, others will be dropped. 524 Even within the same type of traffic, filters can be designed to 525 select only the traffic using certain destination, service or 526 labels will be re-routed if the bandwidth is an issue. 528 8.4 MPLS and IP In The Network 530 The NFRR scheme uses RSVP explicitly routed LSP to protect data 531 traffic while data traffic itself may not use MPLS TE LSPs in 532 the network. In this case, MPLS TE is not the goal of the network 533 design, the NFRR LSPs are used as a tool to accomplish the 534 fast re-route goal. In order for the re-routed traffic to be 535 reliable and loop-free for any network topology, the traffic 536 has to be either source routed or tunneled independent of 537 IP routing. RSVP signaled LSP is widely supported technology 538 and can be easily fit into NFRR application. If the network 539 only needs to protect a few local links or nodes, the RSVP 540 LSPs can be restricted to a limited scope in the network using 541 NFRR. It is also useful for the network which has MPLS TE in the 542 core and IP or LDP LSPs at the edge. 544 Even in the case the provider has outband circuits to protect 545 the link or node, NFRR can also be used without RSVP signaled 546 LSP involved. The multicast RPF extension for RSVP functionality 547 can be statically applied on the MP node in this case. 549 8.5 Link Protection and Node Protection 551 Node protection in fast re-route is not without issues. Not all 552 the LSRs have the node-protection option. For example, the PHP 553 nodes can only perform link-protection for the last hop of LSPs. 555 The node-protection scheme also takes more network resource 556 since the MP is further away from the nexthop and it requires 557 more signaling work to identify the flow going through the 558 next-nexthop node in IP, LDP and multicast cases. 560 With Non-stop forwarding, protocol graceful restart and software 561 modular design make good inroad into provider's networks, a 562 complete node failure will gradually become rare events and a 563 node down often can be scheduled. 565 9. IANA Considerations 567 The NFRR proposal requires that IANA allocate a C-class number 568 for Bypass Nexthop object. 570 10. Security Considerations 572 This document does not introduce new security issues. The security 573 considerations pertaining to the original RSVP protocol [3] remain 574 relevant. 576 11. Acknowledgments 578 The authors would like to thank George Apostolopoulos, Enke Chen, 579 Albert Tian, Liming Wei and Jun Zhang for their contributions and 580 comments to this document. 582 12. Intellectual Property Considerations 584 Redback Networks may have intellectual property rights claimed in 585 regard to some of the specification contained in this document. 587 13. Full Copyright Statement 589 Copyright (C) The Internet Society (2002). All Rights Reserved. 591 This document and translations of it may be copied and furnished to 592 others, and derivative works that comment on or otherwise explain it 593 or assist in its implementation may be prepared, copied, published 594 and distributed, in whole or in part, without restriction of any 595 kind, provided that the above copyright notice and this paragraph are 596 included on all such copies and derivative works. However, this 597 document itself may not be modified in any way, such as by removing 598 the copyright notice or references to the Internet Society or other 599 Internet organizations, except as needed for the purpose of 600 developing Internet standards in which case the procedures for 601 copyrights defined in the Internet Standards process must be 602 followed, or as required to translate it into languages other than 603 English. 605 The limited permissions granted above are perpetual and will not be 606 revoked by the Internet Society or its successors or assigns. 608 This document and the information contained herein is provided on an 609 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 610 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 611 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 612 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 613 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 615 14. References 617 [1] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP 618 tunnels", RFC3029, December 2001. 620 [2] Pan, P., Gan, D., Swallow, G., Vasseur, J.Ph., Copper, D., 621 Atlas, A., Jork, M., "Fast Reroute Technique in RSVP-TE", 622 Interne draft, draft-pan-rsvp-fastreroute-03.txt, work in 623 progress. 625 [3] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) 626 -- version 1 functional specification," RFC2205, 627 September 1997. 629 [4] Smit, H., Shen, N., "Calculating IGP Routes Over Traffic 630 Engineering Tunnels", draft-hsmit-shen-mpls-igp-spf-01.txt, 631 Work In Progress. 633 [5] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", RFC 2119, March 1997. 636 15. Author Information 638 Naiming Shen 639 Redback Networks, Inc. 640 300 Holger Way 641 San Jose, CA 95134 642 Email: naiming@redback.com 644 Ping Pan 645 CIENA Corp. 646 5965 Silver Creek Valley Road 647 San Jose, CA 95138 648 Email: ppan@ciena.com