idnits 2.17.1 draft-ietf-mpls-bgp-mpls-restart-03.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 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 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 document seems to lack an Authors' Addresses Section. ** 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: ---------------------------------------------------------------------------- == Line 397 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 3107 (ref. '2') (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yakov Rekhter (Juniper Networks) 3 Internet Draft Rahul Aggarwal (Juniper Networks) 4 Expiration Date: August 2004 6 Graceful Restart Mechanism for BGP with MPLS 8 draft-ietf-mpls-bgp-mpls-restart-03.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 A mechanism for BGP that would help minimize the negative effects on 33 routing caused by BGP restart is described in "Graceful Restart 34 Mechanism for BGP" (see [1]). This document extends this mechanism to 35 also minimize the negative effects on MPLS forwarding caused by the 36 Label Switching Router's (LSR's) control plane restart, and 37 specifically by the restart of its BGP component when BGP is used to 38 carry MPLS labels and the LSR is capable of preserving the MPLS 39 forwarding state across the restart. 41 The mechanism described in this document is agnostic with respect to 42 the types of the addresses carried in the BGP Network Layer 43 Reachability Information (NLRI) field. As such it works in 44 conjunction with any of the address famililies that could be carried 45 in BGP (e.g., IPv4, IPv6, etc...) 46 The mechanism described in this document is applicable to all LSRs, 47 both those with the ability to preserve their forwarding state during 48 BGP restart and those without (although the latter need to implement 49 only a subset of the mechanism described in this document). 50 Supporting (a subset of) the mechanism described here by the LSRs 51 that can not preserve their MPLS forwarding state across the restart 52 would not reduce the negative impact on MPLS traffic caused by their 53 control plane restart, but it would minimize the impact if their 54 neighbor(s) are capable of preserving the forwarding state across the 55 restart of their control plane and implement the mechanism described 56 here. 58 The mechanism makes minimalistic assumptions on what has to be 59 preserved across restart - the mechanism assumes that only the actual 60 MPLS forwarding state has to be preserved; the mechanism does not 61 require any of the BGP-related state to be preserved across the 62 restart. 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 Summary for Sub-IP Area 72 (This section to be removed before publication.) 74 0.1 Summary 76 This document describes a mechanism that helps to minimize the 77 negative effects on MPLS forwarding caused by LSR's control plane 78 restart, and specifically by the restart of its BGP component in the 79 case where BGP is used to carry MPLS labels and LSR is capable of 80 preserving its MPLS forwarding state across the restart. 82 0.2 Related documents 84 See the Reference Section 86 0.3 Where does it fit in the Picture of the Sub-IP Work 88 This work fits squarely in MPLS box. 90 0.4 Why is it Targeted at this WG 92 The specifications on carrying MPLS Labels in BGP is a product of the 93 MPLS WG. This document specifies procedures to minimize the negative 94 effects on MPLS forwarding caused by the restart of the control plane 95 BGP module in the case where BGP is used to carry MPLS labels. Since 96 the procedures described in this document are directly related to 97 MPLS forwarding and carrying MPLS labels in BGP, it would be logical 98 to target this document at the MPLS WG. 100 0.5 Justification 102 The WG should consider this document, as it allows to minimize the 103 negative effects on MPLS forwarding caused by the restart of the 104 control plane BGP module in the case where BGP is used to carry MPLS 105 labels. 107 1. Motivation 109 For the sake of brevity in the context of this document by "MPLS 110 forwarding state" we mean either (outgoing label, 111 next hop)>, or
(outgoing label, next hop)> 112 mapping. In the context of this document the forwarding state that is 113 referred to in [1] means MPLS forwarding state. 115 In the case where a Label Switching Router (LSR) could preserve its 116 MPLS forwarding state across restart of its control plane, and 117 specifically its BGP component, and BGP is used to carry MPLS labels 118 (as specified in [2]), it may be desirable not to perturb the LSPs 119 going through that LSR (and specifically, the LSPs established by 120 BGP). In this document, we describe a mechanism that allows to 121 accomplish this goal. The mechanism described in this document works 122 in conjunction with the mechanism specified in [1]. The mechanism 123 described in this document places no restrictions on the types of 124 addresses (address families) that it can support. 126 The mechanism described in this document is applicable to all LSRs, 127 both those with the ability to preserve forwarding state during BGP 128 restart and those without (although the latter need to implement only 129 a subset of the mechanism described in this document). Supporting (a 130 subset of) the mechanism described here by the LSRs that can not 131 preserve their MPLS forwarding state across the restart would not 132 reduce the negative impact on MPLS traffic caused by their control 133 plane restart, but it would minimize the impact if their neighbor(s) 134 are capable of preserving the forwarding state across the restart of 135 their control plane and implement the mechanism described here. 137 2. Assumptions 139 First of all we assume that an LSR implements the Graceful Restart 140 Mechanism for BGP, as specified in [1]. Second, we assume that the 141 LSR is capable of preserving its MPLS forwarding state across the 142 restart of its control plane (including the restart of BGP). 144 The mechanism makes minimalistic assumptions on what has to be 145 preserved across restart - the mechanism assumes that only the actual 146 MPLS forwarding state has to be preserved; the mechanism does not 147 require any of the BGP-related state to be preserved across the 148 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 needs to preserve across the restart the 156 information about which protocol has assigned which labels. 158 3. Capability Advertisement 160 An LSR that supports the mechanism described in this document 161 advertises this to its peer by using the Graceful Restart Capability, 162 as specified in [1]. The Subsequent Address Family Identifier (SAFI) 163 in the advertised capability MUST indicate that the Network Layer 164 Reachability Information (NLRI) field carries not just addressing 165 information but labels as well (see [2]). 167 4. Procedures for the restarting LSR 169 After the LSR restarts, it follows the procedures as specified in 170 [1]. In addition, if the LSR is able to preserve its MPLS forwarding 171 state across the restart, the LSR advertises this to its neighbors by 172 appropriately setting the Flag field in the Graceful Restart 173 Capability for all applicable AFI/SAFI pairs. 175 Once the restarting LSR completes its route selection (as specified 176 in Section "Procedures for the Restarting Speaker" of [1]), then in 177 addition to the procedures specified in [1], the restarting LSR 178 performs one of the following: 180 4.1. Case 1 182 The following applies when (a) the best route selected by the 183 restarting LSR was received with a label, (b) that label is not an 184 Implicit NULL, and (c) the LSR advertises this route with itself as 185 the next hop. 187 In this case the restarting LSR searches its MPLS forwarding state 188 (the one preserved across the restart) for an entry with equal to the one in the received route. If such an 190 entry is found, the LSR no longer marks the entry as stale. In 191 addition if the entry is of type rather than , the LSR 193 uses the incoming label from the entry when advertising the route to 194 its neighbors. If the found entry has no incoming label, or if no 195 such entry is found, the LSR just picks up some unused label when 196 advertising the route to its neighbors (assuming that there are 197 neighbors to which the LSR has to advertise the route with a label). 199 4.2. Case 2 201 The following applies when (a) the best route selected by the 202 restarting LSR was received either without a label, or with an 203 Implicit NULL label, or the route is originated by the restarting 204 LSR, (b) the LSR advertises this route with itself as the next hop, 205 and (c) the LSR has to generate a (non Implicit NULL) label for the 206 route. 208 In this case the LSR searches its MPLS forwarding state for an entry 209 that indicates that the LSR has to perform label pop, and the next 210 hop equal to the next hop of the route in consideration. If such an 211 entry is found, then the LSR uses the incoming label from the entry 212 when advertising the route to its neighbors. If no such entry is 213 found, the LSR just picks up some unused label when advertising the 214 route to its neighbors. 216 The description in the above paragraph assumes that the restarting 217 LSR generates the same label for all the routes with the same next 218 hop. If this is not the case, and the restarting LSR generates a 219 unique label per each such route, then the LSR needs to preserve 220 across the restart not just mapping, but also the prefix associated with this mapping. In 222 such case the LSR would search its MPLS forwarding state for an entry 223 that (a) indicates Label pop (means no outgoing label), (b) the next 224 hop equal to the next hop of the route and (c) has the same prefix as 225 the route. If such an entry is found, then the LSR uses the incoming 226 label from the entry when advertising the route to its neighbors. If 227 no such entry is found, the LSR just picks up some unused label when 228 advertising the route to its neighbors. 230 4.3. Case 3 232 The following applies when the restarting LSR does not set BGP Next 233 Hop to self. 235 In this case the restarting LSR, when advertising its best route for 236 a particular NLRI just uses the label that was received with that 237 route. And if the route was received with no label, the LSR 238 advertises the route with no label as well. 240 5. Alternative procedures for the restarting LSR 242 In this section we describe an alternative to the procedures 243 described in Section "Procedures for the restarting LSR". 245 The procedures described in this section assume that the restarting 246 LSR has (at least) as many unallocated as allocated labels. The 247 latter forms the MPLS forwarding state that the LSR managed to 248 preserve across the restart. The former is used for allocating labels 249 after the restart. 251 After the LSR restarts, it follows the procedures as specified in 252 [1]. In addition, if the LSR is able to preserve its MPLS forwarding 253 state across the restart, the LSR advertises this to its neighbors by 254 appropriately setting the Flag field in the Graceful Restart 255 Capability. 257 To create local label bindings the LSR uses unallocated labels (this 258 is pretty much the normal procedure). That means that as long as the 259 LSR retains the MPLS forwarding state that the LSR preserved across 260 the restart, the labels from that state are not used for creating 261 local label bindings. 263 The restarting LSR SHOULD retain the MPLS forwarding state that the 264 LSR preserved across the restart at least until the LSR sends End-of- 265 RIB marker to all of its neighbors (by that time the LSR already 266 completed its route selection process, and also advertised its Adj- 267 RIB-Out to its neighbors). The restarting LSR MAY retain the 268 forwarding state even a bit longer, as to allow the neighbors to 269 receive and process the routes that have been advertised by the 270 restarting LSR. After that, the restarting LSR MAY delete the MPLS 271 forwarding state that it preserved across the restart. 273 Note that while an LSR is in the process of restarting, the LSR may 274 have not one, but two local label bindings for a given BGP route - 275 one that was retained from prior to restart, and another that was 276 created after the restart. Once the LSR completes its restart, the 277 former will be deleted. Both of these bindings though would have the 278 same outgoing label (and the same next hop). 280 6. Procedures for a neighbor of a restarting LSR 282 The neighbor of a restarting LSR (the receiving router in terminology 283 used in [1]) follows the procedures specified in [1]. In addition, 284 the neighbor treats the MPLS labels received from the restarting LSR 285 the same way as it treats the routes received from the restarting LSR 286 (both prior and after the restart). 288 Replacing the stale routes by the routing updates received from the 289 restarting LSR involves replacing/updating the appropriate MPLS 290 labels. 292 In addition, if the Flags in the Graceful Restart Capability received 293 from the restarting LSR indicate that the LSR wasn't able to retain 294 its MPLS state across the restart, the neighbor SHOULD immediately 295 remove all the NLRI and the associated MPLS labels that it previously 296 acquired via BGP from the restarting LSR. 298 An LSR, once it creates a binding between a label and a Forwarding 299 Equivalence Class (FEC), SHOULD keep the value of the label in this 300 binding for as long as the LSR has a route to the FEC in the binding. 301 If the route to the FEC disappears, and then re-appears again later, 302 then this may result in using a different label value, as when the 303 route re-appears, the LSR would create a new binding. 305 To minimize the potential mis-routing caused by the label change, 306 when creating a new binding the LSR SHOULD pick up the 307 least recently used label. Once an LSR releases a label, the LSR 308 SHALL NOT re-use this label for advertising a binding to 309 a neighbor that supports graceful restart for at least the Restart 310 Time, as advertised by the neighbor to the LSR. 312 7. Security Consideration 314 The security considerations pertaining to the original BGP protocol 315 remain relevant. 317 In addition, the mechanism described here renders LSRs that implement 318 it to additional denial-of-service attacks as follows: 320 An intruder may impersonate a BGP peer in order to force a failure 321 and reconnection of the TCP connection, but where the intruder 322 sets the Forwarding State (F) bit (as defined in [1]) to 0 on 323 reconnection. This forces all labels received from the peer to be 324 released. 326 An intruder could intercept the traffic between BGP peers and 327 override the setting of the Forwarding State (F) bit to be set to 328 0. This forces all labels received from the peer to be released. 330 All of these attacks may be countered by use of an authentication 331 scheme between BGP peers, such as the scheme outlined in [RFC2385]. 333 As with BGP carrying labels, a security issue may exist if a BGP 334 implementation continues to use labels after expiration of the BGP 335 session that first caused them to be used. This may arise if the 336 upstream LSR detects the session failure after the downstream LSR has 337 released and re-used the label. The problem is most obvious with the 338 platform-wide label space and could result in mis-routing of data to 339 other than intended destinations and it is conceivable that these 340 behaviors may be deliberately exploited to either obtain services 341 without authorization or to deny services to others. 343 In this document, the validity of the BGP session may be extended by 344 the Restart Time, and the session may be re-established in this 345 period. After the expiry of the Restart Time the session must be 346 considered to have failed and the same security issue applies as 347 described above. 349 However, the downstream LSR may declare the session as failed before 350 the expiration of its Restart Time. This increases the period during 351 which the downstream LSR might reallocate the label while the 352 upstream LSR continues to transmit data using the old usage of the 353 label. To reduce this issue, this document requires that labels are 354 not re-used until for at least the Restart Time. 356 8. Intellectual Property Considerations 358 This section is taken from Section 10.4 of [RFC2026]. 360 The IETF takes no position regarding the validity or scope of any 361 intellectual property or other rights that might be claimed to 362 pertain to the implementation or use of the technology described in 363 this document or the extent to which any license under such rights 364 might or might not be available; neither does it represent that it 365 has made any effort to identify any such rights. Information on the 366 IETF's procedures with respect to rights in standards-track and 367 standards-related documentation can be found in BCP-11. Copies of 368 claims of rights made available for publication and any assurances of 369 licenses to be made available, or the result of an attempt made to 370 obtain a general license or permission for the use of such 371 proprietary rights by implementors or users of this specification can 372 be obtained from the IETF Secretariat. 374 The IETF invites any interested party to bring to its attention any 375 copyrights, patents or patent applications, or other proprietary 376 rights which may cover technology that may be required to practice 377 this standard. Please address the information to the IETF Executive 378 Director. 380 The IETF has been notified of intellectual property rights claimed in 381 regard to some or all of the specification contained in this 382 document. For more information consult the online list of claimed 383 rights. 385 9. Copyright Notice 387 Copyright (C) The Internet Society (date). All Rights Reserved. 389 This document and translations of it may be copied and furnished to 390 others, and derivative works that comment on or otherwise explain it 391 or assist in its implmentation may be prepared, copied, published and 392 distributed, in whole or in part, without restriction of any kind, 393 provided that the above copyright notice and this paragraph are 394 included on all such copies and derivative works. However, this 395 document itself may not be modified in any way, such as by removing 396 the copyright notice or references to the Internet Society or other 397 Internet organizations, except as needed for the purpose of 398 developing Internet standards in which case the procedures for 399 copyrights defined in the Internet Standards process must be 400 followed, or as required to translate it into languages other than 401 English. 403 The limited permissions granted above are perpetual and will not be 404 revoked by the Internet Society or its successors or assigns. 406 This document and the information contained herein is provided on an 407 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 408 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 409 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 410 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 411 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 413 10. Acknowledgments 415 We would like to thank Chaitanya Kodeboyina and Loa Andersson for 416 their review and comments. The approach described in Section 417 "Alternative procedures for the restarting LSR" is based on the idea 418 suggested by Manoj Leelanivas. 420 11. Normative References 422 [1] "Graceful Restart Mechanism for BGP", draft-ietf-idr- 423 restart-01.txt 425 [2] Rekhter, Y., Rosen, E., "Carrying Label Information in BGP-4", 426 RFC3107 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119 431 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 432 Signature Option", RFC2385 434 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 435 3", RFC2026 436 12. Author Information 438 Yakov Rekhter 439 Juniper Networks 440 1194 N.Mathilda Ave 441 Sunnyvale, CA 94089 442 e-mail: yakov@juniper.net 444 Rahul Aggarwal 445 Juniper Networks 446 1194 N.Mathilda Ave 447 Sunnyvale, CA 94089 448 e-mail: rahul@juniper.net