idnits 2.17.1 draft-ietf-mpls-bgp-mpls-restart-05.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 3978, Section 5.1 on line 32. -- Found old boilerplate from RFC 3978, Section 5.5 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 382. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 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 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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) == Unused Reference: 'RFC2026' is defined on line 417, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: February 2006 5 Graceful Restart Mechanism for BGP with MPLS 7 draft-ietf-mpls-bgp-mpls-restart-05.txt 9 Status of this Memo 11 Internet-Drafts are working documents of the Internet Engineering 12 Task Force (IETF), its areas, and its working groups. Note that 13 other groups may also distribute working documents as Internet- 14 Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress". 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 IPR Disclosure Acknowledgement 29 By submitting this Internet-Draft, each author represents that any 30 applicable patent or other IPR claims of which he or she is aware 31 have been or will be disclosed, and any of which he or she becomes 32 aware will be disclosed, in accordance with Section 6 of BCP 79. 34 Abstract 36 A mechanism for BGP that helps minimize the negative effects on 37 routing caused by BGP restart has already been developed an is 38 described in a separate document ("Graceful Restart Mechanism for 39 BGP"). This document extends this mechanism to also minimize the 40 negative effects on MPLS forwarding caused by the Label Switching 41 Router's (LSR's) control plane restart, and specifically by the 42 restart of its BGP component when BGP is used to carry MPLS labels 43 and the LSR is capable of preserving the MPLS forwarding state across 44 the restart. 46 The mechanism described in this document is agnostic with respect to 47 the types of the addresses carried in the BGP Network Layer 48 Reachability Information (NLRI) field. As such it works in 49 conjunction with any of the address famililies that could be carried 50 in BGP (e.g., IPv4, IPv6, etc...) 52 The mechanism described in this document is applicable to all LSRs, 53 both those with the ability to preserve their forwarding state during 54 BGP restart and those without (although the latter need to implement 55 only a subset of the mechanism described in this document). 56 Supporting a subset of the mechanism described here by the LSRs that 57 can not preserve their MPLS forwarding state across the restart would 58 not reduce the negative impact on MPLS traffic caused by their 59 control plane restart, but it would minimize the impact if their 60 neighbor(s) are capable of preserving the forwarding state across the 61 restart of their control plane and implement the mechanism described 62 here. 64 Specification of Requirements 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 1. Introduction 72 For the sake of brevity in the context of this document by "MPLS 73 forwarding state" we mean either (outgoing label, 74 next hop)>, or (outgoing 75 label, next hop)>, or label pop, next hop>, or 76 mapping. In the context of this document 77 the forwarding state that is referred to in [1] means MPLS forwarding 78 state, as defined above. In the context of this document the term 79 "next hop" refers to the next hop as advertised in BGP. 81 In the case where a Label Switching Router (LSR) could preserve its 82 MPLS forwarding state across restart of its control plane, and 83 specifically its BGP component, and BGP is used to carry MPLS labels 84 (e.g., as specified in [RFC3107]), it may be desirable not to perturb 85 the LSPs going through that LSR (and specifically, the LSPs 86 established by BGP) after failure of or restart of the BGP component 87 of the control plane. In this document, we describe a mechanism that 88 allows this goal to be accomplished. The mechanism described in this 89 document works in conjunction with the mechanism specified in [1]. 90 The mechanism described in this document places no restrictions on 91 the types of addresses (address families) that it can support. 93 The mechanism described in this document is applicable to all LSRs, 94 both those with the ability to preserve forwarding state during BGP 95 restart and those without (although the latter need to implement only 96 a subset of the mechanism described in this document). Supporting a 97 subset of the mechanism described here by the LSRs that can not 98 preserve their MPLS forwarding state across the restart would not 99 reduce the negative impact on MPLS traffic caused by their control 100 plane restart, but it would minimize the impact if their neighbor(s) 101 are capable of preserving the forwarding state across the restart of 102 their control plane and implement the mechanism described here. The 103 subset includes all the procedures described in this document, except 104 the procedures in Sections 4.1, 4.2, 4.3 and 5. 106 2. General requirements 108 First of all an LSR MUST implement the Graceful Restart Mechanism for 109 BGP, as specified in [1]. Second, the LSR SHOULD be capable of 110 preserving its MPLS forwarding state across the restart of its 111 control plane (including the restart of BGP). Third, for the 112 label> bindings distributed 113 via BGP the LSR SHOULD be able either (a) to reconstruct the same 114 bindings as the LSR had prior to the restart (see Section 4), or (b) 115 to create new label> bindings after restart, while 116 temporarily maintaining MPLS forwarding state corresponding to both 117 the bindings prior to the restart, as well as to the newly created 118 bindings (see Section 5). Fourth, as long as the LSR retains the MPLS 119 forwarding state that the LSR preserved across the restart, the 120 labels from that state can not be used to create new local label 121 bindings (but could be used to reconstruct the existing bindings, as 122 per procedures in Section 4). Finally, for each next hop, if the next 123 hop is reachable via a Label Switched Path (LSP), then the restarting 124 LSR MUST be able to preserve the MPLS forwarding state associated 125 with that LSP across the restart. 127 In the scenario where label binding on an LSR is created/maintained 128 not just by the BGP component of the control plane, but by other 129 protocol components as well (e.g., LDP, RSVP-TE), and the LSR 130 supports restart of the individual components of the control plane 131 that create/maintain label binding (e.g., restart of BGP, but no 132 restart of LDP) the LSR MUST be able to preserve across the restart 133 the information about which protocol has assigned which labels. 135 After the LSR restarts, it MUST follow the procedures as specified in 136 [1]. In addition, if the LSR is able to preserve its MPLS forwarding 137 state across the restart, the LSR SHOULD advertise this to its 138 neighbors by appropriately setting the Flag for Address Family field 139 in the Graceful Restart Capability for all applicable AFI/SAFI pairs. 141 3. Capability Advertisement 143 An LSR that supports the mechanism described in this document 144 advertises this to its peer by using the Graceful Restart Capability, 145 as specified in [1]. The Subsequent Address Family Identifier (SAFI) 146 in the advertised capability MUST indicate that the Network Layer 147 Reachability Information (NLRI) field carries not just addressing 148 Information, but labels as well (see [RFC3107] as an example of where 149 NLRI carries labels). 151 4. Procedures for the restarting LSR 153 Procedures in this section apply when a restarting LSR is able to 154 reconstruct the same label> bindings as the LSR had prior to 155 the restart. 157 The procedures described in this section are conceptual and do not 158 have to be implemented precisely as described here, as long as the 159 implementations support the described functionality and their 160 externally visible behavior is the same. 162 Once the LSR completes its route selection (as specified in Section 163 "Procedures for the Restarting Speaker" of [1]), then in addition to 164 the procedures specified in [1], the LSR performs one of the 165 following: 167 4.1. Case 1 169 The following applies when (a) the best route selected by the LSR was 170 received with a label, (b) that label is not an Implicit NULL, and 171 (c) the LSR advertises this route with itself as the next hop. 173 In this case the LSR searches its MPLS forwarding state (the one 174 preserved across the restart) for an entry with equal to the one in the received route. If such an entry is 176 found, the LSR no longer marks the entry as stale. In addition if the 177 entry is of type rather 178 than , the LSR uses the incoming label from the entry when 180 advertising the route to its neighbors. If the found entry has no 181 incoming label, or if no such entry is found, the LSR allocates a new 182 label when advertising the route to its neighbors (assuming that 183 there are neighbors to which the LSR has to advertise the route with 184 a label). 186 4.2. Case 2 188 The following applies when (a) the best route selected by the LSR was 189 received either without a label, or with an Implicit NULL label, or 190 the route is originated by the LSR, (b) the LSR advertises this route 191 with itself as the next hop, and (c) the LSR has to generate a (non 192 Implicit NULL) label for the route. 194 In this case the LSR searches its MPLS forwarding state for an entry 195 that indicates that the LSR has to perform label pop, and the next 196 hop equal to the next hop of the route in consideration. If such an 197 entry is found, then the LSR uses the incoming label from the entry 198 when advertising the route to its neighbors. If no such entry is 199 found, the LSR allocates a new label when advertising the route to 200 its neighbors. 202 The description in the above paragraph assumes that the LSR generates 203 the same label for all the routes with the same next hop. If this is 204 not the case, and the LSR generates a unique label per each such 205 route, then the LSR needs to preserve across the restart not just 206 mapping, but also the 207 Forwarding Equivalence Class (FEC) associated with this mapping. In 208 such case the LSR would search its MPLS forwarding state for an entry 209 that (a) indicates Label pop (means no outgoing label), (b) the next 210 hop equal to the next hop of the route and (c) has the same FEC as 211 the route. If such an entry is found, then the LSR uses the incoming 212 label from the entry when advertising the route to its neighbors. If 213 no such entry is found, the LSR allocates a new label when 214 advertising the route to its neighbors. 216 4.3. Case 3 218 The following applies when the LSR does not set BGP next hop to self. 220 In this case the LSR, when advertising its best route for a 221 particular NLRI just uses the label that was received with that 222 route. And if the route was received with no label, the LSR 223 advertises the route with no label as well. Either way, the LSR does 224 not allocate a label for that route. 226 5. Alternative procedures for the restarting LSR 228 In this section we describe an alternative to the procedures 229 described in Section "Procedures for the restarting LSR". 231 Procedures in this section apply when a restarting LSR does not 232 reconstruct the same label> bindings as the LSR had prior to 233 the restart, but instead creates new label> bindings after 234 restart, while temporarily maintaining MPLS forwarding state 235 corresponding to both the bindings prior to the restart, as well as 236 to the newly created bindings. 238 The procedures described in this section require that for the use by 239 BGP graceful restart the LSR SHOULD have (at least) as many 240 unallocated labels as labels allocated for the label> 241 bindings distributed by BGP. The latter forms the MPLS forwarding 242 state that the LSR managed to preserve across the restart. The former 243 is used for allocating labels after the restart. 245 To create (new) local label bindings after the restart the LSR uses 246 unallocated labels (this is pretty much the normal procedure). 248 The LSR SHOULD retain the MPLS forwarding state that the LSR 249 preserved across the restart at least until the LSR sends End-of-RIB 250 marker to all of its neighbors (by that time the LSR already 251 completed its route selection process, and also advertised its Adj- 252 RIB-Out to its neighbors). The LSR MAY retain the forwarding state 253 even a bit longer (the amount of extra time MAY be controlled by 254 configuration on the LSR), as to allow the neighbors to receive and 255 process the routes that have been advertised by the LSR. After that, 256 the LSR SHOULD delete the MPLS forwarding state that it preserved 257 across the restart. 259 Note that while an LSR is in the process of restarting, the LSR may 260 have not one, but two local label bindings for a given BGP route - 261 one that was retained from prior to restart, and another that was 262 created after the restart. Once the LSR completes its restart, the 263 former will be deleted. Both of these bindings though would have the 264 same outgoing label (and the same next hop). 266 6. Procedures for a neighbor of a restarting LSR 268 The neighbor of a restarting LSR (the receiving router in terminology 269 used in [1]) follows the procedures specified in [1]. In addition, 270 the neighbor treats the MPLS labels received from the restarting LSR 271 the same way as it treats the routes received from the restarting LSR 272 (both prior and after the restart). 274 Replacing the stale routes by the routing updates received from the 275 restarting LSR involves replacing/updating the appropriate MPLS 276 labels. 278 In addition, if the Flags in the Graceful Restart Capability received 279 from the restarting LSR indicate that the LSR wasn't able to retain 280 its MPLS state across the restart, the neighbor SHOULD immediately 281 remove all the NLRI and the associated MPLS labels that it previously 282 acquired via BGP from the restarting LSR. 284 An LSR, once it creates a binding between a label and a Forwarding 285 Equivalence Class (FEC), SHOULD keep the value of the label in this 286 binding for as long as the LSR has a route to the FEC in the binding. 287 If the route to the FEC disappears, and then re-appears again later, 288 then this may result in using a different label value, as when the 289 route re-appears, the LSR would create a new binding. 291 To minimize the potential mis-routing caused by the label change, 292 when creating a new binding the LSR SHOULD pick up the 293 least recently used label. Once an LSR releases a label, the LSR 294 SHALL NOT re-use this label for advertising a binding to 295 a neighbor that supports graceful restart for at least the Restart 296 Time, as advertised by the neighbor to the LSR. This rule SHALL 297 apply to any label release at any time. 299 7. Comparison between alternative procedures for the restarting LSR 301 Procedures described in Section 4 involve more computational overhead 302 on the restarting router relative to the procedures described in 303 Section 5. 305 Procedures described in Section 5 requires twice as many labels as 306 the procedures described in Section 4. 308 Procedures described in Section 4 cause fewer changes to the MPLS 309 forwarding state in the neighbors of the restarting router than the 310 procedures described in Section 5. 312 In principle it is possible for an LSR to use procedures described in 313 Section 4 for some AFI/SAFI(s) and procedures described in Section 5 314 for other AFI/SAFI(s). 316 8. Security Consideration 318 The security considerations pertaining to the original BGP protocol 319 remain relevant. 321 In addition, the mechanism described here renders LSRs that implement 322 it vulnerable to additional denial-of-service attacks as follows: 324 An intruder may impersonate a BGP peer in order to force a failure 325 and reconnection of the TCP connection, but where the intruder 326 sets the Forwarding State (F) bit (as defined in [1]) to 0 on 327 reconnection. This forces all labels received from the peer to be 328 released. 330 An intruder could intercept the traffic between BGP peers and 331 override the setting of the Forwarding State (F) bit to be set to 332 0. This forces all labels received from the peer to be released. 334 All of these attacks may be countered by use of an authentication 335 scheme between BGP peers, such as the scheme outlined in [RFC2385]. 337 As with BGP carrying labels, a security issue may exist if a BGP 338 implementation continues to use labels after expiration of the BGP 339 session that first caused them to be used. This may arise if the 340 upstream LSR detects the session failure after the downstream LSR has 341 released and re-used the label. The problem is most obvious with the 342 platform-wide label space and could result in mis-routing of data to 343 other than intended destinations and it is conceivable that these 344 behaviors may be deliberately exploited to either obtain services 345 without authorization or to deny services to others. 347 In this document, the validity of the BGP session may be extended by 348 the Restart Time, and the session may be re-established in this 349 period. After the expiry of the Restart Time the session must be 350 considered to have failed and the same security issue applies as 351 described above. 353 However, the downstream LSR may declare the session as failed before 354 the expiration of its Restart Time. This increases the period during 355 which the downstream LSR might reallocate the label while the 356 upstream LSR continues to transmit data using the old usage of the 357 label. To reduce this issue, this document requires that labels are 358 not re-used until for at least the Restart Time. 360 9. Intellectual Property Considerations 362 The IETF takes no position regarding the validity or scope of any 363 Intellectual Property Rights or other rights that might be claimed to 364 pertain to the implementation or use of the technology described in 365 this document or the extent to which any license under such rights 366 might or might not be available; nor does it represent that it has 367 made any independent effort to identify any such rights. Information 368 on the procedures with respect to rights in RFC documents can be 369 found in BCP 78 and BCP 79. 371 Copies of IPR disclosures made to the IETF Secretariat and any 372 assurances of licenses to be made available, or the result of an 373 attempt made to obtain a general license or permission for the use of 374 such proprietary rights by implementers or users of this 375 specification can be obtained from the IETF on-line IPR repository at 376 http://www.ietf.org/ipr. 378 The IETF invites any interested party to bring to its attention any 379 copyrights, patents or patent applications, or other proprietary 380 rights that may cover technology that may be required to implement 381 this standard. Please address the information to the IETF at ietf- 382 ipr@ietf.org. 384 10. Copyright Notice 386 Copyright (C) The Internet Society (2005). 388 This document is subject to the rights, licenses and restrictions 389 contained in BCP 78, and except as set forth therein, the authors 390 retain all their rights. 392 This document and the information contained herein are provided on an 393 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 394 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 395 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 396 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 397 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 398 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 400 11. Acknowledgments 402 We would like to thank Chaitanya Kodeboyina and Loa Andersson for 403 their review and comments. The approach described in Section 404 "Alternative procedures for the restarting LSR" is based on the idea 405 suggested by Manoj Leelanivas. 407 12. Normative References 409 [1] "Graceful Restart Mechanism for BGP", work in progress 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119 414 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 415 Signature Option", RFC2385 417 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 418 3", RFC2026 420 13. Non-normative References 422 [RFC3107] Rekhter, Y., Rosen, E., "Carrying Label Information in 423 BGP-4", RFC3107 425 14. Author Information 427 Yakov Rekhter 428 Juniper Networks 429 1194 N.Mathilda Ave 430 Sunnyvale, CA 94089 431 e-mail: yakov@juniper.net 433 Rahul Aggarwal 434 Juniper Networks 435 1194 N.Mathilda Ave 436 Sunnyvale, CA 94089 437 e-mail: rahul@juniper.net