idnits 2.17.1 draft-li-idr-flowspec-rpd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 14 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2018) is 2013 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 1565, 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 (~~), 5 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: April 25, 2019 Y. Luo 6 China Telcom Co., Ltd. 7 S. Lu 8 Tencent 9 H. Chen 10 S. Zhuang 11 N. Wu 12 Huawei 13 October 22, 2018 15 BGP FlowSpec Extensions for Routing Policy Distribution (RPD) 16 draft-li-idr-flowspec-rpd-03 18 Abstract 20 This document describes a mechanism to use BGP Flowspec address 21 family as routing-policy distribution protocol. This mechanism is 22 called BGP FlowSpec Extensions for Routing Policy Distribution (BGP- 23 FS RPD). 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 25, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 67 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 4 69 3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 5 70 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 72 5.1. Traffic Actions for Routing Policy Distribution . . . . . 7 73 5.2. Option 1: BGP Policy Attribute . . . . . . . . . . . . . 7 74 5.2.1. Match Fields . . . . . . . . . . . . . . . . . . . . 8 75 5.2.2. Action Fields . . . . . . . . . . . . . . . . . . . . 13 76 5.2.3. Application Examples . . . . . . . . . . . . . . . . 15 77 5.3. Option 2: BGP Wide Community . . . . . . . . . . . . . . 19 78 5.3.1. New Wide Community Atoms . . . . . . . . . . . . . . 20 79 5.3.2. New Wide Community Actions . . . . . . . . . . . . . 26 80 5.3.3. Application Examples . . . . . . . . . . . . . . . . 27 81 5.4. Capability Negotiation . . . . . . . . . . . . . . . . . 34 82 6. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 34 83 6.1. Route-Policy . . . . . . . . . . . . . . . . . . . . . . 34 84 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 90 11.2. Informative References . . . . . . . . . . . . . . . . . 37 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 93 1. Introduction 95 It is difficult to optimize traffic paths on a traditional IP network 96 because of: 98 o Heavy configuration and error prone. Traffic can only be adjusted 99 device by device. All routers that the traffic traverses need to 100 be configured. The configuration workload is heavy. The 101 operation is not only time consuming but also prone to 102 misconfiguration for Service Providers. 104 o Complex. The routing policies used to control network routes are 105 complex, posing difficulties to subsequent maintenance, high 106 maintenance skills are required. 108 It is desirable to have an automatic mechanism for setting up routing 109 policies, which can simplify the routing policies configuration. 110 This document describes extensions to BGP for Routing Policy 111 Distribution. 113 2. Definitions and Acronyms 115 BGP Flow Specification route: BGP Flow Specification routes are 116 defined in RFC 5575. Each BGP Flow Specification route contains BGP 117 Network Layer Reachability Information (NLRI) and Extended Community 118 Attributes, which carry traffic filtering rules and actions to be 119 taken on filtered traffic. 121 BGP Flow Specification peer relationship: A BGP Flow Specification 122 peer relationship is established between the device that generates 123 BGP Flow Specification routes and each network ingress that will 124 transmit the BGP Flow Specification routes. After receiving the BGP 125 Flow Specification routes, the peer delivers preferred BGP Flow 126 Specification routes to the forwarding plane. The routes are then 127 converted into traffic policies that control attack traffic. 129 o ACL:Access Control List 131 o BGP: Border Gateway Protocol 133 o FS: Flow Specification 135 o PBR:Policy-Based Routing 137 o RPD: Routing Policy Distribution 139 o VPN: Virtual Private Network 141 3. Problem Statements 143 It is obvious that providers have the requirements to adjust their 144 business traffic from time to time because: 146 o Business development or network failure introduces link congestion 147 and overload. 149 o Network transmission quality is decreased as the result of delay, 150 loss and they need to adjust traffic to other paths. 152 o To control OPEX and CPEX, prefer the transit provider with lower 153 price. 155 3.1. Inbound Traffic Control 157 In the scenario below, for the reasons above, the provider of AS100 158 saying P may wish the inbound traffic from AS200 enters AS100 through 159 link L3 instead of the others. Since P doesn't have any 160 administration over AS200, so there is no way for P to modify the 161 route selection criteria directly. 163 Traffic from PE1 to Prefix1 164 -----------------------------------> 166 +-----------------+ +-------------------------+ 167 | +---------+ | L1 | +----+ +----------+| 168 | |Speaker1 | +------------+ |IGW1| |policy || 169 | +---------+ |** L2**| +----+ |controller|| 170 | | ** ** | +----------+| 171 | +---+ | **** | | 172 | |PE1| | **** | | 173 | +---+ | ** ** | | 174 | +---------+ |** L3**| +----+ | 175 | |Speaker2 | +------------+ |IGW2| AS100 | 176 | +---------+ | L4 | +----+ | 177 | | | | 178 | AS200 | | | 179 | | | ... | 180 | | | | 181 | +---------+ | | +----+ +-------+ | 182 | |Speakern | | | |IGWn| |Prefix1| | 183 | +---------+ | | +----+ +-------+ | 184 +-----------------+ +-------------------------+ 186 Prefix1 advertised from AS100 to AS200 187 <---------------------------------------- 189 Inbound Traffic Control case 191 3.2. Outbound Traffic Control 193 In the scenario below, the provider of AS100 saying P prefers link L3 194 for the traffic to the destination Prefix2 among multiple exits and 195 links. This preference can be dynamic and changed frequently because 196 of the reasons above. So the provider P expects an efficient and 197 convenient solution. 199 Traffic from PE2 to Prefix2 200 -----------------------------------> 201 +-------------------------+ +-----------------+ 202 |+----------+ +----+ |L1 | +---------+ | 203 ||policy | |IGW1| +------------+ |Speaker1 | | 204 ||controller| +----+ |** **| +---------+ | 205 |+----------+ |L2** ** | +-------+| 206 | | **** | |Prefix2|| 207 | | **** | +-------+| 208 | |L3** ** | | 209 | AS100 +----+ |** **| +---------+ | 210 | |IGW2| +------------+ |Speaker2 | | 211 | +----+ |L4 | +---------+ | 212 | | | | 213 |+---+ | | AS200 | 214 ||PE2| ... | | | 215 |+---+ | | | 216 | +----+ | | +---------+ | 217 | |IGWn| | | |Speakern | | 218 | +----+ | | +---------+ | 219 +-------------------------+ +-----------------+ 221 Prefix2 advertised from AS200 to AS100 222 <---------------------------------------- 224 Outbound Traffic Control case 226 4. Proposed Solution 228 BGP FlowSpec [RFC5575] leverages the BGP control plane to simplify 229 the distribution of filter rules. New filter rules can be injected 230 to all BGP peers simultaneously without changing router 231 configuration. Its typical application is for DDOS mitigation. 233 This document introduces a mechanism that uses BGP Flowspec as a 234 routing policy distribution protocol. It can be as powerful as the 235 device-based routing policy while still has the efficiency and 236 convenience of BGP Flowspec. 238 This draft will use the term BGP-FS RPD (or BGP RPD for short) as the 239 abbreviation of BGP Extensions for Routing Policy Distribution. 241 5. Protocol Extensions 242 5.1. 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). This document defines Routing Policy 248 Distribution (RPD, or R for short) Flag (Bit 45). The 6th byte with 249 this newly defined flag is illustrated below: 251 40 41 42 43 44 45 46 47 252 +---+---+---+---+---+---+---+---+ 253 | reserved | R | S | T | 254 +---+---+---+---+---+---+---+---+ 256 Traffic-action with RPD (R) flag 258 RPD (R) Flag (Bit 45): When this bit is set, the corresponding 259 filtering rules will be used as Routing Policy. 261 5.2. Option 1: BGP Policy Attribute 263 This document defines and uses a new BGP attribute called the "BGP 264 Policy attribute". This is an optional BGP attribute. The format of 265 this attribute is defined as follows: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Attr Flag |Attr Type(TBD) | Attr Length ~ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 ~ Match fields (Variable) ~ 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | | 277 ~ Action fields (Variable) ~ 278 | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Format of BGP Policy Attribute 283 Match fields: Match Fields define the matching criteria for the BGP 284 Policy Attribute. 286 Action fields: Action fields define the action being applied to the 287 target route. 289 5.2.1. Match Fields 291 Match Fields define the matching criteria for the BGP Policy 292 Attribute. It has the following format: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Match Type (2 octets) | Length (2 octets) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ~ Sub-TLVs (Variable) ~ 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Match Fields Format 304 Match Type: 306 1: Permit, specifies the permit mode of a match rule. If a route 307 matches the matching criteria of the BGP Policy Attribute, the 308 actions defined by the Action fields of the BGP Policy Attribute are 309 performed. If a route does not match the matching criteria for the 310 BGP Policy Attribute, then nothing needs to be done with this route. 312 2: Deny, specifies the deny mode of a match rule. In the deny mode, 313 If a route does not match the matching criteria of the BGP Policy 314 Attribute, the actions defined by the Action fields of the BGP Policy 315 Attribute are performed. If a route matches the matching criteria of 316 the BGP Policy Attribute, then nothing needs to be done with this 317 route. 319 Length: The total length of the Sub-TLVs in the Match fields. 321 The contents of Match fields are encoded as Sub-TLVs, where each Sub- 322 TLV has the following format: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type (2 octets) | Length (2 octets) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 ~ Values (Variable) ~ 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Sub-TLV Format 334 Type: The Type field contains a value of 1-65534. The values 0 and 335 65535 are reserved for future use. 337 Length: The Length field represents the total length of a given TLV's 338 value field in octets. 340 Values: The Value field contains the TLV value. 342 The following TLVs are defined: 344 Type TBD1: BGP IPv4 Session (or IPv4 Session for short), whose TLV 345 contains the IPv4 local address/speaker and remote address/speaker of 346 a BGP session. Its TLV (or Sub-TLV) 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 (TBD1) | Length (8) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Local IPv4 Address | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Remote IPv4 Address | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Format of IPv4 Session TLV 360 Type TBD2: BGP IPv6 Session (or IPv6 Session for short), whose TLV 361 contains the IPv6 local address/speaker and remote address/speaker of 362 a BGP session. Its TLV (or Sub-TLV) format is illustrated below: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type (TBD2) | Length (32) | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 ~ Local IPv6 Address (16 Bytes) ~ 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 ~ Remote IPv6 Address (16 Bytes) ~ 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Format of IPv6 Session TLV 376 Type TBD3: IPv4 Prefix Range, which represents a range of IPv4 377 prefixes. Its format is illustrated below: 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Type (TBD3) | Length (Variable) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Flags | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | IPv4 Address | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | MaskLen | LeMaskLen | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 ~ . . . 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | IPv4 Address | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | MaskLen | LeMaskLen | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Format of IPv4 Prefix Range TLV 399 The IPv4 Prefix Range TLV (or Sub-TLV) contains a number of triple 400 s. Each triple represents an IPv4 prefix range from IPv4- 402 Address/MaskLen to IPv4-Address/LeMaskLen. For example, triple 403 <10.10.0.0, 16, 16> represents prefixes 10.10.0.0/16 (i.e., from 404 10.10.0.0/16 to 10.10.0.0/16). Triple <20.20.15.0, 20, 24> 405 represents prefixes from 20.20.15.0/20 to 20.20.15.0/24. 407 The encoding of IPv4 Prefix Range may be optimized to the following 408 compact format: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type (TBD3) | Length (Variable) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Flags | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | MaskLen | LeMaskLen | IPv4 Prefix ~ 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 ~ . . . 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | MaskLen | LeMaskLen | IPv4 Prefix ~ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Compact Format of IPv4 Prefix Range TLV 426 It contains a number of triple s. 427 Each triple represents an IPv4 428 prefix range from IPv4-Prefix/MaskLen to IPv4-Prefix/LeMaskLen. 429 LeMaskLen is the length of the prefix. For example, triple <16, 16, 430 10.10.0.0> represents prefixes 10.10.0.0/16 (i.e., from 10.10.0.0/16 431 to 10.10.0.0/16). Triple <20, 24, 20.20.15.0> represents prefixes 432 from 20.20.15.0/20 to 20.20.15.0/24. 434 Similarly, Type TBD4: IPv6 Prefix Range represents a range of IPv6 435 prefixes. Its format is illustrated below: 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Type (TBD4) | Length (Variable) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Flags | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 ~ IPv6 Address (16 Bytes) ~ 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | MaskLen | LeMaskLen | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 ~ . . . 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 ~ IPv6 Address (16 Bytes) ~ 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | MaskLen | LeMaskLen | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Format of IPv6 Prefix Range TLV 457 The encoding of IPv6 Prefix Range may be optimized to the following 458 compact format: 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type (TBD4) | Length (Variable) | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Flags | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | MaskLen | LeMaskLen | IPv6 Prefix ~ 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 ~ . . . 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | MaskLen | LeMaskLen | IPv6 Prefix ~ 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Compact Format of IPv6 Prefix Range TLV 476 Type TBD5: AS Path, which represents a sequence of AS numbers. For 477 an AS number occurs multiple times in a row in a path, it is 478 represented by the AS number and a count indicating the times that 479 the AS number occurs. Its format is illustrated below: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type (TBD5) | Length (Variable) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Flags | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | AS1 | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Count1 | 491 +-+-+-+-+-+-+-+-+ 492 ~ . . . 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | ASn | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Countn | 497 +-+-+-+-+-+-+-+-+ 499 Format of AS Path TLV 501 For example, AS Path "123456, 6553603, 6553603, 6553603" is 502 represented by AS1 = 123456, Count1 = 1, AS2 = 6553603, and Count2 = 503 3. 505 Type TBD6: Communities, which represents a list of communities 506 values. Its format is illustrated below: 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type (TBD6) | Length (Variable) | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Flags | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Community 1 Value | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 ~ . . . ~ 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Community n Value | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Format of Communities TLV 524 5.2.2. Action Fields 526 Action fields define the action being applied to the targeted route. 527 It has the following format. 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Action Type (2 octets) | Length (2 octets) | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 ~ Action Values (Variable) ~ 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Action Fields Format 539 Action Type: The Action Type field contains a value of 1-65534. The 540 values 0 and 65535 are reserved for future use. 542 Action Length: The Action Length field represents the total length of 543 the Action Values in octets. 545 Action Values: The Action Values field contain parameters of the 546 action. 548 Supported format of the TLVs can be: 550 Type TBD7: Add AS Path, which indicates to add the sequence of AS 551 numbers represented in the TLV to AS Path. Its TLV (or Sub-TLV) 552 format is illustrated below: 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type (TBD7) | Length (Variable) | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | OP | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | AS1 | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Count1 | 564 +-+-+-+-+-+-+-+-+ 565 ~ . . . 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | ASn | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Countn | 570 +-+-+-+-+-+-+-+-+ 572 Format of Add AS Path TLV 574 When OP = 1, the sequence of AS numbers are added in the end of the 575 existing AS Path. When OP = 2, the sequence of AS numbers are added 576 in the front of the existing AS Path. 578 Type TBD8: Change Med, which indicates to change the Med according to 579 OP. Its TLV (or Sub-TLV) format is illustrated below: 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type (TBD8) | Length (5) | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | OP | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Value | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Format of Change Med TLV 593 When OP = 1, assign the Value to the existing Med. When OP = 2, add 594 the Value to the existing Med. If the sum of them is greater than 595 the maximum value for Med, assign the maximum value to Med. When OP 596 = 3, subtract the Value from the existing Med. If the existing Med 597 minus the Value is less than 0, assign 0 to Med. 599 Type TBD9: Deny, which indicates Deny action. Its TLV (or Sub-TLV) 600 format is illustrated below: 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Type (TBD9) | Length (0) | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Format of Atom Deny 610 5.2.3. Application Examples 612 5.2.3.1. Change Attributes 614 Multiple attributes of a route may be changed when it matches given 615 matching criteria. In the example below, the policy has the 616 following matching criteria: 618 o match 20.20.15.0/20 to 20.20.15.0/24 620 o match as-path 6553601 6553601 622 The actions to be applied are add 12345 to the existing MED and add 623 AS sequence 123456, 6553602, 6553602 to the end of existing AS Path. 624 These actions are listed as follows: 626 o apply MED = MED + 12345 628 o apply add as-path 123456, 6553602, 6553602 630 The corresponding BGP Policy Attribute Encoding for these is 631 illustrated below. 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | MatchType: 1 | Length: 20 | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 |PrefxRange:TBD3 | Length: 6 | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Flags (0) | MaskLen: 20 | LeMaskLen: 24 |IPv4 Prefix:20.| 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 |20.15 | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | AS Path: TBD5 | Length: 6 | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | OP: 1 | AS 6553601 | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | AS-Contiue | Count 2 | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 |ActionType: 3 | Length: 24 | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 |Change MED: TBD8 | Length: 5 | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | OP: 2 | Value: 12345 | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 |Value-Contiue | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 |Add AS Path: TBD7 | Length: 11 | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | OP: 1 | AS 123456 | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | AS-Contiue | Count 1 | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | AS 6553602 | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Count 2 | 667 +-+-+-+-+-+-+-+-+ 669 Example BGP Policy Attribute Encoding for Change Attributes 671 5.2.3.2. Inbound Traffic Control 673 The traffic destined for Prefix1 needs to be scheduled to link 674 Speaker1 -> IGW2 for transmission. 676 The Policy Controller constructs a BGP-FS RPD route and pushes it to 677 all the IGW routers, the route carries: 679 1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI; 680 2. Flow Specification Traffic Action Extended Community with the 681 Routing Policy Distribution (R) Flag (Bit 45) set. When this bit 682 is set, the corresponding filtering rules will be used as Routing 683 Policies. 685 3. NO_ADVERTISE Community [RFC1997] 687 4. BGP Policy Attribute: 689 * Match Type: 2, Deny 691 * IPv4 Session Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer 692 Speaker1 694 * Action Type: Route-Prepend-AS 696 * Action Value: Prepend-AS times is 5 698 IGW1 processes the received BGP-FS RPD route as follows: 700 1. IGW1 gets the target prefix Prefix1 from the Destination Prefix 701 component in the BGP FS NLRI of the BGP FS RPD route; 703 2. IGW1 identifies the Routing Policy Distribution (R) Flag carrying 704 in the Flow Specification Traffic Action Extended Community, then 705 IGW1 knows that the corresponding filtering rules will be used as 706 Routing Policies. 708 3. IGW1 uses the target prefix Prefix1 to choose the matching 709 routes, in this case, IGW1 will choose the current best route of 710 Prefix1; 712 4. IGW1 gets the matching criteria from the BGP Policy Attribute: 713 Local BGP Speaker IGW2, Remote BGP Speaker1; 715 5. IGW1 gets the action from the BGP Policy Attribute: Route- 716 Prepend-AS, 5 times; 718 IGW1 checks the matching criteria and finds that it doesn't hits the 719 matching criteria: Local BGP Speaker IGW2, Remote BGP Speaker1, at 720 the same time the Match Type is "Deny" mode, so IGW1 sends the best 721 route of Prefix1 to Speaker1 and Speaker2 with performing the Action 722 instructions from the BGP-FS RPD route: Prepend Local AS 5 times. 724 IGW2 processes the received BGP FS RPD route as follows: 726 1. IGW2 gets the target prefix Prefix1 from the Destination Prefix 727 component in the BGP-FS NLRI of the BGP FS RPD route; 729 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying 730 in the Flow Specification Traffic Action Extended Community, then 731 IGW2 knows that the corresponding filtering rules will be used as 732 Routing Policies. 734 3. IGW2 uses the target prefix Prefix1 to choose the matching 735 routes, in this case, IGW2 will choose the current best route of 736 Prefix1; 738 4. IGW2 gets the matching criteria from the BGP Policy Attribute: 739 Local BGP Speaker IGW2, Remote BGP Speaker1; 741 5. IGW2 gets the action from the BGP Policy Attribute: Route- 742 Prepend-AS, 5 times; 744 IGW2 checks the matching criteria and finds that there is a speaker 745 which hits the matching criteria: Local BGP Speaker IGW2, Remote BGP 746 Peer Speaker1, but the Match Type is "Deny" mode, so IGW2 sends the 747 best route of Prefix1 to Speaker1, without performing the Action 748 instructions from the BGP-FS RPD route. At the same time, IGW2 sends 749 the best route of Prefix1 to Speaker2 with performing the Action 750 instructions from the BGP-FS RPD route: Prepend Local AS 5 times. 752 In the similar manner, other IGWs will perform the same Action 753 instructions as IGW1. Then the traffic destined for Prefix1 has been 754 be scheduled to link L3 for transmission. 756 5.2.3.3. Outbound Traffic Control 758 In this scenario, if the bandwidth usage of a link exceeds the 759 specified threshold, the Policy Controller automatically identifies 760 which traffic needs to be scheduled and the Policy Controller 761 automatically calculates traffic control paths based on network 762 topology and traffic information. 764 For example, the outbound traffic destined for Prefix2 needs to be 765 scheduled to link IGW2 -> Speaker1 for transmission. 767 The Policy Controller sends a BGP-FS RPD route to IGW2, the route 768 carries: 770 1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI; 772 2. Flow Specification Traffic Action Extended Community with the 773 Routing Policy Distribution (R) Flag (Bit 45) set. When this bit 774 is set, the corresponding filtering rules will be used as Routing 775 Policies. 777 3. NO_ADVERTISE Community [RFC1997] 779 4. BGP Policy Attribute: 781 * Match Type: 1, Permit 783 * IPv4 Session Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer 784 Speaker1 786 * Action Type: Route-Preference 788 * Action Value: none 790 IGW2 processes the received BGP FS RPD route as follows: 792 1. IGW2 gets the target prefix Prefix2 from the Destination Prefix 793 component in the BGP-FS NLRI of the BGP FS RPD route; 795 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying 796 in the Flow Specification Traffic Action Extended Community, then 797 IGW2 knows that the corresponding filtering rules will be used as 798 Routing Policies. 800 3. IGW2 uses the target prefix Prefix2 to choose the matching 801 routes, in this case, the prefix Prefix2 has two more routes: 803 Prefix Next-Hop Local BGP Speaker Remote BGP Peer 804 Prefix2 Speaker1 IGW2 Speaker1 805 Prefix2 Speaker2 IGW2 Speaker2 806 ... 808 4. IGW2 gets the matching criteria from the BGP Policy Attribute: 809 Local BGP Speaker IGW2, Remote BGP Peer Speaker1; 811 5. IGW2 gets the action from the BGP Policy Attribute: Route- 812 Preference; 814 So IGW2 chooses the BGP route received from Speaker1 instead of 815 Speaker2 as the best route and the outbound traffic destined for 816 Prefix2 can be scheduled to link L3 for transmission. 818 5.3. Option 2: BGP Wide Community 820 The BGP wide community is defined in 821 [I-D.ietf-idr-wide-bgp-communities]. It can be used to facilitate 822 the delivery of new network services, and be extended easily for 823 distributing different kinds of routing policies. 825 This section describes an alternative extension to BGP protocol, 826 which extends the BGP wide community for distributing routing 827 policies. A few of new wide community atoms and new actions are 828 defined below. 830 5.3.1. New Wide Community Atoms 832 A wide community Atom is a TLV (or sub-TLV), which may be included in 833 a BGP wide community container (or BGP wide community for short). 834 The format of the TLV (or sub-TLV) and 8 wide community Atoms are 835 defined in [I-D.ietf-idr-wide-bgp-communities]. 3 new wide community 836 Atoms will be defined in this document. For your reference, the 837 format of the TLV is illustrated below: 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+ 842 | Type | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Length | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Value (variable) | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Format of Wide Community Atom TLV 851 Some of the existing 8 wide community Atoms (from Type 1 to 8) and 9 852 new wide community Atoms (from TBD1 to TBD9) are listed as follows: 854 +------+---------------------------------------------------------+ 855 | Type | Description | 856 +------+---------------------------------------------------------+ 857 | 1 | Autonomous System Number List | 858 | 2 | IPv4 Prefix (1 octet prefix length + prefix) List | 859 | . | . | 860 | : | : | 861 | 8 | UTF-8 String | 862 | TBD1 | BGP IPv4 Session (local address and remote address) | 863 | TBD2 | BGP IPv6 Session (local address and remote address) | 864 | TBD3 | IPv4 Prefix Range | 865 | TBD4 | IPv6 Prefix Range | 866 | TBD5 | AS Path | 867 | TBD6 | Communities | 868 | TBD7 | Add AS-Path | 869 | TBD8 | Change MED | 870 | TBD9 | Deny | 871 +------+---------------------------------------------------------+ 873 Existing and New Wide Community Atoms 875 The wide community Atom BGP IPv4 Session contains the IPv4 local 876 address and remote address of a BGP session. Its format is 877 illustrated below: 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+ 882 | Type (TBD1) | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Length (8) | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Local IPv4 Address | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Remote IPv4 Address | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 Format of Atom BGP IPv4 Session 893 The wide community Atom BGP IPv6 Session contains the IPv6 local 894 address and remote address of a BGP session. Its format is 895 illustrated below: 897 0 1 2 3 898 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 899 +-+-+-+-+-+-+-+-+ 900 | Type (TBD2) | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Length (32) | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 ~ Local IPv6 Address (16 bytes) ~ 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 ~ Remote IPv6 Address (16 bytes) ~ 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Format of Atom BGP IPv6 Session 911 The wide community Atom IPv4 Prefix Range represents a range of IPv4 912 prefixes. Its format is illustrated below: 914 0 1 2 3 915 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 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Type (TBD3) | Length (Variable) | Flags | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | IPv4 Address | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | MaskLen | LeMaskLen | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 ~ . . . 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | IPv4 Address | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | MaskLen | LeMaskLen | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Format of Atom IPv4 Prefix Range 932 It contains a number of triple s. 933 Each triple represents an IPv4 934 prefix range from IPv4-Address/MaskLen to IPv4-Address/LeMaskLen. 935 For example, triple <10.10.0.0, 16, 16> represents prefixes 936 10.10.0.0/16 (i.e., from 10.10.0.0/16 to 10.10.0.0/16). Triple 937 <20.20.15.0, 20, 24> represents prefixes from 20.20.15.0/20 to 938 20.20.15.0/24. Note that MaskLen must be less than or equal to 939 LeMaskLen except for LeMaskLen = 0, in this case, triple 940 represents prefix IPv4-Address/MaskLen. 942 The encoding of Atom IPv4 Prefix Range may be optimized as the format 943 below: 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Type (TBD3) | Length (Variable) | Flags | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | MaskLen | LeMaskLen | IPv4 Prefix ~ 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 ~ . . . 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | MaskLen | LeMaskLen | IPv4 Prefix ~ 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 Compact Format of Atom IPv4 Prefix Range 959 It contains a number of triple s. 960 Each triple represents an IPv4 961 prefix range from IPv4-Prefix/MaskLen to IPv4-Prefix/LeMaskLen. 962 LeMaskLen is the length of the prefix. For example, triple <16, 16, 963 10.10.0.0> represents prefixes 10.10.0.0/16 (i.e., from 10.10.0.0/16 964 to 10.10.0.0/16). Triple <20, 24, 20.20.15.0> represents prefixes 965 from 20.20.15.0/20 to 20.20.15.0/24 967 Similarly, the wide community Atom IPv6 Prefix Range represents a 968 range of IPv6 prefixes. Its format is illustrated below: 970 0 1 2 3 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Type (TBD4) | Length (Variable) | Flags | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 ~ IPv6 Address (16 bytes) ~ 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | MaskLen | LeMaskLen | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 ~ . . . 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 ~ IPv6 Address (16 bytes) ~ 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | MaskLen | LeMaskLen | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Format of Atom IPv6 Prefix Range 988 The encoding of Atom IPv6 Prefix Range may be optimized as the format 989 below: 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Type (TBD4) | Length (Variable) | Flags | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | MaskLen | LeMaskLen | IPv6 Prefix ~ 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 ~ . . . 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | MaskLen | LeMaskLen | IPv6 Prefix ~ 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 Compact Format of Atom IPv6 Prefix Range 1005 The wide community Atom AS Path represents a sequence of AS numbers. 1006 For an AS number occurs multiple times in a row in a path, it is 1007 represented by the AS number and a count indicating the times that 1008 the AS number occurs. Its format is illustrated below: 1010 0 1 2 3 1011 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 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Type (TBD5) | Length (Variable) | Flags | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | AS1 | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Count1 | 1018 +-+-+-+-+-+-+-+-+ 1019 ~ . . . 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | ASn | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Countn | 1024 +-+-+-+-+-+-+-+-+ 1026 Format of Atom AS Path 1028 For example, AS Path "123456, 6553603, 6553603, 6553603" is 1029 represented by AS1 = 123456, Count1 = 1, AS2 = 6553603, and Count2 = 1030 3. 1032 The wide community Atom Communities represents a list of communities 1033 values. Its format is illustrated below: 1035 0 1 2 3 1036 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 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Type (TBD6) | Length (Variable) | Flags | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Community 1 Value | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 ~ . . . ~ 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Community n Value | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 Format of Atom Communities 1049 The wide community Atom Add AS Path indicates to add the sequence of 1050 AS numbers represented in the Atom to AS Path. Its format is 1051 illustrated below: 1053 0 1 2 3 1054 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 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Type (TBD7) | Length (Variable) | OP | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | AS1 | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Count1 | 1061 +-+-+-+-+-+-+-+-+ 1062 ~ . . . 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | ASn | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Countn | 1067 +-+-+-+-+-+-+-+-+ 1069 Format of Atom Add AS Path 1071 When OP = 1, the sequence of AS numbers are added in the end of the 1072 existing AS Path. When OP = 2, the sequence of AS numbers are added 1073 in the front of the existing AS Path. 1075 The wide community Atom Change Med indicates to change the Med 1076 according to OP. Its format is illustrated below: 1078 0 1 2 3 1079 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 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Type (TBD8) | Length (5) | OP | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Value | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Format of Atom Change Med 1088 When OP = 1, assign the Value to the existing Med. When OP = 2, add 1089 the Value to the existing Med. If the sum of them is greater than 1090 the maximum value for Med, assign the maximum value to Med. When OP 1091 = 3, subtract the Value from the existing Med. If the existing Med 1092 minus the Value is less than 0, assign 0 to Med. 1094 The wide community Atom Deny indicates Deny action. Its format is 1095 illustrated below: 1097 0 1 2 3 1098 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 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Type (TBD9) | Length (0) | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 Format of Atom Deny 1105 5.3.2. New Wide Community Actions 1107 A Registered Wide BGP Community Value may indicate an action. For 1108 example, value 17 indicates "PREPEND N TIMES BY AS" as defined in 1109 draft [I-D.ietf-idr-registered-wide-bgp-communities]. 2 new values 1110 for actions are defined in this document. Some of the existing 1111 values (from 1 to 24) and the two new values are listed below: 1113 +-------+-------------------------------------------------------+ 1114 | Value | Description | 1115 +-------+-------------------------------------------------------+ 1116 | 1 | BLACKHOLE | 1117 | 2 | SOURCE FILTER | 1118 | . | . | 1119 | : | : | 1120 | 24 | FREE POOL | 1121 | TBD11 | change attributes | 1122 | TBD12 | no advertise | 1123 +-------+-------------------------------------------------------+ 1125 Existing and New Wide Communities Values 1127 When action "change attributes" is used, multiple attributes can be 1128 changed. The parameters and operations for the action are 1129 represented by the Atoms related to the operations. These Atoms are 1130 included in a BGP Wide Community Parameter(s) TLV. The Atoms may be 1131 "Add AS-Path" and "Change MED". 1133 5.3.3. Application Examples 1135 5.3.3.1. Change Attributes 1137 Multiple attributes of a route may be changed when it matches given 1138 criteria. In the example below, the policy has the following 1139 matching criteria: 1141 o match 20.20.15.0/20 to 20.20.15.0/24 1143 o match as-path 6553601 6553601 1145 The actions to be applied are add 12345 to the existing MED and add 1146 AS sequence 123456, 6553602, 6553602, 6553602, 6553602 to the end of 1147 existing AS Path. These actions are listed as follows: 1149 o apply MED = MED + 12345 1151 o apply add as-path 123456, 6553602, 6553602, 6553602, 6553602 1153 The corresponding BGP Wide Community Encoding for these is 1154 illustrated below. 1156 0 1 2 3 1157 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 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Container Type: 1 |Flags |0|1| Reserved(0) | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Length: 71 | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Community: Change Attributes TBD11 | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Source AS 64496 | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Context AS 64496 | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | Target TLV: 1 | Length: 18 | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 |PrefxRange:TBD3| Length: 6 | Flags (0) | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | MaskLen: 20 | LeMaskLen: 24 |IPv4 Prefix: 20.20. | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 |.15 | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | AS Path: TBD5 | Length: 6 | OP: 1 | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | AS 6553601 | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Count 2 | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 |ExcTargetTLV: 2| Length: 0 | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 |Param TLV: 3| Length: 32 | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 |ChangeMED: TBD8| Length: 5 | OP: 2 | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | Value: 12345 | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 |AddASPath: TBD7| Length: 11 | OP: 1 | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | AS 123456 | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | Count 1 | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | AS 6553602 | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Count 4 | 1200 +-+-+-+-+-+-+-+-+ 1202 Example BGP Wide Community Encoding for Change Attributes 1204 5.3.3.2. Inbound Traffic Control 1206 As required in the case, traffic from PE1 to Prefix1 need to enter 1207 through L3, so IGWs except IGW2 should prepend ASN list to Prefix1 1208 when populating to AS100. As shown in figure below, community 1209 "PREPEND N TIMES BY AS" and "Exclude Target(s) TLV" are be used. 1211 The encoding example using BGP Wide Community: 1213 0 1 2 3 1214 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 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | Container Type: 1 |Flags |0|1| Reserved(0) | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | Length: 36 | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | Community: PREPEND N TIMES BY AS 17 | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | Source AS 100 | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Context AS 100 | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 |ExcTargetTLV: 2| Length: 11 | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 |IPv4Sess: TBD1 | Length: 8 | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Local Address/Speaker #IGW2 | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Remote Address/Speaker #Speaker1 | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Param TLV: 3 | Length: 7 | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Integer: 4 | Length: 4 | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Prepend # 5 | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 Example encoding for Inbound Traffic Control case 1243 "PREPEND N TIMES BY AS" Wide Community has been defined in 1244 [I-D.ietf-idr-registered-wide-bgp-communities]. 1246 The traffic destined for Prefix1 needs to be scheduled to link 1247 Speaker1 -> IGW2 for transmission. 1249 The Policy Controller constructs a BGP RPD route and pushes it to all 1250 the IGW routers, the route carries: 1252 1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI; 1254 2. Flow Specification Traffic Action Extended Community with the 1255 Routing Policy Distribution (R) Flag (Bit 45) set. When this bit 1256 is set, the corresponding filtering rules will be used as Routing 1257 Policies. 1259 3. NO_ADVERTISE Community [RFC1997] 1261 4. Wide BGP Community Attribute: 1263 PREPEND N TIMES BY AS: 1264 Type: 0x0001 S = src AS # 1265 F = 0x80 C = 0x00000000 1266 H = 0 T = none 1267 L = 36 octets E = Type_TBD (BGP IPv4 session) 1268 R = 17 P = Type_4 (0x05) 1270 Where "BGP IPv4 session" Atom TLV contains: 1271 The BGP session IPv4 local address: Local BGP Speaker IGW2 1272 The BGP session IPv4 peer address: Remote BGP Peer Speaker1 1274 IGW1 processes the received BGP-FS RPD route as follows: 1276 1. IGW1 gets the target prefix Prefix1 from the Destination Prefix 1277 component in the BGP FS NLRI of the BGP FS RPD route; 1279 2. IGW1 identifies the Routing Policy Distribution (R) Flag carrying 1280 in the Flow Specification Traffic Action Extended Community, then 1281 IGW1 knows that the corresponding filtering rules will be used as 1282 Routing Policies. 1284 3. IGW1 uses the target prefix Prefix1 to choose the matching 1285 routes, in this case, IGW1 will choose the current best route of 1286 Prefix1; 1288 4. IGW1 gets the action type from the Wide BGP Community Attribute: 1289 PREPEND N TIMES BY AS; 1291 5. IGW1 gets the matching criteria from the Wide BGP Community 1292 Attribute: Exclude the BGP IPv4 session: ; 1295 6. IGW1 gets the parameter for "PREPEND N TIMES BY AS" from the Wide 1296 BGP Community Attribute: 5 times; 1298 IGW1 checks the matching criteria and finds that it doesn't hits the 1299 exclude matching criteria: Local BGP Speaker IGW2, Remote BGP 1300 Speaker1, so IGW1 sends the best route of Prefix1 to Speaker1 and 1301 Speaker2 with performing the Action instructions from the BGP-FS RPD 1302 route: Prepend Local AS 5 times. 1304 IGW2 processes the received BGP FS RPD route as follows: 1306 1. IGW2 gets the target prefix Prefix1 from the Destination Prefix 1307 component in the BGP-FS NLRI of the BGP FS RPD route; 1309 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying 1310 in the Flow Specification Traffic Action Extended Community, then 1311 IGW2 knows that the corresponding filtering rules will be used as 1312 Routing Policies. 1314 3. IGW2 uses the target prefix Prefix1 to choose the matching 1315 routes, in this case, IGW2 will choose the current best route of 1316 Prefix1; 1318 4. IGW2 gets the action type from the Wide BGP Community Attribute: 1319 PREPEND N TIMES BY AS; 1321 5. IGW2 gets the matching criteria from the BGP Policy Attribute: 1322 Exclude the BGP IPv4 session: ; 1325 6. IGW2 gets the parameter for "PREPEND N TIMES BY AS" from the Wide 1326 BGP Community Attribute: 5 times; 1328 IGW2 checks the matching criteria and finds that there is a speaker 1329 which hits the exclude matching criteria: Local BGP Speaker IGW2, 1330 Remote BGP Peer Speaker1, so IGW2 sends the best route of Prefix1 to 1331 Speaker1 without performing the Action instructions from the BGP-FS 1332 RPD route, at the same time, IGW2 sends the best route of Prefix1 to 1333 Speaker2 with performing the Action instructions from the BGP-FS RPD 1334 route: Prepend Local AS 5 times. 1336 In the similar manner, other IGWs will perform the same Action 1337 instructions as IGW1. Then the traffic destined for Prefix1 has been 1338 be scheduled to link L3 for transmission. 1340 5.3.3.3. Outbound Traffic Control 1342 As required in the case, traffic from PE2 to Prefix2 need to exit 1343 through L3, so IGWs should prefer the route from IGW2 to Speaker1. 1344 As shown in figure below, community "LOCAL PREFERENCE" and "Target(s) 1345 TLV" are be used. 1347 The encoding example using BGP Wide Community: 1349 0 1 2 3 1350 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 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Container Type: 1 |Flags |0|1| Reserved(0) | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | Length: 36 | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | Community: LOCAL PREFERENCE 20 | 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Source AS 100 | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | Context AS 100 | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 | TargetTLV: 1 | Length: 11 | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | IPv4Sess:TBD1| Length: 8 | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | Local Address/Speaker #IGW2 | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Remote Address/Speaker #Speaker1 | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Param TLV: 3 | Length: 7 | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Integer: 4 | Length: 4 | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | Increment # 100 | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 Example encoding for Outbound Traffic Control case 1379 "LOCAL PREFERENCE" Wide Community has been defined in 1380 [I-D.ietf-idr-registered-wide-bgp-communities]. 1382 In this scenario, if the bandwidth usage of a link exceeds the 1383 specified threshold, the Policy Controller automatically identifies 1384 which traffic needs to be scheduled and the Policy Controller 1385 automatically calculates traffic control paths based on network 1386 topology and traffic information. 1388 For example, the outbound traffic destined for Prefix2 needs to be 1389 scheduled to link IGW2 -> Speaker1 for transmission. 1391 The Policy Controller sends a BGP-FS RPD route to IGW2, the route 1392 carries: 1394 1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI; 1395 2. Flow Specification Traffic Action Extended Community with the RPD 1396 (R) Flag (Bit 45) set. When this bit is set, the corresponding 1397 filtering rules will be used as Routing Policies. 1399 3. NO_ADVERTISE Community [RFC1997] 1401 4. Wide BGP Community Attribute: 1403 LOCAL PREFERENCE: 1404 Type: 0x0001 S = src AS # 1405 F = 0x80 C = 0x00000000 1406 H = 0 T = Type_TBD (BGP IPv4 session) 1407 L = 36 octets E = none 1408 R = 20 P = Type_4 (0x64) 1410 Where "BGP IPv4 session" Atom TLV contains: 1411 The BGP session IPv4 local address: Local BGP Speaker IGW2 1412 The BGP session IPv4 peer address: Remote BGP Peer Speaker1 1414 IGW2 processes the received BGP FS RPD route as follows: 1416 1. IGW2 gets the target prefix Prefix2 from the Destination Prefix 1417 component in the BGP-FS NLRI of the BGP FS RPD route; 1419 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying 1420 in the Flow Specification Traffic Action Extended Community, then 1421 IGW2 knows that the corresponding filtering rules will be used as 1422 Routing Policies. 1424 3. IGW2 uses the target prefix Prefix2 to choose the matching 1425 routes, in this case, the prefix Prefix2 has two more routes: 1427 Prefix Next-Hop Local BGP Speaker Remote BGP Peer 1428 -------------------------------------------------------- 1429 Prefix2 Speaker1 IGW2 Speaker1 1430 Prefix2 Speaker2 IGW2 Speaker2 1431 ... 1433 4. IGW2 gets the action type from the Wide BGP Community Attribute: 1434 LOCAL PREFERENCE; 1436 5. IGW2 gets the matching criteria from the Wide BGP Community 1437 Attribute: Local BGP Speaker IGW2, Remote BGP Peer Speaker1; 1439 6. IGW2 gets the parameter for "LOCAL PREFERENCE" from the Wide BGP 1440 Community Attribute: increment 100; 1442 So IGW2 chooses the BGP route received from Speaker1 instead of 1443 Speaker2 as the best route and the outbound traffic destined for 1444 Prefix2 can be scheduled to link L3 for transmission. 1446 5.4. Capability Negotiation 1448 It is necessary to negotiate the capability to support BGP Extensions 1449 for Routing Policy Distribution (RPD). The BGP RPD Capability is a 1450 new BGP capability [RFC5492]. The Capability Code for this 1451 capability is to be specified by the IANA. The Capability Length 1452 field of this capability is variable. The Capability Value field 1453 consists of one or more of the following tuples: 1455 +--------------------------------------------------+ 1456 | Address Family Identifier (2 octets) | 1457 +--------------------------------------------------+ 1458 | Subsequent Address Family Identifier (1 octet) | 1459 +--------------------------------------------------+ 1460 | Send/Receive (1 octet) | 1461 +--------------------------------------------------+ 1463 BGP RPD Capability 1465 The meaning and use of the fields are as follows: 1467 Address Family Identifier (AFI): This field is the same as the one 1468 used in [RFC4760]. 1470 Subsequent Address Family Identifier (SAFI): This field is the same 1471 as the one used in [RFC4760]. 1473 Send/Receive: This field indicates whether the sender is (a) willing 1474 to receive Routing Policies from its peer (value 1), (b) would like 1475 to send Routing Policies to its peer (value 2), or (c) both (value 3) 1476 for the . 1478 6. Consideration 1480 6.1. Route-Policy 1482 Routing policies are used to filter routes and control how routes are 1483 received and advertised. If route attributes, such as reachability, 1484 are changed, the path along which network traffic passes changes 1485 accordingly. 1487 When advertising, receiving, and importing routes, the router 1488 implements certain policies based on actual networking requirements 1489 to filter routes and change the attributes of the routes. Routing 1490 policies serve the following purposes: 1492 o Control route advertising: Only routes that match the rules 1493 specified in a policy are advertised. 1495 o Control route receiving: Only the required and valid routes are 1496 received. This reduces the size of the routing table and improves 1497 network security. 1499 o Filter and control imported routes: A routing protocol may import 1500 routes discovered by other routing protocols. Only routes that 1501 satisfy certain conditions are imported to meet the requirements 1502 of the protocol. 1504 o Modify attributes of specified routes Attributes of the routes: 1505 that are filtered by a routing policy are modified to meet the 1506 requirements of the local device. 1508 o Configure fast reroute (FRR): If a backup next hop and a backup 1509 outbound interface are configured for the routes that match a 1510 routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be 1511 implemented. 1513 Routing policies are implemented using the following procedures: 1515 1. Define rules: Define features of routes to which routing policies 1516 are applied. Users define a set of matching rules based on 1517 different attributes of routes, such as the destination address 1518 and the address of the router that advertises the routes. 1520 2. Implement the rules: Apply the matching rules to routing policies 1521 for advertising, receiving, and importing routes. 1523 7. Contributors 1525 The following people have substantially contributed to the definition 1526 of the BGP-FS RPD and to the editing of this document: 1528 Peng Zhou 1529 Huawei 1530 Email: Jewpon.zhou@huawei.com 1532 8. IANA Considerations 1534 TBD. 1536 9. Security Considerations 1538 TBD. 1540 10. Acknowledgements 1542 The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong, 1543 Haibo Wang, Lucy Yong, Qiandeng Liang, Zhenqiang Li for their 1544 comments to this work. 1546 11. References 1548 11.1. Normative References 1550 [I-D.ietf-idr-wide-bgp-communities] 1551 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 1552 and P. Jakma, "BGP Community Container Attribute", draft- 1553 ietf-idr-wide-bgp-communities-05 (work in progress), July 1554 2018. 1556 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 1557 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 1558 . 1560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1561 Requirement Levels", BCP 14, RFC 2119, 1562 DOI 10.17487/RFC2119, March 1997, 1563 . 1565 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1566 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1567 DOI 10.17487/RFC4271, January 2006, 1568 . 1570 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1571 "Multiprotocol Extensions for BGP-4", RFC 4760, 1572 DOI 10.17487/RFC4760, January 2007, 1573 . 1575 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 1576 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 1577 2009, . 1579 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 1580 and D. McPherson, "Dissemination of Flow Specification 1581 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 1582 . 1584 11.2. Informative References 1586 [I-D.ietf-idr-registered-wide-bgp-communities] 1587 Raszuk, R. and J. Haas, "Registered Wide BGP Community 1588 Values", draft-ietf-idr-registered-wide-bgp-communities-02 1589 (work in progress), May 2016. 1591 Authors' Addresses 1593 Zhenbin Li 1594 Huawei 1595 Huawei Bld., No.156 Beiqing Rd. 1596 Beijing 100095 1597 China 1599 Email: lizhenbin@huawei.com 1601 Liang Ou 1602 China Telcom Co., Ltd. 1603 109 West Zhongshan Ave,Tianhe District 1604 Guangzhou 510630 1605 China 1607 Email: oul@gsta.com 1609 Yujia Luo 1610 China Telcom Co., Ltd. 1611 109 West Zhongshan Ave,Tianhe District 1612 Guangzhou 510630 1613 China 1615 Email: luoyuj@gsta.com 1617 Sujian Lu 1618 Tencent 1619 Tengyun Building,Tower A ,No. 397 Tianlin Road 1620 Shanghai, Xuhui District 200233 1621 China 1623 Email: jasonlu@tencent.com 1624 Huaimo Chen 1625 Huawei 1626 Boston, MA 1627 USA 1629 Email: Huaimo.chen@huawei.com 1631 Shunwan Zhuang 1632 Huawei 1633 Huawei Bld., No.156 Beiqing Rd. 1634 Beijing 100095 1635 China 1637 Email: zhuangshunwan@huawei.com 1639 Nan Wu 1640 Huawei 1641 Huawei Bld., No.156 Beiqing Rd. 1642 Beijing 100095 1643 China 1645 Email: eric.wu@huawei.com