The following considerations must be taken into account when configuring and using Flex-Algorithms:
IS-IS algorithms 128 to 255 can program only the tunnel table, while IS-IS for algorithm 0 can program both the tunnel and the IP routing tables. For operational simplicity, the show>router>isis>routes command displays the correct egress interface.
To prevent the accidental creation of an overload of local FADs, the operator is only allowed to configure a maximum of 256 local FADs on a router.
A router can participate in a maximum of seven Flex-Algorithms. Each algorithm has the capability to advertise a single locally configured FAD.
The SR OS implementation assumes that the participation of a specific flex-algo is valid for all IGP areas. For example, for an IS-IS instance where Level 1 and Level 2 capability is enabled, that in both Levels both the algorithm is enabled and the FAD advertised if flexible-algorithm-definition advertisement is enabled.
All Flex-Algorithm participating nodes must advertise the locally used FADs when configured and optionally advertise node participation when the winning FAD is supported.
The winning FAD on a router is selected based on the following tie-breaker:
select the FAD with the highest priority
select the FAD advertised by the highest IGP system ID
If the local router does not support the winning FAD, the router should remove itself from the flex-algo topology by not advertising algorithm participation in the IS-IS router TLV capability. In such a case, no SPF is computed and any prefix SID of that flex-algo is removed from the associated routing and tunnel tables.
When the FAD selects a metric type, only links that have such metric type configured are considered for the flex-algo topology.
Leaking of a FAD on an ABR is not supported.
When advertising the FAD flags-TLV, the SR OS router always sets the M-flag, which forces the IS-IS routers to use Flex-Algorithm aware metrics for inter-area routing. The enforced M-flag ensures that the best ABR, according to the Flex-Algorithm, is selected to exit the area outside the local IGP area. Without the M-flag, the wrong ABR may be selected and cause routing loops or a traffic blackhole. This handling assumes that an ABR must advertise the IS-IS Flex-Algorithm prefix metric sub-TLV when leaking prefixes and associated SIDs. Advertising the flags-TLV is optional, and is controlled through the no flags-tlv configuration within the Flex-Algorithm definition.
SR OS supports the Administrative Groups (AGs) as defined in RFC 5305. The following considerations apply:
Up to 32 link colors can be used.
Flex-Algorithm feature reuses the existing AGs in combination with application-specific TLV extensions.
SR OS provides the following limited Extended Administrative Group (EAG) support for Flex-Algorithm.
The Nokia implementation supports only AG advertisement; EAG advertisement is not supported. The IS-IS TLV types used for an AG and an EAG are different.
For backward compatibility, vendors may use only the first 32 colors in the EAG.
If EAG is used to add a color on the links, the link attribute size can be 4 octets (or a multiple of 4 octets) long.
The EAG for Flex-Algorithms is forwarded for appropriate ASLA encoding in accordance with RFC 8919.
When an EAG ASLA link attribute is received, the SR OS router handles it as follows.
SR OS provides limited EAG support and only parses EAGs that are 4 octets long. The EAG represents a traditional 4-octet AG to support backward compatibility.
SR OS treats the ASLA-encoded EAG as opaque information when the EAG size is a multiple of 4 octets long (that is, 4, 8, and so on).
Because of limited EAG support, a new trap is not sent if the AG and EAG link attributes are inconsistent. In such a case, the AG attributes are used in accordance with RFC 7308.
The receipt of a Flex-Algorithm FAD that contains an include/exclude EAG ASLA link attribute is handled as follows.
If the SR OS router receives a FAD where the AG TLV length is 4 octets, the FAD can be used for flex-algo and it is treated as an AG.
If the SR OS router receives a FAD where the AG TLV length is greater than 4 octets and bits are set to 1 in the first 4 octets only (the remaining bits are set to 0), the FAD participates assuming that the AGs have been configured as a result of EAG backward compatibility.
If the SR OS router receives a FAD where the length of the AG TLV is greater than 4 octets and has bits set to 1 beyond the first 32 bits, the router blocks this FAD. SR OS does not support EAG bits beyond the first 32 bits.
Flex-Algorithm uses the IS-IS min/max unidirectional link delay sub-TLV as defined in RFC 8570. This delay is set through static configuration or through dynamic link delay measurement.
SR OS allows the user to enable and disable Flex-Algorithm Loop Free Alternate (LFA) paths. The LFA type is inherited from the algorithm 0 base topology configuration.
Operators can protect links and nodes using the LFA fast-convergence technology. If the primary path is constrained by a specific flex-algo topology, the LFA SPF calculation is executed within the flex-algo topology. This calculation identifies the correct LFA, R-LFA or TI-LFA bounded by this topology. Consequently, the constraints of a specific flex-algo topology are respected even during failure scenarios.
Enabling or disabling the flex-algo dependent LFA, R-LFA, or TI-LFA is aligned with enabling the LFA within the router flex-algo context.
A new configuration node LFA is added in the IGP parameter within the Flex-Algorithm configuration. The shutdown and no shutdown commands are also added to this node.
The LFA parameter allows the user to disable or enable loopfree alternates for this flex-algo. The rlfa and tlfa parameters are inherited from algorithm 0.
The Flex-Algorithm LFA exclude policy configuration is copied from the flex-algo 0 configuration.
The Flex-Algorithm aware LFA may cause additional resource consumption (for example, in memory and in CPU).
SR OS Flex-Algorithm support for LFA policies supported by algorithm 0, including SRLG, protection type, exclude and include groups.
To address interaction with SR-LDP mapping server, Flex-Algorithms are not compatible with the SR-LDP mapping server. SR OS only supports mapping-server TLV with algorithm 0.
Interaction with SR-TE policy
Flex-Algorithms have no impact on how SR-TE LSPs are used. Applications that support the use of SR-TE LSPs continue to be supported. All SR-TE resolution mechanisms are supported.
SR-TE changes as follows as a result of Flex-Algorithm support:
When an SR-TE path is constructed through manual router configuration or received from the PCE, the sequence of SR-TE SIDs may include one or more Flex-Algorithm prefix node SIDs.
At the SR-TE head-end router, the sequenced SR-TE label stack (the sequence of SIDs) is imposed upon the payload and the packet is forwarded using the NHLFE from the top label or SID.
Validity of a specific SR-TE LSP is the same as without Flex-Algorithm support.
To address interaction with SR policies, similar to SR-TE LSPs, SR policies are only influenced by Flex-Algorithms due to construction of the segment list. The segment list may be constructed using one or more Flex-Algorithm prefix node label SIDs. All applications capable of using SR policies have opaque awareness if a segment list is constructed using Flex-Algorithm labels or SIDs.
Flex-Algorithm and adjacency SID protection
During fast-reroute process, local repair of the links to reach the Q-node from the P-node is determined by the sub-topology defined by the Flex-Algorithm. Therefore, the used link considers the configured administrative group constraints.
However, the adj-sid backup is based upon algo=0, because adj-sids are not advertised using a Flex-Algorithm. Consequently, there is a risk to violate the Flex-Algorithm if the related link breaks while it is in use as backup for a Flex-Algorithm path. This Flex-Algorithm SLA break can be avoided when adj-sids are configured with no backup capability.
To address duplicate SID handling, IS-IS uses the first learned remote SID and generates a trap for duplicate entries.
Interaction with IGP shortcut and forwarding adjacency features
To select the optimal shortest path within a constrained topology, Flex-Algorithm paths are carefully crafted using the constraints specified in the FAD. If the constrained topology includes logical RSVP-TE links that conceal FAD constraints, the Flex-Algorithm may send traffic wrongly over out-of-profile physical links.
To avoid the use of Flex-Algorithm in the range of 128 to 255, which causes data plane traffic to be sent over tunnels that hide physical link properties, the following features are not supported:
SR-LDP stitching
IGP shortcut
forwarding adjacency; forwarding adjacencies are not considered in the flex-algo topology.
Relationship between Flex-Algorithm and algorithm 0 configuration
A configured router with Flex-Algorithm does not have to advertise an algo 0 SID.
Interaction of Flex-Algorithm aware nodes and FAD flags-TLV
When Flex-Algorithms are enabled, SR OS advertises by default FAD flags-TLV in IGP to signal the mandatory use of Flex-Algorithm aware performance metrics. For correct Flex-Algorithm operation, it is expected that Flex-Algorithm aware nodes support FAD flags-TLV interpretation. For improved interoperability, it is possible to stop advertising the FAD flags-TLV using the no flags-tlv command when defining a flexible algorithm on SR OS.
Flex-Algorithm for BGP services
BGP next hop can be automatically resolved over an IGP Flex-Algorithms topology using the import policy action flex-algo (for BGP, BGP LU, and VPN).
BGP next hop Flex-Algorithms aware autobind for BGP EVPN service is not supported.
Flex-Algorithm and TLV encoding
Flex-Algorithms BGP-LS export and TLV encoding is supported.