diff options
Diffstat (limited to 'doc/rfc/rfc9502.txt')
| -rw-r--r-- | doc/rfc/rfc9502.txt | 1112 |
1 files changed, 1112 insertions, 0 deletions
diff --git a/doc/rfc/rfc9502.txt b/doc/rfc/rfc9502.txt new file mode 100644 index 0000000..80e927e --- /dev/null +++ b/doc/rfc/rfc9502.txt @@ -0,0 +1,1112 @@ + + + + +Internet Engineering Task Force (IETF) W. Britto +Request for Comments: 9502 S. Hegde +Category: Standards Track P. Kaneriya +ISSN: 2070-1721 R. Shetty + R. Bonica + Juniper Networks + P. Psenak + Cisco Systems + November 2023 + + + IGP Flexible Algorithm in IP Networks + +Abstract + + This document extends IGP Flexible Algorithm so that it can be used + with regular IPv4 and IPv6 forwarding. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9502. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. Requirements Language + 3. Use Case Example + 4. Advertising Flexible Algorithm Definitions (FADs) + 5. Advertising IP Flexible Algorithm Participation + 5.1. The IS-IS IP Algorithm Sub-TLV + 5.2. The OSPF IP Algorithm TLV + 6. Advertising IP Flexible Algorithm Reachability + 6.1. The IS-IS IPv4 Algorithm Prefix Reachability TLV + 6.2. The IS-IS IPv6 Algorithm Prefix Reachability TLV + 6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV + 6.3.1. The OSPFv2 IP Forwarding Address Sub-TLV + 6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV + 6.5. The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV + 7. Calculating of IP Flexible Algorithm Paths + 8. IP Flexible Algorithm Forwarding + 9. Deployment Considerations + 10. Protection + 11. IANA Considerations + 12. Security Considerations + 13. References + 13.1. Normative References + 13.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + An IGP Flexible Algorithm allows IGPs to compute constraint-based + paths. The base IGP Flexible Algorithm specification describes how + it is used with Segment Routing (SR) data planes: SR MPLS and SRv6. + + An IGP Flexible Algorithm as specified in [RFC9350] computes a + constraint-based path to: + + * All Flexible-Algorithm-specific Prefix Segment Identifiers (SIDs) + [RFC8402]. + + * All Flexible-Algorithm-specific SRv6 Locators [RFC8986]. + + Therefore, Flexible Algorithm cannot be deployed in the absence of SR + or SRv6. + + This document extends Flexible Algorithm, allowing it to compute + paths to IPv4 and IPv6 prefixes. + +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. Use Case Example + + In this section, we illustrate one use case that motivates this + specification: if a specific service can be identified by an IP + address, traffic to it can use constraint-based paths computed + according to this specification. + + The System architecture for the 5G System [TS.23.501-3GPP] describes + the N3 interface between gNodeB and UPF (User Plane Function). + + Mobile networks are becoming more and more IP-centric. Each end-user + session from a gNodeB can be destined to a specific UPF based on the + session requirements. For example, some sessions require high + bandwidth, while others need to be routed along the lowest latency + path. Each UPF is assigned a unique IP address. As a result, + traffic for different sessions is destined to a different destination + IP address. + + The IP address allocated to the UPF can be associated with an + algorithm. The mobile user traffic is then forwarded along the path + based on the algorithm-specific metric and constraints. As a result, + traffic can be sent over a path that is optimized for minimal latency + or highest bandwidth. This mechanism is used to achieve Service + Level Agreement (SLA) appropriate for a user session. + +4. Advertising Flexible Algorithm Definitions (FADs) + + To guarantee loop-free forwarding, all routers that participate in a + Flex-Algorithm MUST agree on the Flexible Algorithm Definition (FAD). + + Selected nodes within the IGP domain MUST advertise FADs as described + in Sections 5, 6, and 7 of [RFC9350]. + +5. Advertising IP Flexible Algorithm Participation + + A node may use various algorithms when calculating paths to nodes and + prefixes. Algorithm values are defined in the "IGP Algorithm Types" + registry [IANA-ALG]. + + Only a node that is participating in a Flex-Algorithm is: + + * Able to compute a path for such Flex-Algorithm + + * Part of the topology for such Flex-Algorithm + + Flexible Algorithm participation MUST be advertised for each Flexible + Algorithm data plane independently, as specified in [RFC9350]. Using + Flexible Algorithm for regular IPv4 and IPv6 prefixes represents an + independent Flexible Algorithm data plane; as such, the Flexible + Algorithm participation for the IP Flexible Algorithm data plane MUST + be signaled independently of any other Flexible Algorithm data plane + (e.g., SR). + + All routers in an IGP domain participate in default algorithm 0. + Advertisement of participation in IP Flexible Algorithm does not + impact the router participation in default algorithm 0. + + Advertisement of participation in IP Flexible Algorithm does not + impact the router participation signaled for other data planes. For + example, it is possible that a router participates in a particular + Flex-Algorithm for the IP data plane but does not participate in the + same Flex-Algorithm for the SR data plane. + + The following sections describe how the IP Flexible Algorithm + participation is advertised in IGP protocols. + +5.1. The IS-IS IP Algorithm Sub-TLV + + The IS-IS [ISO10589] IP Algorithm Sub-TLV is a sub-TLV of the IS-IS + 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: IS-IS IP Algorithm Sub-TLV + + Type (1 octet): IP Algorithm Sub-TLV (Value 29) + + Length (1 octet): Variable + + Algorithm (1 octet): Value from 128 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 MUST select the first advertisement + in the lowest-numbered Link State PDU (LSP), and subsequent instances + of the IP Algorithm Sub-TLV MUST be ignored. + + Algorithms outside the Flex-Algorithm range (128-255) MUST be ignored + by the receiver. This situation SHOULD be logged as an error. + + The IP Flex-Algorithm participation advertised in the IS-IS IP + Algorithm Sub-TLV is topology independent. When a router advertises + participation in the IS-IS 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 [RFC2328] IP Algorithm TLV is a top-level TLV of the Router + Information Opaque Link State Advertisement (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 (2 octets): IP Algorithm TLV (21) + + Length( 2 octets): Variable + + Algorithm (1 octet): Value from 128 to 255 + + The IP Algorithm TLV is optional. It MUST only be advertised once in + the Router Information LSA. + + Algorithms outside the Flex-Algorithm range (128-255) MUST be ignored + by the receiver. This situation SHOULD be logged as an error. + + 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 LSA. If the IP Algorithm TLV appears in multiple Router + Information LSAs that have different flooding scopes, the IP + Algorithm TLV in the Router Information LSA with the area-scoped + flooding scope MUST be used. If the IP Algorithm TLV appears in + multiple Router Information LSAs that have the same flooding scope, + the IP Algorithm TLV in the Router Information LSA with the + numerically smallest Instance ID (Opaque ID for OSPFv2 or Link State + ID for OSPFv3) MUST be used, and subsequent instances of the IP + Algorithm TLV MUST be ignored. + + The Router Information LSA can be advertised at any of the defined + flooding scopes (link, area, or Autonomous System (AS)). For the + purpose of IP Algorithm TLV advertisement, area- or AS-scoped + flooding is REQUIRED. The AS flooding scope SHOULD NOT be used + unless local configuration policy on the originating router indicates + domain-wide flooding. + + The IP Flexible Algorithm participation advertised in the 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 Flexible Algorithm Reachability + + To be able to associate the prefix with the Flex-Algorithm, the + existing prefix reachability advertisements cannot be used, because + they advertise the prefix reachability in default algorithm 0. + Instead, new IP Flexible Algorithm reachability advertisements are + defined in IS-IS and OSPF. + + The M-flag in the FAD is not applicable to IP Algorithm Prefixes. + Any IP Algorithm Prefix advertisement includes the Algorithm and + Metric fields. When an 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. + +6.1. The IS-IS IPv4 Algorithm Prefix Reachability TLV + + The IPv4 Algorithm Prefix Reachability top-level TLV is defined for + advertising IPv4 Flexible Algorithm Prefix Reachability in IS-IS. + + This new TLV shares the sub-TLV space defined for TLVs Advertising + Prefix Reachability. + + The IS-IS 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 | Rsvd | MTID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: IS-IS IPv4 Algorithm Prefix Reachability TLV + + Type (1 octet): IPv4 Algorithm Prefix Reachability TLV (Value 126) + + Length (1 octet): Variable based on number of prefix entries encoded + + Rsvd (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: IS-IS IPv4 Algorithm Prefix Reachability TLV + + Metric (4 octets): Metric information as defined in [RFC5305] + + Flags (1 octet): + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |D| Reserved | + +-+-+-+-+-+-+-+-+ + + D-flag: The D-flag is described as the "up/down bit" in + Section 4.1 of [RFC5305]. 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. + + The remaining bits: Reserved for future use. They MUST be set to + zero on transmission and MUST be ignored on receipt. + + Algorithm (1 octet): Associated Algorithm from 128 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) + + If the Algorithms in the IS-IS IPv4 Algorithm Prefix Reachability TLV + are outside the Flex-Algorithm range (128-255), the IS-IS IPv4 + Algorithm Prefix Reachability TLV MUST be ignored by the receiver. + This situation SHOULD be logged as an error. + + If a router receives multiple IPv4 Algorithm Prefix Reachability + advertisements for the same prefix from the same originator, it MUST + select the first advertisement in the lowest-numbered LSP and ignore + any subsequent IPv4 Algorithm Prefix Reachability advertisements for + the same prefix. + + If a router receives multiple IPv4 Algorithm Prefix Reachability + advertisements for the same prefix, from different originators, where + all of them do not advertise the same algorithm, it MUST ignore all + of them and MUST NOT install any forwarding entries based on these + advertisements. This situation SHOULD be logged as an error. + + In cases where a prefix advertisement is received in both an IPv4 + Prefix Reachability TLV [RFC5305] [RFC5120] 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 IS-IS IPv6 Algorithm Prefix Reachability TLV + + The IS-IS IPv6 Algorithm Prefix Reachability TLV is identical to the + IS-IS IPv4 Algorithm Prefix Reachability TLV, except that it has a + distinct type. The type is 127. + + If the Algorithms in the IS-IS IPv6 Algorithm Prefix Reachability TLV + are outside the Flex-Algorithm range (128-255), the IS-IS IPv6 + Algorithm Prefix Reachability TLV MUST be ignored by the receiver. + This situation SHOULD be logged as an error. + + If a router receives multiple IPv6 Algorithm Prefix Reachability + advertisements for the same prefix from the same originator, it MUST + select the first advertisement in the lowest-numbered LSP and ignore + any subsequent IPv6 Algorithm Prefix Reachability advertisements for + the same prefix. + + If a router receives multiple IPv6 Algorithm Prefix Reachability + advertisements for the same prefix, from different originators, where + all of them do not advertise the same algorithm, it MUST ignore all + of them and MUST NOT install any forwarding entries based on these + advertisements. This situation SHOULD be logged as an error. + + In cases where a prefix advertisement is received in both an IPv6 + Prefix Reachability TLV [RFC5308] [RFC5120] and an IPv6 Algorithm + Prefix Reachability TLV, the IPv6 Prefix Reachability advertisement + MUST be preferred when installing entries in the forwarding plane. + + In cases where a prefix advertisement is received in both an IS-IS + SRv6 Locator TLV [RFC9352] and in IS-IS IPv6 Algorithm Prefix + Reachability TLV, the receiver MUST ignore both of them and MUST NOT + install any forwarding entries based on these advertisements. This + situation SHOULD be logged as an error. + +6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV + + A new sub-TLV of the OSPFv2 Extended Prefix TLV is defined for + advertising IP Algorithm Prefix Reachability in OSPFv2, the 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 | Flags | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: OSPFv2 IP Algorithm Prefix Reachability Sub-TLV + + Type (2 octets): The value is 6 + + Length (2 octets): 8 + + MT-ID (1 octet): Multi-Topology ID as defined in [RFC4915] + + Algorithm (1 octet): Associated Algorithm from 128 to 255 + + Flags (1 octet): The following flags are defined: + + 0 1 2 3 4 5 6 7 8 + +-+-+-+-+-+-+-+-+-+ + |E| Reserved | + +-+-+-+-+-+-+-+-+-+ + + Where: + + E bit: The same as the E bit defined in Appendix A.4.5 of + [RFC2328]. + + The remaining bits: Reserved for future use. They MUST be set to + zero on transmission and MUST be ignored on receipt. + + Reserved (1 octet): SHOULD be set to 0 on transmission and MUST be + ignored on reception. + + Metric (4 octets): The algorithm-specific metric value. The metric + value of 0XFFFFFFFF MUST be considered unreachable. + + If the Algorithms in the OSPFv2 IP Algorithm Prefix Reachability Sub- + TLV are outside the Flex-Algorithm range (128-255), the OSPFv2 IP + Algorithm Prefix Reachability Sub-TLV MUST be ignored by the + receiver. This situation SHOULD be logged as an error. + + An 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 occurrences of this sub-TLV in the OSPFv2 Extended Prefix + TLV. + + An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix + Reachability TLVs for the same prefix from different originators + where all of them do not advertise the same algorithm MUST ignore all + of them and MUST NOT install any forwarding entries based on these + advertisements. This situation SHOULD be logged as an error. + + In cases where a prefix advertisement is received in any of the LSAs + advertising the prefix reachability for algorithm 0 and in an OSPFv2 + IP Algorithm Prefix Reachability Sub-TLV, only the prefix + reachability advertisement for algorithm 0 MUST be used, and all + occurrences of the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV + MUST be ignored. + + When computing the IP Algorithm Prefix reachability in OSPFv2, only + information present in the OSPFv2 Extended Prefix TLV MUST be used. + There will not be any information advertised for the IP Algorithm + Prefix in any of the OSPFv2 LSAs that advertise prefix reachability + for algorithm 0. For the IP Algorithm Prefix, the OSPFv2 Extended + Prefix TLV is used to advertise the prefix reachability, unlike for + algorithm 0 prefixes, where the OSPFv2 Extended Prefix TLV is only + used to advertise additional attributes -- but not the reachability + itself. + +6.3.1. The OSPFv2 IP Forwarding Address Sub-TLV + + A new sub-TLV of the OSPFv2 Extended Prefix TLV is defined for + advertising IP Forwarding Address, the OSPFv2 IP Forwarding Address + Sub-TLV. + + The OSPFv2 IP Forwarding Address 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Forwarding Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: OSPFv2 IP Forwarding Address Sub-TLV + + Type (2 octets): The value is 7 + + Length (2 octets): 4 + + Forwarding Address (4 octets): The same as defined in Appendix A.4.5 + of [RFC2328] + + The OSPFv2 IP Forwarding Address Sub-TLV MUST NOT be used for + computing algorithm 0 prefix reachability and MUST be ignored for + algorithm 0 prefixes. + + The OSPFv2 IP Forwarding Address Sub-TLV is optional. If it is not + present, the forwarding address for computing the IP Algorithm Prefix + reachability is assumed to be equal to 0.0.0.0. + + The OSPFv2 IP Forwarding Address Sub-TLV is only applicable to AS + External and Not-So-Stubby Area (NSSA) External route types. If the + OSPFv2 IP Forwarding Address Sub-TLV is advertised in the OSPFv2 + Extended Prefix TLV that has the Route Type field set to any other + type, the OSPFv2 IP Forwarding Address Sub-TLV MUST be ignored. + +6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV + + The OSPFv3 [RFC5340] 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 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: OSPFv3 IP Algorithm Prefix Reachability Sub-TLV + + Where: + + Type (2 octets): The value is 35 + + Length (2 octets): 8 + + Algorithm (1 octet): Associated Algorithm from 128 to 255 + + 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 metric + value of 0XFFFFFFFF MUST be considered unreachable. + + If the Algorithms in the OSPFv3 IP Algorithm Prefix Reachability Sub- + TLV are outside the Flex-Algorithm range (128-255), the OSPFv3 IP + Algorithm Prefix Reachability Sub-TLV MUST be ignored by the + receiver. This situation SHOULD be logged as an error. + + When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is present, + the NU-bit in the PrefixOptions field of the parent TLV MUST be set. + This is needed to prevent the OSPFv3 IP Algorithm Prefix Reachability + advertisement from contributing to the base algorithm reachability. + If the NU-bit in the PrefixOptions field of the parent TLV is not + set, the OSPFv3 IP Algorithm Prefix Sub-TLV MUST be ignored by the + receiver. + + The metric value in the parent TLV is RECOMMENDED to be set to + LSInfinity [RFC2328]. This recommendation is provided as a network + troubleshooting convenience; if it is not followed, the protocol will + still function correctly. + + An 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 + occurrences of this sub-TLV in the parent TLV. + + An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix + Reachability TLVs for the same prefix from different originators + where all of them do not advertise the same algorithm MUST ignore all + of them and MUST NOT install any forwarding entries based on these + advertisements. This situation SHOULD be logged as an error. + + In cases where a prefix advertisement is received in any of the LSAs + advertising the prefix reachability for algorithm 0 and in an OSPFv3 + OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, only the prefix + reachability advertisement for algorithm 0 MUST be used, and all + occurrences of the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV + MUST be ignored. + + In cases where a prefix advertisement is received in both an OSPFv3 + SRv6 Locator TLV and in an OSPFv3 IP Algorithm Prefix Reachability + Sub-TLV, the receiver MUST ignore both of them and MUST NOT install + any forwarding entries based on these advertisements. This situation + SHOULD be logged as an error. + +6.5. The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV + + [RFC9350] defines the OSPF Flexible Algorithm ASBR Metric (FAAM) Sub- + TLV that is used by an OSPFv2 or an OSPFv3 Area Border Router (ABR) + to advertise a Flex-Algorithm-specific metric associated with the + corresponding ASBR LSA. + + As described in [RFC9350], each data plane signals its participation + independently. IP Flexible Algorithm participation is signaled + independent of SR Flexible Algorithm participation. As a result, the + calculated topologies for SR and IP Flexible Algorithm could be + different. Such a difference prevents the usage of FAAM for the + purpose of the IP Flexible 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 [RFC9350] + + * OSPFv3 Inter-Area-Router TLV, as defined in [RFC8362] + + The 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: OSPF IP Flexible Algorithm ASBR Metric Sub-TLV + + Where: + + Type (2 octets): 2 (allocated by IANA) for OSPFv2, 36 for OSPFv3 + + Length (2 octets): 8 + + Algorithm (1 octet): Associated Algorithm from 128 to 255 + + Reserved (3 octets): SHOULD be set to 0 on transmission and MUST be + ignored on reception + + Metric (4 octets): The algorithm-specific metric value + + If the Algorithms in the OSPF IP Flexible Algorithm ASBR Metric Sub- + TLV are outside the Flex-Algorithm range (128-255), the OSPF IP + Flexible Algorithm ASBR Metric Sub-TLV MUST be ignored by the + receiver. This situation SHOULD be logged as an error. + + The usage of the IPFAAM Sub-TLV is similar to the usage of the FAAM + Sub-TLV defined in [RFC9350], but it is used to advertise IP Flexible + Algorithm metric. + + An OSPF ABR MUST include the OSPF IPFAAM Sub-TLVs as part of any IP + Flexible Algorithm ASBR reachability advertisement between areas. + + The FAAM Sub-TLV as defined in [RFC9350] MUST NOT be used during IP + Flexible Algorithm path calculation; the IPFAAM Sub-TLV MUST be used + instead. + +7. Calculating of IP Flexible Algorithm Paths + + The IP Flexible Algorithm is considered as yet another data plane of + the Flexible Algorithm as described in [RFC9350]. + + Participation in the IP Flexible Algorithm is signaled as described + in Section 5 and is specific to the IP Flexible Algorithm data plane. + + Calculation of IP Flexible Algorithm paths follows what is described + in [RFC9350]. This computation uses the IP Flexible Algorithm data + plane participation and is independent of the Flexible Algorithm + calculation done for any other Flexible Algorithm data plane (e.g., + SR, SRv6). + + The IP Flexible Algorithm data plane only considers participating + nodes during the Flexible Algorithm calculation. When computing + paths for a given Flex-Algorithm, all nodes that do not advertise + participation for such IP Flex-Algorithm, as described in Section 5, + MUST be pruned from the topology. + +8. IP Flexible Algorithm Forwarding + + The 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. + +9. Deployment Considerations + + IGP Flexible Algorithm can be used by many data planes. The original + specification was done for SR and SRv6; this specification adds IP as + another data plane that can use IGP Flexible Algorithm. Other data + planes may be defined in the future. This section provides some + details about the coexistence of the various data planes of an IGP + Flexible Algorithm. + + Flexible Algorithm Definition (FAD), as described in [RFC9350], is + data plane independent and is used by all Flexible Algorithm data + planes. + + Participation in the Flexible Algorithm, as described in [RFC9350], + is data plane specific. + + Calculation of the Flexible Algorithm paths is data plane specific + and uses data-plane-specific participation advertisements. + + Data-plane-specific participation and calculation guarantee that the + forwarding of the traffic over the Flex-Algorithm data-plane-specific + paths is consistent between all nodes that apply the IGP Flex- + Algorithm to the data plane. + + Multiple data planes 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 a 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 advertisements. Note that for + a particular Flex-Algorithm, for a particular IP prefix, there will + only be path(s) calculated and installed for a single data plane. + +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 (LFAs) [RFC5286] + + * Remote Loop-Free Alternates (R-LFAs) [RFC7490] + + LFA and R-LFA computations MUST be restricted to the Flex-Algorithm + topology and the computed backup next hops should be programmed for + the IP Flex-Algorithm prefixes. + +11. IANA Considerations + + This specification updates the "OSPF Router Information (RI) TLVs" + registry as follows: + + +=======+==============+=======================+ + | Value | TLV Name | Reference | + +=======+==============+=======================+ + | 21 | IP Algorithm | RFC 9502, Section 5.2 | + +-------+--------------+-----------------------+ + + Table 1 + + This document also updates the "IS-IS Sub-TLVs for IS-IS Router + CAPABILITY TLV" registry as follows: + + +=======+==============+=======================+ + | Value | TLV Name | Reference | + +=======+==============+=======================+ + | 29 | IP Algorithm | RFC 9502, Section 5.1 | + +-------+--------------+-----------------------+ + + Table 2 + + This document also updates the "IS-IS Top-Level TLV Codepoints" + registry as follows: + + +=======+=====================+=====+=====+=====+=======+===========+ + | Value | TLV Name | IIH | LSP | SNP | Purge | Reference | + +=======+=====================+=====+=====+=====+=======+===========+ + | 126 | IPv4 Algorithm | n | y | n | n | RFC 9502, | + | | Prefix | | | | | Section | + | | Reachability | | | | | 6.1 | + +-------+---------------------+-----+-----+-----+-------+-----------+ + | 127 | IPv6 Algorithm | n | y | n | n | RFC 9502, | + | | Prefix | | | | | Section | + | | Reachability | | | | | 6.2 | + +-------+---------------------+-----+-----+-----+-------+-----------+ + + Table 3 + + Since the above TLVs share the sub-TLV space managed in the "IS-IS + Sub-TLVs for TLVs Advertising Prefix Reachability" registry, IANA has + added "IPv4 Algorithm Prefix Reachability TLV (126)" and "IPv6 + Algorithm Prefix Reachability TLV (127)" to the list of TLVs in the + description of that registry. + + In addition, columns headed "126" and "127" have been added to that + registry, as follows: + + +======+=========================================+=====+=====+ + | Type | Description | 126 | 127 | + +======+=========================================+=====+=====+ + | 1 | 32-bit Administrative Tag Sub-TLV | y | y | + +------+-----------------------------------------+-----+-----+ + | 2 | 64-bit Administrative Tag Sub-TLV | y | y | + +------+-----------------------------------------+-----+-----+ + | 3 | Prefix Segment Identifier | n | n | + +------+-----------------------------------------+-----+-----+ + | 4 | Prefix Attribute Flags | y | y | + +------+-----------------------------------------+-----+-----+ + | 5 | SRv6 End SID | n | n | + +------+-----------------------------------------+-----+-----+ + | 6 | Flexible Algorithm Prefix Metric (FAPM) | n | n | + +------+-----------------------------------------+-----+-----+ + | 11 | IPv4 Source Router ID | y | y | + +------+-----------------------------------------+-----+-----+ + | 12 | IPv6 Source Router ID | y | y | + +------+-----------------------------------------+-----+-----+ + | 32 | BIER Info | n | n | + +------+-----------------------------------------+-----+-----+ + + Table 4 + + This document registers the following in the "OSPFv2 Extended Prefix + TLV Sub-TLVs" registry: + + +=======+=========================================+===============+ + | Value | TLV Name | Reference | + +=======+=========================================+===============+ + | 6 | OSPFv2 IP Algorithm Prefix Reachability | RFC 9502, | + | | | Section 6.3 | + +-------+-----------------------------------------+---------------+ + | 7 | OSPFv2 IP Forwarding Address | RFC 9502, | + | | | Section 6.3.1 | + +-------+-----------------------------------------+---------------+ + + Table 5 + + IANA has created the "IP Algorithm Prefix Reachability Sub-TLV Flags" + registry within the "Open Shortest Path First v2 (OSPFv2) Parameters" + group of registries. The new registry defines the bits in the 8-bit + Flags field in the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV + (Section 6.3). New bits can be allocated via IETF Review or IESG + Approval [RFC8126] + + +=====+============+=======================+ + | Bit | Name | Reference | + +=====+============+=======================+ + | 0 | E bit | RFC 9502, Section 6.3 | + +-----+------------+-----------------------+ + | 1-7 | Unassigned | | + +-----+------------+-----------------------+ + + Table 6 + + This document registers the following in the "OSPFv3 Extended-LSA + Sub-TLVs" registry: + + +=======+=======================+======+=============+ + | Value | Description | L2BM | Reference | + +=======+=======================+======+=============+ + | 35 | OSPFv3 IP Algorithm | X | RFC 9502, | + | | Prefix Reachability | | Section 6.4 | + +-------+-----------------------+------+-------------+ + | 36 | OSPFv3 IP Flexible | X | RFC 9502, | + | | Algorithm ASBR Metric | | Section 6.5 | + +-------+-----------------------+------+-------------+ + + Table 7 + + This document registers the following in the "OSPFv2 Extended Inter- + Area ASBR Sub-TLVs" registry: + + +=======+========================================+=============+ + | Value | Description | Reference | + +=======+========================================+=============+ + | 2 | OSPF IP Flexible Algorithm ASBR Metric | RFC 9502, | + | | | Section 6.5 | + +-------+----------------------------------------+-------------+ + + Table 8 + +12. Security Considerations + + This document inherits security considerations from [RFC9350]. + + This document adds one new way to disrupt IGP networks that are using + Flexible Algorithm: an attacker can suppress reachability for a given + prefix whose reachability is advertised by a legitimate node for a + particular IP Flex-Algorithm X by advertising the same prefix in + Flex-Algorithm Y from another malicious node. (To see why this is, + consider, for example, the rule given in the second-to-last paragraph + of Section 6.1). + + This attack can be addressed by the existing security extensions, as + described in [RFC5304] and [RFC5310] for IS-IS, in [RFC2328] and + [RFC7474] for OSPFv2, and in [RFC4552] and [RFC5340] for OSPFv3. + + If a node that is authenticated is taken over by an attacker, such a + rogue node can perform the attack described above. Such an attack is + not preventable through authentication, and it is not different from + advertising any other incorrect information through IS-IS or OSPF. + +13. References + +13.1. Normative References + + [ISO10589] ISO, "Information technology - Telecommunications and + information exchange between systems - Intermediate System + to Intermediate System intra-domain routeing information + exchange protocol for use in conjunction with the protocol + for providing the connectionless-mode network service (ISO + 8473)", Second Edition, ISO/IEC 10589:2002, November 2002. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, + DOI 10.17487/RFC2328, April 1998, + <https://www.rfc-editor.org/info/rfc2328>. + + [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality + for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, + <https://www.rfc-editor.org/info/rfc4552>. + + [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, + <https://www.rfc-editor.org/info/rfc4915>. + + [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, + <https://www.rfc-editor.org/info/rfc5120>. + + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, DOI 10.17487/RFC5304, October + 2008, <https://www.rfc-editor.org/info/rfc5304>. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, October + 2008, <https://www.rfc-editor.org/info/rfc5305>. + + [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, + DOI 10.17487/RFC5308, October 2008, + <https://www.rfc-editor.org/info/rfc5308>. + + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, DOI 10.17487/RFC5310, February + 2009, <https://www.rfc-editor.org/info/rfc5310>. + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, Ed., + "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July + 2008, <https://www.rfc-editor.org/info/rfc5340>. + + [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., + "Security Extension for OSPFv2 When Using Manual Key + Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, + <https://www.rfc-editor.org/info/rfc7474>. + + [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, <https://www.rfc-editor.org/info/rfc7770>. + + [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions + for Advertising Router Information", RFC 7981, + DOI 10.17487/RFC7981, October 2016, + <https://www.rfc-editor.org/info/rfc7981>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [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, <https://www.rfc-editor.org/info/rfc8362>. + + [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., + and A. Gulko, "IGP Flexible Algorithm", RFC 9350, + DOI 10.17487/RFC9350, February 2023, + <https://www.rfc-editor.org/info/rfc9350>. + + [RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., + and Z. Hu, "IS-IS Extensions to Support Segment Routing + over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, + February 2023, <https://www.rfc-editor.org/info/rfc9352>. + +13.2. Informative References + + [IANA-ALG] IANA, "IGP Algorithm Types", + <https://www.iana.org/assignments/igp-parameters>. + + [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, + <https://www.rfc-editor.org/info/rfc5286>. + + [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, + <https://www.rfc-editor.org/info/rfc7490>. + + [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, + <https://www.rfc-editor.org/info/rfc8126>. + + [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, <https://www.rfc-editor.org/info/rfc8402>. + + [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, + <https://www.rfc-editor.org/info/rfc8986>. + + [TS.23.501-3GPP] + 3GPP, "System architecture for 5G System (5GS)", Release + 18.3.0, 3GPP TS 23.501, September 2023. + +Acknowledgements + + Thanks to Bruno Decraene for his contributions to this document. + Special thanks to Petr Bonbon Adamec of Cesnet for supporting + interoperability testing. + +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 + + + 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 + Mlynske nivy 43 + 82109 Bratislava + Slovakia + Email: ppsenak@cisco.com |