idnits 2.17.00 (12 Aug 2021) /tmp/idnits394/draft-wu-idr-flowspec-redirect-group-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-idr-wide-bgp-communities]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (7 March 2022) is 68 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) == Missing Reference: 'RFC8955' is mentioned on line 571, but not defined == Missing Reference: 'RFC8956' is mentioned on line 576, but not defined -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-idr-flowspec-redirect-ip' == Outdated reference: A later version (-07) exists of draft-ietf-idr-wide-bgp-communities-06 == Outdated reference: A later version (-07) exists of draft-jiang-idr-ts-flowspec-srv6-policy-04 ** Downref: Normative reference to an Informational draft: draft-jiang-idr-ts-flowspec-srv6-policy (ref. 'I-D.jiang-idr-ts-flowspec-srv6-policy') Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group Z. Wu 3 Internet-Draft H. Wang 4 Intended status: Standards Track L. Wang 5 Expires: 8 September 2022 Z. Tan 6 Huawei Technologies 7 7 March 2022 9 BGP Flowspec Redirect Load Balancing Group Community 10 draft-wu-idr-flowspec-redirect-group-00 12 Abstract 14 This document defines an extension to "BGP Community Container 15 Attribute" [I-D.ietf-idr-wide-bgp-communities] , which allows 16 flowspec redirection to multiple paths. This extended community 17 serves to redirect traffic to a load balancing group and supports 18 both equal-cost multi-path(ECMP) and unequal-cost multi-path(UCMP) 19 scenarios. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 8 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Redirect Load Balancing Group Community . . . . . . . . . . . 3 63 2.1. Community Value . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Param TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Sub-TLVs(Atoms) . . . . . . . . . . . . . . . . . . . . . 5 66 2.3.1. Atom Type 1: IPv4 Prefix Only . . . . . . . . . . . . 6 67 2.3.2. Atom Type 2: IPv4 Prefix with Weight . . . . . . . . 6 68 2.3.3. Atom Type 3: IPv4 Prefix with Color . . . . . . . . . 7 69 2.3.4. Atom Type 4: IPv4 Prefix with Color and Weight . . . 8 70 2.3.5. Atom Type 5: IPv6 Prefix Only . . . . . . . . . . . . 8 71 2.3.6. Atom Type 6: IPv6 Prefix with Weight . . . . . . . . 9 72 2.3.7. Atom Type 7: IPv6 Prefix with Color . . . . . . . . . 10 73 2.3.8. Atom Type 8: IPv6 Prefix with Color and Weight . . . 10 74 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 3.1. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 3.2. UCMP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.1. Redirect Group Wide Community Parameter TLV . . . . . . . 12 79 4.2. Redirect Group Wide Community Parameter Sub-TLVs . . . . 12 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 5.1. BGP Wide Communities Community Type : Redirect Group . . 12 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 7.2. References . . . . . . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 "Redirect to IP Extended Community", defined in 91 [I-D.ietf-idr-flowspec-redirect-ip], allows traffic to be redirected 92 to a specific IPv4 or IPv6 address, and 93 [I-D.jiang-idr-ts-flowspec-srv6-policy] defines the redirection 94 action to a SRv6 tunnel by additionally carrying the "Color Extended 95 Community" [RFC8955]. 97 However, scenarios involving redirection load balancing are not 98 described in both documents. Although in some implementations, 99 Equal-cost multi-path(ECMP) of "Redirect to IP" action can be 100 achieved by encoding multiple redirect Extended Communities, the 101 current set of mechanisms can hardly support neither ECMP of SRv6 102 tunnels nor unequal-cost multi-path(UCMP) of either types. 104 This document defines an extension to "BGP Community Container 105 Attribute" [I-D.ietf-idr-wide-bgp-communities], the "Redirect Load 106 Balancing Group" community. It is a new type of wide community 107 container attribute with encoding format of multiple redirection path 108 TLVs. Each of these TLVs represents a different redirection action. 109 It allows traffic redirection to a load balancing group and supports 110 both ECMP and UCMP scenarios. 112 1.1. Terminology 114 This document introduces the following terms: 116 ECMP: Equal-Cost Multi-Path 118 UCMP: Unequal-Cost Multi-Path 120 2. Redirect Load Balancing Group Community 122 This document defines a new type of "BGP Community Container 123 Attribute", the "Redirect Load Balancing Group" community type. The 124 format complies with "BGP Community Container Attribute" 125 [I-D.ietf-idr-wide-bgp-communities] and is shown below: 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Type | Flags |C|T| Reserved | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Length | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Community Value: Redirect Load Balancing Group | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Source AS Number | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Context AS Number | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Param TLV | Length | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | | 143 | sub-TLVs | 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Figure 1: Redirect Load Balancing Group Community Format 149 The Type, Flags, Reserved and Length fields comply with the "BGP 150 Community Container Attribute Common Header" definition. 152 The container type MUST be 1, which represents BGP Wide Community. 154 The Length field represents the total length of the container's 155 contents in octets. 157 2.1. Community Value 159 The Community Value, Source AS Number and Context AS Number fields 160 comply with the corresponding definition in "BGP Community Container 161 Attribute". 163 Community Value: 4 octets value that represents the "Redirect Load 164 Balancing Group" community type. The value is TBD and requires IANA 165 registration; See Section 5.1. 167 2.2. Param TLV 169 The BGP Wide Community Parameter TLV (Sub-Type 3) contains a list of 170 atoms, comply with "BGP Wide Community Parameter(s) TLV" section of 171 "BGP Community Container Attribute". 173 The Parameter TLV MUST present and SHOULD appear only once in a 174 "Redirect Load Balancing Group" community container, no or multiple 175 present SHOULD be considered malformed. 177 Sub-Type: Type 3 (BGP Wide Community Parameter TLV) 179 Length: Length of all the sub-TLVs in octets. 181 2.3. Sub-TLVs(Atoms) 183 The list of atoms that Param Tlv contains. Each atom represents a 184 different redirection path. 186 The general format of the sub-TLVs comply with atoms' format defined 187 in "BGP Community Container Attribute", as below: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+ 192 | Type | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Length | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Value | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 2: Param Sub-TlV Format 201 The Type field is an octet from 1~254 (0 and 255 are reserved). 202 Supported type of the sub-TLVs includes: 204 Type 1: IPv4 Prefix Only 206 Type 2: IPv4 Prefix with Weight 208 Type 3: IPv4 Prefix with Color 210 Type 4: IPv4 Prefix with Color and Weight 212 Type 5: IPv6 Prefix Only 214 Type 6: IPv6 Prefix with Weight 216 Type 7: IPv6 Prefix with Color 218 Type 8: IPv6 Prefix with Color and Weight 219 These sub-TLV types SHOULD be used exclusively within "Redirect Load 220 Balancing Group" community containers. 222 The Length represents the length of the "Value" field in octets, and 223 it is fixed for each specific sub-TLV. 225 If the length and type of a sub-TLV do not match, the "Redirect Load 226 Balancing Group" community container SHOULD be considered malformed. 228 If a sub-TLV is a total dupilication of a previous one, the latter 229 sub-TLV MUST be ignored. 231 In principle, sub-TLVs of different types may be combined in any 232 mode. The supported combinations depend on the specific 233 implementation. 235 2.3.1. Atom Type 1: IPv4 Prefix Only 237 Indicating the redirection path is unweighted and to a IPv4 address. 238 The format is shown below: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type: 1 | Length: 6 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Flag(2) | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | IPv4(4) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 3: Atom Type 1: IPv4 Prefix Only 252 Length: MUST be 6. 254 Flags: 2 octets, reserved for future use, MUST be set to 0 upon the 255 sender and MUST be ignored upon the reciever. 257 IPv4: 4-octet IPv4 address, redirection destination 259 2.3.2. Atom Type 2: IPv4 Prefix with Weight 261 Indicating the redirection path is weighted and to a IPv4 address. 262 The format is shown below: 264 0 1 2 3 265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type: 2 | Length: 7 | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Flag(2) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | IPv4(4) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Weight(1) | 274 +-+-+-+-+-+-+-+-+ 276 Figure 4: Atom Type 2: IPv4 Prefix with Weight 278 Length: MUST be 7. 280 Flags: 2 octets, reserved for future use, MUST be set to 0 upon the 281 sender and MUST be ignored upon the reciever. 283 IPv4: 4-octet IPv4 address, redirection destination 285 Weight: 1 octet, values from 1~255, load balancing weight 287 2.3.3. Atom Type 3: IPv4 Prefix with Color 289 Indicating the redirection path is unweighted and to a SR-TE tunnel. 290 The format is shown below: 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: 3 | Length: 10 | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Flag(2) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | IPv4(4) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Color(4) | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 5: Atom Type 3: IPv4 Prefix with Color 306 Length: MUST be 10. 308 Flags: 2 octets, reserved for future use, MUST be set to 0 upon the 309 sender and MUST be ignored upon the reciever. 311 IPv4: 4-octet IPv4 address, SR-TE tunnel Endpoint for redirection 312 Color: 4 octets, SR-TE tunnel Color for redirection 314 2.3.4. Atom Type 4: IPv4 Prefix with Color and Weight 316 Indicating the redirection path is weighted and to a SR-TE tunnel. 317 The format is shown below: 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type: 4 | Length: 11 | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Flag(2) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | IPv4(4) | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Color(4) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Weight(1) | 331 +-+-+-+-+-+-+-+-+ 333 Figure 6: Atom Type 4: IPv4 Prefix with Color and Weight 335 Length: MUST be 11. 337 Flags: 2 octets, reserved for future use, MUST be set to 0 upon the 338 sender and MUST be ignored upon the reciever. 340 IPv4: 4-octet IPv4 address, SR-TE tunnel Endpoint for redirection 342 Color: 4 octets, SR-TE tunnel Color for redirection 344 Weight: 1 octet, values from 1~255, load balancing weight 346 2.3.5. Atom Type 5: IPv6 Prefix Only 348 Indicating the redirection path is unweighted and to a IPv6 address. 349 The format is shown below: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type: 5 | Length: 18 | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Flag(2) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | IPv6(16) | 359 ~ ~ 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 7: Atom Type 5: IPv6 Prefix Only 364 Length: MUST be 18. 366 Flags: 2 octets, reserved for future use, MUST be set to 0 upon the 367 sender and MUST be ignored upon the reciever. 369 IPv6: 16-octet IPv6 address, redirection destination 371 2.3.6. Atom Type 6: IPv6 Prefix with Weight 373 Indicating the redirection path is weighted and to a IPv6 address. 374 The format is shown below: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type: 6 | Length: 19 | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Flag(2) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | IPv6(16) | 384 ~ ~ 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Weight(1) | 387 +-+-+-+-+-+-+-+-+ 389 Figure 8: Atom Type 6: IPv6 Prefix with Weight 391 Length: MUST be 19. 393 Flags: 2 octets, reserved for future use, MUST be set to 0 upon the 394 sender and MUST be ignored upon the reciever. 396 IPv6: 16-octet IPv6 address, redirection destination 398 Weight: 1 octet, values from 1~255, load balancing weight 400 2.3.7. Atom Type 7: IPv6 Prefix with Color 402 Indicating the redirection path is unweighted and to a SRv6 tunnel. 403 The format is shown below: 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Type: 7 | Length: 22 | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Flag(2) | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | IPv6(16) | 413 ~ ~ 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Color(4) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 9: Atom Type 7: IPv6 Prefix with Color 420 Length: MUST be 22. 422 Flags: 2 octets, reserved for future use, MUST be set to 0 upon the 423 sender and MUST be ignored upon the reciever. 425 IPv6: 16-octet IPv6 address, SRv6 tunnel Endpoint for redirection 427 Color: 4 octets, SRv6 tunnel Color for redirection 429 2.3.8. Atom Type 8: IPv6 Prefix with Color and Weight 431 Indicating the redirection path is weighted and to a SRv6 tunnel. 432 The format is shown below: 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type: 8 | Length: 23 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Flag(2) | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | IPv6(16) | 442 ~ ~ 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Color(4) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Weight(1) | 447 +-+-+-+-+-+-+-+-+ 448 Figure 10: Atom Type 8: IPv6 Prefix with Color and Weight 450 Length: MUST be 23. 452 Flags: 2 octets, reserved for future use, MUST be set to 0 upon the 453 sender and MUST be ignored upon the reciever. 455 IPv6: 16-octet IPv6 address, SRv6 tunnel Endpoint for redirection 457 Color: 4 octets, SRv6 tunnel Color for redirection 459 Weight: 1 octet, values from 1~255, load balancing weight 461 3. Scenarios 463 This section describes a few use-case scenarios when deploying 464 "Redirect Load Balancing Group" community type. 466 Weighted atom types: Atoms contain a Weight field, such as Type 2, 467 4, 6, 8 469 Unweighted atom types: Atoms do not contain a Weight field, such as 470 Type 1, 3, 5, 7 472 3.1. ECMP 474 A system that originates a flowspec route with a "Redirect Load 475 Balancing Group" community, among which its parameter TLV contains 476 more than 1 atoms. If not all atoms are of a weighted type, these 477 atoms will form a ECMP group. 479 Implementations MUST be prepared to accept a Parameter TLV with both 480 weighted and unweighted atoms. In this case, the Weight field of the 481 weighted atom SHOULD be ignored. 483 3.2. UCMP 485 A system that originates a flowspec route with a "Redirect Load 486 Balancing Group" community, among which its parameter TLV contains 487 more than 1 atoms. If all atoms are of a weighted type, these atoms 488 will form a UCMP group. 490 In this case, the Weight field value of these atoms SHOULD NOT be 491 ignored, and the values are used as the ratio of the UCMP group. 493 4. Error Handling 495 Comply with Error Handling Procedure in "BGP Community Container 496 Attribute" [I-D.ietf-idr-wide-bgp-communities]. 498 In addition: 500 4.1. Redirect Group Wide Community Parameter TLV 502 A "Redirect Load Balancing Group" community container with no or 503 multiple parameter TLVs SHOULD be considered malformed, and a "treat 504 as withdraw" behavior is expected. 506 4.2. Redirect Group Wide Community Parameter Sub-TLVs 508 If the length and type of a sub-TLV do not match, the "Redirect Load 509 Balancing Group" community container SHOULD be considered malformed, 510 and a "treat as withdraw" behavior is expected. 512 5. IANA Considerations 514 5.1. BGP Wide Communities Community Type : Redirect Group 516 This document requests a new community value under "Registered Type 1 517 BGP Wide Community Community Types" registery. This registery is 518 defined and requested in "BGP Community Container Attribute" 519 [I-D.ietf-idr-wide-bgp-communities]. 521 Requested value: 523 Name Type Value 524 ---- ---------- 525 Redirect Load Balancing Group TBD 527 6. Security Considerations 529 A system that originates a flowspec route with a "Redirect Load 530 Balancing Group" BGP wide community can cause many receivers of that 531 route to redirect traffic to a single next-hop, overwhelming that 532 next-hop and resulting in inadvertent or deliberate denial-of- 533 service. This is also a concern about the "redirect to IP" extended 534 community, therefore this document introduces no additional security 535 considerations than those already covered in [RFC8955]. 537 7. References 539 7.1. Normative References 541 [I-D.ietf-idr-flowspec-redirect-ip] 542 Uttaro, J., Haas, J., Texier, M., Karch, A., Ray, S., 543 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 544 IP Action", Work in Progress, Internet-Draft, draft-ietf- 545 idr-flowspec-redirect-ip-02, 5 February 2015, 546 . 549 [I-D.ietf-idr-wide-bgp-communities] 550 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 551 and P. Jakma, "BGP Community Container Attribute", Work in 552 Progress, Internet-Draft, draft-ietf-idr-wide-bgp- 553 communities-06, 10 January 2022, 554 . 557 [I-D.jiang-idr-ts-flowspec-srv6-policy] 558 Jiang, W., Liu, Y., and S. Chen, "Traffic Steering using 559 BGP Flowspec with SRv6 Policy", Work in Progress, 560 Internet-Draft, draft-jiang-idr-ts-flowspec-srv6-policy- 561 04, 11 July 2021, . 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, 566 DOI 10.17487/RFC2119, March 1997, 567 . 569 7.2. References 571 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 572 Bacher, "Dissemination of Flow Specification Rules", 573 RFC 8955, DOI 10.17487/RFC8955, December 2020, 574 . 576 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 577 "Dissemination of Flow Specification Rules for IPv6", 578 RFC 8956, DOI 10.17487/RFC8956, December 2020, 579 . 581 Authors' Addresses 583 Zhiwen Wu 584 Huawei Technologies 585 No. 156 Beiqing Road 586 Beijing 587 100095 588 P.R. China 589 Email: wuzhiwen1@huawei.com 591 Haibo Wang 592 Huawei Technologies 593 No. 156 Beiqing Road 594 Beijing 595 100095 596 P.R. China 597 Email: rainsword.wang@huawei.com 599 Lili Wang 600 Huawei Technologies 601 No. 156 Beiqing Road 602 Beijing 603 100095 604 P.R. China 605 Email: lily.wong@huawei.com 607 Zhen Tan 608 Huawei Technologies 609 No. 156 Beiqing Road 610 Beijing 611 100095 612 P.R. China 613 Email: tanzhen6@huawei.com