In a previous blog, we gave an introduction to the Juniper Paragon Pathfinder (formerly known as NorthStar Controller) and its role in a segment routed network. In this blog, we’ll look at the Path Diversity use case.
Operators often need to create pairs of diversely-routed Label-Switched Paths (LSPs) across the network to ensure resilience. Diversely-routed LSPs are LSPs that don’t have any links, nodes or shared-risk link groups (SRLGs) in common. These are used to create highly available services, such as diversely routed pairs of pseudo-wires. The idea is that if a network element fails, at most only one of the LSPs is affected and the other remains intact and continues to carry the customer’s traffic. Some customers of the service use the two paths in a “live-live” manner, i.e. deliberately sending duplicate traffic over both paths and reconciling at the application layer. On the other hand, other customers simply load-balance their traffic over the two paths.
The Problem with Distributed Path Computation
Let’s have a look at Figure 1 below.
We want to create a pair of diversely-routed LSPs with the blue LSP going from PE1 to PE3 and the red LSP going from PE2 to PE4. If we ask the two ingress routers, PE1 and PE2, to each compute the path of their own LSP, there is no guarantee that they will be diverse because there is no mechanism for the two ingress routers to collaborate about the path computation. So, as shown in Figure 1, PE1 might end up computing a path PE1-P2-P5-PE3 while PE2 computes a path PE2-P2-P5-PE4. This means the two paths would share fate between P2 and P5, so the paths would not be diverse. This is a common problem when attempting to create diversely routed LSPs via distributed path computation.
Solving Path Diversity with the Paragon Pathfinder Controller
If we leverage Paragon Pathfinder to do the path computation instead of using distributed path computation, it can easily compute both paths simultaneously in such a way that they are diverse. This is a key advantage of centralized path computation. Paragon Pathfinder knows the topology of the network and the segment routing SIDs for each link via BGP-LS or IGP peering with the network. Having computed both paths as diverse with no shared nodes, links or SRLGs, it sends details of the paths via the Path Computation Element Protocol (PCEP) to the two ingress routers, which install the paths in their RIBs and FIBs so that they are ready to carry traffic. The PCEP message specifies the exact path that the LSP must follow, in terms of the IP addresses of each successive link in the path and the associated segment-routing adjacency SID.
Paragon Pathfinder learns SLRGs in the following ways:
- From configuration via the GUI
- From the network, via BGP-LS or IGP peering, if the SRLGs are configured on the routers
- Via Paragon Pathfinder’s northbound REST API
- From an optical controller, via a Yang model [1] created for this purpose, or via the ONF Transport API (TAPI) [2].
As seen in Figure 2, the link between P1 and P4 and the link between P2 and P5 are both members of SRLG 100. This could be because the two links share the same optical fiber in the underlying optical layer. Paragon Pathfinder takes this into account when it does the path computation. As can be seen in Figure 2, the red LSP follows the path PE1-P1-P4-PE3 while the blue LSP follows the path PE2-P3-P6-PE4. In this way, the two paths are completely diverse: they have no links, nodes or SRLGs in common, so if a network element fails, at most only one of the LSPs will be affected.
Conclusion
A centralized controller, such as the Paragon Pathfinder, enables operators to easily create and manage diverse LSPs, providing a solution to what has always been a very difficult to achieve with distributed path computation.
References
[1] https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
[2] https://github.com/OpenNetworkingFoundation/TAPI
[3] Video about Paragon Pathfinder and Path Diversity: https://www.youtube.com/watch?v=BYh82iTXPVQ
