BGP FlowSpec Extensions for Routing Policy Distribution (RPD)

The traffic-action extended community consists of 6 bytes of which only the 2 least significant bits of the 6th byte (from left to right) are currently defined in . Terminal Action (bit 47) and Sample (bit 46) defines in , this document defines Route Policy Distribution Flag(Bit 45). The Flow Specification Traffic Actions for Routing Policy Distribution:

Route Policy Distribution Flag(Bit 45): When this bit is set, the corresponding filtering rules will be used as Route Policy.

This document defines and uses a new BGP attribute called the "BGP Policy attribute". This is an optional BGP attribute. The format of this attribute is defined as follows:

Match fields: Match Fields define the matching criteria for the BGP Policy Attribute. Action fields: Action fields define the action being applied to the target route.

Match Fields define the matching criteria for the BGP Policy Attribute.

Match Type: 0: Permit, specifies the permit mode of a match rule. If a route matches the matching criteria of the BGP Policy Attribute, the actions defined by the Action fields of the BGP Policy Attribute are performed. If a route does not match the matching criteria for the BGP Policy Attribute, then nothing needs to do with this route. 1: Deny, specifies the deny mode of a match rule. In the deny mode, If a route does not match the matching criteria of the BGP Policy Attribute, the actions defined by the Action fields of the BGP Policy Attribute are performed. If a route matches the matching criteria of the BGP Policy Attribute, then nothing needs to do with this route. Number of Sub-TLVs: The number of Sub-TLVs contain in Match fields. The contents of Match fields are encoded as Sub-TLVs, where each TLV has the following format:

Type: The Type field contains a value of 1-65534. The values 0 and 65535 are reserved for future use. Length: The Length field represents the total length of a given TLV's value field in octets. Values: The Value field contains the TLV value. Supported format of the TLVs can be: Type 1: IPv4 Neighbor Type 2: IPv6 Neighbor Type 3: ASN List ... To be added in later versions.

Action fields define the action being applied to the targeted route.

Action Type: The Action Type field contains a value of 1-65534. The values 0 and 65535 are reserved for future use. Action Length: The Action Length field represents the total length of the Action Values in octets. Action Values: The Action Values field contain parameters of the action. Supported format of the TLVs can be: Type 1: Route-Preference Type 2: Route-Prepend-AS ... To be added in later versions.

The traffic destined for Prefix1 needs to be scheduled to link Speaker1 -> IGW2 for transmission. The Policy Controller constructs a BGP-FS RPD route and pushes it to all the IGW routers, the route carries: Prefix1 in the Destination Prefix component of the BGP-FS NLRI; Flow Specification Traffic Action Extended Community with the Route Policy Distribution Flag(Bit 45) set. When this bit is set, the corresponding filtering rules will be used as Routing Policies. NO_ADVERTISE Community BGP Policy Attribute: Match Type: 2, Deny IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer Speaker1 Action Type: Route-Prepend-AS Action Value: Prepend-AS times is 5 IGW1 processes the received BGP-FS RPD route as follows: IGW1 gets the target prefix Prefix1 from the Destination Prefix component in the BGP FS NLRI of the BGP FS RPD route; IGW1 identifies the Route Policy Distribution Flag carrying in the Flow Specification Traffic Action Extended Community, then IGW1 knows that the corresponding filtering rules will be used as Routing Policies. IGW1 uses the target prefix Prefix1 to choose the matching routes, in this case, IGW1 will choose the current best route of Prefix1; IGW1 gets the matching criteria from the BGP Policy Attribute: Local BGP Speaker IGW2, Remote BGP Speaker1; IGW1 gets the action from the BGP Policy Attribute: Route-Prepend-AS, 5 times; IGW1 checks the matching criteria and finds that it doesn't hits the matching criteria: Local BGP Speaker IGW2, Remote BGP Speaker1, at the same time the Match Type is "Deny" mode, so IGW1 sends the best route of Prefix1 to Speaker1 and Speaker2 with performing the Action instructions from the BGP-FS RPD route: Prepend Local AS 5 times. IGW2 processes the received BGP FS RPD route as follows: IGW2 gets the target prefix Prefix1 from the Destination Prefix component in the BGP-FS NLRI of the BGP FS RPD route; IGW2 identifies the Route Policy Distribution Flag carrying in the Flow Specification Traffic Action Extended Community, then IGW2 knows that the corresponding filtering rules will be used as Routing Policies. IGW2 uses the target prefix Prefix1 to choose the matching routes, in this case, IGW2 will choose the current best route of Prefix1; IGW2 gets the matching criteria from the BGP Policy Attribute: Local BGP Speaker IGW2, Remote BGP Speaker1; IGW2 gets the action from the BGP Policy Attribute: Route-Prepend-AS, 5 times; IGW2 checks the matching criteria and finds that there is a speaker which hits the matching criteria: Local BGP Speaker IGW2, Remote BGP Peer Speaker1, but the Match Type is "Deny" mode, so IGW2 sends the best route of Prefix1 to Speaker1, without performing the Action instructions from the BGP-FS RPD route. At the same time, IGW2 sends the best route of Prefix1 to Speaker2 with performing the Action instructions from the BGP-FS RPD route: Prepend Local AS 5 times. In the similar manner, other IGWs will perform the same Action instructions as IGW1. Then the traffic destined for Prefix1 has been be scheduled to link L3 for transmission.

In this scenario, if the bandwidth usage of a link exceeds the specified threshold, the Policy Controller automatically identifies which traffic needs to be scheduled and the Policy Controller automatically calculates traffic control paths based on network topology and traffic information. For example, the outbound traffic destined for Prefix2 needs to be scheduled to link IGW2 -> Speaker1 for transmission. The Policy Controller sends a BGP-FS RPD route to IGW2, the route carries: Prefix2 in the Destination Prefix component of the BGP-FS NLRI; Flow Specification Traffic Action Extended Community with the Route Policy Distribution Flag(Bit 45) set. When this bit is set, the corresponding filtering rules will be used as Routing Policies. NO_ADVERTISE Community BGP Policy Attribute: Match Type: 1, Permit IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer Speaker1 Action Type: Route-Preference Action Value: none IGW2 processes the received BGP FS RPD route as follows: IGW2 gets the target prefix Prefix2 from the Destination Prefix component in the BGP-FS NLRI of the BGP FS RPD route; IGW2 identifies the Route Policy Distribution Flag carrying in the Flow Specification Traffic Action Extended Community, then IGW2 knows that the corresponding filtering rules will be used as Routing Policies. IGW2 uses the target prefix Prefix2 to choose the matching routes, in this case, the prefix Prefix2 has two more routes:

IGW2 gets the matching criteria from the BGP Policy Attribute: Local BGP Speaker IGW2, Remote BGP Peer Speaker1; IGW2 gets the action from the BGP Policy Attribute: Route-Preference; So IGW2 chooses the BGP route received from Speaker1 instead of Speaker2 as the best route and the outbound traffic destined for Prefix2 can be scheduled to link L3 for transmission.

This section describes the option 2 for protocol extensions, which is completely different from section 5.2 by reusing BGP Wide Community introduced in . BGP Wide Community Attribute is a very useful tool that it can be used to convey different kinds of routing policies.

Wide Community Atoms define in , in that draft it defines Type 1 to Type 8. New wide community atoms have to be introduced since the entrance and exit of traffic need to be designated precisely.

Supported format of the TLVs can be: Type 1: Autonomous System number list Type 2: IPv4 prefix (1 octet prefix length + prefix) list Type 3: IPv6 prefix (1 octet prefix length + prefix) list Type 4: Integer list Type 5: IEEE Floating Point Number list Type 6: Neighbor Class list Type 7: User-defined Class list7 Type 8: UTF-8 String Type TBD: BGP IPv4 neighbor --- Newly introduced in this draft, which contains the BGP session IPv4 local address and the BGP session IPv4 peer address. Type TBD: BGP IPv6 neighbor --- Newly introduced in this draft, which contains the BGP session IPv6 local address and the BGP session IPv6 peer address.

As required in the case, traffic from PE1 to Prefix1 need to enter through L3, so IGWs except IGW2 should prepend ASN list to Prefix1 when populating to AS100. As shown in figure below, community "PREPEND N TIMES BY AS" and "Exclude Target(s) TLV" are be used. The encoding example using BGP Wide Community:

"PREPEND N TIMES BY AS" Wide Community has been defined in . The traffic destined for Prefix1 needs to be scheduled to link Speaker1 -> IGW2 for transmission. The Policy Controller constructs a BGP-FS RPD route and pushes it to all the IGW routers, the route carries: Prefix1 in the Destination Prefix component of the BGP-FS NLRI; Flow Specification Traffic Action Extended Community with the Route Policy Distribution Flag(Bit 45) set. When this bit is set, the corresponding filtering rules will be used as Routing Policies. NO_ADVERTISE Community Wide BGP Community Attribute:

IGW1 processes the received BGP-FS RPD route as follows: IGW1 gets the target prefix Prefix1 from the Destination Prefix component in the BGP FS NLRI of the BGP FS RPD route; IGW1 identifies the Route Policy Distribution Flag carrying in the Flow Specification Traffic Action Extended Community, then IGW1 knows that the corresponding filtering rules will be used as Routing Policies. IGW1 uses the target prefix Prefix1 to choose the matching routes, in this case, IGW1 will choose the current best route of Prefix1; IGW1 gets the action type from the Wide BGP Community Attribute: PREPEND N TIMES BY AS; IGW1 gets the matching criteria from the Wide BGP Community Attribute: Exclude the BGP IPv4 neighbor: <Local BGP Speaker IGW2, Remote BGP Speaker1>; IGW1 gets the parameter for "PREPEND N TIMES BY AS" from the Wide BGP Community Attribute: 5 times; IGW1 checks the matching criteria and finds that it doesn't hits the exclude matching criteria: Local BGP Speaker IGW2, Remote BGP Speaker1, so IGW1 sends the best route of Prefix1 to Speaker1 and Speaker2 with performing the Action instructions from the BGP-FS RPD route: Prepend Local AS 5 times. IGW2 processes the received BGP FS RPD route as follows: IGW2 gets the target prefix Prefix1 from the Destination Prefix component in the BGP-FS NLRI of the BGP FS RPD route; IGW2 identifies the Route Policy Distribution Flag carrying in the Flow Specification Traffic Action Extended Community, then IGW2 knows that the corresponding filtering rules will be used as Routing Policies. IGW2 uses the target prefix Prefix1 to choose the matching routes, in this case, IGW2 will choose the current best route of Prefix1; IGW2 gets the action type from the Wide BGP Community Attribute: PREPEND N TIMES BY AS; IGW2 gets the matching criteria from the BGP Policy Attribute: Exclude the BGP IPv4 neighbor: <Local BGP Speaker IGW2, Remote BGP Speaker1>; IGW2 gets the parameter for "PREPEND N TIMES BY AS" from the Wide BGP Community Attribute: 5 times; IGW2 checks the matching criteria and finds that there is a speaker which hits the exclude matching criteria: Local BGP Speaker IGW2, Remote BGP Peer Speaker1, so IGW2 sends the best route of Prefix1 to Speaker1 without performing the Action instructions from the BGP-FS RPD route, at the same time, IGW2 sends the best route of Prefix1 to Speaker2 with performing the Action instructions from the BGP-FS RPD route: Prepend Local AS 5 times. In the similar manner, other IGWs will perform the same Action instructions as IGW1. Then the traffic destined for Prefix1 has been be scheduled to link L3 for transmission.

As required in the case, traffic from PE2 to Prefix2 need to exit through L3, so IGWs should perfer the route from IGW2 to Speaker1. As shown in figure below, community "LOCAL PREFERENCE" and "Target(s) TLV" are be used. The encoding example using BGP Wide Community:

"LOCAL PREFERENCE" Wide Community has been defined in In this scenario, if the bandwidth usage of a link exceeds the specified threshold, the Policy Controller automatically identifies which traffic needs to be scheduled and the Policy Controller automatically calculates traffic control paths based on network topology and traffic information. For example, the outbound traffic destined for Prefix2 needs to be scheduled to link IGW2 -> Speaker1 for transmission. The Policy Controller sends a BGP-FS RPD route to IGW2, the route carries: Prefix2 in the Destination Prefix component of the BGP-FS NLRI; Flow Specification Traffic Action Extended Community with the Route Policy Distribution Flag(Bit 45) set. When this bit is set, the corresponding filtering rules will be used as Routing Policies. NO_ADVERTISE Community Wide BGP Community Attribute:

IGW2 processes the received BGP FS RPD route as follows: IGW2 gets the target prefix Prefix2 from the Destination Prefix component in the BGP-FS NLRI of the BGP FS RPD route; IGW2 identifies the Route Policy Distribution Flag carrying in the Flow Specification Traffic Action Extended Community, then IGW2 knows that the corresponding filtering rules will be used as Routing Policies. IGW2 uses the target prefix Prefix2 to choose the matching routes, in this case, the prefix Prefix2 has two more routes:

IGW2 gets the action type from the Wide BGP Community Attribute: LOCAL PREFERENCE; IGW2 gets the matching criteria from the Wide BGP Community Attribute: Local BGP Speaker IGW2, Remote BGP Peer Speaker1; IGW2 gets the parameter for "LOCAL PREFERENCE" from the Wide BGP Community Attribute: increment 100; So IGW2 chooses the BGP route received from Speaker1 instead of Speaker2 as the best route and the outbound traffic destined for Prefix2 can be scheduled to link L3 for transmission.

It is necessary to negotiate the capability to support BGP FlowSpec Extensions for Route Policy Distribution (RPD). The BGP FS RPD Capability is a new BGP capability . The Capability Code for this capability is to be specified by the IANA. The Capability Length field of this capability is variable. The Capability Value field consists of one or more of the following tuples:

The meaning and use of the fields are as follows: Address Family Identifier (AFI): This field is the same as the one used in . Subsequent Address Family Identifier (SAFI): This field is the same as the one used in . Send/Receive: This field indicates whether the sender is (a) willing to receive Route Policies via BGP FLowSpec from its peer (value 1), (b) would like to send Route Policies via BGP FLowSpec to its peer (value 2), or (c) both (value 3) for the <AFI, SAFI>.