RFC 9502
IGP Flexible Algorithm in IP Networks
RFC 9502: IGP Flexible Algorithm in IP Networks ✨
okay bestie, here's the title block 🎀 this one's from the IETF, and it's a Standards Track doc 👑
- Number: RFC 9502
- Title: IGP Flexible Algorithm in IP Networks
- Authors: W. Britto, S. Hegde, P. Kaneriya, R. Shetty, and R. Bonica (all Juniper Networks), plus P. Psenak (Cisco Systems) 🫶
- Category: Standards Track
- ISSN: 2070-1721
- Date: November 2023
- Obsoletes / Updates: the header doesn't list any, so nothing to report here 🦋
Abstract
okay so the whole point is this: it extends IGP Flexible Algorithm so it can work with plain old IPv4 and IPv6 forwarding 💜
Status of This Memo
this one's an Internet Standards Track document 💅
it's a product of the Internet Engineering Task Force (IETF), so it reflects consensus from the IETF community ✨ it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). for more on Internet Standards, check Section 2 of RFC 7841 🌸
for the current status, errata, and feedback info, go to https://www.rfc-editor.org/info/rfc9502 🔥
Copyright Notice
© 2023 IETF Trust and the people listed as authors, all rights reserved 🌈
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as of the publication date, so read those carefully because they spell out your rights and restrictions 🧚
also, if you pull Code Components out of this doc, they need the Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that 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' Addresses1. Introduction ✨
okay so an IGP Flexible Algorithm lets IGPs compute constraint-based paths 🦋 the base spec explains how it works with Segment Routing (SR) data planes, which means 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].
so, Flexible Algorithm can't be deployed without SR or SRv6 💀 that's the whole dependency chain bestie 🌸
this document extends Flexible Algorithm so it can 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" are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly as shown here 🧚 so if they're lowercase, they're just regular words, no cap 😭
3. Use Case Example 🌈
this section shows one use case that motivates the whole spec: if a specific service can be identified by an IP address, then traffic to that service can use constraint-based paths computed under this specification 🦋
the System architecture for the 5G System [TS.23.501-3GPP] describes the N3 interface between the gNodeB and the UPF (User Plane Function) 📶
mobile networks are getting more and more IP-centric 💜 each end-user session from a gNodeB can be sent to a specific UPF depending on what that session needs. like, some sessions need high bandwidth, while others need the lowest latency path 🏃♀️ each UPF gets its own unique IP address, so traffic for different sessions goes to a different destination IP address. it's giving clean separation 💅
the IP address given to a UPF can be tied to an algorithm 🫶 then the mobile user traffic follows the path based on the algorithm-specific metric and constraints. so traffic can take a route optimized for minimal latency or highest bandwidth 🔥 this is how the network hits a Service Level Agreement (SLA) that fits each user session ✨
4. Advertising Flexible Algorithm Definitions (FADs) 👑
bestie, to guarantee loop-free forwarding, all routers that take part in a Flex-Algorithm MUST agree on the Flexible Algorithm Definition (FAD) 🔒
selected nodes inside the IGP domain MUST advertise FADs as described in Sections 5, 6, and 7 of [RFC9350] 📣
5. Advertising IP Flexible Algorithm Participation 💖
a node can use different algorithms when it calculates paths to nodes and prefixes 🧚 algorithm values are defined in the "IGP Algorithm Types" registry [IANA-ALG] 📋
only a node that's participating in a Flex-Algorithm is:
- Able to compute a path for such Flex-Algorithm
- Part of the topology for such Flex-Algorithm
okay this part is important 🙈 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 counts as its own independent Flexible Algorithm data plane. so the 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 take part in default algorithm 0 🌸 advertising participation in IP Flexible Algorithm does not change a router's participation in default algorithm 0 ✨
advertising participation in IP Flexible Algorithm also doesn't change the participation a router signals for other data planes 🦋 for example, a router can participate in a particular Flex-Algorithm for the IP data plane but not in that same Flex-Algorithm for the SR data plane. it's giving separate lanes 🛣️💅
the next sections describe how IP Flexible Algorithm participation gets 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 it has this 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 🚧 so the S bit in the Router Capability TLV, which is where the IP Algorithm Sub-TLV gets 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 that gets multiple IP Algorithm sub-TLVs from the same originator MUST select the first advertisement in the lowest-numbered Link State PDU (LSP), and any later 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 this way, the participation applies to all topologies the advertising node takes part in ✨
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 it has this 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 come in from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information LSA 👑 if the IP Algorithm TLV shows up in multiple Router Information LSAs with different flooding scopes, the one in the area-scoped Router Information LSA MUST be used 🌸 if it shows up in multiple Router Information LSAs with the same flooding scope, the one with the numerically smallest Instance ID (Opaque ID for OSPFv2 or Link State ID for OSPFv3) MUST be used, and any 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 IP Algorithm TLV advertisement, area- or AS-scoped flooding is REQUIRED 💖 the AS flooding scope SHOULD NOT be used unless the 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 the OSPF IP Algorithm TLV, that participation applies to all topologies the advertising node takes part in ✨
6. Advertising IP Flexible Algorithm Reachability 🦋
okay so bestie, the normal prefix reachability ads can't be reused here 🙅♀️ because they advertise reachability in default algorithm 0. So we get brand new IP Flexible Algorithm reachability advertisements in both IS-IS and OSPF 💖
The M-flag in the FAD is not applicable to IP Algorithm Prefixes 🙈 Every IP Algorithm Prefix advertisement carries 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. no cap, it does not matter what the M-flag says ✨
6.1. The IS-IS IPv4 Algorithm Prefix Reachability TLV 🎀
The IPv4 Algorithm Prefix Reachability top-level TLV is the one for advertising IPv4 Flexible Algorithm Prefix Reachability in IS-IS 🌸
This new TLV shares the sub-TLV space defined for TLVs Advertising Prefix Reachability, so it's giving family 👯♀️
The IS-IS IPv4 Algorithm Prefix Reachability TLV looks like this:
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 the 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 ✨
Then you get one or more prefix entries that look like this:
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. first come, first served, but make it lowest-numbered LSP 💅
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. this is the messy drama, periodt 😭
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. the regular one wins, obviously 👑
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. two different ways of saying "this is a mess", so both get tossed 🙃
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. It's called the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV, and it's iconic 💜
The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV looks like this:
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. first one in, the rest get ghosted 👻
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. algorithm 0 gets the spotlight in this one 🌟
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. so for Flex-Algo prefixes, the Extended Prefix TLV is the star of the show ⭐
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. It's the OSPFv2 IP Forwarding Address Sub-TLV, and it's giving very helpful sidekick energy 🫶
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. hands off algorithm 0, this one is not its problem 🙅♀️
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. only works for the external route types, so anything else just gets ignored, respectfully 💅✨
6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV ✨
Okay bestie, this is the OSPFv3 version of the IP Algorithm Prefix Reachability Sub-TLV 🦋 It's how OSPFv3 ([RFC5340]) advertises IP Algorithm Prefix Reachability, and it's giving main character energy.
The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is a sub-TLV of these OSPFv3 TLVs, which are defined in [RFC8362]:
- Intra-Area-Prefix TLV
- Inter-Area-Prefix TLV
- External-Prefix TLV
Here's what it looks like 🎀
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):
35 - Length (2 octets):
8 - Algorithm (1 octet): the associated Algorithm, from
128to255 - Reserved (3 octets): SHOULD be set to
0on transmission and MUST be ignored on reception. - Metric (4 octets): the algorithm-specific metric value. A metric value of
0XFFFFFFFFMUST be considered unreachable.
If the Algorithms in the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV are outside the Flex-Algorithm range (128-255), the 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 stop 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 there as a network troubleshooting convenience. If it isn't followed, the protocol will still function correctly ✨
An OSPFv3 router that receives 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 it in that parent TLV. 🫶
An OSPFv3 router that receives multiple OSPFv3 IP Algorithm Prefix Reachability TLVs for the same prefix from different originators, where not all of them 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. 😭
When a prefix advertisement is received in any of the LSAs advertising the prefix reachability for algorithm 0 and in an 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. 🌸
When a prefix advertisement is received in both an OSPFv3 SRv6 Locator TLV and 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. An OSPFv2 or OSPFv3 Area Border Router (ABR) uses it 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 independently of SR Flexible Algorithm participation. Because of that, the calculated topologies for SR and IP Flexible Algorithm could be different 👀 That difference is exactly why FAAM can't be used for the purpose of IP Flexible Algorithm.
The OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is defined for advertising the IP Flex-Algorithm-specific metric associated with an ASBR, sent by the ABR. 🦋
The IPFAAM Sub-TLV is a sub-TLV of:
- 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 this 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,36for OSPFv3 - Length (2 octets):
8 - Algorithm (1 octet): the associated Algorithm, from
128to255 - Reserved (3 octets): SHOULD be set to
0on 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 IPFAAM Sub-TLV is used in a similar way to the FAAM Sub-TLV defined in [RFC9350], but it's used to advertise the IP Flexible Algorithm metric instead 💖
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 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 treated 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 it's specific to the IP Flexible Algorithm data plane.
Calculation of IP Flexible Algorithm paths follows what's described in [RFC9350]. This computation uses the IP Flexible Algorithm data plane participation, and it's 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 that 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 described in Section 5 includes the MTID value, which associates the prefix with a specific topology. The 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 written for SR and SRv6, and 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 gives some details about how the various data planes of an IGP Flexible Algorithm coexist 🌈
The 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 it uses data-plane-specific participation advertisements.
Data-plane-specific participation and calculation guarantee that the forwarding of 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 as such they 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 and 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 won't 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:
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 🎀
okay bestie, this part is all about IANA (the folks who keep the registries 🗂️). we're updating a bunch of them so everything lines up, no cap 💅
First up, the "OSPF Router Information (RI) TLVs" registry gets a new entry ✨
+=======+==============+=======================+
| Value | TLV Name | Reference |
+=======+==============+=======================+
| 21 | IP Algorithm | RFC 9502, Section 5.2 |
+-------+--------------+-----------------------+
Table 1Next, the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry gets updated too 🦋
+=======+==============+=======================+
| Value | TLV Name | Reference |
+=======+==============+=======================+
| 29 | IP Algorithm | RFC 9502, Section 5.1 |
+-------+--------------+-----------------------+
Table 2And the "IS-IS Top-Level TLV Codepoints" registry gets two new friends 🌸
+=======+=====================+=====+=====+=====+=======+===========+
| 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 3Okay, here's the tea ☕. Those two TLVs share the sub-TLV space that's managed in the "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry, so IANA added "IPv4 Algorithm Prefix Reachability TLV (126)" and "IPv6 Algorithm Prefix Reachability TLV (127)" to the list of TLVs in that registry's description. It's giving organized 🧚
On top of that, that same registry gets two brand new columns, labeled "126" and "127" 💜
+======+=========================================+=====+=====+
| 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 4Now the OSPFv2 side 🦄 This document registers two entries 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 5IANA also made a brand new registry called "IP Algorithm Prefix Reachability Sub-TLV Flags", sitting inside the "Open Shortest Path First v2 (OSPFv2) Parameters" group of registries 🌈 It defines the bits in the 8-bit Flags field of 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 6Last but not least, the OSPFv3 and OSPFv2 Inter-Area ASBR registries get their new sub-TLVs too ⭐ 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 7And 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 812. Security Considerations 🔐
⚠️ bestie, this section is seriously important, so read it carefully.
This document inherits security considerations from [RFC9350]. 🫶
Okay, so this document adds one NEW way to mess with IGP networks that are using Flexible Algorithm 😭 An attacker can suppress reachability for a given prefix. That prefix's reachability is advertised by a legitimate node for a particular IP Flex-Algorithm X, and the attacker wins by advertising the same prefix in Flex-Algorithm Y from another malicious node. (If you're wondering why that works, check the rule in the second-to-last paragraph of Section 6.1. It's the whole reason 🙈)
Good news though: this attack can be handled by the existing security extensions. For IS-IS, that's [RFC5304] and [RFC5310]. For OSPFv2, it's [RFC2328] and [RFC7474]. For OSPFv3, it's [RFC4552] and [RFC5340]. 🛡️
Now the part that's kinda scary 💀 If a node that is authenticated gets taken over by an attacker, that rogue node can perform the attack described above. Authentication can't prevent that. It's not different from advertising any other incorrect information through IS-IS or OSPF, so keep your eyes open, bestie 👀
13. References 📚
13.1. Normative References 📚✨
okay bestie, these are the docs this whole spec leans on, so they're the ones you need to have open 💅 Every reference below is copied exactly as written, DOIs and URLs included 🔗
[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 🌸
these ones are the extra reading, the background stuff that's good to know but isn't strictly required to build this 🧚 same deal, everything's verbatim
[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 🫶
big thank-yous go out to Bruno Decraene for his contributions to this document 💖 and special shoutout to Petr Bonbon Adamec of Cesnet for supporting interoperability testing 🎀 literally the MVPs
Authors' Addresses 🦋
here are the brains behind the spec, all their details exactly as they're listed 👑
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📦 where this page comes from
- ietf: rfc9502 2023-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms