| Internet-Draft | Abbreviated-Title | March 2023 |
| Li & Wang | Expires 4 September 2023 | [Page] |
BGP and IGP are commonly used network protocols during network construction. At the beginning of BGP protocol design, EBGP and IBGP loop prevention are considered. Similarly, the IGP protocol has a loop prevention mechanism. In actual deployment, some or even all routes of the two protocols are imported to each other. Route import causes the loss of the anti-loop attribute of the protocol. As a result, the anti-loop fails.¶
This document provides a feasible solution to the above problems. Attribute information is added when routes are imported between protocols. The added attribute information can be advertised to neighboring neighbors through BGP peers or IGP peers. How the new attributes are advertised using IGP peers is beyond the scope of this article.¶
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 [RFC2119].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 September 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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[RFC4271] 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:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr.Flags | Attr.Type Code| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Site ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Process ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Site 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:¶
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.¶
Code Point Description ------- ------------------------------- TBD Route Origin Site List Attribute¶
The following initial Sub-TLV codepoints are assigned by this document:¶
SubType Description ------- ------------------------------- 1 BGP Route Origin Site sub-TLV 2 OSPF Route Origin Site sub-TLV¶
There are no additional security risks introduced by this design.¶