Huawei Technologies

Huawei Bld., No.156 Beiqing Rd. Beijing, 100095 China wangqiang88@huawei.com

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.

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.

where: Type: 33(is suggested) Length: (1 octet), the length value is 4 octets Redistribution Credibility ID: (4 octets), includes: Times-to-Redistribution (called TTR, 1 octet) Credibility route-type (called Cred route-type, 1 octet) Reserved (2 octet) The format of Redistribution Credibility ID sub-TLV in ISIS is as the following:

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 Advertising Prefix Reachability" registry as specified. Type Description 27 135 235 236 237 Reference 33 (is suggested) Redistribution Credibility ID y y y y y This document

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.