IGP Flexible Algorithm in IP Networks Juniper Networks
Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India bwilliam@juniper.net
Juniper Networks
Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India shraddha@juniper.net
Juniper Networks
Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India pkaneria@juniper.net
Juniper Networks
Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India mrajesh@juniper.net
Juniper Networks
2251 Corporate Park Drive Herndon 20171 Virginia United States of America rbonica@juniper.net
Cisco Systems
Apollo Business Center Mlynske nivy 43 Bratislava 82109 Slovakia ppsenak@cisco.com
rtg lsr IS-IS 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 .
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 () 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
  • .  Introduction
  • .  Requirements Language
  • .  Use Case Example
  • .  Advertising Flexible Algorithm Definitions (FADs)
  • .  Advertising IP Flexible Algorithm Participation
    • .  The IS-IS IP Algorithm Sub-TLV
    • .  The OSPF IP Algorithm TLV
  • .  Advertising IP Flexible Algorithm Reachability
    • .  The IS-IS IPv4 Algorithm Prefix Reachability TLV
    • .  The IS-IS IPv6 Algorithm Prefix Reachability TLV
    • .  The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV
      • .  The OSPFv2 IP Forwarding Address Sub-TLV
    • .  The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV
    • .  The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV
  • .  Calculating of IP Flexible Algorithm Paths
  • .  IP Flexible Algorithm Forwarding
  • .  Deployment Considerations
  • . Protection
  • . IANA Considerations
  • . Security Considerations
  • . References
    • .  Normative References
    • .  Informative References
  • Acknowledgements
  • Authors' Addresses
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 computes a constraint-based path to:
  • All Flexible-Algorithm-specific Prefix Segment Identifiers (SIDs) .
  • All Flexible-Algorithm-specific SRv6 Locators .
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.
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 when, and only when, they appear in all capitals, as shown here.
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 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.
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 , , and of .
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 . 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 . 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.
The IS-IS IP Algorithm Sub-TLV The IS-IS IP Algorithm Sub-TLV is a sub-TLV of the IS-IS Router Capability TLV and has the following format:
IS-IS IP Algorithm Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
The OSPF IP Algorithm TLV The OSPF IP Algorithm TLV is a top-level TLV of the Router Information Opaque Link State Advertisement (LSA) and has the following format:
OSPF IP Algorithm TLV 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 | | +- -+ | | + +
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.
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.
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:
IS-IS IPv4 Algorithm Prefix Reachability TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 . Note that the value 0 is legal.
Followed by one or more prefix entries of the form:
IS-IS IPv4 Algorithm Prefix Reachability TLV 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) . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Metric (4 octets):
Metric information as defined in
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 . 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 and an IPv4 Algorithm Prefix Reachability TLV, the IPv4 Prefix Reachability advertisement MUST be preferred when installing entries in the forwarding plane.
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 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 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.
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:
OSPFv2 IP Algorithm Prefix Reachability Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 octets):
The value is 6
Length (2 octets):
8
MT-ID (1 octet):
Multi-Topology ID as defined in
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 .
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.
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:
OSPFv2 IP Forwarding Address Sub-TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (2 octets):
The value is 7
Length (2 octets):
4
Forwarding Address (4 octets):
The same as defined in
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.
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 :
  • Intra-Area-Prefix TLV
  • Inter-Area-Prefix TLV
  • External-Prefix TLV
The format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is shown below:
OSPFv3 IP Algorithm Prefix Reachability Sub-TLV 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):
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 . 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.
The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV 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 , 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
  • OSPFv3 Inter-Area-Router TLV, as defined in
The OSPF IPFAAM Sub-TLV has the following format:
OSPF IP Flexible Algorithm ASBR Metric Sub-TLV 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):
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 , 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 MUST NOT be used during IP Flexible Algorithm path calculation; the IPFAAM Sub-TLV MUST be used instead.
Calculating of IP Flexible Algorithm Paths The IP Flexible Algorithm is considered as yet another data plane of the Flexible Algorithm as described in . Participation in the IP Flexible Algorithm is signaled as described in and is specific to the IP Flexible Algorithm data plane. Calculation of IP Flexible Algorithm paths follows what is described in . 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 , MUST be pruned from the topology.
IP Flexible Algorithm Forwarding The 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.
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 , is data plane independent and is used by all Flexible Algorithm data planes. Participation in the Flexible Algorithm, as described in , 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.
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)
  • Remote Loop-Free Alternates (R-LFAs)
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.
IANA Considerations This specification updates the "OSPF Router Information (RI) TLVs" registry as follows:
Value TLV Name Reference
21 IP Algorithm RFC 9502,
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,
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 Prefix Reachability n y n n RFC 9502,
127 IPv6 Algorithm Prefix Reachability n y n n RFC 9502,
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
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,
7 OSPFv2 IP Forwarding Address RFC 9502,
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 (). New bits can be allocated via IETF Review or IESG Approval
Bit Name Reference
0 E bit RFC 9502,
1-7 Unassigned
This document registers the following in the "OSPFv3 Extended-LSA Sub-TLVs" registry:
Value Description L2BM Reference
35 OSPFv3 IP Algorithm Prefix Reachability X RFC 9502,
36 OSPFv3 IP Flexible Algorithm ASBR Metric X RFC 9502,
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,
Security Considerations This document inherits security considerations from . 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 ). This attack can be addressed by the existing security extensions, as described in and for IS-IS, in and for OSPFv2, and in and 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.
References Normative References 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) International Organization for Standardization Second Edition Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. OSPF Version 2 This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] Authentication/Confidentiality for OSPFv3 This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK] Multi-Topology (MT) Routing in OSPF This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology. An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK] M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK] IS-IS Cryptographic Authentication This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK] IS-IS Extensions for Traffic Engineering This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK] Routing IPv6 with IS-IS This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK] IS-IS Generic Cryptographic Authentication This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK] OSPF for IPv6 Security Extension for OSPFv2 When Using Manual Key Management The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks. This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header. Extensions to OSPF for Advertising Optional Router Capabilities It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities. IS-IS Extensions for Advertising Router Information This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. This document obsoletes RFC 4971. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. OSPFv3 Link State Advertisement (LSA) Extensibility OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support. IGP Flexible Algorithm IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. Informative References IGP Algorithm Types IANA Basic Specification for IP Fast Reroute: Loop-Free Alternates This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK] Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing over IPv6 (SRv6) Network Programming The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. System architecture for 5G System (5GS) 3GPP Release 18.3.0
Acknowledgements Thanks to for his contributions to this document. Special thanks to of Cesnet for supporting interoperability testing.
Authors' Addresses Juniper Networks
Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India bwilliam@juniper.net
Juniper Networks
Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India shraddha@juniper.net
Juniper Networks
Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India pkaneria@juniper.net
Juniper Networks
Elnath-Exora Business Park Survey Bangalore Karnataka 560103 India mrajesh@juniper.net
Juniper Networks
2251 Corporate Park Drive Herndon 20171 Virginia United States of America rbonica@juniper.net
Cisco Systems
Apollo Business Center Mlynske nivy 43 Bratislava 82109 Slovakia ppsenak@cisco.com