idnits 2.17.1 draft-ietf-idr-flowspec-interfaceset-03.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 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 (March 11, 2017) is 2602 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 602, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-idr-rtc-no-rt-06 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-05) exists of draft-hares-idr-flowspec-v2-00 == Outdated reference: A later version (-05) exists of draft-uttaro-idr-bgp-persistence-03 Summary: 2 errors (**), 0 flaws (~~), 6 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: September 12, 2017 Nokia 6 K. Patel 7 Arrcus, Inc 8 J. Haas 9 Juniper Networks 10 L. Yong 11 Huawei 12 March 11, 2017 14 Applying BGP flowspec rules on a specific interface set 15 draft-ietf-idr-flowspec-interfaceset-03 17 Abstract 19 BGP flowspec is an extension to BGP that allows for the dissemination 20 of traffic flow specification rules. The primary application of this 21 extension is DDoS mitigation where the flowspec rules are applied in 22 most cases to all peering routers of the network. 24 This document will present another use case of BGP flowspec where 25 flow specifications are used to maintain some access control lists at 26 network boundary. BGP flowspec is a very efficient distributing 27 machinery that can help in saving OPEX while deploying/updating ACLs. 28 This new application requires flow specification rules to be applied 29 only on a specific subset of interfaces and in a specific direction. 31 The current specification of BGP flowspec ([RFC5575]) introduces the 32 notion of flow specification (which describes the matching criterion) 33 and traffic filtering actions. The flow specification is encoded as 34 part of the NLRI while the traffic filtering actions are encoded as 35 extended communities. The combination of a flow specification and 36 one or more actions is known as a flow specification rule. [RFC5575] 37 does not detail where the flow specification rules need to be 38 applied. 40 Besides the flow specification and traffic filtering actions, this 41 document introduces the notion of traffic filtering scope in order to 42 drive where a particular rule must be applied. In particular, this 43 document introduces the "interface-set" traffic filtering scope that 44 could be used in parallel of traffic filtering actions (marking, 45 rate-limiting ...). The purpose of this extension is to inform 46 remote routers about groups of interfaces where the rule must be 47 applied. 49 This extension can also be used in a DDoS mitigation context where a 50 provider wants to apply the filtering only on specific peers. 52 Requirements Language 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 Status of This Memo 60 This Internet-Draft is submitted in full conformance with the 61 provisions of BCP 78 and BCP 79. 63 Internet-Drafts are working documents of the Internet Engineering 64 Task Force (IETF). Note that other groups may also distribute 65 working documents as Internet-Drafts. The list of current Internet- 66 Drafts is at http://datatracker.ietf.org/drafts/current/. 68 Internet-Drafts are draft documents valid for a maximum of six months 69 and may be updated, replaced, or obsoleted by other documents at any 70 time. It is inappropriate to use Internet-Drafts as reference 71 material or to cite them other than as "work in progress." 73 This Internet-Draft will expire on September 12, 2017. 75 Copyright Notice 77 Copyright (c) 2017 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents 82 (http://trustee.ietf.org/license-info) in effect on the date of 83 publication of this document. Please review these documents 84 carefully, as they describe your rights and restrictions with respect 85 to this document. Code Components extracted from this document must 86 include Simplified BSD License text as described in Section 4.e of 87 the Trust Legal Provisions and are provided without warranty as 88 described in the Simplified BSD License. 90 Table of Contents 92 1. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 93 1.1. Specific filtering for DDoS . . . . . . . . . . . . . . . 3 94 1.2. ACL maintenance . . . . . . . . . . . . . . . . . . . . . 4 95 2. Collaborative filtering and managing filter direction . . . . 5 96 3. Traffic filtering scope . . . . . . . . . . . . . . . . . . . 6 97 4. Interface specific filtering using BGP flowspec . . . . . . . 7 98 5. Interface-set extended community . . . . . . . . . . . . . . 8 99 6. Handling rules from different sources in the processing pipe 9 100 6.1. Combining Policy Based Routing with BGP flowspec and 101 interface-set . . . . . . . . . . . . . . . . . . . . . . 10 102 6.2. Combining flow collection with BGP flowspec and 103 interface-set . . . . . . . . . . . . . . . . . . . . . . 11 104 7. Scaling of per interface rules . . . . . . . . . . . . . . . 11 105 8. Deployment considerations . . . . . . . . . . . . . . . . . . 12 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 107 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 108 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 109 11.1. FlowSpec Transitive Extended Communities . . . . . . . . 13 110 11.2. FlowSpec Non-Transitive Extended Communities . . . . . . 13 111 11.3. FlowSpec interface-set Extended Community . . . . . . . 13 112 11.4. Allocation Advice to IANA . . . . . . . . . . . . . . . 13 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 114 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 115 12.2. Informative References . . . . . . . . . . . . . . . . . 14 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 118 1. Use case 120 1.1. Specific filtering for DDoS 122 ----------------- --- (ebgp) - Peer3 (BW 10G) 123 / \/ 124 | /| 125 | PE --- (ebgp) - Transit1(BW 4x10G) 126 Cust1 --- (ebgp) --- PE | 127 | PE ---- (ebgp) - Peer2 (BW 4*10G) 128 | \| 129 Cust2 --- (ebgp) --- PE |----- (ebgp) - Customer3 130 /| | 131 Peer1(BW10G)-(ebgp) | PE --- (ebgp) - Transit2(BW 4x10G) 132 | | 133 \ / 134 ------------------ 136 Figure 1 138 The figure 1 above displays a typical service provider Internet 139 network owing Customers, Peers and Transit. To protect pro actively 140 against some attacks (e.g. DNS, NTP ...), the service provider may 141 want to deploy some rate-limiting of some flows on peers and transit 142 links. But depending on link bandwidth, the provider may want to 143 apply different rate-limiting values. 145 For 4*10G links peer/transit, it may want to apply a rate-limiting of 146 DNS flows of 1G, while on 10G links, the rate-limiting would be set 147 to 250Mbps. Customer interfaces must not be rate-limited. 149 BGP flowspec infrastructure may already be present on the network, 150 and all PEs may have a BGP session running flowspec address family. 151 The flowspec infrastructure may be reused by the service provider to 152 implement such rate-limiting in a very quick manner and being able to 153 adjust values in future quickly without having to configure each node 154 one by one. Using the current BGP flowspec specification, it would 155 not be possible to implement different rate limiter on different 156 interfaces of a same router. The flowspec rule is applied to all 157 interfaces in all directions or on some interfaces where flowspec is 158 activated but flowspec rule set would be the same among all 159 interfaces. 161 Section Section 4 will detail a solution to address this use case 162 using BGP flowspec. 164 1.2. ACL maintenance 166 --------------- --- (ebgp) - Cust4_VPN 167 / \/ 168 Cust1_INT -- (ebgp) --- PE /| 169 | PE ------ (ebgp) - Transit1 170 Cust3_VPN -- (ebgp) --- PE | 171 | PE ------ (ebgp) - Peer2 172 | \| 173 Cust2_INT -- (ebgp) --- PE |----- (ebgp) - Cust4_INT 174 /| | 175 Peer1 ------ (ebgp) -- | PE ------ (ebgp) - Transit2 176 | | 177 \ / 178 ---------------- 180 Figure 2 182 The figure 1 above displays a typical service provider multiservice 183 network owing Customers, Peers and Transit for Internet, as well as 184 VPN services. The service provider requires to ensure security of 185 its infrastructure by applying ACLs at network boundary. Maintaining 186 and deploying ACLs on hundreds/thousands of routers is really painful 187 and time consuming and a service provider would be interested to 188 deploy/updates ACLs using BGP flowspec. In this scenario, depending 189 on the interface type (Internet customer, VPN customer, Peer, Transit 190 ...) the content of the ACL may be different. 192 We foresee two main cases : 194 o Maintaining complete ACLs using flowspec : in this case all the 195 ingress ACL are maintained and deployed using BGPflowspec. See 196 section Section 9 for more details on security aspects. 198 o Requirement of a quick deployment of a new filtering term due to a 199 security alert : new security alerts often requires a fast 200 deployment of new ACL terms. Using traditional CLI and hop by hop 201 provisioning, such deployment takes time and network is 202 unprotected during this time window. Using BGP flowspec to deploy 203 such rule, a service provider can protect its network in few 204 seconds. Then the SP can decide to keep the rule permanently in 205 BGP flowspec or update its ACL or remove the entry (in case 206 equipments are not vulnerable anymore). 208 Section Section 4 will detail a solution to address this use case 209 using BGP flowspec. 211 2. Collaborative filtering and managing filter direction 213 [RFC5575] states in Section 5. : "This mechanism is primarily 214 designed to allow an upstream autonomous system to perform inbound 215 filtering in their ingress routers of traffic that a given downstream 216 AS wishes to drop.". 218 In case of networks collaborating in filtering, there is a use case 219 for performing outbound filtering. Outbound filtering allows to 220 apply traffic action one step before and so may allow to prevent 221 impact like congestions. 223 ---------------------- 224 / \ 225 | Upstream provider | 226 \ / 227 ----------------------- 228 | | 229 |P2 |P1 230 ---------------------- 231 / \ 232 | MyAS | 233 \ / 234 ----------------------- 236 Figure 3 238 In the figure above, MyAS is connected to an upstream provider. If a 239 malicious traffic comes in from the upstream provider, it may 240 congestion P1 or P2 links. If MyAS apply inbound filtering on P1/P2 241 using BGP flowspec, the congestion issue will not be solved. 243 Using collaborative filtering, the upstream provider may propose to 244 MyAS to filter malicious traffic sent to it. We propose to enhance 245 [RFC5575] to make myAS able to send BGP flowspec updates (on eBGP 246 sessions) to the upstream provider to request outbound filtering on 247 peering interfaces towards MyAS. When the upstream provider will 248 receive the BGP flowspec update from MyAS, the BGP flowspec update 249 will contain request for outbound filtering on a specific set of 250 interfaces. The upstream provider will apply automatically the 251 requested filter and congestion will be prevented. 253 3. Traffic filtering scope 255 We see with the use case described above that some BGP flowspec rules 256 may need to be applied only on specific elements of the network 257 (interfaces, nodes ...). The basic specification detailed in 258 [RFC5575] does not address this and does not give any detail on where 259 the traffic filtering rule need to be applied. 261 In addition to the flow specification (flow matching criterion) and 262 traffic filtering actions described in [RFC5575], this document 263 introduces the notion of traffic filtering scope. The traffic 264 filtering scope will describe where a particular flow specification 265 rule must be applied. 267 Using a traffic filtering scope in a BGP flowspec rule is optional. 268 When a rule does not contain any traffic filtering scope parameter, 269 [RFC5575] applies. 271 4. Interface specific filtering using BGP flowspec 273 The use case detailed above requires application of different BGP 274 flowspec rules on different set of interfaces. 276 We propose to introduce, within BGP flowspec, a traffic filtering 277 scope that identifies a group of interfaces where a particular filter 278 should apply on. Identification of interfaces within BGP flowspec 279 will be done through group identifiers. A group identifier marks a 280 set of interfaces sharing a common administrative property. Like a 281 BGP community, the group identifier itself does not have any 282 significance. It is up to the network administrator to associate a 283 particular meaning to a group identifier value (e.g. group ID#1 284 associated to Internet customer interfaces). The group identifier is 285 a local interface property. Any interface may be associated with one 286 or more group identifiers using manual configuration. 288 When a filtering rule advertised through BGP flowspec must be applied 289 only to particular sets of interfaces, the BGP flowspec BGP update 290 will contain the identifiers associated with the relevant sets of 291 interfaces. In addition to the group identifiers, it will also 292 contain the direction the filtering rule must be applied in (see 293 Section 5). 295 Configuration of group identifiers associated to interfaces may 296 change over time. An implementation MUST ensure that the filtering 297 rules (learned from BGP flowspec) applied to a particular interface 298 are always updated when the group identifier mapping is changing. 300 Considering figure 2, we can imagine the following design : 302 o Internet customer interfaces are associated with group-identifier 303 1. 305 o VPN customer interfaces are associated with group-identifier 2. 307 o All customer interfaces are associated with group-identifier 3. 309 o Peer interfaces are associated with group-identifier 4. 311 o Transit interfaces are associated with group-identifier 5. 313 o All external provider interfaces are associated with group- 314 identifier 6. 316 o All interfaces are associated with group-identifier 7. 318 If the service provider wants to deploy a specific inbound filtering 319 on external provider interfaces only, the provider can send the BGP 320 flow specification using group-identifier 6 and including inbound 321 direction. 323 There are some cases where nodes are dedicated to specific functions 324 (Internet peering, Internet Edge, VPN Edge, Service Edge ...), in 325 this kind of scenario, there is an interest for a constrained 326 distribution of filtering rules that are using the interface specific 327 filtering. Without the constrained route distribution, all nodes 328 will received all the filters even if they are not interested in 329 those filters. Constrained route distribution of flowspec filters 330 would allow for a more optimized distribution. 332 5. Interface-set extended community 334 This document proposes a new BGP Route Target extended community 335 called "flowspec interface-set". This document so expands the 336 definition of the Route Target extended community to allow a new 337 value of high order octet (Type field) to be TBD (in addition to the 338 values specified in [RFC4360]). 340 In order to ease intra-AS and inter-AS use cases, this document 341 proposes to have a transitive as well as a non transitive version of 342 this extended community. 344 This new BGP Route Target extended community is encoded as follows : 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type (TBD) | 0x02 | Autonomous System Number : 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 : AS Number (cont.) |O|I| Group Identifier | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 The flags are : 356 o O : if set, the flow specification rule MUST be applied in 357 outbound direction to the interface set referenced by the 358 following group-identifier. 360 o I : if set, the flow specification rule MUST be applied in input 361 direction to the interface set referenced by the following group- 362 identifier. 364 Both flags can be set at the same time in the interface-set extended 365 community leading to flow rule to be applied in both directions. An 366 interface-set extended community with both flags set to zero MUST be 367 treated as an error and as consequence, the flowspec update MUST be 368 discarded. As having no direction indicated as no sense, there is no 369 need to propagate the filter informations in the network. 371 The Group Identifier is coded as a 14-bit number (values goes from 0 372 to 16383). 374 Multiple instances of the interface-set community may be present in a 375 BGP update. This may appear if the flow rule need to be applied to 376 multiple set of interfaces. 378 Multiple instances of the community in a BGP update MUST be 379 interpreted as a "OR" operation : if a BGP update contains two 380 interface-set communities with group ID 1 and group ID 2, the filter 381 would need to be installed on interfaces belonging to Group ID 1 or 382 Group ID 2. 384 As using a Route Target, route distribution of flowspec NLRI with 385 interface-set may be subject to constrained distribution as defined 386 in [RFC4684]. Constrained route distribution for flowspec routes 387 using interface-set requires discussion and will be addressed in a 388 future revision of the document. 390 6. Handling rules from different sources in the processing pipe 392 A packet on a router may be processed by multiple rules that are 393 originated by different sources (e.g. statically configured, I2RS 394 ephemeral, BGP ephemeral ...). [RFC5575] does not provide any 395 guidance regarding the precedence of BGP flowspec rules compared to 396 other sources. A new version of BGP flowspec 397 [I-D.hares-idr-flowspec-v2] should address these precedence rules 398 definition in future. 400 This document only addresses the usage of "interface-set" in the 401 framework of [RFC5575] and the following generic rules SHOULD be used 402 by an implementation: 404 o An inbound flowspec rule using interface-set SHOULD be processed 405 after all existing inbound traffic processing rules (ACL, PBR, 406 QoS, flow collection ...) and SHOULD be applied before forwarding 407 decision is made. 409 o An outbound flowspec rule using interface-set SHOULD be processed 410 after all existing outbound traffic processing rules (ACL, PBR, 411 QoS, flow collection ...) and SHOULD be applied after forwarding 412 decision has been made. 414 Inbound processing Forwarding Outbound processing 415 ACL->PBR->BGP_FS in -> Lookup -> PBR->QoS->I2RS->BGP_FS out 417 Example of packet processing pipe 419 In the example above, any BGP flowspec rule ([RFC5575]) with an 420 inbound interface-set is processed after all existing features (ACL, 421 PBR and QoS) but before the lookup is done. The outbound BGP 422 flowspec rules with interface-set are applied after the lookup and 423 after all any existing feature. 425 This section gives two examples of combining existing features with 426 BGP flowspec+interface-set attribute on an interface. 428 6.1. Combining Policy Based Routing with BGP flowspec and interface-set 430 In this example, a router has an already configured inbound policy on 431 an interface IF1 with the following rules: 433 o Static policy IN: 435 * Entry 1: from udp 10/8 to 11/8 port 53 then set dscp af11 and 436 accept 438 * Entry 2: from tcp 10/8 to 11/8 port 22 then set dscp af22 and 439 accept 441 * Entry 3: from tcp 10/8 to 11/8 port 80 then set dscp af11 and 442 accept 444 * Entry 4: from ip 10/8 to 11/8 then drop 446 In addition to this static inbound ACL, the router receives the 447 following unordered BGP flowspec version 1 rules with an interface- 448 set matching IF1. 450 o flowspec rules IN : 452 * from udp 10.0.0.1/32 to 11/8 port 53 then drop 454 * from tcp 10/8 to 11/8 port 80 then set dscp af32 and accept 456 * from udp 10/8 to 11/8 then accept 458 The combination of the static inbound ACL and the inbound "interface- 459 set" flowspec rules should result in the following packet processing: 461 o a UDP flow from 10.0.0.1 to 11.0.0.2 on port 53 will be rejected: 462 firstly, it is allowed by the static ACL and DSCP is set to af11 463 but then it is dropped by the flowspec filter. 465 o a UDP flow from 10.0.0.2 to 11.0.0.2 on port 53 will be accepted 466 and DSCP will be set to af11. 468 o a TCP flow from 10.0.0.2 to 11.0.0.2 on port 80 will be accepted 469 and DSCP will be set to af32: firstly, the static PBR rule set the 470 DSCP to af11 and accepts the packet, then the flowspec filter 471 rewrites the DSCP to af32 and accepts it also. 473 6.2. Combining flow collection with BGP flowspec and interface-set 475 A router may activate flow collection features (used in collaboration 476 with Netflow export). Flow collection can be done at input side or 477 output side. When a router is configured to collect flow 478 informations on an inbound interface, the flow collection happens 479 before any BGP flowspec rule with interface-set: if a particular 480 packet flow is denied by a BGP flowspec rule, it will still be 481 collected. 483 The same happens if a router is configured to collect flow 484 informations on an outbound interface, the flow collection happens, 485 and then the BGP flowspec rule is applied: the flow is collected 486 whatever the result of the BGP flowspec rule. 488 7. Scaling of per interface rules 490 Without "interface-set", all the interfaces are using the same 491 flowspec filter, while with "interface-set" different interfaces may 492 have different flowspec filters (with different terms and actions). 493 Having such flowspec rules that are applied on specific interfaces 494 may create forwarding instructions that may be harder to share within 495 the forwarding plane: a particular term may be present or not in the 496 filter of a particular interface. 498 An implementation SHOULD take care about trying to keep sharing 499 forwarding structures as much as possible in order to limit the 500 scaling impact. How the implementation would do so is out of scope 501 of the document. 503 8. Deployment considerations 505 There are some cases where a particular BGP flowspec NLRI may be 506 advertised to different interface groups with a different action. 507 For example, a service provider may want to discard all ICMP traffic 508 from customer interfaces to infrastructure addresses and want to 509 rate-limit the same traffic when it comes from some internal 510 platforms. These particular cases require ADD-PATH to be deployed in 511 order to ensure that all paths (NLRI+interface-set group-id+actions) 512 are propagated within the BGP control plane. Without ADD-PATH, only 513 a single "NLRI+interface-set group-id+actions" will be propagated, so 514 some filtering rules will never be applied. 516 9. Security Considerations 518 Managing permanent Access Control List by using BGP flowspec as 519 described in Section 1.2 helps in saving roll out time of such ACL. 520 However some ACL especially at network boundary are critical for the 521 network security and loosing the ACL configuration may lead to 522 network open for attackers. 524 By design, BGP flowspec rules are ephemeral : the flow rule exists in 525 the router while the BGP session is UP and the BGP path for the rule 526 is valid. We can imagine a scenario where a Service Provider is 527 managing the network boundary ACLs by using only flowspec. In this 528 scenario, if , for example, an attacker succeed to make the internal 529 BGP session of a router to be down , it can open all boundary ACLs on 530 the node, as flowspec rules will disappear due to the BGP session 531 down. 533 In reality, the chance for such attack to occur is low, as boundary 534 ACLs should protect the BGP session from being attacked. 536 In order to complement the BGP flowspec solution is such deployment 537 scenario and provides security against such attack, a service 538 provider may activate Long lived Graceful Restart 539 [I-D.uttaro-idr-bgp-persistence] on the BGP session owning flowspec 540 address family. So in case of BGP session to be down, the BGP paths 541 of flowspec rules would be retained and the flowspec action will be 542 retained. 544 10. Acknowledgements 546 Authors would like to thanks Wim Hendrickx and Robert Raszuk for 547 their valuable comments. 549 11. IANA Considerations 551 11.1. FlowSpec Transitive Extended Communities 553 This document requests a new type from the "BGP Transitive Extended 554 Community Types" extended community registry from the First Come 555 First Served range. This type name shall be 'FlowSpec Transitive 556 Extended Communities'. 558 This document requests creation of a new registry called "FlowSpec 559 Transitive Extended Community Sub-Types". This registry contains 560 values of the second octet (the "Sub-Type" field) of an extended 561 community when the value of the first octet (the "Type" field) is the 562 value allocated in this document. The registration procedure for 563 values in this registry shall be First Come First Served. 565 11.2. FlowSpec Non-Transitive Extended Communities 567 This document requests a new type from the "BGP Non-Transitive 568 Extended Community Types" extended community registry from the First 569 Come First Served range. This type name shall be 'FlowSpec Non- 570 Transitive Extended Communities'. 572 This document requests creation of a new registry called "FlowSpec 573 Non-Transitive Extended Community Sub-Types". This registry contains 574 values of the second octet (the "Sub-Type" field) of an extended 575 community when the value of the first octet (the "Type" field) is the 576 value allocated in this document. The registration procedure for 577 values in this registry shall be First Come First Served. 579 11.3. FlowSpec interface-set Extended Community 581 Within the two new registries above, this document requests a new 582 subtype (suggested value 0x02). This sub-type shall be named 583 "interface-set", with a reference to this document. 585 11.4. Allocation Advice to IANA 587 IANA is requested to allocate the values of the FlowSpec Transitive 588 and Non-Transitive Extended Communities such that their values are 589 identical when ignoring the second high-order bit (Transitive). See 590 section 2, [RFC4360]. An example allocation would be 0x09/0x49. 592 It is suggested to IANA that, when possible, allocations from the 593 FlowSpec Transitive/Non-Transitive Extended Community Sub-Types 594 registries are made for transitive or non-transitive versions of 595 features (section 2, [RFC4360]) that their code point in both 596 registries is identical. 598 12. References 600 12.1. Normative References 602 [I-D.ietf-idr-rtc-no-rt] 603 Rosen, E., Patel, K., Haas, J., and R. Raszuk, "Route 604 Target Constrained Distribution of Routes with no Route 605 Targets", draft-ietf-idr-rtc-no-rt-06 (work in progress), 606 November 2016. 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, 610 DOI 10.17487/RFC2119, March 1997, 611 . 613 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 614 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 615 February 2006, . 617 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 618 R., Patel, K., and J. Guichard, "Constrained Route 619 Distribution for Border Gateway Protocol/MultiProtocol 620 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 621 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 622 November 2006, . 624 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 625 and D. McPherson, "Dissemination of Flow Specification 626 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 627 . 629 12.2. Informative References 631 [I-D.hares-idr-flowspec-v2] 632 Hares, S., "BGP Flow Specification Version 2", draft- 633 hares-idr-flowspec-v2-00 (work in progress), June 2016. 635 [I-D.uttaro-idr-bgp-persistence] 636 Uttaro, J., Chen, E., Decraene, B., and J. Scudder, 637 "Support for Long-lived BGP Graceful Restart", draft- 638 uttaro-idr-bgp-persistence-03 (work in progress), November 639 2013. 641 Authors' Addresses 642 Stephane Litkowski 643 Orange 645 Email: stephane.litkowski@orange.com 647 Adam Simpson 648 Nokia 650 Email: adam.1.simpson@nokia.com 652 Keyur Patel 653 Arrcus, Inc 655 Email: keyur@arrcus.com 657 Jeff Haas 658 Juniper Networks 660 Email: jhaas@juniper.net 662 Lucy Yong 663 Huawei 665 Email: lucy.yong@huawei.com