In our last blog, we introduced Flexible Algorithms (Flex-Algo) and how TE-metric empowers networks to steer traffic intelligently, much like planning a delivery route based on road capacity, congestion, or cost. We showed how businesses can prioritize critical services like video conferencing over bulk data transfers, using custom traffic engineering values.
Now, let’s take the next step in that journey and shift our focus from predefined paths to performance-based paths.
Imagine if your GPS didn’t just calculate the shortest or most affordable route, but also picked the one with the least delay based on live road conditions. That’s where the link delay metric comes in.
Flex-Algo with link delay enables networks to choose paths not just based on cost or length, but on how fast data actually moves across the infrastructure. This becomes crucial for time-sensitive digital services like:
- Video calls
- Online trading systems
- Remote surgeries
- Interactive cloud applications
While TE-metric is set manually by network engineers, link delay can be based on both:
- Static values, defined by link type or service expectations
- Dynamic measurements, collected in real time from the network
This shift allows for smarter, more adaptive routing decisions, where the fastest route isn’t just guessed, it’s known.
In this blog, we’ll explore:
- What link delay really means (in simple terms)
- How it compares to TE-metric
- Real-world examples where it matters
- And how Flex-Algo turns this into a business advantage
What Link Delay Really Means (In Simple Terms):
Let’s simplify it: Link delay is the time it takes for a piece of data to travel from one point in the network to another, just like how long it takes a car to get from one city to the next.
In real life, not all roads are the same. Some are highways, others are winding rural paths. Some have smooth traffic flow, others are clogged with cars. The distance might be the same, but the time to reach your destination can vary a lot depending on road conditions.
In networking, it’s similar. Data travels through cables and routers, and the “delay” on each link depends on things like:
- The type of cable (fiber is faster than copper)
- The number of hops (how many devices the data passes through)
- Congestion (how busy the path is)
- The processing speed of network equipment
So, link delay is a measure of how “quickly” a specific connection can carry traffic. It’s not about how much data can go through (that’s bandwidth), but how long each piece of data takes to move through that path.
How Link Delay Compares to TE-Metric:
Both Link Delay and TE-Metric are used by Flex-Algo to help the network choose smarter paths, but they work in very different ways.
Let’s compare them using a real-life delivery analogy and then break down what it means for networks.
TE-Metric: Custom Route Planning
Imagine you’re managing a delivery service. You assign different numbers (or “weights”) to each road based on your own internal rules:
- Wide highway: 10 points
- Narrow city street: 20 points
- Risky roads: 50 points
You decide the delivery truck should always take the path with the lowest total score, regardless of how long or fast it is.
What it means in networking:
TE-Metric is manually set by engineers. It’s not based on real-time conditions, but rather on how preferred or suitable a link is considered for traffic (cost, reliability, capacity, etc.). It’s great for:
- Avoiding expensive or risky links
- Prioritizing high-capacity paths
- Creating specific routing behaviors (e.g., compliance, cost control)
Link Delay: Real-Time GPS Routing:
Now imagine your delivery truck uses live GPS updates. It checks how long each road is actually taking right now, and picks the one with the shortest delivery time, even if it’s technically a longer route.
What it means in networking:
Link Delay is about actual latency; how much time data takes to pass through. It can be:
- Static (pre-configured expected delay)
- Dynamic (measured live from the network)
This is ideal for:
- Real-time apps like video conferencing or VoIP
- Networks that need responsiveness over cost savings
- Environments where congestion happens often
Real-World Examples Where Link Delay Matters:
Link delay optimization is crucial in many real-world scenarios:
- Video Calls & Conferences: Low delay means smoother, clearer conversations without awkward pauses.
- Online Gaming & Trading: Faster paths give instant response, a must for competitive play or quick trades.
- Telemedicine: Doctors need real-time visuals and control; delays can risk patient safety.
- Smart Factories: Machines must talk instantly; delays can cause defects or safety issues.
Link Delay Explained:
The link delay metric enables Flex-Algo to compute paths based on real-time or statically configured delay values.
- Helps direct traffic over the lowest-latency path instead of the shortest IGP-cost path.
- Uses delay values advertised in IGP extensions (IS-IS or OSPF) to influence path selection.
- Can be dynamically updated in networks that support real-time telemetry and link delay measurement.
TWAMP
TWAMP is a protocol that measures actual network delay by sending test packets between routers. In Flex-Algo, it’s used to calculate real-time link delay, which helps the network pick the fastest path instead of just the shortest. This ensures better performance for delay-sensitive traffic like voice or video.
Hands-On with Flex-Algo Link Delay: Topology, Configuration, and Validation:
Topology: R4, R5, and R6 will function as Provider Edge (PE) routers, while R1, R2, R3, and R7 will serve as Provider (P) routers. The PE routers (R4, R5, and R6) will run algorithms, Flex-Algo 132, 133 and 134. Among the P routers, R3 will run Flex-Algo 132, R1 and R2 will run Flex-Algo 133 and 134, and R7 will support Flex-Algo 132, 133 and 134.
Topology-1: Flex-Algo-0 i.e. default Flexible Algorithm
Topology-2: Flex-Algo-132
Topology-3: Flex-Algo-133
Topology-4: Flex-Algo-134
Sample configuration from R4 device:
Loopback interface configuration on R4(PE) router:
Configures the Prefix-SID for both the default and specific algorithms on the loopback interfaces of the respective devices.
Physical interface configuration:
Enables “label-switching” with network type “point-to-point” (can be broadcast also) and configures ISIS process “OCNOS” under the interface. Minimum and maximum link delay can be manually configured on a link, while dynamic link delay is measured using TWAMP.
In this example, R4 serves as the TWAMP sender, while R1 functions as the reflector for the respective link, as indicated.
Router ISIS configuration:
Note: To enable SR-MPLS under IS-IS, configuring “metric-style wide” and “mpls traffic-engineering” for the respective level is mandatory. For Flex-Algo, we need to enable “capability flex-algo routing” and then configure the required Flex-Algo. By default, the metric type used is IGP metric. To use link-delay, it must be explicitly configured.
In IS-IS Flex-Algo, the default priority is 5. If priorities match, the device with the highest router ID wins. To avoid ambiguity, assign a higher priority to the preferred device. Constraints like ‘exclude-maximum-delay’ should be set only on the FAD winner
Validation Steps:
Check the ISIS neighborship:
Verifies ISIS neighborship status, outgoing interface, and type.
Check the ISIS interface detail filtered to show each link and its corresponding delay:
Delay configured manually is displayed as ‘level-2 min/max delay’, while TWAMP-based dynamic delay appears under ‘measured min/max delay’. If no delay is configured (neither manual nor dynamic), the ‘measured min/max delay’ shows 4294967295, the maximum value, indicating that the link should be excluded from path selection.
Check the ISIS topology:
Shows topology details, including metrics and next-hop information for the default and specified algorithms. In the Metric field, ‘–’ indicates the local device, while ‘**’ signifies exclusion from the respective algorithm.
Check the ISIS routes:
Analyzes IS-IS routes along with their associated metrics and next-hop details for the default and specified algorithms.
Check the ISIS SR state:
Verifies ISIS-SR state and used SRGB on the router.
Check the ISIS SR capabilities of routers in the network:
Identifies IS-IS SR-capable routers in the network, the enabled Flex-Algo instances, and their respective SRGB.
Check the ISIS SR flex-algo status user-config summary:
Shows a summary of the user-configured settings for all Flex-Algos on the local router node.
Shows a summary of the user-configured settings for respective Flex-Algo settings on the local router node.
Check the ISIS SR flex-algo status user-config detail:
Provides a detailed view of the user-configured settings for respective Flex-Algo settings on the local router node.
Check the ISIS SR flex-algo status election summary:
Shows a summary of all Flex-Algo FADs learned from participating routers in the election process.
Shows a summary of a Flex-Algo FAD learned from all routers in the SR domain that participated in the election process.
Check the ISIS SR flex-algo status election detail:
Provides a detailed view of all Flex-Algo FADs learned from routers that participated in the election process, showcasing few routers an example from algorithm 130.
Provides a detailed view of a Flex-Algo FAD learned from all routers in the SR domain that participated in the election process, showcasing few routers an example from algorithm 131.
Check the ISIS SR flex-algo status winner summary:
Shows a summary of all Flex-Algo FAD elected as the winner across all routers in the SR domain.
Shows a summary of the Flex-Algo FAD elected as the winner across all routers in the SR domain.
Check the ISIS SR flex-algo status winner detail:
Provides a detailed view of all Flex-Algo FAD elected as the winner across all routers in the SR domain.
Provides a detailed view of the Flex-Algo FAD elected as the winner across all routers in the SR domain.
Check the ISIS database:
Verifies the ISIS-SR database.
Check the ISIS database verbose:
Provides detailed IS-IS SR database information, including SRGB, Prefix-SID for default and respective algorithm, Adjacency SID. Also includes Flex-Algo details such as metric type, calculation type, priority etc.
Check the MPLS forwarding-table (FTN) entries in software (NSM) for respective algorithm:
Verify the MPLS Forwarding Table (FTN) entries for the loopback addresses of all other routers in the network. This command displays key details such as the outbound label (out-label), outbound interface (out-interface), next-hop, and more. Additionally, for Flex-Algo, it ensures that the correct forwarding paths are established based on the algorithm-specific constraints and metrics. Performing this check on the source router is crucial for validating proper routing and label allocation.
Check the MPLS ilm-table entries in software (NSM) for respective algorithm:
Verify the MPLS ILM (Incoming Label Mapping) table entries for the loopback addresses of all other routers and network links. This command provides critical details, including the inbound label (in-label), outbound label (out-label), outbound interface (out-interface), next-hop, and more. For Flex-Algo, it ensures that label forwarding aligns with the algorithm-specific constraints and path selection. Performing this check on the transit router is essential for validating correct label switching and path computation.
Check the P space nodes, Q space node and PQ node (if we have common PQ) for respective algorithm:
Check the ISIS-SR primary route and TI-LFA backup route along with backup tunnel for respective algorithm:
Verifies Flexible Algorithm specific ISIS TI-LFA routing table
Check the ISIS-SR primary route and TI-LFA backup route along with backup tunnel for a particular FEC in respective algorithm:
Verifies Flexible Algorithm specific ISIS TI-LFA routing table for particular FEC.
Check the MPLS ping and trace:
MPLS ping and trace are available for the default algorithm. For specific algorithms, MPLS ping is currently supported, while MPLS trace will be introduced in the next release.
Conclusion:
Flex-Algo’s ability to define custom path computation based on different metric types makes it a powerful tool for modern network architectures. By selecting the appropriate metric, whether IGP-based, TE-metric-based, or link-delay-based, operators can optimize routing for efficiency, performance, and service differentiation.
Next Topic: Flex-Algo in OcNOS: Leveraging Affinity Constraints for Path Optimization
Suraj Kumar Singh is Senior Solution Lead at IP Infusion.