BGP FlowSpec Extensions for Routing Policy
Distribution (RPD)HuaweiHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comChina Telcom Co., Ltd.109 West Zhongshan Ave,Tianhe DistrictGuangzhou510630Chinaoul@gsta.comChina Telcom Co., Ltd.109 West Zhongshan Ave,Tianhe DistrictGuangzhou510630Chinaluoyuj@gsta.comTencentTengyun Building,Tower A ,No. 397 Tianlin RoadShanghaiXuhui District200233Chinajasonlu@tencent.comHuaweiHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinazhuangshunwan@huawei.comHuaweiHuawei Bld., No.156 Beiqing Rd.Beijing100095Chinaeric.wu@huawei.comThis document describes a mechanism to use BGP Flowspec address
family as routing-policy distribution protocol. This mechanism is called
BGP FlowSpec Extensions for Routing Policy Distribution (BGP-FS
RPD).The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.Some difficulties exist when optimize traffic paths on a traditional
IP network:Traffic can only be adjusted device by device. All routers that
the traffic traverses need to be configured. The configuration
workload is heavy. The operation is not only time consuming but also
prone to misconfiguration for Service Providers.The routing policies used to control network routes are complex,
posing difficulties to subsequent maintenance, high maintenance
skills are required.Hence, an automatic mechanism for setting up routing policies is
desirable which can simplify the complexity of routing policies
configuration. This document describes a mechanism to use BGP Flowspec
address family as route-policy distribution
protocol. This mechanism is called BGP FlowSpec Extensions for Routing
Policy Distribution (BGP-FS RPD).BGP Flow Specification route: BGP Flow Specification routes are
defined in RFC 5575. Each BGP Flow Specification route contains BGP
Network Layer Reachability Information (NLRI) and Extended Community
Attributes, which carry traffic filtering rules and actions to be taken
on filtered traffic.BGP Flow Specification peer relationship: A BGP Flow Specification
peer relationship is established between the device that generates BGP
Flow Specification routes and each network ingress that will transmit
the BGP Flow Specification routes. After receiving the BGP Flow
Specification routes, the peer delivers preferred BGP Flow Specification
routes to the forwarding plane. The routes are then converted into
traffic policies that control attack traffic.ACL:Access Control ListBGP: Border Gateway ProtocolFS: Flow SpecificationPBR:Policy-Based RoutingRPD: Routing Policy DistributionVPN: Virtual Private NetworkIt is obvious that providers have the requirements to adjust their
business traffic from time to time because:Business development or network failure introduces link
congestion and overload.Network transmission quality decreased as the result of delay,
loss and need to adjust traffic to other paths.To control OPEX and CPEX, prefer the transit provider with lower
price.In the scenario below, for reasons above, the provider of AS100
saying P may wish the inbound traffic from AS200 enters AS100 through
link L3 instead of others. Since P doesn't have administration over
AS200, so there is no way for P to modify the route selection criteria
directly.In this scenario, the provider of AS100 saying P wishes to prefer
link L3 for the traffic to the destination Prefix2 among multiple
exits and links. This preference can be dynamic and change frequently
because of the reasons above. So the provider P expects an efficient
and convenient solution.BGP FlowSpec leverages the BGP control plane
to simplify the distribution of filter rules. New filter rules can be
injected to all BGP peers simultaneously without changing router
configuration. Though the typical application of it is for DDOS
mitigation, it doesn’t mean BGP Flowspec only takes effect on the
forwarding plane.This document introduces a mechanism that uses BGP Flowspec as a
route-policy distribution protocol. It can be the same powerful as the
device-based route-policy while still has the efficiency and convenience
of BGP Flowspec.This draft will use the term BGP-FS RPD as the abbreviation of
FlowSpec Extensions for Routing Policy Distribution.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 NeighborType 2: IPv6 NeighborType 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-PreferenceType 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, DenyIPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote
BGP Peer Speaker1Action Type: Route-Prepend-ASAction Value: Prepend-AS times is 5IGW1 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, PermitIPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote
BGP Peer Speaker1Action Type: Route-PreferenceAction Value: noneIGW2 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 listType 2: IPv4 prefix (1 octet prefix length + prefix) listType 3: IPv6 prefix (1 octet prefix length + prefix) listType 4: Integer listType 5: IEEE Floating Point Number listType 6: Neighbor Class listType 7: User-defined Class list7Type 8: UTF-8 StringType 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>.Routing policies are used to filter routes and control how routes
are received and advertised. If route attributes, such as
reachability, are changed, the path along which network traffic passes
changes accordingly.When advertising, receiving, and importing routes, the router
implements certain policies based on actual networking requirements to
filter routes and change the attributes of the routes. Routing
policies serve the following purposes:Control route advertising: Only routes that match the rules
specified in a policy are advertised.Control route receiving: Only the required and valid routes are
received. This reduces the size of the routing table and improves
network security.Filter and control imported routes: A routing protocol may
import routes discovered by other routing protocols. Only routes
that satisfy certain conditions are imported to meet the
requirements of the protocol.Modify attributes of specified routes Attributes of the routes:
that are filtered by a routing policy are modified to meet the
requirements of the local device.Configure fast reroute (FRR): If a backup next hop and a backup
outbound interface are configured for the routes that match a
routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be
implemented.Routing policies are implemented using the following
procedures:Define rules: Define features of routes to which routing
policies are applied. Users define a set of matching rules based
on different attributes of routes, such as the destination address
and the address of the router that advertises the routes.Implement the rules: Apply the matching rules to routing
policies for advertising, receiving, and importing routes.The following people have substantially contributed to the definition
of the BGP-FS RPD and to the editing of this document:TBD.TBD.The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong,
Haibo Wang, Lucy Yong, Qiandeng Liang, Zhenqiang Li for their comments
to this work.