| Internet-Draft | Abbreviated-Title | March 2023 |
| Wang | Expires 3 September 2023 | [Page] |
The route redistribution is often deployed in current network between two different protocols domain or instance/process, such as the ISIS domain redistribute to OSPF domain, the OSPF domain redistribute to BGP domain, IS-IS redistribute to another IS-IS instance/process and so on. The existing network have more complex multiple IGP domains architecture. Therefore, bidirectional route redistribution deployment is more complex for different protocols or instances/processes to learn routes from each other. In recent years, these route redistributions have had many routing loops cases that cause network incident.¶
This document proposes a simplified method to positively avoid routing loop, and introduces new sub-TLVs to support advertisement IPv4 and IPv6 prefix extended attribute as Redistribution Credibility ID, while redistributing route from one protocol domain or instance/process to another.¶
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 3 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.¶
Due to network scope, architecture or network management requirement, many existing network have multiple different IGP protocol domains, including multiple routing protocol and multiple routing instance/process with same protocol. These IGP domains boundary routers need to deploy bidirectional route redistribution to learn routing prefix information for each other. Because of reliability design consideration, these route redistribution configuration have been deployed at least two routers, or even more boundary routers between these adjacent IGP domain.¶
However, there is no routing loop prevention mechanism in multiple routing protocol domain or instance/process scenario. As traditional method, these redistribution routers must be configured complex route control policies, using IP prefix, cost and preference/ administrative distance (AD) and etc., to avoid routing loops and nonoptimal routing problems.¶
As the network scale grows and irregular distribution, these multiple Route Redistribution node configuration become more and more difficult to control. Maybe any network change have to adjust these route redistribution configuration. The manually configured routing policy adjustment mode have more complex and high risky that cannot meet the requirements of the current network. As a result, many serious network loop accidents occur and service traffic had been affected. A simple and low-cost Layer 3 routing loop prevention solution is urgently needed.¶
IS-IS: Intermediate System to Intermediate System¶
OSPF: Open Shortest Path First¶
TTR: Times-to-Redistribution¶
Cred route-type: Credibility route-type¶
This document defines a new Route Redistribution Credibility ID sub-TLV to solve the Layer 3 routing loop problem. The Route Redistribution Credibility ID indicates the Route Credit Rating when this routing prefix has been propagated across multiple routing protocol domain or instance/process. The Route Redistribution Credibility ID is automatically attenuated when the routing prefix cross redistribution node. If a route is redistributed more times, this route’s risk probability of routing loop is higher and its Credibility is lower.¶
This section describes the Route Redistribution Credibility ID Sub-TLV for IS-IS.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redistribution Credibility ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IS-IS Route Redistribution Credibility ID Sub-TLV¶
where:¶
Type: TBD¶
Length: (1 octet), the length value is 4 octets¶
Redistribution Credibility ID: (4 octets), it has the following Field:¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTR |Cred route-type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Route Redistribution Credibility ID Field
¶
where:¶
TTR: Times-to-Redistribution (called TTR, 1 octet), it indicates the number of redistribution times, the value from 0 to 255 is used as quantity of routing domain (means different routing protocol domain or instance/process) to be traveled across from the routing prefix original node to this route redistribution node. For example, each time the route is redistributed, the Times-to-Redistribution (called TTR) value decreases by 1, the route with greater Times-to-Redistribution (called TTR) value can be preferred. This indicate that the route is more closed to the route original node. When the Times-to-Redistribution (called TTR) value is 0, it indicate the route is not trusted.¶
Cred route-type: Credibility route-type (called Cred route-type, 1 octet), it indicate that the route is internal or external Cred route type according to network administration scope. For the routing prefix with same Times-to-Redistribution(called TTR) value scenario, the internal Cred route-type that network administration scope identification is the same as local, can be preferred rather than external Cred route-type with different identification. The network administration scope is specified according to the network layer of logical architecture. The different routing domains (means different routing protocol domain or instance/process) may have a same network administration scope identification, or may have different network administration scope identification.¶
TBD¶
This document requests that IANA allocates new IS-IS Route Redistribution Credibility ID sub-TLV types from the IS-IS "Sub-TLVs for TLVs 27, 135, 235, 236 and 237)" registry as specified.¶
+=========+===============================================+===============+
| Value | Description | reference |
+====================================+======+=============================+
| TBD | IS-IS Redistribution Credibility ID Sub-TLV | This document |
+---------+-----------------------------------------------+---------------+
Figure 3: IANA Allocation for newly defined Sub-TLVs
¶
This document introduces the Route Redistribution Credibility ID, The feature introduces the advertisement of avoiding routing Loop capability information to all routers in routing domain. This information can be confirmed for discovery and verification that all routers in the routing domain support the capability before the feature is turned on. Advertisement of the information defined in this document introduces no new security concerns.¶
The author would like to thank people for their comments on this work.¶