idnits 2.17.1 draft-ietf-idr-rpd-06.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 (July 31, 2020) is 1365 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 690, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-registered-wide-bgp-communities' is defined on line 725, 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 1, 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 July 31, 2020 18 BGP Extensions for Routing Policy Distribution (RPD) 19 draft-ietf-idr-rpd-06 21 Abstract 23 It is hard to adjust traffic and optimize traffic paths on a 24 traditional IP network from time to time through manual 25 configurations. It is desirable to have an automatic mechanism for 26 setting up routing policies, which adjust traffic and optimize 27 traffic paths automatically. This document describes BGP Extensions 28 for Routing 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 RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on February 1, 2021. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3 73 3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 4 74 3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 4 75 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 76 4.1. Using a New AFI and SAFI . . . . . . . . . . . . . . . . 5 77 4.2. BGP Wide Community . . . . . . . . . . . . . . . . . . . 6 78 4.2.1. New Wide Community Atoms . . . . . . . . . . . . . . 6 79 4.3. Capability Negotiation . . . . . . . . . . . . . . . . . 12 80 5. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 12 81 5.1. Route-Policy . . . . . . . . . . . . . . . . . . . . . . 12 82 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 10.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 It is difficult to optimize traffic paths on a traditional IP network 94 because of: 96 o Heavy configuration and error prone. Traffic can only be adjusted 97 device by device. All routers that the traffic traverses need to 98 be configured. The configuration workload is heavy. The 99 operation is not only time consuming but also prone to 100 misconfiguration for Service Providers. 102 o Complex. The routing policies used to control network routes are 103 complex, posing difficulties to subsequent maintenance, high 104 maintenance skills are required. 106 It is desirable to have an automatic mechanism for setting up routing 107 policies, which can simplify the routing policies configuration. 108 This document describes extensions to BGP for Routing Policy 109 Distribution to resolve these issues. 111 2. Terminology 113 The following terminology is used in this document. 115 o ACL:Access Control List 117 o BGP: Border Gateway Protocol 119 o FS: Flow Specification 121 o PBR:Policy-Based Routing 123 o RPD: Routing Policy Distribution 125 o VPN: Virtual Private Network 127 3. Problem Statements 129 It is obvious that providers have the requirements to adjust their 130 business traffic from time to time because: 132 o Business development or network failure introduces link congestion 133 and overload. 135 o Network transmission quality is decreased as the result of delay, 136 loss and they need to adjust traffic to other paths. 138 o To control OPEX and CPEX, prefer the transit provider with lower 139 price. 141 3.1. Inbound Traffic Control 143 In the scenario below, for the reasons above, the provider of AS100 144 saying P may wish the inbound traffic from AS200 enters AS100 through 145 link L3 instead of the others. Since P doesn't have any 146 administration over AS200, so there is no way for P to modify the 147 route selection criteria directly. 149 Traffic from PE1 to Prefix1 150 -----------------------------------> 152 +-----------------+ +-------------------------+ 153 | +---------+ | L1 | +----+ +----------+| 154 | |Speaker1 | +------------+ |IGW1| |policy || 155 | +---------+ |** L2**| +----+ |controller|| 156 | | ** ** | +----------+| 157 | +---+ | **** | | 158 | |PE1| | **** | | 159 | +---+ | ** ** | | 160 | +---------+ |** L3**| +----+ | 161 | |Speaker2 | +------------+ |IGW2| AS100 | 162 | +---------+ | L4 | +----+ | 163 | | | | 164 | AS200 | | | 165 | | | ... | 166 | | | | 167 | +---------+ | | +----+ +-------+ | 168 | |Speakern | | | |IGWn| |Prefix1| | 169 | +---------+ | | +----+ +-------+ | 170 +-----------------+ +-------------------------+ 172 Prefix1 advertised from AS100 to AS200 173 <---------------------------------------- 175 Inbound Traffic Control case 177 3.2. Outbound Traffic Control 179 In the scenario below, the provider of AS100 saying P prefers link L3 180 for the traffic to the destination Prefix2 among multiple exits and 181 links. This preference can be dynamic and changed frequently because 182 of the reasons above. So the provider P expects an efficient and 183 convenient solution. 185 Traffic from PE2 to Prefix2 186 -----------------------------------> 187 +-------------------------+ +-----------------+ 188 |+----------+ +----+ |L1 | +---------+ | 189 ||policy | |IGW1| +------------+ |Speaker1 | | 190 ||controller| +----+ |** **| +---------+ | 191 |+----------+ |L2** ** | +-------+| 192 | | **** | |Prefix2|| 193 | | **** | +-------+| 194 | |L3** ** | | 195 | AS100 +----+ |** **| +---------+ | 196 | |IGW2| +------------+ |Speaker2 | | 197 | +----+ |L4 | +---------+ | 198 | | | | 199 |+---+ | | AS200 | 200 ||PE2| ... | | | 201 |+---+ | | | 202 | +----+ | | +---------+ | 203 | |IGWn| | | |Speakern | | 204 | +----+ | | +---------+ | 205 +-------------------------+ +-----------------+ 207 Prefix2 advertised from AS200 to AS100 208 <---------------------------------------- 210 Outbound Traffic Control case 212 4. Protocol Extensions 214 A solution is proposed to use a new AFI and SAFI with the BGP Wide 215 Community for encoding a routing policy. 217 4.1. Using a New AFI and SAFI 219 A new AFI and SAFI are defined: the Routing Policy AFI whose 220 codepoint 16398 has been assigned by IANA, and SAFI whose codepoint 221 75 has been assigned by IANA. 223 The AFI and SAFI pair uses a new NLRI, which is defined as follows: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+ 228 | NLRI Length | 229 +-+-+-+-+-+-+-+-+ 230 | Policy Type | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Distinguisher (4 octets) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Peer IP (4/16 octets) ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Where: 239 NLRI Length: 1 octet represents the length of NLRI. 241 Policy Type: 1 octet indicates the type of a policy. 1 is for 242 export policy. 2 is for import policy. 244 Distinguisher: 4 octet value uniquely identifies the policy in the 245 peer. 247 Peer IP: 4/16 octet value indicates an IPv4/IPv6 peer. 249 The NLRI containing the Routing Policy is carried in a BGP UPDATE 250 message, which MUST contain the BGP mandatory attributes and MAY also 251 contain some BGP optional attributes. 253 When receiving a BGP UPDATE message, a BGP speaker processes it only 254 if the peer IP address in the NLRI is the IP address of the BGP 255 speaker or 0. 257 The content of the Routing Policy is encoded in a BGP Wide Community. 259 4.2. BGP Wide Community 261 The BGP wide community is defined in 262 [I-D.ietf-idr-wide-bgp-communities]. It can be used to facilitate 263 the delivery of new network services, and be extended easily for 264 distributing different kinds of routing policies. 266 4.2.1. New Wide Community Atoms 268 A wide community Atom is a TLV (or sub-TLV), which may be included in 269 a BGP wide community container (or BGP wide community for short) 270 containing some BGP Wide Community TLVs. Three BGP Wide Community 271 TLVs are defined in [I-D.ietf-idr-wide-bgp-communities], which are 272 BGP Wide Community Target(s) TLV, Exclude Target(s) TLV, and 273 Parameter(s) TLV. Each of these TLVs comprises a series of Atoms, 274 each of which is a TLV (or sub-TLV). A new wide community Atom is 275 defined for BGP Wide Community Target(s) TLV and a few new Atoms are 276 defined for BGP Wide Community Parameter(s) TLV. For your reference, 277 the format of the TLV is illustrated below: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type | Length | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Value (variable) ~ 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Format of Wide Community Atom TLV 289 A RouteAttr Atom TLV (or RouteAttr TLV/sub-TLV for short) is defined 290 and may be included in a Target TLV. It has the following format. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type (TBD1) | Length (variable) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | sub-TLVs ~ 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Format of RouteAttr Atom TLV 302 The Type for RouteAttr is TBD1 (suggested value 48) to be assigned by 303 IANA. In RouteAttr TLV, three sub-TLVs are defined: IP Prefix, AS- 304 Path and Community sub-TLV. 306 An IP prefix sub-TLV gives matching criteria on IPv4 prefixes. Its 307 format is illustrated below: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type (TBD2) | Length (N x 8) |M-Type | Flags | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | IPv4 Address | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Mask | GeMask | LeMask |M-Type | Flags | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 ~ . . . 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | IPv4 Address | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Mask | GeMask | LeMask | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Format of IPv4 Prefix sub-TLV 327 Type: TBD2 (suggested value 1) for IPv4 Prefix is to be assigned by 328 IANA. 330 Length: N x 8, where N is the number of tuples . 333 M-Type: 4 bits for match types, four of which are defined: 335 M-Type = 0: Exact match. 337 M-Type = 1: Match prefix greater and equal to the given masks. 339 M-Type = 2: Match prefix less and equal to the given masks. 341 M-Type = 3: Match prefix within the range of the given masks. 343 Flags: 4 bits. No flags are currently defined. 345 IPv4 Address: 4 octets for an IPv4 address. 347 Mask: 1 octet for the mask length. 349 GeMask: 1 octet for match range, must be less than Mask or be 0. 351 LeMask: 1 octet for match range, must be greater than Mask or be 0. 353 For example, tuple represents an exact IP prefix match for 355 1.1.0.0/22. 357 represents match IP prefix 1.1.0.0/24 greater-equal 24. 360 represents match IP prefix 17.1.0.0/24 less-equal 26. 363 represents match IP prefix 18.1.0.0/24 greater-equal to 365 24 and less-equal 32. 367 Similarly, an IPv6 Prefix sub-TLV represents match criteria on IPv6 368 prefixes. Its format is illustrated below: 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type(TBD3) | Length (N x 20) |M-Type | Flags | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | IPv6 Address (16 octets) ~ 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Mask | GeMask | LeMask |M-Type | Flags | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 ~ . . . 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | IPv6 Address (16 octets ~ 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Mask | GeMask | LeMask | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Format of IPv6 Prefix sub-TLV 388 An AS-Path sub-TLV represents a match criteria in a regular 389 expression string. Its format is illustrated below: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type (TBD4) | Length (Variable) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | AS-Path Regex String | 397 : : 398 | ~ 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Format of AS Path sub-TLV 403 Type: TBD4 (suggested value 2) for AS-Path is to be assigned by 404 IANA. 406 Length: Variable, maximum is 1024. 408 AS-Path Regex String: AS-Path regular expression string. 410 A community sub-TLV represents a list of communities to be matched 411 all. Its format is illustrated below: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type (TBD5) | Length (N x 4 + 1) | Flags | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Community 1 Value | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 ~ . . . ~ 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Community N Value | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Format of Community sub-TLV 427 Type: TBD5 (suggested value 3) for Community is to be assigned by 428 IANA. 430 Length: N x 4 + 1, where N is the number of communities. 432 Flags: 1 octet. No flags are currently defined. 434 In Parameter(s) TLV, two action sub-TLVs are defined: MED change sub- 435 TLV and AS-Path change sub-TLV. When the community in the container 436 is MATCH AND SET ATTR, the Parameter(s) TLV includes some of these 437 sub-TLVs. When the community is MATCH AND NOT ADVERTISE, the 438 Parameter(s) TLV's value is empty. 440 A MED change sub-TLV indicates an action to change the MED. Its 441 format is illustrated below: 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Type (TBD6) | Length (5) | OP | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Value | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Format of MED Change sub-TLV 453 Type: TBD6 (suggested value 1) for MED Change is to be assigned by 454 IANA. 456 Length: 5. 458 OP: 1 octet. Three are defined: 460 OP = 0: assign the Value to the existing MED. 462 OP = 1: add the Value to the existing MED. If the sum is greater 463 than the maximum value for MED, assign the maximum value to 464 MED. 466 OP = 2: subtract the Value from the existing MED. If the 467 existing MED minus the Value is less than 0, assign 0 to MED. 469 Value: 4 octets. 471 An AS-Path change sub-TLV indicates an action to change the AS-Path. 472 Its format is illustrated below: 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Type (TBD7) | Length (n x 5) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | AS1 | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Count1 | 482 +-+-+-+-+-+-+-+-+ 483 ~ . . . 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | ASn | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Countn | 488 +-+-+-+-+-+-+-+-+ 490 Format of AS-Path Change sub-TLV 492 Type: TBD7 (suggested value 2) for AS-Path Change is to be assigned 493 by IANA. 495 Length: n x 5. 497 ASi: 4 octet. An AS number. 499 Counti: 1 octet. ASi repeats Counti times. 501 The sequence of AS numbers are added to the existing AS Path. 503 4.3. Capability Negotiation 505 It is necessary to negotiate the capability to support BGP Extensions 506 for Routing Policy Distribution (RPD). The BGP RPD Capability is a 507 new BGP capability [RFC5492]. The Capability Code for this 508 capability is 72 assigned by the IANA. The Capability Length field 509 of this capability is variable. The Capability Value field consists 510 of one or more of the following tuples: 512 +--------------------------------------------------+ 513 | Address Family Identifier (2 octets) | 514 +--------------------------------------------------+ 515 | Subsequent Address Family Identifier (1 octet) | 516 +--------------------------------------------------+ 517 | Send/Receive (1 octet) | 518 +--------------------------------------------------+ 520 BGP RPD Capability 522 The meaning and use of the fields are as follows: 524 Address Family Identifier (AFI): This field is the same as the one 525 used in [RFC4760]. 527 Subsequent Address Family Identifier (SAFI): This field is the same 528 as the one used in [RFC4760]. 530 Send/Receive: This field indicates whether the sender is (a) willing 531 to receive Routing Policies from its peer (value 1), (b) would like 532 to send Routing Policies to its peer (value 2), or (c) both (value 3) 533 for the . 535 5. Consideration 537 5.1. Route-Policy 539 Routing policies are used to filter routes and control how routes are 540 received and advertised. If route attributes, such as reachability, 541 are changed, the path along which network traffic passes changes 542 accordingly. 544 When advertising, receiving, and importing routes, the router 545 implements certain policies based on actual networking requirements 546 to filter routes and change the attributes of the routes. Routing 547 policies serve the following purposes: 549 o Control route advertising: Only routes that match the rules 550 specified in a policy are advertised. 552 o Control route receiving: Only the required and valid routes are 553 received. This reduces the size of the routing table and improves 554 network security. 556 o Filter and control imported routes: A routing protocol may import 557 routes discovered by other routing protocols. Only routes that 558 satisfy certain conditions are imported to meet the requirements 559 of the protocol. 561 o Modify attributes of specified routes Attributes of the routes: 562 that are filtered by a routing policy are modified to meet the 563 requirements of the local device. 565 o Configure fast reroute (FRR): If a backup next hop and a backup 566 outbound interface are configured for the routes that match a 567 routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be 568 implemented. 570 Routing policies are implemented using the following procedures: 572 1. Define rules: Define features of routes to which routing policies 573 are applied. Users define a set of matching rules based on 574 different attributes of routes, such as the destination address 575 and the address of the router that advertises the routes. 577 2. Implement the rules: Apply the matching rules to routing policies 578 for advertising, receiving, and importing routes. 580 6. Contributors 582 The following people have substantially contributed to the definition 583 of the BGP-FS RPD and to the editing of this document: 585 Peng Zhou 586 Huawei 587 Email: Jewpon.zhou@huawei.com 589 7. Security Considerations 591 Protocol extensions defined in this document do not affect the BGP 592 security other than those as discussed in the Security Considerations 593 section of [RFC5575]. 595 8. Acknowledgements 597 The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong, 598 Lucy Yong, Qiandeng Liang, Zhenqiang Li for their comments to this 599 work. 601 9. IANA Considerations 603 IANA has assigned a new AFI of value 16398 from the registry "Address 604 Family Numbers" for Routing Policy. 606 IANA has assigned a new SAFI of value 75 from the registry 607 "Subsequent Address Family Identifiers (SAFI) Parameters" for Routing 608 Policy. 610 This document defines a new registry called "Routing Policy Type". 611 The allocation policy of this registry is "First Come First Served 612 (FCFS)" according to [RFC8126]. 614 Following code points are defined: 616 +-------------+-----------------------------------+-------------+ 617 | Code Point | Description | Reference | 618 +-------------+-----------------------------------+-------------+ 619 | 0 | Reserved | | 620 +-------------+-----------------------------------+-------------+ 621 | 1 | Export Policy |This document| 622 +-------------+-----------------------------------+-------------+ 623 | 2 | Import Policy |This document| 624 +-------------+-----------------------------------+-------------+ 625 | 3 - 255 | To be assigned in FCFS | | 626 +-------------+-----------------------------------+-------------+ 628 This document requests assigning a code-point from the registry "BGP 629 Community Container Atom Types" as follows: 631 +---------------------+------------------------------+-------------+ 632 | TLV Code Point | Description | Reference | 633 +---------------------+------------------------------+-------------+ 634 | TBD1 (48 suggested) | RouteAttr Atom |This document| 635 +---------------------+------------------------------+-------------+ 637 This document defines a new registry called "Route Attributes Sub- 638 TLV" under RouteAttr Atom TLV. The allocation policy of this 639 registry is "First Come First Served (FCFS)" according to [RFC8126]. 641 Following Sub-TLV code points are defined: 643 +-------------+-----------------------------------+-------------+ 644 | Code Point | Description | Reference | 645 +-------------+-----------------------------------+-------------+ 646 | 0 | Reserved | | 647 +-------------+-----------------------------------+-------------+ 648 | 1 | IPv4 Prefix Sub-TLV |This document| 649 +-------------+-----------------------------------+-------------+ 650 | 2 | AS-Path Sub-TLV |This document| 651 +-------------+-----------------------------------+-------------+ 652 | 3 | Community Sub-TLV |This document| 653 +-------------+-----------------------------------+-------------+ 654 | 4 | IPv6 Prefix Sub-TLV |This document| 655 +-------------+-----------------------------------+-------------+ 656 | 5 - 255 | To be assigned in FCFS | | 657 +-------------+-----------------------------------+-------------+ 659 This document defines a new registry called "Attribute Change Sub- 660 TLV" under Parameter(s) TLV. The allocation policy of this registry 661 is "First Come First Served (FCFS)" according to [RFC8126]. 663 Following Sub-TLV code points are defined: 665 +-------------+-----------------------------------+-------------+ 666 | Code Point | Description | Reference | 667 +-------------+-----------------------------------+-------------+ 668 | 0 | Reserved | | 669 +-------------+-----------------------------------+-------------+ 670 | 1 | MED Change Sub-TLV |This document| 671 +-------------+-----------------------------------+-------------+ 672 | 2 | AS-Path Change Sub-TLV |This document| 673 +-------------+-----------------------------------+-------------+ 674 | 3 - 255 | To be assigned in FCFS | | 675 +-------------+-----------------------------------+-------------+ 677 IANA has assigned a new Code Point of value 72 from the registry 678 "Capability Codes" for Routing Policy Distribution. 680 10. References 682 10.1. Normative References 684 [I-D.ietf-idr-wide-bgp-communities] 685 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 686 and P. Jakma, "BGP Community Container Attribute", draft- 687 ietf-idr-wide-bgp-communities-05 (work in progress), July 688 2018. 690 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 691 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 692 . 694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 695 Requirement Levels", BCP 14, RFC 2119, 696 DOI 10.17487/RFC2119, March 1997, 697 . 699 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 700 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 701 DOI 10.17487/RFC4271, January 2006, 702 . 704 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 705 "Multiprotocol Extensions for BGP-4", RFC 4760, 706 DOI 10.17487/RFC4760, January 2007, 707 . 709 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 710 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 711 2009, . 713 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 714 and D. McPherson, "Dissemination of Flow Specification 715 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 716 . 718 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 719 Writing an IANA Considerations Section in RFCs", BCP 26, 720 RFC 8126, DOI 10.17487/RFC8126, June 2017, 721 . 723 10.2. Informative References 725 [I-D.ietf-idr-registered-wide-bgp-communities] 726 Raszuk, R. and J. Haas, "Registered Wide BGP Community 727 Values", draft-ietf-idr-registered-wide-bgp-communities-02 728 (work in progress), May 2016. 730 Authors' Addresses 731 Zhenbin Li 732 Huawei 733 Huawei Bld., No.156 Beiqing Rd. 734 Beijing 100095 735 China 737 Email: lizhenbin@huawei.com 739 Liang Ou 740 China Telcom Co., Ltd. 741 109 West Zhongshan Ave,Tianhe District 742 Guangzhou 510630 743 China 745 Email: ouliang@chinatelecom.cn 747 Yujia Luo 748 China Telcom Co., Ltd. 749 109 West Zhongshan Ave,Tianhe District 750 Guangzhou 510630 751 China 753 Email: luoyuj@sdu.edu.cn 755 Sujian Lu 756 Tencent 757 Tengyun Building,Tower A ,No. 397 Tianlin Road 758 Shanghai, Xuhui District 200233 759 China 761 Email: jasonlu@tencent.com 763 Gyan S. Mishra 764 Verizon Inc. 765 13101 Columbia Pike 766 Silver Spring MD 20904 767 USA 769 Phone: 301 502-1347 770 Email: gyan.s.mishra@verizon.com 771 Huaimo Chen 772 Futurewei 773 Boston, MA 774 USA 776 Email: Huaimo.chen@futurewei.com 778 Shunwan Zhuang 779 Huawei 780 Huawei Bld., No.156 Beiqing Rd. 781 Beijing 100095 782 China 784 Email: zhuangshunwan@huawei.com 786 Haibo Wang 787 Huawei 788 Huawei Bld., No.156 Beiqing Rd. 789 Beijing 100095 790 China 792 Email: rainsword.wang@huawei.com