7. A set of required routing policies
BGP policies are implemented in the form of configuration information. This information is not directly incorporated into the Protocol. Therefore, BGP can provide very complex routing policies. However, all BGP implementations are not required to support these policies.
We do not try to standardize routing policies so that they apply to each BGP implementation. We strongly encourage all implementations to support the following routing policy sets:
1. BGP implementation should allow an as control to broadcast Routes learned by BGP to adjacent. The implementation should also support the control of the address prefix size. The implementation should also support the control of the autonomous system size, whether the autonomous system is the origin or neighbors. If a route is declared as follows for an external peer, note that the route cannot be advertised to the peer. In particular, the local system must explicitly inform the peer that the route is currently unavailable.
2. BGP implementation should allow an as to give priority to a specific path (when multiple available paths exist ). The implementation must have at least the following functions, allowing managers to set priority for routes from neighbors. The priority value ranges from 0 to 2 ^ (31) to 1.
3. BGP implementation should allow an as to ignore certain routes with specific as in the as_path attribute. For the implementation of this function, you can use the technology described in [2] to set the "weight" of these as to "infinity ". When selecting a route, you must ignore those routes whose "weight" is "infinity.
8. Relationship with other external routing protocols
The guidelines proposed in this section are consistent with those stated in [3.
An as should notify the minimum aggregation of its internal target network and its relationship with the actually used address space. This can be used by managers of non-BGP-4 as to determine the number of routes that can be aggregated from an aggregation route.
A route that carries the attributes of the atomic_aggregate path should not be passed to the BGP-3 or egp2, unless such transfer does not show the convergence of the route NLRI.
8.1 exchange information with egp2
The following guidelines are recommended for routing information exchange between BGP-4 and egp2.
For smooth transition, a BGP spokesman egp2 and BGP-4 can be involved. Therefore, a BGP spokesman may receive IP accessibility information from egp2 or BGP-4. Information generated by egp2 that can be inserted into the BGP-4 after the origin path property is set to 1. Similarly, information generated by the BGP-4 can be inserted into egp2. However, in the second case, when the IP prefix received from the BGP-4 represents a continuous A/B/C class network set, it should be clear about the potential for disaggregation information. The NLRI received by the BGP-4 represents a subset of IP addresses. When inserted, the BGP speaker is asked to insert the corresponding network into egp2. The local system will provide a mechanism to control the accessibility information exchange between egp2 and BGP-4. In particular, when you insert accessibility information from the BGP-4 into egp2, a consistent implementation requirement supports all of the following options:
-Insert the default value (0.0.0.0) without passing other NLRI.
-Controlled disaggregation is allowed, but only for specific routes;
-Non-aggregated NLRI can be passed.
-Only non-aggregated NLRI can be passed.
Exchange routing information with egp2 between a BGP spokesman participating in the BGP-4 and a pure egp2 spokesman can only be found at the domain (Autonomous System) boundary.
8.2 exchange information with BGP-3
The following guidelines are recommended for routing information exchange between BGP-4 and BGP-3.
For smooth transition, a BGP spokesman BGP-3 and BGP-4 can be involved. Therefore, a BGP spokesman may receive IP accessibility information, either from a BGP-3 or from a BGP-4.
A bgp spokesman may insert information from the BGP-4 to the BGP-3 as follows.
If the as_path attribute of a BGP-4 route carries the as_set path segment, the as_path attribute of the BGP-3 route should treat this as_set segment as the as_sequence segment, and the final as_path is a simple as_sequence. The Set/sequence information is lost in this process, but it does not affect the preventive routing, but may affect the policy, if the policy is based on the content or sequence of the as_path attribute.
Insert the NLRI from the BGP-4 into the BGP-3. When the IP prefix received from the BGP-4 represents a continuous set of A/B/C networks, you should be aware of the potential for unaggregation information. The NLRI received by the BGP-4 represents a subset of IP addresses, requiring the BGP spokesman to insert the corresponding network into the BGP-3 when inserting. Local systems will provide a mechanism to control the accessibility information exchange between BGP-3 and BGP-4. In particular, when you insert accessibility information from the BGP-4 into the BGP-3, a consistent implementation requirement supports all of the following options:
-Insert the default value (0.0.0.0) without passing other NLRI.
-Controlled disaggregation is allowed, but only for specific routes;
-Non-aggregated NLRI can be passed.
-Only non-aggregated NLRI can be passed.
The exchange of routing information between a BGP spokesman and a pure BGP-4 spokesman in a BGP-3 can only be found at the boundaries of Autonomous Systems. Within a single autonomous system, all BGP spokesman sessions must be either BGP-3 or BGP-4, not a mixture.
9. Operations on Virtual Switching lines
BGP is used on the Virtual Switch subnet (SVC) and is required to generate as little traffic as possible. In particular, it may be required to eliminate the traffic generated by periodic keepalive messages. BGP includes a mechanism that prevents SVCs from being enabled all the time when the virtual switch line (SVC) service is running and allows it to terminate the sending of periodic keepalive messages.
This section describes how to use smart SVC management to minimize the use of SVC without periodic keepalive messages. The proposed scheme also applies to "permanent" lines, "permanent" lines support features similar to link quality monitoring, or can display requests to determine the link connection status.
9.1 establish a BGP connection
You can set the hold time to 0 in the open message.
9.2 line manager features
Line management must have sufficient functions to compensate for the lack of periodic keepalive messages:
-The link layer's non-accessibility must be determined within the foreseeable and limited time when a failure occurs.
-To determine non-accessibility, you should:
-Enable a sticky counter (compared with a typical sticky counter value ).
-Try to recreate the link layer connection.
-If the dead silence counter is terminated, it should:
-Send an internal line dead to TCP.
-If the connection is rebuilt
-Cancel the dead counter
-Send an internal line up indication to TCP.
9.3 TCP features
TCP must be modified to handle internal announcements from the line manager:
-Dead: Clear the sending queue and cancel the TCP connection.
-Up: send any queue data or allow TCP calls to processes
9.4 hybrid features
Some applications may not ensure that the BGP process and the line manager work in a unified manner. That is to say, when one stop or crash, the other still exists independently.
If this is the case, periodic two-way handshakes between the BGP process and the line manager are required. If the BGP process finds that the line manager is dead, it closes all related TCP connections. If the line manager finds that the BGP process is dead, it closes all connections related to the BGP process and rejects new connections.
