IGP Flexible Algorithms (Flex-Algorithm)
In IP NetworksJuniper NetworksElnath-Exora Business Park SurveyBangaloreKarnataka560103Indiabwilliam@juniper.netJuniper NetworksElnath-Exora Business Park SurveyBangaloreKarnataka560103Indiashraddha@juniper.netJuniper NetworksElnath-Exora Business Park SurveyBangaloreKarnataka560103Indiapkaneria@juniper.netJuniper NetworksElnath-Exora Business Park SurveyBangaloreKarnataka560103Indiamrajesh@juniper.netJuniper Networks2251 Corporate Park DriveHerndon20171VirginiaUSArbonica@juniper.netCisco SystemsApollo Business CenterMlynske nivy 43Bratislava82109Slovakiappsenak@cisco.com
Routing Area
LSR Working GroupISISDraftAn IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
constraint-based paths. As currently defined, IGP Flex-Algorithm is used
with Segment Routing (SR) data planes - SR MPLS and SRv6. Therefore,
Flex-Algorithm cannot be deployed in the absence of SR.This document extends IGP Flex-Algorithm, so that it can be used for
regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be
deployed in any IP network, even in the absence of SR.An IGP Flex-Algorithm as specified in computes a constraint-based path to:
All Flex-Algorithm specific Prefix Segment Identifiers (SIDs)
.All Flex-Algorityhm specific SRv6 Locators .Therefore, Flex-Algorithm cannot be deployed in the absence of
SR and SRv6.This document extends Flex-Algorithm, allowing it to compute paths
to:An IPv4 address.An IPv6 address.This allows Flex-Algorithm to be deployed in any IP network,
even in the absence of SR and SRv6.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only
when, they appear in all capitals, as shown here.Network operators configure multiple loopback interfaces on an egress
node. They associate one or more IP addresses with each loopback
interface and one Flex-Algorithm with each IP address.If a packet is sent to a loopback address, and the loopback address
is not associated with a Flex-Algorithm, the packet follows the IGP
least-cost path to the egress node. If a packet is sent to a loopback
address, and the loopback address is associated with a Flex-Algorithm,
the packet follows the constraint-base path that the Flex-Algorithm
calculated.To guarantee loop free forwarding, all routers that participate in a
Flex-Algorithm MUST agree on the Flex-Algorithm Definition (FAD).Selected nodes within the IGP domain MUST advertise FADs as described
in Sections 5, 6 and 7 of .A node may use various algorithms when calculating paths to nodes and
prefixes. Algorithm values are defined in the IGP Algorithm Type Registry .A node MUST participate in a Flex-Algorithm to be:able to compute path for such Flex-Algorithmbe part of the topology for such Flex-AlgorithmFlex-Algorithm participation MUST be advertised for each
Flex-Algorithm application independently, as specified in Section 10.2
of . Using Flex-Algorithm for
regular IPv4 and IPv6 prefixes represents a new Flex-Algorithm
application (IP Flex-Algorithm), and as such the Flex-Algorithm
participation for the IP Flex-Algorithm application MUST be signalled
independently of any other Flex-Algorithm applications (e.g. SR).Following sections describe how the IP Flex-Algorithm participation
is advertised in IGP protocols.The ISIS IP Algorithm Sub-TLV is a sub-TLV of the ISIS Router
Capability TLV and has the following format:
Type: IP Algorithm Sub-TLV (Value 29)Length: VariableAlgorithm (1 octet): value from 1 to 255.The IP Algorithm Sub-TLV MUST be propagated throughout the level
and MUST NOT be advertised across level boundaries. Therefore, the S
bit in the Router Capability TLV, in which the IP Algorithm Sub-TLV is
advertised, MUST NOT be set.The IP Algorithm Sub-TLV is optional. It MUST NOT be advertised
more than once at a given level. A router receiving multiple IP
Algorithm sub-TLVs from the same originator SHOULD select the first
advertisement in the lowest-numbered LSP and subsequent instances of
the IP Algorithm Sub-TLV MUST be ignored.The IP Algorithm Sub-TLV advertises the participation in
Flex-Algorithms, and MUST NOT impact the router participation in
default algorithm 0. The IP Algorithm Sub-TLV could be used to
advertise support for non-zero standard algorithms, but that is
outside the scope of this document.The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
Sub-TLV is topology independent. When a router advertises
participation in ISIS IP Algorithm Sub-TLV, the participation applies
to all topologies in which the advertising node participates.The OSPF IP Algorithm TLV is a top-level TLV of the Router Information Opaque LSA and has the
following format: Type: IP Algorithm TLV (Value TBD by IANA)Length: VariableAlgorithm (1 octet): value from 1 to 255.The IP Algorithm TLV is optional. It SHOULD only be advertised once
in the Router Information Opaque LSA.When multiple IP Algorithm TLVs are received from a given router,
the receiver MUST use the first occurrence of the TLV in the Router
Information Opaque LSA. If the IP Algorithm TLV appears in multiple
Router Information Opaque LSAs that have different flooding scopes,
the IP Algorithm TLV in the Router Information Opaque LSA with the
area-scoped flooding scope MUST be used. If the IP Algorithm TLV
appears in multiple Router Information Opaque LSAs that have the same
flooding scope, the IP Algorithm TLV in the Router Information (RI)
Opaque LSA with the numerically smallest Instance ID MUST be used and
subsequent instances of the IP Algorithm TLV MUST be ignored.The RI LSA can be advertised at any of the defined opaque flooding
scopes (link, area, or Autonomous System (AS)). For the purpose of IP
Algorithm TLV advertisement, area-scoped flooding is REQUIRED.The IP Algorithm TLV advertises the participation in
Flex-Algorithms, and MUST NOT impact the router participation in
default algorithm 0. The IP Algorithm TLV could be used to advertise
support for non-zero standard algorithms, but that is outside the
scope of this document.The IP Flex-Algorithm participation advertised in OSPF IP Algorithm
TLV is topology independent. When a router advertises participation in
OSPF IP Algorithm TLV, the participation applies to all topologies in
which the advertising node participates.To be able to associate the prefix with the Flex-Algorithm, the
existing prefix reachability advertisements can not be used, because
they advertise the prefix reachability in default algorithm 0. Instead,
a new IP Flex-Algorithm reachability advertisements are defined in ISIS
and OSPF.The M-flag in FAD is not applicable to IP Algorithm Prefixes. Any IP
Algorithm Prefix advertisement includes the Algorithm and Metric fields.
When IP Algorithm Prefix is advertised between areas or domains, the
metric field in the IP Algorithm Prefix advertisement MUST be used
irrespective of the M-flag in the FAD advertisement.Two new top-level TLVs are defined in ISIS to advertise prefix reachability
associated with a Flex-Algorithm.The IPv4 Algorithm Prefix Reachability TLVThe IPv6 Algorithm Prefix Reachability TLVNew top-level TLV of OSPFv2 Extended Prefix Opaque LSA is defined to advertise prefix reachability
associated with a Flex-Algorithm in OSPFv2.A new top level TLV is defined for advertising IPv4 Flex-Algorithm
Prefix Reachability in ISIS - IPv4 Algorithm Prefix Reachability
TLV.This new TLV shares the sub-TLV space defined for TLVs 135, 235,
236 and 237.The ISIS IPv4 Algorithm Prefix Reachability TLV has the following
format: Type: IPv4 Algorithm Prefix Reachability TLV (Value 126).Length: variable.R bits (4 bits): reserved for future use. They MUST be set to
zero on transmission and MUST be ignored on receipt.MTID (12 bits): Multitopology Identifier as defined in
[RFC5120]. Note that the value 0 is legal.Followed by one or more prefix entries of the form: Metric (4 octets): Metric information.Flags (1 octet): D-flag: When the Prefix is leaked from level-2 to level-1,
the D bit MUST be set. Otherwise, this bit MUST be clear.
Prefixes with the D bit set MUST NOT be leaked from level-1 to
level-2. This is to prevent looping.Algorithm (1 octet): Associated Algorithm from 1 to 255.Prefix Len (1 octet): Prefix length measured in bits.Prefix (variable length): Prefix mapped to Flex-Algorithm.Optional Sub-TLV-length (1 octet): Number of octets used by
sub-TLVsOptional sub-TLVs (variable length).A router receiving multiple IPv4 Algorithm Prefix Reachability
advertisements for the same prefix, from the same originator, each
with a different Algorithm, MUST select the first advertisement in the
lowest-numbered LSP and ignore any subsequent IPv4 Algorithm Prefix
Reachability advertisements for the same prefix for any other
Algorithm.A router receiving multiple IPv4 Algorithm Prefix Reachability
advertisements for the same prefix, from different originators, each
with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements.In cases where a prefix advertisement is received in both a IPv4
Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability TLV,
the IPv4 Prefix Reachability advertisement MUST be preferred when
installing entries in the forwarding plane.The ISIS IPv6 Algorithm Prefix Reachability TLV is identical to the
ISIS IPv4 Algorithm Prefix Reachability TLV, except that it has a
unique type. The type is 127.A router receiving multiple IPv6 Algorithm Prefix Reachability
advertisements for the same prefix, from the same originator, each
with a different Algorithm, MUST select the first advertisement in the
lowest-numbered LSP and ignore any subsequent IPv6 Algorithm Prefix
Reachability advertisements for the same prefix for any other
Algorithm.A router receiving multiple IPv6 Algorithm Prefix Reachability
advertisements for the same prefix, from different originators, each
with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements.In cases where a prefix advertisement is received in both a IPv6
Prefix Reachability TLV and an IPv6 Algorithm Prefix Reachability TLV,
the IPv6 Prefix Reachability advertisement MUST be preferred when
installing entries in the forwarding plane.A new Sub-TLV of OSPFv2 Extended Prefix TLV is defined for
advertising IP Algorithm Prefix Reachability in OSPFv2 - OSPFv2 IP
Algorithm Prefix Reachability Sub-TLV.The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV has the
following format:Type (2 octets) : The value is TBD.Length (1 octet): 8MT-ID (1 octet): Multi-Topology ID as defined in Algorithm (1 octet): Associated Algorithm from 1 to 255.
Algorithm values are defined in the IGP Algorithm Type registry.
If the value of Algorithm is 0 the TLV MUST be ignored.Reserved: (2 octets). SHOULD be set to 0 on transmission and
MUST be ignored on reception.Metric (3 octets): The algorithm specific metric value.A OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix
Reachability Sub-TLVs in the same OSPFv2 Extended Prefix TLV, MUST
select the first advertisement of this Sub-TLV and MUST ignore all
remaining occurences of this Sub-TLV in the OSPFv2 Extended Prefix
TLV.A OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix
Reachability TLVs for the same prefix, from different originators,
each with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements.In cases where a prefix advertisement is received in any of the
LSAs advertising the prefix reachability for algorithm 0 (Router-LSA,
Summary-LSA, AS-external-LSA or NSSA AS-external LSA) and in an OSPFv2
IP Algorithm Prefix Reachability TLV, only the prefix reachability
advertisement for algorithm 0 MUST be used and all occurences of the
OSPFv2 IP Algorithm Prefix Reachability TLV MUST be ignored.The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is defined for
advertisement of the IP Algorithm Prefix Reachability in OSPFv3.The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is a sub-TLV of
the following OSPFv3 TLVs defined in : Intra-Area-Prefix TLVInter-Area-Prefix TLVExternal-Prefix TLVThe format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is
shown below:Where:Type (2 octets): The value is TBD.Length (2 octets): 4.Algorithm (1 octet): Associated Algorithm from 1 to 255.
Algorithm values are defined in the IGP Algorithm Type registry.
If the value of Algorithm is 0 the TLV MUST be ignored.Metric (3 octets): The algorithm specific metric value.When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is
present, the metric value in its parent TLV MUST be set to LSInfinity
(). If the metric value in the parent TLV is
not set to LSInfinity, the OSPFv3 IP Algorithm Prefix Sub-TLV MUST be
ignored by the receiver.A OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
Reachability Sub-TLVs in the same parent TLV, MUST select the first
advertisement of this Sub-TLV and MUST ignore all remaining occurences
of this Sub-TLV in the parent TLV.A OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
Reachability TLVs for the same prefix, from different originators,
each with a different Algorithm, MUST ignore all of them and MUST NOT
install any forwarding entries based on these advertisements.In cases where a prefix advertisement is received in any of the
TLVs advertising the prefix reachability for algorithm 0
(Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, or External-Prefix TLV)
with metric other then LSInfinity, all OSPFv3 IP Algorithm Prefix TLVs
received for the prefix MUST be ignored.Section 10.2 of the defines
the OSPF Flexible Algorithm ASBR Metric Sub-TLV (FAAM) that is used by
OSPFv2 and OSPFv3 to advertise Flex-Algorithm specific metric
associated with a given ASBR reachability advertisement by an ABR.As described in section 11 of each application signals the
participation independently. IP Flex-Algorithm participation is
signalled independently of the Segment Routing (SR) Flex-Algorithm
participation. As a result, the calculated topologies for SR and IP
Flex-Algorithm could be different. Such difference prevents the usage
of FAAM for the purpose of the IP Flex-Algorithm.The OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is
defined for the advertisement of the IP Flex-Algorithm specific metric
associated with an ASBR by the ABR.The IPFAAM Sub-TLV is a Sub-TLV of the: - OSPFv2 Extended Inter-Area ASBR TLV as defined in - OSPFv3 Inter-Area-Router TLV defined in OSPF IPFAAM Sub-TLV has the following format: Type (2 octets): TBD for OSPFv2, TBD for OSPFv3.Length (2 octets): 8.Algorithm (1 octet): Associated Algorithm from 1 to 255.
Algorithm values are defined in the IGP Algorithm Type registry.
If the value of Algorithm is 0 the TLV MUST be ignored.Reserved: (3 octets). SHOULD be set to 0 on transmission and
MUST be ignored on reception.Metric (4 octets): The algorithm specific metric value.The usage of the IPFAAM Sub-TLV is similar to the usage of the FAAM
Sub-TLV defined in , but it is
used to advertise IP Flex-Algorithm metric.An OSPF ABR MUST include the OSPF IPFAAM Sub-TLVs as part of the
ASBR reachability advertisement between areas for every IP
Flex-Algorithm in which it participates and the ASBR is reachable
in.FAAM Sub-TLV as defined in
MUST NOT be used during IP Flex-Algorithm path calculation, IPFAAM
Sub-TLV MUST be used instead.IP Flex-Algorthm is considered as yet another application of the
Flex-Algorithm as described in Section 10 and Section 12 of the .Participation for the IP Flex-Algorithm is signalled as described in
and is specific to the IP Flex-Algorithm
application.Calculation of IP Flex-Algorithm paths follows the Section 12 of
. This computation uses the IP
Flex-Algorithm participation and is independent of the Flex-Algorithm
calculation done for any other Flex-Algorithm applications (e.g. SR,
SRv6).IP Flex-Algorithm application only considers participating nodes
during the Flex-Algorithm calculation. When computing paths for a given
Flex-Algorithm, all nodes that do not advertise participation for IP
Flex-Algorithm, as described in , MUST be
pruned from the topology.IP Algorithm Prefix Reachability advertisement as described in includes the MTID value that associates the
prefix with a specific topology. Algorithm Prefix Reachability
advertisement also includes an Algorithm value that explicitly
associates the prefix with a specific Flex-Algorithm. The paths to the
prefix MUST be calculated using the specified Flex-Algorithm in the
associated topology.Forwarding entries for the IP Flex-Algorithm prefixes advertised in
IGPs MUST be installed in the forwarding plane of the receiving IP
Flex-Algorithm prefix capable routers when they participate in the
associated topology and algorithm. Forwarding entries for IP
Flex-Algorithm prefixes associated with Flex-Algorithms in which the
node is not participating MUST NOT be installed in the forwarding
plane.When the IP Flex-Algorithm prefix is associated with a
Flex-Algorithm, LFA paths to the prefix MUST be calculated using such
Flex-Algorithm in the associated topology, to guarantee that they follow
the same constraints as the calculation of the primary paths.IGP Flex-Algorithm can be used by many applications. Original
specification was done for SR and SRv6, this specification adds IP as
another application that can use IGP Flex-Algorithm. Other applications
may be defined in the future. This section provides some details about
the coexistence of the various applications of the IGP
Flex-Algorithm.Flex-Algorithm definition (FAD), as described in , is application independent and is
used by all Flex-Algorithm applications.Participation in the Flex-Algorithm, as described in , is application specific.Calculation of the flex-algo paths is application specific and uses
application specific participation advertisements.Application specific participation and calculation guarantee that the
forwarding of the traffic over the Flex-Algorithm application specific
paths is consistent between all nodes over which the traffic is being
forwarded.Multiple application can use the same Flex-Algorithm value at the
same time and and as such share the FAD for it. For example SR-MPLS and
IP can both use such common Flex-Algorithm. Traffic for SR-MPLS will be
forwarded based on Flex-algorithm specific SR SIDs. Traffic for IP
Flex-Algorithm will be forwarded based on Flex-Algorithm specific prefix
reachability announcements.In many networks where IGP Flexible Algorithms are deployed, IGP
restoration will be fast and additional protection mechanisms will not
be required. IGP restoration may be enhanced by Equal Cost Multipath
(ECMP).In other networks, operators can deploy additional protection
mechanisms. The following are examples:Loop Free Alternates (LFA)Remote Loop Free Alternates (R-LFA)
LFA and R-LFA computations MUST be restricted to the flex-algo
topology and the computed backup nexthops should be programmed for the
IP flex-algo prefixes.This specification updates the OSPF Router Information (RI) TLVs
Registry as follows:ValueTLV NameReferenceTBDIP Algorithm TLVThis Document This document also updates the "Sub-TLVs for TLV 242" registry as
follows:ValueTLV NameReference29IP Algorithm Sub-TLVThis Document This document also updates the "ISIS TLV Codepoints Registry"
registry as follows:ValueTLV NameIIHLSPSNPPurgeReference126IPv4 Algorithm Prefix Reachability TLVNYNNThis document, 127IPv6 Algorithm Prefix Reachability TLVNYNNThis document, This document updates the "OSPFv2 Extended Prefix TLV Sub-TLVs"
registry as follows:ValueTLV NameReferenceTBDOSPFv2 IP Algorithm Prefix Reachability TLVThis Document, This document updates the "OSPFv3 Extended-LSA Sub-TLVs" registry as
follows:ValueTLV NameReferenceTBDOSPFv3 IP Algorithm Prefix Reachability Sub-TLVThis Document, TBDOSPFv3 IP Flexible Algorithm ASBR Metric Sub-TLVThis Document, This document updates the "OSPFv2 Extended Inter-Area ASBR Sub-TLVs"
registry as follows:ValueTLV NameReference2OSPF IP Flexible Algorithm ASBR Metric Sub-TLVThis Document, This document inherits security considerations from .Thanks to Bruno Decraene for his contributions to this document.
Special thanks to Petr Bonbon Adamec of Cesnet for supporting
interoperability testing.Intermediate system to Intermediate system routing
information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service (ISO
8473)IANASub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV)IANA