idnits 2.17.1 draft-ietf-idr-rpd-07.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 8 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 (August 3, 2020) is 1360 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: 'RFC1997' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-registered-wide-bgp-communities' is defined on line 759, 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 (~~), 6 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: February 4, 2021 Y. Luo 6 China Telcom Co., Ltd. 7 S. Lu 8 Tencent 9 G. Mishra 10 Verizon Inc. 11 H. Chen 12 Futurewei 13 S. Zhuang 14 H. Wang 15 Huawei 16 August 3, 2020 18 BGP Extensions for Routing Policy Distribution (RPD) 19 draft-ietf-idr-rpd-07 21 Abstract 23 It is hard to adjust traffic and optimize traffic paths in a 24 traditional IP network from time to time through manual 25 configurations. It is desirable to have a mechanism for setting up 26 routing policies, which adjusts traffic and optimizes traffic paths 27 automatically. This document describes BGP Extensions for Routing 28 Policy Distribution (BGP RPD) to support this. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119] [RFC8174] 35 when, and only when, they appear in all capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on February 4, 2021. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 74 3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 4 75 3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 4 76 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 77 4.1. Using a New AFI and SAFI . . . . . . . . . . . . . . . . 5 78 4.2. BGP Wide Community and Atoms . . . . . . . . . . . . . . 6 79 4.2.1. RouteAttr TLV/sub-TLV . . . . . . . . . . . . . . . . 7 80 4.2.2. Sub-TLVs of the Parameters TLV . . . . . . . . . . . 10 81 4.3. Capability Negotiation . . . . . . . . . . . . . . . . . 12 82 5. Routing Policy Considerations . . . . . . . . . . . . . . . . 13 83 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 87 9.1. Existing Assignments . . . . . . . . . . . . . . . . . . 14 88 9.2. Routing Policy Type Registry . . . . . . . . . . . . . . 14 89 9.3. RouteAttr Atom Type . . . . . . . . . . . . . . . . . . . 15 90 9.4. Route Attributes Sub-TLV Registry . . . . . . . . . . . . 15 91 9.5. Attribute Change Sub-TLV Registry . . . . . . . . . . . . 16 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 94 10.2. Informative References . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 It is difficult to optimize traffic paths in a traditional IP network 100 because of the following: 102 o Heavy and error prone configuration. Traffic can only be adjusted 103 device by device. All routers that the traffic traverses need to 104 be configured. The configuration workload is heavy. The 105 operation is not only time consuming but also prone to 106 misconfiguration for Service Providers. 108 o Complex. The routing policies used to control network routes are 109 complex, posing difficulties to subsequent maintenance. High 110 maintenance skills are required. 112 It is desirable to have an automatic mechanism for setting up routing 113 policies, which can simplify routing policy configuration. This 114 document describes extensions to BGP for Routing Policy Distribution 115 to resolve these issues. 117 2. Terminology 119 The following terminology is used in this document. 121 o ACL: Access Control List 123 o BGP: Border Gateway Protocol [RFC4271] 125 o FS: Flow Specification 127 o NLRI: Network Layer Reachability Information [RFC4271] 129 o PBR: Policy-Based Routing 131 o RPD: Routing Policy Distribution 133 o VPN: Virtual Private Network 135 3. Problem Statement 137 Providers have the requirement to adjust their business traffic 138 routing policies from time to time because of the following: 140 o Business development or network failure introduces link congestion 141 and overload. 143 o Business changes or network additions produce unused resources 144 such as idle links. 146 o Network transmission quality is decreased as the result of delay, 147 loss and they need to adjust traffic to other paths. 149 o To control OPEX and CPEX, they may prefer the transit provider 150 with lower price. 152 3.1. Inbound Traffic Control 154 In Figure 1, for the reasons above, the provider P of AS100 may wish 155 the inbound traffic from AS200 to enter AS100 through link L3 instead 156 of the others. Since P doesn't have any administrative control over 157 AS200, there is no way for P to directly modify the route selection 158 criteria inside AS200. 160 Traffic from PE1 to Prefix1 161 -----------------------------------> 163 +-----------------+ +-------------------------+ 164 | +---------+ | L1 | +----+ +----------+| 165 | |Speaker1 | +------------+ |IGW1| |policy || 166 | +---------+ |** L2**| +----+ |controller|| 167 | | ** ** | +----------+| 168 | +---+ | **** | | 169 | |PE1| | **** | | 170 | +---+ | ** ** | | 171 | +---------+ |** L3**| +----+ | 172 | |Speaker2 | +------------+ |IGW2| AS100 | 173 | +---------+ | L4 | +----+ | 174 | | | | 175 | AS200 | | | 176 | | | ... | 177 | | | | 178 | +---------+ | | +----+ +-------+ | 179 | |Speakern | | | |IGWn| |Prefix1| | 180 | +---------+ | | +----+ +-------+ | 181 +-----------------+ +-------------------------+ 183 Prefix1 advertised from AS100 to AS200 184 <---------------------------------------- 186 Figure 1: Inbound Traffic Control case 188 3.2. Outbound Traffic Control 190 In Figure 2, the provider P of AS100 prefers link L3 for the traffic 191 to the destination Prefix2 among multiple exits and links to AS200. 192 This preference can be dynamic and might change frequently because of 193 the reasons above. So, provider P expects an efficient and 194 convenient solution. 196 Traffic from PE2 to Prefix2 197 -----------------------------------> 198 +-------------------------+ +-----------------+ 199 |+----------+ +----+ |L1 | +---------+ | 200 ||policy | |IGW1| +------------+ |Speaker1 | | 201 ||controller| +----+ |** **| +---------+ | 202 |+----------+ |L2** ** | +-------+| 203 | | **** | |Prefix2|| 204 | | **** | +-------+| 205 | |L3** ** | | 206 | AS100 +----+ |** **| +---------+ | 207 | |IGW2| +------------+ |Speaker2 | | 208 | +----+ |L4 | +---------+ | 209 | | | | 210 |+---+ | | AS200 | 211 ||PE2| ... | | | 212 |+---+ | | | 213 | +----+ | | +---------+ | 214 | |IGWn| | | |Speakern | | 215 | +----+ | | +---------+ | 216 +-------------------------+ +-----------------+ 218 Prefix2 advertised from AS200 to AS100 219 <---------------------------------------- 221 Figure 2: Outbound Traffic Control case 223 4. Protocol Extensions 225 This document specifies a solution using a new AFI and SAFI with the 226 BGP Wide Community for encoding a routing policy. 228 4.1. Using a New AFI and SAFI 230 A new AFI and SAFI are defined: the Routing Policy AFI whose 231 codepoint 16398 has been assigned by IANA, and SAFI whose codepoint 232 75 has been assigned by IANA. 234 The AFI and SAFI pair uses a new NLRI, which is defined as follows: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+ 239 | NLRI Length | 240 +-+-+-+-+-+-+-+-+ 241 | Policy Type | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Distinguisher (4 octets) | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Peer IP (4/16 octets) ~ 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Where: 250 NLRI Length: 1 octet represents the length of NLRI. If the Length 251 is anything other than 9 or 21, the NLRI is corrupt and the 252 enclosing UPDATE message is ignored. 254 Policy Type: 1 octet indicates the type of a policy. 1 is for 255 export policy. 2 is for import policy. If the Policy Type is any 256 other value, the NLRI is corrupt and the enclosing UPDATE message 257 is ignored. 259 Distinguisher: 4 octet value uniquely identifies the policy in the 260 peer. 262 Peer IP: 4/16 octet value indicates an IPv4/IPv6 peer. 264 The NLRI containing the Routing Policy is carried in MP_Reach_NLRI 265 and MP_UNREACH_NLRI path attributes in a BGP UPDATE message, which 266 MUST also contain the BGP mandatory attributes and MAY contain some 267 BGP optional attributes. 269 When receiving a BGP UPDATE message with routing policy, a BGP 270 speaker processes it only if the peer IP address in the NLRI is 0 or 271 the IP address of the BGP speaker. 273 The content of the Routing Policy is encoded in a BGP Wide Community. 275 4.2. BGP Wide Community and Atoms 277 The BGP wide community is defined in 278 [I-D.ietf-idr-wide-bgp-communities]. It can be used to facilitate 279 the delivery of new network services and be extended easily for 280 distributing different kinds of routing policies. 282 A wide community Atom is a TLV (or sub-TLV), which may be included in 283 a BGP wide community container (or BGP wide community for short) 284 containing some BGP Wide Community TLVs. Three BGP Wide Community 285 TLVs are defined in [I-D.ietf-idr-wide-bgp-communities], which are 286 BGP Wide Community Target(s) TLV, Exclude Target(s) TLV, and 287 Parameter(s) TLV. The value of each of these TLVs comprises a series 288 of Atoms, each of which is a TLV (or sub-TLV). A new wide community 289 Atom is defined for BGP Wide Community Target(s) TLV and a few new 290 Atoms are defined for BGP Wide Community Parameter(s) TLV. For your 291 reference, the format of the TLV is illustrated below: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Value (variable) ~ 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Format of Wide Community Atom TLV 303 4.2.1. RouteAttr TLV/sub-TLV 305 A RouteAttr Atom TLV (or RouteAttr TLV/sub-TLV for short) is defined 306 and may be included in a Target TLV. It has the following format. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type (TBD1) | Length (variable) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | sub-TLVs ~ 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Format of RouteAttr Atom TLV 318 The Type for RouteAttr is TBD1. In RouteAttr TLV, four sub-TLVs are 319 defined: IPv4 Prefix, IPv6 Prefix, AS-Path, and Community sub-TLV. 321 An IP prefix sub-TLV gives matching criteria on IPv4 prefixes. Its 322 format is illustrated below: 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 1 | Length (N x 8) |M-Type | Flags | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | IPv4 Address | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Mask | GeMask | LeMask |M-Type | Flags | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 ~ . . . 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | IPv4 Address | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Mask | GeMask | LeMask | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Format of IPv4 Prefix sub-TLV 342 Type: 1 for IPv4 Prefix. 344 Length: N x 8, where N is the number of tuples . If Length is not a multiple of 8, 346 the Atom is corrupt and the enclosing UPDATE message MUST be 347 ignored. 349 M-Type: 4 bits for match types, four of which are defined: 351 M-Type = 0: Exact match. 353 M-Type = 1: Match prefix greater and equal to the given masks. 355 M-Type = 2: Match prefix less and equal to the given masks. 357 M-Type = 3: Match prefix within the range of the given masks. 359 Flags: 4 bits. No flags are currently defined. 361 IPv4 Address: 4 octets for an IPv4 address. 363 Mask: 1 octet for the mask length. 365 GeMask: 1 octet for match range, must be less than Mask or be 0. 367 LeMask: 1 octet for match range, must be greater than Mask or be 0. 369 For example, tuple represents an exact IP prefix match for 371 1.1.0.0/22. 373 represents match IP prefix 1.1.0.0/24 greater-equal 24. 376 represents match IP prefix 17.1.0.0/24 less-equal 26. 379 represents match IP prefix 18.1.0.0/24 greater-equal to 381 24 and less-equal 32. 383 Similarly, an IPv6 Prefix sub-TLV represents match criteria on IPv6 384 prefixes. Its format is illustrated below: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type 4 | Length (N x 20) |M-Type | Flags | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | IPv6 Address (16 octets) ~ 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Mask | GeMask | LeMask |M-Type | Flags | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 ~ . . . 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | IPv6 Address (16 octets ~ 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Mask | GeMask | LeMask | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Format of IPv6 Prefix sub-TLV 404 An AS-Path sub-TLV represents a match criteria in a regular 405 expression string. Its format is illustrated below: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type 2 | Length (Variable) | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | AS-Path Regex String | 413 : : 414 | ~ 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Format of AS Path sub-TLV 419 Type: 2 for AS-Path. 421 Length: Variable, maximum is 1024. 423 AS-Path Regex String: AS-Path regular expression string. 425 A community sub-TLV represents a list of communities to be matched 426 all. Its format is illustrated below: 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Type 3 | Length (N x 4 + 1) | Flags | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Community 1 Value | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 ~ . . . ~ 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Community N Value | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Format of Community sub-TLV 442 Type: 3 for Community. 444 Length: N x 4 + 1, where N is the number of communities. If Length 445 is not a multiple of 4 plus 1, the Atom is corrupt and the 446 enclosing UPDATE MUST be ignored. 448 Flags: 1 octet. No flags are currently defined. These bits MUST be 449 sent as zero and ignored on receipt. 451 4.2.2. Sub-TLVs of the Parameters TLV 453 For the Parameter(s) TLV, two action sub-TLVs are defined: MED change 454 sub-TLV and AS-Path change sub-TLV. When the community in the 455 container is MATCH AND SET ATTR, the Parameter(s) TLV can include 456 these sub-TLVs. When the community is MATCH AND NOT ADVERTISE, the 457 Parameter(s) TLV's value is empty. 459 A MED change sub-TLV indicates an action to change the MED. Its 460 format is illustrated below: 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type 1 | Length (5) | OP | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Value | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Format of MED Change sub-TLV 472 Type: 1 for MED Change. 474 Length: 5. If Length is any other value, the sub-TLV is corrupt and 475 the enclosing UPDATE MUST be ignored. 477 OP: 1 octet. Three are defined: 479 OP = 0: assign the Value to the existing MED. 481 OP = 1: add the Value to the existing MED. If the sum is greater 482 than the maximum value for MED, assign the maximum value to 483 MED. 485 OP = 2: subtract the Value from the existing MED. If the 486 existing MED minus the Value is less than 0, assign 0 to MED. 488 If OP is any other value, the sub-TLV is ignored. 490 Value: 4 octets. 492 An AS-Path change sub-TLV indicates an action to change the AS-Path. 493 Its format is illustrated below: 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Type 2 | Length (n x 5) | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | AS1 | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Count1 | 503 +-+-+-+-+-+-+-+-+ 504 ~ . . . 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | ASn | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Countn | 509 +-+-+-+-+-+-+-+-+ 511 Format of AS-Path Change sub-TLV 513 Type: 2 for AS-Path Change. 515 Length: n x 5. If Length is not a multiple of 5, the sub-TLV is 516 corrupt and the enclosing UPDATE MUST be ignored. 518 ASi: 4 octet. An AS number. 520 Counti: 1 octet. ASi repeats Counti times. 522 The sequence of AS numbers are added to the existing AS Path. 524 4.3. Capability Negotiation 526 It is necessary to negotiate the capability to support BGP Extensions 527 for Routing Policy Distribution (RPD). The BGP RPD Capability is a 528 new BGP capability [RFC5492]. The Capability Code for this 529 capability is 72 assigned by the IANA. The Capability Length field 530 of this capability is variable. The Capability Value field consists 531 of one or more of the following tuples: 533 +--------------------------------------------------+ 534 | Address Family Identifier (2 octets) | 535 +--------------------------------------------------+ 536 | Subsequent Address Family Identifier (1 octet) | 537 +--------------------------------------------------+ 538 | Send/Receive (1 octet) | 539 +--------------------------------------------------+ 541 BGP RPD Capability 543 The meaning and use of the fields are as follows: 545 Address Family Identifier (AFI): This field is the same as the one 546 used in [RFC4760]. 548 Subsequent Address Family Identifier (SAFI): This field is the same 549 as the one used in [RFC4760]. 551 Send/Receive: This field indicates whether the sender is (a) willing 552 to receive Routing Policies from its peer (value 1), (b) would like 553 to send Routing Policies to its peer (value 2), or (c) both (value 3) 554 for the . If Send/Receive is any other value, that tuple 555 is ignored but any other tuples present are still used. 557 5. Routing Policy Considerations 559 Routing policies are used to filter routes and control how routes are 560 received and advertised. If route attributes, such as reachability, 561 are changed, the path along which network traffic passes changes 562 accordingly. 564 When advertising, receiving, and importing routes, the router 565 implements certain policies based on actual networking requirements 566 to filter routes and change the attributes of the routes. Routing 567 policies serve the following purposes: 569 o Control route advertising: Only routes that match the rules 570 specified in a policy are advertised. 572 o Control route receiving: Only the required and valid routes are 573 received. This reduces the size of the routing table and improves 574 network security. 576 o Filter and control imported routes: A routing protocol may import 577 routes discovered by other routing protocols. Only routes that 578 satisfy certain conditions are imported to meet the requirements 579 of the protocol. 581 o Modify attributes of specified routes Attributes of the routes: 582 that are filtered by a routing policy are modified to meet the 583 requirements of the local device. 585 o Configure fast reroute (FRR): If a backup next hop and a backup 586 outbound interface are configured for the routes that match a 587 routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be 588 implemented. 590 Routing policies are implemented using the following procedures: 592 1. Define rules: Define features of routes to which routing policies 593 are applied. Users define a set of matching rules based on 594 different attributes of routes, such as the destination address 595 and the address of the router that advertises the routes. 597 2. Implement the rules: Apply the matching rules to routing policies 598 for advertising, receiving, and importing routes. 600 6. Contributors 602 The following people have substantially contributed to the definition 603 of the BGP-FS RPD and to the editing of this document: 605 Peng Zhou 606 Huawei 607 Email: Jewpon.zhou@huawei.com 609 7. Security Considerations 611 Protocol extensions defined in this document do not affect BGP 612 security other than as discussed in the Security Considerations 613 section of [RFC5575]. 615 8. Acknowledgements 617 The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong, 618 Lucy Yong, Qiandeng Liang, Zhenqiang Li, and Donald Eastlake for 619 their comments to this work. 621 9. IANA Considerations 623 9.1. Existing Assignments 625 IANA has assigned a new AFI of value 16398 from the registry "Address 626 Family Numbers" for Routing Policy. 628 IANA has assigned a new SAFI of value 75 from the registry 629 "Subsequent Address Family Identifiers (SAFI) Parameters" for Routing 630 Policy. 632 IANA has assigned a new Code Point of value 72 from the registry 633 "Capability Codes" for Routing Policy Distribution. 635 9.2. Routing Policy Type Registry 637 IANA is requested to create a new registry called "Routing Policy 638 Type". The allocation policy of this registry is "First Come First 639 Served (FCFS)". 641 The initial code points are as follows: 643 +-------------+-----------------------------------+-------------+ 644 | Code Point | Description | Reference | 645 +-------------+-----------------------------------+-------------+ 646 | 0 | Reserved | | 647 +-------------+-----------------------------------+-------------+ 648 | 1 | Export Policy |This document| 649 +-------------+-----------------------------------+-------------+ 650 | 2 | Import Policy |This document| 651 +-------------+-----------------------------------+-------------+ 652 | 3 - 255 | Available | | 653 +-------------+-----------------------------------+-------------+ 655 9.3. RouteAttr Atom Type 657 IANA is requested to assign a code-point from the registry "BGP 658 Community Container Atom Types" as follows: 660 +---------------------+------------------------------+-------------+ 661 | TLV Code Point | Description | Reference | 662 +---------------------+------------------------------+-------------+ 663 | TBD1 (48 suggested) | RouteAttr Atom |This document| 664 +---------------------+------------------------------+-------------+ 666 9.4. Route Attributes Sub-TLV Registry 668 IANA is requested to create a new registry called "Route Attributes 669 Sub-TLV" under RouteAttr Atom TLV. The allocation policy of this 670 registry is "First Come First Served (FCFS)". 672 The initial code points are as follows: 674 +-------------+-----------------------------------+-------------+ 675 | Code Point | Description | Reference | 676 +-------------+-----------------------------------+-------------+ 677 | 0 | Reserved | | 678 +-------------+-----------------------------------+-------------+ 679 | 1 | IPv4 Prefix Sub-TLV |This document| 680 +-------------+-----------------------------------+-------------+ 681 | 2 | AS-Path Sub-TLV |This document| 682 +-------------+-----------------------------------+-------------+ 683 | 3 | Community Sub-TLV |This document| 684 +-------------+-----------------------------------+-------------+ 685 | 4 | IPv6 Prefix Sub-TLV |This document| 686 +-------------+-----------------------------------+-------------+ 687 | 5 - 255 | Available | | 688 +-------------+-----------------------------------+-------------+ 690 9.5. Attribute Change Sub-TLV Registry 692 IANA is requested to create a new registry called "Attribute Change 693 Sub-TLV" under Parameter(s) TLV. The allocation policy of this 694 registry is "First Come First Served (FCFS)". 696 Initial code points are as follows: 698 +-------------+-----------------------------------+-------------+ 699 | Code Point | Description | Reference | 700 +-------------+-----------------------------------+-------------+ 701 | 0 | Reserved | | 702 +-------------+-----------------------------------+-------------+ 703 | 1 | MED Change Sub-TLV |This document| 704 +-------------+-----------------------------------+-------------+ 705 | 2 | AS-Path Change Sub-TLV |This document| 706 +-------------+-----------------------------------+-------------+ 707 | 3 - 255 | Available | | 708 +-------------+-----------------------------------+-------------+ 710 10. References 712 10.1. Normative References 714 [I-D.ietf-idr-wide-bgp-communities] 715 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 716 and P. Jakma, "BGP Community Container Attribute", draft- 717 ietf-idr-wide-bgp-communities-05 (work in progress), July 718 2018. 720 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 721 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 722 . 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, 726 DOI 10.17487/RFC2119, March 1997, 727 . 729 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 730 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 731 DOI 10.17487/RFC4271, January 2006, 732 . 734 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 735 "Multiprotocol Extensions for BGP-4", RFC 4760, 736 DOI 10.17487/RFC4760, January 2007, 737 . 739 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 740 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 741 2009, . 743 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 744 and D. McPherson, "Dissemination of Flow Specification 745 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 746 . 748 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 749 Writing an IANA Considerations Section in RFCs", BCP 26, 750 RFC 8126, DOI 10.17487/RFC8126, June 2017, 751 . 753 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 754 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 755 May 2017, . 757 10.2. Informative References 759 [I-D.ietf-idr-registered-wide-bgp-communities] 760 Raszuk, R. and J. Haas, "Registered Wide BGP Community 761 Values", draft-ietf-idr-registered-wide-bgp-communities-02 762 (work in progress), May 2016. 764 Authors' Addresses 766 Zhenbin Li 767 Huawei 768 Huawei Bld., No.156 Beiqing Rd. 769 Beijing 100095 770 China 772 Email: lizhenbin@huawei.com 774 Liang Ou 775 China Telcom Co., Ltd. 776 109 West Zhongshan Ave,Tianhe District 777 Guangzhou 510630 778 China 780 Email: ouliang@chinatelecom.cn 781 Yujia Luo 782 China Telcom Co., Ltd. 783 109 West Zhongshan Ave,Tianhe District 784 Guangzhou 510630 785 China 787 Email: luoyuj@sdu.edu.cn 789 Sujian Lu 790 Tencent 791 Tengyun Building,Tower A ,No. 397 Tianlin Road 792 Shanghai, Xuhui District 200233 793 China 795 Email: jasonlu@tencent.com 797 Gyan S. Mishra 798 Verizon Inc. 799 13101 Columbia Pike 800 Silver Spring MD 20904 801 USA 803 Phone: 301 502-1347 804 Email: gyan.s.mishra@verizon.com 806 Huaimo Chen 807 Futurewei 808 Boston, MA 809 USA 811 Email: Huaimo.chen@futurewei.com 813 Shunwan Zhuang 814 Huawei 815 Huawei Bld., No.156 Beiqing Rd. 816 Beijing 100095 817 China 819 Email: zhuangshunwan@huawei.com 820 Haibo Wang 821 Huawei 822 Huawei Bld., No.156 Beiqing Rd. 823 Beijing 100095 824 China 826 Email: rainsword.wang@huawei.com