idnits 2.17.1 draft-li-idr-flowspec-rpd-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 17, 2016) is 2863 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: 'RFC4271' is defined on line 958, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-02 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft Huawei 4 Intended status: Standards Track L. Ou 5 Expires: December 19, 2016 Y. Luo 6 China Telcom Co., Ltd. 7 S. Lu 8 Tencent 9 S. Zhuang 10 N. Wu 11 Huawei 12 June 17, 2016 14 BGP FlowSpec Extensions for Routing Policy Distribution (RPD) 15 draft-li-idr-flowspec-rpd-02 17 Abstract 19 This document describes a mechanism to use BGP Flowspec address 20 family as routing-policy distribution protocol. This mechanism is 21 called BGP FlowSpec Extensions for Routing Policy Distribution (BGP- 22 FS RPD). 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 19, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 66 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 4 68 3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 5 69 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. FlowSpec Traffic Actions for Routing Policy Distribution 6 72 5.2. Option 1: BGP Policy Attribute . . . . . . . . . . . . . 6 73 5.2.1. Match Fields Format . . . . . . . . . . . . . . . . . 7 74 5.2.2. Action Fields Format . . . . . . . . . . . . . . . . 8 75 5.2.3. Operation Examples . . . . . . . . . . . . . . . . . 9 76 5.3. Option 2: BGP Wide Community . . . . . . . . . . . . . . 12 77 5.3.1. New Wide Community Atoms . . . . . . . . . . . . . . 12 78 5.3.2. Operation examples . . . . . . . . . . . . . . . . . 13 79 5.4. Capability Negotiation . . . . . . . . . . . . . . . . . 19 80 6. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 19 81 6.1. Route-Policy . . . . . . . . . . . . . . . . . . . . . . 19 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 88 11.2. Informative References . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 Some difficulties exist when optimize traffic paths on a traditional 94 IP network: 96 o Traffic can only be adjusted device by device. All routers that 97 the traffic traverses need to be configured. The configuration 98 workload is heavy. The operation is not only time consuming but 99 also prone to misconfiguration for Service Providers. 101 o The routing policies used to control network routes are complex, 102 posing difficulties to subsequent maintenance, high maintenance 103 skills are required. 105 Hence, an automatic mechanism for setting up routing policies is 106 desirable which can simplify the complexity of routing policies 107 configuration. This document describes a mechanism to use BGP 108 Flowspec address family [RFC5575] as route-policy distribution 109 protocol. This mechanism is called BGP FlowSpec Extensions for 110 Routing Policy Distribution (BGP-FS RPD). 112 2. Definitions and Acronyms 114 BGP Flow Specification route: BGP Flow Specification routes are 115 defined in RFC 5575. Each BGP Flow Specification route contains BGP 116 Network Layer Reachability Information (NLRI) and Extended Community 117 Attributes, which carry traffic filtering rules and actions to be 118 taken on filtered traffic. 120 BGP Flow Specification peer relationship: A BGP Flow Specification 121 peer relationship is established between the device that generates 122 BGP Flow Specification routes and each network ingress that will 123 transmit the BGP Flow Specification routes. After receiving the BGP 124 Flow Specification routes, the peer delivers preferred BGP Flow 125 Specification routes to the forwarding plane. The routes are then 126 converted into traffic policies that control attack traffic. 128 o ACL:Access Control List 130 o BGP: Border Gateway Protocol 132 o FS: Flow Specification 134 o PBR:Policy-Based Routing 136 o RPD: Routing Policy Distribution 138 o VPN: Virtual Private Network 140 3. Problem Statements 142 It is obvious that providers have the requirements to adjust their 143 business traffic from time to time because: 145 o Business development or network failure introduces link congestion 146 and overload. 148 o Network transmission quality decreased as the result of delay, 149 loss and need to adjust traffic to other paths. 151 o To control OPEX and CPEX, prefer the transit provider with lower 152 price. 154 3.1. Inbound Traffic Control 156 In the scenario below, for reasons above, the provider of AS100 157 saying P may wish the inbound traffic from AS200 enters AS100 through 158 link L3 instead of others. Since P doesn't have administration over 159 AS200, so there is no way for P to modify the route selection 160 criteria directly. 162 Traffic from PE1 to Prefix1 163 -----------------------------------> 165 +-----------------+ +-------------------------+ 166 | +---------+ | L1 | +----+ +----------+| 167 | |Speaker1 | +------------+ |IGW1| |policy || 168 | +---------+ |** L2**| +----+ |controller|| 169 | | ** ** | +----------+| 170 | +---+ | **** | | 171 | |PE1| | **** | | 172 | +---+ | ** ** | | 173 | +---------+ |** L3**| +----+ | 174 | |Speaker2 | +------------+ |IGW2| AS100 | 175 | +---------+ | L4 | +----+ | 176 | | | | 177 | AS200 | | | 178 | | | ... | 179 | | | | 180 | +---------+ | | +----+ +-------+ | 181 | |Speakern | | | |IGWn| |Prefix1| | 182 | +---------+ | | +----+ +-------+ | 183 +-----------------+ +-------------------------+ 185 Prefix1 advertise from AS100 to AS200 186 <---------------------------------------- 187 Figure 1: Inbound Traffic Control case 189 3.2. Outbound Traffic Control 191 In this scenario, the provider of AS100 saying P wishes to prefer 192 link L3 for the traffic to the destination Prefix2 among multiple 193 exits and links. This preference can be dynamic and change 194 frequently because of the reasons above. So the provider P expects 195 an efficient and convenient solution. 197 Traffic from PE2 to Prefix2 198 -----------------------------------> 199 +-------------------------+ +-----------------+ 200 |+----------+ +----+ |L1 | +---------+ | 201 ||policy | |IGW1| +------------+ |Speaker1 | | 202 ||controller| +----+ |** **| +---------+ | 203 |+----------+ |L2** ** | +-------+| 204 | | **** | |Prefix2|| 205 | | **** | +-------+| 206 | |L3** ** | | 207 | AS100 +----+ |** **| +---------+ | 208 | |IGW2| +------------+ |Speaker2 | | 209 | +----+ |L4 | +---------+ | 210 | | | | 211 |+---+ | | AS200 | 212 ||PE2| ... | | | 213 |+---+ | | | 214 | +----+ | | +---------+ | 215 | |IGWn| | | |Speakern | | 216 | +----+ | | +---------+ | 217 +-------------------------+ +-----------------+ 219 Prefix2 advertise from AS200 to AS100 220 <---------------------------------------- 221 Figure 2: Outbound Traffic Control case 223 4. Proposed Solution 225 BGP FlowSpec [RFC5575] leverages the BGP control plane to simplify 226 the distribution of filter rules. New filter rules can be injected 227 to all BGP peers simultaneously without changing router 228 configuration. Though the typical application of it is for DDOS 229 mitigation, it doesn't mean BGP Flowspec only takes effect on the 230 forwarding plane. 232 This document introduces a mechanism that uses BGP Flowspec as a 233 route-policy distribution protocol. It can be the same powerful as 234 the device-based route-policy while still has the efficiency and 235 convenience of BGP Flowspec. 237 This draft will use the term BGP-FS RPD as the abbreviation of 238 FlowSpec Extensions for Routing Policy Distribution. 240 5. Protocol Extensions 242 5.1. FlowSpec Traffic Actions for Routing Policy Distribution 244 The traffic-action extended community consists of 6 bytes of which 245 only the 2 least significant bits of the 6th byte (from left to 246 right) are currently defined in [RFC5575]. Terminal Action (bit 47) 247 and Sample (bit 46) defines in [RFC5575], this document defines Route 248 Policy Distribution Flag(Bit 45). 250 The Flow Specification Traffic Actions for Routing Policy 251 Distribution: 253 40 41 42 43 44 45 46 47 254 +---+---+---+---+---+---+---+---+ 255 | reserved | R | S | T | 256 +---+---+---+---+---+---+---+---+ 257 Figure 3: FlowSpec Traffic-action 259 Route Policy Distribution Flag(Bit 45): When this bit is set, the 260 corresponding filtering rules will be used as Route Policy. 262 5.2. Option 1: BGP Policy Attribute 264 This document defines and uses a new BGP attribute called the "BGP 265 Policy attribute". This is an optional BGP attribute. The format of 266 this attribute is defined as follows: 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | | 270 | Match fields (Variable) | 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 | Action fields (Variable) | 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 4: BGP Policy Attribute 279 Match fields: Match Fields define the matching criteria for the BGP 280 Policy Attribute. 282 Action fields: Action fields define the action being applied to the 283 target route. 285 5.2.1. Match Fields Format 287 Match Fields define the matching criteria for the BGP Policy 288 Attribute. 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Match Type (2 octets) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Number of Sub-TLVs (2 octets) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | | 296 | Sub-TLVs (Variable) | 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 5: Match Fields Format 301 Match Type: 303 0: Permit, specifies the permit mode of a match rule. If a route 304 matches the matching criteria of the BGP Policy Attribute, the 305 actions defined by the Action fields of the BGP Policy Attribute are 306 performed. If a route does not match the matching criteria for the 307 BGP Policy Attribute, then nothing needs to do with this route. 309 1: Deny, specifies the deny mode of a match rule. In the deny mode, 310 If a route does not match the matching criteria of the BGP Policy 311 Attribute, the actions defined by the Action fields of the BGP Policy 312 Attribute are performed. If a route matches the matching criteria of 313 the BGP Policy Attribute, then nothing needs to do with this route. 315 Number of Sub-TLVs: The number of Sub-TLVs contain in Match fields. 317 The contents of Match fields are encoded as Sub-TLVs, where each TLV 318 has the following format: 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type (2 octets) | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Length (2 octets) | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 | Values (Variable) | 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 6: Sub-TLVs Format 331 Type: The Type field contains a value of 1-65534. The values 0 and 332 65535 are reserved for future use. 334 Length: The Length field represents the total length of a given TLV's 335 value field in octets. 337 Values: The Value field contains the TLV value. 339 Supported format of the TLVs can be: 341 Type 1: IPv4 Neighbor 343 Type 2: IPv6 Neighbor 345 Type 3: ASN List 347 ... 349 To be added in later versions. 351 5.2.2. Action Fields Format 353 Action fields define the action being applied to the targeted route. 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Action Type (2 octets) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Action Length (2 octets) | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 | Action Values (Variable) | 362 | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 7: Action Fields Format 366 Action Type: The Action Type field contains a value of 1-65534. The 367 values 0 and 65535 are reserved for future use. 369 Action Length: The Action Length field represents the total length of 370 the Action Values in octets. 372 Action Values: The Action Values field contain parameters of the 373 action. 375 Supported format of the TLVs can be: 377 Type 1: Route-Preference 379 Type 2: Route-Prepend-AS 381 ... 383 To be added in later versions. 385 5.2.3. Operation Examples 387 5.2.3.1. Inbound Traffic Control 389 The traffic destined for Prefix1 needs to be scheduled to link 390 Speaker1 -> IGW2 for transmission. 392 The Policy Controller constructs a BGP-FS RPD route and pushes it to 393 all the IGW routers, the route carries: 395 1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI; 397 2. Flow Specification Traffic Action Extended Community with the 398 Route Policy Distribution Flag(Bit 45) set. When this bit is 399 set, the corresponding filtering rules will be used as Routing 400 Policies. 402 3. NO_ADVERTISE Community [RFC1997] 404 4. BGP Policy Attribute: 406 * Match Type: 2, Deny 408 * IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer 409 Speaker1 411 * Action Type: Route-Prepend-AS 413 * Action Value: Prepend-AS times is 5 415 IGW1 processes the received BGP-FS RPD route as follows: 417 1. IGW1 gets the target prefix Prefix1 from the Destination Prefix 418 component in the BGP FS NLRI of the BGP FS RPD route; 420 2. IGW1 identifies the Route Policy Distribution Flag carrying in 421 the Flow Specification Traffic Action Extended Community, then 422 IGW1 knows that the corresponding filtering rules will be used as 423 Routing Policies. 425 3. IGW1 uses the target prefix Prefix1 to choose the matching 426 routes, in this case, IGW1 will choose the current best route of 427 Prefix1; 429 4. IGW1 gets the matching criteria from the BGP Policy Attribute: 430 Local BGP Speaker IGW2, Remote BGP Speaker1; 432 5. IGW1 gets the action from the BGP Policy Attribute: Route- 433 Prepend-AS, 5 times; 435 IGW1 checks the matching criteria and finds that it doesn't hits the 436 matching criteria: Local BGP Speaker IGW2, Remote BGP Speaker1, at 437 the same time the Match Type is "Deny" mode, so IGW1 sends the best 438 route of Prefix1 to Speaker1 and Speaker2 with performing the Action 439 instructions from the BGP-FS RPD route: Prepend Local AS 5 times. 441 IGW2 processes the received BGP FS RPD route as follows: 443 1. IGW2 gets the target prefix Prefix1 from the Destination Prefix 444 component in the BGP-FS NLRI of the BGP FS RPD route; 446 2. IGW2 identifies the Route Policy Distribution Flag carrying in 447 the Flow Specification Traffic Action Extended Community, then 448 IGW2 knows that the corresponding filtering rules will be used as 449 Routing Policies. 451 3. IGW2 uses the target prefix Prefix1 to choose the matching 452 routes, in this case, IGW2 will choose the current best route of 453 Prefix1; 455 4. IGW2 gets the matching criteria from the BGP Policy Attribute: 456 Local BGP Speaker IGW2, Remote BGP Speaker1; 458 5. IGW2 gets the action from the BGP Policy Attribute: Route- 459 Prepend-AS, 5 times; 461 IGW2 checks the matching criteria and finds that there is a speaker 462 which hits the matching criteria: Local BGP Speaker IGW2, Remote BGP 463 Peer Speaker1, but the Match Type is "Deny" mode, so IGW2 sends the 464 best route of Prefix1 to Speaker1, without performing the Action 465 instructions from the BGP-FS RPD route. At the same time, IGW2 sends 466 the best route of Prefix1 to Speaker2 with performing the Action 467 instructions from the BGP-FS RPD route: Prepend Local AS 5 times. 469 In the similar manner, other IGWs will perform the same Action 470 instructions as IGW1. Then the traffic destined for Prefix1 has been 471 be scheduled to link L3 for transmission. 473 5.2.3.2. Outbound Traffic Control 475 In this scenario, if the bandwidth usage of a link exceeds the 476 specified threshold, the Policy Controller automatically identifies 477 which traffic needs to be scheduled and the Policy Controller 478 automatically calculates traffic control paths based on network 479 topology and traffic information. 481 For example, the outbound traffic destined for Prefix2 needs to be 482 scheduled to link IGW2 -> Speaker1 for transmission. 484 The Policy Controller sends a BGP-FS RPD route to IGW2, the route 485 carries: 487 1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI; 489 2. Flow Specification Traffic Action Extended Community with the 490 Route Policy Distribution Flag(Bit 45) set. When this bit is 491 set, the corresponding filtering rules will be used as Routing 492 Policies. 494 3. NO_ADVERTISE Community [RFC1997] 496 4. BGP Policy Attribute: 498 * Match Type: 1, Permit 500 * IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer 501 Speaker1 503 * Action Type: Route-Preference 505 * Action Value: none 507 IGW2 processes the received BGP FS RPD route as follows: 509 1. IGW2 gets the target prefix Prefix2 from the Destination Prefix 510 component in the BGP-FS NLRI of the BGP FS RPD route; 512 2. IGW2 identifies the Route Policy Distribution Flag carrying in 513 the Flow Specification Traffic Action Extended Community, then 514 IGW2 knows that the corresponding filtering rules will be used as 515 Routing Policies. 517 3. IGW2 uses the target prefix Prefix2 to choose the matching 518 routes, in this case, the prefix Prefix2 has two more routes: 520 Prefix Next-Hop Local BGP Speaker Remote BGP Peer 521 Prefix2 Speaker1 IGW2 Speaker1 522 Prefix2 Speaker2 IGW2 Speaker2 523 ... 525 4. IGW2 gets the matching criteria from the BGP Policy Attribute: 526 Local BGP Speaker IGW2, Remote BGP Peer Speaker1; 528 5. IGW2 gets the action from the BGP Policy Attribute: Route- 529 Preference; 531 So IGW2 chooses the BGP route received from Speaker1 instead of 532 Speaker2 as the best route and the outbound traffic destined for 533 Prefix2 can be scheduled to link L3 for transmission. 535 5.3. Option 2: BGP Wide Community 537 This section describes the option 2 for protocol extensions, which is 538 completely different from section 5.2 by reusing BGP Wide Community 539 introduced in [I-D.ietf-idr-wide-bgp-communities]. 541 BGP Wide Community Attribute is a very useful tool that it can be 542 used to convey different kinds of routing policies. 544 5.3.1. New Wide Community Atoms 546 Wide Community Atoms define in [I-D.ietf-idr-wide-bgp-communities] , 547 in that draft it defines Type 1 to Type 8. 549 New wide community atoms have to be introduced since the entrance and 550 exit of traffic need to be designated precisely. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+ 555 | Type | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Value (variable) | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 8: Wide Community Atoms 563 Supported format of the TLVs can be: 565 o Type 1: Autonomous System number list 567 o Type 2: IPv4 prefix (1 octet prefix length + prefix) list 569 o Type 3: IPv6 prefix (1 octet prefix length + prefix) list 571 o Type 4: Integer list 573 o Type 5: IEEE Floating Point Number list 575 o Type 6: Neighbor Class list 576 o Type 7: User-defined Class list7 578 o Type 8: UTF-8 String 580 o Type TBD: BGP IPv4 neighbor --- Newly introduced in this draft, 581 which contains the BGP session IPv4 local address and the BGP 582 session IPv4 peer address. 584 o Type TBD: BGP IPv6 neighbor --- Newly introduced in this draft, 585 which contains the BGP session IPv6 local address and the BGP 586 session IPv6 peer address. 588 5.3.2. Operation examples 590 5.3.2.1. Inbound Traffic Control 592 As required in the case, traffic from PE1 to Prefix1 need to enter 593 through L3, so IGWs except IGW2 should prepend ASN list to Prefix1 594 when populating to AS100. As shown in figure below, community 595 "PREPEND N TIMES BY AS" and "Exclude Target(s) TLV" are be used. 597 The encoding example using BGP Wide Community: 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Container Type 1 (1) | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 |1 0 0 0 0 0 0 0| 605 +-+-+-+-+-+-+-+-+ 606 | Hop Count: 0 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Length: 36 | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Community: PREPEND N TIMES BY AS 17 | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Own ASN 100 | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Context ASN# 100 | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 |ExcTargetTLV(2)| Length: 11 | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | IPv4Neig(TBD)| Length: 8 | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Local Speaker #IGW2 | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Remote Speaker #Speaker1 | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Param TLV (3) | Length: 7 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Integer (4) | Length: 4 | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Prepend # 5 | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 9: Example encoding for Inbound Traffic Control case 632 "PREPEND N TIMES BY AS" Wide Community has been defined in 633 [I-D.ietf-idr-registered-wide-bgp-communities]. 635 The traffic destined for Prefix1 needs to be scheduled to link 636 Speaker1 -> IGW2 for transmission. 638 The Policy Controller constructs a BGP-FS RPD route and pushes it to 639 all the IGW routers, the route carries: 641 1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI; 643 2. Flow Specification Traffic Action Extended Community with the 644 Route Policy Distribution Flag(Bit 45) set. When this bit is 645 set, the corresponding filtering rules will be used as Routing 646 Policies. 648 3. NO_ADVERTISE Community [RFC1997] 650 4. Wide BGP Community Attribute: 652 PREPEND N TIMES BY AS: 653 Type: 0x0001 S = src AS # 654 F = 0x80 C = 0x00000000 655 H = 0 T = none 656 L = 36 octets E = Type_TBD (BGP IPv4 neighbor) 657 R = 17 P = Type_4 (0x05) 659 Where "BGP IPv4 neighbor" Atom TLV contains: 660 The BGP session IPv4 local address: Local BGP Speaker IGW2 661 The BGP session IPv4 peer address: Remote BGP Peer Speaker1 663 IGW1 processes the received BGP-FS RPD route as follows: 665 1. IGW1 gets the target prefix Prefix1 from the Destination Prefix 666 component in the BGP FS NLRI of the BGP FS RPD route; 668 2. IGW1 identifies the Route Policy Distribution Flag carrying in 669 the Flow Specification Traffic Action Extended Community, then 670 IGW1 knows that the corresponding filtering rules will be used as 671 Routing Policies. 673 3. IGW1 uses the target prefix Prefix1 to choose the matching 674 routes, in this case, IGW1 will choose the current best route of 675 Prefix1; 677 4. IGW1 gets the action type from the Wide BGP Community Attribute: 678 PREPEND N TIMES BY AS; 680 5. IGW1 gets the matching criteria from the Wide BGP Community 681 Attribute: Exclude the BGP IPv4 neighbor: ; 684 6. IGW1 gets the parameter for "PREPEND N TIMES BY AS" from the Wide 685 BGP Community Attribute: 5 times; 687 IGW1 checks the matching criteria and finds that it doesn't hits the 688 exclude matching criteria: Local BGP Speaker IGW2, Remote BGP 689 Speaker1, so IGW1 sends the best route of Prefix1 to Speaker1 and 690 Speaker2 with performing the Action instructions from the BGP-FS RPD 691 route: Prepend Local AS 5 times. 693 IGW2 processes the received BGP FS RPD route as follows: 695 1. IGW2 gets the target prefix Prefix1 from the Destination Prefix 696 component in the BGP-FS NLRI of the BGP FS RPD route; 698 2. IGW2 identifies the Route Policy Distribution Flag carrying in 699 the Flow Specification Traffic Action Extended Community, then 700 IGW2 knows that the corresponding filtering rules will be used as 701 Routing Policies. 703 3. IGW2 uses the target prefix Prefix1 to choose the matching 704 routes, in this case, IGW2 will choose the current best route of 705 Prefix1; 707 4. IGW2 gets the action type from the Wide BGP Community Attribute: 708 PREPEND N TIMES BY AS; 710 5. IGW2 gets the matching criteria from the BGP Policy Attribute: 711 Exclude the BGP IPv4 neighbor: ; 714 6. IGW2 gets the parameter for "PREPEND N TIMES BY AS" from the Wide 715 BGP Community Attribute: 5 times; 717 IGW2 checks the matching criteria and finds that there is a speaker 718 which hits the exclude matching criteria: Local BGP Speaker IGW2, 719 Remote BGP Peer Speaker1, so IGW2 sends the best route of Prefix1 to 720 Speaker1 without performing the Action instructions from the BGP-FS 721 RPD route, at the same time, IGW2 sends the best route of Prefix1 to 722 Speaker2 with performing the Action instructions from the BGP-FS RPD 723 route: Prepend Local AS 5 times. 725 In the similar manner, other IGWs will perform the same Action 726 instructions as IGW1. Then the traffic destined for Prefix1 has been 727 be scheduled to link L3 for transmission. 729 5.3.2.2. Outbound Traffic Control 731 As required in the case, traffic from PE2 to Prefix2 need to exit 732 through L3, so IGWs should perfer the route from IGW2 to Speaker1. 733 As shown in figure below, community "LOCAL PREFERENCE" and "Target(s) 734 TLV" are be used. 736 The encoding example using BGP Wide Community: 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Container Type 1 (1) | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 |1 0 0 0 0 0 0 0| 744 +-+-+-+-+-+-+-+-+ 745 | Hop Count: 0 | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Length: 36 | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Community: LOCAL PREFERENCE 20 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Own ASN 100 | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Context ASN# 100 | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | TargetTLV(1) | Length: 11 | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | IPv4Neig(TBD)| Length: 8 | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Local Speaker #IGW2 | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Remote Speaker #Speaker1 | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Param TLV (3) | Length: 7 | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Integer (4) | Length: 4 | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Increment # 100 | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Figure 10: Example encoding for Outbound Traffic Control case 771 "LOCAL PREFERENCE" Wide Community has been defined in 772 [I-D.ietf-idr-registered-wide-bgp-communities] 774 In this scenario, if the bandwidth usage of a link exceeds the 775 specified threshold, the Policy Controller automatically identifies 776 which traffic needs to be scheduled and the Policy Controller 777 automatically calculates traffic control paths based on network 778 topology and traffic information. 780 For example, the outbound traffic destined for Prefix2 needs to be 781 scheduled to link IGW2 -> Speaker1 for transmission. 783 The Policy Controller sends a BGP-FS RPD route to IGW2, the route 784 carries: 786 1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI; 788 2. Flow Specification Traffic Action Extended Community with the 789 Route Policy Distribution Flag(Bit 45) set. When this bit is 790 set, the corresponding filtering rules will be used as Routing 791 Policies. 793 3. NO_ADVERTISE Community [RFC1997] 795 4. Wide BGP Community Attribute: 797 LOCAL PREFERENCE: 798 Type: 0x0001 S = src AS # 799 F = 0x80 C = 0x00000000 800 H = 0 T = Type_TBD (BGP IPv4 neighbor) 801 L = 36 octets E = none 802 R = 20 P = Type_4 (0x64) 804 Where "BGP IPv4 neighbor" Atom TLV contains: 805 The BGP session IPv4 local address: Local BGP Speaker IGW2 806 The BGP session IPv4 peer address: Remote BGP Peer Speaker1 808 IGW2 processes the received BGP FS RPD route as follows: 810 1. IGW2 gets the target prefix Prefix2 from the Destination Prefix 811 component in the BGP-FS NLRI of the BGP FS RPD route; 813 2. IGW2 identifies the Route Policy Distribution Flag carrying in 814 the Flow Specification Traffic Action Extended Community, then 815 IGW2 knows that the corresponding filtering rules will be used as 816 Routing Policies. 818 3. IGW2 uses the target prefix Prefix2 to choose the matching 819 routes, in this case, the prefix Prefix2 has two more routes: 821 Prefix Next-Hop Local BGP Speaker Remote BGP Peer 822 -------------------------------------------------------- 823 Prefix2 Speaker1 IGW2 Speaker1 824 Prefix2 Speaker2 IGW2 Speaker2 825 ... 827 4. IGW2 gets the action type from the Wide BGP Community Attribute: 828 LOCAL PREFERENCE; 830 5. IGW2 gets the matching criteria from the Wide BGP Community 831 Attribute: Local BGP Speaker IGW2, Remote BGP Peer Speaker1; 833 6. IGW2 gets the parameter for "LOCAL PREFERENCE" from the Wide BGP 834 Community Attribute: increment 100; 836 So IGW2 chooses the BGP route received from Speaker1 instead of 837 Speaker2 as the best route and the outbound traffic destined for 838 Prefix2 can be scheduled to link L3 for transmission. 840 5.4. Capability Negotiation 842 It is necessary to negotiate the capability to support BGP FlowSpec 843 Extensions for Route Policy Distribution (RPD). The BGP FS RPD 844 Capability is a new BGP capability [RFC5492]. The Capability Code 845 for this capability is to be specified by the IANA. The Capability 846 Length field of this capability is variable. The Capability Value 847 field consists of one or more of the following tuples: 849 +--------------------------------------------------+ 850 | Address Family Identifier (2 octets) | 851 +--------------------------------------------------+ 852 | Subsequent Address Family Identifier (1 octet) | 853 +--------------------------------------------------+ 854 | Send/Receive (1 octet) | 855 +--------------------------------------------------+ 856 Figure 11: BGP FS RPD Capability 858 The meaning and use of the fields are as follows: 860 Address Family Identifier (AFI): This field is the same as the one 861 used in [RFC4760]. 863 Subsequent Address Family Identifier (SAFI): This field is the same 864 as the one used in [RFC4760]. 866 Send/Receive: This field indicates whether the sender is (a) willing 867 to receive Route Policies via BGP FLowSpec from its peer (value 1), 868 (b) would like to send Route Policies via BGP FLowSpec to its peer 869 (value 2), or (c) both (value 3) for the . 871 6. Consideration 873 6.1. Route-Policy 875 Routing policies are used to filter routes and control how routes are 876 received and advertised. If route attributes, such as reachability, 877 are changed, the path along which network traffic passes changes 878 accordingly. 880 When advertising, receiving, and importing routes, the router 881 implements certain policies based on actual networking requirements 882 to filter routes and change the attributes of the routes. Routing 883 policies serve the following purposes: 885 o Control route advertising: Only routes that match the rules 886 specified in a policy are advertised. 888 o Control route receiving: Only the required and valid routes are 889 received. This reduces the size of the routing table and improves 890 network security. 892 o Filter and control imported routes: A routing protocol may import 893 routes discovered by other routing protocols. Only routes that 894 satisfy certain conditions are imported to meet the requirements 895 of the protocol. 897 o Modify attributes of specified routes Attributes of the routes: 898 that are filtered by a routing policy are modified to meet the 899 requirements of the local device. 901 o Configure fast reroute (FRR): If a backup next hop and a backup 902 outbound interface are configured for the routes that match a 903 routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be 904 implemented. 906 Routing policies are implemented using the following procedures: 908 1. Define rules: Define features of routes to which routing policies 909 are applied. Users define a set of matching rules based on 910 different attributes of routes, such as the destination address 911 and the address of the router that advertises the routes. 913 2. Implement the rules: Apply the matching rules to routing policies 914 for advertising, receiving, and importing routes. 916 7. Contributors 918 The following people have substantially contributed to the definition 919 of the BGP-FS RPD and to the editing of this document: 921 Peng Zhou 922 Huawei 923 Email: Jewpon.zhou@huawei.com 925 8. IANA Considerations 927 TBD. 929 9. Security Considerations 931 TBD. 933 10. Acknowledgements 935 The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong, 936 Haibo Wang, Lucy Yong, Qiandeng Liang, Zhenqiang Li for their 937 comments to this work. 939 11. References 941 11.1. Normative References 943 [I-D.ietf-idr-wide-bgp-communities] 944 Raszuk, R., Haas, J., Lange, A., Amante, S., Decraene, B., 945 Jakma, P., and R. Steenbergen, "Wide BGP Communities 946 Attribute", draft-ietf-idr-wide-bgp-communities-02 (work 947 in progress), May 2016. 949 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 950 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 951 . 953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 954 Requirement Levels", BCP 14, RFC 2119, 955 DOI 10.17487/RFC2119, March 1997, 956 . 958 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 959 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 960 DOI 10.17487/RFC4271, January 2006, 961 . 963 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 964 "Multiprotocol Extensions for BGP-4", RFC 4760, 965 DOI 10.17487/RFC4760, January 2007, 966 . 968 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 969 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 970 2009, . 972 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 973 and D. McPherson, "Dissemination of Flow Specification 974 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 975 . 977 11.2. Informative References 979 [I-D.ietf-idr-registered-wide-bgp-communities] 980 Raszuk, R. and J. Haas, "Registered Wide BGP Community 981 Values", draft-ietf-idr-registered-wide-bgp-communities-02 982 (work in progress), May 2016. 984 Authors' Addresses 986 Zhenbin Li 987 Huawei 988 Huawei Bld., No.156 Beiqing Rd. 989 Beijing 100095 990 China 992 Email: lizhenbin@huawei.com 994 Liang Ou 995 China Telcom Co., Ltd. 996 109 West Zhongshan Ave,Tianhe District 997 Guangzhou 510630 998 China 1000 Email: oul@gsta.com 1002 Yujia Luo 1003 China Telcom Co., Ltd. 1004 109 West Zhongshan Ave,Tianhe District 1005 Guangzhou 510630 1006 China 1008 Email: luoyuj@gsta.com 1010 Sujian Lu 1011 Tencent 1012 Tengyun Building,Tower A ,No. 397 Tianlin Road 1013 Shanghai, Xuhui District 200233 1014 China 1016 Email: jasonlu@tencent.com 1017 Shunwan Zhuang 1018 Huawei 1019 Huawei Bld., No.156 Beiqing Rd. 1020 Beijing 100095 1021 China 1023 Email: zhuangshunwan@huawei.com 1025 Nan Wu 1026 Huawei 1027 Huawei Bld., No.156 Beiqing Rd. 1028 Beijing 100095 1029 China 1031 Email: eric.wu@huawei.com