idnits 2.17.1 draft-li-idr-flowspec-rpd-05.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 7, 2019) is 1753 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 689, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-registered-wide-bgp-communities' is defined on line 724, 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: January 8, 2020 Y. Luo 6 China Telcom Co., Ltd. 7 S. Lu 8 Tencent 9 H. Chen 10 Futurewei 11 S. Zhuang 12 H. Wang 13 Huawei 14 July 7, 2019 16 BGP Extensions for Routing Policy Distribution (RPD) 17 draft-li-idr-flowspec-rpd-05 19 Abstract 21 It is hard to adjust traffic and optimize traffic paths on a 22 traditional IP network from time to time through manual 23 configurations. It is desirable to have an automatic mechanism for 24 setting up routing policies, which adjust traffic and optimize 25 traffic paths automatically. This document describes BGP Extensions 26 for Routing Policy Distribution (BGP RPD) to support this. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 8, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 3 71 3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 4 72 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Using a New AFI and SAFI . . . . . . . . . . . . . . . . 5 74 4.2. BGP Wide Community . . . . . . . . . . . . . . . . . . . 6 75 4.2.1. New Wide Community Atoms . . . . . . . . . . . . . . 6 76 4.3. Capability Negotiation . . . . . . . . . . . . . . . . . 12 77 5. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5.1. Route-Policy . . . . . . . . . . . . . . . . . . . . . . 12 79 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 85 10.2. Informative References . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 It is difficult to optimize traffic paths on a traditional IP network 91 because of: 93 o Heavy configuration and error prone. Traffic can only be adjusted 94 device by device. All routers that the traffic traverses need to 95 be configured. The configuration workload is heavy. The 96 operation is not only time consuming but also prone to 97 misconfiguration for Service Providers. 99 o Complex. The routing policies used to control network routes are 100 complex, posing difficulties to subsequent maintenance, high 101 maintenance skills are required. 103 It is desirable to have an automatic mechanism for setting up routing 104 policies, which can simplify the routing policies configuration. 105 This document describes extensions to BGP for Routing Policy 106 Distribution to resolve these issues. 108 2. Terminology 110 The following terminology is used in this document. 112 o ACL:Access Control List 114 o BGP: Border Gateway Protocol 116 o FS: Flow Specification 118 o PBR:Policy-Based Routing 120 o RPD: Routing Policy Distribution 122 o VPN: Virtual Private Network 124 3. Problem Statements 126 It is obvious that providers have the requirements to adjust their 127 business traffic from time to time because: 129 o Business development or network failure introduces link congestion 130 and overload. 132 o Network transmission quality is decreased as the result of delay, 133 loss and they need to adjust traffic to other paths. 135 o To control OPEX and CPEX, prefer the transit provider with lower 136 price. 138 3.1. Inbound Traffic Control 140 In the scenario below, for the reasons above, the provider of AS100 141 saying P may wish the inbound traffic from AS200 enters AS100 through 142 link L3 instead of the others. Since P doesn't have any 143 administration over AS200, so there is no way for P to modify the 144 route selection criteria directly. 146 Traffic from PE1 to Prefix1 147 -----------------------------------> 149 +-----------------+ +-------------------------+ 150 | +---------+ | L1 | +----+ +----------+| 151 | |Speaker1 | +------------+ |IGW1| |policy || 152 | +---------+ |** L2**| +----+ |controller|| 153 | | ** ** | +----------+| 154 | +---+ | **** | | 155 | |PE1| | **** | | 156 | +---+ | ** ** | | 157 | +---------+ |** L3**| +----+ | 158 | |Speaker2 | +------------+ |IGW2| AS100 | 159 | +---------+ | L4 | +----+ | 160 | | | | 161 | AS200 | | | 162 | | | ... | 163 | | | | 164 | +---------+ | | +----+ +-------+ | 165 | |Speakern | | | |IGWn| |Prefix1| | 166 | +---------+ | | +----+ +-------+ | 167 +-----------------+ +-------------------------+ 169 Prefix1 advertised from AS100 to AS200 170 <---------------------------------------- 172 Inbound Traffic Control case 174 3.2. Outbound Traffic Control 176 In the scenario below, the provider of AS100 saying P prefers link L3 177 for the traffic to the destination Prefix2 among multiple exits and 178 links. This preference can be dynamic and changed frequently because 179 of the reasons above. So the provider P expects an efficient and 180 convenient solution. 182 Traffic from PE2 to Prefix2 183 -----------------------------------> 184 +-------------------------+ +-----------------+ 185 |+----------+ +----+ |L1 | +---------+ | 186 ||policy | |IGW1| +------------+ |Speaker1 | | 187 ||controller| +----+ |** **| +---------+ | 188 |+----------+ |L2** ** | +-------+| 189 | | **** | |Prefix2|| 190 | | **** | +-------+| 191 | |L3** ** | | 192 | AS100 +----+ |** **| +---------+ | 193 | |IGW2| +------------+ |Speaker2 | | 194 | +----+ |L4 | +---------+ | 195 | | | | 196 |+---+ | | AS200 | 197 ||PE2| ... | | | 198 |+---+ | | | 199 | +----+ | | +---------+ | 200 | |IGWn| | | |Speakern | | 201 | +----+ | | +---------+ | 202 +-------------------------+ +-----------------+ 204 Prefix2 advertised from AS200 to AS100 205 <---------------------------------------- 207 Outbound Traffic Control case 209 4. Protocol Extensions 211 A solution is proposed to use a new AFI and SAFI with the BGP Wide 212 Community for encoding a routing policy. 214 4.1. Using a New AFI and SAFI 216 A new AFI and SAFI are defined: the Routing Policy AFI whose 217 codepoint TBD1 is to be assigned by IANA, and SAFI whose codepoint 218 TBD2 is to be assigned by IANA. 220 The AFI and SAFI pair uses a new NLRI, which is defined as follows: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+ 225 | NLRI Length | 226 +-+-+-+-+-+-+-+-+ 227 | Policy Type | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Distinguisher (4 octets) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Peer IP (4/16 octets) ~ 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Where: 236 NLRI Length: 1 octet represents the length of NLRI. 238 Policy Type: 1 octet indicates the type of a policy. 1 is for 239 export policy. 2 is for import policy. 241 Distinguisher: 4 octet value uniquely identifies the policy in the 242 peer. 244 Peer IP: 4/16 octet value indicates an IPv4/IPv6 peer. 246 The NLRI containing the Routing Policy is carried in a BGP UPDATE 247 message, which MUST contain the BGP mandatory attributes and MAY also 248 contain some BGP optional attributes. 250 When receiving a BGP UPDATE message, a BGP speaker processes it only 251 if the peer IP address in the NLRI is the IP address of the BGP 252 speaker or 0. 254 The content of the Routing Policy is encoded in a BGP Wide Community. 256 4.2. BGP Wide Community 258 The BGP wide community is defined in 259 [I-D.ietf-idr-wide-bgp-communities]. It can be used to facilitate 260 the delivery of new network services, and be extended easily for 261 distributing different kinds of routing policies. 263 4.2.1. New Wide Community Atoms 265 A wide community Atom is a TLV (or sub-TLV), which may be included in 266 a BGP wide community container (or BGP wide community for short) 267 containing some BGP Wide Community TLVs. Three BGP Wide Community 268 TLVs are defined in [I-D.ietf-idr-wide-bgp-communities], which are 269 BGP Wide Community Target(s) TLV, Exclude Target(s) TLV, and 270 Parameter(s) TLV. Each of these TLVs comprises a series of Atoms, 271 each of which is a TLV (or sub-TLV). A new wide community Atom is 272 defined for BGP Wide Community Target(s) TLV and a few new Atoms are 273 defined for BGP Wide Community Parameter(s) TLV. For your reference, 274 the format of the TLV is illustrated below: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type | Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Value (variable) ~ 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Format of Wide Community Atom TLV 286 A RouteAttr Atom TLV (or RouteAttr TLV/sub-TLV for short) is defined 287 and may be included in a Target TLV. It has the following format. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type (TBD1) | Length (variable) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | sub-TLVs ~ 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Format of RouteAttr Atom TLV 299 The Type for RouteAttr is TBD1 (suggested value 48) to be assigned by 300 IANA. In RouteAttr TLV, three sub-TLVs are defined: IP Prefix, AS- 301 Path and Community sub-TLV. 303 An IP prefix sub-TLV gives matching criteria on IPv4 prefixes. Its 304 format is illustrated below: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type (TBD2) | Length (N x 8) |M-Type | Flags | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | IPv4 Address | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Mask | GeMask | LeMask |M-Type | Flags | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 ~ . . . 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | IPv4 Address | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Mask | GeMask | LeMask | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Format of IPv4 Prefix sub-TLV 324 Type: TBD2 (suggested value 1) for IPv4 Prefix is to be assigned by 325 IANA. 327 Length: N x 8, where N is the number of tuples . 330 M-Type: 4 bits for match types, four of which are defined: 332 M-Type = 0: Exact match. 334 M-Type = 1: Match prefix greater and equal to the given masks. 336 M-Type = 2: Match prefix less and equal to the given masks. 338 M-Type = 3: Match prefix within the range of the given masks. 340 Flags: 4 bits. No flags are currently defined. 342 IPv4 Address: 4 octets for an IPv4 address. 344 Mask: 1 octet for the mask length. 346 GeMask: 1 octet for match range, must be less than Mask or be 0. 348 LeMask: 1 octet for match range, must be greater than Mask or be 0. 350 For example, tuple represents an exact IP prefix match for 352 1.1.0.0/22. 354 represents match IP prefix 1.1.0.0/24 greater-equal 24. 357 represents match IP prefix 17.1.0.0/24 less-equal 26. 360 represents match IP prefix 18.1.0.0/24 greater-equal to 362 24 and less-equal 32. 364 Similarly, an IPv6 Prefix sub-TLV represents match criteria on IPv6 365 prefixes. Its format is illustrated below: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type(TBD3) | Length (N x 20) |M-Type | Flags | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | IPv6 Address (16 octets) ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Mask | GeMask | LeMask |M-Type | Flags | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 ~ . . . 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | IPv6 Address (16 octets ~ 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Mask | GeMask | LeMask | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Format of IPv6 Prefix sub-TLV 385 An AS-Path sub-TLV represents a match criteria in a regular 386 expression string. Its format is illustrated below: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type (TBD4) | Length (Variable) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | AS-Path Regex String | 394 : : 395 | ~ 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Format of AS Path sub-TLV 400 Type: TBD4 (suggested value 2) for AS-Path is to be assigned by 401 IANA. 403 Length: Variable, maximum is 1024. 405 AS-Path Regex String: AS-Path regular expression string. 407 A community sub-TLV represents a list of communities to be matched 408 all. Its format is illustrated below: 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 (TBD5) | Length (N x 4 + 1) | Flags | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Community 1 Value | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 ~ . . . ~ 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Community N Value | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Format of Community sub-TLV 424 Type: TBD5 (suggested value 3) for Community is to be assigned by 425 IANA. 427 Length: N x 4 + 1, where N is the number of communities. 429 Flags: 1 octet. No flags are currently defined. 431 In Parameter(s) TLV, two action sub-TLVs are defined: MED change sub- 432 TLV and AS-Path change sub-TLV. When the community in the container 433 is MATCH AND SET ATTR, the Parameter(s) TLV includes some of these 434 sub-TLVs. When the community is MATCH AND NOT ADVERTISE, the 435 Parameter(s) TLV's value is empty. 437 A MED change sub-TLV indicates an action to change the MED. Its 438 format is illustrated below: 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type (TBD6) | Length (5) | OP | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Value | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Format of MED Change sub-TLV 450 Type: TBD6 (suggested value 1) for MED Change is to be assigned by 451 IANA. 453 Length: 5. 455 OP: 1 octet. Three are defined: 457 OP = 0: assign the Value to the existing MED. 459 OP = 1: add the Value to the existing MED. If the sum is greater 460 than the maximum value for MED, assign the maximum value to 461 MED. 463 OP = 2: subtract the Value from the existing MED. If the 464 existing MED minus the Value is less than 0, assign 0 to MED. 466 Value: 4 octets. 468 An AS-Path change sub-TLV indicates an action to change the AS-Path. 469 Its format is illustrated below: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Type (TBD7) | Length (n x 5) | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | AS1 | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Count1 | 479 +-+-+-+-+-+-+-+-+ 480 ~ . . . 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | ASn | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Countn | 485 +-+-+-+-+-+-+-+-+ 487 Format of AS-Path Change sub-TLV 489 Type: TBD7 (suggested value 2) for AS-Path Change is to be assigned 490 by IANA. 492 Length: n x 5. 494 ASi: 4 octet. An AS number. 496 Counti: 1 octet. ASi repeats Counti times. 498 The sequence of AS numbers are added to the existing AS Path. 500 4.3. Capability Negotiation 502 It is necessary to negotiate the capability to support BGP Extensions 503 for Routing Policy Distribution (RPD). The BGP RPD Capability is a 504 new BGP capability [RFC5492]. The Capability Code for this 505 capability is to be specified by the IANA. The Capability Length 506 field of this capability is variable. The Capability Value field 507 consists of one or more of the following tuples: 509 +--------------------------------------------------+ 510 | Address Family Identifier (2 octets) | 511 +--------------------------------------------------+ 512 | Subsequent Address Family Identifier (1 octet) | 513 +--------------------------------------------------+ 514 | Send/Receive (1 octet) | 515 +--------------------------------------------------+ 517 BGP RPD Capability 519 The meaning and use of the fields are as follows: 521 Address Family Identifier (AFI): This field is the same as the one 522 used in [RFC4760]. 524 Subsequent Address Family Identifier (SAFI): This field is the same 525 as the one used in [RFC4760]. 527 Send/Receive: This field indicates whether the sender is (a) willing 528 to receive Routing Policies from its peer (value 1), (b) would like 529 to send Routing Policies to its peer (value 2), or (c) both (value 3) 530 for the . 532 5. Consideration 534 5.1. Route-Policy 536 Routing policies are used to filter routes and control how routes are 537 received and advertised. If route attributes, such as reachability, 538 are changed, the path along which network traffic passes changes 539 accordingly. 541 When advertising, receiving, and importing routes, the router 542 implements certain policies based on actual networking requirements 543 to filter routes and change the attributes of the routes. Routing 544 policies serve the following purposes: 546 o Control route advertising: Only routes that match the rules 547 specified in a policy are advertised. 549 o Control route receiving: Only the required and valid routes are 550 received. This reduces the size of the routing table and improves 551 network security. 553 o Filter and control imported routes: A routing protocol may import 554 routes discovered by other routing protocols. Only routes that 555 satisfy certain conditions are imported to meet the requirements 556 of the protocol. 558 o Modify attributes of specified routes Attributes of the routes: 559 that are filtered by a routing policy are modified to meet the 560 requirements of the local device. 562 o Configure fast reroute (FRR): If a backup next hop and a backup 563 outbound interface are configured for the routes that match a 564 routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be 565 implemented. 567 Routing policies are implemented using the following procedures: 569 1. Define rules: Define features of routes to which routing policies 570 are applied. Users define a set of matching rules based on 571 different attributes of routes, such as the destination address 572 and the address of the router that advertises the routes. 574 2. Implement the rules: Apply the matching rules to routing policies 575 for advertising, receiving, and importing routes. 577 6. Contributors 579 The following people have substantially contributed to the definition 580 of the BGP-FS RPD and to the editing of this document: 582 Peng Zhou 583 Huawei 584 Email: Jewpon.zhou@huawei.com 586 7. Security Considerations 588 Protocol extensions defined in this document do not affect the BGP 589 security other than those as discussed in the Security Considerations 590 section of [RFC5575]. 592 8. Acknowledgements 594 The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong, 595 Lucy Yong, Qiandeng Liang, Zhenqiang Li for their comments to this 596 work. 598 9. IANA Considerations 600 This document requests assigning a new AFI in the registry "Address 601 Family Numbers" as follows: 603 +-----------------------+-------------------------+-------------+ 604 | Code Point | Description | Reference | 605 +-----------------------+-------------------------+-------------+ 606 | TBD (36879 suggested) | Routing Policy AFI |This document| 607 +-------------------------------------------------+-------------+ 609 This document requests assigning a new SAFI in the registry 610 "Subsequent Address Family Identifiers (SAFI) Parameters" as follows: 612 +-----------------------+-------------------------+-------------+ 613 | Code Point | Description | Reference | 614 +-----------------------+-------------------------+-------------+ 615 | TBD(179 suggested) | Routing Policy SAFI |This document| 616 +-----------------------+-------------------------+-------------+ 618 This document defines a new registry called "Routing Policy NLRI". 619 The allocation policy of this registry is "First Come First Served 620 (FCFS)" according to [RFC8126]. 622 Following code points are defined: 624 +-------------+-----------------------------------+-------------+ 625 | Code Point | Description | Reference | 626 +-------------+-----------------------------------+-------------+ 627 | 1 | Export Policy |This document| 628 +-------------+-----------------------------------+-------------+ 629 | 2 | Import Policy |This document| 630 +-------------+-----------------------------------+-------------+ 632 This document requests assigning a code-point from the registry "BGP 633 Community Container Atom Types" as follows: 635 +---------------------+------------------------------+-------------+ 636 | TLV Code Point | Description | Reference | 637 +---------------------+------------------------------+-------------+ 638 | TBD1 (48 suggested) | RouteAttr Atom |This document| 639 +---------------------+------------------------------+-------------+ 641 This document defines a new registry called "Route Attributes Sub- 642 TLV" under RouteAttr Atom TLV. The allocation policy of this 643 registry is "First Come First Served (FCFS)" according to [RFC8126]. 645 Following Sub-TLV code points are defined: 647 +-------------+-----------------------------------+-------------+ 648 | Code Point | Description | Reference | 649 +-------------+-----------------------------------+-------------+ 650 | 0 | Reserved | | 651 +-------------+-----------------------------------+-------------+ 652 | 1 | IP Prefix Sub-TLV |This document| 653 +-------------+-----------------------------------+-------------+ 654 | 2 | AS-Path Sub-TLV |This document| 655 +-------------+-----------------------------------+-------------+ 656 | 3 | Community Sub-TLV |This document| 657 +-------------+-----------------------------------+-------------+ 658 | 4 - 255 | To be assigned in FCFS | | 659 +-------------+-----------------------------------+-------------+ 661 This document defines a new registry called "Attribute Change Sub- 662 TLV" under Parameter(s) TLV. The allocation policy of this registry 663 is "First Come First Served (FCFS)" according to [RFC8126]. 665 Following Sub-TLV code points are defined: 667 +-------------+-----------------------------------+-------------+ 668 | Code Point | Description | Reference | 669 +-------------+-----------------------------------+-------------+ 670 | 0 | Reserved | | 671 +-------------+-----------------------------------+-------------+ 672 | 1 | MED Change Sub-TLV |This document| 673 +-------------+-----------------------------------+-------------+ 674 | 2 | AS-Path Change Sub-TLV |This document| 675 +-------------+-----------------------------------+-------------+ 676 | 3 - 255 | To be assigned in FCFS | | 677 +-------------+-----------------------------------+-------------+ 679 10. References 681 10.1. Normative References 683 [I-D.ietf-idr-wide-bgp-communities] 684 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 685 and P. Jakma, "BGP Community Container Attribute", draft- 686 ietf-idr-wide-bgp-communities-05 (work in progress), July 687 2018. 689 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 690 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 691 . 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, 695 DOI 10.17487/RFC2119, March 1997, 696 . 698 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 699 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 700 DOI 10.17487/RFC4271, January 2006, 701 . 703 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 704 "Multiprotocol Extensions for BGP-4", RFC 4760, 705 DOI 10.17487/RFC4760, January 2007, 706 . 708 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 709 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 710 2009, . 712 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 713 and D. McPherson, "Dissemination of Flow Specification 714 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 715 . 717 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 718 Writing an IANA Considerations Section in RFCs", BCP 26, 719 RFC 8126, DOI 10.17487/RFC8126, June 2017, 720 . 722 10.2. Informative References 724 [I-D.ietf-idr-registered-wide-bgp-communities] 725 Raszuk, R. and J. Haas, "Registered Wide BGP Community 726 Values", draft-ietf-idr-registered-wide-bgp-communities-02 727 (work in progress), May 2016. 729 Authors' Addresses 730 Zhenbin Li 731 Huawei 732 Huawei Bld., No.156 Beiqing Rd. 733 Beijing 100095 734 China 736 Email: lizhenbin@huawei.com 738 Liang Ou 739 China Telcom Co., Ltd. 740 109 West Zhongshan Ave,Tianhe District 741 Guangzhou 510630 742 China 744 Email: oul@gsta.com 746 Yujia Luo 747 China Telcom Co., Ltd. 748 109 West Zhongshan Ave,Tianhe District 749 Guangzhou 510630 750 China 752 Email: luoyuj@gsta.com 754 Sujian Lu 755 Tencent 756 Tengyun Building,Tower A ,No. 397 Tianlin Road 757 Shanghai, Xuhui District 200233 758 China 760 Email: jasonlu@tencent.com 762 Huaimo Chen 763 Futurewei 764 Boston, MA 765 USA 767 Email: Huaimo.chen@futurewei.com 768 Shunwan Zhuang 769 Huawei 770 Huawei Bld., No.156 Beiqing Rd. 771 Beijing 100095 772 China 774 Email: zhuangshunwan@huawei.com 776 Haibo Wang 777 Huawei 778 Huawei Bld., No.156 Beiqing Rd. 779 Beijing 100095 780 China 782 Email: rainsword.wang@huawei.com