What are flex algo definitions?
Flex ago definitions
Normally, routers construct a single shortest path tree based on the IGP metric, and any deviations from this shortest path tree - due to traffic engineering requirements, for example - would require per-path CSPF signaling and control protocols such as RSVP or SR-TE. However, when flexible algorithm - or Flex Algo - is used, routers in the network can each compute unique trees that respect a combination of TE constraints and objectives beyond the base IGP Metric, without the need for per-path signaling and control.
For example, a Flex Algo instance can be configured to use link delay instead of IGP metric, and admin group rules to restrict paths to a specific subset of the network. Each router is configured with the same definition, ensuring they all construct the same view of the shortest path while considering these rules. When a path/packet which follows these rules needs to be sent, traffic can be steered along the network using a SR Prefix SID associated with the Flex Algo definition. Each router in the path would have pre-computed a shortest path next-hop which respects the defined rules. Unlike SR-TE, Flex Algo can achieve forwarding that respects the rules with a single segment in the packet. Note, however, that Flex Algo definition is a reduced form of TE compared to what SR-TE can achieve, and while multiple Flex Algos can exist in the network, the current maximum is 5.
Path control implementation
Flex Algo is inherently a router-based traffic engineering solution for various use cases and can operate without the use of a central path computation. With that in mind, path control can still provide various functions with Flex Algo, including:
-
Compute end-to-end paths across multiple domains with Flex Algo in each domain (local router unable to)
-
Compute end-to-end paths where some domains use Flex Algo, and others use SR-TE (local router unable to)
-
Leverage Flex Algo as an MSD reduction tool and combine with additional TE (PCE-computed diversity, bandwidth, latency constraints, etc. combined with a Flex Algo configured for Delay)
Note: Path control does not support Flex Algo-based computations with PCEP LSPs.
Flex Algo Definition (FAD)
The Flex Algo Definition (FAD) is a core component of Flex Algo. It is a configuration definition applied on each router in the network that is partaking in a Flex Algo instance, and it is flooded to all routers in the local area to ensure consistency and prevent loops. The FAD is also exported to BGP-LS and can be discovered by a PCE/Controller.
The FAD is what makes up the traffic engineering rules to impose on the algorithm, and includes the options below:
Parameter |
Description |
---|---|
Algo |
Specifies the assigned value of the Flex Algo instance. Range is 128-255. Algo 0 is also known as the native IGP Metric algorithm. |
Priority |
Specifies the priority of the Flex Algo instance. |
Metric Type |
Specifies the metric type of the Flex Algo instance. Options are IGP, TE-Metric, or Delay. |
Admin Group Include-All |
Specifies whether the Flex Algo instance will include all admin groups. |
Admin Group Include-Any |
Specifies whether the Flex Algo instance will include any admin groups. |
Admin Group Exclude |
Specifies whether the Flex Algo instance will exclude admin groups. |
Exclude SRLG |
Specifies whether the Flex Algo instance will exclude SRLGs. Not supported by SROS. |
Winning FAD
Since a FAD is configured individually on each router, there must be a distributed consensus to ensure that all routers agree on the same definition and converge to the same topological value. This is known as the winning FAD. The winning FAD occurs for each local link state flooding area. The winning FAD is selected based on the following criteria:
-
From the advertisements of the FAD in the area (including both locally generated advertisements and received advertisements), the one(s) with the numerically-greatest priority value is selected.
-
If there are multiple advertisements of the FAD with the same numerically-greatest priority, the one that is originated from the router with the numerically-greatest System-ID (in the case of IS-IS) or Router ID (in the case of OSPFv2 and OSPFv3) is selected.
© 2024 Nokia. Nokia Confidential Information
Use subject to agreed restrictions on disclosure and use.