idnits 2.17.1 draft-li-idr-flowspec-rpd-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2019) is 1846 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 973, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-05 ** 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: September 11, 2019 Y. Luo 6 China Telcom Co., Ltd. 7 S. Lu 8 Tencent 9 H. Chen 10 S. Zhuang 11 H. Wang 12 Huawei 13 March 10, 2019 15 BGP Extensions for Routing Policy Distribution (RPD) 16 draft-li-idr-flowspec-rpd-04 18 Abstract 20 It is hard to adjust traffic and optimize traffic paths on a 21 traditional IP network from time to time through manual 22 configurations. It is desirable to have an automatic mechanism for 23 setting up routing policies, which adjust traffic and optimize 24 traffic paths automatically. This document describes BGP Extensions 25 for Routing Policy Distribution (BGP RPD) to support this. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 11, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 4 71 3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 4 72 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Extensions to BGP Floespec . . . . . . . . . . . . . . . 5 74 4.1.1. Traffic Actions for Routing Policy Distribution . . . 6 75 4.2. Using a New AFI and SAFI . . . . . . . . . . . . . . . . 6 76 4.3. BGP Wide Community . . . . . . . . . . . . . . . . . . . 7 77 4.3.1. New Wide Community Atoms . . . . . . . . . . . . . . 7 78 4.3.2. Application Examples . . . . . . . . . . . . . . . . 12 79 4.4. Capability Negotiation . . . . . . . . . . . . . . . . . 20 80 5. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 20 81 5.1. Route-Policy . . . . . . . . . . . . . . . . . . . . . . 20 82 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 88 10.2. Informative References . . . . . . . . . . . . . . . . . 23 89 Appendix A. BGP Policy Attribute . . . . . . . . . . . . . . . . 23 90 A.1. Match Fields . . . . . . . . . . . . . . . . . . . . . . 23 91 A.2. Action Fields . . . . . . . . . . . . . . . . . . . . . . 29 92 A.3. Application Examples . . . . . . . . . . . . . . . . . . 31 93 A.3.1. Change Attributes . . . . . . . . . . . . . . . . . . 31 94 A.3.2. Inbound Traffic Control . . . . . . . . . . . . . . . 32 95 A.3.3. Outbound Traffic Control . . . . . . . . . . . . . . 34 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 98 1. Introduction 100 It is difficult to optimize traffic paths on a traditional IP network 101 because of: 103 o Heavy configuration and error prone. Traffic can only be adjusted 104 device by device. All routers that the traffic traverses need to 105 be configured. The configuration workload is heavy. The 106 operation is not only time consuming but also prone to 107 misconfiguration for Service Providers. 109 o Complex. The routing policies used to control network routes are 110 complex, posing difficulties to subsequent maintenance, high 111 maintenance skills are required. 113 It is desirable to have an automatic mechanism for setting up routing 114 policies, which can simplify the routing policies configuration. 115 This document describes extensions to BGP for Routing Policy 116 Distribution to resolve these issues. 118 2. Terminology 120 The following terminology is used in this document. 122 o ACL:Access Control List 124 o BGP: Border Gateway Protocol 126 o FS: Flow Specification 128 o PBR:Policy-Based Routing 130 o RPD: Routing Policy Distribution 132 o VPN: Virtual Private Network 134 3. Problem Statements 136 It is obvious that providers have the requirements to adjust their 137 business traffic from time to time because: 139 o Business development or network failure introduces link congestion 140 and overload. 142 o Network transmission quality is decreased as the result of delay, 143 loss and they need to adjust traffic to other paths. 145 o To control OPEX and CPEX, prefer the transit provider with lower 146 price. 148 3.1. Inbound Traffic Control 150 In the scenario below, for the reasons above, the provider of AS100 151 saying P may wish the inbound traffic from AS200 enters AS100 through 152 link L3 instead of the others. Since P doesn't have any 153 administration over AS200, so there is no way for P to modify the 154 route selection criteria directly. 156 Traffic from PE1 to Prefix1 157 -----------------------------------> 159 +-----------------+ +-------------------------+ 160 | +---------+ | L1 | +----+ +----------+| 161 | |Speaker1 | +------------+ |IGW1| |policy || 162 | +---------+ |** L2**| +----+ |controller|| 163 | | ** ** | +----------+| 164 | +---+ | **** | | 165 | |PE1| | **** | | 166 | +---+ | ** ** | | 167 | +---------+ |** L3**| +----+ | 168 | |Speaker2 | +------------+ |IGW2| AS100 | 169 | +---------+ | L4 | +----+ | 170 | | | | 171 | AS200 | | | 172 | | | ... | 173 | | | | 174 | +---------+ | | +----+ +-------+ | 175 | |Speakern | | | |IGWn| |Prefix1| | 176 | +---------+ | | +----+ +-------+ | 177 +-----------------+ +-------------------------+ 179 Prefix1 advertised from AS100 to AS200 180 <---------------------------------------- 182 Inbound Traffic Control case 184 3.2. Outbound Traffic Control 186 In the scenario below, the provider of AS100 saying P prefers link L3 187 for the traffic to the destination Prefix2 among multiple exits and 188 links. This preference can be dynamic and changed frequently because 189 of the reasons above. So the provider P expects an efficient and 190 convenient solution. 192 Traffic from PE2 to Prefix2 193 -----------------------------------> 194 +-------------------------+ +-----------------+ 195 |+----------+ +----+ |L1 | +---------+ | 196 ||policy | |IGW1| +------------+ |Speaker1 | | 197 ||controller| +----+ |** **| +---------+ | 198 |+----------+ |L2** ** | +-------+| 199 | | **** | |Prefix2|| 200 | | **** | +-------+| 201 | |L3** ** | | 202 | AS100 +----+ |** **| +---------+ | 203 | |IGW2| +------------+ |Speaker2 | | 204 | +----+ |L4 | +---------+ | 205 | | | | 206 |+---+ | | AS200 | 207 ||PE2| ... | | | 208 |+---+ | | | 209 | +----+ | | +---------+ | 210 | |IGWn| | | |Speakern | | 211 | +----+ | | +---------+ | 212 +-------------------------+ +-----------------+ 214 Prefix2 advertised from AS200 to AS100 215 <---------------------------------------- 217 Outbound Traffic Control case 219 4. Protocol Extensions 221 Two solutions are proposed. One extends BGP Floespec. The other 222 uses a new AFI and SAFI. These solutions use the same BGP Wide 223 Community for encoding a routing policy. 225 4.1. Extensions to BGP Floespec 227 BGP FlowSpec [RFC5575] leverages the BGP control plane to simplify 228 the distribution of filter rules. New filter rules can be injected 229 to all BGP peers simultaneously without changing router 230 configuration. Its typical application is for DDOS mitigation. 232 This document extends BGP Flowspec as a routing policy distribution 233 protocol (BGP RPD for short). It can be as powerful as the device- 234 based routing policy while still has the efficiency and convenience 235 of BGP Flowspec. 237 4.1.1. Traffic Actions for Routing Policy Distribution 239 The traffic-action extended community consists of 6 bytes of which 240 only the 2 least significant bits of the 6th byte (from left to 241 right) are currently defined in [RFC5575]: Terminal Action (bit 47) 242 and Sample (bit 46). This document defines Routing Policy 243 Distribution (RPD, or R for short) Flag (Bit 45). The 6th byte with 244 this newly defined flag is illustrated below: 246 40 41 42 43 44 45 46 47 247 +---+---+---+---+---+---+---+---+ 248 | reserved | R | S | T | 249 +---+---+---+---+---+---+---+---+ 251 Traffic-action with RPD (R) flag 253 RPD (R) Flag (Bit 45): When this bit is set, the BGP Wide Community 254 will be used as a Routing Policy. 256 4.2. Using a New AFI and SAFI 258 A new AFI and SAFI are defined: the Routing Policy AFI whose 259 codepoint TBD1 is to be assigned by IANA, and SAFI whose codepoint 260 TBD2 is to be assigned by IANA. 262 The AFI and SAFI pair uses a new NLRI, which is defined as follows: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+ 267 | NLRI Length | 268 +-+-+-+-+-+-+-+-+ 269 | Policy Type | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Distinguisher (4 octets) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Peer IP (4/16 octets) ~ 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Where: 278 NLRI Length: 1 octet represents the length of NLRI. 280 Policy Type: 1 octet indicates the type of a policy. 1 is for 281 export policy. 2 is for import policy. 283 Distinguisher: 4 octet value uniquely identifies the policy in the 284 peer. 286 Peer IP: 4/16 octet value indicates an IPv4/IPv6 peer. 288 The NLRI containing the Routing Policy is carried in a BGP UPDATE 289 message, which MUST contain the BGP mandatory attributes and MAY also 290 contain some BGP optional attributes. 292 When receiving a BGP UPDATE message, a BGP speaker processes it only 293 if the peer IP address in the NLRI is the IP address of the BGP 294 speaker or 0. 296 The content of the Routing Policy is encoded in a BGP Wide Community. 298 4.3. BGP Wide Community 300 The BGP wide community is defined in 301 [I-D.ietf-idr-wide-bgp-communities]. It can be used to facilitate 302 the delivery of new network services, and be extended easily for 303 distributing different kinds of routing policies. 305 4.3.1. New Wide Community Atoms 307 A wide community Atom is a TLV (or sub-TLV), which may be included in 308 a BGP wide community container (or BGP wide community for short) 309 containing some BGP Wide Community TLVs. Three BGP Wide Community 310 TLVs are defined in [I-D.ietf-idr-wide-bgp-communities], which are 311 BGP Wide Community Target(s) TLV, Exclude Target(s) TLV, and 312 Parameter(s) TLV. Each of these TLVs comprises a series of Atoms, 313 each of which is a TLV (or sub-TLV). A new wide community Atom is 314 defined for BGP Wide Community Target(s) TLV and a few new Atoms are 315 defined for BGP Wide Community Parameter(s) TLV. For your reference, 316 the format of the TLV is illustrated below: 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type | Length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Value (variable) ~ 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Format of Wide Community Atom TLV 328 A RouteAttr Atom TLV (or RouteAttr TLV/sub-TLV for short) is defined 329 and may be included in a Target TLV. It has the following format. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type (TBD1) | Length (variable) | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | sub-TLVs ~ 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Format of RouteAttr Atom TLV 341 The Type for RouteAttr is TBD1 (suggested value 48) to be assigned by 342 IANA. In RouteAttr TLV, three sub-TLVs are defined: IP Prefix, AS- 343 Path and Community sub-TLV. 345 An IP prefix sub-TLV gives matching criteria on IPv4 prefixes. Its 346 format is illustrated below: 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type (TBD2) | Length (N x 8) |M-Type | Flags | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | IPv4 Address | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Mask | GeMask | LeMask |M-Type | Flags | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 ~ . . . 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | IPv4 Address | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Mask | GeMask | LeMask | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Format of IPv4 Prefix sub-TLV 366 Type: TBD2 (suggested value 1) for IPv4 Prefix is to be assigned by 367 IANA. 369 Length: N x 8, where N is the number of tuples . 372 M-Type: 4 bits for match types, four of which are defined: 374 M-Type = 0: Exact match. 376 M-Type = 1: Match prefix greater and equal to the given maskes. 378 M-Type = 2: Match prefix less and equal to the given maskes. 380 M-Type = 3: Match prefix within the range of the given maskes. 382 Flags: 4 bits. No flags are currently defined. 384 IPv4 Address: 4 octets for an IPv4 address. 386 Mask: 1 octet for the mask length. 388 GeMask: 1 octet for match range, must be less than Mask or be 0. 390 LeMask: 1 octet for match range, must be greater than Mask or be 0. 392 For example, tuple represents an exact IP prefix match for 394 1.1.0.0/22. 396 represents match IP prefix 1.1.0.0/24 greater-equal 24. 399 represents match IP prefix 17.1.0.0/24 less-equal 26. 402 represents match IP prefix 18.1.0.0/24 greater-equal to 404 24 and less-equal 32. 406 Similarly, an IPv6 Prefix sub-TLV represents match criteria on IPv6 407 prefixes. Its format is illustrated below: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type(TBD3) | Length (N x 20) |M-Type | Flags | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | IPv6 Address (16 octets) ~ 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Mask | GeMask | LeMask |M-Type | Flags | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 ~ . . . 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | IPv6 Address (16 octets ~ 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Mask | GeMask | LeMask | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Format of IPv6 Prefix sub-TLV 427 An AS-Path sub-TLV represents a match criteria in a regular 428 expression string. Its format is illustrated below: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type (TBD4) | Length (Variable) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | AS-Path Regex String | 436 : : 437 | ~ 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Format of AS Path sub-TLV 442 Type: TBD4 (suggested value 2) for AS-Path is to be assigned by 443 IANA. 445 Length: Variable, maximum is 1024. 447 AS-Path Regex String: AS-Path regular expression string. 449 A community sub-TLV represents a list of communities to be matched 450 all. Its format is illustrated below: 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type (TBD5) | Length (N x 4 + 1) | Flags | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Community 1 Value | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 ~ . . . ~ 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Community N Value | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Format of Community sub-TLV 466 Type: TBD5 (suggested value 3) for Community is to be assigned by 467 IANA. 469 Length: N x 4 + 1, where N is the number of communities. 471 Flags: 1 octet. No flags are currently defined. 473 In Parameter(s) TLV, two action sub-TLVs are defined: MED change sub- 474 TLV and AS-Path change sub-TLV. When the community in the container 475 is MATCH AND SET ATTR, the Parameter(s) TLV includes some of these 476 sub-TLVs. When the community is MATCH AND NOT ADVERTISE, the 477 Parameter(s) TLV's value is empty. 479 A MED change sub-TLV indicates an action to change the MED. Its 480 format is illustrated below: 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Type (TBD6) | Length (5) | OP | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Value | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Format of MED Change sub-TLV 492 Type: TBD6 (suggested value 1) for MED Change is to be assigned by 493 IANA. 495 Length: 5. 497 OP: 1 octet. Three are defined: 499 OP = 0: assign the Value to the existing MED. 501 OP = 1: add the Value to the existing MED. If the sum is greater 502 than the maximum value for MED, assign the maximum value to 503 MED. 505 OP = 2: subtract the Value from the existing MED. If the 506 existing MED minus the Value is less than 0, assign 0 to MED. 508 Value: 4 octets. 510 An AS-Path change sub-TLV indicates an action to change the AS-Path. 511 Its format is illustrated below: 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Type (TBD7) | Length (n x 5) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | AS1 | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Count1 | 521 +-+-+-+-+-+-+-+-+ 522 ~ . . . 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | ASn | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Countn | 527 +-+-+-+-+-+-+-+-+ 529 Format of AS-Path Change sub-TLV 531 Type: TBD7 (suggested value 2) for AS-Path Change is to be assigned 532 by IANA. 534 Length: n x 5. 536 ASi: 4 octet. An AS number. 538 Counti: 1 octet. ASi repeats Counti times. 540 The sequence of AS numbers are added to the existing AS Path. 542 4.3.2. Application Examples 544 4.3.2.1. Change Attributes 546 Multiple attributes of a route may be changed when it matches given 547 criteria. In the example below, the policy has the following 548 matching criteria: 550 o match 20.20.15.0/20 to 20.20.15.0/24 552 o match as-path 6553601 6553601 554 The actions to be applied are add 12345 to the existing MED and add 555 AS sequence 123456, 6553602, 6553602, 6553602, 6553602 to the end of 556 existing AS Path. These actions are listed as follows: 558 o apply MED = MED + 12345 560 o apply add as-path 123456, 6553602, 6553602, 6553602, 6553602 561 The corresponding BGP Wide Community Encoding for these is 562 illustrated below. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Container Type: 1 |Flags |0|1| Reserved(0) | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Length: 71 | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Community: Change Attributes TBD11 | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Source AS 64496 | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Context AS 64496 | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Target TLV: 1 | Length: 18 | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 |PrefxRange:TBD3| Length: 6 | Flags (0) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | MaskLen: 20 | LeMaskLen: 24 |IPv4 Prefix: 20.20. | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 |.15 | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | AS Path: TBD5 | Length: 6 | OP: 1 | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | AS 6553601 | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Count 2 | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 |ExcTargetTLV: 2| Length: 0 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 |Param TLV: 3| Length: 32 | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 |ChangeMED: TBD8| Length: 5 | OP: 2 | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Value: 12345 | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |AddASPath: TBD7| Length: 11 | OP: 1 | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | AS 123456 | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Count 1 | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | AS 6553602 | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Count 4 | 608 +-+-+-+-+-+-+-+-+ 610 Example BGP Wide Community Encoding for Change Attributes 612 4.3.2.2. Inbound Traffic Control 614 As required in the case, traffic from PE1 to Prefix1 need to enter 615 through L3, so IGWs except IGW2 should prepend ASN list to Prefix1 616 when populating to AS100. As shown in figure below, community 617 "PREPEND N TIMES BY AS" and "Exclude Target(s) TLV" are be used. 619 The encoding example using BGP Wide Community: 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Container Type: 1 |Flags |0|1| Reserved(0) | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Length: 36 | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Community: PREPEND N TIMES BY AS 17 | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Source AS 100 | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Context AS 100 | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 |ExcTargetTLV: 2| Length: 11 | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 |IPv4Sess: TBD1 | Length: 8 | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Local Address/Speaker #IGW2 | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Remote Address/Speaker #Speaker1 | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Param TLV: 3 | Length: 7 | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Integer: 4 | Length: 4 | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Prepend # 5 | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Example encoding for Inbound Traffic Control case 651 "PREPEND N TIMES BY AS" Wide Community has been defined in 652 [I-D.ietf-idr-registered-wide-bgp-communities]. 654 The traffic destined for Prefix1 needs to be scheduled to link 655 Speaker1 -> IGW2 for transmission. 657 The Policy Controller constructs a BGP RPD route and pushes it to all 658 the IGW routers, the route carries: 660 1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI; 662 2. Flow Specification Traffic Action Extended Community with the 663 Routing Policy Distribution (R) Flag (Bit 45) set. When this bit 664 is set, the corresponding filtering rules will be used as Routing 665 Policies. 667 3. NO_ADVERTISE Community [RFC1997] 669 4. Wide BGP Community Attribute: 671 PREPEND N TIMES BY AS: 672 Type: 0x0001 S = src AS # 673 F = 0x80 C = 0x00000000 674 H = 0 T = none 675 L = 36 octets E = Type_TBD (BGP IPv4 session) 676 R = 17 P = Type_4 (0x05) 678 Where "BGP IPv4 session" Atom TLV contains: 679 The BGP session IPv4 local address: Local BGP Speaker IGW2 680 The BGP session IPv4 peer address: Remote BGP Peer Speaker1 682 IGW1 processes the received BGP-FS RPD route as follows: 684 1. IGW1 gets the target prefix Prefix1 from the Destination Prefix 685 component in the BGP FS NLRI of the BGP FS RPD route; 687 2. IGW1 identifies the Routing Policy Distribution (R) Flag carrying 688 in the Flow Specification Traffic Action Extended Community, then 689 IGW1 knows that the corresponding filtering rules will be used as 690 Routing Policies. 692 3. IGW1 uses the target prefix Prefix1 to choose the matching 693 routes, in this case, IGW1 will choose the current best route of 694 Prefix1; 696 4. IGW1 gets the action type from the Wide BGP Community Attribute: 697 PREPEND N TIMES BY AS; 699 5. IGW1 gets the matching criteria from the Wide BGP Community 700 Attribute: Exclude the BGP IPv4 session: ; 703 6. IGW1 gets the parameter for "PREPEND N TIMES BY AS" from the Wide 704 BGP Community Attribute: 5 times; 706 IGW1 checks the matching criteria and finds that it doesn't hits the 707 exclude matching criteria: Local BGP Speaker IGW2, Remote BGP 708 Speaker1, so IGW1 sends the best route of Prefix1 to Speaker1 and 709 Speaker2 with performing the Action instructions from the BGP-FS RPD 710 route: Prepend Local AS 5 times. 712 IGW2 processes the received BGP FS RPD route as follows: 714 1. IGW2 gets the target prefix Prefix1 from the Destination Prefix 715 component in the BGP-FS NLRI of the BGP FS RPD route; 717 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying 718 in the Flow Specification Traffic Action Extended Community, then 719 IGW2 knows that the corresponding filtering rules will be used as 720 Routing Policies. 722 3. IGW2 uses the target prefix Prefix1 to choose the matching 723 routes, in this case, IGW2 will choose the current best route of 724 Prefix1; 726 4. IGW2 gets the action type from the Wide BGP Community Attribute: 727 PREPEND N TIMES BY AS; 729 5. IGW2 gets the matching criteria from the BGP Policy Attribute: 730 Exclude the BGP IPv4 session: ; 733 6. IGW2 gets the parameter for "PREPEND N TIMES BY AS" from the Wide 734 BGP Community Attribute: 5 times; 736 IGW2 checks the matching criteria and finds that there is a speaker 737 which hits the exclude matching criteria: Local BGP Speaker IGW2, 738 Remote BGP Peer Speaker1, so IGW2 sends the best route of Prefix1 to 739 Speaker1 without performing the Action instructions from the BGP-FS 740 RPD route, at the same time, IGW2 sends the best route of Prefix1 to 741 Speaker2 with performing the Action instructions from the BGP-FS RPD 742 route: Prepend Local AS 5 times. 744 In the similar manner, other IGWs will perform the same Action 745 instructions as IGW1. Then the traffic destined for Prefix1 has been 746 be scheduled to link L3 for transmission. 748 4.3.2.3. Outbound Traffic Control 750 As required in the case, traffic from PE2 to Prefix2 need to exit 751 through L3, so IGWs should prefer the route from IGW2 to Speaker1. 752 As shown in figure below, community "LOCAL PREFERENCE" and "Target(s) 753 TLV" are be used. 755 The encoding example using BGP Wide Community: 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Container Type: 1 |Flags |0|1| Reserved(0) | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Length: 36 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Community: LOCAL PREFERENCE 20 | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Source AS 100 | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Context AS 100 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | TargetTLV: 1 | Length: 11 | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | IPv4Sess:TBD1| Length: 8 | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Local Address/Speaker #IGW2 | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Remote Address/Speaker #Speaker1 | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Param TLV: 3 | Length: 7 | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Integer: 4 | Length: 4 | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Increment # 100 | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 Example encoding for Outbound Traffic Control case 787 "LOCAL PREFERENCE" Wide Community has been defined in 788 [I-D.ietf-idr-registered-wide-bgp-communities]. 790 In this scenario, if the bandwidth usage of a link exceeds the 791 specified threshold, the Policy Controller automatically identifies 792 which traffic needs to be scheduled and the Policy Controller 793 automatically calculates traffic control paths based on network 794 topology and traffic information. 796 For example, the outbound traffic destined for Prefix2 needs to be 797 scheduled to link IGW2 -> Speaker1 for transmission. 799 The Policy Controller sends a BGP-FS RPD route to IGW2, the route 800 carries: 802 1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI; 803 2. Flow Specification Traffic Action Extended Community with the RPD 804 (R) Flag (Bit 45) set. When this bit is set, the corresponding 805 filtering rules will be used as Routing Policies. 807 3. NO_ADVERTISE Community [RFC1997] 809 4. Wide BGP Community Attribute: 811 LOCAL PREFERENCE: 812 Type: 0x0001 S = src AS # 813 F = 0x80 C = 0x00000000 814 H = 0 T = Type_TBD (BGP IPv4 session) 815 L = 36 octets E = none 816 R = 20 P = Type_4 (0x64) 818 Where "BGP IPv4 session" Atom TLV contains: 819 The BGP session IPv4 local address: Local BGP Speaker IGW2 820 The BGP session IPv4 peer address: Remote BGP Peer Speaker1 822 IGW2 processes the received BGP FS RPD route as follows: 824 1. IGW2 gets the target prefix Prefix2 from the Destination Prefix 825 component in the BGP-FS NLRI of the BGP FS RPD route; 827 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying 828 in the Flow Specification Traffic Action Extended Community, then 829 IGW2 knows that the corresponding filtering rules will be used as 830 Routing Policies. 832 3. IGW2 uses the target prefix Prefix2 to choose the matching 833 routes, in this case, the prefix Prefix2 has two more routes: 835 Prefix Next-Hop Local BGP Speaker Remote BGP Peer 836 -------------------------------------------------------- 837 Prefix2 Speaker1 IGW2 Speaker1 838 Prefix2 Speaker2 IGW2 Speaker2 839 ... 841 4. IGW2 gets the action type from the Wide BGP Community Attribute: 842 LOCAL PREFERENCE; 844 5. IGW2 gets the matching criteria from the Wide BGP Community 845 Attribute: Local BGP Speaker IGW2, Remote BGP Peer Speaker1; 847 6. IGW2 gets the parameter for "LOCAL PREFERENCE" from the Wide BGP 848 Community Attribute: increment 100; 850 So IGW2 chooses the BGP route received from Speaker1 instead of 851 Speaker2 as the best route and the outbound traffic destined for 852 Prefix2 can be scheduled to link L3 for transmission. 854 4.4. Capability Negotiation 856 It is necessary to negotiate the capability to support BGP Extensions 857 for Routing Policy Distribution (RPD). The BGP RPD Capability is a 858 new BGP capability [RFC5492]. The Capability Code for this 859 capability is to be specified by the IANA. The Capability Length 860 field of this capability is variable. The Capability Value field 861 consists of one or more of the following tuples: 863 +--------------------------------------------------+ 864 | Address Family Identifier (2 octets) | 865 +--------------------------------------------------+ 866 | Subsequent Address Family Identifier (1 octet) | 867 +--------------------------------------------------+ 868 | Send/Receive (1 octet) | 869 +--------------------------------------------------+ 871 BGP RPD Capability 873 The meaning and use of the fields are as follows: 875 Address Family Identifier (AFI): This field is the same as the one 876 used in [RFC4760]. 878 Subsequent Address Family Identifier (SAFI): This field is the same 879 as the one used in [RFC4760]. 881 Send/Receive: This field indicates whether the sender is (a) willing 882 to receive Routing Policies from its peer (value 1), (b) would like 883 to send Routing Policies to its peer (value 2), or (c) both (value 3) 884 for the . 886 5. Consideration 888 5.1. Route-Policy 890 Routing policies are used to filter routes and control how routes are 891 received and advertised. If route attributes, such as reachability, 892 are changed, the path along which network traffic passes changes 893 accordingly. 895 When advertising, receiving, and importing routes, the router 896 implements certain policies based on actual networking requirements 897 to filter routes and change the attributes of the routes. Routing 898 policies serve the following purposes: 900 o Control route advertising: Only routes that match the rules 901 specified in a policy are advertised. 903 o Control route receiving: Only the required and valid routes are 904 received. This reduces the size of the routing table and improves 905 network security. 907 o Filter and control imported routes: A routing protocol may import 908 routes discovered by other routing protocols. Only routes that 909 satisfy certain conditions are imported to meet the requirements 910 of the protocol. 912 o Modify attributes of specified routes Attributes of the routes: 913 that are filtered by a routing policy are modified to meet the 914 requirements of the local device. 916 o Configure fast reroute (FRR): If a backup next hop and a backup 917 outbound interface are configured for the routes that match a 918 routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be 919 implemented. 921 Routing policies are implemented using the following procedures: 923 1. Define rules: Define features of routes to which routing policies 924 are applied. Users define a set of matching rules based on 925 different attributes of routes, such as the destination address 926 and the address of the router that advertises the routes. 928 2. Implement the rules: Apply the matching rules to routing policies 929 for advertising, receiving, and importing routes. 931 6. Contributors 933 The following people have substantially contributed to the definition 934 of the BGP-FS RPD and to the editing of this document: 936 Peng Zhou 937 Huawei 938 Email: Jewpon.zhou@huawei.com 940 7. IANA Considerations 942 TBD. 944 8. Security Considerations 946 TBD. 948 9. Acknowledgements 950 The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong, 951 Haibo Wang, Lucy Yong, Qiandeng Liang, Zhenqiang Li for their 952 comments to this work. 954 10. References 956 10.1. Normative References 958 [I-D.ietf-idr-wide-bgp-communities] 959 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 960 and P. Jakma, "BGP Community Container Attribute", draft- 961 ietf-idr-wide-bgp-communities-05 (work in progress), July 962 2018. 964 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 965 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 966 . 968 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 969 Requirement Levels", BCP 14, RFC 2119, 970 DOI 10.17487/RFC2119, March 1997, 971 . 973 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 974 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 975 DOI 10.17487/RFC4271, January 2006, 976 . 978 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 979 "Multiprotocol Extensions for BGP-4", RFC 4760, 980 DOI 10.17487/RFC4760, January 2007, 981 . 983 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 984 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 985 2009, . 987 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 988 and D. McPherson, "Dissemination of Flow Specification 989 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 990 . 992 10.2. Informative References 994 [I-D.ietf-idr-registered-wide-bgp-communities] 995 Raszuk, R. and J. Haas, "Registered Wide BGP Community 996 Values", draft-ietf-idr-registered-wide-bgp-communities-02 997 (work in progress), May 2016. 999 Appendix A. BGP Policy Attribute 1001 This document defines and uses a new BGP attribute called the "BGP 1002 Policy attribute". This is an optional BGP attribute. The format of 1003 this attribute is defined as follows: 1005 0 1 2 3 1006 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 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | Attr Flag |Attr Type(TBD) | Attr Length ~ 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | | 1011 ~ Match fields (Variable) ~ 1012 | | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | | 1015 ~ Action fields (Variable) ~ 1016 | | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 Format of BGP Policy Attribute 1021 Match fields: Match Fields define the matching criteria for the BGP 1022 Policy Attribute. 1024 Action fields: Action fields define the action being applied to the 1025 target route. 1027 A.1. Match Fields 1029 Match Fields define the matching criteria for the BGP Policy 1030 Attribute. It has the following format: 1032 0 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Match Type (2 octets) | Length (2 octets) | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 ~ Sub-TLVs (Variable) ~ 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 Match Fields Format 1042 Match Type: 1044 1: Permit, specifies the permit mode of a match rule. If a route 1045 matches the matching criteria of the BGP Policy Attribute, the 1046 actions defined by the Action fields of the BGP Policy Attribute are 1047 performed. If a route does not match the matching criteria for the 1048 BGP Policy Attribute, then nothing needs to be done with this route. 1050 2: Deny, specifies the deny mode of a match rule. In the deny mode, 1051 If a route does not match the matching criteria of the BGP Policy 1052 Attribute, the actions defined by the Action fields of the BGP Policy 1053 Attribute are performed. If a route matches the matching criteria of 1054 the BGP Policy Attribute, then nothing needs to be done with this 1055 route. 1057 Length: The total length of the Sub-TLVs in the Match fields. 1059 The contents of Match fields are encoded as Sub-TLVs, where each Sub- 1060 TLV has the following format: 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Type (2 octets) | Length (2 octets) | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 ~ Values (Variable) ~ 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 Sub-TLV Format 1072 Type: The Type field contains a value of 1-65534. The values 0 and 1073 65535 are reserved for future use. 1075 Length: The Length field represents the total length of a given TLV's 1076 value field in octets. 1078 Values: The Value field contains the TLV value. 1080 The following TLVs are defined: 1082 Type TBD1: BGP IPv4 Session (or IPv4 Session for short), whose TLV 1083 contains the IPv4 local address/speaker and remote address/speaker of 1084 a BGP session. Its TLV (or Sub-TLV) format is illustrated below: 1086 0 1 2 3 1087 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 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | Type (TBD1) | Length (8) | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Local IPv4 Address | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Remote IPv4 Address | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 Format of IPv4 Session TLV 1098 Type TBD2: BGP IPv6 Session (or IPv6 Session for short), whose TLV 1099 contains the IPv6 local address/speaker and remote address/speaker of 1100 a BGP session. Its TLV (or Sub-TLV) format is illustrated below: 1102 0 1 2 3 1103 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 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Type (TBD2) | Length (32) | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 ~ Local IPv6 Address (16 Bytes) ~ 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 ~ Remote IPv6 Address (16 Bytes) ~ 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 Format of IPv6 Session TLV 1114 Type TBD3: IPv4 Prefix Range, which represents a range of IPv4 1115 prefixes. Its format is illustrated below: 1117 0 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Type (TBD3) | Length (Variable) | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Flags | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | IPv4 Address | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | MaskLen | LeMaskLen | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 ~ . . . 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | IPv4 Address | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | MaskLen | LeMaskLen | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 Format of IPv4 Prefix Range TLV 1137 The IPv4 Prefix Range TLV (or Sub-TLV) contains a number of triple 1138 s. Each triple represents an IPv4 prefix range from IPv4- 1140 Address/MaskLen to IPv4-Address/LeMaskLen. For example, triple 1141 <10.10.0.0, 16, 16> represents prefixes 10.10.0.0/16 (i.e., from 1142 10.10.0.0/16 to 10.10.0.0/16). Triple <20.20.15.0, 20, 24> 1143 represents prefixes from 20.20.15.0/20 to 20.20.15.0/24. 1145 The encoding of IPv4 Prefix Range may be optimized to the following 1146 compact format: 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Type (TBD3) | Length (Variable) | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Flags | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | MaskLen | LeMaskLen | IPv4 Prefix ~ 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 ~ . . . 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | MaskLen | LeMaskLen | IPv4 Prefix ~ 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 Compact Format of IPv4 Prefix Range TLV 1164 It contains a number of triple s. 1165 Each triple represents an IPv4 1166 prefix range from IPv4-Prefix/MaskLen to IPv4-Prefix/LeMaskLen. 1167 LeMaskLen is the length of the prefix. For example, triple <16, 16, 1168 10.10.0.0> represents prefixes 10.10.0.0/16 (i.e., from 10.10.0.0/16 1169 to 10.10.0.0/16). Triple <20, 24, 20.20.15.0> represents prefixes 1170 from 20.20.15.0/20 to 20.20.15.0/24. 1172 Similarly, Type TBD4: IPv6 Prefix Range represents a range of IPv6 1173 prefixes. Its format is illustrated below: 1175 0 1 2 3 1176 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 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Type (TBD4) | Length (Variable) | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Flags | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 ~ IPv6 Address (16 Bytes) ~ 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | MaskLen | LeMaskLen | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 ~ . . . 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 ~ IPv6 Address (16 Bytes) ~ 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | MaskLen | LeMaskLen | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 Format of IPv6 Prefix Range TLV 1195 The encoding of IPv6 Prefix Range may be optimized to the following 1196 compact format: 1198 0 1 2 3 1199 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 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Type (TBD4) | Length (Variable) | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Flags | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | MaskLen | LeMaskLen | IPv6 Prefix ~ 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 ~ . . . 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | MaskLen | LeMaskLen | IPv6 Prefix ~ 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 Compact Format of IPv6 Prefix Range TLV 1214 Type TBD5: AS Path, which represents a sequence of AS numbers. For 1215 an AS number occurs multiple times in a row in a path, it is 1216 represented by the AS number and a count indicating the times that 1217 the AS number occurs. Its format is illustrated below: 1219 0 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Type (TBD5) | Length (Variable) | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Flags | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | AS1 | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Count1 | 1229 +-+-+-+-+-+-+-+-+ 1230 ~ . . . 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | ASn | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Countn | 1235 +-+-+-+-+-+-+-+-+ 1237 Format of AS Path TLV 1239 For example, AS Path "123456, 6553603, 6553603, 6553603" is 1240 represented by AS1 = 123456, Count1 = 1, AS2 = 6553603, and Count2 = 1241 3. 1243 Type TBD6: Communities, which represents a list of communities 1244 values. Its format is illustrated below: 1246 0 1 2 3 1247 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 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Type (TBD6) | Length (Variable) | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Flags | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Community 1 Value | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 ~ . . . ~ 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | Community n Value | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 Format of Communities TLV 1262 A.2. Action Fields 1264 Action fields define the action being applied to the targeted route. 1265 It has the following format. 1267 0 1 2 3 1268 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 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Action Type (2 octets) | Length (2 octets) | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 ~ Action Values (Variable) ~ 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Action Fields Format 1277 Action Type: The Action Type field contains a value of 1-65534. The 1278 values 0 and 65535 are reserved for future use. 1280 Action Length: The Action Length field represents the total length of 1281 the Action Values in octets. 1283 Action Values: The Action Values field contain parameters of the 1284 action. 1286 Supported format of the TLVs can be: 1288 Type TBD7: Add AS Path, which indicates to add the sequence of AS 1289 numbers represented in the TLV to AS Path. Its TLV (or Sub-TLV) 1290 format is illustrated below: 1292 0 1 2 3 1293 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 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Type (TBD7) | Length (Variable) | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | OP | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | AS1 | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Count1 | 1302 +-+-+-+-+-+-+-+-+ 1303 ~ . . . 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | ASn | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Countn | 1308 +-+-+-+-+-+-+-+-+ 1310 Format of Add AS Path TLV 1312 When OP = 1, the sequence of AS numbers are added in the end of the 1313 existing AS Path. When OP = 2, the sequence of AS numbers are added 1314 in the front of the existing AS Path. 1316 Type TBD8: Change Med, which indicates to change the Med according to 1317 OP. Its TLV (or Sub-TLV) format is illustrated below: 1319 0 1 2 3 1320 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 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Type (TBD8) | Length (5) | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | OP | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Value | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 Format of Change Med TLV 1331 When OP = 1, assign the Value to the existing Med. When OP = 2, add 1332 the Value to the existing Med. If the sum of them is greater than 1333 the maximum value for Med, assign the maximum value to Med. When OP 1334 = 3, subtract the Value from the existing Med. If the existing Med 1335 minus the Value is less than 0, assign 0 to Med. 1337 Type TBD9: Deny, which indicates Deny action. Its TLV (or Sub-TLV) 1338 format is illustrated below: 1340 0 1 2 3 1341 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 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Type (TBD9) | Length (0) | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 Format of Atom Deny 1348 A.3. Application Examples 1350 A.3.1. Change Attributes 1352 Multiple attributes of a route may be changed when it matches given 1353 matching criteria. In the example below, the policy has the 1354 following matching criteria: 1356 o match 20.20.15.0/20 to 20.20.15.0/24 1358 o match as-path 6553601 6553601 1360 The actions to be applied are add 12345 to the existing MED and add 1361 AS sequence 123456, 6553602, 6553602 to the end of existing AS Path. 1362 These actions are listed as follows: 1364 o apply MED = MED + 12345 1366 o apply add as-path 123456, 6553602, 6553602 1368 The corresponding BGP Policy Attribute Encoding for these is 1369 illustrated below. 1371 0 1 2 3 1372 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 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | MatchType: 1 | Length: 20 | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 |PrefxRange:TBD3 | Length: 6 | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 | Flags (0) | MaskLen: 20 | LeMaskLen: 24 |IPv4 Prefix:20.| 1379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 |20.15 | 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | AS Path: TBD5 | Length: 6 | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | OP: 1 | AS 6553601 | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | AS-Contiue | Count 2 | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 |ActionType: 3 | Length: 24 | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 |Change MED: TBD8 | Length: 5 | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | OP: 2 | Value: 12345 | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 |Value-Contiue | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 |Add AS Path: TBD7 | Length: 11 | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | OP: 1 | AS 123456 | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | AS-Contiue | Count 1 | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | AS 6553602 | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Count 2 | 1405 +-+-+-+-+-+-+-+-+ 1407 Example BGP Policy Attribute Encoding for Change Attributes 1409 A.3.2. Inbound Traffic Control 1411 The traffic destined for Prefix1 needs to be scheduled to link 1412 Speaker1 -> IGW2 for transmission. 1414 The Policy Controller constructs a BGP-FS RPD route and pushes it to 1415 all the IGW routers, the route carries: 1417 1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI; 1418 2. Flow Specification Traffic Action Extended Community with the 1419 Routing Policy Distribution (R) Flag (Bit 45) set. When this bit 1420 is set, the corresponding filtering rules will be used as Routing 1421 Policies. 1423 3. NO_ADVERTISE Community [RFC1997] 1425 4. BGP Policy Attribute: 1427 * Match Type: 2, Deny 1429 * IPv4 Session Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer 1430 Speaker1 1432 * Action Type: Route-Prepend-AS 1434 * Action Value: Prepend-AS times is 5 1436 IGW1 processes the received BGP-FS RPD route as follows: 1438 1. IGW1 gets the target prefix Prefix1 from the Destination Prefix 1439 component in the BGP FS NLRI of the BGP FS RPD route; 1441 2. IGW1 identifies the Routing Policy Distribution (R) Flag carrying 1442 in the Flow Specification Traffic Action Extended Community, then 1443 IGW1 knows that the corresponding filtering rules will be used as 1444 Routing Policies. 1446 3. IGW1 uses the target prefix Prefix1 to choose the matching 1447 routes, in this case, IGW1 will choose the current best route of 1448 Prefix1; 1450 4. IGW1 gets the matching criteria from the BGP Policy Attribute: 1451 Local BGP Speaker IGW2, Remote BGP Speaker1; 1453 5. IGW1 gets the action from the BGP Policy Attribute: Route- 1454 Prepend-AS, 5 times; 1456 IGW1 checks the matching criteria and finds that it doesn't hits the 1457 matching criteria: Local BGP Speaker IGW2, Remote BGP Speaker1, at 1458 the same time the Match Type is "Deny" mode, so IGW1 sends the best 1459 route of Prefix1 to Speaker1 and Speaker2 with performing the Action 1460 instructions from the BGP-FS RPD route: Prepend Local AS 5 times. 1462 IGW2 processes the received BGP FS RPD route as follows: 1464 1. IGW2 gets the target prefix Prefix1 from the Destination Prefix 1465 component in the BGP-FS NLRI of the BGP FS RPD route; 1467 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying 1468 in the Flow Specification Traffic Action Extended Community, then 1469 IGW2 knows that the corresponding filtering rules will be used as 1470 Routing Policies. 1472 3. IGW2 uses the target prefix Prefix1 to choose the matching 1473 routes, in this case, IGW2 will choose the current best route of 1474 Prefix1; 1476 4. IGW2 gets the matching criteria from the BGP Policy Attribute: 1477 Local BGP Speaker IGW2, Remote BGP Speaker1; 1479 5. IGW2 gets the action from the BGP Policy Attribute: Route- 1480 Prepend-AS, 5 times; 1482 IGW2 checks the matching criteria and finds that there is a speaker 1483 which hits the matching criteria: Local BGP Speaker IGW2, Remote BGP 1484 Peer Speaker1, but the Match Type is "Deny" mode, so IGW2 sends the 1485 best route of Prefix1 to Speaker1, without performing the Action 1486 instructions from the BGP-FS RPD route. At the same time, IGW2 sends 1487 the best route of Prefix1 to Speaker2 with performing the Action 1488 instructions from the BGP-FS RPD route: Prepend Local AS 5 times. 1490 In the similar manner, other IGWs will perform the same Action 1491 instructions as IGW1. Then the traffic destined for Prefix1 has been 1492 be scheduled to link L3 for transmission. 1494 A.3.3. Outbound Traffic Control 1496 In this scenario, if the bandwidth usage of a link exceeds the 1497 specified threshold, the Policy Controller automatically identifies 1498 which traffic needs to be scheduled and the Policy Controller 1499 automatically calculates traffic control paths based on network 1500 topology and traffic information. 1502 For example, the outbound traffic destined for Prefix2 needs to be 1503 scheduled to link IGW2 -> Speaker1 for transmission. 1505 The Policy Controller sends a BGP-FS RPD route to IGW2, the route 1506 carries: 1508 1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI; 1510 2. Flow Specification Traffic Action Extended Community with the 1511 Routing Policy Distribution (R) Flag (Bit 45) set. When this bit 1512 is set, the corresponding filtering rules will be used as Routing 1513 Policies. 1515 3. NO_ADVERTISE Community [RFC1997] 1517 4. BGP Policy Attribute: 1519 * Match Type: 1, Permit 1521 * IPv4 Session Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer 1522 Speaker1 1524 * Action Type: Route-Preference 1526 * Action Value: none 1528 IGW2 processes the received BGP FS RPD route as follows: 1530 1. IGW2 gets the target prefix Prefix2 from the Destination Prefix 1531 component in the BGP-FS NLRI of the BGP FS RPD route; 1533 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying 1534 in the Flow Specification Traffic Action Extended Community, then 1535 IGW2 knows that the corresponding filtering rules will be used as 1536 Routing Policies. 1538 3. IGW2 uses the target prefix Prefix2 to choose the matching 1539 routes, in this case, the prefix Prefix2 has two more routes: 1541 Prefix Next-Hop Local BGP Speaker Remote BGP Peer 1542 Prefix2 Speaker1 IGW2 Speaker1 1543 Prefix2 Speaker2 IGW2 Speaker2 1544 ... 1546 4. IGW2 gets the matching criteria from the BGP Policy Attribute: 1547 Local BGP Speaker IGW2, Remote BGP Peer Speaker1; 1549 5. IGW2 gets the action from the BGP Policy Attribute: Route- 1550 Preference; 1552 So IGW2 chooses the BGP route received from Speaker1 instead of 1553 Speaker2 as the best route and the outbound traffic destined for 1554 Prefix2 can be scheduled to link L3 for transmission. 1556 Authors' Addresses 1557 Zhenbin Li 1558 Huawei 1559 Huawei Bld., No.156 Beiqing Rd. 1560 Beijing 100095 1561 China 1563 Email: lizhenbin@huawei.com 1565 Liang Ou 1566 China Telcom Co., Ltd. 1567 109 West Zhongshan Ave,Tianhe District 1568 Guangzhou 510630 1569 China 1571 Email: oul@gsta.com 1573 Yujia Luo 1574 China Telcom Co., Ltd. 1575 109 West Zhongshan Ave,Tianhe District 1576 Guangzhou 510630 1577 China 1579 Email: luoyuj@gsta.com 1581 Sujian Lu 1582 Tencent 1583 Tengyun Building,Tower A ,No. 397 Tianlin Road 1584 Shanghai, Xuhui District 200233 1585 China 1587 Email: jasonlu@tencent.com 1589 Huaimo Chen 1590 Huawei 1591 Boston, MA 1592 USA 1594 Email: Huaimo.chen@huawei.com 1595 Shunwan Zhuang 1596 Huawei 1597 Huawei Bld., No.156 Beiqing Rd. 1598 Beijing 100095 1599 China 1601 Email: zhuangshunwan@huawei.com 1603 Haibo Wang 1604 Huawei 1605 Huawei Bld., No.156 Beiqing Rd. 1606 Beijing 100095 1607 China 1609 Email: rainsword.wang@huawei.com