idnits 2.17.1 draft-ietf-mpls-ldp-restart-06.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 == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 61 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 abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 505 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.) -- 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: 'RFC3036' is mentioned on line 422, but not defined ** Obsolete undefined reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) -- Possible downref: Non-RFC (?) normative reference: ref. 'FT-LDP' == Outdated reference: A later version (-08) exists of draft-ietf-ospf-hitless-restart-01 == Outdated reference: A later version (-05) exists of draft-ietf-isis-restart-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-restart (ref. 'ISIS-RESTART') == Outdated reference: A later version (-13) exists of draft-ietf-idr-restart-03 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Manoj Leelanivas (Juniper Networks) 3 Internet Draft Yakov Rekhter(Juniper Networks) 4 Expiration Date: April 2003 Rahul Aggarwal (Redback Networks) 6 Graceful Restart Mechanism for LDP 8 draft-ietf-mpls-ldp-restart-06.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes a mechanism that helps to minimize the 33 negative effects on MPLS traffic caused by Label Switching Router's 34 (LSR's) control plane restart, and specifically by the restart of its 35 Label Distribution Protocol (LDP) component, on LSRs that are capable 36 of preserving the MPLS forwarding component across the restart. 38 The mechanism described in this document is applicable to all LSRs, 39 both those with the ability to preserve forwarding state during LDP 40 restart and those without (although the latter need to implement only 41 a subset of the mechanism described in this document). Supporting (a 42 subset of) the mechanism described here by the LSRs that can not 43 preserve their MPLS forwarding state across the restart would not 44 reduce the negative impact on MPLS traffic caused by their control 45 plane restart, but it would minimize the impact if their neighbor(s) 46 are capable of preserving the forwarding state across the restart of 47 their control plane and implement the mechanism described here. 49 The mechanism makes minimalistic assumptions on what has to be 50 preserved across restart - the mechanism assumes that only the actual 51 MPLS forwarding state has to be preserved; the mechanism does not 52 require any of the LDP-related state to be preserved across the 53 restart. 55 The procedures described in this document apply to downstream 56 unsolicited label distribution. Extending these procedures to 57 downstream on demand label distribution is for further study. 59 Specification of Requirements 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 65 Summary for Sub-IP Area 67 (This section to be removed before publication.) 69 0.1 Summary 71 This document describes a mechanism that helps to minimize the 72 negative effects on MPLS traffic caused by LSR's control plane 73 restart, and specifically by the restart of its LDP component, on 74 LSRs that are capable of preserving the MPLS forwarding component 75 across the restart. 77 0.2 Related documents 79 See the Reference Section 80 0.3 Where does it fit in the Picture of the Sub-IP Work 82 This work fits squarely in MPLS box. 84 0.4 Why is it Targeted at this WG 86 The LDP is a product of the MPLS WG. This document specifies 87 procedures to minimize the negative effects caused by the restart of 88 the control plane LDP module. Since the procedures described in this 89 document are directly related to LDP, it would be logical to target 90 this document at the MPLS WG. 92 0.5 Justification 94 The WG should consider this document, as it allows to minimize the 95 negative effects caused by the restart of the control plane LDP 96 module. 98 1. Motivation 100 For the sake of brevity in the context of this document by "the 101 control plane" we mean "the LDP component of the control plane". 103 For the sake of brevity in the context of this document by "MPLS 104 forwarding state" we mean either (outgoing label, 105 next hop)> (non-ingress case), or (outgoing label, next hop)> 106 (ingress case) mapping. 108 In the case where a Label Switching Router (LSR) could preserve its 109 MPLS forwarding state across restart of its control plane, and 110 specifically its LDP component [LDP], it is desirable not to perturb 111 the LSPs going through that LSR (and specifically, the LSPs 112 established by LDP). In this document, we describe a mechanism, 113 termed "LDP Graceful Restart", that allows to accomplish this goal. 115 The mechanism described in this document is applicable to all LSRs, 116 both those with the ability to preserve forwarding state during LDP 117 restart and those without (although the latter need to implement only 118 a subset of the mechanism described in this document). Supporting (a 119 subset of) the mechanism described here by the LSRs that can not 120 preserve their MPLS forwarding state across the restart would not 121 reduce the negative impact on MPLS traffic caused by their control 122 plane restart, but it would minimize the impact if their neighbor(s) 123 are capable of preserving the forwarding state across the restart of 124 their control plane and implement the mechanism described here. 126 The mechanism makes minimalistic assumptions on what has to be 127 preserved across restart - the mechanism assumes that only the actual 128 MPLS forwarding state has to be preserved. Clearly this is the 129 minimum amount of state that has to be preserved across the restart 130 in order not to perturb the LSPs traversing a restarting LSR. The 131 mechanism does not require any of the LDP-related state to be 132 preserved across the restart. 134 In the scenario where label binding on an LSR is created/maintained 135 not just by the LDP component of the control plane, but by other 136 protocol components as well (e.g., BGP, RSVP-TE), and the LSR 137 supports restart of the individual components of the control plane 138 that create/maintain label binding (e.g., restart of LDP, but no 139 restart of BGP), the LSR needs to preserve across the restart the 140 information about which protocol has assigned which labels. 142 The procedures described in this document apply to downstream 143 unsolicited label distribution. Extending these procedures to 144 downstream on demand label distribution is for further study. 146 2. LDP Extension 148 An LSR indicates that it is capable of supporting LDP Graceful 149 Restart, as defined in this document, by including the Fault Tolerant 150 (FT) Session TLV as an Optional Parameter in the LDP Initialization 151 message. The format of the FT Session TLV is defined in [FT-LDP]. 152 The L (Learn from Network) flag MUST be set to 1, which indicates 153 that the procedures in this document are used. The rest of the FT 154 flags are set to 0 by a sender and ignored on receipt. 156 The value field of the FT Session TLV contains two components that 157 are used by the mechanisms defined in this document: FT Reconnect 158 Timeout, and Recovery Time. 160 The FT Reconnect Timeout is the time (in milliseconds) that the 161 sender of the TLV would like the receiver of that TLV to wait after 162 the receiver detects the failure of LDP communication with the 163 sender. While waiting, the receiver SHOULD retain the MPLS 164 forwarding state for the (already established) LSPs that traverse a 165 link between the sender and the receiver. The FT Reconnect Timeout 166 should be long enough to allow the restart of the control plane of 167 the sender of the TLV, and specifically its LDP component to bring it 168 to the state where the sender could exchange LDP messages with its 169 neighbors. 171 Setting the FT Reconnect Timeout to 0 indicates that the sender of 172 the TLV will not preserve its forwarding state across the restart, 173 yet the sender supports the procedures defined in Section "Restart of 174 LDP communication with a neighbor LSR" of this document, and 175 therefore could take advantage if its neighbor can preserve its 176 forwarding state across the restart. 178 For a restarting LSR the Recovery Time carries the time (in 179 milliseconds) the LSR is willing to retain its MPLS forwarding state 180 that it preserved across the restart. The time is from the moment the 181 LSR sends the Initialization message that carries the FT Session TLV 182 after restart. Setting this time to 0 indicates that the MPLS 183 forwarding state wasn't preserved across the restart (or even if it 184 was preserved, is no longer available). 186 The Recovery Time SHOULD be long enough to allow the neighboring 187 LSR's to re-sync all the LSP's in a graceful manner, without creating 188 congestion in the LDP control plane. 190 3. Operations 192 An LSR that supports functionality described in this document 193 advertises this to its LDP neighbors by carrying the FT Session TLV 194 in the LDP Initialization message. 196 This document assumes that in certain situations, as specified in 197 section "Egress LSR", in addition to the MPLS forwarding state, an 198 LSR can also preserve its IP forwarding state across the restart. 199 Procedures for preserving IP forwarding state across the restart are 200 defined in [OSPF-RESTART], [ISIS-RESTART], and [BGP-RESTART]. 202 3.1. Procedures for the restarting LSR 204 After an LSR restarts its control plane, the LSR MUST check whether 205 it was able to preserve its MPLS forwarding state from prior to the 206 restart. If no, then the LSR sets the Recovery Time to 0 in the FT 207 Session TLV the LSR sends to its neighbors. 209 If the forwarding state has been preserved, then the LSR starts its 210 internal timer, called MPLS Forwarding State Holding timer (the value 211 of that timer SHOULD be configurable), and marks all the MPLS 212 forwarding state entries as "stale". At the expiration of the timer, 213 all the entries still marked as stale SHOULD be deleted. The value of 214 the Recovery Time advertised in the FT Session TLV is set to the 215 (current) value of the timer at the point when the Initialization 216 message carrying the FT Session TLV is sent. 218 We say that an LSR is in the process of restarting when the MPLS 219 Forwarding State Holding timer is not expired. Once the timer 220 expires, we say that the LSR completed its restart. 222 The following procedures apply when an LSR is in the process of 223 restarting. 225 3.1.1. Non-egress LSR 227 If the label carried in the newly received Mapping message is not an 228 Implicit NULL, the LSR searches its MPLS forwarding state for an 229 entry with the outgoing label equal to the label carried in the 230 message, and the next hop equal to one of the addresses (next hops) 231 received in the Address message from the peer. If such an entry is 232 found, the LSR no longer marks the entry as stale. In addition, if 233 the entry is of type 234 (rather than ), the LSR associates 235 the incoming label from that entry with the FEC received in the Label 236 Mapping message, and advertises (via LDP) to 237 its neighbors. If the found entry has no incoming label, or if no 238 entry is found, the LSR follows the normal LDP procedures. (Note 239 that this paragraph describes the scenario where the restarting LSR 240 is neither the egress, nor the penultimate hop that uses penultimate 241 hop popping for a particular LSP. Note also that this paragraph 242 covers the case where the restarting LSR is the ingress.) 244 If the label carried in the Mapping message is an Implicit NULL 245 label, the LSR searches its MPLS forwarding state for an entry that 246 indicates Label pop (means no outgoing label), and the next hop equal 247 to one of the addresses (next hops) received in the Address message 248 from the peer. If such an entry is found, the LSR no longer marks the 249 entry as stale, the LSR associates the incoming label from that entry 250 with the FEC received in the Label Mapping message from the neighbor, 251 and advertises (via LDP) to its neighbors. If 252 the found entry has no incoming label, or if no entry is found, the 253 LSR follows the normal LDP procedures. (Note that this paragraph 254 describes the scenario where the restarting LSR is a penultimate hop 255 for a particular LSP, and this LSP uses penultimate hop popping.) 257 The description in the above paragraph assumes that the restarting 258 LSR generates the same label for all the LSPs that terminate on the 259 same LSR (different from the restarting LSR), and for which the 260 restarting LSR is a penultimate hop. If this is not the case, and the 261 restarting LSR generates a unique label per each such LSP, then the 262 LSR needs to preserve across the restart not just mapping, but also the FEC associated with 264 this mapping. In such case the LSR searches its MPLS forwarding state 265 for an entry that (a) indicates Label pop (means no outgoing label), 266 (b) the next hop equal to one of the addresses (next hops) received 267 in the Address message from the peer, and (c) has the same FEC as the 268 one received in the Label Mapping message. If such an entry is found, 269 the LSR no longer marks the entry as stale, the LSR associates the 270 incoming label from that entry with the FEC received in the Label 271 Mapping message from the neighbor, and advertises (via LDP) to its neighbors. If the found entry has no incoming 273 label, or if no entry is found, the LSR follows the normal LDP 274 procedures. 276 3.1.2. Egress LSR 278 If an LSR determines that it is an egress for a particular FEC, the 279 LSR is configured to generate a non-NULL label for that FEC, and the 280 LSR is configured to generate the same (non-NULL) label for all the 281 FECs that share the same next hop and for which the LSR is an egress, 282 the LSR searches its MPLS forwarding state for an entry that 283 indicates Label pop (means no outgoing label), and the next hop equal 284 to the next hop for that FEC. (Determining the next hop for the FEC 285 depends on the type of the FEC. For example, when the FEC is an IP 286 address prefix, the next hop for that FEC is determined from the IP 287 forwarding table.) If such an entry is found, the LSR no longer marks 288 this entry as stale, the LSR associates the incoming label from that 289 entry with the FEC, and advertises (via LDP) to 290 its neighbors. If the found entry has no incoming label, or if no 291 entry is found, the LSR follows the normal LDP procedures. 293 If an LSR determines that it is an egress for a particular FEC, the 294 LSR is configured to generate a non-NULL label for that FEC, and the 295 LSR is configured to generate a unique label for each such FEC, then 296 the LSR needs to preserve across the restart not just mapping, but also the FEC 298 associated with this mapping. In such case the LSR would search its 299 MPLS forwarding state for an entry that indicates Label pop (means no 300 outgoing label), and the next hop equal to the next hop for that FEC 301 associated with the entry (Determining the next hop for the FEC 302 depends on the type of the FEC. For example, when the FEC is an IP 303 address prefix, the next hop for that FEC is determined from the IP 304 forwarding table.) If such an entry is found, the LSR no longer marks 305 this entry as stale, the LSR associates the incoming label from that 306 entry with the FEC, and advertises (via LDP) to 307 its neighbors. If the found entry has no incoming label, or if no 308 entry is found, the LSR follows the normal LDP procedures. 310 If an LSR determines that it is an egress for a particular FEC, and 311 the LSR is configured to generate a NULL (either Explicit or 312 Implicit) label for that FEC, the LSR just advertises (via LDP) such 313 label (together with the FEC) to its neighbors. 315 3.2. Alternative procedures for the restarting LSR 317 In this section we describe an alternative to the procedures 318 described in Section "Procedures for the restarting LSR". 320 The procedures described in this section assumes that the restarting 321 LSR has (at least) as many unallocated as allocated labels. The 322 latter form the MPLS forwarding state that the LSR managed to 323 preserve across the restart. 325 After an LSR restarts its control plane, the LSR MUST check whether 326 it was able to preserve its MPLS forwarding state from prior to the 327 restart. If no, then the LSR sets the Recovery Time to 0 in the FT 328 Session TLV the LSR sends to its neighbors. 330 If the forwarding state has been preserved, then the LSR starts its 331 internal timer, called MPLS Forwarding State Holding timer (the value 332 of that timer SHOULD be configurable), and marks all the MPLS 333 forwarding state entries as "stale". At the expiration of the timer, 334 all the entries still marked as stale SHOULD be deleted. The value of 335 the Recovery Time advertised in the FT Session TLV is set to the 336 (current) value of the timer at the point when the Initialization 337 message carrying the FT Session TLV is sent. 339 We say that an LSR is in the process of restarting when the MPLS 340 Forwarding State Holding timer is not expired. Once the timer 341 expires, we say that the LSR completed its restart. 343 While an LSR is in the process of restarting, the LSR creates local 344 label binding by following the normal LDP procedures. 346 Note that while an LSR is in the process of restarting, the LSR may 347 have not one, but two local label bindings for a given FEC - one that 348 was retained from prior to restart, and another that was created 349 after the restart. Once the LSR completes its restart, the former 350 will be deleted. Both of these bindings though would have the same 351 outgoing label (and the same next hop). 353 3.3. Restart of LDP communication with a neighbor LSR 355 When an LSR detects that its LDP session with a neighbor went down, 356 and the LSR knows that the neighbor is capable of preserving its MPLS 357 forwarding state across the restart (as was indicated by the FT 358 Session TLV in the Initialization message received from the 359 neighbor), the LSR retains the label-FEC bindings received via that 360 session (rather than discarding the bindings), but marks them as 361 "stale". 363 After detecting that the LDP session with the neighbor went down, the 364 LSR tries to re-establish LDP communication with the neighbor 365 following the usual LDP procedures. 367 The amount of time the LSR keeps its stale label-FEC bindings is set 368 to the lesser of the FT Reconnect Timeout, as was advertised by the 369 neighbor, and a local timer, called the Neighbor Liveness Timer. If 370 within that time the LSR still doesn't establish an LDP session with 371 the neighbor, all the stale bindings SHOULD be deleted. The Neighbor 372 Liveness Timer is started when the LSR detects that its LDP session 373 with the neighbor went down. The value of the Neighbor Liveness timer 374 SHOULD be configurable. 376 If the LSR re-establishes an LDP session with the neighbor within the 377 lesser of the FT Reconnect Timeout and the Neighbor Liveness Timer, 378 and the LSR determines that the neighbor was not able to preserve its 379 MPLS forwarding state, the LSR SHOULD immediately delete all the 380 stale label-FEC bindings received from that neighbor. If the LSR 381 determines that the neighbor was able to preserve its MPLS forwarding 382 state (as was indicated by the non-zero Recovery Time advertised by 383 the neighbor), the LSR SHOULD further keep the stale label-FEC 384 bindings received from the neighbor for as long as the lesser of the 385 Recovery Time, advertised by the neighbor, and a local configurable 386 value, called Maximum Recovery Time. 388 The LSR SHOULD try to complete the exchange of its label mapping 389 information with the neighbor within 1/2 of the Recovery Time, as 390 specified in the FT Session TLV received from the neighbor. 392 The LSR handles the Label Mapping messages received from the neighbor 393 by following the normal LDP procedures, except that (a) it treats the 394 stale entries in its Label Information Base (LIB), as if these 395 entries have been received over the (newly established) session, (b) 396 if the label-FEC binding carried in the message is the same as the 397 one that is present in the LIB, but is marked as stale, the LIB entry 398 no longer is marked as stale, and (c) if for the FEC in the label-FEC 399 binding carried in the message there is already a label-FEC binding 400 in the LIB that is marked as stale, and the label in the LIB binding 401 is different from the label carried in the message, the LSR just 402 updates the LIB entry with the new label. 404 An LSR, once it creates a binding, SHOULD keep the value 405 of the label in this binding for as long as the LSR has a route to 406 the FEC in the binding. If the route to the FEC disappears, and then 407 re-appears again later, then this may result in using a different 408 label value, as when the route re-appears, the LSR would create a new 409 binding. 411 To minimize the potential mis-routing caused by the label change, 412 when creating a new binding the LSR SHOULD pick up the 413 least recently used label. Once an LSR releases a label, the LSR 414 SHOULD NOT re-use this label for advertising a binding 415 to a neighbor that supports graceful restart for at least the sum of 416 FT Reconnect Timeout plus Recovery Time, as advertised by the 417 neighbor to the LSR. 419 4. Security Consideration 421 The security considerations pertaining to the original LDP protocol 422 [RFC3036] remain relevant. 424 In addition, the mechanism described here renders LSRs that implement 425 it to additional denial-of-service attacks as follows: 427 An intruder may impersonate an LDP peer in order to force a 428 failure and reconnection of the TCP connection, but where the 429 intruder sets the Recovery Time to 0 on reconnection. This forces 430 all labels received from the peer to be released. 432 An intruder could intercept the traffic between LDP peers and 433 override the setting of the Recovery Time to be set to 0. This 434 forces all labels received from the peer to be released. 436 All of these attacks may be countered by use of an authentication 437 scheme between LDP peers, such as the MD5- based scheme outlined in 438 [LDP]. 440 As with LDP, a security issue may exist if an LDP implementation 441 continues to use labels after expiration of the session that first 442 caused them to be used. This may arise if the upstream LSR detects 443 the session failure after the downstream LSR has released and re-used 444 the label. The problem is most obvious with the platform-wide label 445 space and could result in mis-routing of data to other than intended 446 destinations and it is conceivable that these behaviors may be 447 deliberately exploited to either obtain services without 448 authorization or to deny services to others. 450 In this document, the validity of the session may be extended by the 451 Reconnect Timeout, and the session may be re-established in this 452 period. After the expiry of the Reconnection Timeout the session 453 must be considered to have failed and the same security issue applies 454 as described above. 456 However, the downstream LSR may declare the session as failed before 457 the expiration of its Reconnection Timeout. This increases the 458 period during which the downstream LSR might reallocate the label 459 while the upstream LSR continues to transmit data using the old usage 460 of the label. To reduce this issue, this document requires that 461 labels are not re-used until for at least the sum of Reconnect 462 Timeout plus Recovery Time. 464 5. Intellectual Property Considerations 466 This section is taken from Section 10.4 of [RFC2026]. 468 The IETF takes no position regarding the validity or scope of any 469 intellectual property or other rights that might be claimed to 470 pertain to the implementation or use of the technology described in 471 this document or the extent to which any license under such rights 472 might or might not be available; neither does it represent that it 473 has made any effort to identify any such rights. Information on the 474 IETF's procedures with respect to rights in standards-track and 475 standards-related documentation can be found in BCP-11. Copies of 476 claims of rights made available for publication and any assurances of 477 licenses to be made available, or the result of an attempt made to 478 obtain a general license or permission for the use of such 479 proprietary rights by implementors or users of this specification can 480 be obtained from the IETF Secretariat. 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights which may cover technology that may be required to practice 485 this standard. Please address the information to the IETF Executive 486 Director. 488 The IETF has been notified of intellectual property rights claimed in 489 regard to some or all of the specification contained in this 490 document. For more information consult the online list of claimed 491 rights. 493 6. Copyright Notice 495 Copyright (C) The Internet Society (date). All Rights Reserved. 497 This document and translations of it may be copied and furnished to 498 others, and derivative works that comment on or otherwise explain it 499 or assist in its implmentation may be prepared, copied, published and 500 distributed, in whole or in part, without restriction of any kind, 501 provided that the above copyright notice and this paragraph are 502 included on all such copies and derivative works. However, this 503 document itself may not be modified in any way, such as by removing 504 the copyright notice or references to the Internet Society or other 505 Internet organizations, except as needed for the purpose of 506 developing Internet standards in which case the procedures for 507 copyrights defined in the Internet Standards process must be 508 followed, or as required to translate it into languages other than 509 English. 511 The limited permissions granted above are perpetual and will not be 512 revoked by the Internet Society or its successors or assigns. 514 This document and the information contained herein is provided on an 515 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 516 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 517 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 518 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 519 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 521 7. Acknowledgments 523 We would like to thank Loa Andersson, Chaitanya Kodeboyina, Ina 524 Minei, Nischal Sheth, Enke Chen, and Adrian Farrel for their 525 contributions to this document. 527 8. Normative References 529 [LDP] "Label Distribution Protocol", RFC3036 531 [FT-LDP] "Fault Tolerance for LDP and CR-LDP", work in progress 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, March 1997. 536 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 537 3", RFC2026 538 9. Non-normative References 540 [OSPF-RESTART] "Hitless OSPF Restart", draft-ietf-ospf-hitless- 541 restart-01.txt 543 [ISIS-RESTART] "Restart signaling for ISIS", draft-ietf-isis- 544 restart-01.txt 546 [BGP-RESTART] "Graceful Restart Mechanism for BGP", draft-ietf-idr- 547 restart-03.txt 549 10. Author Information 551 Manoj Leelanivas 552 Juniper Networks 553 1194 N.Mathilda Ave 554 Sunnyvale, CA 94089 555 e-mail: manoj@juniper.net 557 Yakov Rekhter 558 Juniper Networks 559 1194 N.Mathilda Ave 560 Sunnyvale, CA 94089 561 e-mail: yakov@juniper.net 563 Rahul Aggarwal 564 Redback Networks 565 350 Holger Way 566 San Jose, CA 95134 567 e-mail: rahul@redback.com