idnits 2.17.1 draft-uttaro-idr-bgp-persistence-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6368, but the abstract doesn't seem to directly say this. It does mention RFC6368 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1137 has weird spacing: '...lineaux cedex...' -- The document date (July 19, 2018) is 2102 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-idr-bgp-gr-notification-15 == Outdated reference: A later version (-12) exists of draft-ietf-idr-bgp-bestpath-selection-criteria-09 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Uttaro 3 Internet-Draft AT&T 4 Updates: 6368 (if approved) E. Chen 5 Intended status: Standards Track Cisco Systems 6 Expires: January 20, 2019 B. Decraene 7 Orange 8 J. Scudder 9 Juniper Networks 10 July 19, 2018 12 Support for Long-lived BGP Graceful Restart 13 draft-uttaro-idr-bgp-persistence-04 15 Abstract 17 In this document we introduce a new BGP capability termed "Long-lived 18 Graceful Restart Capability" so that stale routes can be retained for 19 a longer time upon session failure. A well-known BGP community 20 "LLGR_STALE" is introduced for marking stale routes retained for a 21 longer time. A second well-known BGP community, "NO_LLGR", is 22 introduced to mark routes for which these procedures should not be 23 applied. We also specify that such long-lived stale routes be 24 treated as the least-preferred, and their advertisements be limited 25 to BGP speakers that have advertised the new capability. Use of this 26 extension is not advisable in all cases, and we provide guidelines to 27 help determine if it is. 29 We update RFC 6368 by specifying that the LLGR_STALE community must 30 be propagated into, or out of, the path attributes exchanged between 31 PE and CE. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 20, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Long-lived Graceful Restart Capability . . . . . . . . . 5 72 3.2. LLGR_STALE Community . . . . . . . . . . . . . . . . . . 6 73 3.3. NO_LLGR Community . . . . . . . . . . . . . . . . . . . . 7 74 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Use of Graceful Restart Capability . . . . . . . . . . . 7 76 4.2. Session Resets . . . . . . . . . . . . . . . . . . . . . 8 77 4.3. Processing LLGR_STALE Routes . . . . . . . . . . . . . . 10 78 4.4. Route Selection . . . . . . . . . . . . . . . . . . . . . 10 79 4.5. Multicast VPN . . . . . . . . . . . . . . . . . . . . . . 10 80 4.6. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 4.7. Optional Partial Deployment Procedure . . . . . . . . . . 13 82 4.8. Procedures when BGP is the PE-CE Protocol in a VPN . . . 13 83 4.8.1. Procedures when EBGP is the PE-CE Protocol in a VPN . 13 84 4.8.2. Procedures when IBGP is the PE-CE Protocol in a VPN . 14 85 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 86 5.1. When BGP is the PE-CE Protocol in a VPN . . . . . . . . . 17 87 5.2. Risks of Depreferencing Routes . . . . . . . . . . . . . 17 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 19 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 95 11.2. Informative References . . . . . . . . . . . . . . . . . 24 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 Historically, routing protocols in general and BGP in particular have 101 been designed with a focus on correctness, where a key part of 102 "correctness" is for each network element's forwarding state to 103 converge toward the current state of the network as quickly as 104 possible. For this reason, the protocol was designed to remove state 105 advertised by routers which went down (from a BGP perspective) as 106 quickly as possible. Over time, this has been relaxed somewhat, 107 notably by BGP Graceful Restart [RFC4724]; however, the paradigm has 108 remained one of attempting to rapidly remove "stale" state from the 109 network. 111 Over time, two phenomena have arisen that call into question the 112 underlying assumptions of this paradigm. The first is the widespread 113 adoption of tunneled forwarding infrastructures, for example MPLS. 114 Such infrastructures eliminate the risk of some types of forwarding 115 loops that can arise in hop-by-hop forwarding, and thus reduce one of 116 the motivations for strong consistency between forwarding elements. 117 The second is the increasing use of BGP as a transport for data less 118 closely associated with packet forwarding than was originally the 119 case. Examples include the use of BGP for autodiscovery (VPLS 120 [RFC4761]) and filter programming (FLOWSPEC [RFC5575]). In these 121 cases, BGP data takes on a character more akin to configuration than 122 to traditional routing. 124 The observations above motivate a desire to offer network operators 125 the ability to choose to retain BGP data for a longer period than has 126 hitherto been possible when the BGP control plane fails for some 127 reason. Although the semantics of BGP Graceful Restart [RFC4724] are 128 close to those desired, several gaps exist, most notably in maximum 129 time for which "stale" information can be retained -- Graceful 130 Restart imposes a 4095 second upper bound. 132 In this document we introduce a new BGP capability termed "Long-lived 133 Graceful Restart Capability" so that stale information can be 134 retained for a longer time across a session reset. We also introduce 135 two new BGP well-known communities, "LLGR_STALE", to mark such 136 information, and "NO_LLGR", to indicate that these procedures should 137 not be applied to the marked route. Long-lived stale information is 138 to be treated as least-preferred, and its advertisement limited to 139 BGP speakers that support the new capability. Where possible, we 140 reference the semantics of BGP Graceful Restart [RFC4724] rather than 141 specifying similar semantics in this document. 143 The expected deployment model for this extension is that it will only 144 be invoked for certain address families. This is discussed in more 145 detail in the Deployment Considerations section (Section 5). When 146 used, its use may be combined with that of traditional Graceful 147 Restart, in which case it is invoked only after the traditional 148 Graceful Restart interval has elapsed, or it may be invoked 149 immediately. Apart from the potential to greatly extend the timer, 150 the most obvious difference between Long-Lived and traditional 151 Graceful Restart is that in the Long-Lived version, routes are 152 "depreferenced", that is, treated as least-preferred, whereas in the 153 traditional version, route preference is not affected. The design 154 choice to treat Long-Lived Stale routes as least-preferred was 155 informed by the expectation that they might be retained for a 156 (potentially) almost unbounded period of time, whereas in the 157 traditional Graceful Restart case, stale routes are retained for only 158 a brief interval. In the GR case, the tradeoff between advertising 159 new route status (at the cost of routing churn) and not advertising 160 it (at the cost of suboptimal or incorrect route selection) is 161 resolved in favor of not advertising, and in the LLGR case, it is 162 resolved in favor of advertising new state. 164 1.1. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 2. Definitions 172 Depreference, Depreferenced: A route is said to be depreferenced if 173 it has its route selection preference reduced in reaction to some 174 event. 176 GR: Abbreviation for "Graceful Restart" [RFC4724], also sometimes 177 referred to herein as "conventional Graceful Restart" or 178 "conventional GR" to distinguish it from the "Long-lived Graceful 179 Restart" defined by this document. 181 Helper: Or "helper router". During Graceful Restart or Long-lived 182 Graceful Restart, the router that detects a session failure and 183 applies the listed procedures. [RFC4724] refers to this as the 184 "receiving speaker". 186 LLGR: Abbreviation for "Long-lived Graceful Restart". 188 LLST: Abbreviation for "Long-lived Stale Time". 190 Route: We use "route" to mean any information encoded as a BGP NLRI 191 and set of path attributes. As discussed above, the connection 192 between such routes and installation of forwarding state may be 193 quite remote. 195 3. Protocol Extensions 197 A new BGP capability and two new BGP communities are introduced. 199 3.1. Long-lived Graceful Restart Capability 201 The "Long-lived Graceful Restart Capability", or "LLGR Capability" 202 (value: 71) is a new BGP capability [RFC5492] that can be used by a 203 BGP speaker to indicate its ability to preserve its state according 204 to the procedures of this document. This capability MUST be 205 advertised in conjunction with the Graceful Restart capability 206 [RFC4724], see the "Use of Graceful Restart Capability" section 207 (Section 4.1). 209 The capability value consists of zero or more tuples as follows: 212 +--------------------------------------------------+ 213 | Address Family Identifier (16 bits) | 214 +--------------------------------------------------+ 215 | Subsequent Address Family Identifier (8 bits) | 216 +--------------------------------------------------+ 217 | Flags for Address Family (8 bits) | 218 +--------------------------------------------------+ 219 | Long-lived Stale Time (24 bits) | 220 +--------------------------------------------------+ 221 | ... | 222 +--------------------------------------------------+ 223 | Address Family Identifier (16 bits) | 224 +--------------------------------------------------+ 225 | Subsequent Address Family Identifier (8 bits) | 226 +--------------------------------------------------+ 227 | Flags for Address Family (8 bits) | 228 +--------------------------------------------------+ 229 | Long-lived Stale Time (24 bits) | 230 +--------------------------------------------------+ 232 The meaning of the fields are as follows: 234 Address Family Identifier (AFI), Subsequent Address Family 235 Identifier (SAFI): 237 The AFI and SAFI, taken in combination, indicate that the BGP 238 speaker has the ability to preserve its forwarding state for 239 the address family during a subsequent BGP restart. Routes may 240 be explicitly associated with a particular AFI and SAFI using 241 the encoding of [RFC4760] or implicitly associated with 242 if using the encoding of [RFC4271]. 244 Flags for Address Family: 246 This field contains bit flags relating to routes that were 247 advertised with the given AFI and SAFI. 249 0 1 2 3 4 5 6 7 250 +-+-+-+-+-+-+-+-+ 251 |F| Reserved | 252 +-+-+-+-+-+-+-+-+ 254 The most significant bit is used to indicate whether the state 255 for routes that were advertised with the given AFI and SAFI has 256 indeed been preserved during the previous BGP restart. When 257 set (value 1), the bit indicates that the state has been 258 preserved. This bit is called the "F bit" since it was 259 historically used to indicate preservation of Forwarding State. 260 Use of the F bit is detailed in the Session Resets section 261 (Section 4.2). 263 The remaining bits are reserved and MUST be set to zero by the 264 sender and ignored by the receiver. 266 Long-lived Stale Time: 268 This time (in seconds) specifies how long stale information 269 (for the AFI/SAFI) may be retained (possibly in conjunction 270 with the period specified by the "Restart Time" in the Graceful 271 Restart Capability, if present). 273 3.2. LLGR_STALE Community 275 We introduce a well-known BGP community [RFC1997] "LLGR_STALE" 276 (value: 0xFFFF0006). It can be used to mark stale routes retained 277 for a longer period of time. Such long-lived stale routes are to be 278 handled according to the procedures specified in the Operation 279 section (Section 4). 281 An implementation MAY allow users to configure policies that accept, 282 reject, or modify routes based on the presence or absence of this 283 community. 285 3.3. NO_LLGR Community 287 We introduce a well-known BGP community "NO_LLGR" (value: 288 0xFFFF0007). It can be used to mark routes which a BGP speaker does 289 not want treated according to these procedures, as detailed in the 290 Operation section (Section 4). 292 An implementation MAY allow users to configure policies that accept, 293 reject, or modify routes based on the presence or absence of this 294 community. 296 4. Operation 298 A BGP speaker MAY use BGP Capabilities Advertisement [RFC5492] to 299 advertise the "Long-lived Graceful Restart Capability" to indicate 300 its ability to retain state and perform related procedures specified 301 in this document. The setting of the parameters for an AFI/SAFI 302 depends on the properties of the BGP speaker, network scale, and 303 local configuration. 305 In the presence of the "Long-lived Graceful Restart Capability", the 306 procedures specified in [RFC4724] and 307 [I-D.ietf-idr-bgp-gr-notification] continue to apply unless 308 explicitly revised by this document. 310 4.1. Use of Graceful Restart Capability 312 The Graceful Restart capability MUST be advertised in conjunction 313 with the LLGR capability. If it is not so advertised, the LLGR 314 capability MUST be disregarded. The purpose for mandating that both 315 be used in conjunction is to enable reuse of certain base mechanisms 316 that are common to both "flavors", notably origination, collection 317 and processing of EoR, as well as the finite state machine 318 modifications and connection reset logic introduced by GR. 320 We observe that if support for conventional Graceful Restart is not 321 desired for the session, the conventional GR phase can be skipped by 322 omitting all AFI/SAFI from the GR capability, advertising a Restart 323 Time of zero, or both. The Session Resets section (Section 4.2) 324 discusses the interaction of conventional and long-lived GR. 326 4.2. Session Resets 328 BGP Graceful Restart [RFC4724], updated by 329 [I-D.ietf-idr-bgp-gr-notification], defines conditions under which a 330 BGP session can reset and have its associated routes retained. If 331 such a reset occurs for a session for which the LLGR Capability has 332 also been exchanged, the following procedures apply. 334 If the Graceful Restart Capability that was received does not list 335 all AFI/SAFI supported by the session, then for those non-listed AFI/ 336 SAFI the GR "Restart Time" shall be deemed zero. Similarly, if the 337 received LLGR Capability does not list all AFI/SAFI supported by the 338 session, then for those non-listed AFI/SAFI the "Long-lived Stale 339 Time" shall be deemed zero. 341 The following text in Section 4.2 of the GR specification [RFC4724] 342 no longer applies: 344 If the session does not get re-established within the "Restart 345 Time" that the peer advertised previously, the Receiving Speaker 346 MUST delete all the stale routes from the peer that it is 347 retaining. 349 and the following procedures are specified instead: 351 After the session goes down and before the session is re-established, 352 the stale routes for an AFI/SAFI MUST be retained. The interval for 353 which they are retained is limited by the sum of the "Restart Time" 354 in the received Graceful Restart Capability and the "Long-lived Stale 355 Time" in the received Long-lived Graceful Restart Capability. These 356 timers MAY be modified by local configuration. 358 If the value of the "Restart Time" or the "Long-lived Stale Time" is 359 zero, the duration of the corresponding period would be zero seconds. 360 So, for example, if the "Restart Time" is zero and the "Long-lived 361 Stale Time" is nonzero, only the procedures particular to LLGR would 362 apply. Conversely, if the "Long-lived Stale Time" is zero and the 363 "Restart Time" is nonzero, only the procedures of GR would apply. If 364 both are zero, none of these procedures would apply, only those of 365 the base BGP specification (although EoR would still be used as 366 detailed in [RFC4724]). And finally, if both are nonzero, then the 367 procedures would be applied serially -- first those of GR, then those 368 of LLGR. We observe that during the first interval, while the 369 procedures of GR are in effect, route preference would not be 370 affected, while during the second interval, while LLGR procedures are 371 in effect, routes would be treated as least-preferred as specified 372 elsewhere in this document. 374 Once the "Restart Time" period ends (including the case that the 375 "Restart Time" is zero), the LLGR period is said to have begun and 376 the following procedures MUST be performed: 378 o The helper router MUST start a timer for the "Long-lived Stale 379 Time". If the timer for the "Long-lived Stale Time" expires 380 before the session is re-established, the helper MUST delete all 381 the stale routes from the neighbor that it is retaining. 383 o The helper router MUST attach the LLGR_STALE community for the 384 stale routes being retained. Note that this requirement implies 385 that the routes would need to be readvertised, to disseminate the 386 modified community. 388 o If any of the routes from the peer have been marked with the 389 NO_LLGR community, either as sent by the peer, or as the result of 390 a configured policy, they MUST NOT be retained, but MUST be 391 removed as per the normal operation of [RFC4271]. 393 o The helper router MUST perform the procedures listed under 394 Section 4.3. 396 Once the session is re-established, the procedures specified in 397 [RFC4724] apply for the stale routes irrespective of whether the 398 stale routes are retained during the "Restart Time" period or the 399 "Long-lived Stale Time" period. However, in the case of consecutive 400 restarts (i.e, the session goes down before the EoR is received) the 401 previously marked stale routes MUST NOT be deleted before the timer 402 for the "Long-lived Stale Time" expires. 404 Similarly to [RFC4724], once the session is re-established, if the F 405 bit for a specific address family is not set in the newly received 406 LLGR Capability, or if a specific address family is not included in 407 the newly received LLGR Capability, or if the LLGR and accompanying 408 GR Capability are not received in the re-established session at all, 409 then the Helper MUST immediately remove all the stale routes from the 410 peer that it is retaining for that address family. 412 If a "Long-lived Stale Time" timer is running for a peer, it MUST NOT 413 be updated (other than by manual operator intervention) until the 414 peer has established and synchronized a new session. The session is 415 termed "synchronized" once the EoR has been received from the peer. 417 The value of the "Long-lived Stale Time" in the capability received 418 from a neighbor MAY be reduced by local configuration. 420 While the session is down, the expiration of the "Long-lived Stale 421 Time" timer is treated analogously to the expiration of the "Restart 422 Time" timer in Graceful Restart. However, the timer continues to run 423 once the session has re-established. The timer is not stopped, nor 424 updated, until EoR is received from the peer. If the timer expires 425 during synchronization with the peer, any stale routes that the peer 426 has not refreshed, are removed. If the session subsequently resets 427 prior to becoming synchronized, any remaining routes should be 428 removed immediately. 430 4.3. Processing LLGR_STALE Routes 432 A BGP speaker that has advertised the "Long-lived Graceful Restart 433 Capability" to a neighbor MUST perform the following upon receiving a 434 route from that neighbor with the "LLGR_STALE" community, or upon 435 attaching the "LLGR_STALE" community itself per Section 4.2: 437 o Treat the route as the least-preferred in route selection (see 438 below). See the Risks of Depreferencing Routes section 439 (Section 5.2) for a discussion of potential risks inherent in 440 doing this. 442 o The route SHOULD NOT be advertised to any neighbor from which the 443 Long-lived Graceful Restart Capability has not been received. The 444 exception is described in the Optional Partial Deployment 445 Procedure section (Section 4.7). Note that this requirement 446 implies that such routes should be withdrawn from any such 447 neighbor. 449 o The "LLGR_STALE" community MUST NOT be removed when the route is 450 further advertised. 452 4.4. Route Selection 454 In this document, when we refer to treating a route as least- 455 preferred, this means the route MUST be treated as less preferred 456 than any other route that is not so treated. When performing route 457 selection between two routes both of which are least-preferred, 458 normal tie-breaking applies. Note that this would only be expected 459 to happen if the only routes available for selection were least- 460 preferred -- in all other cases, such routes would have been 461 eliminated from consideration. 463 4.5. Multicast VPN 465 If LLGR is being used in a network that carries Multicast VPN (MVPN) 466 traffic ([RFC6513],[RFC6514]), special considerations apply. 468 [RFC6513] defines the notion of the "Upstream PE" and the "Upstream 469 Multicast Hop" (UMH) for a particular multicast flow. To determine 470 the Upstream PE and/or the UMH for a particular flow, a particular 471 set of comparable BGP routes (the "UMH-eligible" routes for that 472 flow, as defined in [RFC6513]) is considered, and the "best" one 473 (according to the BGP bestpath selection algorithm) is chosen. The 474 UMH-eligible routes are routes with AFI/SAFI 1/1, 1/2, 2/1, or 2/2. 475 When a router detects a change in the Upstream PE or UMH for a given 476 flow, the router may modify its data plane state for that flow. For 477 example, the router may begin to discard any packets of the flow that 478 it believes have arrived from the previously chosen Upstream PE or 479 UMH. The assumption is that the newly chosen Upstream PE and/or UMH 480 will make the corresponding changes, if necessary, to their own data 481 plane states. In addition, if a router detects a change in the 482 Uptream PE or UMH for a given flow, it may originate or readvertise 483 (with different attributes) certain of the BGP MCAST-VPN routes 484 (routes with SAFI 5) that are defined in [RFC6514]. The assumption 485 is that the MCAST-VPN routes will be properly distributed by BGP to 486 other routers that have data plane states for the given flow, i.e., 487 that BGP will converge so that all routers handle the flow in a 488 consistent manner. 490 However, if detection of a change to the Upstream PE or UMH is based 491 entirely on stale routes, one cannot assume that BGP will converge; 492 rather one must assume that the UMH-eligible routes and the MCAST-VPN 493 routes are not being properly distributed. Since the purpose of the 494 LLGR procedures is to try to keep the data flowing (by "freezing" the 495 data plane states) when the control plane updates are not being 496 properly distributed, it does not seem appropriate to react to 497 changes that are based entirely on stale routes. Therefore, the 498 following rules MUST be applied when a router is computing or 499 recomputing the Upstream PE and/or the UMH for a given multicast 500 flow: 502 o STALE routes (i.e., UMH-eligible routes with the LLGR_STALE 503 attribute) are less preferable than non-STALE routes. 505 o If all the UMH-eligible routes for a given flow are STALE, then 506 the Upstream PE and/or UMH for that flow is considered to be 507 "stale". 509 o If the Upstream PE or UMH for a given multicast flow has already 510 been determined, and the result of a new computation yields a new 511 Upstream PE or UMH, but the Upstream PE or UMH is "stale" (as 512 defined just above), then the Upstream PE and/or UMH for that flow 513 MUST be left unchanged. 515 o If the Upstream PE or UMH for a given multicast flow has not 516 already been determined, but is now determined to be STALE, the 517 multicast flow is considered to have no reachable Upstream PE and/ 518 or UMH. 520 [RFC6514] also defines a set of route types with SAFI 5 ("MCAST-VPN" 521 routes). LLGR can be applied to MCAST-VPN routes. However, the 522 following MCAST-VPN route types require special procedures, as 523 specified in this section: 525 o Leaf A-D routes 526 o C-multicast Shared Tree Join routes 527 o C-multicast Source Tree Join routes 529 Routes of these three types are always "targeted" to a particular 530 upstream router. Depending on the situation, the targeted router may 531 be the Upstream PE for a given flow or the UMH for a given flow. 532 Alternatively, the targeted router may be determined by choosing the 533 "best" route (according to the BGP bestpath algorithm) from among a 534 set of comparable Intra-AS I-PMSI A-D routes, or from among a set of 535 comparable Inter-AS I-PMSI A-D routes, or from among a set of 536 comparable S-PMSI A-D routes. (See [RFC6513], [RFC6514], [RFC6625], 537 and [RFC7452] for details.) Once the target is chosen, it is 538 identified in an IPv4-address-specific Route Target (RT) or an IPv6- 539 address-specific RT that is attached to the route before the route is 540 advertised. If the target for one of these routes changes, the value 541 of the attached RT will also change. This in turn may cause the 542 route to be advertised, readvertised, or withdrawn on specific BGP 543 sessions. 545 For cases where the targeted router is the Upstream PE or the UMH for 546 a particular flow, the rules given previously in this section apply. 547 For example, if a Leaf A-D route is targeted to a flow's UMH, and all 548 the relevant UMH-eligible routes are stale, the UMH is left 549 unchanged. Thus the Leaf A-D route is not readvertised with a new 550 RT. 552 In those cases where the targeted router for a given Leaf A-D route 553 is selected by comparing a set of S-PMSI A-D routes, or where the 554 targeted router for a given C-multicast Shared or Source Tree Join 555 route is selected by comparing a set of Inter-AS I-PMSI A-D routes, 556 the following rules MUST be applied: 558 o STALE routes (i.e., "I/S-PMSI A-D routes" with the LLGR_STALE 559 attribute) are less preferable than non-STALE routes. 561 o If all the routes being considered are STALE, then the targeted 562 router of the Leaf A-D route or C-multicast Shared or Source Tree 563 Join route MUST NOT be changed. 565 This prevents a Leaf A-D route or C-multicast route from being 566 targeted to a particular router if the relevant I/S-PMSI A-D routes 567 from that router are stale. Since those routes are stale, it is 568 likely that the Leaf A-D route or C-multicast route would not make it 569 to the targeted router, in which case it is better to maintain the 570 existing data plane states than to make changes that presuppose that 571 the MCAST-VPN routes will be properly distributed. 573 4.6. Errors 575 If the LLGR capability is received without an accompanying GR 576 capability, the LLGR capability MUST be ignored, that is, the 577 implementation MUST behave as though no LLGR capability had been 578 received. 580 4.7. Optional Partial Deployment Procedure 582 Ideally, all routers in an Autonomous System would support this 583 specification before it was enabled. However, to facilitate 584 incremental deployment, stale routes MAY be advertised to neighbors 585 that have not advertised the Long-lived Graceful Restart Capability 586 under the following conditions: 588 o The neighbors MUST be internal (IBGP or Confederation) neighbors. 590 o The NO_EXPORT community [RFC1997] MUST be attached to the stale 591 routes. 593 o The stale routes MUST have their LOCAL_PREF set to zero. See the 594 Risks of Depreferencing Routes section (Section 5.2) for a 595 discussion of potential risks inherent in doing this. 597 If this strategy for partial deployment is used, the network operator 598 should set LOCAL_PREF to zero for all LLGR routes throughout the 599 Autonomous System. This trades off a small reduction in flexibility 600 (ordering may not be preserved between competing LLGR routes) for 601 consistency between routers which do, and do not, support this 602 specification. Since consistency of route selection can be important 603 for preventing forwarding loops, the latter consideration dominates. 605 4.8. Procedures when BGP is the PE-CE Protocol in a VPN 607 4.8.1. Procedures when EBGP is the PE-CE Protocol in a VPN 609 In VPN deployments, for example [RFC4364], EBGP is often used as a 610 PE-CE protocol. It may be a practical necessity in such deployments 611 to accommodate interoperation with peer routers that cannot easily be 612 upgraded to support specifications such as this one. This leads to a 613 problem: in this specification, we take pains to ensure that "stale" 614 routing information will not leak beyond the perimeter of routers 615 that support these procedures, so that it can be depreferenced as 616 expected, and we provide a workaround (Section 4.7) for the case 617 where one or more IBGP routers are not upgraded. However, in the VPN 618 PE-CE case, the protocol in use is EBGP, and our workaround does not 619 work since it relies on the use of LOCAL_PREF, an IBGP-only path 620 attribute. 622 We observe that the principal motivation for restricting the 623 propagation of "stale" routing information is the desire to prevent 624 it from spreading without limit once it exits the "safe" perimeter. 625 We further observe that VPN deployments are typically topologically 626 constrained, making this concern moot. For this reason, an 627 implementation MAY advertise stale routes over a PE-CE session, when 628 explicitly configured to do so. That is, the second rule listed in 629 Section 4.3 MAY be disregarded in such cases. All other rules 630 continue to apply. Finally, if this exception is used, the 631 implementation SHOULD by default attach the NO_EXPORT community to 632 the routes in question, as an additional protection against stale 633 routes spreading without limit. Attachment of the NO_EXPORT 634 community MAY be disabled by explicit configuration, to accommodate 635 exceptional cases. 637 See further discussion of using explicitly configured policy to 638 mitigate this issue in Section 5.1. 640 4.8.2. Procedures when IBGP is the PE-CE Protocol in a VPN 642 If IBGP is used as the PE-CE protocol, following the procedures of 643 [RFC6368], then when a PE router imports a VPN route that contains 644 the ATTR_SET attribute into a destination VRF and subsequently 645 advertises that route to a CE router, 647 o If the CE router does support the procedures of this document (in 648 other words, if the CE router has advertised the LLGR Capability): 649 In addition to including in the advertised route the path 650 attributes derived from the ATTR_SET as per [RFC6368], the PE 651 router MUST also include the LLGR_STALE community if it is present 652 in the path attributes of the imported route, even if it is not 653 present in the ATTR_SET attribute. 655 o If the CE router does not support the procedures of this document, 656 then the optional procedures of Section 4.7 MAY be followed, 657 attaching the NO_EXPORT community and setting the value of 658 LOCAL_PREF to zero, overriding the value found in the ATTR_SET. 660 Similarly, when a PE router receives a route from a CE into its VRF 661 and subsequently exports that route to a VPN address family, 663 o If the PE router does support the procedures of this document (in 664 other words, if the PE router has advertised the LLGR Capability): 665 In addition to including in the VPN route the ATTR_SET derived 666 from the path attributes as per [RFC6368], the PE router MUST also 667 include the LLGR_STALE community in the VPN route if it is present 668 in the path attributes of the route as received from the CE. 670 o If the PE router does not support the procedures of this document, 671 there exists no ideal solution. The CE could advertise a route 672 with LLGR_STALE, with the understanding that the LLGR_STALE 673 marking will only be honored by the provider network if 674 appropriate policy configuration exists on the PE (see 675 Section 5.1). It is at least guaranteed that LLGR_STALE will be 676 propagated when the route is propagated beyond the provider 677 network. Or, the CE could refrain from advertising the LLGR_STALE 678 route to the incapable PE. 680 5. Deployment Considerations 682 The deployment considerations discussed in [RFC4724] apply to this 683 document. In addition, network operators are cautioned to carefully 684 consider the potential disadvantages of deploying these procedures 685 for a given AFI/SAFI. Most notably, if used for an AFI/SAFI that 686 conveys traditional reachability information, use of a long-lived 687 stale route could result in a loss of connectivity for the covered 688 prefix. This specification takes pains to mitigate this risk where 689 possible, by making such routes least-preferred and by restricting 690 the scope of such routes to routers that support these procedures 691 (or, optionally, a single Autonomous System, see "Optional Partial 692 Deployment Procedure", above). However, according to the normal 693 rules of IP forwarding a stale more-specific route, that has no non- 694 stale alternate paths available, will still be used instead of a non- 695 stale less-specific route. Networks in which the deployment of these 696 procedures would be especially concerning include those which do not 697 use "tunneled" forwarding (in other words, those using traditional 698 hop-by-hop forwarding). 700 Implementations MUST NOT enable these procedures by default. They 701 MUST require affirmative configuration per AFI/SAFI in order to 702 enable them. 704 The procedures of this document do not alter the route resolvability 705 requirement of [RFC4271] Section 9.1.2.1.. Because of this, it will 706 commonly be the case that "stale" IBGP routes will only continue to 707 be used if the router depicted in the next hop remains resolvable, 708 even if its BGP component is down. Details of IGP fault-tolerance 709 strategies are beyond the scope of this document. In addition to the 710 foregoing, it may be advisable to check the viability of the next hop 711 through other means, see for example 712 [I-D.ietf-idr-bgp-bestpath-selection-criteria]. This may be 713 especially useful in cases where the next hop is known directly at 714 the network layer, notably EBGP. 716 As discussed in this document, after a BGP session goes down and 717 before the session is re-established, stale routes may be retained 718 for up to two consecutive periods, controlled by the "Restart Time" 719 and the "Long-lived Stale Time", respectively. During the first 720 period routing churn would be prevented but with potential 721 blackholing of traffic. During the second period potential 722 blackholing of traffic may be reduced but routing churn would be 723 visible throughout the network. The setting of the relevant 724 parameters for a particular application should take into account the 725 tradeoffs, the network dynamics and potential failure scenarios. If 726 needed, the first period can be bypassed either by local 727 configuration or by setting the "Restart Time" in the Graceful 728 Restart Capability to zero and/or not listing the AFI/SAFI in that 729 Capability. 731 The setting of the F bit (and the "Forwarding State" bit of the 732 accompanying GR capability) depends in part on deployment 733 considerations. The F bit can be understood as an indication that 734 the Helper should flush associated routes (if the bit is left clear). 735 As discussed in the Introduction, an important use case for LLGR is 736 for routes that are more akin to configuration than to traditional 737 routing. For such routes, it may make sense to always set the F bit, 738 regardless of other considerations. Likewise, for control-plane-only 739 entities such as dedicated route reflectors, that do not participate 740 in the forwarding plane, it makes sense to always set the F bit. 741 Overall, the rule of thumb is that if loss of state on the restarting 742 router can reasonably be expected to cause a forwarding loop or black 743 hole, the F bit should be set scrupulously according to whether state 744 has been retained. Specifics of when the F bit is, and is not, set 745 are implementation-dependent and may also be controlled by 746 configuration. Also, for every AFI/SAFI represented in the LLGR 747 capability that is also represented in the GR capability, there will 748 be two corresponding F bits -- the LLGR F bit and the GR F bit. If 749 the LLGR F bit is set, the corresponding GR F bit should also be set, 750 since to do otherwise would cause the state to be cleared on the 751 Receiving Router per the normal rules of GR, violating the intent of 752 the set LLGR bit. 754 5.1. When BGP is the PE-CE Protocol in a VPN 756 As discussed in Section 4.8, it may be necessary for a PE (or CE, in 757 the symmetric case) to advertise stale routes to a CE (or PE) in some 758 VPN deployments, even if the CE (PE) does not support this 759 specification. In that case, the operator configuring their PE (CE) 760 to advertise such routes should notify the operator of the CE (PE) 761 receiving the routes, and the CE (PE) should be configured to 762 depreference the routes. Typical BGP implementations will be able to 763 do this by matching on the LLGR_STALE community, and setting the 764 LOCAL_PREF for matching routes to zero, similar to the procedure 765 described in Section 4.7. 767 5.2. Risks of Depreferencing Routes 769 Depreferencing EBGP routes is considered safe, no different from the 770 common practice of applying a routing policy to an EBGP session. 771 However, the same is not always true of IBGP. 773 Consistent route selection is a fundamental tenet of IBGP correctness 774 and safe operation in hop-by-hop routed networks. When routers 775 within an AS apply different criteria in selecting routes, they can 776 arrive at inconsistent route selections, potentially with the 777 consequence of forming forwarding loops unless some form of tunneled 778 forwarding is used to prevent "core" routers from making a 779 (potentially inconsistent) forwarding decision based on the IP 780 header. 782 This specification uses the state of a peering session as an input to 783 the selection criteria, depreferencing routes that are associated 784 with a session that has gone down but have not yet aged out. Since 785 different routers within an AS might have different notions as to 786 whether their respective sessions with a given peer are up or down, 787 they might apply different selection criteria to routes from that 788 peer. This could result in a forwarding loop forming between such 789 routers. 791 For an example of such a forwarding loop, consider the following 792 simple topology: 794 A ---- B ---- C ------------------------- D 795 ^ ^ 796 | | 797 R1 R2 799 In this example, A - D are routers with a full mesh of IBGP sessions 800 between them. The short links have unit cost, the long link has cost 801 5. Routers A and D are AS border routers, each advertising some 802 route, R, into the AS -- these are denoted R1 and R2 in the diagram. 803 In ordinary operation, it can be seen that routers B and C will 804 select R1 for forwarding, and will forward toward A. 806 Suppose that the session between A and B goes down for some reason, 807 and stays down long enough for LLGR processing to be invoked on B. 808 Then on B, route R1 will be depreferenced, leading to the selection 809 of R2 by B. However, C will continue to prefer R1. It can be seen 810 that in this case, a forwarding loop for packets destined to R would 811 form between B and C. (We note that other forwarding loop scenarios 812 can be constructed for traditional GR, but are generally considered 813 less severe since GR can remain in effect for a much more limited 814 interval.) 816 The potential benefits of this specification can outweigh the risks 817 discussed above, as long as care is exercised in deployment. The 818 cardinal rule to be followed is, if a given set of routes are being 819 used within an AS for hop-by-hop forwarding, it is not recommended to 820 enable LLGR procedures. If tunneled forwarding (such as MPLS) is 821 used within the AS, or if routes are being used for purposes other 822 than hop-by-hop forwarding, less caution is needed, though the 823 operator should still carefully consider the consequences of enabling 824 LLGR. 826 6. Security Considerations 828 The security implications of the LLGR mechanism defined within in 829 this document are akin to those incurred by the maintenance of stale 830 routing information within a network. This is particularly relevant 831 when considering the maintenance of routing information that is 832 utilised for service segregation - such as MPLS label entries. 834 For MPLS VPN services, the effectiveness of the traffic isolation 835 between VPNs relies on the correctness of the MPLS labels between 836 ingress and egress PEs. In particular, when an egress PE withdraws a 837 label L1 allocated to a VPN1 route, this label MUST NOT be assigned 838 to a VPN route of a different VPN until all ingress PEs stop using 839 the old VPN1 route using L1. 841 Such a corner case may happen today, if the propagation of VPN routes 842 by BGP messages between PEs takes more time than the label re- 843 allocation delay on a PE. Given that we can generally bound worst 844 case BGP propagation time to a few minutes (for example 2-5), the 845 security breach will not occur if PEs are designed to not reallocate 846 a previous used and withdrawn label before a few minutes. 848 The problem is made worse with BGP GR between PEs as VPN routes can 849 be stalled for a longer period of time (for example 20 minutes). 851 This is further aggravated by the BGP LLGR extension proposed in this 852 document as VPN routes can be stalled for a much longer period of 853 time (for example 2 hours, 1 day). 855 Therefore, to avoid VPN breach, before enabling BGP LLGR, SPs need to 856 check how fast a given label can be reused by a PE, taking into 857 account: 859 o The load of the BGP route churn on a PE (in term of number of VPN 860 label advertised and churn rate). 862 o The label allocation policy on the PE (possibly depending upon the 863 size of pool of the VPN labels (which can be restricted by 864 hardware consideration or others MPLS usages), the label 865 allocation scheme (for example per route or per VRF/CE), the re- 866 allocation policy (for example least recently used label...) 868 Note that [RFC4781] which defines Graceful Restart Mechanism for BGP 869 with MPLS is also applicable to BGP LLGR. 871 In addition to these considerations, the LLGR mechanism described 872 within this document is considered to be complex to exploit 873 maliciously - in order to inject packets into a topology, there is a 874 requirement to engineer a specific LLGR state between two PE devices, 875 whilst engineering label reallocation to occur in a manner that 876 results in the two topologies overlapping. Such allocation is 877 particularly difficult to engineer (since it is typically an internal 878 mechanism of an LSR). 880 7. Examples of Operation 882 For illustrative purposes, we present a few examples of how this 883 specification might be used in practice. These examples are neither 884 exhaustive nor normative. 886 Consider the following scenario: A border router, ASBR1, has an IBGP 887 peering with a route reflector, RR1, from which it learns routes. It 888 has an EBGP peering with an external peer, EXT, to which it 889 advertises those routes. The external peer has advertised the GR and 890 LLGR Capabilities to ASBR1. ASBR1 is configured to support GR and 891 LLGR on its session with RR1 and EXT. RR1 advertises a GR Restart 892 Time of 1 (second) and a LLST of 3600 (seconds): 894 +----------+--------------------------------------------------------+ 895 | Time | Event | 896 +----------+--------------------------------------------------------+ 897 | t | ASBR1's IBGP session with RR fails. ASBR1 retains RR's | 898 | | routes according to the rules of GR [RFC4724] | 899 | | | 900 | t+1 | GR Restart Time expires. ASBR1 transitions RR's routes | 901 | | to long-lived stale by attaching the LLGR_STALE | 902 | | community and depreferencing them. However, since it | 903 | | has no backup routes, it continues to make use of | 904 | | them. It re-announces them to EXT with the LLGR_STALE | 905 | | community attached. | 906 | | | 907 | t+1+3600 | LLST expires. ASBR1 removes RR's stale routes from its | 908 | | own RIB and sends BGP updates to withdraw them from | 909 | | EXT. | 910 +----------+--------------------------------------------------------+ 912 Next, imagine the same scenario but suppose RR1 advertised a GR 913 Restart Time of zero, effectively disabling GR. Equally, ASBR1 could 914 have used local configuration to override RR1's offered Restart Time, 915 setting it to a locally-configured value of zero: 917 +----------+--------------------------------------------------------+ 918 | Time | Event | 919 +----------+--------------------------------------------------------+ 920 | t | ASBR1's IBGP session with RR fails. ASBR1 transitions | 921 | | RR's routes to long-lived stale by attaching the | 922 | | LLGR_STALE community and depreferencing them. However, | 923 | | since it has no backup routes, it continues to make | 924 | | use of them. It re-announces them to EXT with the | 925 | | LLGR_STALE community attached. | 926 | | | 927 | t+0+3600 | LLST expires. ASBR1 removes RR's stale routes from its | 928 | | own RIB and sends BGP updates to withdraw them from | 929 | | EXT. | 930 +----------+--------------------------------------------------------+ 932 Next, imagine the original scenario, but consider that the ASBR1-RR1 933 session comes back up and becomes synchronized 180 seconds after the 934 failure was detected: 936 +---------+---------------------------------------------------------+ 937 | Time | Event | 938 +---------+---------------------------------------------------------+ 939 | t | ASBR1's IBGP session with RR fails. ASBR1 retains RR's | 940 | | routes according to the rules of GR [RFC4724] | 941 | | | 942 | t+1 | GR Restart Time expires. ASBR1 transitions RR's routes | 943 | | to long-lived stale by attaching the LLGR_STALE | 944 | | community and depreferencing them. However, since it | 945 | | has no backup routes, it continues to make use of them. | 946 | | It re-announces them to EXT with the LLGR_STALE | 947 | | community attached. | 948 | | | 949 | t+1+179 | Session is reestablished and resynchronized. ASBR1 | 950 | | removes the LLGR_STALE community from RR1's routes and | 951 | | re-announces them to EXT with the LLGR_STALE community | 952 | | removed. | 953 +---------+---------------------------------------------------------+ 955 Finally, imagine the original scenario, but consider that EXT has not 956 advertised the LLGR Capability to ASBR1: 958 +----------+--------------------------------------------------------+ 959 | Time | Event | 960 +----------+--------------------------------------------------------+ 961 | t | ASBR1's IBGP session with RR fails. ASBR1 retains RR's | 962 | | routes according to the rules of GR [RFC4724] | 963 | | | 964 | t+1 | GR Restart Time expires. ASBR1 transitions RR's routes | 965 | | to long-lived stale by attaching the LLGR_STALE | 966 | | community and depreferencing them. However, since it | 967 | | has no backup routes, it continues to make use of | 968 | | them. It withdraws them from EXT. | 969 | | | 970 | t+1+3600 | LLST expires. ASBR1 removes RR's stale routes from its | 971 | | own RIB. | 972 +----------+--------------------------------------------------------+ 974 8. Acknowledgements 976 We would like to thank Nabil Bitar, Martin Djernaes, Roberto 977 Fragassi, Jeffrey Haas, Nicolai Leymann, Paul Mattes, John Medamana, 978 Pranav Mehta, Han Nguyen, Saikat Ray and Eric Rosen for their 979 valuable input and contributions to the discussion and solution. 981 9. Contributors 983 Clarence Filsfils 984 Cisco Systems 985 Brussels 1000 986 Belgium 988 Email: cf@cisco.com 990 Pradosh Mohapatra 991 Cumulus Networks 993 Email: pmohapat@cumulusnetworks.com 995 Yakov Rekhter 996 Juniper Networks 998 Email: yakov@juniper.net 1000 Eric Rosen 1001 Cisco Systems 1003 Email: erosen@cisco.com 1005 Rob Shakir 1006 BT 1008 Email: rob.shakir@bt.com 1010 Adam Simpson 1011 Alcatel-Lucent 1012 600 March Road 1013 Ottawa, Ontario K2K 2E6 1014 Canada 1016 Email: adam.simpson@alcatel-lucent.com 1018 10. IANA Considerations 1020 This document defines a new BGP capability - Long-lived Graceful 1021 Restart Capability. IANA has assigned a Capability Code of 71. 1023 This document introduces a new BGP community "LLGR_STALE" for marking 1024 the long-lived stale routes, and another community "NO_LLGR" to 1025 indicate that stale routes should not be retained. IANA has assigned 1026 these well-known community values 0xFFFF0006 and 0xFFFF0007, 1027 respectively. 1029 11. References 1031 11.1. Normative References 1033 [I-D.ietf-idr-bgp-gr-notification] 1034 Patel, K., Fernando, R., Scudder, J., and J. Haas, 1035 "Notification Message support for BGP Graceful Restart", 1036 draft-ietf-idr-bgp-gr-notification-15 (work in progress), 1037 April 2018. 1039 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 1040 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 1041 . 1043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1044 Requirement Levels", BCP 14, RFC 2119, 1045 DOI 10.17487/RFC2119, March 1997, 1046 . 1048 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1049 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1050 DOI 10.17487/RFC4271, January 2006, 1051 . 1053 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1054 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1055 DOI 10.17487/RFC4724, January 2007, 1056 . 1058 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1059 "Multiprotocol Extensions for BGP-4", RFC 4760, 1060 DOI 10.17487/RFC4760, January 2007, 1061 . 1063 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 1064 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 1065 2009, . 1067 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1068 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1069 2012, . 1071 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1072 Encodings and Procedures for Multicast in MPLS/BGP IP 1073 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1074 . 1076 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 1077 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 1078 RFC 6625, DOI 10.17487/RFC6625, May 2012, 1079 . 1081 11.2. Informative References 1083 [I-D.ietf-idr-bgp-bestpath-selection-criteria] 1084 Asati, R., "BGP Bestpath Selection Criteria Enhancement", 1085 draft-ietf-idr-bgp-bestpath-selection-criteria-09 (work in 1086 progress), June 2018. 1088 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1089 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1090 2006, . 1092 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1093 LAN Service (VPLS) Using BGP for Auto-Discovery and 1094 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1095 . 1097 [RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism 1098 for BGP with MPLS", RFC 4781, DOI 10.17487/RFC4781, 1099 January 2007, . 1101 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1102 and D. McPherson, "Dissemination of Flow Specification 1103 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1104 . 1106 [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. 1107 Yamagata, "Internal BGP as the Provider/Customer Edge 1108 Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", 1109 RFC 6368, DOI 10.17487/RFC6368, September 2011, 1110 . 1112 [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 1113 "Architectural Considerations in Smart Object Networking", 1114 RFC 7452, DOI 10.17487/RFC7452, March 2015, 1115 . 1117 Authors' Addresses 1118 James Uttaro 1119 AT&T 1120 200 S. Laurel Avenue 1121 Middletown, NJ 07748 1122 USA 1124 Email: ju1738@att.com 1126 Enke Chen 1127 Cisco Systems 1128 170 W. Tasman Drive 1129 San Jose, CA 95134 1130 USA 1132 Email: enkechen@cisco.com 1134 Bruno Decraene 1135 Orange 1136 38-40 Rue de General Leclerc 1137 92794 Issy Moulineaux cedex 9 1138 France 1140 Email: bruno.decraene@orange.com 1142 John G. Scudder 1143 Juniper Networks 1144 1194 N. Mathilda Ave 1145 Sunnyvale, CA 94089 1146 USA 1148 Email: jgs@juniper.net