LSR Working Group W. Britto Internet-Draft S. Hegde Intended status: Standards Track P. Kaneriya Expires: 22 June 2022 R. Shetty R. Bonica Juniper Networks P. Psenak Cisco Systems 19 December 2021 IGP Flexible Algorithms (Flex-Algorithm) In IP Networks draft-ietf-lsr-ip-flexalgo-04 Abstract An 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 June 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Britto, et al. Expires 22 June 2022 [Page 1] Internet-Draft IP Flex-Algorithm December 2021 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Egress Node Procedures . . . . . . . . . . . . . . . . . . . 3 4. Advertising Flex-Algorithm Definitions (FAD) . . . . . . . . 3 5. Advertising IP Flex-Algorithm Participation . . . . . . . . . 3 5.1. The ISIS IP Algorithm Sub-TLV . . . . . . . . . . . . . . 4 5.2. The OSPF IP Algorithm TLV . . . . . . . . . . . . . . . . 5 6. Advertising IP Flex-Algorthm Reachability . . . . . . . . . . 6 6.1. The ISIS IPv4 Algorithm Prefix Reachability TLV . . . . . 6 6.2. The ISIS IPv6 Algorithm Prefix Reachability TLV . . . . . 8 6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV . . . 9 6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV . . . 10 6.5. The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV . . . 11 7. Calculating of IP Flex-Algorthm Paths . . . . . . . . . . . . 13 8. IP Flex-Algorthm Forwarding . . . . . . . . . . . . . . . . . 13 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 10. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 14.2. Informative References . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction An IGP Flex-Algorithm as specified in [I-D.ietf-lsr-flex-algo] computes a constraint-based path to: * All Flex-Algorithm specific Prefix Segment Identifiers (SIDs) [RFC8402]. * All Flex-Algorityhm specific SRv6 Locators [RFC8986]. Therefore, Flex-Algorithm cannot be deployed in the absence of SR and SRv6. Britto, et al. Expires 22 June 2022 [Page 2] Internet-Draft IP Flex-Algorithm December 2021 This document extends Flex-Algorithm, allowing it to compute paths to: * An IPv4 [RFC0791] address. * An IPv6 [RFC8200] address. This allows Flex-Algorithm to be deployed in any IP network, even in the absence of SR and SRv6. 2. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Egress Node Procedures 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. 4. Advertising Flex-Algorithm Definitions (FAD) 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 [I-D.ietf-lsr-flex-algo]. 5. Advertising IP Flex-Algorithm Participation A node may use various algorithms when calculating paths to nodes and prefixes. Algorithm values are defined in the IGP Algorithm Type Registry [IANA-ALG]. A node MUST participate in a Flex-Algorithm to be: * able to compute path for such Flex-Algorithm Britto, et al. Expires 22 June 2022 [Page 3] Internet-Draft IP Flex-Algorithm December 2021 * be part of the topology for such Flex-Algorithm Flex-Algorithm participation MUST be advertised for each Flex- Algorithm application independently, as specified in Section 10.2 of [I-D.ietf-lsr-flex-algo]. 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. 5.1. The ISIS IP Algorithm Sub-TLV The ISIS IP Algorithm Sub-TLV is a sub-TLV of the ISIS Router Capability TLV [RFC7981] and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ISIS IP Algorithm Sub-TLV * Type: IP Algorithm Sub-TLV (Value 29) * Length: Variable * Algorithm (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. Britto, et al. Expires 22 June 2022 [Page 4] Internet-Draft IP Flex-Algorithm December 2021 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. 5.2. The OSPF IP Algorithm TLV The OSPF IP Algorithm TLV is a top-level TLV of the Router Information Opaque LSA [RFC7770] and has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm... | Algorithm n | | +- -+ | | + + Figure 2: OSPF IP Algorithm TLV * Type: IP Algorithm TLV (Value TBD by IANA) * Length: Variable * Algorithm (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. Britto, et al. Expires 22 June 2022 [Page 5] Internet-Draft IP Flex-Algorithm December 2021 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. 6. Advertising IP Flex-Algorthm Reachability 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 [ISO10589] to advertise prefix reachability associated with a Flex-Algorithm. * The IPv4 Algorithm Prefix Reachability TLV * The IPv6 Algorithm Prefix Reachability TLV New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684] is defined to advertise prefix reachability associated with a Flex- Algorithm in OSPFv2. 6.1. The ISIS IPv4 Algorithm Prefix Reachability TLV 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. Britto, et al. Expires 22 June 2022 [Page 6] Internet-Draft IP Flex-Algorithm December 2021 The ISIS IPv4 Algorithm Prefix Reachability TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |R|R|R|R| MTID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ISIS IPv4 Algorithm Prefix Reachability TLV * 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: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pfx Length | Prefix (variable)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-tlv-len | Sub-TLVs (variable) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: ISIS IPv4 Algorithm Prefix Reachability TLV * Metric (4 octets): Metric information. * Flags (1 octet): 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |D| Reserved | +-+-+-+-+-+-+-+-+ D-flag: When the Prefix is leaked from level-2 to level-1, the Britto, et al. Expires 22 June 2022 [Page 7] Internet-Draft IP Flex-Algorithm December 2021 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- TLVs * Optional 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. 6.2. The ISIS IPv6 Algorithm Prefix Reachability TLV 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. Britto, et al. Expires 22 June 2022 [Page 8] Internet-Draft IP Flex-Algorithm December 2021 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. 6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV 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: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: OSPFv2 IP Algorithm Prefix Reachability Sub-TLV * Type (2 octets) : The value is TBD. * Length (1 octet): 8 * MT-ID (1 octet): Multi-Topology ID as defined in [RFC8402] * 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. Britto, et al. Expires 22 June 2022 [Page 9] Internet-Draft IP Flex-Algorithm December 2021 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. 6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV 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 [RFC8362]: * Intra-Area-Prefix TLV * Inter-Area-Prefix TLV * External-Prefix TLV The format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: OSPFv3 Algorithm Prefix Sub-TLV Where: Britto, et al. Expires 22 June 2022 [Page 10] Internet-Draft IP Flex-Algorithm December 2021 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 ([RFC2328]). 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. 6.5. The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV Section 10.2 of the [I-D.ietf-lsr-flex-algo] 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 [I-D.ietf-lsr-flex-algo] 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. Britto, et al. Expires 22 June 2022 [Page 11] Internet-Draft IP Flex-Algorithm December 2021 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 [I-D.ietf-lsr-flex-algo] - OSPFv3 Inter-Area-Router TLV defined in [RFC8362] OSPF IPFAAM Sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: 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 [I-D.ietf-lsr-flex-algo], 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. Britto, et al. Expires 22 June 2022 [Page 12] Internet-Draft IP Flex-Algorithm December 2021 FAAM Sub-TLV as defined in [I-D.ietf-lsr-flex-algo] MUST NOT be used during IP Flex-Algorithm path calculation, IPFAAM Sub-TLV MUST be used instead. 7. Calculating of IP Flex-Algorthm Paths IP Flex-Algorthm is considered as yet another application of the Flex-Algorithm as described in Section 10 and Section 12 of the [I-D.ietf-lsr-flex-algo]. Participation for the IP Flex-Algorithm is signalled as described in Section 5 and is specific to the IP Flex-Algorithm application. Calculation of IP Flex-Algorithm paths follows the Section 12 of [I-D.ietf-lsr-flex-algo]. 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 Section 5, MUST be pruned from the topology. 8. IP Flex-Algorthm Forwarding IP Algorithm Prefix Reachability advertisement as described in Section 5 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. Britto, et al. Expires 22 June 2022 [Page 13] Internet-Draft IP Flex-Algorithm December 2021 9. Deployment Considerations 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 [I-D.ietf-lsr-flex-algo], is application independent and is used by all Flex-Algorithm applications. Participation in the Flex-Algorithm, as described in [I-D.ietf-lsr-flex-algo], 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. 10. Protection 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) [RFC5286] * Remote Loop Free Alternates (R-LFA) [RFC7490] 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. Britto, et al. Expires 22 June 2022 [Page 14] Internet-Draft IP Flex-Algorithm December 2021 11. IANA Considerations This specification updates the OSPF Router Information (RI) TLVs Registry as follows: +=======+==================+===========================+ | Value | TLV Name | Reference | +=======+==================+===========================+ | TBD | IP Algorithm TLV | This Document Section 5.2 | +-------+------------------+---------------------------+ Table 1 This document also updates the "Sub-TLVs for TLV 242" registry as follows: +=======+======================+===========================+ | Value | TLV Name | Reference | +=======+======================+===========================+ | 29 | IP Algorithm Sub-TLV | This Document Section 5.1 | +-------+----------------------+---------------------------+ Table 2 This document also updates the "ISIS TLV Codepoints Registry" registry as follows: +=======+==================+=====+=====+=====+=======+=============+ | Value | TLV Name | IIH | LSP | SNP | Purge | Reference | +=======+==================+=====+=====+=====+=======+=============+ | 126 | IPv4 Algorithm | N | Y | N | N | This | | | Prefix | | | | | document, | | | Reachability TLV | | | | | Section 6.1 | +-------+------------------+-----+-----+-----+-------+-------------+ | 127 | IPv6 Algorithm | N | Y | N | N | This | | | Prefix | | | | | document, | | | Reachability TLV | | | | | Section 6.2 | +-------+------------------+-----+-----+-----+-------+-------------+ Table 3 This document updates the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry as follows: Britto, et al. Expires 22 June 2022 [Page 15] Internet-Draft IP Flex-Algorithm December 2021 +=======+=========================+================+ | Value | TLV Name | Reference | +=======+=========================+================+ | TBD | OSPFv2 IP Algorithm | This Document, | | | Prefix Reachability TLV | Section 6.3 | +-------+-------------------------+----------------+ Table 4 This document updates the "OSPFv3 Extended-LSA Sub-TLVs" registry as follows: +=======+==============================+================+ | Value | TLV Name | Reference | +=======+==============================+================+ | TBD | OSPFv3 IP Algorithm Prefix | This Document, | | | Reachability Sub-TLV | Section 6.4 | +-------+------------------------------+----------------+ | TBD | OSPFv3 IP Flexible Algorithm | This Document, | | | ASBR Metric Sub-TLV | Section 6.5 | +-------+------------------------------+----------------+ Table 5 This document updates the "OSPFv2 Extended Inter-Area ASBR Sub-TLVs" registry as follows: +=======+============================+================+ | Value | TLV Name | Reference | +=======+============================+================+ | 2 | OSPF IP Flexible Algorithm | This Document, | | | ASBR Metric Sub-TLV | Section 6.5 | +-------+----------------------------+----------------+ Table 6 12. Security Considerations This document inherits security considerations from [I-D.ietf-lsr-flex-algo]. 13. Acknowledgements Thanks to Bruno Decraene for his contributions to this document. Special thanks to Petr Bonbon Adamec of Cesnet for supporting interoperability testing. Britto, et al. Expires 22 June 2022 [Page 16] Internet-Draft IP Flex-Algorithm December 2021 14. References 14.1. Normative References [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", Work in Progress, Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 2021, . [ISO10589] IANA, "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)", August 1987, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . Britto, et al. Expires 22 June 2022 [Page 17] Internet-Draft IP Flex-Algorithm December 2021 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . 14.2. Informative References [IANA-ALG] IANA, "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV)", August 1987, . [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, . Britto, et al. Expires 22 June 2022 [Page 18] Internet-Draft IP Flex-Algorithm December 2021 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . Authors' Addresses William Britto Juniper Networks Elnath-Exora Business Park Survey Bangalore 560103 Karnataka India Email: bwilliam@juniper.net Shraddha Hegde Juniper Networks Elnath-Exora Business Park Survey Bangalore 560103 Karnataka India Email: shraddha@juniper.net Parag Kaneriya Juniper Networks Elnath-Exora Business Park Survey Bangalore 560103 Karnataka India Email: pkaneria@juniper.net Britto, et al. Expires 22 June 2022 [Page 19] Internet-Draft IP Flex-Algorithm December 2021 Rejesh Shetty Juniper Networks Elnath-Exora Business Park Survey Bangalore 560103 Karnataka India Email: mrajesh@juniper.net Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20171 United States of America Email: rbonica@juniper.net Peter Psenak Cisco Systems Apollo Business Center 82109 Mlynske nivy 43 Slovakia Email: ppsenak@cisco.com Britto, et al. Expires 22 June 2022 [Page 20]