idnits 2.17.1 draft-ietf-mpls-bgp-mpls-restart-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 34. -- Found old boilerplate from RFC 3978, Section 5.5 on line 57. ** Found boilerplate matching RFC 3978, Section 5.5 (on line 57), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 4 text on line 451. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 11 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], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == Line 205 has weird spacing: '...el when adver...' == Line 437 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) == Outdated reference: A later version (-13) exists of draft-ietf-idr-restart-01 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Yakov Rekhter (Juniper Networks) 2 Internet Draft Rahul Aggarwal (Juniper Networks) 3 Expiration Date: July 2005 5 Graceful Restart Mechanism for BGP with MPLS 7 draft-ietf-mpls-bgp-mpls-restart-04.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 IPR Disclosure Acknowledgement 31 By submitting this Internet-Draft, I certify that any applicable 32 patent or other IPR claims of which I am aware have been disclosed, 33 and any of which I become aware will be disclosed, in accordance with 34 RFC 3668. 36 Copyright Notice 38 Copyright (C) The Internet Society (year). This document is subject 39 to the rights, licenses and restrictions contained in BCP 78, and 40 except as set forth therein, the authors retain all their rights. 42 Additional copyright notices are not permitted in IETF Documents 43 except in the case where such document is the product of a joint 44 development effort between the IETF and another standards development 45 organization or the document is a republication of the work of 46 another standards organization. Such exceptions must be approved on 47 an individual basis by the IAB. 49 Disclaimer 51 This document and the information contained herein are provided on an 52 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 53 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 54 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 55 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 56 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 57 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 59 Abstract 61 A mechanism for BGP that would help minimize the negative effects on 62 routing caused by BGP restart is described in "Graceful Restart 63 Mechanism for BGP" (see [1]). This document extends this mechanism to 64 also minimize the negative effects on MPLS forwarding caused by the 65 Label Switching Router's (LSR's) control plane restart, and 66 specifically by the restart of its BGP component when BGP is used to 67 carry MPLS labels and the LSR is capable of preserving the MPLS 68 forwarding state across the restart. 70 The mechanism described in this document is agnostic with respect to 71 the types of the addresses carried in the BGP Network Layer 72 Reachability Information (NLRI) field. As such it works in 73 conjunction with any of the address famililies that could be carried 74 in BGP (e.g., IPv4, IPv6, etc...) 76 The mechanism described in this document is applicable to all LSRs, 77 both those with the ability to preserve their forwarding state during 78 BGP restart and those without (although the latter need to implement 79 only a subset of the mechanism described in this document). 80 Supporting a subset of the mechanism described here by the LSRs that 81 can not preserve their MPLS forwarding state across the restart would 82 not reduce the negative impact on MPLS traffic caused by their 83 control plane restart, but it would minimize the impact if their 84 neighbor(s) are capable of preserving the forwarding state across the 85 restart of their control plane and implement the mechanism described 86 here. 88 Specification of Requirements 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 1. Motivation 96 For the sake of brevity in the context of this document by "MPLS 97 forwarding state" we mean either (outgoing label, 98 next hop)>, or (outgoing 99 label, next hop)>, or label pop, next hop>, or 100 mapping. In the context of this document 101 the forwarding state that is referred to in [1] means MPLS forwarding 102 state, as defined above. In the context of this document the term 103 "next hop" refers to the next hop as advertised in BGP. 105 In the case where a Label Switching Router (LSR) could preserve its 106 MPLS forwarding state across restart of its control plane, and 107 specifically its BGP component, and BGP is used to carry MPLS labels 108 (e.g., as specified in [RFC3107]), it may be desirable not to perturb 109 the LSPs going through that LSR (and specifically, the LSPs 110 established by BGP). In this document, we describe a mechanism that 111 allows to accomplish this goal. The mechanism described in this 112 document works in conjunction with the mechanism specified in [1]. 113 The mechanism described in this document places no restrictions on 114 the types of addresses (address families) that it can support. 116 The mechanism described in this document is applicable to all LSRs, 117 both those with the ability to preserve forwarding state during BGP 118 restart and those without (although the latter need to implement only 119 a subset of the mechanism described in this document). Supporting a 120 subset of the mechanism described here by the LSRs that can not 121 preserve their MPLS forwarding state across the restart would not 122 reduce the negative impact on MPLS traffic caused by their control 123 plane restart, but it would minimize the impact if their neighbor(s) 124 are capable of preserving the forwarding state across the restart of 125 their control plane and implement the mechanism described here. The 126 subset includes all the procedures described in this document, except 127 the procedures in Sections 4.1, 4.2, 4.3, 5, and 6. 129 2. General requirements 131 First of all an LSR MUST implement the Graceful Restart Mechanism for 132 BGP, as specified in [1]. Second, the LSR SHOULD be capable of 133 preserving its MPLS forwarding state across the restart of its 134 control plane (including the restart of BGP). Third, for the 135 label> bindings distributed 136 via BGP the LSR SHOULD be able either (a) to reconstruct the same 137 bindings as the LSR had prior to the restart (see Section 4), or (b) 138 to create new label> bindings after restart, while temporary 139 maintaining MPLS forwarding state corresponds to both the bindings 140 prior to the restart, as well as to the newly created bindings (see 141 Section 5). Fourth, as long as the LSR retains the MPLS forwarding 142 state that the LSR preserved across the restart, the labels from that 143 state can not be used to create new local label bindings (but could 144 be used to reconstruct the existing bindings, as per procedures in 145 Section 4). Finally, for each next hop, if the next hop is reachable 146 via a Label Switched Path (LSP), then the restarting LSR MUST be able 147 to preserve the MPLS forwarding state associated with that LSP across 148 the restart. 150 In the scenario where label binding on an LSR is created/maintained 151 not just by the BGP component of the control plane, but by other 152 protocol components as well (e.g., LDP, RSVP-TE), and the LSR 153 supports restart of the individual components of the control plane 154 that create/maintain label binding (e.g., restart of BGP, but no 155 restart of LDP) the LSR MUST be able to preserve across the restart 156 the information about which protocol has assigned which labels. 158 After the LSR restarts, it MUST follow the procedures as specified in 159 [1]. In addition, if the LSR is able to preserve its MPLS forwarding 160 state across the restart, the LSR SHOULD advertise this to its 161 neighbors by appropriately setting the Flag for Address Family field 162 in the Graceful Restart Capability for all applicable AFI/SAFI pairs. 164 3. Capability Advertisement 166 An LSR that supports the mechanism described in this document 167 advertises this to its peer by using the Graceful Restart Capability, 168 as specified in [1]. The Subsequent Address Family Identifier (SAFI) 169 in the advertised capability MUST indicate that the Network Layer 170 Reachability Information (NLRI) field carries not just addressing 171 Information, but labels as well (see [RFC3107] as an example of where 172 NLRI carries labels). 174 4. Procedures for the restarting LSR 176 Procedures in this section applies when a restarting LSR is able to 177 reconstruct the same label> bindings as the LSR had prior to 178 the restart. 180 The procedures described in this section are conceptual and do not 181 have to be implemented precisely as described here, as long as the 182 implementations support the described functionality and their 183 externally visible behavior is the same. 185 Once the LSR completes its route selection (as specified in Section 186 "Procedures for the Restarting Speaker" of [1]), then in addition to 187 the procedures specified in [1], the LSR performs one of the 188 following: 190 4.1. Case 1 192 The following applies when (a) the best route selected by the LSR was 193 received with a label, (b) that label is not an Implicit NULL, and 194 (c) the LSR advertises this route with itself as the next hop. 196 In this case the LSR searches its MPLS forwarding state (the one 197 preserved across the restart) for an entry with equal to the one in the received route. If such an entry is 199 found, the LSR no longer marks the entry as stale. In addition if the 200 entry is of type rather 201 than , the LSR uses the incoming label from the entry when 203 advertising the route to its neighbors. If the found entry has no 204 incoming label, or if no such entry is found, the LSR allocates a new 205 label when advertising the route to its neighbors (assuming that 206 there are neighbors to which the LSR has to advertise the route with 207 a label). 209 4.2. Case 2 211 The following applies when (a) the best route selected by the LSR was 212 received either without a label, or with an Implicit NULL label, or 213 the route is originated by the LSR, (b) the LSR advertises this route 214 with itself as the next hop, and (c) the LSR has to generate a (non 215 Implicit NULL) label for the route. 217 In this case the LSR searches its MPLS forwarding state for an entry 218 that indicates that the LSR has to perform label pop, and the next 219 hop equal to the next hop of the route in consideration. If such an 220 entry is found, then the LSR uses the incoming label from the entry 221 when advertising the route to its neighbors. If no such entry is 222 found, the LSR allocates a new label when advertising the route to 223 its neighbors. 225 The description in the above paragraph assumes that the LSR generates 226 the same label for all the routes with the same next hop. If this is 227 not the case, and the LSR generates a unique label per each such 228 route, then the LSR needs to preserve across the restart not just 229 mapping, but also the 230 Forwarding Equivalence Class (FEC) associated with this mapping. In 231 such case the LSR would search its MPLS forwarding state for an entry 232 that (a) indicates Label pop (means no outgoing label), (b) the next 233 hop equal to the next hop of the route and (c) has the same FEC as 234 the route. If such an entry is found, then the LSR uses the incoming 235 label from the entry when advertising the route to its neighbors. If 236 no such entry is found, the LSR allocates a new label when 237 advertising the route to its neighbors. 239 4.3. Case 3 241 The following applies when the LSR does not set BGP next hop to self. 243 In this case the LSR, when advertising its best route for a 244 particular NLRI just uses the label that was received with that 245 route. And if the route was received with no label, the LSR 246 advertises the route with no label as well. Either way, the LSR does 247 not allocate label for that route. 249 5. Alternative procedures for the restarting LSR 251 In this section we describe an alternative to the procedures 252 described in Section "Procedures for the restarting LSR". 254 Procedures in this section apply when a restarting LSR does not 255 reconstruct the same label> bindings as the LSR had prior to 256 the restart, but instead creates new label> bindings after 257 restart, while temporary maintaining MPLS forwarding state 258 corresponding to both the bindings prior to the restart, as well as 259 to the newly created bindings. 261 The procedures described in this section requires that for the use by 262 BGP graceful restart the LSR SHOULD have (at least) as many 263 unallocated labels as labels allocated for the label> 264 bindings distributed by BGP. The latter forms the MPLS forwarding 265 state that the LSR managed to preserve across the restart. The former 266 is used for allocating labels after the restart. 268 To create (new) local label bindings after the restart the LSR uses 269 unallocated labels (this is pretty much the normal procedure). 271 The LSR SHOULD retain the MPLS forwarding state that the LSR 272 preserved across the restart at least until the LSR sends End-of-RIB 273 marker to all of its neighbors (by that time the LSR already 274 completed its route selection process, and also advertised its Adj- 275 RIB-Out to its neighbors). The LSR MAY retain the forwarding state 276 even a bit longer (the amount of extra time MAY be controlled by 277 configuration on the LSR), as to allow the neighbors to receive and 278 process the routes that have been advertised by the LSR. After that, 279 the LSR MAY delete the MPLS forwarding state that it preserved across 280 the restart. 282 Note that while an LSR is in the process of restarting, the LSR may 283 have not one, but two local label bindings for a given BGP route - 284 one that was retained from prior to restart, and another that was 285 created after the restart. Once the LSR completes its restart, the 286 former will be deleted. Both of these bindings though would have the 287 same outgoing label (and the same next hop). 289 6. Procedures for a neighbor of a restarting LSR 291 The neighbor of a restarting LSR (the receiving router in terminology 292 used in [1]) follows the procedures specified in [1]. In addition, 293 the neighbor treats the MPLS labels received from the restarting LSR 294 the same way as it treats the routes received from the restarting LSR 295 (both prior and after the restart). 297 Replacing the stale routes by the routing updates received from the 298 restarting LSR involves replacing/updating the appropriate MPLS 299 labels. 301 In addition, if the Flags in the Graceful Restart Capability received 302 from the restarting LSR indicate that the LSR wasn't able to retain 303 its MPLS state across the restart, the neighbor SHOULD immediately 304 remove all the NLRI and the associated MPLS labels that it previously 305 acquired via BGP from the restarting LSR. 307 An LSR, once it creates a binding between a label and a Forwarding 308 Equivalence Class (FEC), SHOULD keep the value of the label in this 309 binding for as long as the LSR has a route to the FEC in the binding. 310 If the route to the FEC disappears, and then re-appears again later, 311 then this may result in using a different label value, as when the 312 route re-appears, the LSR would create a new binding. 314 To minimize the potential mis-routing caused by the label change, 315 when creating a new binding the LSR SHOULD pick up the 316 least recently used label. Once an LSR releases a label, the LSR 317 SHALL NOT re-use this label for advertising a binding to 318 a neighbor that supports graceful restart for at least the Restart 319 Time, as advertised by the neighbor to the LSR. 321 7. Comparison between alternative procedures for the restarting LSR 323 Procedures described in Section 4 involve more computational overhead 324 on the restarting router relative to the procedures described in 325 Section 5. 327 Procedures described in Section 5 requires twice as many labels as 328 the procedures described in Section 4. 330 Procedures described in Section 4 cause fewer changes to the MPLS 331 forwarding state in the neighbors of the restarting router than the 332 procedures described in Section 5. 334 In principle it is possible for an LSR to use procedures described in 335 Section 4 for some AFI/SAFI(s) and procedures described in Section 5 336 for other AFI/SAFI(s). 338 8. Security Consideration 340 The security considerations pertaining to the original BGP protocol 341 remain relevant. 343 In addition, the mechanism described here renders LSRs that implement 344 it to additional denial-of-service attacks as follows: 346 An intruder may impersonate a BGP peer in order to force a failure 347 and reconnection of the TCP connection, but where the intruder 348 sets the Forwarding State (F) bit (as defined in [1]) to 0 on 349 reconnection. This forces all labels received from the peer to be 350 released. 352 An intruder could intercept the traffic between BGP peers and 353 override the setting of the Forwarding State (F) bit to be set to 354 0. This forces all labels received from the peer to be released. 356 All of these attacks may be countered by use of an authentication 357 scheme between BGP peers, such as the scheme outlined in [RFC2385]. 359 As with BGP carrying labels, a security issue may exist if a BGP 360 implementation continues to use labels after expiration of the BGP 361 session that first caused them to be used. This may arise if the 362 upstream LSR detects the session failure after the downstream LSR has 363 released and re-used the label. The problem is most obvious with the 364 platform-wide label space and could result in mis-routing of data to 365 other than intended destinations and it is conceivable that these 366 behaviors may be deliberately exploited to either obtain services 367 without authorization or to deny services to others. 369 In this document, the validity of the BGP session may be extended by 370 the Restart Time, and the session may be re-established in this 371 period. After the expiry of the Restart Time the session must be 372 considered to have failed and the same security issue applies as 373 described above. 375 However, the downstream LSR may declare the session as failed before 376 the expiration of its Restart Time. This increases the period during 377 which the downstream LSR might reallocate the label while the 378 upstream LSR continues to transmit data using the old usage of the 379 label. To reduce this issue, this document requires that labels are 380 not re-used until for at least the Restart Time. 382 9. Intellectual Property Considerations 384 This section is taken from Section 10.4 of [RFC2026]. 386 The IETF takes no position regarding the validity or scope of any 387 intellectual property or other rights that might be claimed to 388 pertain to the implementation or use of the technology described in 389 this document or the extent to which any license under such rights 390 might or might not be available; neither does it represent that it 391 has made any effort to identify any such rights. Information on the 392 IETF's procedures with respect to rights in standards-track and 393 standards-related documentation can be found in BCP-11. Copies of 394 claims of rights made available for publication and any assurances of 395 licenses to be made available, or the result of an attempt made to 396 obtain a general license or permission for the use of such 397 proprietary rights by implementors or users of this specification can 398 be obtained from the IETF Secretariat. 400 The IETF invites any interested party to bring to its attention any 401 copyrights, patents or patent applications, or other proprietary 402 rights which may cover technology that may be required to practice 403 this standard. Please address the information to the IETF Executive 404 Director. 406 The IETF has been notified of intellectual property rights claimed in 407 regard to some or all of the specification contained in this 408 document. For more information consult the online list of claimed 409 rights. 411 Juniper Networks, Inc. is seeking patent protection on some or all of 412 the technology described in this Internet-Draft. If technology in 413 this document is adopted as a standard, Juniper Networks agrees to 414 license, on reasonable and non-discriminatory terms, any patent 415 rights it obtains covering such technology to the extent necessary to 416 comply with the standard. 418 Redback Networks, Inc. is seeking patent protection on some of the 419 technology described in this Internet-Draft. If technology in this 420 document is adopted as a standard, Redback Networks agrees to 421 license, on reasonable and non-discriminatory terms, any patent 422 rights it obtains covering such technology to the extent necessary to 423 comply with the standard. 425 10. Copyright Notice 427 Copyright (C) The Internet Society (date). All Rights Reserved. 429 This document and translations of it may be copied and furnished to 430 others, and derivative works that comment on or otherwise explain it 431 or assist in its implmentation may be prepared, copied, published and 432 distributed, in whole or in part, without restriction of any kind, 433 provided that the above copyright notice and this paragraph are 434 included on all such copies and derivative works. However, this 435 document itself may not be modified in any way, such as by removing 436 the copyright notice or references to the Internet Society or other 437 Internet organizations, except as needed for the purpose of 438 developing Internet standards in which case the procedures for 439 copyrights defined in the Internet Standards process must be 440 followed, or as required to translate it into languages other than 441 English. 443 The limited permissions granted above are perpetual and will not be 444 revoked by the Internet Society or its successors or assigns. 446 This document and the information contained herein is provided on an 447 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 448 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 449 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 450 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 451 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 453 11. Acknowledgments 455 We would like to thank Chaitanya Kodeboyina and Loa Andersson for 456 their review and comments. The approach described in Section 457 "Alternative procedures for the restarting LSR" is based on the idea 458 suggested by Manoj Leelanivas. 460 12. Normative References 462 [1] "Graceful Restart Mechanism for BGP", draft-ietf-idr- 463 restart-01.txt 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119 468 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 469 Signature Option", RFC2385 471 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 472 3", RFC2026 474 13. Non-normative References 476 [RFC3107] Rekhter, Y., Rosen, E., "Carrying Label Information in 477 BGP-4", RFC3107 479 14. Author Information 481 Yakov Rekhter 482 Juniper Networks 483 1194 N.Mathilda Ave 484 Sunnyvale, CA 94089 485 e-mail: yakov@juniper.net 487 Rahul Aggarwal 488 Juniper Networks 489 1194 N.Mathilda Ave 490 Sunnyvale, CA 94089 491 e-mail: rahul@juniper.net