Route policy distribution (RPD) is used to distribute route-policies dynamically.
Without RPD, route-policies can be generated only through manual configuration, and then the route-policies are applied to peers. Such a generation mode is not applicable when the route-policies need to be adjusted dynamically and frequently. For example, in the inbound traffic optimization scenario with an NCE, the NCE monitors the traffic bandwidth usage on the network in real time, and users perform traffic optimization based on the analysis result. Specifically, for traffic optimization purposes, route-policies need to be used to modify route attributes to control the route selection on the peer end. However, the traffic bandwidth usage constantly changes, leading to the constant changes of traffic optimization policies. In this case, route-policies configured manually are not suitable. RPD provides a dynamic route-policy distribution mode for the NCE. With RPD, route-policy information is transmitted through the BGP RPD address family.
After RPD is configured, you can use the NCE to monitor and control traffic in real time. The traffic optimization policy configurations are performed on the NCE, not on forwarders. Forwarders receive RPD routes from the NCE, generate route-policies based on the routes, and implement the route-policies.
RPD route: Carries route-policy information and distributes the information to peers in the BGP RPD address family. After learning the RPD route, the receiver converts it into a route-policy and applies the policy.
RPD routes are in the format of policy type (export policy)/peer address/policy ID, for example, 1/1.1.1.1/1.
Table 1 describes the fields in the routes.
Field |
Description |
---|---|
Policy type |
Specifies the policy type. Currently, only export policies are supported. |
Peer address |
Specifies the peer address used by the policy. |
Policy ID |
Specifies the ID of a policy. |
Route-policies carried in RPD routes are encapsulated through the WideCommunity attribute. Figure 1 shows the WideCommunity format used by RPD routes.
Field Name |
Length (in bits) |
Description |
---|---|---|
Container Type |
16 |
The value is 1, indicating the WideCommunity attribute. |
Flags |
8 |
The R bit is 0, indicating a private attribute. The T bit is 0, which is not used currently. |
HopCount |
8 |
This field is not used currently. The value is 1. |
Length |
32 |
Total packet length. |
Community |
32 |
Value of WideCommunity. Each value identifies a specific function of WideCommunity. If the value is MATCH AND SET ATTR, the attributes of the routes that match specific conditions are modified. If the value is MATCH AND NOT ADVERTISE, the routes that match specific conditions are not advertised. |
OWN AS |
32 |
AS number of the NCE. |
Context AS |
32 |
AS number of the local device (forwarder). |
Target TLV |
8 |
Target TLV. |
Length |
16 |
Target TLV length. |
RouteAttr |
8 |
Route attribute type. The TLV has three sub-TLVs: IP Prefix, AS-Path, and Community. |
Length |
16 |
Length of the route attribute type. |
IP Prefix |
8 |
IP address prefix. |
Length |
16 |
Length of IP address prefix. |
Type |
4 |
Matching type of the IP address prefix.
|
Flags |
4 |
This field is not used currently. |
IP Address |
32 |
IP address. |
Mask |
8 |
Mask of the IP address. |
GeMask |
8 |
Used to specify a range. The value of this field must be less than or equal to the length of the Mask or be 0. |
LeMask |
8 |
Used to specify a range. The value of this field must be greater than the length of the Mask or be 0. |
AS-Path |
8 |
AS_Path. |
Length |
16 |
AS_Path length. |
as-path regex string |
32 |
Content of the AS_Path, which is presented using a regular expression. The maximum length of the AS_Path is 1024 bytes. |
Community |
8 |
Community attribute. |
Length |
16 |
Length of the community attribute. |
Flags |
8 |
This field is not used currently. |
Community value |
32 |
Community attribute value. |
ExcTargetTLV |
8 |
This field is not used currently. Even if this TLV has a value, it is also ignored. |
Length |
16 |
ExcTargetTLV length. |
Param TLV |
8 |
Content of the action to be performed. The format depends on the Community value, and the TLV content also varies according to the Community value. If the Community value is MATCH AND SET ATTR, the MED, Community, or AS_Path attribute is modified. If the Community value is MATCH AND NOT ADVERTISE, the Param TLV is empty, without any sub-TLV. |
Length |
16 |
Param TLV length. |
In the following example, the typical networking of inbound traffic optimization is used to describe how RPD works to implement traffic optimization:
Figure 2 shows an inbound traffic optimization scenario. NCE collects traffic information from devices and performs analysis and calculation to identify the routes to be adjusted. After a traffic optimization policy is configured on NCE, NCE converts the policy into an RPD route and delivers the route to the devices, which are forwarders in this scenario.
In this scenario, forwarders receive the policies delivered by NCE and adjust route attributes (MED, Community, or AS_Path) based on the policies. The forwarders follow the policies strictly when advertising routes, but are not responsible for the traffic optimization results. You can check the traffic optimization results in real time through NCE.
The IP network optimization solution provides users with a method of on-demand traffic scheduling to make full use of network bandwidth. In the IP network optimization solution, this feature ensures inbound traffic optimization in MAN ingress or IGW scenarios. In this solution, the router functions as a forwarder and needs to be configured with the RPD feature so that the router executes the route-policies carried in the RPD routes delivered by NCE to dynamically adjust traffic for inbound traffic optimization.
In traffic optimization scenarios, this feature spares manual BGP route-policy maintenance, which is complex, time-consuming, and error-prone. Therefore, this feature reduces maintenance workload and improves maintenance quality.