SR based Loop-free implementation

An IP network computes paths based on the distributed IGP protocols. If a node or link fails, a loop may occur on the network because LSDBs are not synchronized. Take the IS-IS/OSPF link-state protocol as an example. Each time the network topology changes, some routers need to update the FIB table based on the new topology. Due to the different convergence time and convergence orders, different routers may be asynchronous for a short time. Depending on the capability, configuration parameters, and service volume of the device, the database may not be synchronized in milliseconds to seconds. During this period, each device on the packet forwarding path may be in the pre-convergence state or the post-convergence state. If the status is not synchronized, forwarding routes may be inconsistent and a forwarding loop may occur. However, such a loop disappears after all devices on the forwarding path complete convergence. Such a transient loop is called a “microloop”. Microloops may cause packet loss, delay variation, and packet disorder on the network. The Segment Routing defined in can be used to cope with microloop issue on the network. When a loop may occur due to a network topology change, a network node creates a loop-free segment list to direct traffic to the destination address. After all network nodes converge, the network node returns to the normal forwarding state. This effectively eliminates loops on the network. describes the basic principles of how to use Segment Routing to cope with microloop. This document describes some optional implementation methods of SR for microloop avoidance in different scenarios.

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 .

Tangent microloops refer to the microloops occurred after node/link failures. Along the traffic forwarding path, a loop may occur if a node closer to the point of failure converges before a node far from the point of failure. Figure 1 is used as an example to describe the tangent microloop occur process: when the link between R3 and R5 fails, it is assumed that R7 completes convergence first and R2 does not complete convergence. R1 and R2 forward the packet along the previous path to R3. Since R7 has convergenced, it forwarded the traffic to R2 according to the route after convergence. Thus, the tangent microloops happened between R2 and R7.

SRv6 TI-LFA is deployed in all nodes of the network, and when the link between R3 and R5 fails, the convergence process after deploying tangent anti-microloop is as follows: Phase 1: The hold-down timer T1 is configured on R3 which is the neighboring node (R3) of the failed node/link and R3 uses TI-LFA forwarding for the duration of T1; Phase 2: The remote nodes configure the hold-down timer T2 and inserts a microloop avoidance segment list in the packet (for example, R7 inserts the microloop avoidance segment list <4::5> into the packet and forwards it to R2); Phase 3: T2 timeout, the remote nodes returns to normal convergence firstly; Phase 4: T1 timeout, R3 reverts back to normal convergence. Time T1 must be longer than time T2. This program is limited to single point of failure, the TI-LFA backup path may be affected in case of multi-point failure.

Microloops may occur not only when the node/link fails, but also after the failure node/link recovering. Figure 2 is used as an example to introduce the process of the cut-back microloop. R1 forwards the traffic to the destination R6 following the path R1->R2->R3->R5->R6. When the link between R2 and R3 fails, R1 forwards the traffic to the destination R6 following the re-converged path R1->R2->R4->R5->R6. After the failure link between R2 and R3 is recovered, assuming that R4 is the first to complete convergence, R1 forwards the traffic to R2. Since R2 has not completed convergence, the packet is still forwarded to R4 in accordance with the path before the the failure link recovering. R4 has already completed convergence, so R4 forwards it to R2 in accordance with the path after the the failure link recovering, and the mircoloop occurred between R2 and R4.

Since the network does not enter the TI-LFA forwarding process after the node/link failure is recovered, the delay convergence cannot be used in the back-cut scenario to prevent the generation of microloops as in the tangent scenario. From the above process of back-cut microloop generation, it can be seen that microloops happens because R4 is unable to pre-install a loop-free path computed for link up. Therefore, in order to eliminate potential loop after the the faulty node/link recovering, R4 needs to be able to converge to a loop-free path. When the faulty node/link is recovered, the path can be anti-microloop by simply specifying Adj-SIDs of the neighbor node. As shown in Figure. 2, R4 senses that the faulty link R2-R3 is recovered and re-converges to the destination R6 with the R4->R2->R3->R5->R6 path. The recovery of the faulty link R2-R3 does not affect the SR path from R4 to R2, so the path from R4 to R2 must be a loop-free path. Similarly, the path from R3 to R6 is not affected by the recovery of the failed R2-R3 link, and the path from R3 to R6 must be loop-free. The only thing affected is the path from R2 to R3. The loop-free path from R4 to R6 can be determined by just specifying the path from R2 to R3. So it is only necessary to insert an End.X SID from R2 to R3 in the converged path of R4 End. X SID instructs the message to be forwarded from R2 to R3, and the path from R4 to R6 is guaranteed to be loop-free.

When an IPv4 or IPv6 prefix is advertised by multiple nodes in an IS-IS domain, the prefix has multiple route sources, which is called a multi-source route. This section is for the multi-source microloop avoidance scenario, which may occur when multiple nodes advertise the same route with inconsistent convergence speeds. SRv6 multi-source microloop prevention mainly uses SRv6 END.X and END SID as the label stack for multi-source microloop prevention. SR-MPLS mainly uses the prefix SID and Adj SID as the label stack for multi-source anti-microloop. The following example is to describe how microloops happen when multiple nodes advertise the same route. 1. R3 and R6 both import the route 2001:db8:3::. The link between R2 and R3 fails. It is assumed that R2 first completes convergence, and R1 hasn’t completed convergence yet. 2. R1 forwards the packet to R2 along the path before the failure. 3. Because R2 has completed convergence, R2 forwards packets to R1 according to the next hop of the route. In this way, a loop is formed between R1 and R2.

A possible solution is that: the preferred destination node of the packets destined for 2001:db8:3:: changes from R3 to R6, but the convergence path from R2 to R5 does not change. In this case, timer T1 on R2 can be started. Before T1 expires, for a packet that accesses the R6, an End.X SID between the R5 and the R6 or an End SID of the R6 is added to the encapsulation in order to ensure that the packet is forwarded to the R6. A basic principle is similar to that of SR-MPLS.

The multi-point failure microloop scenario refers to the microloop occurs when multiple nodes or links fail. After multiple nodes or links fail, the node will preferentially detect the nearest failure. When the convergence paths are inconsistent or the convergence is asynchronous, a microloop may occur. The figure 4 is used as an example to introduce the process of multi-point failure microloop. The cost of the link between R3 and R6 is 100, and the cost of the other links is node R1 forwards the traffic to the destination node R7 along the forwarding path R1->R2->R5->R6->R7. When the node R5 fails, R2 forwards the traffic to the destination node R7 along the path R1->R2->R3->R4->R7 of the R5 failure convergence. At the same time, node R4 also fails, and R3 converges and forwards according to the path R3->R2->R5->R6->R7. A microloop occurs between R2 and R3. The multi-point failure scheme uses the strict explicit path to prevent microloop after convergence. As shown in Figure 4, node R1 completes convergence and calculates a strict explicit path to node R7 ( R1->R2->R3->R6->R7) after node R2 detecting the node failure of R5 and node R3 detecting the failure of node R4. And the normal forwarding next hop is restored after all nodes converge. The specific process of deploying multi-point failure anti-microloop convergence is as follows: Phase 1: After node R2 detecting the node failure of R5 and node R3 detecting the failure of node R4, node R1 calculates a strict explicit path to node R7 and starts timer T1. Phase 2: Before T1 times out, node R1 forwards the traffic to the destination node R7 along strict explicit path R1->R2->R3->R6->R7. Phase 3: After T1 times out, restore the forwarding path after convergence.

There are various scenarios and different implementation methods for loop prevention, and some solutions already introduced by other IETF proposals. This section tries to compare behaviors of the solutions. This article mainly uses segment routing and convergence delay solutions to prevent microloop in various scenarios. The implementation methods proposed by this document based on SR microloop avoidance mechanism can be used for subsequent research and development. And the definition of timer is not included in this document. Local Convergence Delay proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence. This mechanism only avoids the forwarding loops on the links between the node local to the failure and its neighbors. Forwarding loops may still occur on other links. oFIB describes a mechanism where the convergence of the network upon a topology change is ordered in order to prevent transient forwarding loops. Each router in the network deduces the failure type from the LSA/LSP received and computes/applies a specific FIB update timer based on the failure type and its rank in the network, considering the failure point as root. The oFIB mechanism solves all the transient forwarding loops in a network at the price of introducing complexity in the convergence process that may require careful monitoring by the service provider.

The behavior described in this document is internal functionality to a router that result in the ability to explicitly steer traffic over the post convergence path after a remote topology change in a manner that guarantees loop freeness. Because the behavior serves to minimize the disruption associated with a topology changes, it can be seen as a modest security enhancement.

No requirements for IANA.

The authors would like to thank everyone who contributed to the draft.