BGP Flowspec Redirect Load Balancing Group Community

"Redirect to IP Extended Community", defined in , allows traffic to be redirected to a specific IPv4 or IPv6 address, and defines the redirection action to a SRv6 tunnel by additionally carrying the "Color Extended Community". However, scenarios involving redirection load balancing are not described in both documents. Although in some implementations, Equal-cost multi-path(ECMP) of "Redirect to IP" action can be achieved by encoding multiple redirect Extended Communities, the current set of mechanisms can hardly support neither ECMP of SRv6 tunnels nor unequal-cost multi-path(UCMP) of either types. This document defines an extension to "BGP Community Container Attribute", the "Redirect Load Balancing Group" community. It is a new type of wide community container attribute with encoding format of multiple redirection path TLVs. Each of these TLVs represents a different redirection action. It allows traffic redirection to a load balancing group and supports both ECMP and UCMP scenarios. The "Redirect Load Balancing Group" community is intended to be used within flowspec-v1 scenarios, the compatibility and interactions with flowspec-v2 is outside the scope of this document.

This document introduces the following terms: Equal-Cost Multi-Path Unequal-Cost Multi-Path Redirect Load Balancing Group Community, a new type of BGP Community Container Attribute defined by this document Sub-tlv of the BGP Wide Community Parameter TLV, each represents a redirection path

This document defines a new type of "BGP Community Container Attribute", the "Redirect Load Balancing Group" community type. The format complies with "BGP Community Container Attribute" and is shown below:

The Type, Flags, Reserved and Length fields comply with the "BGP Community Container Attribute Common Header" definition. The container type MUST be 1, which represents BGP Wide Community. The Length field represents the total length of the container's contents in octets.

The Community Value, Source AS Number and Context AS Number fields comply with the corresponding definition in "BGP Community Container Attribute". Community Value: 4 octets value that represents the "Redirect Load Balancing Group" community type. The value is TBD and requires IANA registration; See Section 5.1.

The BGP Wide Community Parameter TLV (Sub-Type 3) contains a list of path-tlvs, comply with "BGP Wide Community Parameter(s) TLV" section of "BGP Community Container Attribute". The Parameter TLV MUST present and SHOULD appear only once in a "Redirect Load Balancing Group" community container, no or multiple present SHOULD be considered malformed. Sub-Type: Type 3 (BGP Wide Community Parameter TLV) Length: Length of all the sub-TLVs in octets.

The list of path-tlvs that Param Tlv contains. Each path-tlv represents a different redirection path. The general format of the sub-TLVs comply with path-tlvs' format defined in "BGP Community Container Attribute", as below:

The Type field is an octet from 1~254 (0 and 255 are reserved). Supported type of the sub-TLVs includes: IPv4 Prefix Only IPv4 Prefix with Weight IPv4 Prefix with Color IPv4 Prefix with Color and Weight IPv6 Prefix Only IPv6 Prefix with Weight IPv6 Prefix with Color IPv6 Prefix with Color and Weight These sub-TLV types SHOULD be used exclusively within "Redirect Load Balancing Group" community containers. The Length represents the length of the "Value" field in octets, and it is fixed for each specific sub-TLV. If the length and type of a sub-TLV do not match, the "Redirect Load Balancing Group" community container SHOULD be considered malformed. If a sub-TLV is a total dupilication of a previous one, the latter sub-TLV MUST be ignored. In principle, sub-TLVs of different types may be combined in any mode. The supported combinations depend on the specific implementation.

Indicating the redirection path is unweighted and to a IPv4 address. The format is shown below:

Length: MUST be 6. Flags: 2 octets, reserved for future use, MUST be set to 0 upon the sender and MUST be ignored upon the receiver. IPv4: 4-octet IPv4 address, redirection destination

Indicating the redirection path is weighted and to a IPv4 address. The format is shown below:

Length: MUST be 7. Flags: 2 octets, reserved for future use, MUST be set to 0 upon the sender and MUST be ignored upon the receiver. IPv4: 4-octet IPv4 address, redirection destination Weight: 1 octet, values from 1~255, load balancing weight

Indicating the redirection path is unweighted and to a SR-TE tunnel. The format is shown below:

Length: MUST be 10. Flags: 2 octets, reserved for future use, MUST be set to 0 upon the sender and MUST be ignored upon the receiver. IPv4: 4-octet IPv4 address, SR-TE tunnel Endpoint for redirection Color: 4 octets, SR-TE tunnel Color for redirection

Indicating the redirection path is weighted and to a SR-TE tunnel. The format is shown below:

Length: MUST be 11. Flags: 2 octets, reserved for future use, MUST be set to 0 upon the sender and MUST be ignored upon the receiver. IPv4: 4-octet IPv4 address, SR-TE tunnel Endpoint for redirection Color: 4 octets, SR-TE tunnel Color for redirection Weight: 1 octet, values from 1~255, load balancing weight

Indicating the redirection path is unweighted and to a IPv6 address. The format is shown below:

Length: MUST be 18. Flags: 2 octets, reserved for future use, MUST be set to 0 upon the sender and MUST be ignored upon the receiver. IPv6: 16-octet IPv6 address, redirection destination

Indicating the redirection path is weighted and to a IPv6 address. The format is shown below:

Length: MUST be 19. Flags: 2 octets, reserved for future use, MUST be set to 0 upon the sender and MUST be ignored upon the receiver. IPv6: 16-octet IPv6 address, redirection destination Weight: 1 octet, values from 1~255, load balancing weight

Indicating the redirection path is unweighted and to a SRv6 tunnel. The format is shown below:

Length: MUST be 22. Flags: 2 octets, reserved for future use, MUST be set to 0 upon the sender and MUST be ignored upon the receiver. IPv6: 16-octet IPv6 address, SRv6 tunnel Endpoint for redirection Color: 4 octets, SRv6 tunnel Color for redirection

Indicating the redirection path is weighted and to a SRv6 tunnel. The format is shown below:

Length: MUST be 23. Flags: 2 octets, reserved for future use, MUST be set to 0 upon the sender and MUST be ignored upon the receiver. IPv6: 16-octet IPv6 address, SRv6 tunnel Endpoint for redirection Color: 4 octets, SRv6 tunnel Color for redirection Weight: 1 octet, values from 1~255, load balancing weight

This section describes a few use-case scenarios when deploying "Redirect Load Balancing Group" community type. Path-tlvs contain a Weight field, such as Type 2, 4, 6, 8 Path-tlvs do not contain a Weight field, such as Type 1, 3, 5, 7

A system that originates a flowspec route with a "Redirect Load Balancing Group" community, among which its parameter TLV contains more than 1 path-tlvs. If not all path-tlvs are of a weighted type, these path-tlvs will form a ECMP group. Implementations MUST be prepared to accept a Parameter TLV with both weighted and unweighted path-tlvs. In this case, the Weight field of the weighted path-tlv SHOULD be ignored.

A system that originates a flowspec route with a "Redirect Load Balancing Group" community, among which its parameter TLV contains more than 1 path-tlvs. If all path-tlvs are of a weighted type, these path-tlvs will form a UCMP group. In this case, the Weight field value of these path-tlvs SHOULD NOT be ignored, and the values are used as the ratio of the UCMP group.

In the absence of explicit configuration, a Redirect Group attribute MUST be validated before it is used for redirection action or sent to a BGP peer. The validation procedure for a Redirect Group attribute follows the following rules: Each Path-tlv of the Redirect Group attribute SHOULD be validated separately. The validation of each path follows the validation procedure of Redirect to IP Action. A Redirect Group attribute SHOULD be considered verified, only after all path-tlvs in the Redirect Group attribute are verified. If any path-tlvs are invalid, these paths SHOULD NOT participate in load-balance calculation and used for redirection actions. If any path-tlvs are invalid, the Redirect Group attribute SHOULD NOT be sent to a BGP peer.

Comply with Error Handling Procedure in "BGP Community Container Attribute". In addition:

A "Redirect Load Balancing Group" community container with no or multiple parameter TLVs SHOULD be considered malformed, and a "treat as withdraw" behavior is expected.

If the length and type of a sub-TLV do not match, the "Redirect Load Balancing Group" community container SHOULD be considered malformed, and a "treat as withdraw" behavior is expected.

The Extended Community attributes for redirection mentioned in this section include: Redirect to IP Extended Community Redirect to IPv6 Extended Community Redirect to SRv6 Policy

There SHOULD be an explicit configuration to control whether the Redirect Group attribute is used for redirection actions. In the absence of the explicit configuration(by default), the Redirect Group attribute MAY NOT take precedence over Extended Community attribute. With the explicit configuration, the Redirect Group attribute MAY take precedence over Extended Community attribute for redirection. For clarity, the first scenario, in which the Redirect Group attribute does not take precedence, is called configuration situation A. And the second scenario is called configuration situation B.

While receiving a flowspec route with Redirect Group attribute from a BGP peer: In configuration situation A, the Redirect Group attribute SHOULD NOT be used for redirection actions. If the route carries Extended Community attributes for redirection, these attributes MAY be used to generate the redirection actions. The Redirect Group attribute SHOULD still be saved locally and advertised with the fowspec route to other appropriate peers. In configuration situation B, the Redirect Group attribute SHOULD take precedence over Extended Community attribute for redirection. If the route carries Extended Community attributes for redirection, these attributes SHOULD NOT be used to generate the redirection actions, but SHOULD still be saved locally and advertised with the fowspec route to other appropriate peers.

While encoding a local-generated flowspec route: In configuration situation A, a Redirect Group attribute SHOULD NOT be encoded. Appropriate Extended Community attributes MAY be used for specifying redirection actions. In configuration situation B, the Redirect Group attribute SHOULD be encoded for specifying redirection actions, despite of there is one or more paths. For the sake of compatibility, we MAY select the path with the lowest IP address from the paths of the Redirect Group attribute and encode it with appropriate Extended Community attributes. During this selection, an IPv4 address is preferred over an IPv6 address. While encoding a flowspec route learned from other BGP peers: In configuration situation A, the Redirect Group attribute MUST be encoded without modification. In configuration situation B, the Redirect Group attribute MUST pass the validation procedure before it is encoded and sent to a BGP peer.

This document requests a new community value under "Registered Type 1 BGP Wide Community Community Types" registery. This registery is defined and requested in "BGP Community Container Attribute". Requested value:

A system that originates a flowspec route with a "Redirect Load Balancing Group" BGP wide community can cause many receivers of that route to redirect traffic to a single next-hop, overwhelming that next-hop and resulting in inadvertent or deliberate denial-of-service. This is also a concern about the "redirect to IP" extended community, therefore this document introduces no additional security considerations than those already covered in .