idnits 2.17.1 draft-ietf-idr-flowspec-interfaceset-01.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([RFC5575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 8, 2016) is 2879 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) == Unused Reference: 'I-D.ietf-idr-rtc-no-rt' is defined on line 567, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-idr-rtc-no-rt-05 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-05) exists of draft-uttaro-idr-bgp-persistence-03 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group S. Litkowski 3 Internet-Draft Orange 4 Intended status: Standards Track A. Simpson 5 Expires: December 10, 2016 Alcatel Lucent 6 K. Patel 7 Cisco 8 J. Haas 9 Juniper Networks 10 June 8, 2016 12 Applying BGP flowspec rules on a specific interface set 13 draft-ietf-idr-flowspec-interfaceset-01 15 Abstract 17 BGP Flow-spec is an extension to BGP that allows for the 18 dissemination of traffic flow specification rules. The primary 19 application of this extension is DDoS mitigation where the flowspec 20 rules are applied in most cases to all peering routers of the 21 network. 23 This document will present another use case of BGP Flow-spec where 24 flow specifications are used to maintain some access control lists at 25 network boundary. BGP Flowspec is a very efficient distributing 26 machinery that can help in saving OPEX while deploying/updating ACLs. 27 This new application requires flow specification rules to be applied 28 only on a specific subset of interfaces and in a specific direction. 30 The current specification of BGP Flow-spec ([RFC5575]) introduces the 31 notion of flow specification (which describes the matching criterion) 32 and traffic filtering actions. The flow specification is encoded as 33 part of the NLRI while the traffic filtering actions are encoded as 34 extended communities. The combination of a flow specification and 35 one or more actions is known as a flow specification rule. [RFC5575] 36 does not detail where the flow specification rules need to be 37 applied. 39 Besides the flow specification and traffic filtering actions, this 40 document introduces the notion of traffic filtering scope in order to 41 drive where a particular rule must be applied. In particular, this 42 document introduces the "interface-set" traffic filtering scope that 43 could be used in parallel of traffic filtering actions (marking, 44 rate-limiting ...). The purpose of this extension is to inform 45 remote routers about groups of interfaces where the rule must be 46 applied. 48 This extension can also be used in a DDoS mitigation context where a 49 provider wants to apply the filtering only on specific peers. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Status of This Memo 59 This Internet-Draft is submitted in full conformance with the 60 provisions of BCP 78 and BCP 79. 62 Internet-Drafts are working documents of the Internet Engineering 63 Task Force (IETF). Note that other groups may also distribute 64 working documents as Internet-Drafts. The list of current Internet- 65 Drafts is at http://datatracker.ietf.org/drafts/current/. 67 Internet-Drafts are draft documents valid for a maximum of six months 68 and may be updated, replaced, or obsoleted by other documents at any 69 time. It is inappropriate to use Internet-Drafts as reference 70 material or to cite them other than as "work in progress." 72 This Internet-Draft will expire on December 10, 2016. 74 Copyright Notice 76 Copyright (c) 2016 IETF Trust and the persons identified as the 77 document authors. All rights reserved. 79 This document is subject to BCP 78 and the IETF Trust's Legal 80 Provisions Relating to IETF Documents 81 (http://trustee.ietf.org/license-info) in effect on the date of 82 publication of this document. Please review these documents 83 carefully, as they describe your rights and restrictions with respect 84 to this document. Code Components extracted from this document must 85 include Simplified BSD License text as described in Section 4.e of 86 the Trust Legal Provisions and are provided without warranty as 87 described in the Simplified BSD License. 89 Table of Contents 91 1. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 92 1.1. Specific filtering for DDoS . . . . . . . . . . . . . . . 3 93 1.2. ACL maintenance . . . . . . . . . . . . . . . . . . . . . 4 94 2. Collaborative filtering and managing filter direction . . . . 5 95 3. Traffic filtering scope . . . . . . . . . . . . . . . . . . . 6 96 4. Interface specific filtering using BGP flowspec . . . . . . . 6 97 5. Interface-set extended community . . . . . . . . . . . . . . 8 98 6. Interaction with permanent traffic filtering rules . . . . . 9 99 6.1. Interaction with interface ACLs . . . . . . . . . . . . . 9 100 6.2. Interaction with flow collection . . . . . . . . . . . . 11 101 7. Scaling of per interface rules . . . . . . . . . . . . . . . 11 102 8. Deployment considerations . . . . . . . . . . . . . . . . . . 11 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 104 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 105 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 108 12.2. Informative References . . . . . . . . . . . . . . . . . 13 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 111 1. Use case 113 1.1. Specific filtering for DDoS 115 ----------------- --- (ebgp) - Peer3 (BW 10G) 116 / \/ 117 | /| 118 | PE --- (ebgp) - Transit1(BW 4x10G) 119 Cust1 --- (ebgp) --- PE | 120 | PE ---- (ebgp) - Peer2 (BW 4*10G) 121 | \| 122 Cust2 --- (ebgp) --- PE |----- (ebgp) - Customer3 123 /| | 124 Peer1(BW10G)-(ebgp) | PE --- (ebgp) - Transit2(BW 4x10G) 125 | | 126 \ / 127 ------------------ 129 Figure 1 131 The figure 1 above displays a typical service provider Internet 132 network owing Customers, Peers and Transit. To protect pro actively 133 against some attacks (e.g. DNS, NTP ...), the service provider may 134 want to deploy some rate-limiting of some flows on peers and transit 135 links. But depending on link bandwidth, the provider may want to 136 apply different rate-limiting values. 138 For 4*10G links peer/transit, it may want to apply a rate-limiting of 139 DNS flows of 1G, while on 10G links, the rate-limiting would be set 140 to 250Mbps. Customer interfaces must not be rate-limited. 142 BGP Flow-spec infrastructure may already be present on the network, 143 and all PEs may have a BGP session running flowspec address family. 144 The Flowspec infrastructure may be reused by the service provider to 145 implement such rate-limiting in a very quick manner and being able to 146 adjust values in future quickly without having to configure each node 147 one by one. Using the current BGP flowspec specification, it would 148 not be possible to implement different rate limiter on different 149 interfaces of a same router. The flowspec rule is applied to all 150 interfaces in all directions or on some interfaces where flowspec is 151 activated but flowspec rule set would be the same among all 152 interfaces. 154 Section Section 4 will detail a solution to address this use case 155 using BGP Flowspec. 157 1.2. ACL maintenance 159 --------------- --- (ebgp) - Cust4_VPN 160 / \/ 161 Cust1_INT -- (ebgp) --- PE /| 162 | PE ------ (ebgp) - Transit1 163 Cust3_VPN -- (ebgp) --- PE | 164 | PE ------ (ebgp) - Peer2 165 | \| 166 Cust2_INT -- (ebgp) --- PE |----- (ebgp) - Cust4_INT 167 /| | 168 Peer1 ------ (ebgp) -- | PE ------ (ebgp) - Transit2 169 | | 170 \ / 171 ---------------- 173 Figure 2 175 The figure 1 above displays a typical service provider multiservice 176 network owing Customers, Peers and Transit for Internet, as well as 177 VPN services. The service provider requires to ensure security of 178 its infrastructure by applying ACLs at network boundary. Maintaining 179 and deploying ACLs on hundreds/thousands of routers is really painful 180 and time consuming and a service provider would be interested to 181 deploy/updates ACLs using BGP Flowspec. In this scenario, depending 182 on the interface type (Internet customer, VPN customer, Peer, Transit 183 ...) the content of the ACL may be different. 185 We foresee two main cases : 187 o Maintaining complete ACLs using flowspec : in this case all the 188 ingress ACL are maintained and deployed using BGPFlowspec. See 189 section Section 9 for more details on security aspects. 191 o Requirement of a quick deployment of a new filtering term due to a 192 security alert : new security alerts often requires a fast 193 deployment of new ACL terms. Using traditional CLI and hop by hop 194 provisioning, such deployment takes time and network is 195 unprotected during this time window. Using BGP flowspec to deploy 196 such rule, a service provider can protect its network in few 197 seconds. Then the SP can decide to keep the rule permanently in 198 BGP Flowspec or update its ACL or remove the entry (in case 199 equipments are not vulnerable anymore). 201 Section Section 4 will detail a solution to address this use case 202 using BGP Flowspec. 204 2. Collaborative filtering and managing filter direction 206 [RFC5575] states in Section 5. : "This mechanism is primarily 207 designed to allow an upstream autonomous system to perform inbound 208 filtering in their ingress routers of traffic that a given downstream 209 AS wishes to drop.". 211 In case of networks collaborating in filtering, there is a use case 212 for performing outbound filtering. Outbound filtering allows to 213 apply traffic action one step before and so may allow to prevent 214 impact like congestions. 216 ---------------------- 217 / \ 218 | Upstream provider | 219 \ / 220 ----------------------- 221 | | 222 |P2 |P1 223 ---------------------- 224 / \ 225 | MyAS | 226 \ / 227 ----------------------- 229 Figure 3 231 In the figure above, MyAS is connected to an upstream provider. If a 232 malicious traffic comes in from the upstream provider, it may 233 congestion P1 or P2 links. If MyAS apply inbound filtering on P1/P2 234 using BGP Flowspec, the congestion issue will not be solved. 236 Using collaborative filtering, the upstream provider may propose to 237 MyAS to filter malicious traffic sent to it. We propose to enhance 238 [RFC5575] to make myAS able to send BGP FlowSpec updates (on eBGP 239 sessions) to the upstream provider to request outbound filtering on 240 peering interfaces towards MyAS. When the upstream provider will 241 receive the BGP Flowspec update from MyAS, the BGP flowspec update 242 will contain request for outbound filtering on a specific set of 243 interfaces. The upstream provider will apply automatically the 244 requested filter and congestion will be prevented. 246 3. Traffic filtering scope 248 We see with the use case described above that some BGP flowspec rules 249 may need to be applied only on specific elements of the network 250 (interfaces, nodes ...). The basic specification detailed in 251 [RFC5575] does not address this and does not give any detail on where 252 the traffic filtering rule need to be applied. 254 In addition to the flow specification (flow matching criterion) and 255 traffic filtering actions described in [RFC5575], this document 256 introduces the notion of traffic filtering scope. The traffic 257 filtering scope will describe where a particular flow specification 258 rule must be applied. 260 Using a traffic filtering scope in a BGP Flow spec rule is optional. 261 When a rule does not contain any traffic filtering scope parameter, 262 [RFC5575] applies. 264 4. Interface specific filtering using BGP flowspec 266 The use case detailed above requires application of different BGP 267 Flowspec rules on different set of interfaces. 269 We propose to introduce, within BGP Flowspec, a traffic filtering 270 scope that identifies a group of interfaces where a particular filter 271 should apply on. Identification of interfaces within BGP Flowspec 272 will be done through group identifiers. A group identifier marks a 273 set of interfaces sharing a common administrative property. Like a 274 BGP community, the group identifier itself does not have any 275 significance. It is up to the network administrator to associate a 276 particular meaning to a group identifier value (e.g. group ID#1 277 associated to Internet customer interfaces). The group identifier is 278 a local interface property. Any interface may be associated with one 279 or more group identifiers using manual configuration. 281 When a filtering rule advertised through BGP Flowspec must be applied 282 only to particular sets of interfaces, the BGP Flowspec BGP update 283 will contain the identifiers associated with the relevant sets of 284 interfaces. In addition to the group identifiers, it will also 285 contain the direction the filtering rule must be applied in (see 286 Section 5). 288 Configuration of group identifiers associated to interfaces may 289 change over time. An implementation MUST ensure that the filtering 290 rules (learned from BGP Flowspec) applied to a particular interface 291 are always updated when the group identifier mapping is changing. 293 Considering figure 2, we can imagine the following design : 295 o Internet customer interfaces are associated with group-identifier 296 1. 298 o VPN customer interfaces are associated with group-identifier 2. 300 o All customer interfaces are associated with group-identifier 3. 302 o Peer interfaces are associated with group-identifier 4. 304 o Transit interfaces are associated with group-identifier 5. 306 o All external provider interfaces are associated with group- 307 identifier 6. 309 o All interfaces are associated with group-identifier 7. 311 If the service provider wants to deploy a specific inbound filtering 312 on external provider interfaces only, the provider can send the BGP 313 flow specification using group-identifier 6 and including inbound 314 direction. 316 There are some cases where nodes are dedicated to specific functions 317 (Internet peering, Internet Edge, VPN Edge, Service Edge ...), in 318 this kind of scenario, there is an interest for a constrained 319 distribution of filtering rules that are using the interface specific 320 filtering. Without the constrained route distribution, all nodes 321 will received all the filters even if they are not interested in 322 those filters. Constrained route distribution of flowspec filters 323 would allow for a more optimized distribution. 325 5. Interface-set extended community 327 This document proposes a new BGP Route Target extended community 328 called "flowspec interface-set". This document so expands the 329 definition of the Route Target extended community to allow a new 330 value of high order octet (Type field) to be TBD (in addition to the 331 values specified in [RFC4360]). 333 In order to ease intra-AS and inter-AS use cases, this document 334 proposes to have a transitive as well as a non transitive version of 335 this extended community. 337 This new BGP Route Target extended community is encoded as follows : 339 0 1 2 3 340 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type (TBD) | 0x02 | Autonomous System Number : 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 : AS Number (cont.) |O|I| Group Identifier | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 The flags are : 349 o O : if set, the flow specification rule MUST be applied in 350 outbound direction to the interface set referenced by the 351 following group-identifier. 353 o I : if set, the flow specification rule MUST be applied in input 354 direction to the interface set referenced by the following group- 355 identifier. 357 Both flags can be set at the same time in the interface-set extended 358 community leading to flow rule to be applied in both directions. An 359 interface-set extended community with both flags set to zero MUST be 360 treated as an error and as consequence, the FlowSpec update MUST be 361 discarded. As having no direction indicated as no sense, there is no 362 need to propagate the filter informations in the network. 364 The Group Identifier is coded as a 14-bit number (values goes from 0 365 to 16383). 367 Multiple instances of the interface-set community may be present in a 368 BGP update. This may appear if the flow rule need to be applied to 369 multiple set of interfaces. 371 Multiple instances of the community in a BGP update MUST be 372 interpreted as a "OR" operation : if a BGP update contains two 373 interface-set communities with group ID 1 and group ID 2, the filter 374 would need to be installed on interfaces belonging to Group ID 1 or 375 Group ID 2. 377 As using a Route Target, route distribution of flowspec NLRI with 378 interface-set may be subject to constrained distribution as defined 379 in [RFC4684]. Constrained route distribution for flowspec routes 380 using interface-set requires discussion and will be addressed in a 381 future revision of the document. 383 6. Interaction with permanent traffic filtering rules 385 [RFC5575] states that BGP Flowspec is primarily designed to allow 386 upstream AS to perform inbound filtering in their ingress routers. 387 This specification does not precise where this ingress filtering 388 should happen in the packet processing pipe. 390 This proposal enhances [RFC5575] in order to add rules for traffic 391 coming from or going to specific interfaces. Based on this 392 enhancement, some new requirements come to implementations. 394 An implementation SHOULD apply input actions (I bit set) within the 395 input packet processing pipe. An implementation SHOULD apply output 396 actions (O bit set) within the output packet processing pipe. 398 As input and output processing pipes may also involve already present 399 static/permanent features that will manipulate the packet, the next 400 sections will try to clarify how the static behaviors should interact 401 will BGP flowspec actions. 403 6.1. Interaction with interface ACLs 405 Deploying interface specific filters using BGP FlowSpec (dynamic 406 entries) may interfere with existing permanent interface ACL (static 407 entries). The content of the existing permanent ACL MUST NOT be 408 altered by dynamic entries coming from BGP FlowSpec. Permanent ACLs 409 are using a specific ordering which is not compatible with the 410 ordering of FS rules and misordering of ACL may lead to undesirable 411 behaviour. In order, to keep a deterministic and well known 412 behaviour, an implementation SHOULD process the BGP FlowSpec ACL as 413 follows : 415 o In inbound direction, the permanent ACL action is applied first 416 followed by FlowSpec action. This gives the primary action to the 417 permanent ACL as it is done today. 419 o In outbound direction, FlowSpec action is applied first followed 420 by permanent ACL. This gives the final action to the permanent 421 ACL as it is done today. 423 Inbound filters Outbound filters 424 --------- ------- ---------- ------- --------- 425 |Permanent| -> |Dynamic| -> |Forwarding| -> |Dynamic| -> |Permanent| 427 In order for a flow to be accepted, the flow must be accepted by the 428 two ACLs and a flow is rejected when one of the ACL rejects it as 429 described in the table below : 431 +-------------------------+--------------------------+--------------+ 432 | Permanent ACL entry | FlowSpec ACL entry | Result | 433 | action | action | action | 434 +-------------------------+--------------------------+--------------+ 435 | Drop | Drop | Drop | 436 | Drop | Accept | Drop | 437 | Accept | Drop | Drop | 438 | Accept | Accept | Accept | 439 +-------------------------+--------------------------+--------------+ 441 Example : 443 o ACL permanent IN : 445 * Entry 1 : permit udp from 10/8 to 11/8 port 53 447 * Entry 2 : permit tcp from 10/8 to 11/8 port 22 449 * Entry 3 : deny ip from 10/8 to 11/8 451 o ACL dynamic FlowSpec IN : 453 * Entry 1 : deny udp from 10.0.0.1/32 to 11/8 port 53 455 * Entry 2 : permit tcp from 10/8 to 11/8 port 80 457 In the example above : 459 o a UDP flow from 10.0.0.1 to 11.0.0.2 on port 53 will be rejected 460 because the dynamic ACL rejects it. 462 o a UDP flow from 10.0.0.2 to 11.0.0.2 on port 53 will be accepted 463 because both ACLs accept it. 465 o a TCP flow from 10.0.0.2 to 11.0.0.2 on port 80 will be rejected 466 because permanent ACL rejects it. 468 6.2. Interaction with flow collection 470 A router may activate flow collection features (used in collaboration 471 with Netflow export). Flow collection can be done at input side or 472 output side. As for ACL, an implementation SHOULD process : 474 o BGP FS rules after the inbound flow collection : in case of DDoS 475 protection, it is important to keep monitoring of attack flows and 476 so performing action, after collection. 478 o BGP FS rules before the outbound flow collection : purpose of 479 outbound flow collection is really to track flows that are exiting 480 the interface. BGP FS rules should not interfere in this. 482 Inbound Outbound 483 Flow BGP BGP Flow 484 collection FS FS collection 485 --------- ------- ---------- ------- --------- 486 |Permanent| -> |Dynamic| -> |Forwarding| -> |Dynamic| -> |Permanent| 488 7. Scaling of per interface rules 490 Creating rules that are applied on specific interfaces may create 491 forwarding rules that may be harder to share. 493 An implementation SHOULD take care about trying to keep sharing 494 forwarding structures as much as possible in order to limit the 495 scaling impact. How the implementation would do so is out of scope 496 of the document. 498 8. Deployment considerations 500 There are some cases where a particular BGP Flowspec NLRI may be 501 advertised to different interface groups with a different action. 502 For example, a service provider may want to discard all ICMP traffic 503 from customer interfaces to infrastructure addresses and want to 504 rate-limit the same traffic when it comes from some internal 505 platforms. These particular cases require ADD-PATH to be deployed in 506 order to ensure that all paths (NLRI+interface-set group-id+actions) 507 are propagated within the BGP control plane. Without ADD-PATH, only 508 a single "NLRI+interface-set group-id+actions" will be propagated, so 509 some filtering rules will never be applied. 511 9. Security Considerations 513 Managing permanent Access Control List by using BGP Flowspec as 514 described in Section 1.2 helps in saving roll out time of such ACL. 515 However some ACL especially at network boundary are critical for the 516 network security and loosing the ACL configuration may lead to 517 network open for attackers. 519 By design, BGP flowspec rules are ephemeral : the flow rule exists in 520 the router while the BGP session is UP and the BGP path for the rule 521 is valid. We can imagine a scenario where a Service Provider is 522 managing the network boundary ACLs by using only FlowSpec. In this 523 scenario, if , for example, an attacker succeed to make the internal 524 BGP session of a router to be down , it can open all boundary ACLs on 525 the node, as flowspec rules will disappear due to the BGP session 526 down. 528 In reality, the chance for such attack to occur is low, as boundary 529 ACLs should protect the BGP session from being attacked. 531 In order to complement the BGP flowspec solution is such deployment 532 scenario and provides security against such attack, a service 533 provider may activate Long lived Graceful Restart 534 [I-D.uttaro-idr-bgp-persistence] on the BGP session owning Flowspec 535 address family. So in case of BGP session to be down, the BGP paths 536 of Flowspec rules would be retained and the flowspec action will be 537 retained. 539 10. Acknowledgements 541 Authors would like to thanks Wim Hendrickx and Robert Raszuk for 542 their valuable comments. 544 11. IANA Considerations 546 This document requests a new type from the "BGP Transitive Extended 547 Community Types" extended community registry. This type name shall 548 be 'FlowSpec'. 550 This document requests a new type from the "BGP Non-Transitive 551 Extended Community Types" extended community registry. This type 552 name shall be 'FlowSpec'. 554 This document requests creation of a new registry called "FlowSpec 555 Extended Community Sub-Types". This registry contains values of the 556 second octet (the "Sub-Type" field) of an extended community when the 557 value of the first octet (the "Type" field) is to one of those 558 allocated in this document. 560 Within this new registry, this document requests a new subtype 561 (suggested value 0x02), this sub-type shall be named "interface-set". 563 12. References 565 12.1. Normative References 567 [I-D.ietf-idr-rtc-no-rt] 568 Rosen, E., Patel, K., Haas, J., and R. Raszuk, "Route 569 Target Constrained Distribution of Routes with no Route 570 Targets", draft-ietf-idr-rtc-no-rt-05 (work in progress), 571 May 2016. 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, 575 DOI 10.17487/RFC2119, March 1997, 576 . 578 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 579 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 580 February 2006, . 582 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 583 R., Patel, K., and J. Guichard, "Constrained Route 584 Distribution for Border Gateway Protocol/MultiProtocol 585 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 586 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 587 November 2006, . 589 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 590 and D. McPherson, "Dissemination of Flow Specification 591 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 592 . 594 12.2. Informative References 596 [I-D.uttaro-idr-bgp-persistence] 597 Uttaro, J., Chen, E., Decraene, B., and J. Scudder, 598 "Support for Long-lived BGP Graceful Restart", draft- 599 uttaro-idr-bgp-persistence-03 (work in progress), November 600 2013. 602 Authors' Addresses 604 Stephane Litkowski 605 Orange 607 Email: stephane.litkowski@orange.com 608 Adam Simpson 609 Alcatel Lucent 611 Email: adam.simpson@alcatel-lucent.com 613 Keyur Patel 614 Cisco 616 Email: keyupate@cisco.com 618 Jeff Haas 619 Juniper Networks 621 Email: jhaas@juniper.net