idnits 2.17.1 draft-ietf-lsr-ip-flexalgo-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 16, 2022) is 711 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0791' is defined on line 786, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC7684' is defined on line 823, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 847, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-19 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group W. Britto 3 Internet-Draft S. Hegde 4 Intended status: Standards Track P. Kaneriya 5 Expires: November 17, 2022 R. Shetty 6 R. Bonica 7 Juniper Networks 8 P. Psenak 9 Cisco Systems 10 May 16, 2022 12 IGP Flexible Algorithms (Flex-Algorithm) In IP Networks 13 draft-ietf-lsr-ip-flexalgo-06 15 Abstract 17 An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute 18 constraint-based paths. The base IGP Flex-Algorithm specification 19 describes how it is used with Segment Routing (SR) data planes - SR 20 MPLS and SRv6. 22 This document extends IGP Flex-Algorithm, so that it can be used with 23 regular IPv4 and IPv6 forwarding. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 17, 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Use Case Example . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Advertising Flex-Algorithm Definitions (FAD) . . . . . . . . 3 63 5. Advertising IP Flex-Algorithm Participation . . . . . . . . . 3 64 5.1. The IS-IS IP Algorithm Sub-TLV . . . . . . . . . . . . . 4 65 5.2. The OSPF IP Algorithm TLV . . . . . . . . . . . . . . . . 5 66 6. Advertising IP Flex-Algorthm Reachability . . . . . . . . . . 6 67 6.1. The IS-IS IPv4 Algorithm Prefix Reachability TLV . . . . 6 68 6.2. The IS-IS IPv6 Algorithm Prefix Reachability TLV . . . . 8 69 6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV . . . 9 70 6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV . . . 10 71 6.5. The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV . . . 11 72 7. Calculating of IP Flex-Algorthm Paths . . . . . . . . . . . . 13 73 8. IP Flex-Algorthm Forwarding . . . . . . . . . . . . . . . . . 13 74 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 13 75 10. Protection . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 81 14.2. Informative References . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 An IGP Flex-Algorithm as specified in [I-D.ietf-lsr-flex-algo] 87 computes a constraint-based path to: 89 o All Flex-Algorithm specific Prefix Segment Identifiers (SIDs) 90 [RFC8402]. 92 o All Flex-Algorithm specific SRv6 Locators [RFC8986]. 94 Therefore, Flex-Algorithm cannot be deployed in the absence of SR and 95 SRv6. 97 This document extends Flex-Algorithm, allowing it to compute paths to 98 IPv4 and IPv6 prefixes. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 3. Use Case Example 110 Mobile networks are becoming more and more IP centric. Each end-user 111 session from a gNB (gNodeB) can be destined to a specific UPFs (User 112 Plane Function) based on the session requirements. For example, some 113 sessions require high bandwidth, others need to be routed along the 114 lowest latency path. Each UPF is assigned a unique IP address. As a 115 result, traffic for different sessions is destined to a different 116 destination IP address. 118 By associating the prefix that contains the UPF addresses with a 119 specific IP algorithm and routing the algorithm specific traffic 120 according to a certain constraints, e.g., low latency, a session 121 traffic is routed according to the SLA (Service Level Agreement) 122 appropriate for such session. 124 4. Advertising Flex-Algorithm Definitions (FAD) 126 To guarantee loop free forwarding, all routers that participate in a 127 Flex-Algorithm MUST agree on the Flex-Algorithm Definition (FAD). 129 Selected nodes within the IGP domain MUST advertise FADs as described 130 in Sections 5, 6, and 7 of [I-D.ietf-lsr-flex-algo]. 132 5. Advertising IP Flex-Algorithm Participation 134 A node may use various algorithms when calculating paths to nodes and 135 prefixes. Algorithm values are defined in the IGP Algorithm Type 136 Registry [IANA-ALG]. 138 A node MUST participate in a Flex-Algorithm to be: 140 o Able to compute path for such Flex-Algorithm 142 o Part of the topology for such Flex-Algorithm 143 Flex-Algorithm participation MUST be advertised for each Flex- 144 Algorithm data-plane independently, as specified in 145 [I-D.ietf-lsr-flex-algo]. Using Flex-Algorithm for regular IPv4 and 146 IPv6 prefixes represents an independent Flex-Algorithm data-plane, 147 and as such, the Flex-Algorithm participation for the IP Flex- 148 Algorithm data-plane MUST be signalled independently of any other 149 Flex-Algorithm data-plane (e.g., SR). 151 Advertisement of participation in IP Flex-Algorithm MUST NOT impact 152 the router participation in default algorithm 0. 154 Advertisement of participation in IP Flex-Algorithm MUST NOT impact 155 the router participation signaled for other data-planes. 157 The following sections describe how the IP Flex-Algorithm 158 participation is advertised in IGP protocols. 160 5.1. The IS-IS IP Algorithm Sub-TLV 162 The ISIS [ISO10589] IP Algorithm Sub-TLV is a sub-TLV of the IS-IS 163 Router Capability TLV [RFC7981] and has the following format: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1: IS-IS IP Algorithm Sub-TLV 175 o Type: IP Algorithm Sub-TLV (Value 29) 177 o Length: Variable 179 o Algorithm (1 octet): Value from 128 to 255. 181 The IP Algorithm Sub-TLV MUST be propagated throughout the level and 182 MUST NOT be advertised across level boundaries. Therefore, the S bit 183 in the Router Capability TLV, in which the IP Algorithm Sub-TLV is 184 advertised, MUST NOT be set. 186 The IP Algorithm Sub-TLV is optional. It MUST NOT be advertised more 187 than once at a given level. A router receiving multiple IP Algorithm 188 sub-TLVs from the same originator MUST select the first advertisement 189 in the lowest-numbered LSP and subsequent instances of the IP 190 Algorithm Sub-TLV MUST be ignored. 192 The use of IP Algorithm Sub-TLV to advertise support for algorithms 193 outside the Flex-Algorithm range (128-255) is outside the scope of 194 this document. 196 The IP Flex-Algorithm participation advertised in the IS-IS IP 197 Algorithm Sub-TLV is topology independent. When a router advertises 198 participation in the IS-IS IP Algorithm Sub-TLV, the participation 199 applies to all topologies in which the advertising node participates. 201 5.2. The OSPF IP Algorithm TLV 203 The OSPF [RFC2328] IP Algorithm TLV is a top-level TLV of the Router 204 Information Opaque LSA [RFC7770] and has the following format: 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Type | Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Algorithm 1 | Algorithm... | Algorithm n | | 212 +- -+ 213 | | 214 + + 216 Figure 2: OSPF IP Algorithm TLV 218 o Type: IP Algorithm TLV (Value TBD by IANA) 220 o Length: Variable 222 o Algorithm (1 octet): Value from 128 to 255. 224 The IP Algorithm TLV is optional. It MUST only be advertised once in 225 the Router Information LSA. 227 When multiple IP Algorithm TLVs are received from a given router, the 228 receiver MUST use the first occurrence of the TLV in the Router 229 Information LSA. If the IP Algorithm TLV appears in multiple Router 230 Information LSAs that have different flooding scopes, the IP 231 Algorithm TLV in the Router Information LSA with the area-scoped 232 flooding scope MUST be used. If the IP Algorithm TLV appears in 233 multiple Router Information LSAs that have the same flooding scope, 234 the IP Algorithm TLV in the Router Information LSA with the 235 numerically smallest Instance ID (Opaque ID for OSPFv2 or Link State 236 ID for OSPFv3) MUST be used and subsequent instances of the IP 237 Algorithm TLV MUST be ignored. 239 The Router Information LSA can be advertised at any of the defined 240 flooding scopes (link, area, or Autonomous System (AS)). For the 241 purpose of IP Algorithm TLV advertisement, area-scoped flooding is 242 REQUIRED. 244 The IP Flex-Algorithm participation advertised in the OSPF IP 245 Algorithm TLV is topology independent. When a router advertises 246 participation in OSPF IP Algorithm TLV, the participation applies to 247 all topologies in which the advertising node participates. 249 6. Advertising IP Flex-Algorthm Reachability 251 To be able to associate the prefix with the Flex-Algorithm, the 252 existing prefix reachability advertisements can not be used, because 253 they advertise the prefix reachability in default algorithm 0. 254 Instead, a new IP Flex-Algorithm reachability advertisements are 255 defined in IS-IS and OSPF. 257 The M-flag in FAD is not applicable to IP Algorithm Prefixes. Any IP 258 Algorithm Prefix advertisement includes the Algorithm and Metric 259 fields. When an IP Algorithm Prefix is advertised between areas or 260 domains, the metric field in the IP Algorithm Prefix advertisement 261 MUST be used irrespective of the M-flag in the FAD advertisement. 263 6.1. The IS-IS IPv4 Algorithm Prefix Reachability TLV 265 A top-level TLV is defined for advertising IPv4 Flex-Algorithm Prefix 266 Reachability in IS-IS - IPv4 Algorithm Prefix Reachability TLV. 268 This new TLV shares the sub-TLV space defined for TLVs Advertising 269 Prefix Reachability. 271 The IS-IS IPv4 Algorithm Prefix Reachability TLV has the following 272 format: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Type | Length |R|R|R|R| MTID | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 3: IS-IS IPv4 Algorithm Prefix Reachability TLV 282 o Type: IPv4 Algorithm Prefix Reachability TLV (Value 126). 284 o Length: Variable. 286 o R bits (4 bits): Reserved for future use. They MUST be set to 287 zero on transmission and MUST be ignored on receipt. 289 o MTID (12 bits): Multitopology Identifier as defined in [RFC5120]. 290 Note that the value 0 is legal. 292 Followed by one or more prefix entries of the form: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Metric | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Flags | Algorithm | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Pfx Length | Prefix (variable)... 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Sub-tlv-len | Sub-TLVs (variable) . . . | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 4: IS-IS IPv4 Algorithm Prefix Reachability TLV 308 o Metric (4 octets): Metric information. 310 o Flags (1 octet): 312 0 1 2 3 4 5 6 7 313 +-+-+-+-+-+-+-+-+ 314 |D| Reserved | 315 +-+-+-+-+-+-+-+-+ 317 D-flag: When the Prefix is leaked from level-2 to level-1, the 318 D bit MUST be set. Otherwise, this bit MUST be clear. 319 Prefixes with the D bit set MUST NOT be leaked from level-1 to 320 level-2. This is to prevent looping. 322 o Algorithm (1 octet): Associated Algorithm from 128 to 255. 324 o Prefix Len (1 octet): Prefix length measured in bits. 326 o Prefix (variable length): Prefix mapped to Flex-Algorithm. 328 o Optional Sub-TLV-length (1 octet): Number of octets used by sub- 329 TLVs 331 o Optional sub-TLVs (variable length). 333 A router receiving multiple IPv4 Algorithm Prefix Reachability 334 advertisements for the same prefix, from the same originator, each 335 with a different Algorithm, MUST select the first advertisement in 336 the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm 337 Prefix Reachability advertisements for the same prefix for any other 338 Algorithm. 340 A router receiving multiple IPv4 Algorithm Prefix Reachability 341 advertisements for the same prefix, from different originators, each 342 with a different Algorithm, MUST ignore all of them and MUST NOT 343 install any forwarding entries based on these advertisements. This 344 situation SHOULD be logged as an error. 346 In cases where a prefix advertisement is received in both a IPv4 347 Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability 348 TLV, the IPv4 Prefix Reachability advertisement MUST be preferred 349 when installing entries in the forwarding plane. 351 6.2. The IS-IS IPv6 Algorithm Prefix Reachability TLV 353 The IS-IS IPv6 Algorithm Prefix Reachability TLV is identical to the 354 IS-IS IPv4 Algorithm Prefix Reachability TLV, except that it has a 355 unique type. The type is 127. 357 A router receiving multiple IPv6 Algorithm Prefix Reachability 358 advertisements for the same prefix, from the same originator, each 359 with a different Algorithm, MUST select the first advertisement in 360 the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm 361 Prefix Reachability advertisements for the same prefix for any other 362 Algorithm. 364 A router receiving multiple IPv6 Algorithm Prefix Reachability 365 advertisements for the same prefix, from different originators, each 366 with a different Algorithm, MUST ignore all of them and MUST NOT 367 install any forwarding entries based on these advertisements. This 368 situation SHOULD be logged as an error. 370 In cases where a prefix advertisement is received in both an IPv6 371 Prefix Reachability TLV and an IPv6 Algorithm Prefix Reachability 372 TLV, the IPv6 Prefix Reachability advertisement MUST be preferred 373 when installing entries in the forwarding plane. 375 In cases where a prefix advertisement is received in both IS-IS SRv6 376 Locator TLV and in IS-IS IPv6 Algorithm Prefix Reachability TLV, the 377 receiver MUST ignore both of them and MUST NOT install any forwarding 378 entries based on these advertisements. This situation SHOULD be 379 logged as an error. 381 6.3. The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV 383 A new Sub-TLV of the OSPFv2 Extended Prefix TLV is defined for 384 advertising IP Algorithm Prefix Reachability in OSPFv2, the OSPFv2 IP 385 Algorithm Prefix Reachability Sub-TLV. 387 The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV has the following 388 format: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Type | Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | MT-ID | Algorithm | Reserved | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Metric | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 5: OSPFv2 IP Algorithm Prefix Reachability Sub-TLV 402 o Type (2 octets) : The value is TBD. 404 o Length (2 octet): 8 406 o MT-ID (1 octet): Multi-Topology ID as defined in [RFC4915] 408 o Algorithm (1 octet): Associated Algorithm from 128 to 255. 410 o Reserved: (2 octets). SHOULD be set to 0 on transmission and MUST 411 be ignored on reception. 413 o Metric (4 octets): The algorithm specific metric value. 415 An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix 416 Reachability Sub-TLVs in the same OSPFv2 Extended Prefix TLV, MUST 417 select the first advertisement of this Sub-TLV and MUST ignore all 418 remaining occurences of this Sub-TLV in the OSPFv2 Extended Prefix 419 TLV. 421 An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix 422 Reachability TLVs for the same prefix, from different originators, 423 each with a different Algorithm, MUST ignore all of them and MUST NOT 424 install any forwarding entries based on these advertisements. This 425 situation SHOULD be logged as an error. 427 In cases where a prefix advertisement is received in any of the LSAs 428 advertising the prefix reachability for algorithm 0 and in an OSPFv2 429 IP Algorithm Prefix Reachability TLV, only the prefix reachability 430 advertisement for algorithm 0 MUST be used and all occurences of the 431 OSPFv2 IP Algorithm Prefix Reachability TLV MUST be ignored. 433 6.4. The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV 435 The OSPFv3 [RFC5340] IP Algorithm Prefix Reachability Sub-TLV is 436 defined for advertisement of the IP Algorithm Prefix Reachability in 437 OSPFv3. 439 The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is a sub-TLV of 440 the following OSPFv3 TLVs defined in [RFC8362]: 442 o Intra-Area-Prefix TLV 444 o Inter-Area-Prefix TLV 446 o External-Prefix TLV 448 The format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is 449 shown below: 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Type | Length | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Algorithm | Reserved | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Metric | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 6: OSPFv3 IP Algorithm Prefix Reachability Sub-TLV 463 Where: 465 Type (2 octets): The value is TBD. 467 Length (2 octets): 8. 469 Algorithm (1 octet): Associated Algorithm from 128 to 255. 471 Reserved: (3 octets). SHOULD be set to 0 on transmission and MUST 472 be ignored on reception. 474 Metric (4 octets): The algorithm specific metric value. 476 When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is present, 477 the metric value in its parent TLV MUST be set to LSInfinity 478 [RFC2328]. If the metric value in the parent TLV is not set to 479 LSInfinity, the OSPFv3 IP Algorithm Prefix Sub-TLV MUST be ignored by 480 the receiver. 482 An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix 483 Reachability Sub-TLVs in the same parent TLV, MUST select the first 484 advertisement of this Sub-TLV and MUST ignore all remaining 485 occurences of this Sub-TLV in the parent TLV. 487 An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix 488 Reachability TLVs for the same prefix, from different originators, 489 each with a different Algorithm, MUST ignore all of them and MUST NOT 490 install any forwarding entries based on these advertisements. This 491 situation SHOULD be logged as an error. 493 In cases where a prefix advertisement is received in any of the LSAs 494 advertising the prefix reachability for algorithm 0 and in an OSPFv3 495 OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, only the prefix 496 reachability advertisement for algorithm 0 MUST be used and all 497 occurences of the OSPFv3 IP Algorithm Prefix Reachability TLV MUST be 498 ignored. 500 In cases where a prefix advertisement is received in both an OSPFv3 501 SRv6 Locator TLV and in an OSPFv3 IP Algorithm Prefix Reachability 502 Sub-TLV, the receiver MUST ignore both of them and MUST NOT install 503 any forwarding entries based on these advertisements. This situation 504 SHOULD be logged as an error. 506 6.5. The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV 508 [I-D.ietf-lsr-flex-algo] defines the OSPF Flexible Algorithm ASBR 509 Metric Sub-TLV (FAAM) that is used by an OSPFv2 or an OSPFv3 ABR to 510 advertise a Flex-Algorithm specific metric associated with the 511 corresponding ASBR LSA. 513 As described in [I-D.ietf-lsr-flex-algo] each data-plane signals the 514 participation independently. IP Flex-Algorithm participation is 515 signaled independent of the Segment Routing (SR) Flex-Algorithm 516 participation. As a result, the calculated topologies for SR and IP 517 Flex-Algorithm could be different. Such difference prevents the 518 usage of FAAM for the purpose of the IP Flex-Algorithm. 520 The OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is 521 defined for the advertisement of the IP Flex-Algorithm specific 522 metric associated with an ASBR by the ABR. 524 The IPFAAM Sub-TLV is a Sub-TLV of the: 526 - OSPFv2 Extended Inter-Area ASBR TLV as defined in 527 [I-D.ietf-lsr-flex-algo] 529 - OSPFv3 Inter-Area-Router TLV defined in [RFC8362] 531 The OSPF IPFAAM Sub-TLV has the following format: 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type | Length | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Algorithm | Reserved | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Metric | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 where: 545 Figure 7: OSPF IP Flexible Algorithm ASBR Metric Sub-TLV 547 Type (2 octets): TBD for OSPFv2, TBD for OSPFv3. 549 Length (2 octets): 8. 551 Algorithm (1 octet): Associated Algorithm from 128 to 255. 553 Reserved: (3 octets). SHOULD be set to 0 on transmission and MUST 554 be ignored on reception. 556 Metric (4 octets): The algorithm specific metric value. 558 The usage of the IPFAAM Sub-TLV is similar to the usage of the FAAM 559 Sub-TLV defined in [I-D.ietf-lsr-flex-algo], but it is used to 560 advertise IP Flex-Algorithm metric. 562 An OSPF ABR MUST include the OSPF IPFAAM Sub-TLVs as part of the ASBR 563 reachability advertisement between areas for every IP Flex-Algorithm 564 in which it participates and the ASBR is reachable in. 566 The FAAM Sub-TLV as defined in [I-D.ietf-lsr-flex-algo] MUST NOT be 567 used during IP Flex-Algorithm path calculation, the IPFAAM Sub-TLV 568 MUST be used instead. 570 7. Calculating of IP Flex-Algorthm Paths 572 The IP Flex-Algorthm is considered as yet another data-plane of the 573 Flex-Algorithm as described [I-D.ietf-lsr-flex-algo]. 575 Participation for the IP Flex-Algorithm is signalled as described in 576 Section 5 and is specific to the IP Flex-Algorithm data-plane. 578 Calculation of IP Flex-Algorithm paths follows what is described in 579 [I-D.ietf-lsr-flex-algo]. This computation uses the IP Flex- 580 Algorithm data-plane participation and is independent of the Flex- 581 Algorithm calculation done for any other Flex-Algorithm data-plane 582 (e.g., SR, SRv6). 584 The IP Flex-Algorithm data-plane only considers participating nodes 585 during the Flex-Algorithm calculation. When computing paths for a 586 given Flex-Algorithm, all nodes that do not advertise participation 587 for the IP Flex-Algorithm, as described in Section 5, MUST be pruned 588 from the topology. 590 8. IP Flex-Algorthm Forwarding 592 The IP Algorithm Prefix Reachability advertisement as described in 593 Section 5 includes the MTID value that associates the prefix with a 594 specific topology. Algorithm Prefix Reachability advertisement also 595 includes an Algorithm value that explicitly associates the prefix 596 with a specific Flex-Algorithm. The paths to the prefix MUST be 597 calculated using the specified Flex-Algorithm in the associated 598 topology. 600 Forwarding entries for the IP Flex-Algorithm prefixes advertised in 601 IGPs MUST be installed in the forwarding plane of the receiving IP 602 Flex-Algorithm prefix capable routers when they participate in the 603 associated topology and algorithm. Forwarding entries for IP Flex- 604 Algorithm prefixes associated with Flex-Algorithms in which the node 605 is not participating MUST NOT be installed in the forwarding plane. 607 When the IP Flex-Algorithm prefix is associated with a Flex- 608 Algorithm, LFA paths to the prefix MUST be calculated using such 609 Flex-Algorithm in the associated topology, to guarantee that they 610 follow the same constraints as the calculation of the primary paths. 612 9. Deployment Considerations 614 IGP Flex-Algorithm can be used by many data-planes. The original 615 specification was done for SR and SRv6, this specification adds IP as 616 another data-plane that can use IGP Flex-Algorithm. Other data- 617 planes may be defined in the future. This section provides some 618 details about the coexistence of the various data-planes of an IGP 619 Flex-Algorithm. 621 Flex-Algorithm definition (FAD), as described in 622 [I-D.ietf-lsr-flex-algo], is data-plane independent and is used by 623 all Flex-Algorithm data-planes. 625 Participation in the Flex-Algorithm, as described in 626 [I-D.ietf-lsr-flex-algo], is data-plane specific. 628 Calculation of the flex-algo paths is data-plane specific and uses 629 data-plane specific participation advertisements. 631 Data-plane specific participation and calculation guarantee that the 632 forwarding of the traffic over the Flex-Algorithm data-plane specific 633 paths is consistent between all nodes that apply the IGP Flex- 634 Algorithm to the data-plane. 636 Multiple data-planes can use the same Flex-Algorithm value at the 637 same time and, and as such, share the FAD for it. For example, SR- 638 MPLS and IP can both use a common Flex-Algorithm. Traffic for SR- 639 MPLS will be forwarded based on Flex-algorithm specific SR SIDs. 640 Traffic for IP Flex-Algorithm will be forwarded based on Flex- 641 Algorithm specific prefix reachability advertisements. Note that for 642 a particular Flex-Algorithm, for a particular IP prefix, there will 643 only be path(s) calculated and installed for a single data-plane. 645 10. Protection 647 In many networks where IGP Flexible Algorithms are deployed, IGP 648 restoration will be fast and additional protection mechanisms will 649 not be required. IGP restoration may be enhanced by Equal Cost 650 Multipath (ECMP). 652 In other networks, operators can deploy additional protection 653 mechanisms. The following are examples: 655 o Loop Free Alternates (LFA) [RFC5286] 657 o Remote Loop Free Alternates (R-LFA) [RFC7490] 659 LFA and R-LFA computations MUST be restricted to the flex-algo 660 topology and the computed backup nexthops should be programmed for 661 the IP flex-algo prefixes. 663 11. IANA Considerations 665 This specification updates the OSPF Router Information (RI) TLVs 666 Registry as follows: 668 +-------+------------------+---------------------------+ 669 | Value | TLV Name | Reference | 670 +-------+------------------+---------------------------+ 671 | TBD | IP Algorithm TLV | This Document Section 5.2 | 672 +-------+------------------+---------------------------+ 674 Table 1 676 This document also updates the ISIS "Sub-TLVs for TLV 242" registry 677 as follows: 679 +-------+----------------------+---------------------------+ 680 | Value | TLV Name | Reference | 681 +-------+----------------------+---------------------------+ 682 | 29 | IP Algorithm Sub-TLV | This Document Section 5.1 | 683 +-------+----------------------+---------------------------+ 685 Table 2 687 This document also updates the "IS-IS TLV Codepoints Registry" 688 registry as follows: 690 +-------+------------------+-----+-----+-----+-------+--------------+ 691 | Value | TLV Name | IIH | LSP | SNP | Purge | Reference | 692 +-------+------------------+-----+-----+-----+-------+--------------+ 693 | 126 | IPv4 Algorithm | N | Y | N | N | This | 694 | | Prefix | | | | | document, | 695 | | Reachability TLV | | | | | Section 6.1 | 696 | 127 | IPv6 Algorithm | N | Y | N | N | This | 697 | | Prefix | | | | | document, | 698 | | Reachability TLV | | | | | Section 6.2 | 699 +-------+------------------+-----+-----+-----+-------+--------------+ 701 Table 3 703 The above TLVs share the sub-TLV space defined in "IS-IS Sub-TLVs for 704 TLVs Advertising Prefix Reachability". This document updates the 705 description of that registry by including IPv4 Algorithm Prefix 706 Reachability TLV and IPv6 Algorithm Prefix Reachability TLV. It also 707 includes these TLVs in a table which lists the presence of Sub-TLVs 708 in a parent TLVs as follows: 710 Type Description 126 127 711 ---- ---------------------------------- --- --- 712 1 32-bit Administrative Tag Sub-TLV y y 713 2 64-bit Administrative Tag Sub-TLV y y 714 3 Prefix Segment Identifier n n 715 4 Prefix Attribute Flags y y 716 5 SRv6 End SID n n 717 6 Flex-Algorithm Prefix Metric n n 718 11 IPv4 Source Router ID y y 719 12 IPv6 Source Router ID y y 720 32 BIER Info n n 722 This document updates the "OSPFv2 Extended Prefix TLV Sub-TLVs" 723 registry as follows: 725 +-------+-----------------------------------+-----------------------+ 726 | Value | TLV Name | Reference | 727 +-------+-----------------------------------+-----------------------+ 728 | TBD | OSPFv2 IP Algorithm Prefix | This Document, | 729 | | Reachability TLV | Section 6.3 | 730 +-------+-----------------------------------+-----------------------+ 732 Table 4 734 This document updates the "OSPFv3 Extended-LSA Sub-TLVs" registry as 735 follows: 737 +-------+-------------------------------------+---------------------+ 738 | Value | TLV Name | Reference | 739 +-------+-------------------------------------+---------------------+ 740 | TBD | OSPFv3 IP Algorithm Prefix | This Document, | 741 | | Reachability Sub-TLV | Section 6.4 | 742 | TBD | OSPFv3 IP Flexible Algorithm ASBR | This Document, | 743 | | Metric Sub-TLV | Section 6.5 | 744 +-------+-------------------------------------+---------------------+ 746 Table 5 748 This document updates the "OSPFv2 Extended Inter-Area ASBR Sub-TLVs" 749 registry as follows: 751 +-------+------------------------------------+----------------------+ 752 | Value | TLV Name | Reference | 753 +-------+------------------------------------+----------------------+ 754 | 2 | OSPF IP Flexible Algorithm ASBR | This Document, | 755 | | Metric Sub-TLV | Section 6.5 | 756 +-------+------------------------------------+----------------------+ 758 Table 6 760 12. Security Considerations 762 This document inherits security considerations from 763 [I-D.ietf-lsr-flex-algo]. 765 13. Acknowledgements 767 Thanks to Bruno Decraene for his contributions to this document. 768 Special thanks to Petr Bonbon Adamec of Cesnet for supporting 769 interoperability testing. 771 14. References 773 14.1. Normative References 775 [I-D.ietf-lsr-flex-algo] 776 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 777 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 778 algo-19 (work in progress), April 2022. 780 [ISO10589] 781 IANA, "Intermediate system to Intermediate system routing 782 information exchange protocol for use in conjunction with 783 the Protocol for providing the Connectionless-mode Network 784 Service (ISO 8473)", August 1987, . 786 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 787 DOI 10.17487/RFC0791, September 1981, 788 . 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, 792 DOI 10.17487/RFC2119, March 1997, 793 . 795 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 796 DOI 10.17487/RFC2328, April 1998, 797 . 799 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 800 (TE) Extensions to OSPF Version 2", RFC 3630, 801 DOI 10.17487/RFC3630, September 2003, 802 . 804 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 805 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 806 RFC 4915, DOI 10.17487/RFC4915, June 2007, 807 . 809 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 810 Topology (MT) Routing in Intermediate System to 811 Intermediate Systems (IS-ISs)", RFC 5120, 812 DOI 10.17487/RFC5120, February 2008, 813 . 815 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 816 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 817 2008, . 819 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 820 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 821 . 823 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 824 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 825 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 826 2015, . 828 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 829 S. Shaffer, "Extensions to OSPF for Advertising Optional 830 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 831 February 2016, . 833 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 834 for Advertising Router Information", RFC 7981, 835 DOI 10.17487/RFC7981, October 2016, 836 . 838 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 839 Writing an IANA Considerations Section in RFCs", BCP 26, 840 RFC 8126, DOI 10.17487/RFC8126, June 2017, 841 . 843 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 844 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 845 May 2017, . 847 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 848 (IPv6) Specification", STD 86, RFC 8200, 849 DOI 10.17487/RFC8200, July 2017, 850 . 852 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 853 F. Baker, "OSPFv3 Link State Advertisement (LSA) 854 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 855 2018, . 857 14.2. Informative References 859 [IANA-ALG] 860 IANA, "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY 861 TLV)", August 1987, . 864 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 865 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 866 DOI 10.17487/RFC5286, September 2008, 867 . 869 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 870 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 871 RFC 7490, DOI 10.17487/RFC7490, April 2015, 872 . 874 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 875 Decraene, B., Litkowski, S., and R. Shakir, "Segment 876 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 877 July 2018, . 879 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 880 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 881 (SRv6) Network Programming", RFC 8986, 882 DOI 10.17487/RFC8986, February 2021, 883 . 885 Authors' Addresses 887 William Britto 888 Juniper Networks 889 Elnath-Exora Business Park Survey 890 Bangalore, Karnataka 560103 891 India 893 Email: bwilliam@juniper.net 894 Shraddha Hegde 895 Juniper Networks 896 Elnath-Exora Business Park Survey 897 Bangalore, Karnataka 560103 898 India 900 Email: shraddha@juniper.net 902 Parag Kaneriya 903 Juniper Networks 904 Elnath-Exora Business Park Survey 905 Bangalore, Karnataka 560103 906 India 908 Email: pkaneria@juniper.net 910 Rejesh Shetty 911 Juniper Networks 912 Elnath-Exora Business Park Survey 913 Bangalore, Karnataka 560103 914 India 916 Email: mrajesh@juniper.net 918 Ron Bonica 919 Juniper Networks 920 2251 Corporate Park Drive 921 Herndon, Virginia 20171 922 USA 924 Email: rbonica@juniper.net 926 Peter Psenak 927 Cisco Systems 928 Apollo Business Center 929 Mlynske nivy 43, Bratislava 82109 930 Slovakia 932 Email: ppsenak@cisco.com