Loop prevention for route import between protocols

During actual network deployment or operation and maintenance, it is common to import BGP and IGP routes to each other. In practice, engineers must have a good understanding of network planning and network status. If they are not careful, routing loops may occur. The following figure shows an example:

+---+ |RT2| +---+ / | --IBGP--/ | / | / | / | +---+ +---+ | |RT1|----IBGP----|RR | IGP +---+ +---+ | \ | \ | \ | --IBGP--\ | \ | +---+ |RT3| +---+ As shown in the figure, RT1 imports routes and advertises the routes to the RR. The RR advertises the routes to RT2 through an IBGP peer. IGP imports BGP routes on R2 and advertises the routes to RT3. In this case, the BGP anti-loop attribute information is lost. On RT3, BGP imports IGP routes. RT3 preferentially selects the locally imported routes and advertises the routes to the RR through IBGP. The RR selects the route from RT3 and advertises routing updates to RT2. As a result, a routing loop occurs. This document provides a mechanism to prevent loops caused by route import between protocols. This mechanism is implemented through a new attribute, which we call the route origin site List attribute. This attribute is transmitted between protocols when routes are imported to each other and can be advertised to neighbors. When a neighbor receives a route, it checks whether the local protocol route origin site information is contained in the route origin site attribute. If yes, a routing loop occurs. How IGP advertises and generates protocol site attributes is beyond the scope of this document. How to transfer route origin site attributes between BGP and IGP is beyond the scope of this document.

The attribute encoding content of the Route Origin Site List is the information about the site where the route enters the BGP routing table or IGP routing table for the first time. The Route Origin Site List attribute is optional and transitive. Since the route may pass through multiple sites, the attribute length field should be 2 bytes, that is, the extended length flag bit should be set. The Route Origin Site List attribute contains one or more sub-TLVs. The Route Origin Site List attribute are defined as follows:

Attr.Flags: Optional-transitive, extended length bit is set, refer to . Attr.Type Code: TBD. Length: 2 bytes. Indicates the total length of the sub-TLVs. sub-TLVs: Variable length, containing one or more sub-TLVs.

A sub-TLV on the originating node of a route, indicating that the route is imported to each other, for example, BGP imports IGP routes. The sub-TLVs is optional and may be present multiple times in the Route Origin Site List. When a route is advertised, the sub-TLV should be added to the Route Origin Site List of the route. The receiver should check whether a loop occurs on the route according to the Route Origin Site List attribute of the route. Similarly, when importing a route, the protocol checks whether a loop occurs on the route according to the Route Origin Site List.

This type of sub-TLV indicates that the route that carries this attribute is imported to BGP from other protocols at the site. The sub-TLV codes are as follows:

Type: 1. Length: Specifies the length of the value field in terms of octets. The value MUST be 8. VPN ID: 4 octets of vpn instance ID. Indicates the VPN to which the route is imported. Protocol Site ID: 4 octets. Identifies the protocol site on which the route is imported to BGP. It is recommended that the site ID be generated as a random number.

This type of sub-TLV indicates that the route that carries this attribute is imported to OSPF from other protocols at the site. The sub-TLV codes are as follows:

Type: 2. Length: Specifies the length of the value field in terms of octets. The value MUST be 8. Process ID: 4 octets. Indicates the OSPF process to which the route is imported. Protocol Site ID: 4 octets. Identifies the protocol site on which the route is imported to OSPF. It is recommended that the site ID be generated using a random number or ospf router-id.

For a route imported from one protocol to another, the local Route Origin Site information SHOULD be added to the Route Origin Site List attribute when the protocol advertises the route. The attribute of a route received from a neighbor SHOULD not be modified when the route is forwarded to other neighbors. To prevent inter-AS loops, the local Route Origin Site information needs to be added to the attribute of the Route Origin Site List for the scenario where the route is received from the neighbor and forwarded to the EBGP neighbor.

When a route is received, the local Route Origin Site information SHOULD be compared with the Route Origin Site List attribute of the route to determine whether a loop occurs. If a routing loop occurs, the protocol SHOULD be handled as follows: For the BGP protocol, the priority of routes with loops SHOULD be lower than that of non-loop routes. Therefore, in the BGP route selection rules, loop detection SHOULD be one of the route selection rules, and this rule SHOULD be placed in a higher priority position. For the OSPF protocol, the priority of routes with loops SHOULD be lower than that of non-loop routes, and adjust the routing metric to a larger value. When routes are imported between protocols, the content of Route Origin Site List attribute SHOULD be transferred to the peer protocol. Each protocol advertises the attribute content to its neighbors. The method used by other routing protocols to publish the content of this attribute is not discussed in this document.

The validation of the TLVs/sub-TLVs introduced in this document and defined in their respective sub-sections of Section 2 MUST be performed to determine if they are malformed or invalid. In case of any error detected, either at the attribute or its TLV/sub-TLV level, the "Attribute discard" strategy MUST be applied. This is because this attribute is used for loop detection, and abnormal attribute mishandling may cause more serious problems than attribute discarding.

+---+ |RT2| [1,200] +---+ / | --IBGP--/ | / | / | [0,100] / | +---+ +---+ | |RT1|----IBGP----|RR | IGP +---+ +---+ | \ | \ | \ | --IBGP--\ | \ | +---+ |RT3| [0,300] +---+ As shown in the figure, RT1 imports the route, adds [0, 100] to the Route Origin Site List attribute of the route, and advertises the route to the RR through the IBGP peer. The RR advertises the route to RT2 through the IBGP peer. The route contains the Route Origin Site List attribute {[0, 100]}. On RT2, OSPF process 1 imports BGP routes and advertises them to RT3 through the OSPF neighbor. The routes include {[1, 200], [0, 100]}. [1, 200] is added by OSPF process 1. On RT3, BGP imports OSPF routes that carry the {[1, 200], [0, 100]} attribute. RT3 preferentially selects the locally imported route and sends the route to the RR through an IBGP peer. The route carries {[0, 300], [1, 200], [0, 100]}, [1, 300] is added by BGP. The RR preferentially selects the route from RT3 and advertises a route update carrying {[0, 300], [1, 200], [0, 100]} to RT2. After RT2 receives the route, OSPF process 1 imports BGP routes. BGP sends the route with {[0, 300], [1, 200], [0, 100]} to OSPF. OSPF compares [1,200] with {[0, 300], [1, 200], [0, 100]}, and finds that a loop occurs in the route. After OSPF adjusts the route priority, it advertises a low-priority route to RT3. If there are other OSPF routes on RT3, other routes are preferred to break the loop. Or, on RT3, when BGP imports OSPF routes containing {[0, 300], [1, 200], [0, 100]}, it compares the [0,300] with {[0, 300], [1, 200], [0, 100]} to find routing loops and reduce the Route selection priority. Therefore, the route sent by RR to RT3 takes priority, and the loop is broken.

This document requests the creation of a new registry called "Route Origin Site List Attribute" under the "BGP Path Attribute" registry.

The following initial Sub-TLV codepoints are assigned by this document:

There are no additional security risks introduced by this design.